GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5522

Network Working Group W. Eddy Request for Comments: 5522 Verizon Category: Informational W. Ivancic

                                                                  NASA
                                                              T. Davis
                                                                Boeing
                                                          October 2009
        Network Mobility Route Optimization Requirements for
Operational Use in Aeronautics and Space Exploration Mobile Networks

Abstract

 This document describes the requirements and desired properties of
 Network Mobility (NEMO) Route Optimization techniques for use in
 global-networked communications systems for aeronautics and space
 exploration.
 Substantial input to these requirements was given by aeronautical
 communications experts outside the IETF, including members of the
 International Civil Aviation Organization (ICAO) and other
 aeronautical communications standards bodies.

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

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
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the BSD License.

Eddy, et al. Informational [Page 1] RFC 5522 Aero and Space NEMO RO Requirements October 2009

Table of Contents

 1. Introduction ....................................................2
 2. NEMO RO Scenarios ...............................................5
    2.1. Aeronautical Communications Scenarios ......................5
         2.1.1. Air Traffic Services Domain .........................6
         2.1.2. Airline Operational Services Domain .................8
         2.1.3. Passenger Services Domain ...........................9
    2.2. Space Exploration Scenarios ...............................10
 3. Required Characteristics .......................................12
    3.1. Req1 - Separability .......................................13
    3.2. Req2 - Multihoming ........................................14
    3.3. Req3 - Latency ............................................15
    3.4. Req4 - Availability .......................................16
    3.5. Req5 - Packet Loss ........................................17
    3.6. Req6 - Scalability ........................................18
    3.7. Req7 - Efficient Signaling ................................19
    3.8. Req8 - Security ...........................................20
    3.9. Req9 - Adaptability .......................................22
 4. Desirable Characteristics ......................................22
    4.1. Des1 - Configuration ......................................22
    4.2. Des2 - Nesting ............................................23
    4.3. Des3 - System Impact ......................................23
    4.4. Des4 - VMN Support ........................................23
    4.5. Des5 - Generality .........................................24
 5. Security Considerations ........................................24
 6. Acknowledgments ................................................24
 7. References .....................................................25
    7.1. Normative References ......................................25
    7.2. Informative References ....................................25
 Appendix A.  Basics of IP-Based Aeronautical Networking  ........28
 Appendix B.  Basics of IP-based Space Networking ................30

1. Introduction

 As background, the Network Mobility (NEMO) terminology and NEMO goals
 and requirements documents are suggested reading ([4], [5]).
 The base NEMO standard [1] extends Mobile IPv6 [2] for singular
 mobile hosts in order to be used by Mobile Routers (MRs) supporting
 entire mobile networks.  NEMO allows mobile networks to efficiently
 remain reachable via fixed IP address prefixes no matter where they
 relocate within the network topology.  This is accomplished through
 the maintenance of a bidirectional tunnel between a NEMO MR and a
 NEMO-supporting Home Agent (HA) placed at some relatively stable
 point in the network.  NEMO does not provide Mobile IPv6's Route
 Optimization (RO) features to Mobile Network Nodes (MNNs) other than
 to the NEMO MR itself.  Corresponding Nodes (CNs) that communicate

Eddy, et al. Informational [Page 2] RFC 5522 Aero and Space NEMO RO Requirements October 2009

 with MNNs behind an MR do so through the HA and the bidirectional
 Mobile Router - Home Agent (MRHA) tunnel.  Since the use of this
 tunnel may have significant drawbacks [6], RO techniques that allow a
 more direct path between the CN and MR to be used are highly
 desirable.
 For decades, mobile networks of some form have been used for
 communications with people and avionics equipment on board aircraft
 and spacecraft.  These have not typically used IP, although
 architectures are being devised and deployed based on IP in both the
 aeronautics and space exploration communities (see Appendix A and
 Appendix B for more information).  An aircraft or spacecraft
 generally contains many computing nodes, sensors, and other devices
 that are possible to address individually with IPv6.  This is
 desirable to support network-centric operations concepts.  Given that
 a craft has only a small number of access links, it is very natural
 to use NEMO MRs to localize the functions needed to manage the large
 onboard network's reachability over the few dynamic access links.  On
 an aircraft, the nodes are arranged in multiple, independent
 networks, based on their functions.  These multiple networks are
 required for regulatory reasons to have different treatments of their
 air-ground traffic and must often use distinct air-ground links and
 service providers.
 For aeronautics, the main disadvantage of using NEMO bidirectional
 tunnels is that airlines operate flights that traverse multiple
 continents, and a single plane may fly around the entire world over a
 span of a couple days.  If a plane uses a static HA on a single
 continent, then for a large percentage of the time, when the plane is
 not on the same continent as the HA, a great amount of delay is
 imposed by using the MRHA tunnel.  Avoiding the delay from
 unnecessarily forcing packets across multiple continents is the
 primary goal of pursuing NEMO RO for aeronautics.
 Other properties of the aeronautics and space environments amplify
 the known issues with NEMO bidirectional MRHA tunnels [6] even
 further.
    Longer routes leading to increased delay and additional
    infrastructure load:
       In aeronautical networks (e.g., using "Plain Old" Aircraft
       Communication Addressing and Reporting System (ACARS) or ACARS
       over VHF Data Link (VDL) mode 2) the queueing delays are often
       long due to Automatic Repeat Request (ARQ) mechanisms and
       underprovisioned radio links.  Furthermore, for space
       exploration and for aeronautical communications systems that
       pass through geosynchronous satellites, the propagation delays
       are also long.  These delays, combined with the additional need

Eddy, et al. Informational [Page 3] RFC 5522 Aero and Space NEMO RO Requirements October 2009

       to cross continents in order to transport packets between
       ground stations and CNs, mean that delays are already quite
       high in aeronautical and space networks without the addition of
       an MRHA tunnel.  The increased delays caused by MRHA tunnels
       may be unacceptable in meeting Required Communication
       Performance [7].
    Increased packet overhead:
       Given the constrained link bandwidths available in even future
       communications systems for aeronautics and space exploration,
       planners are extremely adverse to header overhead.  Since any
       amount of available link capacity can be utilized for extra
       situational awareness, science data, etc., every byte of
       header/tunnel overhead displaces a byte of useful data.
    Increased chances of packet fragmentation:
       RFC 4888 [6] identifies fragmentation due to encapsulation as
       an artifact of tunneling.  While links used in the aeronautics
       and space domains are error-prone and may cause loss of
       fragments on the initial/final hop(s), considerations for
       fragmentation along the entire tunneled path are the same as
       for the terrestrial domain.
    Increased susceptibility to failure:
       The additional likelihood of either a single link failure
       disrupting all communications or an HA failure disrupting all
       communications is problematic when using MRHA tunnels for
       command and control applications that require high availability
       for safety-of-life or safety-of-mission.
 For these reasons, an RO extension to NEMO is highly desirable for
 use in aeronautical and space networking.  In fact, a standard RO
 mechanism may even be necessary before some planners will seriously
 consider advancing use of the NEMO technology from experimental
 demonstrations to operational use within their communications
 architectures.  Without an RO solution, NEMO is difficult to justify
 for realistic operational consideration.
 In Section 2 we describe the relevant high-level features of the
 access and onboard networks envisioned for use in aeronautics and
 space exploration, as they influence the properties of usable NEMO RO
 solutions.  Section 3 then lists the technical and functional
 characteristics that are absolutely required of a NEMO RO solution
 for these environments, while Section 4 lists some additional
 characteristics that are desired but not necessarily required.  In
 Appendix A and Appendix B we provide brief primers on the specific
 operational concepts used in aeronautics and space exploration,
 respectively, for IP-based network architectures.

Eddy, et al. Informational [Page 4] RFC 5522 Aero and Space NEMO RO Requirements October 2009

 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 [3].
 Although this document does not specify an actual protocol, but
 rather specifies just the requirements for a protocol, it still uses
 the RFC 2119 language to make the requirements clear.

2. NEMO RO Scenarios

 To motivate and drive the development of the requirements and
 desirable features for NEMO RO solutions, this section describes some
 operational characteristics to explain how access networks, HAs, and
 CNs are configured and distributed geographically and topologically
 in aeronautical and space network architectures.  This may be useful
 in determining which classes of RO techniques within the known
 solution space [8] are feasible.

2.1. Aeronautical Communications Scenarios

 Since aircraft may be simultaneously connected to multiple ground
 access networks using diverse technologies with different coverage
 properties, it is difficult to say much in general about the rate of
 changes in active access links and care-of addresses (CoAs).  As one
 data point, for using VDL mode 2 data links, the length of time spent
 on a single access channel varies depending on the stage of flight.
 On the airport surface, VDL mode 2 access is stable while a plane is
 unloaded, loaded, refueled, etc., but other wired and wireless LAN
 links (e.g. local networks available while on a gate) may come and
 go.  Immediately after takeoff and before landing, planes are in the
 terminal maneuvering area for approximately 10 minutes and stably use
 another VDL mode 2 channel.  During en route flight, handovers
 between VDL mode 2 channels may occur every 30 to 60 minutes,
 depending on the exact flight plan and layout of towers, cells, and
 sectors used by a service provider.  These handovers may result in
 having a different access router and a change in CoA, though the use
 of local mobility management (e.g., [9]) may limit the changes in CoA
 to only handovers between different providers or types of data links.
 The characteristics of a data flow between a CN and MNN varies both
 depending on the data flow's domain and on the particular application
 within the domain.  Even within the three aeronautical domains
 described below, there are varying classes of service that are
 regulated differently (e.g., for emergencies versus nominal
 operations), but this level of detail has been abstracted out for the
 purposes of this document.  It is assumed that any viable NEMO RO
 solution will be able to support a granularity of configuration with
 many sub-classes of traffic within each of the specific domains
 listed here.

Eddy, et al. Informational [Page 5] RFC 5522 Aero and Space NEMO RO Requirements October 2009

2.1.1. Air Traffic Services Domain

 The MNNs involved in Air Traffic Services (ATS) consist of pieces of
 avionics hardware on board an aircraft that are used to provide
 navigation, control, and situational awareness.  The applications run
 by these MNNs are mostly critical to the safety of the lives of the
 passengers and crew.  The MNN equipment may consist of a range of
 devices from typical laptop computers to very specialized avionics
 devices.  These MNNs will mostly be Local Fixed Nodes (LFNs), with a
 few Local Mobile Nodes (LMNs) to support Electronic Flight Bags, for
 instance.  It can be assumed that Visiting Mobile Nodes (VMNs) are
 never used within the ATS domain.
 An MR used for ATS will be capable of using multiple data links (at
 least VHF-based, satellite, HF-based, and wired), and will likely be
 supported by a backup unit in the case of failure, leading to a case
 of a multihomed MR that is at least multi-interfaced and possibly
 multi-prefixed as well, in NEMO terminology.
 The existing ATS link technologies may be too anemic for a complete
 IP-based ATS communications architecture (link technologies and
 acronyms are briefly defined in Appendix A).  At the time of this
 writing, the ICAO is pursuing future data link standards that support
 higher data rates.  Part of the problem is limited spectrum, pursued
 under ICAO ACP-WG-F, "Spectrum Management", and part of the problem
 is the data link protocols themselves, pursued under ICAO ACP-WG-T,
 "Future Communications Technology".  ACP-WG-T has received inputs
 from studies on a number of potential data link protocols, including
 B-AMC, AMACS, P34, LDL, WCDMA, and others.  Different link
 technologies may be used in different stages of flight, for instance
 802.16 in the surface and terminal area, P34 or LDL en route, and
 satcom in oceanic flight.  Both current and planned data links used
 for Passenger Information and Entertainment Services (PIES) and/or
 Airline Operational Services (AOS), such as the satcom links employed
 by passenger Internet-access systems, support much higher data rates
 than current ATS links.
 Since, for ATS, the MRs and MNNs are under regulatory control and are
 actively tested and maintained, it is not completely unreasonable to
 assume that special patches or software be run on these devices to
 enable NEMO RO.  In fact, since these devices are accessed by skilled
 technicians and professionals, it may be that some special
 configuration is required for NEMO RO.  Of course, simplicity in set
 up and configuration is highly preferable, however, and the desirable
 feature labeled "Des1" later in this document prefers solutions with
 lower configuration state and overhead.  To minimize costs of

Eddy, et al. Informational [Page 6] RFC 5522 Aero and Space NEMO RO Requirements October 2009

 ownership and operations, it is also highly desirable for only widely
 available, off-the-shelf operating systems or network stacks to be
 required, but this is not a full requirement.
 Data flows from the ATS domain may be assumed to consist mainly of
 short transactional exchanges, such as clearance requests and grants.
 Future ATS communications are likely to include longer messages and
 higher message frequencies for positional awareness and trajectory
 intent of all vehicles in motion at the airport and all aircraft
 within a thirty-mile range during flight.  Many of these may be
 aircraft-to-aircraft, but the majority of current exchanges are
 between the MNNs and a very small set of CNs within a control
 facility and take place at any time due to the full transfer of
 control as a plane moves across sectors of airspace.  The set of CNs
 may be assumed to be topologically close to one another.  These CNs
 are also involved in other data flows over the same access network
 that the MR is attached to, managing other flights within the sector.
 These CNs are often geographically and topologically much closer to
 the MR in comparison to a single fixed HA.
 The MNNs and CNs used for ATS will support IP services, as IP is the
 basis of the new Aeronautical Telecommunications Network (ATN)
 architecture being defined by ICAO.  Some current ATS ground systems
 run typical operating systems, like Solaris, Linux, and Windows, on
 typical workstation computer hardware.  There is some possibility for
 an RO solution to require minor changes to these CNs, though it is
 much more desirable if completely off-the-shelf CN machines and
 operating systems can be used.  Later in this document, the security
 requirements suggest that RO might be performed with mobility anchors
 that are topologically close to the CNs, rather than directly to CNs
 themselves.  This could possibly mean that CN modifications are not
 required.
 During the course of a flight, there are several events for which an
 RO solution should consider the performance implications:
 o  Initial session creation with an ATS CN (called "Data Link Logon"
    in the aeronautical jargon).
 o  Transfer of control between ATS CNs, resulting in regional
    differences in where the controlling CN is located.
 o  Aircraft-initiated contact with a non-controlling ATS CN, which
    may be located anywhere, without relation to the controlling CN.
 o  Non-controlling, ATS, CN-initiated contact with the aircraft.

Eddy, et al. Informational [Page 7] RFC 5522 Aero and Space NEMO RO Requirements October 2009

 o  Aircraft transition between one access link to another, resulting
    in change of CoA.
 o  Concurrent use of multiple access links with different care-of
    addresses.

2.1.2. Airline Operational Services Domain

 Data flows for Airline Operational Services (AOS) are not critical to
 the safety of the passengers or aircraft, but are needed for the
 business operations of airlines operating flights, and may affect the
 profitability of an airline's flights.  Most of these data flows are
 sourced by MNNs that are part of the flight management system or
 sensor nodes on an aircraft, and are terminated at CNs located near
 an airline's headquarters or operations center.  AOS traffic may
 include detailed electronic passenger manifests, passenger ticketing
 and rebooking traffic, and complete electronic baggage manifests.
 When suitable bandwidth is available (currently on the surface when
 connected to a wired link at a gate), "airplane health information"
 data transfers of between 10 and several hundred megabytes of data
 are likely, and in the future, it is expected that the In-Flight
 Entertainment (IFE) systems may receive movie refreshes of data
 (e.g., television programming or recent news updates) running into
 the multi-gigabyte range.
 Currently, these flows are often short messages that record the
 timing of events of a flight, engine performance data, etc., but may
 be longer flows that upload weather or other supplementary data to an
 aircraft.  In addition, email-like interactive messaging may be used
 at any time during a flight.  For instance, messages can be exchanged
 before landing to arrange for arrival-gate services to be available
 for handicapped passengers, refueling, food and beverage stocking,
 and other needs.  This messaging is not limited to landing
 preparation, though, and may occur at any stage of flight.
 The equipment comprising these MNNs and CNs has similar
 considerations to the equipment used for the ATS domain.  A key
 difference between ATS and AOS is that AOS data flows are routed to
 CNs that may be much more geographically remote to the aircraft than
 CNs used by ATS flows, as AOS CNs will probably be located at an
 airline's corporate data center or headquarters.  The AOS CNs will
 also probably be static for the lifetime of the flight, rather than
 dynamic like the ATS CNs.  An HA used for AOS may be fairly close
 topologically to the CNs, and RO may not be as big of a benefit for
 AOS since simple event logging is more typical than time-critical
 interactive messaging.  For the small number of messaging flows,
 however, the CNs are geographically (but not necessarily
 topologically) very close to the aircraft, though this depends on how

Eddy, et al. Informational [Page 8] RFC 5522 Aero and Space NEMO RO Requirements October 2009

 applications are written -- whether they use centralized servers or
 exchange messages directly.  Additionally, since AOS communication is
 more advisory in nature than ATS, rather than safety-critical, AOS
 flows are less sensitive to tunnel inefficiencies than ATS flows.
 For these reasons, in this document, we consider AOS data flow
 concerns with RO mechanisms to not be full requirements, but instead
 consider them desirable properties, which are discussed in Section 4.
 Future AOS MNNs and CNs can be expected to implement IPv6 and conform
 to the new IPv6-based ATN Standards and Recommended Practices (SARPS)
 that ICAO is defining.  AOS CNs have similar hardware and software
 properties as described for ATS above.

2.1.3. Passenger Services Domain

 The MNNs involved in the Passenger Information and Entertainment
 Services (PIES) domain are mostly beyond the direct control of any
 single authority.  The majority of these MNNs are VMNs and personal
 property brought on board by passengers for the duration of a flight,
 and thus it is unreasonable to assume that they be preloaded with
 special software or operating systems.  These MNNs run stock Internet
 applications like web browsing, email, and file transfer, often
 through VPN tunnels.  The MNNs themselves are portable electronics,
 such as laptop computers and mobile smartphones capable of connecting
 to an onboard wireless access network (e.g., using 802.11).  To these
 MNN devices and users, connecting to the onboard network is identical
 to connecting to any other terrestrial "hotspot" or typical wireless
 LAN.  The MNNs are completely oblivious to the fact that this access
 network is on an airplane and possibly moving around the globe.  The
 users are not always technically proficient and may not be capable of
 performing any special configuration of their MNNs or applications.
 The largest class of PIES CNs consists of typical web servers and
 other nodes on the public Internet.  It is not reasonable to assume
 that these can be modified specifically to support a NEMO RO scheme.
 Presently, these CNs would be mostly IPv4-based, though an increasing
 number of IPv6 PIES CNs are expected in the future.  This document
 does not consider the problem of IPv4-IPv6 transition, beyond the
 assumption that either MNNs and CNs are running IPv6 or a transition
 mechanism exists somewhere within the network.
 A small number of PIES MNNs may be LFNs that store and distribute
 cached media content (e.g., movies and music) or that may provide
 gaming services to passengers.  Due to the great size of the data
 stored on these LFNs compared to the anemic bandwidth available air-
 to-ground, these LFNs will probably not attempt to communicate off-
 board at all during the course of a flight, but will wait to update
 their content via either high-speed links available on the ground or

Eddy, et al. Informational [Page 9] RFC 5522 Aero and Space NEMO RO Requirements October 2009

 removable media inserted by the flight crew.  However, if a higher
 bandwidth link were affordably available, it might be used in-flight
 for these purposes, but supporting this is not a requirement.  Data
 flows needed for billing passengers for access to content are
 relatively low bandwidth and are currently done in-flight.  The
 requirements of these data flows are less stringent than those of
 ATS, however, so they are not specifically considered here.
 The PIES domain is not critical to safety-of-life, but is merely an
 added comfort or business service to passengers.  Since PIES
 applications may consume much more bandwidth than the available links
 used in other domains, the PIES MNNs may have their packets routed
 through a separate high-bandwidth link that is not used by the ATS
 data flows.  For instance, several service providers are planning to
 offer passenger Internet access during flight at DSL-like rates, just
 as the former Connexion by Boeing system did.  Several airlines also
 plan to offer onboard cellular service to their passengers, possibly
 utilizing Voice-over-IP for transport.  Due to the lack of
 criticality and the likelihood of being treated independently, in
 this document, PIES MNN concerns are not considered as input to
 requirements in Section 3.  The RO solution should be optimized for
 ATS and AOS needs and consider PIES as a secondary concern.
 With this in consideration, the PIES domain is also the most likely
 to utilize NEMO for communications in the near-term, since relatively
 little regulations and bureaucracy are involved in deploying new
 technology in this domain and since IP-based PIES systems have
 previously been developed and deployed (although not using NEMO)
 [10].  For these reasons, PIES concerns factor heavily into the
 desirable properties in Section 4, outside of the mandatory
 requirements.
 Some PIES nodes are currently using 2.5G/3G links for mobile data
 services, and these may be able to migrate to an IP-based onboard
 mobile network, when available.

2.2. Space Exploration Scenarios

 This section describes some features of the network environments
 found in space exploration that are relevant to selecting an
 appropriate NEMO RO mechanism.  It should be noted that IPv4-based
 mobile routing has been demonstrated on board the UK-DMC satellite
 and that the documentation on this serves as a useful reference for
 understanding some of the goals and configuration issues for certain
 types of space use of NEMO [11].  This section assumes space use of
 NEMO within the "near-Earth" range of space (i.e., not for
 communications between the Earth and Mars or other "deep space"
 locations).  Note that NEMO is currently being considered for use out

Eddy, et al. Informational [Page 10] RFC 5522 Aero and Space NEMO RO Requirements October 2009

 to lunar distances.  No strong distinction is made here between
 civilian versus military use, or exploration mission versus Earth-
 observing or other mission types; our focus is on civilian
 exploration missions, but we believe that many of the same basic
 concerns are relevant to these other mission types.
 In space communications, a high degree of bandwidth asymmetry is
 often present, with the uplink from the ground to a craft typically
 being multiple orders of magnitude slower than the downlink from the
 craft to the ground.  This means that the RO overhead may be
 negligible on the downlink but significant for the uplink.  An RO
 scheme that minimizes the amount of signaling from CNs to an MN is
 desirable, since these uplinks may be low-bandwidth to begin with
 (possibly only several kilobits per second).  Since the uplink is
 used for sending commands, it should not be blocked for long periods
 while serializing long RO signaling packets; any RO signaling from
 the CN to MNNs must not involve large packets.
 For unmanned space flight, the MNNs on board a spacecraft consist
 almost entirely of LFN-sensing devices and processing devices that
 send telemetry and science data to CNs on the ground and actuator
 devices that are commanded from the ground in order to control the
 craft.  Robotic lunar rovers may serve as VMNs behind an MR located
 on a lander or orbiter, but these rovers will contain many
 independent instruments and could probably be configured as an MR and
 LFNs instead of using a single VMN address.
 It can be assumed that for manned spaceflight, at least multiple MRs
 will be present and online simultaneously for fast failover.  These
 will usually be multihomed over space links in diverse frequency
 bands, and so multiple access network prefixes can be expected to be
 in use simultaneously, especially since some links will be direct to
 ground stations while others may be bent-pipe repeated through
 satellite relays like the Tracking and Data Relay Satellite System
 (TDRSS).  This conforms to the (n,1,1) or (n,n,1) NEMO multihoming
 scenarios [12].  For unmanned missions, if low weight and power are
 more critical, it is likely that only a single MR and single link/
 prefix may be present, conforming to the (1,1,1) or (1,n,1) NEMO
 multihoming scenarios [12].
 In some modes of spacecraft operation, all communications may go
 through a single onboard computer (or a Command and Data Handling
 system as on the International Space Station) rather than directly to
 the MNNs themselves, so there is only ever one MNN behind an MR that
 is in direct contact with off-board CNs.  In this case, removing the
 MR and using simple host-based Mobile IPv6 rather than NEMO is
 possible.  However, an MR is more desirable because it could be part
 of a modular communications adapter that is used in multiple diverse

Eddy, et al. Informational [Page 11] RFC 5522 Aero and Space NEMO RO Requirements October 2009

 missions to bridge onboard buses and intelligently manage space
 links.  This is cheaper and leads to faster development time than
 re-creating these capabilities per-mission if using simple Mobile
 IPv6 with a single Command and Data Handling node that varies widely
 between spacecraft.  Also, all visions for the future involve
 network-centric operations where the direct addressability and
 accessibility of end devices and data is crucial.  As network-centric
 operations become more prevalent, application of NEMO is likely to be
 needed to increase the flexibility of data flow.
 The MRs and MNNs on board a spacecraft are highly customized
 computing platforms, and adding custom code or complex configurations
 in order to obtain NEMO RO capabilities is feasible, although it
 should not be assumed that any amount of code or configuration
 maintenance is possible after launch.  The RO scheme as it is
 initially configured should continue to function throughout the
 lifetime of an asset.
 For manned space flight, additional MNNs on spacesuits and astronauts
 may be present and used for applications like two-way voice
 conversation or video-downlink.  These MNNs could be reusable and
 reconfigured per-flight for different craft or mission network
 designs, but it is still desirable for them to be able to
 autoconfigure themselves, and they may move between nested or non-
 nested MRs during a mission.  For instance, if astronauts move
 between two docked spacecrafts, each craft may have its own local MR
 and wireless coverage that the suit MNNs will have to reconfigure
 for.  It is desirable if an RO solution can respond appropriately to
 this change in locality and not cause high levels of packet loss
 during the transitional period.  It is also likely that these MNNs
 will be part of Personal Area Networks (PANs), and so may appear
 either directly as MNNs behind the main MR on board or have their own
 MR within the PAN and thus create a nested (or even multi-level
 nested) NEMO configuration.

3. Required Characteristics

 This section lists requirements that specify the absolute minimal
 technical and/or functional properties that a NEMO RO mechanism must
 possess to be usable for aeronautical and space communications.
 In the recent work done by the International Civil Aviation
 Organization (ICAO) to identify viable mobility technologies for
 providing IP services to aircraft, a set of technical criteria was
 developed ([13], [14]).  The nine required characteristics listed in
 this document can be seen as directly descended from these ICAO
 criteria, except here we have made them much more specific and
 focused for the NEMO technology and the problem of RO within NEMO.

Eddy, et al. Informational [Page 12] RFC 5522 Aero and Space NEMO RO Requirements October 2009

 The original ICAO criteria were more general and used for comparing
 the features of different mobility solutions (e.g., mobility
 techniques based on routing protocols versus transport protocols
 versus Mobile IP, etc.).  Within the text describing each requirement
 in this section, we provide the high-level ICAO criteria from which
 it evolved.
 These requirements for aeronautics are generally similar to or in
 excess of the requirements for space exploration, so we do not add
 any additional requirements specifically for space exploration.  In
 addition, the lack of a standards body regulating performance and
 safety requirements for space exploration means that the requirements
 for aviation are much easier to agree upon and base within existing
 requirements frameworks.  After consideration, we believe that the
 set of aviation-based requirements outlined here also fully suffices
 for space exploration.
 It is understood that different solutions may be needed for
 supporting different domains.  This may mean either different NEMO RO
 solutions or different mobility solutions entirely.  Divergent
 solutions amongst the domains are acceptable, though preferably
 avoided if possible.
 An underlying requirement that would be assumed by the use of Mobile
 IP technology for managing mobility (rather than a higher-layer
 approach) is that IP addresses used both within the mobile network
 and by CNs to start new sessions with nodes within the mobile network
 remain constant throughout the course of flights and operations.  For
 ATS and AOS, this allows the Home Addresses (HoAs) to serve as node
 identifiers, rather than just locators, and for PIES it allows common
 persistent applications (e.g., Voice over IP (VoIP) clients, VPN
 clients, etc.) to remain connected throughout a flight.  Prior
 aeronautical network systems like the prior OSI-based ATN and
 Connexion by Boeing set a precedent for keeping a fixed Mobile
 Network Prefix (MNP), though they relied on interdomain routing
 protocols (IDRP and BGP) to accomplish this, rather than NEMO
 technology.  This requirement applies to the selection in general of
 a mobility management technology, and not specifically to an RO
 solution once NEMO has been decided on for mobility management.

3.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.
 Entries in this database can be similar to those used in IPsec
 security policy databases in order to specify either bypassing or
 utilizing RO for specific flows.

Eddy, et al. Informational [Page 13] RFC 5522 Aero and Space NEMO RO Requirements October 2009

3.1.1. Rationale for Aeronautics - Separability

 Even if RO is available to increase the performance of a mobile
 network's traffic, it may not be appropriate for all flows.
 There may also be a desire to push certain flows through the MRHA
 path, rather than performing RO, to enable them to be easily recorded
 by a central service.
 For these reasons, an RO scheme must have the ability to be bypassed
 by applications that desire to use bidirectional tunnels through an
 HA.  This desire could be expressed through a policy database similar
 to the security policy database used by IPsec, for instance, but the
 specific means of signaling or configuring the expression of this
 desire by applications is left as a detail for the specific RO
 specifications.
 In addition, it is expected that the use of NEMO technology be
 decided on a per-domain basis, so that it is possible that, for some
 domains, separate MRs or even non-NEMO mobility techniques are used.
 This requirement for an RO policy database only applies to domains
 that utilize NEMO.
 This requirement was derived from ICAO's TC-1 [15] - "The approach
 should provide a means to define data communications that can be
 carried only over authorized paths for the traffic type and category
 specified by the user."
 One suggested approach to traffic separation is multi-addressing of
 the onboard networks, with treatment of a traffic domain determined
 by the packet addresses used.  However, there are other techniques
 possible for meeting this requirement, and so multi-addressing is not
 itself a requirement.  The Req1 requirement we describe above is
 intended for separating the traffic within a domain that makes use of
 NEMO based on flow properties (e.g., short messaging flows vs. longer
 file transfers or voice flows).

3.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.

3.2.1. Rationale for Aeronautics - Multihoming

 Multiple factors drive a requirement for multihoming capabilities.
 For ATS safety-of-life critical traffic, the need for high
 availability suggests a basic multihoming requirement.  The

Eddy, et al. Informational [Page 14] RFC 5522 Aero and Space NEMO RO Requirements October 2009

 regulatory and operational difficulty in deploying new systems and
 transitioning away from old ones also implies that a mix of access
 technologies may be in use at any given time, and may require
 simultaneous use.  Another factor is that the multiple domains of
 applications on board may actually be restricted in what data links
 they are allowed to use, based on regulations and policy; thus, at
 certain times or locations, PIES data flows may have to use distinct
 access links from those used by ATS data flows.
 This drives the requirement that an RO solution MUST allow for an MR
 to be connected to multiple access networks simultaneously and have
 multiple CoAs in use simultaneously.  The selection of a proper CoA
 and access link to use per-packet may be either within or outside the
 scope of the RO solution.  As a minimum, if an RO solution is
 integrable with the MONAMI6 basic extensions (i.e., registration of
 multiple CoAs and flow bindings) and does not preclude their use,
 then this requirement can be considered to be satisfied.
 It is not this requirement's intention that an RO scheme itself
 provide multihoming, but rather simply to exclude RO techniques whose
 use is not possible in multihomed scenarios.
 In terms of NEMO multihoming scenarios [12], it MUST be possible to
 support at least the (n,1,n) and (n,n,n) scenarios.
 This requirement was derived from ICAO's TC-2 - "The approach should
 enable an aircraft to both roam between and to be simultaneously
 connected to multiple independent air-ground networks."

3.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.

3.3.1. Rationale for Aeronautics - Latency

 It is possible that an RO scheme may take longer to set up or involve
 more signaling than the basic NEMO MRHA tunnel maintenance that
 occurs during an update to the MR's active CoAs when the set of
 usable access links changes.  During this period of flux, it may be
 important for applications to be able to immediately get packets onto
 the ground network, especially considering that connectivity may have
 been blocked for some period of time while link-layer and NEMO
 procedures for dealing with the transition occurred.  Also, when an
 application starts for the first time, the RO scheme may not have
 previous knowledge related to the CN and may need to perform some set

Eddy, et al. Informational [Page 15] RFC 5522 Aero and Space NEMO RO Requirements October 2009

 up before an optimized path is available.  If the RO scheme blocks
 packets either through queueing or dropping while it is configuring
 itself, this could result in unacceptable delays.
 Thus, when transitions in the MR's set of active access links occurs,
 the RO scheme MUST NOT block packets from using the MRHA tunnel if
 the RO scheme requires more time to set up or configure itself than
 the basic NEMO tunnel maintenance.  Additionally, when an application
 flow is started, the RO scheme MUST allow packets to immediately be
 sent, perhaps without the full benefit of RO, if the RO scheme
 requires additional time to configure a more optimal path to the CN.
 This requirement was derived from ICAO's TC-3 - "The approach should
 minimize latency during establishment of initial paths to an
 aircraft, during handoff, and during transfer of individual data
 packets."

3.4. Req4 - Availability

 An RO solution MUST be compatible with network redundancy mechanisms
 and MUST NOT prevent fallback 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
 communications in general.

3.4.1. Rationale for Aeronautics - Availability

 A need for high availability of connectivity to ground networks
 arises from the use of IP networking for carrying safety-of-life
 critical traffic.  For this reason, single points of failure need to
 be avoided.  If an RO solution assumes either a single onboard MR, a
 single HA, or some similar vulnerable point, and is not usable when
 the network includes standard reliability mechanisms for routers,
 then the RO technique will not be acceptable.  An RO solution also
 MUST NOT itself imply a single point of failure.
 This requirement specifies that the RO solution itself does not
 create any great new fragility.  Although in basic Mobile IPv6 and
 NEMO deployments, the use of a single HA implies a single point of
 failure, there are mechanisms enabling the redundancy of HAs (e.g.,
 [16]).  It is assumed that some HA-redundancy techniques would be
 employed to increase robustness in an aeronautical setting.  It
 should also be understood that the use of RO techniques decreases
 dependence on HAs in the infrastructure and allows a certain level of
 robustness to HA failures in that established sessions using RO may

Eddy, et al. Informational [Page 16] RFC 5522 Aero and Space NEMO RO Requirements October 2009

 be able to operate based on Binding Cache entries even after an HA
 failure.  With RO, an HA failure primarily impacts the ability to
 connect new application flows to a mobile network.
 If a failure occurs in a path selected by an RO technique, then that
 RO technique MUST NOT prevent fallback to the MRHA path for affected
 traffic.
 This does not mention specific redundancy mechanisms for MRs, HAs, or
 other networking elements, so as long as some reasonable method for
 making each component redundant fits within the assumptions of the RO
 mechanism, this requirement can be considered satisfied.
 There is no intention to support "Internet-less" operation through
 this requirement.  When an MR is completely disconnected from the
 majority of the network with which it is intended to communicate,
 including its HA, there is no requirement for it to be able to retain
 any communications involving parties outside the mobile networks
 managed by itself.
 This requirement was derived from ICAO's TC-4 - "The approach should
 have high availability which includes not having a single point of
 failure."

3.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.

3.5.1. Rationale for Aeronautics - Packet Loss

 It is possible that some RO schemes could cause data packets to be
 lost during transitions in RO state or due to unforeseen packet
 filters along the RO-selected path.  This could be difficult for an
 application to detect and respond to in time.  For this reason, an RO
 scheme SHOULD NOT cause packets to be dropped at any point in
 operation, when they would not normally have been dropped in a non-RO
 configuration.
 As an attempt at optimizing against packet loss, some techniques may,
 for some time, duplicate packets sent over both the MRHA tunnel and
 the optimized path.  If this results in duplicate packets being
 delivered to the application, this is also unacceptable.

Eddy, et al. Informational [Page 17] RFC 5522 Aero and Space NEMO RO Requirements October 2009

 This requirement does not necessarily imply make-before-break in
 transitioning between links.  The intention is that during the
 handoff period, the RO scheme itself should not produce losses (or
 duplicates) that would not have occurred if RO had been disabled.
 This requirement was derived from ICAO's TC-5 - "The approach should
 not negatively impact end-to-end data integrity, for example, by
 introducing packet loss during path establishment, handoff, or data
 transfer."
 It is understood that this may be a requirement that is not easily
 implementable with regards to RO.  Furthermore Req1, Separability,
 may be sufficient in allowing loss-sensitive and duplicate-sensitive
 flows to take the MRHA path.

3.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.

3.6.1. Rationale for Aeronautics - Scalability

 Several thousand aircraft may be in operation at some time, each with
 perhaps several hundred MNNs onboard.  The number of active
 spacecraft using IP will be multiple orders of magnitude smaller than
 this over at least the next decade, so the aeronautical needs are
 more stringent in terms of scalability to large numbers of MRs.  It
 would be a non-starter if the combined use of an RO technique by all
 of the MRs in the network caused ground networks provisioned within
 the realm of typical long-haul private telecommunications networks
 (like the FAA's Telecommunications Infrastructure (FTI) or the NASA
 Integrated Services Network (NISN)) to be overloaded or melt-down
 under the RO signaling load or amount of rapid path changes for
 multiple data flows.
 Thus, an RO scheme MUST be simultaneously usable by the MNNs on
 hundreds of thousands of craft without overloading the ground network
 or routing system.  The scheme must also be tolerant to the delay
 and/or loss of initial packets, which may become more pervasive in
 future Internet routing and addressing architectures [17].
 Since at least one traffic domain (PIES) requires connectivity to the
 Internet and it is possible that the Internet would provide transport
 for other domains at some distant point in the future, this
 requirement explicitly forbids the use of techniques that are known
 to scale poorly in terms of their global effects, like BGP, for the

Eddy, et al. Informational [Page 18] RFC 5522 Aero and Space NEMO RO Requirements October 2009

 purposes of RO.  The previous OSI-based ATN system used IDRP and an
 "island" concept for maintaining connectivity to the mobile network
 but was not tested on a large scale deployment.  The Connexion by
 Boeing system used BGP announces and withdrawals as a plane moved
 across the globe in order to maintain connectivity [10].  This was
 found to contribute to a significant amount of churn in the global
 Internet routing tables, which is undesirable for a number of
 reasons, and must be avoided in the future.
 This requirement was derived from ICAO's TC-6 - "The approach should
 be scalable to accommodate anticipated levels of aircraft equipage."
 The specific scaling factor for the number of aircraft used in our
 version of the requirement is an order of magnitude larger than the
 estimated equipage cited in an ICAO draft letter-of-intent to ARIN
 for an IPv6 prefix allocation request.  There were several other
 estimates that different groups had made, and it was felt in the IETF
 that using a larger estimate was more conservative.  It should be
 noted that even with this difference of an order of magnitude, the
 raw number is still several orders of magnitude lower than that of
 estimated cellular telephone users, which might use the same protocol
 enhancements as the cellular industry has also adopted Mobile IP
 standards.

3.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.

3.7.1. Rationale for Aeronautics - Efficient Signaling

 The amount of bandwidth available for aeronautical and space
 communications has historically been quite small in comparison to the
 desired bandwidth (e.g., in the case of VDL links, the bandwidth is 8
 kbps of shared resources).  This situation is expected to persist for
 at least several more years.  Links tend to be provisioned based on
 estimates of application needs (which could well prove wrong if
 either demand or the applications in use themselves do not follow
 expectations) and do not leave much room for additional networking
 protocol overhead.  Since every byte of available air-ground link
 capacity that is used by signaling for NEMO RO is likely to delay
 bytes of application data and reduce application throughput, it is
 important that the NEMO RO scheme's signaling overhead scales up much
 more slowly than the throughput of the flows RO is being performed

Eddy, et al. Informational [Page 19] RFC 5522 Aero and Space NEMO RO Requirements October 2009

 on.  This way, as higher-rate data links are deployed along with more
 bandwidth-hungry applications, the NEMO RO scheme will be able to
 safely be discounted in capacity planning.
 Note that in meeting this requirement, an RO technique must be
 efficient in both the size and number of individual messages that it
 sends, as well in the ensemble of messages sent at one time (for
 instance, to give RO to multiple ongoing flows following a handover),
 in order to prevent storms of packets related to RO.
 This requirement was derived from ICAO's TC-7 - "The approach should
 result in throughput which accommodates anticipated levels of
 aircraft equipage."

3.8. Req8 - Security

 For the ATS/AOS domains, there are three security sub-requirements:
 1.  The RO scheme MUST NOT further expose MNPs on the wireless link
     than already is the case for NEMO basic support.
 2.  The RO scheme MUST permit the receiver of a binding update (BU)
     to validate an MR's ownership of the CoAs claimed by an MR.
 3.  The RO scheme MUST ensure that only explicitly authorized MRs are
     able to perform a binding update for a specific MNP.
 For the PIES domain, there are no additional requirements beyond
 those of normal Internet services and the same requirements for
 normal Mobile IPv6 RO apply.

3.8.1. Rationale for Aeronautics - Security

 The security needs are fairly similar between ATS and AOS, but vary
 widely between the ATS/AOS domains and PIES.  For PIES, the traffic
 flows are typical of terrestrial Internet use and the security
 requirements for RO are identical to those of conventional Mobile
 IPv6 RO.  For ATS/AOS, however, there are somewhat more strict
 requirements, along with some safe assumptions that designers of RO
 schemes can make.  Below, we describe each of these ATS/AOS issues,
 but do not further discuss PIES RO security.
 The first security requirement is driven by concerns expressed by ATS
 communications engineers.  The concern is driven by current air-
 ground links to a craft and their lack of security, which has allowed
 eavesdroppers to track individual flights in detail.  Protecting the
 MNP from exposure has been expressed as a requirement by this
 community, though the security of the RO system should not depend on

Eddy, et al. Informational [Page 20] RFC 5522 Aero and Space NEMO RO Requirements October 2009

 secrecy of the MNP.  The RO scheme should use some reasonable
 security mechanisms in order to both protect RO signaling via strong
 authentication and encrypt the MNP from being visible over air-ground
 links.
 The second security requirement is driven by the risk of flooding
 attacks that are started by an attacker redirecting an MNP's traffic
 to some target victim CoA.  To protect bindings to bogus CoAs from
 being sent, the RO scheme must somehow validate that an MR actually
 possesses any CoAs that it claims.  For the purposes of aeronautics,
 it is safe to assume ingress filtering is in place in the access
 networks.
 To protect against "rogue" MRs or abuse of compromised MRs, the RO
 scheme MUST be capable of checking that an MR is actually authorized
 to perform a binding update for a specific MNP.  To meet this
 requirement, it can be assumed that some aeronautical organization
 authority exists who can provide the required authorization, possibly
 in the form of a certificate that the MR possesses, signed by the
 aeronautical authority.
 It is also reasonable to assume trust relationships between each MR
 and a number of mobility anchor points topologically near to its CNs
 (these anchor points may be owned by the service providers), but it
 is not reasonable to assume that trust relationships can be
 established between an MR and any given CN itself.  Within the
 onboard networks for ATS and AOS, it is reasonable to assume that the
 LFNs and MRs have some trust relationship.
 It is felt by many individuals that by the time the IP-based ATN
 grows into production use, there will be a global ATN-specific Public
 Key Infrastructure (PKI) usable for ATS, though it is agreed that
 such a PKI does not currently exist and will take time to develop
 both technically and politically.  This PKI could permit the
 establishment of trust relationships among any pair of ATS MNNs, MRs,
 or CNs through certificate paths, in contrast to the more limited
 amount of trust relationships described in the previous paragraph.
 While it has been suggested that early test and demonstration
 deployments with a more limited-scale PKI deployment can be used in
 the near-term, as a global PKI is developed, some parties still feel
 that assuming a global PKI may be overly bold in comparison to
 assuming trust relationships with anchor points.  It is always
 possible to scale the anchor point assumption up if a PKI develops
 that allows the CNs themselves to become the anchor points.  It is
 not possible to go back down in the other direction if a global PKI
 never emerges.

Eddy, et al. Informational [Page 21] RFC 5522 Aero and Space NEMO RO Requirements October 2009

 This requirement was extrapolated from ICAO's TC-8 - "The approach
 should be secure" and made more specific with help from the MEXT
 working group.

3.9. Req9 - Adaptability

 Applications using new transport protocols, IPsec, or new IP options
 MUST be possible within an RO scheme.

3.9.1. Rationale for Aeronautics - Adaptability

 The concepts of operations are not fully developed for network-
 centric command and control and other uses of IP-based networks in
 aeronautical and space environments.  The exact application
 protocols, data flow characteristics, and even transport protocols
 that will be used in either transitional or final operational
 concepts are not completely defined yet, and may even change with
 deployment experience.  The RO solution itself should allow all
 higher-layer protocols, ports, and options to be used.
 This requirement was derived from ICAO's TC-9 - "The approach should
 be scalable to accommodate anticipated transition to new IP-based
 communication protocols."

4. Desirable Characteristics

 In this section, we identify some of the properties of the system
 that are not strict requirements due to either being difficult to
 quantify or to being features that are not immediately needed, but
 that may provide additional benefits that would help encourage
 adoption.

4.1. Des1 - Configuration

 For ATS systems, complex configurations are known to increase
 uncertainty in context, human error, and the potential for reaching
 undesirable (unsafe) states [18].  Since RO alters the communications
 context between an MNN and CN, it is desirable that a NEMO RO
 solution be as simple to configure as possible and also easy to
 automatically disable if an undesirable state is reached.
 For CNs at large airports, the Binding Cache state management
 functions may be simultaneously dealing with hundreds of airplanes
 with multiple service providers and a volume of mobility events due
 to arrivals and departures.  The ability to have simple interfaces
 for humans to access the Binding Cache configuration and alter it in
 case of errors is desirable, if this does not interfere with the RO
 protocol mechanisms themselves.

Eddy, et al. Informational [Page 22] RFC 5522 Aero and Space NEMO RO Requirements October 2009

4.2. Des2 - Nesting

 It is desirable if the RO mechanism supports RO for nested MRs, since
 it is possible that, for PIES and astronaut spacesuits, PANs with MRs
 will need to be supported.  For oceanic flight, ATS and AOS may also
 benefit from the capability of nesting MRs between multiple planes to
 provide a "reachback" to terrestrial ground stations rather than
 relying solely on lower rate HF or satellite systems.  In either
 case, this mode of operation is beyond current strict requirements
 and is merely desirable.  It is also noted that there are other ways
 to support these communications scenarios using routing protocols or
 other means outside of NEMO.
 Loop-detection, in support of nesting, is specifically not a
 requirement at this stage of ATN and space network designs, due to
 both the expectation that the operational environments are carefully
 controlled and inherently avoid loops and the understanding that
 scenarios involving nesting are not envisioned in the near future.

4.3. Des3 - System Impact

 Low complexity in systems engineering and configuration management is
 desirable in building and maintaining systems using the RO mechanism.
 This property may be difficult to quantify, judge, and compare
 between different RO techniques, but a mechanism that is perceived to
 have lower impact on the complexity of the network communications
 system should be favored over an otherwise equivalent mechanism (with
 regards to the requirements listed above).  This is somewhat
 different than Des1 (Configuration), in that Des1 refers to operation
 and maintenance of the system once deployed, whereas Des3 is
 concerned with the initial design, deployment, transition, and later
 upgrade path of the system.

4.4. Des4 - VMN Support

 At least LFNs MUST be supported by a viable RO solution for
 aeronautics, as these local nodes are within the ATS and AOS domains.
 If Mobile IPv6 becomes a popular technology used by portable consumer
 devices, VMNs within the PIES domain are expected to be numerous, and
 it is strongly desirable for them to be supported by the RO
 technique, but not strictly required.  LMNs are potentially present
 in future space exploration scenarios, such as manned exploration
 missions to the moon and Mars.

Eddy, et al. Informational [Page 23] RFC 5522 Aero and Space NEMO RO Requirements October 2009

4.5. Des5 - Generality

 An RO mechanism that is "general purpose", in that it is also readily
 usable in other contexts outside of aeronautics and space
 exploration, is desirable.  For instance, an RO solution that is
 usable within Vehicular ad hoc Networks (VANETs) [19] or consumer
 electronics equipment [20] could satisfy this.  The goal is for the
 technology to be more widely used and maintained outside the
 relatively small aeronautical networking community and its vendors,
 in order to make acquisitions and training faster, easier, and
 cheaper.  This could also allow aeronautical networking to possibly
 benefit from future RO scheme optimizations and developments whose
 research and development is funded and performed externally by the
 broader industry and academic communities.

5. Security Considerations

 This document does not create any security concerns in and of itself.
 The security properties of any NEMO RO scheme that is to be used in
 aeronautics and space exploration are probably much more stringent
 than for more general NEMO use, due to the safety-of-life and/or
 national security issues involved.  The required security properties
 are described under Req8 of Section 3 within this document.
 Under an assumption of closed and secure backbone networks, the air-
 ground link is the weakest portion of the network and most
 susceptible to injection of packets, flooding, and other attacks.
 Future air-ground data links that will use IP are being developed
 with link-layer security as a concern.  This development can assist
 in meeting one of this document's listed security requirements (that
 MNPs not be exposed on the wireless link), but the other requirements
 affect the RO technology more directly without regard to the presence
 or absence of air-ground link-layer security.
 When deploying in operational networks where network-layer security
 may be mandated (e.g., virtual private networks), the interaction
 between this and NEMO RO techniques should be carefully considered to
 ensure that the security mechanisms do not undo the route
 optimization by forcing packets through a less optimal overlay or
 underlay.  For instance, when IPsec tunnel use is required, the
 locations of the tunnel endpoints can force sub-optimal end-to-end
 paths to be taken.

6. Acknowledgments

 Input from several parties is indirectly included in this document.
 Participants in the Mobile Platform Internet (MPI) mailing list and
 BoF efforts helped to shape the document, and the early content was

Eddy, et al. Informational [Page 24] RFC 5522 Aero and Space NEMO RO Requirements October 2009

 borrowed from MPI problem statement and proposed requirements
 documents ([21], [13]).  The NEMO and MONAMI6 working group
 participants were instrumental in completing this document.  The
 participants in the MEXT interim meeting February 7th and 8th of 2008
 in Madrid were critical in solidifying these requirements.  Specific
 suggestions from Steve Bretmersky, Thierry Ernst, Tony Li, Jari
 Arkko, Phillip Watson, Roberto Baldessari, Carlos Jesus Bernardos
 Cano, Eivan Cerasi, Marcelo Bagnulo, Serkan Ayaz, Christian Bauer,
 Fred Templin, Alexandru Petrescu, Tom Henderson, and Tony Whyman were
 incorporated into this document.
 Wesley Eddy's work on this document was performed at NASA's Glenn
 Research Center, primarily in support of NASA's Advanced
 Communications Navigations and Surveillance Architectures and System
 Technologies (ACAST) project, and the NASA Space Communications
 Architecture Working Group (SCAWG) in 2005 and 2006.

7. References

7.1. Normative References

 [1]   Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
       "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
       January 2005.
 [2]   Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
       IPv6", RFC 3775, June 2004.
 [3]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.

7.2. Informative References

 [4]   Ernst, T. and H-Y. Lach, "Network Mobility Support
       Terminology", RFC 4885, July 2007.
 [5]   Ernst, T., "Network Mobility Support Goals and Requirements",
       RFC 4886, July 2007.
 [6]   Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility
       Route Optimization Problem Statement", RFC 4888, July 2007.
 [7]   ICAO Asia/Pacific Regional Office, "Required Communication
       Performance (RCP) Concepts - An Introduction", Informal South
       Pacific ATS Coordinating Group 20th meeting, Agenda Item 7,
       January 2006.

Eddy, et al. Informational [Page 25] RFC 5522 Aero and Space NEMO RO Requirements October 2009

 [8]   Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility
       Route Optimization Solution Space Analysis", RFC 4889,
       July 2007.
 [9]   Kempf, J., "Goals for Network-Based Localized Mobility
       Management (NETLMM)", RFC 4831, April 2007.
 [10]  Dul, A., "Global IP Network Mobility", Presentation at IETF
       62 Plenary, March 2005.
 [11]  Ivancic, W., Paulsen, P., Stewart, D., Shell, D., Wood, L.,
       Jackson, C., Hodgson, D., Northam, J., Bean, N., Miller, E.,
       Graves, M., and L. Kurisaki, "Secure, Network-centric
       Operations of a Space-based Asset: Cisco Router in Low Earth
       Orbit (CLEO) and Virtual Mission Operations Center (VMOC)",
       NASA Technical Memorandum TM-2005-213556, May 2005.
 [12]  Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of
       Multihoming in Network Mobility Support", RFC 4980,
       October 2007.
 [13]  Davis, T., "Mobile Internet Platform Aviation Requirements",
       Work in Progress, September 2006.
 [14]  ICAO WG-N SWG1, "Analysis of Candidate ATN IPS Mobility
       Solutions", Meeting #12, Working Paper 6, Bangkok, Thailand,
       January 2007.
 [15]  Davis, T., "Aviation Global Internet Operations Requirements",
       ICAO WG-N, Sub-Working-Group N1, Information Paper #4 (IP4),
       September 2006.
 [16]  Wakikawa, R., "Home Agent Reliability Protocol", Work
       in Progress, July 2009.
 [17]  Zhang, L. and S. Brim, "A Taxonomy for New Routing and
       Addressing Architecture Designs", Work in Progress, March 2008.
 [18]  ICAO, "Threat and Error Management (TEM) in Air Traffic
       Control", ICAO Preliminary Edition, October 2005.
 [19]  Baldessari, R., "C2C-C Consortium Requirements for NEMO Route
       Optimization", Work in Progress, July 2007.
 [20]  Ng, C., "Consumer Electronics Requirements for Network Mobility
       Route Optimization", Work in Progress, February 2008.

Eddy, et al. Informational [Page 26] RFC 5522 Aero and Space NEMO RO Requirements October 2009

 [21]  Ivancic, W., "Multi-Domained, Multi-Homed Mobile Networks",
       Work in Progress, September 2006.
 [22]  CCSDS, "Cislunar Space Internetworking: Architecture", CCCSDS
       000.0-G-1 Draft Green Book, December 2006.
 [23]  NASA Space Communication Architecture Working Group, "NASA
       Space Communication and Navigation Architecture Recommendations
       for 2005-2030", SCAWG Final Report, May 2006.

Eddy, et al. Informational [Page 27] RFC 5522 Aero and Space NEMO RO Requirements October 2009

Appendix A. Basics of IP-Based Aeronautical Networking

 The current standards for aeronautical networking are based on the
 ISO OSI networking stack and are referred to as the Aeronautical
 Telecommunications Network (ATN).  While standardized, the ATN has
 not been fully deployed and seems to be in only limited use compared
 to its full vision and potential.  The International Civil Aviation
 Organization (ICAO) is a part of the United Nations that produces
 standards for aeronautical communications.  The ICAO has recognized
 that an ATN based on OSI lacks the widespread commercial network
 support required for the successful deployment of new, more
 bandwidth-intensive ATN applications, and has recently been working
 towards a new IPv6-based version of the ATN.
 Supporting mobility in an IP-based network may be vastly different
 than it is in the OSI-based ATN, which uses the Inter-Domain Routing
 Protocol (IDRP) to recompute routing tables as mobile networks change
 topological points of attachment.  ICAO recognizes this and has
 studied various mobility techniques based on link, network,
 transport, routing, and application protocols [14].
 Work done within ICAO has identified the NEMO technology as a
 promising candidate for use in supporting global, IP-based mobile
 networking.  The main concerns with NEMO have been with its current
 lack of route optimization support and its potentially complex
 configuration requirements in a large airport environment with
 multiple service providers and 25 or more airlines sharing the same
 infrastructure.
 A significant challenge to the deployment of networking technologies
 to aeronautical users is the low capability of existing air-ground
 data links for carrying IP-based (or other) network traffic.  Due to
 barriers of spectrum and certification, production of new standards
 and equipment for the lower layers below IP is slow.  Currently
 operating technologies may have data rates measured in the several
 kbps range, and it is clear that supporting advanced IP-based
 applications will require new link technologies to be developed
 simultaneously with the development of networking technologies
 appropriate for aeronautics.
 In addition to well-known commercial data links that can be adapted
 for aeronautical use, such as Wideband Code-Division Multiple Access
 (WCDMA) standards or the IEEE 802.16 standard, several more
 specialized technologies either exist or have been proposed for air-
 ground use:

Eddy, et al. Informational [Page 28] RFC 5522 Aero and Space NEMO RO Requirements October 2009

 o  VHF Data Link (VDL) specifies four modes of operation in the
    117.975 - 137 MHz range that are capable of supporting different
    mixes of digital voice and data at fairly low rates.  The low
    rates are driven by the need to operate within 25 kHz channels
    internationally allocated for aeronautical use.  VDL mode 2 is
    somewhat widely deployed on aircraft and two global service
    providers support VDL access networks.  Experiences with VDL mode
    2 indicate that several kbps of capacity delivered to a craft can
    be expected in practice, and the use of long timers and a
    collision avoidance algorithm over a large physical space
    (designed to operate at 200 nautical miles) limit the performance
    of IP-based transport protocols and applications.
 o  Aircraft Communications and Reporting System (ACARS) is a
    messaging system that can be used over several types of underlying
    RF data links (e.g., VHF, HF, and satellite relay).  ACARS
    messaging automates the sending and processing of several types of
    event notifications over the course of a flight.  ACARS in general
    is a higher-level messaging system, whereas the more specific
    "Plain Old ACARS" (POA) refers to a particular legacy RF interface
    that the ACARS system employed prior to the adoption of VDL and
    other data links.  Support for IP-based networking and advanced
    applications over POA is not feasible.
 o  Broadband Aeronautical Multi-carrier Communications (B-AMC) is a
    hybrid cellular system that uses multi-carrier CDMA from ground-
    to-air and Orthogonal Frequency Division Multiplexing (OFDM) in
    the air-to-ground direction.  B-AMC runs in the L-band of spectrum
    and is adapted from the Broadband-VHF (B-VHF) technology
    originally developed to operate in the VHF spectrum.  L-band use
    is intended to occupy the space formerly allocated for Distance
    Measuring Equipment (DME) using channels with greater bandwidth
    than are available than in the VHF band, where analog voice use
    will continue to be supported.  B-AMC may permit substantially
    higher data rates than existing deployed air-ground links.
 o  All-Purpose Multi-Channel Aviation Communications System (AMACS)
    is an adaptation of the Global System for Mobile Communications
    (GSM) physical layer to operate in the L-band with 50 - 400 kHz
    channels and use VDL mode 4's media access technique.  AMACS may
    permit data rates in the several hundred kbps range, depending on
    specific channelization policies deployed.
 o  Project 34 (P34) is a wideband public-safety radio system capable
    of being used in the L-band.  P34 is designed to offer several
    hundred kbps of capacity specifically for IP-based packet
    networking.  It uses OFDM in 50, 100, or 150 kHz channels and

Eddy, et al. Informational [Page 29] RFC 5522 Aero and Space NEMO RO Requirements October 2009

    exact performance will depend on the particular operating band,
    range (guard time), and channelization plan configured in
    deployment.
 o  L-Band Data Link (LDL) is another proposal using the L-band based
    on existing technologies.  LDL adapts the VDL mode 3 access
    technique and is expected to be capable of up to 100 kbps.

Appendix B. Basics of IP-based Space Networking

 IP itself is only in limited operational use for communicating with
 spacecraft currently (e.g., the Surry Satellite Technology Limited
 (SSTL) Disaster Monitoring Constellation (DMC) satellites).  Future
 communications architectures include IP-based networking as an
 essential building block, however.  The Consultative Committee for
 Space Data Systems (CCSDS) has a working group that is producing a
 network architecture for using IP-based communications in both manned
 and unmanned near-Earth missions, and has international participation
 towards this goal [22].  NASA's Space Communications Architecture
 Working Group (SCAWG) also has developed an IP-based multi-mission
 networking architecture [23].  Neither of these is explicitly based
 on Mobile IP technologies, but NEMO is usable within these
 architectures and they may be extended to include NEMO when/if the
 need becomes apparent.

Eddy, et al. Informational [Page 30] RFC 5522 Aero and Space NEMO RO Requirements October 2009

Authors' Addresses

 Wesley M. Eddy
 Verizon Federal Network Systems
 NASA Glenn Research Center
 21000 Brookpark Road, MS 54-5
 Cleveland, OH  44135
 USA
 EMail: weddy@grc.nasa.gov
 Will Ivancic
 NASA Glenn Research Center
 21000 Brookpark Road, MS 54-5
 Cleveland, OH  44135
 USA
 Phone: +1-216-433-3494
 EMail: William.D.Ivancic@grc.nasa.gov
 Terry Davis
 Boeing Commercial Airplanes
 P.O.Box 3707  MC 0Y-96
 Seattle, WA  98124-2207
 USA
 Phone: 206-280-3715
 EMail: Terry.L.Davis@boeing.com

Eddy, et al. Informational [Page 31]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5522.txt · Last modified: 2009/10/08 00:03 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki