[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

MEXT Working Group                                              C. Bauer
Internet-Draft                                                   S. Ayaz
Intended status: Informational                                       DLR
Expires: March 13, 2010                                       A. Ebalard
                                                                    EADS
                                                       September 9, 2009


                Solution Space for Aeronautical NEMO RO
                   draft-bauer-mext-aero-solspace-00

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 13, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.







Bauer, et al.            Expires March 13, 2010                 [Page 1]


Internet-Draft       Aeronautical NEMO RO Sol. Space      September 2009


Abstract

   Many potential solutions have been proposed for NEMO Route
   Optimization, although none has been adopted up to now.  This draft
   aims on evaluating the different approaches for the aeronautical use
   case.  At the end, a recommendation for the next steps is given.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Correspondent Router . . . . . . . . . . . . . . . . . . .  6
     3.2.  Global HA to HA  . . . . . . . . . . . . . . . . . . . . .  9
   4.  Next steps . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   5.  Considerations for PIES  . . . . . . . . . . . . . . . . . . . 13
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 16
   Appendix A.  Short Overview of all RO Solutions  . . . . . . . . . 19
     A.1.  Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 19
     A.2.  Applicability to the Aeronautical Environment  . . . . . . 27
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29

























Bauer, et al.            Expires March 13, 2010                 [Page 2]


Internet-Draft       Aeronautical NEMO RO Sol. Space      September 2009


1.  Introduction

   An extensive overview of NEMO Route Optimization (RO) solution
   candidates has been provided in [RFC4889].  The options are manifold
   and obviously the solution has to be adopted based on the operational
   environment.  The task of this draft is to investigate the solutions
   in more detail and highlight the deficiencies of the protocols that
   should be addressed in the future.

   A document listing the requirements that have to be fulfilled by a
   potential aeronautical NEMO RO solution has already been compiled
   [I-D.ietf-mext-aero-reqs].  In addition, another document
   [I-D.bauer-mext-aero-topology] provides information on the
   aeronautical network environment.  We will rely on both to perform
   the investigation.

   It is expected that the reader is familiar with the NEMO Support
   Terminology [RFC4885] and the three above mentioned documents.

































Bauer, et al.            Expires March 13, 2010                 [Page 3]


Internet-Draft       Aeronautical NEMO RO Sol. Space      September 2009


2.  Overview

   The focus of our investigations is on RO for the ATS/AOS service
   classes (cf. [I-D.ietf-mext-aero-reqs]).  As defined in
   [I-D.ietf-mext-aero-reqs], the problem of nested MRs is not a
   requirement and merely desired and can therefore be ignored in the
   first step.  Its only use case is that of a MANET of aircraft, where
   other solutions to the problem can be found, e.g. within the MANET
   (routing) itself, that are transparent to NEMO.  Support for VMNs is
   also not required for the ATS/AOS domain.

   Hence the applicable NEMO RO solutions can be categorized as follows,
   listing those nodes that are involved in mobility related signaling:

   1.  MNN to CN: RO is performed between the end systems.

   2.  MR to CN: The Mobile Router performs RO on behalf of the MNN with
       the CN.

   3.  MR to CR: The MR performs RO with a Correspondent Router that is
       located close to the CN and that can forward traffic from and to
       the CN.

   4.  MR to HA: The MR binds to a topologically closer Home Agent.

   The requirements from [I-D.ietf-mext-aero-reqs] play an important
   role for the analysis.  We list them here for ease of reading:

   1.   Req1 - Separability: "Since RO may be inappropriate for some
        flows, an RO scheme MUST support configuration by a per-domain
        dynamic RO policy database [...]".  The rationale for this
        requirement is to trigger RO only for flows that really require
        it.

   2.   Req2 - Multihoming: " An RO solution MUST support an MR having
        multiple interfaces, and MUST allow a given domain to be bound
        to a specific interface.  It MUST be possible to use different
        MNPs for different domains".  Multihoming itself is supposed to
        allow segregation of traffic flows over different interfaces.

   3.   Req3 - Latency: "While an RO solution is in the process of
        setting up or reconfiguring, packets of specified flows MUST be
        capable of using the MRHA tunnel".

   4.   Req4 - Availability: "An RO solution MUST be compatible with
        network redundancy mechanisms and MUST NOT prevent fall-back to
        the MRHA tunnel if an element in an optimized path fails.  An RO
        mechanism MUST NOT add any new single point of failure for



Bauer, et al.            Expires March 13, 2010                 [Page 4]


Internet-Draft       Aeronautical NEMO RO Sol. Space      September 2009


        communications in general".  Redundancy mechanisms do not have
        to be considered for the RO mechanism itself; this requirement
        merely tries to ensure that RO does not interfere with any
        existing redundancy mechanism.

   5.   Req5 - Packet Loss: "An RO scheme SHOULD NOT cause either loss
        or duplication of data packets during RO path establishment,
        usage, or transition, above that caused in the NEMO basic
        support case.  An RO scheme MUST NOT itself create non-transient
        losses and duplications within a packet stream".

   6.   Req6 - Scalability: "An RO scheme MUST be simultaneously usable
        by the MNNs on hundreds of thousands of craft without
        overloading the ground network or routing system.  This
        explicitly forbids injection of BGP routes into the global
        Internet for purposes of RO".

   7.   Req7 - Efficient Signaling: "An RO scheme MUST be capable of
        efficient signaling in terms of both size and number of
        individual signaling messages and the ensemble of signaling
        messages that may simultaneously be triggered by concurrent
        flows".

   8.   Req8 - Security #1 (for ATS): "The RO scheme MUST NOT further
        expose MNPs on the wireless link than already is the case for
        NEMO basic support".

   9.   Req8 - Security #2 (for ATS): "The RO scheme MUST permit the
        receiver of a BU to validate an MR's ownership of the CoAs
        claimed by an MR" and "the RO scheme MUST ensure that only
        explicitly authorized MRs are able to perform a binding update
        for a specific MNP".

   10.  Req9 - Adaptability: "Applications using new transport
        protocols, IPsec, or new IP options MUST be possible within an
        RO scheme".  In particular, the RO scheme should not fail on the
        use of previously unknown higher layer protocols.

   In the first stage we have performed a short analysis of all the four
   possible approaches outlined above.  We came to the conclusion that
   only two of these, namely "MR to CR" and "MR to HA", are of interest
   to the aeronautical environment.  We therefore focus on these in
   Section 3 below.  Nevertheless, for completeness, we have added the
   short analysis of all four categories in Appendix A.







Bauer, et al.            Expires March 13, 2010                 [Page 5]


Internet-Draft       Aeronautical NEMO RO Sol. Space      September 2009


3.  Discussion

   This section discusses the "MR to CR" and "MR to HA" proposals in
   detail.

3.1.  Correspondent Router

   The CR approach was first introduced in [I-D.orc] and later a
   proposal specifically targeted at the aeronautical requirements has
   been specified in [I-D.draft-bernardos-mext-nemo-ro-cr].  Another
   document [I-D.draft-wakikawa-mext-cr-consideration] discusses
   possible issues and provides considerations for the CR protocol.

   Req1 - Separability: at the moment, the only obvious way how
   separation could work is on a per address/prefix basis and not
   traffic type or application.  The major problem is related to the CR
   relying on IGP advertisements within its network to attract traffic
   destined for the MR.  In that case, the separability of different
   flows can only be achieved based on addresses/prefixes, but not on
   traffic type on the CR side.  The CR specifications (either [I-D.orc]
   or [I-D.draft-bernardos-mext-nemo-ro-cr]) do not discuss the
   compatibility with [I-D.draft-ietf-monami6-multiplecoa] and
   [I-D.draft-ietf-mext-flow-binding] in order to dispatch flows between
   the MN and its CR via different interfaces (CoA) on the MR.  However,
   whether it is really necessary to direct certain flows, destined to
   the same CN, over the RO path and others over the MR-HA tunnel is not
   obvious.  At least for the ATS domain, it could be considered
   sufficient to have separability on a per-address basis.

   Req2 - Multihoming has, to a certain degree, already been addressed
   above.  Nevertheless, when taking a more detailed look at MCoA, its
   implementation within the CR protocol comes at the expense of the MR
   having to register each CoA separatly (no bulk registration).  The
   signaling overhead for the registration grows linearly with the
   number of CRs the MR is binding with.  At least for the ATS domain,
   this might not be considered as problematic given that only one or at
   most two CR bindings are probably active at a certain point in time
   (cf. [I-D.bauer-mext-aero-topology]).

   Req3 - Latency: the delay of establishing RO with the CR is the sum
   of the discovery and the registration procedures.  Appendix A.3 of
   [I-D.draft-bernardos-mext-nemo-ro-cr]) states that these steps may be
   done while the MR-HA tunnel is still used for sending user data.  The
   signaling during a handover is equivalent to that of standard MIPv6
   RO for [I-D.orc] and an IKEv2 and BU/BA exchange for
   [I-D.draft-bernardos-mext-nemo-ro-cr].  For as long as this signaling
   is performed, it could be expected to rely on the (updated) MR-HA
   tunnel for as long as the binding with the CR has not been renewed.



Bauer, et al.            Expires March 13, 2010                 [Page 6]


Internet-Draft       Aeronautical NEMO RO Sol. Space      September 2009


   This behaviour depends though on which of the MR-CR and MR-HA
   bindings has been first successfully updated.  A change of the CoA
   will trigger the same series of events, except for the discovery
   procedure that is not needed anymore.

   Req4 - Availability: the MR maintains a communication path with a
   unique and static HA and also has direct routing paths (RO paths)
   with its correspondents, via the various CRs located near those final
   correspondents.  In case of failure of the CR, the MR could switch
   back to the MR-HA tunnel, given that the failure is detected.
   However, it is difficult to assess whether the probability for a CR
   failure is larger then for a HA failure.  On the other hand, a CR
   could also increase the availability in case of HA failure if
   credentials between MR and CR are available and RO can therefore be
   established in a different way compared to MIPv6 RO.  In terms of
   routing path characteristics, the shorter path used by the MR-CR
   tunnel might have a lower probability of failure than the "longer"
   MR-HA path.

   Req5 - Packet loss: as already mentioned for Req3, while performing
   signaling for setting up the RO state, the MR-HA tunnel could be used
   for user data and no packet loss would therefore be induced.  For as
   long as the mobility binding at the CR has not been re-established,
   packets can flow from the MR via the HA (if already available)
   directly to the CN, but on the reverse path packets will be sent to
   the old CoA of the MR and therefore be lost.

   Req6 - Scalability: if the number of CNs and, most importantly, the
   number of networks in which they are hosted increases, more CRs will
   be needed.  Appendix A.6 of [I-D.draft-bernardos-mext-nemo-ro-cr]
   does not discuss the fact that the more CRs a MR has a binding with,
   the more signaling it needs to send after a handover (change of CoA).
   It is therefore important to consider the number of nodes within the
   ATS and AOS domains.  Taking into account the ATS communication model
   (cf. [I-D.bauer-mext-aero-topology]), the number of CRs that the MR
   should have an active binding with might be limited to two.

   Req7 - Efficient Signaling: signaling is required for each binding
   with a CR.  If MCoA/flow-binding should be supported, the amount of
   signaling might increase.  An aspect that is not discussed in
   Appendix A.7 of [I-D.draft-bernardos-mext-nemo-ro-cr] is the
   signaling that may be required for the detection of the CR, required
   once at the time RO is initiated.

   Req8 - Security: a main requirement is that the authenticity of the
   MNP of the MR has to be verified.  [I-D.orc] relies on the well known
   Return Routability method of Mobile IPv6 and therefore inherits its
   security weaknesses.  [I-D.draft-bernardos-mext-nemo-ro-cr] proposes



Bauer, et al.            Expires March 13, 2010                 [Page 7]


Internet-Draft       Aeronautical NEMO RO Sol. Space      September 2009


   to use IKEv2/IPsec to secure the BU/BA exchange with the assumption
   that "certificates are used to prove ownership of prefixes by MRs and
   CRs".  The location, domain and associated authority under which the
   CR is deployed can make the deployment difficult, depending on the
   availability of those credentials.

   Req9 - Adaptability: for as long as generic packet tunneling is used
   between MR and CR, no problems can be expected wrt security protocols
   within the inner tunnel.  This is similar to NEMO Basic Support.  The
   discussion related to Req1 and Req2 already mentioned that using
   certain traffic types (e.g. specific transport protocol) for either
   flow-specific RO or flow-bindings management could be regarded as
   problematic.

   The following paragraphs are not directly related to the requirements
   anymore, but are from a more general perspective.

   A critical item, that is not directly covered by the requirements, is
   the discovery of the CR: it is difficult for the MR to know the
   anycast address for a particual CR, as needed for the discovery
   request message.  Deriving it from the CN address, as originally
   proposed in [I-D.orc], can not work if both CN and CR do not share
   the same 64bit prefix.

   A CR could be regarded as an entity that is close to the CN but
   already has a trust relationship with the MR.  Taking a closer look
   at the topology of the aeronautical environment, presented in
   [I-D.bauer-mext-aero-topology], reveals that the following two
   options for deployment of CRs are possible for ATS:

   1.  CR in ANSP network: while the topological location is excellent
       for RO purposes, the CR can not be considered to have a trust
       relationship anymore.  If the CR would have, then a trust-
       relationship would also be possible with the CN, as both are
       within the same operational domain.

   2.  CR in the neighbouring gACSP network: having a trust relationship
       between MR and the gACSP domain is very likely, but the
       topological location is not ideal anymore.  The CR can, in
       general, not be on-path anymore.  In fact, it is located in a
       completely different domain, a situation that will cause
       operational problems, especially if the network of the CN is
       multi-homed and peering with several gACSPs.

   These deployment options are dependent on the credentials mentioned
   in the discussion of Req8 above.





Bauer, et al.            Expires March 13, 2010                 [Page 8]


Internet-Draft       Aeronautical NEMO RO Sol. Space      September 2009


3.2.  Global HA to HA

   The Global Home Agent to Home Agent protocol is specified in
   [I-D.draft-wakikawa-mext-global-haha-spec] and makes use of the HA
   reliability protocol [I-D.draft-ietf-mip6-hareliability].

   Req1 - Separability: in Global HAHA, instead of having RO triggered
   on a per-flow or per-destination basis, the MR/MN's position dictates
   the HA instance used by the MN/MR (usually the topologically closest
   one).  From this perspective, HAHA does not directly provide a way to
   support this requirement.  Whether this requirement is applicable to
   HAHA is a different question though.  Nevertheless, while not
   explicitly discussed in HAHA at the time of writing, compatibility
   with MCoA [I-D.draft-ietf-monami6-multiplecoa] and flow-binding
   [I-D.draft-ietf-mext-flow-binding] specifications could address this
   issue.

   Req2 - Multihoming: compatibility with the MCoA/flow-binding
   specifications needs to be discussed, as already shortly mentioned
   above in Req1.  From a more general point of view, Global HAHA does
   not fundamentally modify the relationship with the HA, therefore
   making these protocol extension applicable to it.  But due to the way
   the primary HA of a MN/MR is selected (the topologically closest
   instance of the first active CoA is used), the addition of new CoA
   raises questions.  If two CoAs have different HA attractors, how
   should the protocol behave: should it manage to keep a single primary
   HA for all CoAs (considering one is a primary) or be extended to
   support bindings for different CoAs with different HAs?  Because the
   binding cache has to be shared between the HA instances, adding
   support for MCoA/flow-binding to Global HAHA may require additional
   synchronization and complicates the protocol.

   Req3 - Latency: the overall latency is composed of the BU/BA exchange
   between the MR and the HA.  In case the MR moves to a different
   location that attracts a different HA, the MR will receive a HA
   Switch Message that forces him to establish a binding with the new
   HA.  This requires an additional IKEv2/IPsec and BU/BA exchange.  In
   general, the latency is therefore equivalent to the standard NEMO
   protocol and several additional RTTs if the MR binds to a new HA
   after handover events (change of CoA).

   Req4 - Availability: the operation of HAHA is based on the HA
   reliability protocol [I-D.draft-ietf-mip6-hareliability] that
   describes how failovers are performed between local instances.  Due
   to this, a local HA failure can be overcome and this part of the
   requirement be therefore fulfilled due to the additional local HA
   instances.  When looking at the MR-HA path, if the routing to the
   home network is broken (not the physical link the MR is using but an



Bauer, et al.            Expires March 13, 2010                 [Page 9]


Internet-Draft       Aeronautical NEMO RO Sol. Space      September 2009


   element along the path), current behavior is unknown (both for Global
   HAHA and NEMO Basic Support).  Depending on the precise nature of the
   routing failure, it might be possible within the context of Global
   HAHA that another HA island starts attracting traffic (this however
   will also be dependendent on the BGP convergence time of the anycast
   prefix advertised by the "new" HA island).

   Req5 - Packet loss: Global HAHA shows the same behaviour as standard
   MIPv6/NEMO Basic Support.  For as long as the MN/MR has not finished
   mobility signaling for updating the tunnel with the new CoA, the HA
   will send packets to the old CoA that will therefore be lost.  After
   this signaling has been finished, the MR could be informed by its
   current HA to switch to another, closer HA.  While this adds latency
   for setting up the RO path (shorter route due to closer HA), it is a
   "soft" movement and will not cause packet loss as long as the binding
   with the old HA is kept active while the new binding has not yet been
   succesfully established.

   Req6 - Scalability: with Global HAHA, a given MR being handled by the
   closest HA instance leads to a natural distribution of the traffic
   between all the HAs.  The traffic load at the ground network is
   dependent on the location of the MRs and the HA islands.  From a
   routing table perspective, Global HAHA deployment puts some load on
   the BGP routing system, as prefixes have to be advertised.  The
   number of BGP advertised prefixes is dependent on the number of
   anycast prefixes and HA islands, but should at least be constant and
   not show any frequent advertise/withdrawal behaviour.  Another
   critical aspect is the network traffic caused by synchronizing the
   binding caches between the various HA instances (cf.
   [I-D.draft-ietf-mip6-hareliability]) if the number of HAs is very
   large.

   Req7 - Efficient Signaling: in Global HAHA the amount of signaling
   between the MR and its HA is roughly the same as in NEMO Basic
   Support.  This number is increased by the HA switch operation and
   therefore depending on the number of HAs.  Most importantly, the
   amount of signaling is constant - it does not depend on the number of
   correspondent nodes the MR is currently communicating with.
   Considering that MCoA/flow-bindings will work with Global HAHA in the
   future, the expected amount of signaling will still remain minimal,
   for as long as it is performed with only a single HA.  As already
   discussed for Req2 - Multihoming, sychronizing flow-bindings among
   different HAs will induce more overhead.

   Req8 - Security: as in Global HAHA bindings are only performed with
   the HAs of the home network (within a single administrative domain),
   meeting the security requirements is much easier to fulfill.  IKEv2/
   IPsec protects the BU/BA message exchanges between the MR and the HA



Bauer, et al.            Expires March 13, 2010                [Page 10]


Internet-Draft       Aeronautical NEMO RO Sol. Space      September 2009


   instances.  Consecutively, due to the use of IKEv2, the problem of
   MNP authentication is directly addressed.

   Req9 - Adaptability: As Global HAHA does not modify the operation of
   the MR-HA tunnel (apart from having it with the closest HA instance),
   no limitations are introduced when compared to NEMO Basic Support.

   The following paragraphs are not directly related to the requirements
   anymore, but are from a more general perspective.

   Global HA to HA does not have the problems of the CR protocol wrt
   security and credentials, as its scope is restricted to the MR and
   the Mobility Service Provider (MSP) operating the HAs.  Its
   disadvantage is that the level of provided RO depends on the global
   network presence of the MSP. gACSPs (cf.
   [I-D.bauer-mext-aero-topology]) can achieve this goal, whether this
   also holds for airlines acting as their own MSP is unclear.  This is
   in fact a critical aspect for HAHA, as a home network without a
   distributed global presence can not meet the original goal of
   providing an adequate, short latency RO path.

   As mentioned in Section 3.3.1 of [I-D.bauer-mext-aero-topology], the
   MR could actually be attached to the same network as the CN.
   Failures within the home network or with the routing path between the
   visited and the home network breaks connectivity to the HAs and would
   then prevent communications although both nodes (MR and CN) are in
   close topological proximity.
























Bauer, et al.            Expires March 13, 2010                [Page 11]


Internet-Draft       Aeronautical NEMO RO Sol. Space      September 2009


4.  Next steps

   The investigation showed that both protocols have advantages and
   disadvantages, although open questions remain for both of them.

   The CR protocol has issues related to its discovery procedure, but
   can support multihoming, although at the expense of having to
   register each CoA separately.  The deployment options are restricted
   by the availability of credentials and by the location of the CNs.

   Global HA to HA has the advantage of restricting the mobility
   signaling to the MR and home network only.  How multihoming can be
   addressed is not yet clear; in addition, the overhead caused in the
   ground network might become an issue with a growing number of HAs.

   We therefore think that additional work and investigations in the
   following areas are required:

   For CR:

   1.  Discovery procedure.

   2.  A more detailed specification of the mobility signaling between
       MR and CR, including mutual authentication between MR and CR.

   For HAHA:

   1.  Overhead caused by binding cache synchronizations between HAs.

   2.  Support for multihoming as in
       [I-D.draft-ietf-monami6-multiplecoa] and
       [I-D.draft-ietf-mext-flow-binding].

   Aftewards, the solution space investgation can be revisited and the
   proper solution be selected.
















Bauer, et al.            Expires March 13, 2010                [Page 12]


Internet-Draft       Aeronautical NEMO RO Sol. Space      September 2009


5.  Considerations for PIES

   All discussion up to now have been focussed on the ATS/AOS traffic
   classes.  Passenger communications, especially for passenger owned
   devices, has been ignored.

   We think though that the number of options is severly limited for
   this scenario:

   1.  RO signaling involving the CNs is unrealistic as those nodes are
       usually within the public Internet and will most like not
       implement any mobility functionality.

   2.  Deployment of special infrastructure in the Internet, e.g.  CRs,
       just for the purpose of RO seems unlikely.

   3.  Forcing passengers to install software for mobility functionality
       might be regarded as problematic.

   As a consequence, Route Optimization has to be limited to the MR and
   the MSP network.  This implies Global HA to HA is a reasonable
   solution for the PIES domain.  This would also allow to reuse the
   protocol for the ATS/AOS environment.




























Bauer, et al.            Expires March 13, 2010                [Page 13]


Internet-Draft       Aeronautical NEMO RO Sol. Space      September 2009


6.  Security Considerations

   This document only presents information related to the aeronautical
   NEMO RO solution space.  There are no security issues in this
   document.














































Bauer, et al.            Expires March 13, 2010                [Page 14]


Internet-Draft       Aeronautical NEMO RO Sol. Space      September 2009


7.  Acknowledgements

   Christian Bauer and Serkan Ayaz have been partially supported by the
   European Commission through the NEWSKY project.  The views and
   conclusions contained herein are those of the authors and should not
   be interpreted as necessarily representing the official policies or
   endorsements, either expressed or implied, of the NEWSKY project or
   the European Commission.











































Bauer, et al.            Expires March 13, 2010                [Page 15]


Internet-Draft       Aeronautical NEMO RO Sol. Space      September 2009


8.  References

8.1.  Normative References

   [I-D.bauer-mext-aero-topology]
              Bauer, C. and S. Ayaz, "ATN Topology Considerations for
              Aeronautical NEMO RO", draft-bauer-mext-aero-topology-00
              (work in progress), July 2008.

   [I-D.ietf-mext-aero-reqs]
              Eddy, W., Ivancic, W., and T. Davis, "Network Mobility
              Route Optimization Requirements for Operational Use in
              Aeronautics and Space Exploration Mobile Networks",
              draft-ietf-mext-aero-reqs-04 (work in progress),
              August 2009.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC3963]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
              Thubert, "Network Mobility (NEMO) Basic Support Protocol",
              RFC 3963, January 2005.

   [RFC4889]  Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network
              Mobility Route Optimization Solution Space Analysis",
              RFC 4889, July 2007.

8.2.  Informative References

   [I-D.bernardos-nemo-miron]
              Bernardos, C., "Mobile IPv6 Route Optimisation for Network
              Mobility (MIRON)", draft-bernardos-nemo-miron-01 (work in
              progress), July 2007.

   [I-D.draft-bernardos-mext-nemo-ro-cr]
              Bernardos, C., Calderon, M., and I. Soto, "Correspondent
              Router based Route Optimisation for NEMO (CRON)",
              July 2008, <http://tools.ietf.org/html/
              draft-bernardos-mext-nemo-ro-cr>.

   [I-D.draft-ietf-mext-flow-binding]
              Soliman, H., Tsirtsis, G., Montavont, N., Giaretta, G.,
              and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and NEMO
              Basic Support", July 2009, <draft-ietf-mext-flow-binding">http://tools.ietf.org/html/
              draft-ietf-mext-flow-binding">I-D.draft-ietf-mext-flow-binding>.

   [I-D.draft-ietf-mip6-hareliability]
              Wakikawa, R., "Home Agent Reliability Protocol",



Bauer, et al.            Expires March 13, 2010                [Page 16]


Internet-Draft       Aeronautical NEMO RO Sol. Space      September 2009


              July 2009,
              <http://tools.ietf.org/html/
              draft-ietf-mip6-hareliability>.

   [I-D.draft-ietf-monami6-multiplecoa]
              Wakikawa, R., Tsirtsis, G., Ernst, T., and K. Nagami,
              "Multiple Care-of Addresses Registration", May 2009, <http
              ://tools.ietf.org/html/draft-ietf-monami6-multiplecoa>.

   [I-D.draft-wakikawa-mext-cr-consideration]
              Wakikawa, R., "The Design Consideration of Correspondent
              Router", July 2008, <http://tools.ietf.org/html/
              draft-wakikawa-mext-cr-consideration>.

   [I-D.draft-wakikawa-mext-global-haha-spec]
              Wakikawa, R., Zhu, Z., and L. Zhang, "Global HA to HA
              Protocol Specification", July 2009, <http://
              tools.ietf.org/html/draft-wakikawa-mext-global-haha-spec>.

   [I-D.ndproxy]
              Lee, K., Jeong, J., Park, J., and H. Kim, "ND-Proxy based
              Route and DNS Optimizations for Mobile Nodes in Mobile
              Network", February 2004,
              <http://tools.ietf.org/html/draft-jeong-nemo-ro-ndproxy>.

   [I-D.orc]  Wakikawa, R. and M. Watari, "Optimized Route Cache
              Protocol (ORC)", October 2004,
              <http://tools.ietf.org/html/draft-wakikawa-nemo-orc>.

   [I-D.pd]   Lee, K., Jeong, J., Park, J., and H. Kim, "Route
              Optimization for Mobile Nodes in Mobile Network based on
              Prefix Delegation", February 2004,
              <http://tools.ietf.org/html/draft-leekj-nemo-ro-pd>.

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC4225]  Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
              Nordmark, "Mobile IP Version 6 Route Optimization Security
              Design Background", RFC 4225, December 2005.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC4885]  Ernst, T. and H-Y. Lach, "Network Mobility Support
              Terminology", RFC 4885, July 2007.

   [RFC5142]  Haley, B., Devarapalli, V., Deng, H., and J. Kempf,



Bauer, et al.            Expires March 13, 2010                [Page 17]


Internet-Draft       Aeronautical NEMO RO Sol. Space      September 2009


              "Mobility Header Home Agent Switch Message", RFC 5142,
              January 2008.

















































Bauer, et al.            Expires March 13, 2010                [Page 18]


Internet-Draft       Aeronautical NEMO RO Sol. Space      September 2009


Appendix A.  Short Overview of all RO Solutions

   This Appendix covers all four approaches (MNN to CN, MR to CN, MR to
   CR, MR to HA) to the RO problem with a short analysis.

A.1.  Analysis

   For each solution class, a specific draft is shortly summarized
   before the analysis is performed.

A.1.1.  MNN to CN

   In general, for this solution class information related to the MRs
   access network and access routers (ARs) is exposed to the MNNs.
   Based on this information, the MNNs can perform RO by themselves
   directly with the CN.  The MR is therefore only in a supporting role.

A.1.1.1.  Proposal(s)

   The MR is attached to a subnet with an appropriate AR.  The draft
   [I-D.ndproxy] describes how the MR relays the subnet prefix of the AR
   inside the mobile network to the MNNs, that in turn use
   Autoconfiguration [RFC4862] to configure their IP addresses.  The MR
   then acts as a ND proxy.

   Another, similar approach relies on prefix delegation between MR and
   AR [I-D.pd] where the AR receives a complete proper prefix that can
   be used inside the NEMO mobile network.

   Packets sent over the RO path use the Type 2 Routing Header and Home
   Destination Option as specified for RO in [RFC3775].

A.1.1.2.  Analysis

   This approach might face problems in the presence of Secure Neighbor
   Discovery in the access network [RFC3971] when using the MR as ND
   proxy.  MNNs have to implement MIPv6 [RFC3775] for performing RO
   themselves and the MR has to be upgraded as well.

   Verifying the requirements against this solution approach, we come to
   the following conclusions:

   1.   Req1: Fulfilled.  MNNs can decide by themselves to perform RO.

   2.   Req2: To be discussed.  MNNs can configure one address per
        advertised (access network) prefix.  The disadvantage is that
        the access network has to accept every MNN address as source
        address for packets, something that may not be supported if the



Bauer, et al.            Expires March 13, 2010                [Page 19]


Internet-Draft       Aeronautical NEMO RO Sol. Space      September 2009


        egress interface supports having only a single IP address.

   3.   Req3: Fulfilled.  Can rely on standard MIPv6 RO; MR-HA tunnel
        therefore used for as long as RO has not been completed.

   4.   Req4: Fulfilled.  RO is performed between the end systems - no
        additional single-point of failure for communication added.

   5.   Req5: Fulfilled.  As long as the RO path has not been
        established, packets can be sent over the MR-HA tunnel.

   6.   Req6: Problematic.  Signaling overhead will be per MNN/CoA/home
        network prefix/CN.  BGP not relevant.

   7.   Req7: Problematic.  The signaling for RO is equal to that of
        standard MIPv6.  Several messages and RTTs are needed for every
        MNN that is performing RO.

   8.   Req8 #1: To be discussed.  While the MNP itself is not part of
        the RO signaling, the addresses of the individual end systems
        within the RO signaling is in cleartext.  This is also the case
        for NEMO Basic support though, if no IPsec confidentiality
        protection is used for user data traffic.

   9.   Req8 #2: Problematic.  If relying on standard MIPv6 RO, MNP/HoA
        verification can be broken.

   10.  Req9: To be discussed.

   As conclusion, while this approach allows for high granularity of RO
   triggering and setup due to the fact that the MNN is in charge, this
   approach has problems related to scalability and security if standard
   MIPv6 RO is used at the MNNs.

A.1.2.  MR to CN

   In general, within this solution class the MR performs RO on behalf
   of the MNN.

A.1.2.1.  Proposal(s)

   The MR acts as a transparent MIPv6-MN-proxy by performing standard
   MIPv6 RO signaling on behalf of the MNN/LFN with the CN.  The draft
   [I-D.bernardos-nemo-miron] describes the detailed operation where the
   MR performs the Return Routability procedure with its own CoA and the
   MNN address as HoA.  Packets protected by IPsec AH between LFN and CN
   can not be supported in RO mode, but instead have to be routed via
   the MR-HA tunnel.



Bauer, et al.            Expires March 13, 2010                [Page 20]


Internet-Draft       Aeronautical NEMO RO Sol. Space      September 2009


   Packets sent over the RO path use the Type 2 Routing Header and Home
   Destination Option as specified for RO in [RFC3775].

A.1.2.2.  Analysis

   The basic problem of this approach is the MR acting transparently
   between MNN and CN and performing the RO as MN from the CN
   perspective.  This can cause problems for security related protocols,
   as the MR actions can be regarded as man-in-the-middle attacks.  This
   is particularly the case for IPsec AH.

   Verifying the requirements against this solution approach, we come to
   the following conclusions:

   1.   Req1: To be discussed.  MR has to be configured with policies
        and has to perform packet inspection.  Whether RO can be
        specifically triggered for certain flows, depending on the
        traffic type, remains to be clarified though (esp. wrt IPsec).

   2.   Req2: Basically fulfilled.  The MR could register several CoAs
        for the MNN with the help of
        [I-D.draft-ietf-monami6-multiplecoa], although no bulk
        registration is available in this case.

   3.   Req3: Fulfilled.  Can rely on standard MIPv6 RO; MR-HA tunnel
        therefore used for as long as RO has not been completed.

   4.   Req4: Fulfilled.  RO is performed with the correspondent node -
        no additional single-point of failure for communication added.

   5.   Req5: Fulfilled.  As long as the RO path has not been
        established, packets can be sent over the MR-HA tunnel.

   6.   Req6: Problematic.  Signaling overhead will be per MNN/CoA/home
        network prefix/CN.  BGP not relevant.

   7.   Req7: Problematic.  The signaling for RO is equal to that of
        standard MIPv6.  Several messages and RTTs are needed for every
        MNN-CN pair for which RO is performed.

   8.   Req8 #1: To be discussed.  While the MNP itself is not part of
        the RO signaling, the addresses of the individual end systems
        within the RO signaling is in cleartext.  This is also the case
        for NEMO Basic support though, if no IPsec confidentiality
        protection is used for user data traffic.

   9.   Req8 #2: Problematic.  If relying on standard MIPv6 RO, MNP/HoA
        verification can be broken.



Bauer, et al.            Expires March 13, 2010                [Page 21]


Internet-Draft       Aeronautical NEMO RO Sol. Space      September 2009


   10.  Req9: Problematic.  IPsec AH not supported for reverse path from
        MNN/LFN to CN.

   This approach allows to use simple LFNs as MNNs, but introduces
   problems due to the middlebox operation at the MR.  Security concerns
   with respect to the RO procedure itself are existing if standard
   MIPv6 RO is used.  Scalability is similar to the approaches in
   Appendix A.1.1.

A.1.3.  MR to CR

   For this approach, a new mobility entity called Correspondent Router
   (CR) is introduced.  The MR performs RO with the CR that forwards
   traffic from/to the CN/MNN.

A.1.3.1.  Proposal(s)

   The CR approach was first introduced in [I-D.orc] as a possible
   solution to the NEMO RO problem.  Later, a proposal based on the CR
   idea which specifically targeted the aeronautical requirements has
   been specified in [I-D.draft-bernardos-mext-nemo-ro-cr].  A third
   document [I-D.draft-wakikawa-mext-cr-consideration] has then been
   issued by the main author of [I-D.orc] for discussing possible issues
   and for providing considerations for the CR protocol.

   The MR performs a discovery procedure to detect the CR that should be
   located either 1) on the routing-path to the CN or 2) within the
   network of the CN where it can announce proxy-routes via an IGP for
   the MNP(s) of the MR.  Once the mobility binding has been
   established, the CR can intercept traffic (e.g. based on routes
   advertised via IGP) and tunnel it to the MR.  Similarly, in the
   reverse direction the MR tunnels traffic destined to the prefix(es)
   served by the CR directly to this router.  This is shown in Figure 1.

   The discovery procedure is a critical part of the overall protocol
   and while the original document [I-D.orc] did propose a solution,
   issues related to this approach are discussed in
   [I-D.draft-bernardos-mext-nemo-ro-cr].  Hence, this topic has to be
   regarded as work in progress.

   The authentication of the MNP in [I-D.orc] is achieved by adding a
   prefix sub-option containing the MNP(s) of the MR to the Home Test
   Init (HoTI) message.  The HA only forwards the message to the CR if
   the originator of the message (MR) is also the owner of the prefix
   contained with the HoTI message.

   CR Discovery is achieved by an ICMP-based mechanism similar to
   Dynamic Home Agent Address Discovery (DHAAD), based on the



Bauer, et al.            Expires March 13, 2010                [Page 22]


Internet-Draft       Aeronautical NEMO RO Sol. Space      September 2009


   Correspondent Nodes 64bit prefix.

   The operation of a CR is more complicated if it is located in a
   multihomed site: asymmetric routing could result if the CR serving
   the MR on the forward path can not ensure to also intercept and
   foward packets to the MR on the reverse path.

                         +----+
                         | MR | <--+
                         +----+    |
                                   v
                              +----------------+
                              | Access Network |
                              +----------------+
                                   ^
                                   |  +----------+
                                   |  |  +----+  |
                               +---|--+  | CN |  |
                               |   |     +----+  |
                               |   |       ^     |
                               |   v       |     |
                               | +----+    |     |
                               | | CR | <--+     |
                               | +----+          |
                               |   ANSP Network  |
                               +-----------------+

                        Figure 1: CR-based NEMO RO.

A.1.3.2.  Analysis

   The CR approach has both advantages and disadvantages.

   1.   Req1: To be discussed.  MR has to be configured with policies
        and has to perform packet inspection.  Whether RO can be
        specifically triggered for certain flows, depending on the
        traffic type, remains to be clarified though (esp. wrt IPsec).

   2.   Req2: Basically fulfilled.  The MR could register several CoAs
        for its MNP(s) with the help of
        [I-D.draft-ietf-monami6-multiplecoa], although no bulk
        registration is available in this case.

   3.   Req3: Fulfilled.  Similar to standard MIPv6 RO; MR-HA tunnel
        therefore used for as long as RO has not been completed.

   4.   Req4: To be discussed.  The CR itself could be regarded as a new
        single point of failure, but if CR failure can be detected the



Bauer, et al.            Expires March 13, 2010                [Page 23]


Internet-Draft       Aeronautical NEMO RO Sol. Space      September 2009


        MR-HA tunnel could be used again.

   5.   Req5: Fulfilled.  As long as the RO path has not been
        established, packets can be sent over the MR-HA tunnel.  When
        the MR performs a transition to a new access network and an RO
        state has been established with the CR, packets will be lost as
        the CR will send them to the old CoA of the MR.  This is also
        true for NEMO Basic Support though, where the HA will send
        packets to the old CoA of the MR for as long as the mobility
        binding has not been updated.

   6.   Req6: To be discussed.  Signaling overhead is per CoA/MNP/CR.
        BGP not relevant, IGP advertisements and routing table size at
        the CR grows with the number of registered MNPs though.

   7.   Req7: To be discussed.  CNs within the same network can be
        served by a single CR, mobility signaling is therefore only
        performed for new CoAs.  The overall signaling overhead is
        directly related to the distribution of CNs and CRs.  An
        additional overhead is caused by the discovery procedure.

   8.   Req8 #1: To be discussed.  The MNP itself is part of the RO
        signaling and could be sent in cleartext.

   9.   Req8 #2: Problematic.  If relying on standard MIPv6 RO, MNP/HoA
        verification can be broken.

   10.  Req9: Fulfilled.  The tunneling between MR and CR preserves
        inner packet characteristics.

   An advantage of CR is that RO is scalable wrt the number of CNs as
   mobility signaling is performed per network or at least per grouped
   list of prefixes served by the CR (under the assumption that the CNs
   are located within those prefixes).

   Another problem is the authentication between MR and CR: [I-D.orc]
   relies on the standard MIPv6 Return Routability procedure that has
   security weaknesses.  In addition, the authentication of the CR to
   the MR is not taken into account in the original draft, but has to be
   considered as a potential threat.

A.1.4.  MR to HA

   For this approach a new home network architecture is introduced where
   Home Agent functionality is shared among a set of instances that is
   geographically spread.  At a given moment, based on the current
   topological location, the MR uses the closest HA instance.




Bauer, et al.            Expires March 13, 2010                [Page 24]


Internet-Draft       Aeronautical NEMO RO Sol. Space      September 2009


A.1.4.1.  Proposal

   The Global Home Agent to Home Agent protocol
   [I-D.draft-wakikawa-mext-global-haha-spec] extends the original
   MIPv6/NEMO model, where only a single HA is available per MN, to an
   architecture where HAs are geographically distributed.  MNs can bind
   to the closest HA to achieve a certain level of RO.

   The Home Network relies on advertising a large common prefix via EGP
   that inflicts anycast routing.  The traffic of a CN will be attracted
   by the topologically closest HA, just as mobility signaling from the
   MN will always be attracted by the topologically closest HA as well.
   In the latter case, the closer HA will inform the MNs current primary
   HA of the suboptimal routing.  The primary HA will send a HA switch
   message that orders the MN to bind with the closer HA, based on
   signaling specified in [RFC5142].  This way, by reducing the distance
   between the MR and its HA, a certain degree of RO is achieved.
   Signaling between HAs is based on
   [I-D.draft-ietf-mip6-hareliability].

   A graphical illustration is shown in Figure 2.

                     +----+
                     | MR | <-----+
                     +----+       |
                                  v
                          +----------------+
                          | Access Network |
                          +----------------+
                                  |
                     +------------|------------------+
                                  |                  |
                     | +----+   +----+   +----+      |
                     | | HA |   | HA |   | HA |      |
                     | +----+   +----+   +----+      |
                     |   Mobility | Service Provider |
                     +------------|------------------+
                                  |
                                  v
                             +--------------+
                             |   +----+     |
                             |   | CN |     |
                             |   +----+     |
                             | ANSP Network |
                             +--------------+

                        Figure 2: Global HA to HA.




Bauer, et al.            Expires March 13, 2010                [Page 25]


Internet-Draft       Aeronautical NEMO RO Sol. Space      September 2009


A.1.4.2.  Analysis

   HAHA is significantly different from the other approaches as it does
   not require any mobility functionality in the CN or within the CN
   network.  Mobility signaling, apart from the MR and its current
   primary HA, is performed within the various instances of the HAs in
   the ground network only.

   1.   Req1: To be discussed.  RO is always implicitly provided by
        switching to a closer HA.  Packet inspection at the MR would
        have to be introduced to identitfy the different flows.  This
        requirement could only be discussed within the context of
        multihoming extensions, namely
        [I-D.draft-ietf-monami6-multiplecoa] and
        [I-D.draft-ietf-mext-flow-binding].

   2.   Req2: To be discussed.  Given compatability to
        [I-D.draft-ietf-monami6-multiplecoa] is provided, the MR could
        register several CoAs for its MNP(s).  It is unclear though how
        the protocol could support simultaneous mobility signaling with
        two HAs if each one is considered to be close to each
        respective, active interface at the MR.

   3.   Req3: Fulfilled.  As long as the MR has not registered to the
        new HA, the old MR-HA tunnel should be preserved.

   4.   Req4: Fulfilled.  HAHA adds availability mechanisms to the home
        network as it is based on [I-D.draft-ietf-mip6-hareliability].

   5.   Req5: Fulfilled.  As long as the binding with the new HA has not
        been completed, packets can be sent over the MR-previous HA
        tunnel.

   6.   Req6: To be discussed.  Signaling overhead is per CoA/HA.  HAHA
        relies on BGP advertisements to achieve anycast routing.  The
        scale of the advertisements should only be per HA island/anycast
        prefix and not per MR/MNP.

   7.   Req7: Fulfilled.  Mobility signaling is similar to MIPv6/NEMO
        and performed per MR and HA.

   8.   Req8 #1: Fulfilled.  No exposure on the wireless link to what
        already happens for NEMO.

   9.   Req8 #2: Fulfilled.  Security is on the same level as in NEMO.

   10.  Req9: Fulfilled.  The tunneling between MR and HA preserves
        inner packet characteristics.



Bauer, et al.            Expires March 13, 2010                [Page 26]


Internet-Draft       Aeronautical NEMO RO Sol. Space      September 2009


   While the level of RO provided by HAHA is not as good as for the
   previous approaches, it can help eliminate continental round-trip
   times in the aviation scenario.

   A large advantage are the strong security properties as mobility
   signaling is restricted to the MR and the HA (mobility service
   provider).

A.2.  Applicability to the Aeronautical Environment

A.2.1.  Overview

   Table 1 provides a summary of the fulfillment of the individual
   requirements by each solution.  Certain requirements turned out to be
   difficult to assess within the context of the solution - in that case
   the "D" categorization has been used to indicate that a more detailed
   investigation is needed on that subject.

   As can be seen the first two approaches "MNN to CN" and "MR to CN"
   have problems related to scalability and efficient signaling, as RO
   signaling is always performed on a per CN basis.  The latter, in
   addition, has problems related to the security (address
   authentication) and adaptility requirements.  The "MNN to CN"
   approach is mostly interesting from the nesting problem perspective
   only.

   The rationale for Requirement 8 - Security (Section 3.8.1 in
   [I-D.ietf-mext-aero-reqs]) mentions that it is "reasonable to assume
   trust relationships between each MR and a number of mobility anchor
   points topologically near to its CNs".  The rationale says that this
   trust relationship equates on having credentials for the
   authentication of the MNP between the mobility entities (MR, HA, CR).
   This statement actually rules out all "X to CN" approaches (under the
   assumption that standard MIPv6 Return Routability signaling should
   not be accepted due to its security limitations).

   More promising solutions are the CR and the HAHA protocols and we
   have therefore focussed on these two approaches in more detail in
   Section 3.












Bauer, et al.            Expires March 13, 2010                [Page 27]


Internet-Draft       Aeronautical NEMO RO Sol. Space      September 2009


       +-------------+-----------+----------+----------+----------+
       | Requirement | MNN to CN | MR to CN | MR to CR | MR to HA |
       +-------------+-----------+----------+----------+----------+
       |      1      |     F     |     D    |     D    |     D    |
       |             |           |          |          |          |
       |      2      |     D     |     F    |     F    |     D    |
       |             |           |          |          |          |
       |      3      |     F     |     F    |     F    |     F    |
       |             |           |          |          |          |
       |      4      |     F     |     F    |     D    |     F    |
       |             |           |          |          |          |
       |      5      |     F     |     F    |     F    |     F    |
       |             |           |          |          |          |
       |      6      |     P     |     P    |     D    |     D    |
       |             |           |          |          |          |
       |      7      |     P     |     P    |     D    |     F    |
       |             |           |          |          |          |
       |     8-1     |     D     |     D    |     D    |     F    |
       |             |           |          |          |          |
       |     8-2     |     P     |     P    |     P    |     F    |
       |             |           |          |          |          |
       |      9      |     D     |     P    |     F    |     F    |
       +-------------+-----------+----------+----------+----------+

      Abbreviations: F...  Fulfilled, P...  Problematic, D...  To be
                                 discussed

               Table 1: Overview of solution characteristics























Bauer, et al.            Expires March 13, 2010                [Page 28]


Internet-Draft       Aeronautical NEMO RO Sol. Space      September 2009


Authors' Addresses

   Christian Bauer
   German Aerospace Center (DLR)

   Email: Christian.Bauer@dlr.de


   Serkan Ayaz
   German Aerospace Center (DLR)

   Email: Serkan.Ayaz@dlr.de


   Arnauld Ebalard
   EADS Innovation Works

   Email: arnaud.ebalard@eads.net

































Bauer, et al.            Expires March 13, 2010                [Page 29]


Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/