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
AbstractThis 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.
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 4], ). The base NEMO standard  extends Mobile IPv6  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
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 , 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  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
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 . 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  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.
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 . 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. 8] are feasible. 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.
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
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.
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.
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.
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) . 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. 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
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 . 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 . 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
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. 13], ). 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.
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.
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).
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 , 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."
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." 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
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."
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. 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
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 . 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.
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."
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.
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. 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.
19] or consumer electronics equipment  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. 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.
borrowed from MPI problem statement and proposed requirements documents (, ). 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.  Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007.  Ernst, T., "Network Mobility Support Goals and Requirements", RFC 4886, July 2007.  Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility Route Optimization Problem Statement", RFC 4888, July 2007.  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.
 Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility Route Optimization Solution Space Analysis", RFC 4889, July 2007.  Kempf, J., "Goals for Network-Based Localized Mobility Management (NETLMM)", RFC 4831, April 2007.  Dul, A., "Global IP Network Mobility", Presentation at IETF 62 Plenary, March 2005.  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.  Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of Multihoming in Network Mobility Support", RFC 4980, October 2007.  Davis, T., "Mobile Internet Platform Aviation Requirements", Work in Progress, September 2006.  ICAO WG-N SWG1, "Analysis of Candidate ATN IPS Mobility Solutions", Meeting #12, Working Paper 6, Bangkok, Thailand, January 2007.  Davis, T., "Aviation Global Internet Operations Requirements", ICAO WG-N, Sub-Working-Group N1, Information Paper #4 (IP4), September 2006.  Wakikawa, R., "Home Agent Reliability Protocol", Work in Progress, July 2009.  Zhang, L. and S. Brim, "A Taxonomy for New Routing and Addressing Architecture Designs", Work in Progress, March 2008.  ICAO, "Threat and Error Management (TEM) in Air Traffic Control", ICAO Preliminary Edition, October 2005.  Baldessari, R., "C2C-C Consortium Requirements for NEMO Route Optimization", Work in Progress, July 2007.  Ng, C., "Consumer Electronics Requirements for Network Mobility Route Optimization", Work in Progress, February 2008.
 Ivancic, W., "Multi-Domained, Multi-Homed Mobile Networks", Work in Progress, September 2006.  CCSDS, "Cislunar Space Internetworking: Architecture", CCCSDS 000.0-G-1 Draft Green Book, December 2006.  NASA Space Communication Architecture Working Group, "NASA Space Communication and Navigation Architecture Recommendations for 2005-2030", SCAWG Final Report, May 2006.
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:
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
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. 22]. NASA's Space Communications Architecture Working Group (SCAWG) also has developed an IP-based multi-mission networking architecture . 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.