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

Versions: 00 01

MEXT Working Group                                          C. Bernardos
Internet-Draft                                                M. Bagnulo
Intended status: Informational                                      UC3M
Expires: May 7, 2009                                    November 3, 2008


   Analysis on how to address NEMO RO for Aeronautics Mobile Networks
           draft-bernardos-mext-aero-nemo-ro-sol-analysis-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 May 7, 2009.

Abstract

   The Network Mobility Basic Support protocol enables networks to roam
   and attach to different access networks without disrupting the
   ongoing sessions that nodes of the mobile network may have.  By
   extending the Mobile IPv6 support to Mobile Routers, nodes of the
   mobile network are not required to support any kind of mobility,
   since packets go through the Mobile Router-Home Agent (MRHA) bi-
   directional tunnel.  Data packets belonging to communications of
   nodes of the mobile network have to traverse the Home Agent, and
   therefore resulting paths are likely to be suboptimal.  Additionally,
   the solution adds packet overhead, due to the use of encapsulation
   between the Mobile Router and the Home Agent.




Bernardos & Bagnulo        Expires May 7, 2009                  [Page 1]


Internet-Draft    Aeronautics NEMO RO solution analysis    November 2008


   There are currently a set of well defined NEMO Route Optimization
   requirements for Operational Use in Aeronautics and Space
   Exploration, which potential solutions should meet.  This document
   analyses how the problem of NEMO RO for Aeronautics Mobile Networks
   might be tackled, in a way as generic as possible, trying to identify
   those open questions and deployment considerations that need to be
   addressed.

   The main goal of this document is to foster the discussion about
   aeronautics NEMO RO solution space within the MEXT WG.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].



































Bernardos & Bagnulo        Expires May 7, 2009                  [Page 2]


Internet-Draft    Aeronautics NEMO RO solution analysis    November 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Solution Space analysis  . . . . . . . . . . . . . . . . . . .  4
   3.  Design issues/questions/trade-offs . . . . . . . . . . . . . .  8
     3.1.  Where are the RO entities located? . . . . . . . . . . . .  9
     3.2.  Who administratively manages the RO entities?  . . . . . . 10
     3.3.  Which kind of addresses are gonna be used and who own
           them?  . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     3.4.  How many RO entities are needed to globally perform
           NEMO RO? . . . . . . . . . . . . . . . . . . . . . . . . . 11
     3.5.  What trust relationships are needed? . . . . . . . . . . . 12
     3.6.  Is the solution flexible enough to allow the
           participation of the end-nodes (CNs and/or MNNs)?  . . . . 13
     3.7.  Does the solution allow for a hierarchical scheme? . . . . 13
     3.8.  What is the target protocol complexity?  . . . . . . . . . 14
     3.9.  How is routing performed within the ATN? . . . . . . . . . 14
     3.10. Does the solution allow for implementing
           legal/political/economical requirements? . . . . . . . . . 14
     3.11. What is the robustness of the solution (i.e. what type
           of failure affects to the reachability)? . . . . . . . . . 15
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 16
   Appendix A.  Change Log  . . . . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 18





















Bernardos & Bagnulo        Expires May 7, 2009                  [Page 3]


Internet-Draft    Aeronautics NEMO RO solution analysis    November 2008


1.  Introduction

   This document assumes that the reader is familiar with the
   terminology related to Network Mobility [4] and [5], and with the
   Mobile IPv6 [2] and NEMO Basic Support [3] protocols.

   The MEXT WG is currently chartered to work on three use cases for
   route optimization of network mobility, namely aeronautics [6],
   vehicular [7] and consumer electronics [8].  The work on the
   requirements for the aeronautics use case seems to be mature enough
   at this point to start discussing about solutions.  This document is
   an initial attempt aimed at fostering discussion on solutions, by
   presenting a general framework of how a solution for the aeronautics
   use case could look like, and identifying and highlighting relevant
   questions, issues and deployment models that need to be taken care of
   during the solution definition process.

   The requirements for the aeronautics use case [6] differentiate among
   three different domains of interest: Air Traffic Services (ATS), Air
   Operational Services (AOS) and Passenger Information and
   Entertainment Services (PIES).  Besides, two kind of requirements are
   identified: required (minimal properties that a solution must
   possess) and desirable (difficult to quantify or not immediately
   needed requirements) characteristics.  Since the PIES domain is not
   critical to safety-of-life, but mostly involves added comfort and
   business services to passengers, this domain has not been taken into
   account as input for the required characteristics.

   Due to the very different nature of the required and desirable
   characteristics, and the importance of the former ones, this document
   only analyzes how a solution for ATS/AOS would look like.


2.  Solution Space analysis

   In this section we try to outline the general lines of a NEMO Route
   Optimization solution for the aeronautics use case (ATS/AOS domains),
   based on the set of requirements described in [6], which we summarize
   next:
   o  Separability: an RO solution MUST support configuration by using a
      dynamic RO policy database, so RO for certain flows can be
      disabled/enabled.  A granularity level similar to the one of IPsec
      security policy databases is expected to be supported.
   o  Multihoming: an RO solution MUST support multi-interfaced MRs, and
      it MUST allow the use of different interfaces (and also different
      MNPs) for different domains.





Bernardos & Bagnulo        Expires May 7, 2009                  [Page 4]


Internet-Draft    Aeronautics NEMO RO solution analysis    November 2008


   o  Latency: an RO solution MUST allow packets to use the MRHA tunnel
      while setting up or reconfiguring the RO path.
   o  Availability: an RO solution MUST NOT prevent to fall-back using
      the default MRHA tunnel if the RO path fails for whatever reason.
      This basically also means that an RO solution MUST NOT introduce
      any new single point of failure for the communications.
   o  Packet Loss: an RO solution SHOULD NOT cause either additional
      loss or duplication of data packets due to the use of RO, above
      that caused in the NEMO basic default solution.
   o  Scalability: an RO solution MUST be simultaneously usable by
      hundreds of thousands of crafts without overloading the ground
      network or the routing system.
   o  Efficient Signaling: an RO solution MUST be efficient in terms of
      the number of required signaling messages, and avoid signaling
      storms as a result of providing multiple ongoing flows with RO
      following a handover.
   o  Security: an RO solution MUST NOT expose MNPs on the wireless
      egress link, MUST allow the receiver of BUs to validate CoA
      ownership, and MUST ensure that only explicitly authorized MRNs
      are able to send a BU for a specific MNP.
   o  Adaptability: an RO solution MUST NOT prevent applications from
      using transport protocols, IPsec or new IP options.
   o  Although it is not explicitly listed as a required characteristic
      -- but only suggested in [6] --, it seems to be widely accepted
      that modifications to CNs MUST NOT be required by an RO solution.

   From this list of requirements, a first conclusion that can be
   obtained is that a solution for the aeronautics NEMO RO use case MUST
   NOT require changes on the CNs in order to correctly operate, that
   is, a solution MUST provide certain level of RO with legacy IPv6 CNs.
   This means that the solution would likely rely on a set of entities
   at the infrastructure, performing the RO function between them or/and
   also the MR.

   In a glimpse, a solution along the lines mentioned before would
   operate as follows (Figure 1): an optimized route between a mobile
   network deployed in a craft and a CN (or set of CNs) is set-up (upon
   some sort of trigger/policy) between two (or more in general terms)
   NEMO RO entities (NROEs).  These RO entities should be located -- in
   order to provide an optimized route as shorter as possible -- close
   to the mobile network and/or the CN.  It should be noted that one of
   these RO entities may be collocated within the MR.  A tunnel between
   the RO entities (or a chain/nesting of tunnels, in case several RO
   entities are involved in the same optimized route) is established, so
   data traffic between the mobile network and the CN (or set of CNs)
   can be routed through this shorter route (compared with the default
   MRHA one).  It might be the case that certain additional operations
   are needed in order to ensure that traffic sent/received by the CN



Bernardos & Bagnulo        Expires May 7, 2009                  [Page 5]


Internet-Draft    Aeronautics NEMO RO solution analysis    November 2008


   (or by the mobile network) is routed through the RO entities, so they
   can forward packets using the optimized route.  Involving more than
   two RO entities might be useful in order to deploy hierarchical
   schemes (i.e. a chain of RO entities is set up along the path between
   the MR and the CN), in which the MR would only need to update/
   exchange signaling with the closest RO entity, but not with all the
   RO entities involved ih the optimization.  This may improve the
   handover performance for the optimized flows and reduce the signaling
   load.










































Bernardos & Bagnulo        Expires May 7, 2009                  [Page 6]


Internet-Draft    Aeronautics NEMO RO solution analysis    November 2008


                  ---------
                  | HA_MR |
                  ---------
                      |
                      |
             (-*-*-*-*+*-*-*-*-)
          -*-                   -*-
         (                         )
      -*-            ATN            -*-            ------
     (                                 )           | CN |
    (                   --------        )          ------
   (                    | NROE |.........)--+          |
    (                  /./------        )   |====?=====?==
     (                /./              )         |
      -*-            /./            -*-        ------
         (        --------         )           | CN |
          -*-     | NROE |      -*-            ------
             (    --------     )
              -*-     .     -*-
                 (    .    )
                  -*- . -*-
                    -*+*-
                      |
                      |
                    ------       ------------------------------
                    | AR |       | AR: Access Router          |
                    ------       | CN: Correspondent Node     |
                       |         | MR: Mobile Router          |
             ===?==========      | HA_MR: MR's Home Agent     |
                |                | MNP: Mobile Network Prefix |
              ------             | MNN: Mobile Network Node   |
              | MR |             | NROE: NEMO RO Entity       |
              ------             ------------------------------
                |
         ===?========?====(MNP)
            |        |
         -------  -------
         | MNN |  | MNN |
         -------  -------

              Figure 1: RO entity-based solution architecture

   This approach, based on the use of RO network entities that are in
   charge of performing the NEMO RO, seems to be the solution that has
   received more positive feedback from the MEXT WG so far.  This
   solution -- as described in this document -- is very general and
   leaves (on purpose) many aspects open/undefined.  Depending on the
   particular design decisions that can be taken, completely different



Bernardos & Bagnulo        Expires May 7, 2009                  [Page 7]


Internet-Draft    Aeronautics NEMO RO solution analysis    November 2008


   solutions might be the outcome.  For example, there are currently two
   proposed solutions that implement the RO entity-based concept in
   different ways: the global Home Agent to Home Agent (HAHA) [9], [10],
   and the Correspondent Router based RO for NEMO (CRON) [11].

   Since different design decisions might result into completely
   different solutions, each of them meeting different requirements and
   providing different features, it is very important to understand the
   impact of the related design decisions, as well as the involved
   trade-offs, when designing a NEMO RO solution for the aeronautics use
   case.  It is also important to look at the deployment issues derived
   from the particular characteristics of the Aeronautical
   Telecommunications Networks (ATNs) [12].  The next section of this
   document is aimed at identifying the different important design
   aspects, deployment issues and resulting trade-offs when considering
   an RO entity-based NEMO RO solution.  The goal of such an exercise is
   to help the MEXT WG in the design of the NEMO RO solution for the
   aeronautics use case.


3.  Design issues/questions/trade-offs

   In this section, we attempt to identify relevant design issues,
   questions and involved trade-offs when considering an RO entity-based
   NEMO RO solution, by asking the following questions:

   1.  Where are the RO entities located?

   2.  Who administratively manages the RO entities?

   3.  Which kind of addresses are gonna be used and who own them?

   4.  How many RO entities are needed to globally perform NEMO RO?

   5.  What trust relationships are needed?

   6.  Is the solution flexible enough to allow the participation of the
   end-nodes (CNs and/or MNNs)?

   7.  Does the solution allow for a hierarchical scheme?

   8.  What is the target protocol complexity?

   9.  How is routing performed within the ATN?

   10.  Does the solution allow for implementing legal/political/
   economical requirements?




Bernardos & Bagnulo        Expires May 7, 2009                  [Page 8]


Internet-Draft    Aeronautics NEMO RO solution analysis    November 2008


   11.  What is the robustness of the solution (i.e. what type of
   failure affects to the reachability)?

3.1.  Where are the RO entities located?

   A first important question is where the RO entities are located.

   One option is to place the RO entities at the gACSPs.  In this case
   the optimized path would have at least one end-point (depending on
   whether the solution involves two RO entities at the infrastructure
   or one entity at the infrastructure and the MR) at the gACSP.  This
   may be not good enough from a performance point of view, since the
   farther the RO entities are from the communication end-points (i.e.,
   the mobile network and the CNs) the more likely the resulting path
   would be less optimal.

   There are some potentially relevant questions related to placing
   entities at the gACSPs:
   o  can an MR get connectivity from two different gACSPs?
   o  is it possible that the same MR needs to make use of RO entities
      placed at different gACSPs?
   o  would it be possible/required that an RO path is set-up between RO
      entities belonging to two different gACSPs?  If so, the different
      routing policies that gACSPs might implement are relevant, as we
      analyze later.

   Another potential configuration is to place the RO entities at the
   ANSPs.  This configuration would allow to have one end-point of the
   optimization close to the CNs (for the ATS scenario) and therefore
   would result in paths that in general would be closer to the optimal
   case.  On the other hand, this approach would require more RO
   entities to be deployed, therefore eventually increasing the
   complexity of the solution.  Besides, a solution that only places the
   infrastructure RO entities at the ANSPs would require the MR being
   the other RO entity in the NEMO RO process, since an MR might get
   connectivity through a gACSP, or through an lACSP that is not an
   ANSP.  In the AOS scenario, this configuration might not work, since
   AOS CNs might not get connectivity through an ANSP, and therefore an
   RO entity should be deployed somewhere else.

   In those communication scenarios in which the MR is attached to an
   ANSP access network and it is communicating with a CN also attached
   to the same ANSP, placing the RO entities at the ANSP (or collocated
   within the MR) provides the additional advantage that these
   communications would survive failures on the gACSPs to which the ANSP
   gets connectivity from.  This brings the following question:





Bernardos & Bagnulo        Expires May 7, 2009                  [Page 9]


Internet-Draft    Aeronautics NEMO RO solution analysis    November 2008


   o  if a craft attached to an ANSP access network is communicating
      with a CN attached to the same ANSP, is it required for the NEMO
      RO solution to survive when the link of the ANSP to its gACSP goes
      down? or put in a different way, would it be OK for such a
      communication to be broken?  It should be noted that the default
      MRHA path used by the NEMO Basic Support protocol would likely
      fail in this scenario.

   Another approach is to deploy infrastructure RO entities at the
   networks where CN are attached (these networks might be ANSPs in some
   scenarios) and at MRs.  This would provide shorter paths, at the cost
   of higher complexity.

   Last, a solution might not assume any particular placement of the RO
   entities, i.e. they can be located anywhere.  This assumption,
   however, might not hold, depending on different aspects -- such as
   security and addressing (for example if prefixes used in ATS cannot
   leak to the Internet, leading to ATS traffic traversing the public
   Internet).

3.2.  Who administratively manages the RO entities?

   It is also important to analyze who will be the stakeholders than
   manage the RO entities, since this might have a critical impact on
   the trust relationships that can be assumed among the different RO
   entities.

   One first scenario is the one in which all the RO entities are
   managed by the same administrative entity.  This compresses both the
   case of RO entities deployed and managed by the airline company, and
   the case of a global ACSP providing the RO entities for airlines with
   an agreement with the ACSP.  The obvious advantage of this scenario
   is that it makes security and authentication easier, since all the RO
   entities belong to the same administrative domain.  However, this
   does not mean that this scenario is excluded from having trust
   issues, since a particular solution might require to inject routes in
   some parts of the network (e.g., RO entities owned by an airline and
   placed in networks not managed by the airline, anycast routing,
   etc.), and this could require additional trust relationships.

   A second scenario is that in which RO entities are managed by
   different administrative domains.  This approach has the advantage
   that it provides additional flexibility, but it has the drawback of
   requiring additional trust agreements in order to enable NEMO RO to
   be provided in a secure way.  Depending on the particular solution,
   these additional trust relationships may include those that are
   necessary to enable anycast routing, route injection or strong state
   synchronization, among others.  These are examples of functions that



Bernardos & Bagnulo        Expires May 7, 2009                 [Page 10]


Internet-Draft    Aeronautics NEMO RO solution analysis    November 2008


   are usually not easy to achieve across different domains.

   For AOS, it seems assumable to deploy an RO entity close the the CNs,
   and then perform RO between this entity and the MR, since both
   entities are operated by the same organization (therefore, existence
   of certificates between these nodes could be expected).  The ATS case
   is different, and should be analyzed carefully.  Although some trust
   may exist between an RO entity belonging to an ANSP and another RO
   entity (e.g., one deployed at the aircraft, or one deployed at one
   gACSP), assuming the existence of certificates or strong trust
   relationships is not clear at this point [12].  This brings the
   following question:
   o  which trust relationships are expected? this will be analyzed in
      further detail in another subsection.

3.3.  Which kind of addresses are gonna be used and who own them?

   Addressing aspects might be relevant for the design of a NEMO RO
   solution.  Some related questions are the following:
   o  are there gonna be reserved blocks of addresses for aeronautical
      use (i.e. addressing used to derive MNPs from)?
   o  can prefixes used to derive the MNPs configured at the crafts leak
      on the routing tables of the public Internet? can ATS/AOS traffic
      traverse the public Internet?
   o  what kind of addressing is gonna be used for ATS and AOS? would it
      be the same kind of addressing?
   o  is it fine to use PA addresses to derive the MNPs configured at
      the crafts or is it a requirement to use PI addresses (delegated
      to the airline, to enable provider independency)?  One possible
      solution design is that MNPs are derived from the addressing of a
      gACSP which deploy several RO entities to perform NEMO RO, but
      this scenario would tie the airline to keep using the same
      provider.

3.4.  How many RO entities are needed to globally perform NEMO RO?

   Another important aspect that should be taken into account is the
   number of RO entities that would be required to perform NEMO RO
   efficiently.  There are many aspects that may have an impact on the
   number of required RO entities, such as:
   o  Location of the RO entities.  If a solution is based on placing RO
      entities very close to the CNs this might require an entity per CN
      network (e.g., per ANSP).  Solutions relying on RO entities
      located at gACSPs may require less entities to be deployed.
   o  Who owns/manages the RO entities.  Depending on the particular
      solution, it could happen that each airline has to deploy its own
      RO entities, thus requiring a set of RO entities per airline.




Bernardos & Bagnulo        Expires May 7, 2009                 [Page 11]


Internet-Draft    Aeronautics NEMO RO solution analysis    November 2008


   o  Required level of RO.  Of course, depending on the optimization
      levels that are required to be achieved, the location and number
      of RO entities would change.  If certain amount of additional
      delay are allowed, it is expected that less entities would be
      needed, since there is usually a trade-off between the number and
      location of RO entities, and the reduction of the delay due to the
      optimized path.

3.5.  What trust relationships are needed?

   Trust relationships are a quite important aspect to be analyzed.  As
   it has been described in this document, a solution based on the
   deployment of RO entities may take many different forms, depending on
   the design decisions and the deployment assumptions that are
   followed.  Most of the design decisions would have an impact or would
   be constrained by the trust relationships that are in place among the
   different players involved in the NEMO RO.

   A solution based on the establishment of an optimized path between
   two or more RO entities inherently requires those entities to have
   strong trust relationships with the end-points of the communications,
   since they are providing an alternative -- over the MRHA default path
   -- route for their communication.  Therefore, both MNNs and CNs MUST
   have some form of trust relationship with the RO entities, to allow
   the latter set-up an optimized route for their traffic (on their
   behalf).  As an example, both the MR and the HA of a particular
   mobile network clearly have the required trust relationship with the
   MNNs of the mobile network, and therefore they could take part of an
   optimization mechanism.  Other entities but the MR and its HA would
   need additional trust relationships in place in order to take part of
   a NEMO RO solution.

   The RO entities involved in a NEMO RO solution MUST also have some
   trust relationship between them, allowing them to authenticate each
   other.

   Additionally, RO entities involved in an RO attempt MUST be able to
   show each other that they are authorized to send and receive packets
   originated/destined to the nodes (MNNs or CNs) they are providing RO
   with.  As an example, let's assume a particular solution in which
   there are two RO entities, one placed close to the mobile network,
   and the other placed close to the CN.  In this example, the entity
   close to the mobile network should be able to show to the one close
   to the CN that it is authorized to send/received packets originated/
   destined to the MNNs of that particular mobile network.  It should be
   noted that the same kind of authorization is required and provided
   when the NEMO Basic Support protocol is used (i.e. the MR has to be
   authorized to set-up a tunnel with its HA to exchange packets, and



Bernardos & Bagnulo        Expires May 7, 2009                 [Page 12]


Internet-Draft    Aeronautics NEMO RO solution analysis    November 2008


   both MR and HA have to authenticate each other before setting up the
   tunnel).  Actually, the same authorization is required between any
   Internet host and the routers it uses to forward its traffic.

   RO entities MUST also be authorized to inject the routes (if any)
   required to get the packets that are subject of being route
   optimized.  The simpler case is that in which an RO entity is the
   default router of the MNNs (i.e. the MR) or the CNs, since in this
   scenario nothing is required to make MNNs/CNs forward to the RO
   entity their traffic, and therefore this entity is inherently
   authorized to forward that traffic.  Other kind of solutions, in
   which the RO entities are not collocated with the MR and the default
   router of the CN might require the RO entities to inject routes
   within a certain portion of the network.  This might be hard to
   achieve across different domains.

   The location and ownership of the RO entities would likely have a
   great impact on the potentially required trust relationships.
   Therefore, trust and location issues have to be simultaneously
   considered.

3.6.  Is the solution flexible enough to allow the participation of the
      end-nodes (CNs and/or MNNs)?

   Supporting legacy end-nodes (MNNs and CNs) seems to be a required
   characteristic, although it is not explicitly listed as that in [6].
   That means that a solution MUST NOT require changes neither at the
   MNNs nor at the CNs to operate.  However, that does necessary imply
   that a particular solution cannot benefit from inserting changes on
   some specific MNNs and/or CNs.  In other words, a solution could
   provide the option of collocating the RO entity function within some
   MNNs and/or CNs -- in those scenarios in which these modifications
   can be done.  This brings the following question:
   o  is it permitted for a solution to collocate the RO entity function
      within certain MNNs and/or CNs in case their software upgrade is
      possible and that change brings operation benefits?

3.7.  Does the solution allow for a hierarchical scheme?

   Solutions based on the deployment of RO entities that perform the
   required route optimization operations may benefit from adopting
   hierarchical schemes.  This, for example, may help to reduce
   signaling and produce faster handovers.  Therefore, a consideration
   that could also be taken into account when designing a solution is if
   it would support a hierarchical mode of operation.

   Another somehow related design consideration is the following: a
   particular solution might benefit from deploying NetLMM-alike access



Bernardos & Bagnulo        Expires May 7, 2009                 [Page 13]


Internet-Draft    Aeronautics NEMO RO solution analysis    November 2008


   networks and collocating the functionality of the NEMO RO entity with
   that of the LMA.  This could improve the overall performance,
   although at the prize of increasing the global complexity and
   requiring ACSPs to be NetLMM-alike.

3.8.  What is the target protocol complexity?

   It is obvious that a solution should be as less complex as possible,
   but there is always a trade-off involved: less complex solutions
   usually provide less features/performance gains/etc., and the other
   way around.  There are some particular requirements of the
   aeronautical NEMO RO scenario that would likely impact on the
   solution complexity, and that should be taken into account.

   For example, in order to meet the separability requirement [12], RO
   entities in charge of performing the RO would have to be able to
   decide whether a certain flow has to be optimized or not.  This could
   be done by local policies or explicit signaling.  Even in the case of
   local policies, some mechanisms would be needed to support the
   update/modification of the policies.  It seems likely that it would
   be up to the mobile networks to decide what flows are to be optimized
   and which not.  Therefore, the costs associated to meet the
   separability requirement would likely involve some sort of signaling
   between the mobile networks and the RO entities (at least to trigger
   the NEMO RO of a particular flow).  This cost should be evaluated and
   taken into account when designing an RO entity-based solution.  As an
   example, if a solution collocates one RO entity function within the
   MR, this solution would likely require less signaling to meet the
   separability requirement than another solution that makes use of RO
   entities placed on the network infrastructure.

3.9.  How is routing performed within the ATN?

   Routing policies and related issues within the ATN are an important
   input to be considered when designing an RO entity-based solution.
   Therefore, we should address the following questions:
   o  is it OK to have asymmetrical optimized routes? depending on the
      design of the solution, it might be possible that some sort of
      asymmetric routing appears.
   o  what are the routing policies followed by the ACSPs (especially
      gACSPs)? do they do cold or hot-potato routing? cold-potato
      routing may lead to very suboptimal routes under some particular
      scenarios, even when a NEMO RO solution is used.

3.10.  Does the solution allow for implementing legal/political/
       economical requirements?

   In some Internet scenarios, it is preferred that data traffic does



Bernardos & Bagnulo        Expires May 7, 2009                 [Page 14]


Internet-Draft    Aeronautics NEMO RO solution analysis    November 2008


   not traverse certain networks because of different reasons, such as
   legal, political or economical ones.  Is that also the case for the
   aeronautics use case?.  If so, it might be important to provide NEMO
   RO solutions with the required mechanisms to implement the policies
   that translate those potential legal/political/economical
   requirements.

3.11.  What is the robustness of the solution (i.e. what type of failure
       affects to the reachability)?

   It is also important to analyze the robustness of a particular
   solution design, in terms of the types of failures that might affect
   to the reachability of the network.  For example, a solution may
   provide an RO path despite of a broken path between the NEMO and its
   home network, while another one may not.  It is important to identify
   which are the failures that can happen in an ATN, which ones would
   only affect the reachability of a craft only when using a NEMO RO
   solution, and if it is fine to have those failures.


4.  Security Considerations

   This document analyzes a general approach to perform NEMO RO for the
   aeronautics use case.  As such, it identifies some security issues
   that should be taken into account in the design of a concrete
   solution.


5.  IANA Considerations

   This document has no actions for IANA.


6.  Acknowledgments

   The work of Carlos J. Bernardos has been partly supported by the
   Spanish Government under the POSEIDON (TSI2006-12507-C03-01) project.


7.  References

7.1.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

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



Bernardos & Bagnulo        Expires May 7, 2009                 [Page 15]


Internet-Draft    Aeronautics NEMO RO solution analysis    November 2008


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

7.2.  Informative References

   [4]   Manner, J. and M. Kojo, "Mobility Related Terminology",
         RFC 3753, June 2004.

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

   [6]   Eddy, W., Ivancic, W., and T. Davis, "NEMO Route Optimization
         Requirements for Operational Use in Aeronautics and  Space
         Exploration Mobile Networks", draft-ietf-mext-aero-reqs-02
         (work in progress), May 2008.

   [7]   Baldessari, R., Ernst, T., Festag, A., and M. Lenardi,
         "Automotive Industry Requirements for NEMO Route Optimization",
         draft-ietf-mext-nemo-ro-automotive-req-01 (work in progress),
         July 2008.

   [8]   Ng, C., Hirano, J., Petrescu, A., and E. Paik, "Consumer
         Electronics Requirements for Network Mobility Route
         Optimization", draft-ng-nemo-ce-req-02 (work in progress),
         February 2008.

   [9]   Thubert, P., Wakikawa, R., and V. Devarapalli, "Global HA to HA
         protocol", draft-thubert-mext-global-haha-00 (work in
         progress), March 2008.

   [10]  Wakikawa, R., Shima, K., and N. Shigechika, "The Global HAHA
         Operation at the Interop Tokyo 2008",
         draft-wakikawa-mext-haha-interop2008-00 (work in progress),
         July 2008.

   [11]  Bernardos, C., Calderon, M., and I. Soto, "Correspondent Router
         based Route Optimisation for NEMO (CRON)",
         draft-bernardos-mext-nemo-ro-cr-00 (work in progress),
         July 2008.

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







Bernardos & Bagnulo        Expires May 7, 2009                 [Page 16]


Internet-Draft    Aeronautics NEMO RO solution analysis    November 2008


Appendix A.  Change Log

   Changes from -00 to -01:
   o  Terminology changes: s/correspondent entity/RO entity.
   o  New solution design issue: robustness.
   o  Marcelo Bagnulo enlisted as author.
   o  Some editorial changes.


Authors' Addresses

   Carlos J. Bernardos
   Universidad Carlos III de Madrid
   Av. Universidad, 30
   Leganes, Madrid  28911
   Spain

   Phone: +34 91624 6236
   Email: cjbc@it.uc3m.es
   URI:   http://www.it.uc3m.es/cjbc/


   Marcelo Bagnulo
   Universidad Carlos III de Madrid
   Av. Universidad, 30
   Leganes, Madrid  28911
   Spain

   Phone: +34 91624 9500
   Email: marcelo@it.uc3m.es
   URI:   http://www.it.uc3m.es/marcelo/




















Bernardos & Bagnulo        Expires May 7, 2009                 [Page 17]


Internet-Draft    Aeronautics NEMO RO solution analysis    November 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Bernardos & Bagnulo        Expires May 7, 2009                 [Page 18]


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