MEXT Working Group W. Eddy Internet-Draft Verizon Intended status: Informational W. Ivancic Expires: August 28, 2008 NASA T. Davis Boeing February 25, 2008 NEMO Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks draft-ietf-mext-aero-reqs-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 28, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document describes the requirements and desired properties of NEMO Route Optimization techniques for use in global networked communications systems for aeronautics and space exploration. Eddy, et al. Expires August 28, 2008 [Page 1] Internet-Draft Aero and Space NEMO RO Requirements February 2008 This version has been reviewed by members of the International Civil Aviation Orgnanization (ICAO) and other aeronautical communications standards bodies, and contributed to by a number of aeronautical communications experts outside the normal IETF process. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. NEMO RO Scenarios . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Aeronautical Communications Scenarios . . . . . . . . . . 5 2.2. Space Exploration Scenarios . . . . . . . . . . . . . . . 9 3. Required Characteristics . . . . . . . . . . . . . . . . . . . 11 3.1. Req1 - Separability . . . . . . . . . . . . . . . . . . . 12 3.2. Req2 - Multihoming . . . . . . . . . . . . . . . . . . . . 12 3.3. Req3 - Latency . . . . . . . . . . . . . . . . . . . . . . 13 3.4. Req4 - Availability . . . . . . . . . . . . . . . . . . . 14 3.5. Req5 - Packet Loss . . . . . . . . . . . . . . . . . . . . 15 3.6. Req6 - Scalability . . . . . . . . . . . . . . . . . . . . 16 3.7. Req7 - Efficient Signaling . . . . . . . . . . . . . . . . 16 3.8. Req8 - Security . . . . . . . . . . . . . . . . . . . . . 17 3.9. Req9 - Adaptability . . . . . . . . . . . . . . . . . . . 18 4. Desirable Characteristics . . . . . . . . . . . . . . . . . . 19 4.1. Des1 - Configuration . . . . . . . . . . . . . . . . . . . 19 4.2. Des2 - Nesting . . . . . . . . . . . . . . . . . . . . . . 20 4.3. Des3 - System Impact . . . . . . . . . . . . . . . . . . . 20 4.4. Des4 - VMN Support . . . . . . . . . . . . . . . . . . . . 20 4.5. Des5 - Generality . . . . . . . . . . . . . . . . . . . . 21 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 8. Changes from draft-eddy-nemo-aero-reqs-02 . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . . 23 Appendix A. Basics of IP-based Aeronautical Networking . . . . . 24 Appendix B. Basics of IP-based Space Networking . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 27 Eddy, et al. Expires August 28, 2008 [Page 2] Internet-Draft Aero and Space NEMO RO Requirements February 2008 1. Introduction As background the NEMO terminology and NEMO goals and requirements documents are suggested reading [4] [5]. The drafts produced as part of the Mobile Platform Internet (MPI) effort are also of relevence, and some of the material in this document is borrowed from the MPI drafts [6] [7]. The base NEMO standard [1] allows Mobile IPv6 [2] to be used by mobile routers, although NEMO does not support Mobile IPv6's Route Optimization (RO) features. 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 Mobile Router (MR) and a NEMO Home Agent (HA) placed at some relatively stable point in the network. Corresponding Nodes (CNs) that communicate with Mobile Network Nodes (MNNs) behind an MR do so through the HA and MRHA tunnel in both directions. Since the use of this tunnel may have significant drawbacks [8], 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 onboard 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 often must 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 Eddy, et al. Expires August 28, 2008 [Page 3] Internet-Draft Aero and Space NEMO RO Requirements February 2008 primary goal of pursuing NEMO RO for aeronautics. Many other properties of the aeronautics and space environments amplify the known issues with NEMO bidirectional MRHA tunnels [8] 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 ARQ mechanisms and underprovisioned radio links. Furthermore, for aeronautical communications systems that pass through geosynchronous satellites, and for space exploration, 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 means 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 [9]. 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 - Packet fragmentation exacerbates the issue with header overhead and adds to unreliability and possibly the need for end-to-end retransmission if fragments are lost. Since error-prone radio links are sometimes used in the aeronautical and space environments, loss of fragments resulting in loss of entire packets is possible. The odds of packets requiring fragmentation must be minimized in aeronautical and space networks. 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 Eddy, et al. Expires August 28, 2008 [Page 4] Internet-Draft Aero and Space NEMO RO Requirements February 2008 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 relevent 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 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, in this section some operational characteristics are described 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 [10] 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. the Gatelink system) 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 Eddy, et al. Expires August 28, 2008 [Page 5] Internet-Draft Aero and Space NEMO RO Requirements February 2008 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. [11]) 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 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. 2.1.1. Air Traffic Services Domain The MNNs involved in Air Traffic Services (ATS) consist of pieces of avoinics hardware onboard an aircraft 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 multi-homed MR that is at least multi-interfaced and possibly multi-prefixed as well, in NEMO terminology. Since for ATS, the MRs and MNNs are under regulatory control and are actively tested and maintained, it is not unreasonable to assume that special patches or software be running on these devices to enable NEMO RO. In fact, since these devices are accessed by skilled technicians and professionals, it may be acceptable even if complex configuration is required for NEMO RO. Of course simplicity in setup and configuration is desirable, however. 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 Eddy, et al. Expires August 28, 2008 [Page 6] Internet-Draft Aero and Space NEMO RO Requirements February 2008 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 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 all share the same network prefix. 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. 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 Gatelink system), "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 Eddy, et al. Expires August 28, 2008 [Page 7] Internet-Draft Aero and Space NEMO RO Requirements February 2008 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 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 under the desirable properties in Section 4. 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 onboard 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. A small number of PIES MNNs may be LFNs that store and distribute cached media content (e.g. movies and music), or 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 are available on the ground, or via 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 ATC, however, so they are not specifically considered here. Eddy, et al. Expires August 28, 2008 [Page 8] Internet-Draft Aero and Space NEMO RO Requirements February 2008 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 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 relatatively little regulations and beaurocracy are involved in deploying new technology in this domain, and IP-based PIES systems have previously been developed and deployed (although not using NEMO) [12]. 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 relevent to selecting an appropriate NEMO RO mechanism. It should be noted that IPv4-based mobile routing has been demonstrated onboard 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 [13]. 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 relevent 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 Eddy, et al. Expires August 28, 2008 [Page 9] Internet-Draft Aero and Space NEMO RO Requirements February 2008 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 onboard 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 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 on-line 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 TDRSS. This conforms to the (n,1,1) or (n,n,1) NEMO multihoming scenarios [14]. 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 [14]. 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, but an MR is more desirable because it could be part of a modular communications adapter that is used in multiple diverse missions to bridge on-board buses and intelligently manage space links, rather 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. Eddy, et al. Expires August 28, 2008 [Page 10] Internet-Draft Aero and Space NEMO RO Requirements February 2008 The MRs and MNNs onboard 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 astonauts move between two docked spacecraft, each craft may have its own local MR and wireless coverage that the suit MNNs will have to reconfigure for. It is desirable if a 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 onboard, or might 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 Civial Aviation Organization (ICAO) to identify viable mobility technologies for providing IP services to aircraft, a set of technical criteria was developed [7] [15]. 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 Eddy, et al. Expires August 28, 2008 [Page 11] Internet-Draft Aero and Space NEMO RO Requirements February 2008 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. 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. 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 perform 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 is decided on a per-domain basis, so that it is possible that for some domains, separate MRs are used, or even non-NEMO mobility techniques. This requirement for an RO policy database only applies to domains that utilize NEMO. This requirement was derived from ICAO's TC-1 - "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." 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. Eddy, et al. Expires August 28, 2008 [Page 12] Internet-Draft Aero and Space NEMO RO Requirements February 2008 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 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 onboard may actually be restricted in what data links they are allowed to use based on regulations and policy, so 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 [14], 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 setup 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 Eddy, et al. Expires August 28, 2008 [Page 13] Internet-Draft Aero and Space NEMO RO Requirements February 2008 been blocked for some period of time while link-layer and NEMO proceedures 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 setup 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 setup 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 fall-back to the MRHA tunnel if an element in an optimized path fails. An RO mechanism MUST NOT add any new single point of failure for 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 MR onboard, 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. 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 Eddy, et al. Expires August 28, 2008 [Page 14] Internet-Draft Aero and Space NEMO RO Requirements February 2008 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 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 MUST 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. 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 unforseen 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 MUST 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 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. Eddy, et al. Expires August 28, 2008 [Page 15] Internet-Draft Aero and Space NEMO RO Requirements February 2008 3.6. Req6 - Scalability An RO scheme MUST be simultaneously usable by ten thousand 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 NASA's 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 ten thousand nodes without overloading the ground network or routing system. 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. This requirement was derived from ICAO's TC-6 - "The approach should be scaleable to accomodate anticipated levels of aircraft equipage." 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 Eddy, et al. Expires August 28, 2008 [Page 16] Internet-Draft Aero and Space NEMO RO Requirements February 2008 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 on. This way as higher-rate datalinks 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 as 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: * The RO scheme MUST NOT further expose MNPs on the wireless link than already is the case for NEMO basic support. * The RO scheme MUST permit the receiver of a BU to validate the CoAs claimed by an MR. * 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 Aeronatics - 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, Eddy, et al. Expires August 28, 2008 [Page 17] Internet-Draft Aero and Space NEMO RO Requirements February 2008 but do not further discuss PIES RO security. The first security requirement is driven by concerns expressed by ATS communications engineers. The concern is with the air-ground links to a craft, and their current lack of security. If an RO scheme exposes the MNP to eavesdroppers on these links, it may enable attackers to easily send packets towards onboard networks of crafts. The RO scheme should use some reasonable form of encryption (e.g. standard ESP transforms) in order to protect any new RO signalling data that contains the MNP. 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. In typical Mobile IPv6 RO, the return routability test provides a form of validation, under certain assumptions. For the purposes of aeronautics, when designing a technique for an MR to demonstrate ownership of some CoA, it is safe to assume ingress filtering on the part of the access network providers, in conjunction with the ability to correlate a BU's source address and the decrypted alternate CoA at the end recipient of the BU. (Note: this is particularly subject to MEXT discussion) To protect against "rouge" 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 relationshiops 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. 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. Eddy, et al. Expires August 28, 2008 [Page 18] Internet-Draft Aero and Space NEMO RO Requirements February 2008 3.9.1. Rationale for Aeronatics - 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 and final operational concepts are not completely defined yet, and may even change with deployment experience. If the RO solution assumes that some amount of preconfiguration of flow properties (port number ranges, etc.) is required, this could make the integration of new applications or protocols difficult. An RO scheme might assume this in order to classify between flows that prefer the MRHA tunnel to an optimized path per requirement Req1, for instance, among other reasons. Since flag days or other such large-scale synchronized configuration updates are to be avoided to ensure high availability, the RO scheme MUST NOT fail on the use of unexpected higher layer protocols (transport and above). Specifically, the use of IPsec by applications MUST be possible. Security based on IPsec is widely understood and modules qualified for use in aeronautical and space exploration environments are currently available off-the-shelf due to the US Department of Defense HAIPE work. Other security frameworks may not be as attractive due to a lack of familiarity or available flight-qualified systems. If an RO solution precludes the use of IPsec by applications, this would make it undesirable or unusable. This drives the requirement that new applications, potentially using new transport protocols must be usable within an RO scheme, and MUST NOT involve global reconfiguration events for MRs. This requirement was derived from ICAO's TC-9 - "The approach should be scalable to accomodate 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 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 undesirable Eddy, et al. Expires August 28, 2008 [Page 19] Internet-Draft Aero and Space NEMO RO Requirements February 2008 (unsafe) states to be reached [16]. 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 are desirable, if this does not interfere with the RO protocol mechanisms themselves. 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, that 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 groundstations 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. 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 Eddy, et al. Expires August 28, 2008 [Page 20] Internet-Draft Aero and Space NEMO RO Requirements February 2008 in future space exploration scenarios, such as Moon and Mars manned exploration missions. 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, a RO solution that is usable within VANETs [17] or consumer electronics equipment [18] 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 suseceptible 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. Eddy, et al. Expires August 28, 2008 [Page 21] Internet-Draft Aero and Space NEMO RO Requirements February 2008 6. IANA Considerations This document neither creates nor updates any IANA registries. 7. Acknowledgments Input from several parties is indirectly included in this document. Participants in the MPI mailing list and BoF efforts helped to shape the document. 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, and Christian Bauer were incorporated into this document. Wesley Eddy's work on this document was performed at NASA's Glenn Research Center, while 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). 8. Changes from draft-eddy-nemo-aero-reqs-02 Note, this section will be removed upon publication as an RFC. At the IETF70 mext the aeronautics community indicated we would change the nemo-aero-req-02 document into a mext document with little modification. This the the corresponding document. Any Undefined Acronyms have been defined during first use. 9. References 9.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 Eddy, et al. Expires August 28, 2008 [Page 22] Internet-Draft Aero and Space NEMO RO Requirements February 2008 Levels", BCP 14, RFC 2119, March 1997. 9.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] Ivancic, W., "Multi-Domained, Multi-Homed Mobile Networks", draft-ivancic-mobile-platforms-problem-00 (work in progress), September 2006. [7] Davis, T., "Mobile Internet Platform Aviation Requirements", draft-davis-mip-aviationreq-00 (work in progress), September 2006. [8] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility Route Optimization Problem Statement", RFC 4888, July 2007. [9] 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. [10] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility Route Optimization Solution Space Analysis", RFC 4889, July 2007. [11] Kempf, J., "Goals for Network-Based Localized Mobility Management (NETLMM)", RFC 4831, April 2007. [12] Dul, A., "Global IP Network Mobility", presentation at IETF 62 plenary , March 2005. [13] 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. [14] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of Multihoming in Network Mobility Support", RFC 4980, October 2007. [15] ICAO WG-N SWG1, "Analysis of Candidate ATN IPS Mobility Eddy, et al. Expires August 28, 2008 [Page 23] Internet-Draft Aero and Space NEMO RO Requirements February 2008 Solutions", Meeting #12, Working Paper 6, Bangkok, Thailand, January 2007. [16] ICAO, "Threat and Error Management (TEM) in Air Traffic Control", ICAO Preliminary Edition, October 2005. [17] Baldessari, R., "C2C-C Consortium Requirements for NEMO Route Optimization", draft-baldessari-c2ccc-nemo-req-01 (work in progress), July 2007. [18] Ng, C., "Consumer Electronics Requirements for Network Mobility Route Optimization", draft-ng-nemo-ce-req-00 (work in progress), July 2007. [19] CCSDS, "Cislunar Space Internetworking: Architecture", CCCSDS 000.0-G-1 Draft Green Book, December 2006. [20] NASA Space Communication Architecture Working Group, "NASA Space Communication and Navigation Architecture Recommendations for 2005-2030", SCAWG Final Report, May 2006. 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 IP-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 [15]. 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 Eddy, et al. Expires August 28, 2008 [Page 24] Internet-Draft Aero and Space NEMO RO Requirements February 2008 multiple service providers and 25 or more airlines sharing the same infrastructure. 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 are one example). 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 [19]. NASA's Space Communications Architecture Working Group (SCAWG) also has developed an IP-based multi-mission networking architecture [20]. 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. 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 Eddy, et al. Expires August 28, 2008 [Page 25] Internet-Draft Aero and Space NEMO RO Requirements February 2008 Terry Davis Boeing Commercial Airplanes P.O.Box 3707 MC 07-25 Seattle, WA 98124-2207 USA Phone: 206-280-3715 Email: Terry.L.Davis@boeing.com Eddy, et al. Expires August 28, 2008 [Page 26] Internet-Draft Aero and Space NEMO RO Requirements February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Eddy, et al. Expires August 28, 2008 [Page 27]