diff options
Diffstat (limited to 'doc/rfc/rfc5522.txt')
| -rw-r--r-- | doc/rfc/rfc5522.txt | 1739 |
1 files changed, 1739 insertions, 0 deletions
diff --git a/doc/rfc/rfc5522.txt b/doc/rfc/rfc5522.txt new file mode 100644 index 0000000..e3767ff --- /dev/null +++ b/doc/rfc/rfc5522.txt @@ -0,0 +1,1739 @@ + + + + + + +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] + |