idnits 2.17.1 draft-ietf-mext-aero-reqs-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1195. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1206. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1213. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1219. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 25, 2008) is 5905 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '3' is defined on line 1037, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) -- No information found for draft-davis-mip-aviationreq - is the name correct? == Outdated reference: A later version (-02) exists of draft-ng-nemo-ce-req-00 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEXT Working Group W. Eddy 3 Internet-Draft Verizon 4 Intended status: Informational W. Ivancic 5 Expires: August 28, 2008 NASA 6 T. Davis 7 Boeing 8 February 25, 2008 10 NEMO Route Optimization Requirements for Operational Use in Aeronautics 11 and Space Exploration Mobile Networks 12 draft-ietf-mext-aero-reqs-01 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 28, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 This document describes the requirements and desired properties of 46 NEMO Route Optimization techniques for use in global networked 47 communications systems for aeronautics and space exploration. 49 This version has been reviewed by members of the International Civil 50 Aviation Orgnanization (ICAO) and other aeronautical communications 51 standards bodies, and contributed to by a number of aeronautical 52 communications experts outside the normal IETF process. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. NEMO RO Scenarios . . . . . . . . . . . . . . . . . . . . . . 5 58 2.1. Aeronautical Communications Scenarios . . . . . . . . . . 5 59 2.2. Space Exploration Scenarios . . . . . . . . . . . . . . . 9 60 3. Required Characteristics . . . . . . . . . . . . . . . . . . . 11 61 3.1. Req1 - Separability . . . . . . . . . . . . . . . . . . . 12 62 3.2. Req2 - Multihoming . . . . . . . . . . . . . . . . . . . . 12 63 3.3. Req3 - Latency . . . . . . . . . . . . . . . . . . . . . . 13 64 3.4. Req4 - Availability . . . . . . . . . . . . . . . . . . . 14 65 3.5. Req5 - Packet Loss . . . . . . . . . . . . . . . . . . . . 15 66 3.6. Req6 - Scalability . . . . . . . . . . . . . . . . . . . . 16 67 3.7. Req7 - Efficient Signaling . . . . . . . . . . . . . . . . 16 68 3.8. Req8 - Security . . . . . . . . . . . . . . . . . . . . . 17 69 3.9. Req9 - Adaptability . . . . . . . . . . . . . . . . . . . 18 70 4. Desirable Characteristics . . . . . . . . . . . . . . . . . . 19 71 4.1. Des1 - Configuration . . . . . . . . . . . . . . . . . . . 19 72 4.2. Des2 - Nesting . . . . . . . . . . . . . . . . . . . . . . 20 73 4.3. Des3 - System Impact . . . . . . . . . . . . . . . . . . . 20 74 4.4. Des4 - VMN Support . . . . . . . . . . . . . . . . . . . . 20 75 4.5. Des5 - Generality . . . . . . . . . . . . . . . . . . . . 21 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 78 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 79 8. Changes from draft-eddy-nemo-aero-reqs-02 . . . . . . . . . . 22 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 82 9.2. Informative References . . . . . . . . . . . . . . . . . . 23 83 Appendix A. Basics of IP-based Aeronautical Networking . . . . . 24 84 Appendix B. Basics of IP-based Space Networking . . . . . . . . . 25 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 86 Intellectual Property and Copyright Statements . . . . . . . . . . 27 88 1. Introduction 90 As background the NEMO terminology and NEMO goals and requirements 91 documents are suggested reading [4] [5]. The drafts produced as part 92 of the Mobile Platform Internet (MPI) effort are also of relevence, 93 and some of the material in this document is borrowed from the MPI 94 drafts [6] [7]. 96 The base NEMO standard [1] allows Mobile IPv6 [2] to be used by 97 mobile routers, although NEMO does not support Mobile IPv6's Route 98 Optimization (RO) features. NEMO allows mobile networks to 99 efficiently remain reachable via fixed IP address prefixes no matter 100 where they relocate within the network topology. This is 101 accomplished through the maintenance of a bidirectional tunnel 102 between a NEMO Mobile Router (MR) and a NEMO Home Agent (HA) placed 103 at some relatively stable point in the network. Corresponding Nodes 104 (CNs) that communicate with Mobile Network Nodes (MNNs) behind an MR 105 do so through the HA and MRHA tunnel in both directions. Since the 106 use of this tunnel may have significant drawbacks [8], RO techniques 107 that allow a more direct path between the CN and MR to be used are 108 highly desirable. 110 For decades, mobile networks of some form have been used for 111 communications with people and avionics equipment onboard aircraft 112 and spacecraft. These have not typically used IP, although 113 architectures are being devised and deployed based on IP in both the 114 aeronautics and space exploration communities (see Appendix A and 115 Appendix B for more information). An aircraft or spacecraft 116 generally contains many computing nodes, sensors, and other devices 117 that are possible to address individually with IPv6. This is 118 desirable to support network-centric operations concepts. Given that 119 a craft has only a small number of access links, it is very natural 120 to use NEMO MRs to localize the functions needed to manage the large 121 onboard network's reachability over the few dynamic access links. On 122 an aircraft, the nodes are arranged in multiple independent networks, 123 based on their functions. These multiple networks are required for 124 regulatory reasons to have different treatments of their air-ground 125 traffic, and often must use distinct air-ground links and service 126 providers. 128 For aeronautics, the main disadvantage of using NEMO bidirectional 129 tunnels is that airlines operate flights that traverse multiple 130 continents, and a single plane may fly around the entire world over a 131 span of a couple days. If a plane uses a static HA on a single 132 continent, then for a large percentage of the time when the plane is 133 not on the same continent as the HA, a great amount of delay is 134 imposed by using the MRHA tunnel. Avoiding the delay from 135 unnecessarily forcing packets across multiple continents is the 136 primary goal of pursuing NEMO RO for aeronautics. 138 Many other properties of the aeronautics and space environments 139 amplify the known issues with NEMO bidirectional MRHA tunnels [8] 140 even further. 142 Longer routes leading to increased delay and additional 143 infrastructure load - In aeronautical networks (e.g. using Plain 144 Old Aircraft Communication Addressing and Reporting System (ACARS) 145 or ACARS over VHF Data Link (VDL) mode 2 ) the queueing delays are 146 often long due to ARQ mechanisms and underprovisioned radio links. 147 Furthermore, for aeronautical communications systems that pass 148 through geosynchronous satellites, and for space exploration, the 149 propagation delays are also long. These delays combined with the 150 additional need to cross continents in order to transport packets 151 between ground stations and CNs means that delays are already 152 quite high in aeronautical and space networks without the addition 153 of an MRHA tunnel. The increased delays caused by MRHA tunnels 154 may be unacceptable in meeting Required Communication Performance 155 [9]. 157 Increased packet overhead - Given the constrained link bandwidths 158 available in even future communications systems for aeronautics 159 and space exploration, planners are extremely adverse to header 160 overhead. Since any amount of available link capacity can be 161 utilized for extra situational awareness, science data, etc., 162 every byte of header/tunnel overhead displaces a byte of useful 163 data. 165 Increased chances of packet fragmentation - Packet fragmentation 166 exacerbates the issue with header overhead and adds to 167 unreliability and possibly the need for end-to-end retransmission 168 if fragments are lost. Since error-prone radio links are 169 sometimes used in the aeronautical and space environments, loss of 170 fragments resulting in loss of entire packets is possible. The 171 odds of packets requiring fragmentation must be minimized in 172 aeronautical and space networks. 174 Increased susceptibility to failure - The additional likelihood of 175 either a single link failure disrupting all communications or an 176 HA failure disrupting all communications is problematic when using 177 MRHA tunnels for command and control applications that require 178 high availability for safety-of-life or safety-of-mission. 180 For these reasons, an RO extension to NEMO is highly desirable for 181 use in aeronautical and space networking. In fact, a standard RO 182 mechanism may even be necessary before some planners will seriously 183 consider advancing use of the NEMO technology from experimental 184 demonstrations to operational use within their communications 185 architectures. Without an RO solution, NEMO is difficult to justify 186 for realistic operational consideration. 188 In Section 2 we describe the relevent high-level features of the 189 access and onboard networks envisioned for use in aeronautics and 190 space exploration, as they influence the properties of usable NEMO RO 191 solutions. Section 3 then lists the technical and functional 192 characteristics that are absolutely required of a NEMO RO solution 193 for these environments, while Section 4 lists some additional 194 characteristics that are desired, but not necessarily required. In 195 Appendix A and Appendix B we provide brief primers on the specific 196 operational concepts used in aeronautics and space exploration 197 respectively for IP-based network architectures. 199 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 200 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 201 document are to be interpreted as described in RFC 2119. Although 202 this document does not specify an actual protocol, but rather just 203 the requirements for a protocol, it still uses the RFC 2119 language 204 to make the requirements clear. 206 2. NEMO RO Scenarios 208 To motivate and drive the development of the requirements and 209 desirable features for NEMO RO solutions, in this section some 210 operational characteristics are described to explain how access 211 networks, HAs, and CNs are configured and distributed geographically 212 and topologically in aeronautical and space network architectures. 213 This may be useful in determining which classes of RO techniques 214 within the known solution space [10] are feasible. 216 2.1. Aeronautical Communications Scenarios 218 Since aircraft may be simultaneously connected to multiple ground 219 access networks using diverse technologies with different coverage 220 properties, it is difficult to say much in general about the rate of 221 changes in active access links and care-of addresses (CoAs). As one 222 data point, for using VDL mode 2 data links, the length of time spent 223 on a single access channel varies depending on the stage of flight. 224 On the airport surface, VDL mode 2 access is stable while a plane is 225 unloaded, loaded, refueled, etc., but other wired and wireless LAN 226 links (e.g. the Gatelink system) may come and go. Immediately after 227 takeoff and before landing, planes are in the terminal maneuvering 228 area for approximately 10 minutes and stably use another VDL mode 2 229 channel. During en-route flight, handovers between VDL mode 2 230 channels may occur every 30 to 60 minutes, depending on the exact 231 flight plan and layout of towers, cells, and sectors used by a 232 service provider. These handovers may result in having a different 233 access router and a change in CoA, though the use of local mobility 234 management (e.g. [11]) may limit the changes in CoA to only handovers 235 between different providers or types of data links. 237 The characteristics of a data flow between a CN and MNN varies both 238 depending on the data flow's domain, and the particular application 239 within the domain. Even within the three aeronautical domains 240 described below, there are varying classes of service that are 241 regulated differently (e.g. for emergencies versus nominal 242 operations), but this level of detail has been abstracted out for the 243 purposes of this document. It is assumed that any viable NEMO RO 244 solution will be able to support a granularity of configuration with 245 many sub-classes of traffic within each of the specific domains 246 listed here. 248 2.1.1. Air Traffic Services Domain 250 The MNNs involved in Air Traffic Services (ATS) consist of pieces of 251 avoinics hardware onboard an aircraft used to provide navigation, 252 control, and situational awareness. The applications run by these 253 MNNs are mostly critical to the safety of the lives of the passengers 254 and crew. The MNN equipment may consist of a range of devices from 255 typical laptop computers to very specialized avionics devices. These 256 MNNs will mostly be Local Fixed Nodes (LFNs), with a few Local Mobile 257 Nodes (LMNs) to support Electronic Flight Bags, for instance. It can 258 be assumed that Visiting Mobile Nodes (VMNs) are never used within 259 the ATS domain. 261 An MR used for ATS will be capable of using multiple data links (at 262 least VHF-based, satellite, HF-based, and wired), and will likely be 263 supported by a backup unit in the case of failure, leading to a case 264 of a multi-homed MR that is at least multi-interfaced and possibly 265 multi-prefixed as well, in NEMO terminology. 267 Since for ATS, the MRs and MNNs are under regulatory control and are 268 actively tested and maintained, it is not unreasonable to assume that 269 special patches or software be running on these devices to enable 270 NEMO RO. In fact, since these devices are accessed by skilled 271 technicians and professionals, it may be acceptable even if complex 272 configuration is required for NEMO RO. Of course simplicity in setup 273 and configuration is desirable, however. 275 Data flows from the ATS domain may be assumed to consist mainly of 276 short transactional exchanges such as clearance requests and grants. 277 Future ATS communications are likely to include longer messages and 278 higher message frequencies for positional awareness and trajectory 279 intent of all vehicles in motion at the airport and all aircraft 280 within a thirty mile range during flight. Many of these may be 281 aircraft-to-aircraft, but the majority of current exchanges are 282 between the MNNs and a very small set of CNs within a control 283 facility at any time due to the full transfer of control as a plane 284 moves across sectors of airspace. The set of CNs may be assumed to 285 all share the same network prefix. These CNs are also involved in 286 other data flows over the same access network that the MR is attached 287 to, managing other flights within the sector. These CNs are often 288 geographically and topologically much closer to the MR in comparison 289 to a single fixed HA. 291 2.1.2. Airline Operational Services Domain 293 Data flows for Airline Operational Services (AOS) are not critical to 294 the safety of the passengers or aircraft, but are needed for the 295 business operations of airlines operating flights, and may affect the 296 profitability of an airline's flights. Most of these data flows are 297 sourced by MNNs that are part of the flight management system or 298 sensor nodes on an aircraft, and are terminated at CNs located near 299 an airline's headquarters or operations center. AOS traffic may 300 include detailed electronic passenger manifests, passenger ticketing 301 and rebooking traffic, and complete electronic baggage manifests. 302 When suitable bandwidth is available (currently on the surface when 303 connected to a wired Gatelink system), "airplane health information" 304 data transfers of between 10 and several-hundred megabytes of data 305 are likely, and in the future, it is expected that the In-Flight 306 Entertainment (IFE) systems may receive movie refreshes of data (e.g. 307 television programming or recent news updates) running into the 308 multi-gigabyte range. 310 Currently, these flows are often short messages that record the 311 timing of events of a flight, engine performance data, etc., but may 312 be longer flows that upload weather or other supplementary data to an 313 aircraft. In addition, email-like interactive messaging may be used 314 at any time during a flight. For instance, messages can be exchanged 315 before landing to arrange for arrival-gate services to be available 316 for handicapped passengers, refueling, food and beverage stocking, 317 and other needs. This messaging is not limited to landing 318 preparation, though, and may occur at any stage of flight. 320 The equipment comprising these MNNs and CNs has similar 321 considerations to the equipment used for the ATS domain. A key 322 difference between ATS and AOS is that AOS data flows are routed to 323 CNs that may be much more geographically remote to the aircraft than 324 CNs used by ATS flows, as AOS CNs will probably be located at an 325 airline's corporate data center or headquarters. The AOS CNs will 326 also probably be static for the lifetime of the flight, rather than 327 dynamic like the ATS CNs. An HA used for AOS may be fairly close 328 topologically to the CNs, and RO may not be as big of a benefit for 329 AOS, since simple event logging is more typical than time-critical 330 interactive messaging. For the small number of messaging flows, 331 however, the CNs are geographically (but not necessarily 332 topologically) very close to the aircraft, though this depends on how 333 applications are written; whether they use centralized servers or 334 exchange messages directly. Additionally, since AOS communication is 335 more advisory in nature than ATS, rather than safety-critical, AOS 336 flows are less sensitive to tunnel inefficiencies than ATS flows. 337 For these reasons, in this document, we consider AOS data flow 338 concerns with RO mechanisms to not be full requirements, but instead 339 consider them under the desirable properties in Section 4. 341 2.1.3. Passenger Services Domain 343 The MNNs involved in the Passenger Information and Entertainment 344 Services (PIES) domain are mostly beyond the direct control of any 345 single authority. The majority of these MNNs are VMNs and personal 346 property brought onboard by passengers for the duration of a flight, 347 and thus it is unreasonable to assume that they be preloaded with 348 special software or operating systems. These MNNs run stock Internet 349 applications like web browsing, email, and file transfer, often 350 through VPN tunnels. The MNNs themselves are portable electronics 351 such as laptop computers and mobile smartphones capable of connecting 352 to an onboard wireless access network (e.g. using 802.11). To these 353 MNN devices and users, connecting to the onboard network is identical 354 to connecting to any other terrestrial "hotspot" or typical wireless 355 LAN. The MNNs are completely oblivious to the fact that this access 356 network is on an airplane and possibly moving around the globe. The 357 users are not always technically-proficient and may not be capable of 358 performing any special configuration of their MNNs or applications. 360 A small number of PIES MNNs may be LFNs that store and distribute 361 cached media content (e.g. movies and music), or may provide gaming 362 services to passengers. Due to the great size of the data stored on 363 these LFNs compared to the anemic bandwidth available air-to-ground, 364 these LFNs will probably not attempt to communicate off-board at all 365 during the course of a flight, but will wait to update their content 366 via either high-speed links are available on the ground, or via 367 removable media inserted by the flight crew. However, if a higher 368 bandwidth link were affordably available, it might be used in-flight 369 for these purposes, but supporting this is not a requirement. Data 370 flows needed for billing passengers for access to content are 371 relatively low bandwidth and are currently done in-flight. The 372 requirements of these data flows are less stringent than those of 373 ATC, however, so they are not specifically considered here. 375 The PIES domain is not critical to safety-of-life, but is merely an 376 added comfort or business service to passengers. Since PIES 377 applications may consume much more bandwidth than the available links 378 used in other domains, the PIES MNNs may have their packets routed 379 through a separate high-bandwidth link, that is not used by the ATS 380 data flows. For instance, several service providers are planning to 381 offer passenger Internet access during flight at DSL-like rates, just 382 as the Connexion by Boeing system did. Several airlines also plan to 383 offer onboard cellular service to their passengers, possibly 384 utilizing Voice-over-IP for transport. Due to the lack of 385 criticality and the likelihood of being treated independently, in 386 this document, PIES MNN concerns are not considered as input to 387 requirements in Section 3. The RO solution should be optimized for 388 ATS and AOS needs, and consider PIES as a secondary concern. 390 With this in consideration, the PIES domain is also the most likely 391 to utilize NEMO for communications in the near-term since 392 relatatively little regulations and beaurocracy are involved in 393 deploying new technology in this domain, and IP-based PIES systems 394 have previously been developed and deployed (although not using NEMO) 395 [12]. For these reasons, PIES concerns factor heavily into the 396 desirable properties in Section 4 outside of the mandatory 397 requirements. 399 Some PIES nodes are currently using 2.5G/3G links for mobile data 400 services, and these may be able to migrate to an IP-based onboard 401 mobile network, when available. 403 2.2. Space Exploration Scenarios 405 This section describes some features of the network environments 406 found in space exploration that are relevent to selecting an 407 appropriate NEMO RO mechanism. It should be noted that IPv4-based 408 mobile routing has been demonstrated onboard the UK-DMC satellite and 409 that the documentation on this serves as a useful reference for 410 understanding some of the goals and configuration issues for certain 411 types of space use of NEMO [13]. This section assumes space use of 412 NEMO within the "near-Earth" range of space (i.e. not for 413 communications between the Earth and Mars, or other "deep-space" 414 locations). Note, that NEMO is currently being considered for use 415 out to Lunar distances. No strong distinction is made here between 416 civilian versus military use, or exploration mission versus Earth- 417 observing or other mission types; our focus is on civilian 418 exploration missions, but we believe that many of the same basic 419 concerns are relevent to these other mission types. 421 In space communications, a high degree of bandwidth asymmetry is 422 often present, with the uplink from the ground to a craft typically 423 being multiple orders of magnitude slower than the downlink from the 424 craft to the ground. This means that the RO overhead may be 425 negligible on the downlink but significant for the uplink. An RO 426 scheme that minimizes the amount of signaling from CNs to an MN is 427 desirable, since these uplinks may be low-bandwidth to begin with 428 (possibly only several kilobits per second). Since the uplink is 429 used for sending commands, it should not be blocked for long periods 430 while serializing long RO signaling packets; any RO signaling from 431 the CN to MNNs must not involve large packets. 433 For unmanned space flight, the MNNs onboard a spacecraft consist 434 almost entirely of LFN sensing devices and processing devices that 435 send telemetry and science data to CNs on the ground and actuator 436 devices that are commanded from the ground in order to control the 437 craft. Robotic lunar rovers may serve as VMNs behind an MR located 438 on a lander or orbiter, but these rovers will contain many 439 independent instruments and could probably configured as an MR and 440 LFNs instead of using a single VMN address. 442 It can be assumed that for manned spaceflight, at least, multiple MRs 443 will be present and on-line simultaneously for fast failover. These 444 will usually be multihomed over space links in diverse frequency 445 bands, and so multiple access network prefixes can be expected to be 446 in use simultaneously, especially since some links will be direct to 447 ground stations while others may be bent-pipe repeated through 448 satellite relays like TDRSS. This conforms to the (n,1,1) or (n,n,1) 449 NEMO multihoming scenarios [14]. For unmanned missions, if low 450 weight and power are more critical, it is likely that only a single 451 MR and single link/prefix may be present, conforming to the (1,1,1) 452 or (1,n,1) NEMO multihoming scenarios [14]. 454 In some modes of spacecraft operation, all communications may go 455 through a single onboard computer (or a Command and Data Handling 456 system as on the International Space Station) rather than directly to 457 the MNNs themselves, so there is only ever one MNN behind an MR that 458 is in direct contact with off-board CNs. In this case removing the 459 MR and using simple host-based Mobile IPv6 rather than NEMO is 460 possible, but an MR is more desirable because it could be part of a 461 modular communications adapter that is used in multiple diverse 462 missions to bridge on-board buses and intelligently manage space 463 links, rather than re-creating these capabilities per-mission if 464 using simple Mobile IPv6 with a single Command and Data Handling node 465 that varies widely between spacecraft. Also, all visions for the 466 future involve network-centric operations where the direct 467 addressability and accessibility of end devices and data is crucial. 468 As network-centric operations become more prevalent, application of 469 NEMO is likely to be needed to increase the flexibility of data flow. 471 The MRs and MNNs onboard a spacecraft are highly-customized computing 472 platforms, and adding custom code or complex configurations in order 473 to obtain NEMO RO capabilities is feasible, although it should not be 474 assumed that any amount of code or configuration maintenance is 475 possible after launch. The RO scheme as it is initially configured 476 should continue to function throughout the lifetime of an asset. 478 For manned space flight, additional MNNs on spacesuits and astronauts 479 may be present and used for applications like two-way voice 480 conversation or video-downlink. These MNNs could be reusable and 481 reconfigured per-flight for different craft or mission network 482 designs, but it is still desirable for them to be able to 483 autoconfigure themselves and they may move between nested or non- 484 nested MRs during a mission. For instance, if astonauts move between 485 two docked spacecraft, each craft may have its own local MR and 486 wireless coverage that the suit MNNs will have to reconfigure for. 487 It is desirable if a RO solution can respond appropriately to this 488 change in locality, and not cause high levels of packet loss during 489 the transitional period. It is also likely that these MNNs will be 490 part of Personal Area Networks (PANs), and so may appear either 491 directly as MNNs behind the main MR onboard, or might have their own 492 MR within the PAN and thus create a nested (or even multi-level 493 nested) NEMO configuration. 495 3. Required Characteristics 497 This section lists requirements that specify the absolute minimal 498 technical and/or functional properties that a NEMO RO mechanism must 499 possess to be usable for aeronautical and space communications. 501 In the recent work done by the International Civial Aviation 502 Organization (ICAO) to identify viable mobility technologies for 503 providing IP services to aircraft, a set of technical criteria was 504 developed [7] [15]. The nine required characteristics listed in this 505 document can be seen as directly descended from these ICAO criteria, 506 except here we have made them much more specific and focused for the 507 NEMO technology and the problem of RO within NEMO. The original ICAO 508 criteria were more general and used for comparing the features of 509 different mobility solutions (e.g. mobility techniques based on 510 routing protocols versus transport protocols versus Mobile IP, etc.). 511 Within the text describing each requirement in this section, we 512 provide the high-level ICAO criteria from which it evolved. 514 These requirements for aeronautics are generally similar to or in 515 excess of the requirements for space exploration, so we do not add 516 any additional requirements specifically for space exploration. In 517 addition, the lack of a standards body regulating performance and 518 safety requirements for space exploration means that the requirements 519 for aviation are much easier to agree upon and base within existing 520 requirements frameworks. After consideration, we believe that the 521 set of aviation-based requirements outlined here also fully suffices 522 for space exploration. 524 3.1. Req1 - Separability 526 Since RO may be inappropriate for some flows, an RO scheme MUST 527 support configuration by a per-domain dynamic RO policy database. 528 Entries in this database can be similar to those used in IPsec 529 security policy databases in order to specify either bypassing or 530 utilizing RO for specific flows. 532 3.1.1. Rationale for Aeronautics - Separability 534 Even if RO is available to increase the performance of a mobile 535 network's traffic, it may not be appropriate for all flows. 537 There may also be a desire to push certain flows through the MRHA 538 path rather than perform RO to enable them to be easily recorded by a 539 central service. 541 For these reasons, an RO scheme must have the ability to be bypassed 542 by applications that desire to use bidirectional tunnels through an 543 HA. This desire could be expressed through a policy database similar 544 to the Security Policy Database used by IPsec, for instance, but the 545 specific means of signaling or configuring the expression of this 546 desire by applications is left as a detail for the specific RO 547 specifications. 549 In addition, it is expected that the use of NEMO technology is 550 decided on a per-domain basis, so that it is possible that for some 551 domains, separate MRs are used, or even non-NEMO mobility techniques. 552 This requirement for an RO policy database only applies to domains 553 that utilize NEMO. 555 This requirement was derived from ICAO's TC-1 - "The approach should 556 provide a means to define data communications that can be carried 557 only over authorized paths for the traffic type and category 558 specified by the user." 560 3.2. Req2 - Multihoming 562 An RO solution MUST support an MR having multiple interfaces, and 563 MUST allow a given domain to be bound to a specific interface. It 564 MUST be possible to use different MNPs for different domains. 566 3.2.1. Rationale for Aeronautics - Multihoming 568 Multiple factors drive a requirement for multihoming capabilities. 569 For ATS safety-of-life critical traffic, the need for high 570 availability suggests a basic multihoming requirement. The 571 regulatory and operational difficulty in deploying new systems and 572 transitioning away from old ones also implies that a mix of access 573 technologies may be in use at any given time, and may require 574 simultaneous use. Another factor is that the multiple domains of 575 applications onboard may actually be restricted in what data links 576 they are allowed to use based on regulations and policy, so at 577 certain times or locations, PIES data flows may have to use distinct 578 access links from those used by ATS data flows. 580 This drives the requirement that an RO solution MUST allow for an MR 581 to be connected to multiple access networks simultaneously and have 582 multiple CoAs in use simultaneously. The selection of a proper CoA 583 and access link to use per-packet may be either within or outside the 584 scope of the RO solution. As a minimum, if an RO solution is 585 integrable with the MONAMI6 basic extensions (i.e. registration of 586 multiple CoAs and flow bindings), and does not preclude their use, 587 then this requirement can be considered to be satisfied. 589 It is not this requirement's intention that an RO scheme itself 590 provide multihoming, but rather simply to exclude RO techniques whose 591 use is not possible in multihomed scenarios. 593 In terms of NEMO multihoming scenarios [14], it MUST be possible to 594 support at least the (n,1,n) and (n,n,n) scenarios. 596 This requirement was derived from ICAO's TC-2 - "The approach should 597 enable an aircraft to both roam between and to be simultaneously 598 connected to multiple independent air-ground networks." 600 3.3. Req3 - Latency 602 While an RO solution is in the process of setting up or 603 reconfiguring, packets of specified flows MUST be capable of using 604 the MRHA tunnel. 606 3.3.1. Rationale for Aeronautics - Latency 608 It is possible that an RO scheme may take longer to setup or involve 609 more signaling than the basic NEMO MRHA tunnel maintenance that 610 occurs during an update to the MR's active CoAs when the set of 611 usable access links changes. During this period of flux, it may be 612 important for applications to be able to immediately get packets onto 613 the ground network, especially considering that connectivity may have 614 been blocked for some period of time while link-layer and NEMO 615 proceedures for dealing with the transition occurred. Also, when an 616 application starts for the first time, the RO scheme may not have 617 previous knowledge related to the CN and may need to perform some 618 setup before an optimized path is available. If the RO scheme blocks 619 packets either through queueing or dropping while it is configuring 620 itself, this could result in unacceptable delays. 622 Thus, when transitions in the MR's set of active access links occurs, 623 the RO scheme MUST NOT block packets from using the MRHA tunnel if 624 the RO scheme requires more time to setup or configure itself than 625 the basic NEMO tunnel maintenance. Additionally, when an application 626 flow is started, the RO scheme MUST allow packets to immediately be 627 sent, perhaps without the full benefit of RO, if the RO scheme 628 requires additional time to configure a more optimal path to the CN. 630 This requirement was derived from ICAO's TC-3 - "The approach should 631 minimize latency during establishment of initial paths to an 632 aircraft, during handoff, and during transfer of individual data 633 packets." 635 3.4. Req4 - Availability 637 An RO solution MUST be compatible with network redundancy mechanisms 638 and MUST NOT prevent fall-back to the MRHA tunnel if an element in an 639 optimized path fails. 641 An RO mechanism MUST NOT add any new single point of failure for 642 communications in general. 644 3.4.1. Rationale for Aeronautics - Availability 646 A need for high availability of connectivity to ground networks 647 arises from the use of IP networking for carrying safety-of-life 648 critical traffic. For this reason, single points of failure need to 649 be avoided. If an RO solution assumes either a single MR onboard, a 650 single HA, or some similar vulnerable point, and is not usable when 651 the network includes standard reliability mechanisms for routers, 652 then the RO technique will not be acceptable. An RO solution also 653 MUST NOT itself imply a single point of failure. 655 If a failure occurs in a path selected by an RO technique, then that 656 RO technique MUST NOT prevent fallback to the MRHA path for affected 657 traffic. 659 This does not mention specific redundancy mechanisms for MRs, HAs, or 660 other networking elements, so as long as some reasonable method for 661 making each component redundant fits within the assumptions of the RO 662 mechanism, this requirement can be considered satisfied. 664 There is no intention to support "Internet-less" operation through 665 this requirement. When an MR is completely disconnected from the 666 majority of the network it is intended to communicate, including its 667 HA, there is no requirement for it to be able to retain any 668 communications involving parties outside the mobile networks managed 669 by itself. 671 This requirement was derived from ICAO's TC-4 - "The approach should 672 have high availability which includes not having a single point of 673 failure." 675 3.5. Req5 - Packet Loss 677 An RO scheme MUST NOT cause either loss or duplication of data 678 packets during RO path establishment, usage, or transition, above 679 that caused in the NEMO basic support case. 681 3.5.1. Rationale for Aeronautics - Packet Loss 683 It is possible that some RO schemes could cause data packets to be 684 lost during transitions in RO state or due to unforseen packet 685 filters along the RO-selected path. This could be difficult for an 686 application to detect and respond to in time. For this reason, an RO 687 scheme MUST NOT cause packets to be dropped at any point in 688 operation, when they would not normally have been dropped in a non-RO 689 configuration. 691 As an attempt at optimizing against packet loss, some techniques may 692 for some time duplicate packets sent over both the MRHA tunnel and 693 the optimized path. If this results in duplicate packets being 694 delivered to the application, this is also unacceptable 696 This requirement does not necessarily imply make-before-break in 697 transitioning between links. The intention is that during the 698 handoff period, the RO scheme itself should not produce losses (or 699 duplicates) that would not have occurred if RO had been disabled. 701 This requirement was derived from ICAO's TC-5 - "The approach should 702 not negatively impact end-to-end data integrity, for example, by 703 introducing packet loss during path establishment, handoff, or data 704 transfer." 706 It is understood that this may be a requirement that is not easily 707 implementable with regards to RO. Furthermore Req1, Separability, 708 may be sufficient in allowing loss-sensitive and duplicate-sensitive 709 flows to take the MRHA path. 711 3.6. Req6 - Scalability 713 An RO scheme MUST be simultaneously usable by ten thousand craft 714 without overloading the ground network or routing system. This 715 explicitly forbids injection of BGP routes into the global Internet 716 for purposes of RO. 718 3.6.1. Rationale for Aeronautics - Scalability 720 Several thousand aircraft may be in operation at some time, each with 721 perhaps several hundred MNNs onboard. The number of active 722 spacecraft using IP will be multiple orders of magnitude smaller than 723 this over at least the next decade, so the aeronautical needs are 724 more stringent in terms of scalability to large numbers of MRs. It 725 would be a non-starter if the combined use of an RO technique by all 726 of the MRs in the network caused ground networks provisioned within 727 the realm of typical long-haul private telecommunications networks 728 (like the FAA's Telecommunications Infrastructure (FTI) or NASA's 729 NISN) to be overloaded or melt-down under the RO signaling load or 730 amount of rapid path changes for multiple data flows. 732 Thus, an RO scheme MUST be simultaneously usable by ten thousand 733 nodes without overloading the ground network or routing system. 735 Since at least one traffic domain (PIES) requires connectivity to the 736 Internet, and it is possible that the Internet would provide 737 transport for other domains at some distant point in the future, this 738 requirement explicitly forbids the use of techniques that are known 739 to scale poorly in terms of their global effects, like BGP, for the 740 purposes of RO. 742 This requirement was derived from ICAO's TC-6 - "The approach should 743 be scaleable to accomodate anticipated levels of aircraft equipage." 745 3.7. Req7 - Efficient Signaling 747 An RO scheme MUST be capable of efficient signaling in terms of both 748 size and number of individual signaling messages and the ensemble of 749 signaling messages that may simultaneously be triggered by concurrent 750 flows. 752 3.7.1. Rationale for Aeronautics - Efficient Signaling 754 The amount of bandwidth available for aeronautical and space 755 communications has historically been quite small in comparison to the 756 desired bandwidth (e.g. in the case of VDL links the bandwidth is 8 757 kbps of shared resources). This situation is expected to persist for 758 at least several more years. Links tend to be provisioned based on 759 estimates of application needs (which could well prove wrong if 760 either demand or the applications in-use themselves do not follow 761 expectations), and do not leave much room for additional networking 762 protocol overhead. Since every byte of available air-ground link 763 capacity that is used by signaling for NEMO RO is likely to delay 764 bytes of application data and reduce application throughput, it is 765 important that the NEMO RO scheme's signaling overhead scales up much 766 more slowly than the throughput of the flows RO is being performed 767 on. This way as higher-rate datalinks are deployed along with more 768 bandwidth-hungry applications, the NEMO RO scheme will be able to 769 safely be discounted in capacity planning. 771 Note that in meeting this requirement, an RO technique must be 772 efficient in both the size and number of individual messages that it 773 sends, as well as the ensemble of messages sent at one time (for 774 instance, to give RO to multiple ongoing flows following a handover) 775 in order to prevent storms of packets related to RO. 777 This requirement was derived from ICAO's TC-7 - "The approach should 778 result in throughput which accommodates anticipated levels of 779 aircraft equipage." 781 3.8. Req8 - Security 783 For the ATS/AOS domains, there are three security sub-requirements: 785 * The RO scheme MUST NOT further expose MNPs on the wireless link 786 than already is the case for NEMO basic support. 788 * The RO scheme MUST permit the receiver of a BU to validate the CoAs 789 claimed by an MR. 791 * The RO scheme MUST ensure that only explicitly authorized MRs are 792 able to perform a binding update for a specific MNP. 794 For the PIES domain, there are no additional requirements beyond 795 those of normal Internet services and the same requirements for 796 normal Mobile IPv6 RO apply. 798 3.8.1. Rationale for Aeronatics - Security 800 The security needs are fairly similar between ATS and AOS, but vary 801 widely between the ATS/AOS domains and PIES. For PIES, the traffic 802 flows are typical of terrestrial Internet use and the security 803 requirements for RO are identical to those of conventional Mobile 804 IPv6 RO. For ATS/AOS, however, there are somewhat more strict 805 requirements, along with some safe assumptions that designers of RO 806 schemes can make. Below, we describe each of these ATS/AOS issues, 807 but do not further discuss PIES RO security. 809 The first security requirement is driven by concerns expressed by ATS 810 communications engineers. The concern is with the air-ground links 811 to a craft, and their current lack of security. If an RO scheme 812 exposes the MNP to eavesdroppers on these links, it may enable 813 attackers to easily send packets towards onboard networks of crafts. 814 The RO scheme should use some reasonable form of encryption (e.g. 815 standard ESP transforms) in order to protect any new RO signalling 816 data that contains the MNP. 818 To protect bindings to bogus CoAs from being sent, the RO scheme must 819 somehow validate that an MR actually possesses any CoAs that it 820 claims. In typical Mobile IPv6 RO, the return routability test 821 provides a form of validation, under certain assumptions. For the 822 purposes of aeronautics, when designing a technique for an MR to 823 demonstrate ownership of some CoA, it is safe to assume ingress 824 filtering on the part of the access network providers, in conjunction 825 with the ability to correlate a BU's source address and the decrypted 826 alternate CoA at the end recipient of the BU. (Note: this is 827 particularly subject to MEXT discussion) 829 To protect against "rouge" MRs or abuse of compromised MRs, the RO 830 scheme MUST be capable of checking that an MR is actually authorized 831 to perform a binding update for a specific MNP. To meet this 832 requirement, it can be assumed that some aeronautical organization 833 authority exists who can provide the required authorization, possibly 834 in the form of a certificate that the MR possesses, signed by the 835 aeronautical authority. 837 It is also reasonable to assume trust relationshiops between each MR 838 and a number of mobility anchor points topologically near to its CNs 839 (these anchor points may be owned by the service providers), but it 840 is not reasonable to assume that trust relationships can be 841 established between an MR and any given CN itself. 843 This requirement was extrapolated from ICAO's TC-8 - "The approach 844 should be secure.", and made more specific with help from the MEXT 845 working group. 847 3.9. Req9 - Adaptability 849 Applications using new transport protocols, IPsec, or new IP options 850 MUST be possible within an RO scheme. 852 3.9.1. Rationale for Aeronatics - Adaptability 854 The concepts of operations are not fully developed for network- 855 centric command and control and other uses of IP-based networks in 856 aeronautical and space environments. The exact application 857 protocols, data flow characteristics, and even transport protocols 858 that will be used in either transitional and final operational 859 concepts are not completely defined yet, and may even change with 860 deployment experience. If the RO solution assumes that some amount 861 of preconfiguration of flow properties (port number ranges, etc.) is 862 required, this could make the integration of new applications or 863 protocols difficult. An RO scheme might assume this in order to 864 classify between flows that prefer the MRHA tunnel to an optimized 865 path per requirement Req1, for instance, among other reasons. Since 866 flag days or other such large-scale synchronized configuration 867 updates are to be avoided to ensure high availability, the RO scheme 868 MUST NOT fail on the use of unexpected higher layer protocols 869 (transport and above). 871 Specifically, the use of IPsec by applications MUST be possible. 872 Security based on IPsec is widely understood and modules qualified 873 for use in aeronautical and space exploration environments are 874 currently available off-the-shelf due to the US Department of Defense 875 HAIPE work. Other security frameworks may not be as attractive due 876 to a lack of familiarity or available flight-qualified systems. If 877 an RO solution precludes the use of IPsec by applications, this would 878 make it undesirable or unusable. 880 This drives the requirement that new applications, potentially using 881 new transport protocols must be usable within an RO scheme, and MUST 882 NOT involve global reconfiguration events for MRs. 884 This requirement was derived from ICAO's TC-9 - "The approach should 885 be scalable to accomodate anticipated transition to new IP-based 886 communication protocols." 888 4. Desirable Characteristics 890 In this section, we identify some of the properties of the system 891 that are not strict requirements due to either being difficult to 892 quantify or to being features that are not immediately needed, but 893 may provide additional benefits that would help encourage adoption. 895 4.1. Des1 - Configuration 897 For ATS systems, complex configurations are known to increase 898 uncertainty in context, human error and the potential for undesirable 899 (unsafe) states to be reached [16]. Since RO alters the 900 communications context between an MNN and CN, it is desirable that a 901 NEMO RO solution be as simple to configure as possible and also easy 902 to automatically disable if an undesirable state is reached. 904 For CNs at large airports, the Binding Cache state management 905 functions may be simultaneously dealing with hundreds of airplanes 906 with multiple service providers, and a volume of mobility events due 907 to arrivals and departures. The ability to have simple interfaces 908 for humans to access the Binding Cache configuration and alter it in 909 case of errors are desirable, if this does not interfere with the RO 910 protocol mechanisms themselves. 912 4.2. Des2 - Nesting 914 It is desirable if the RO mechanism supports RO for nested MRs, since 915 it is possible that for PIES and astronaut spacesuits, that PANs with 916 MRs will need to be supported. For oceanic flight, ATS and AOS may 917 also benefit from the capability of nesting MRs between multiple 918 planes to provide a "reachback" to terrestrial groundstations rather 919 than relying solely on lower rate HF or satellite systems. In either 920 case, this mode of operation is beyond current strict requirements 921 and is merely desirable. It is also noted that there are other ways 922 to support these communications scenarios using routing protocols or 923 other means outside of NEMO. 925 4.3. Des3 - System Impact 927 Low complexity in systems engineering and configuration management is 928 desirable in building and maintaining systems using the RO mechanism. 929 This property may be difficult to quantify, judge, and compare 930 between different RO techniques, but a mechanism that is perceived to 931 have lower impact on the complexity of the network communications 932 system should be favored over an otherwise equivalent mechanism (with 933 regards to the requirements listed above). This is somewhat 934 different than Des1 (Configuration), in that Des1 refers to operation 935 and maintenance of the system once deployed, whereas Des3 is 936 concerned with the initial design, deployment, transition, and later 937 upgrade path of the system. 939 4.4. Des4 - VMN Support 941 At least LFNs MUST be supported by a viable RO solution for 942 aeronautics, as these local nodes are within the ATS and AOS domains. 943 If Mobile IPv6 becomes a popular technology used by portable consumer 944 devices, VMNs within the PIES domain are expected to be numerous, and 945 it is strongly desirable for them to be supported by the RO 946 technique, but not strictly required. LMNs are potentially present 947 in future space exploration scenarios, such as Moon and Mars manned 948 exploration missions. 950 4.5. Des5 - Generality 952 An RO mechanism that is "general purpose", in that it is also readily 953 usable in other contexts outside of aeronautics and space 954 exploration, is desirable. For instance, a RO solution that is 955 usable within VANETs [17] or consumer electronics equipment [18] 956 could satisfy this. The goal is for the technology to be more 957 widely-used and maintained outside the relatively-small aeronautical 958 networking community and its vendors, in order to make acquisitions 959 and training faster, easier, and cheaper. This could also allow 960 aeronautical networking to possibly benefit from future RO scheme 961 optimizations and developments whose research and development is 962 funded and performed externally by the broader industry and academic 963 communities. 965 5. Security Considerations 967 This document does not create any security concerns in and of itself. 968 The security properties of any NEMO RO scheme that is to be used in 969 aeronautics and space exploration are probably much more stringent 970 than for more general NEMO use, due to the safety-of-life and/or 971 national security issues involved. The required security properties 972 are described under Req8 of Section 3 within this document. 974 Under an assumption of closed and secure backbone networks, the air- 975 ground link is the weakest portion of the network, and most 976 suseceptible to injection of packets, flooding, and other attacks. 977 Future air-ground data links that will use IP are being developed 978 with link-layer security as a concern. This development can assist 979 in meeting one of this document's listed security requirements (that 980 MNPs not be exposed on the wireless link), but the other requirements 981 affect the RO technology more directly without regard to the presence 982 or absence of air-ground link-layer security. 984 When deploying in operational networks where network layer security 985 may be mandated (e.g. virtual private networks), the interaction 986 between this and NEMO RO techniques should be carefully considered to 987 ensure that the security mechanisms do not undo the route 988 optimization by forcing packets through a less-optimal overlay or 989 underlay. For instance, when IPsec tunnel use is required, the 990 locations of the tunnel endpoints can force sub-optimal end-to-end 991 paths to be taken. 993 6. IANA Considerations 995 This document neither creates nor updates any IANA registries. 997 7. Acknowledgments 999 Input from several parties is indirectly included in this document. 1000 Participants in the MPI mailing list and BoF efforts helped to shape 1001 the document. The NEMO and MONAMI6 working group participants were 1002 instrumental in completing this document. The participants in the 1003 MEXT interim meeting February 7th and 8th of 2008 in Madrid were 1004 critical in solidifying these requirements. Specific suggestions 1005 from Steve Bretmersky, Thierry Ernst, Tony Li, Jari Arkko, Phillip 1006 Watson, Roberto Baldessari, Carlos Jesus Bernardos Cano, Eivan 1007 Cerasi, Marcelo Bagnulo, Serkan Ayaz, and Christian Bauer were 1008 incorporated into this document. 1010 Wesley Eddy's work on this document was performed at NASA's Glenn 1011 Research Center, while in support of NASA's Advanced Communications 1012 Navigations and Surveillance Architectures and System Technologies 1013 (ACAST) project, and the NASA Space Communications Architecture 1014 Working Group (SCAWG). 1016 8. Changes from draft-eddy-nemo-aero-reqs-02 1018 Note, this section will be removed upon publication as an RFC. 1020 At the IETF70 mext the aeronautics community indicated we would 1021 change the nemo-aero-req-02 document into a mext document with 1022 little modification. This the the corresponding document. 1024 Any Undefined Acronyms have been defined during first use. 1026 9. References 1028 9.1. Normative References 1030 [1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 1031 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1032 January 2005. 1034 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1035 IPv6", RFC 3775, June 2004. 1037 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1038 Levels", BCP 14, RFC 2119, March 1997. 1040 9.2. Informative References 1042 [4] Ernst, T. and H-Y. Lach, "Network Mobility Support 1043 Terminology", RFC 4885, July 2007. 1045 [5] Ernst, T., "Network Mobility Support Goals and Requirements", 1046 RFC 4886, July 2007. 1048 [6] Ivancic, W., "Multi-Domained, Multi-Homed Mobile Networks", 1049 draft-ivancic-mobile-platforms-problem-00 (work in progress), 1050 September 2006. 1052 [7] Davis, T., "Mobile Internet Platform Aviation Requirements", 1053 draft-davis-mip-aviationreq-00 (work in progress), 1054 September 2006. 1056 [8] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility 1057 Route Optimization Problem Statement", RFC 4888, July 2007. 1059 [9] ICAO Asia/Pacific Regional Office, "Required Communication 1060 Performance (RCP) Concepts - An Introduction", Informal South 1061 Pacific ATS Coordinating Group 20th meeting, Agenda Item 7, 1062 January 2006. 1064 [10] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility 1065 Route Optimization Solution Space Analysis", RFC 4889, 1066 July 2007. 1068 [11] Kempf, J., "Goals for Network-Based Localized Mobility 1069 Management (NETLMM)", RFC 4831, April 2007. 1071 [12] Dul, A., "Global IP Network Mobility", presentation at IETF 62 1072 plenary , March 2005. 1074 [13] Ivancic, W., Paulsen, P., Stewart, D., Shell, D., Wood, L., 1075 Jackson, C., Hodgson, D., Northam, J., Bean, N., Miller, E., 1076 Graves, M., and L. Kurisaki, "Secure, Network-centric 1077 Operations of a Space-based Asset: Cisco Router in Low Earth 1078 Orbit (CLEO) and Virtual Mission Operations Center (VMOC)", 1079 NASA Technical Memorandum TM-2005-213556, May 2005. 1081 [14] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of 1082 Multihoming in Network Mobility Support", RFC 4980, 1083 October 2007. 1085 [15] ICAO WG-N SWG1, "Analysis of Candidate ATN IPS Mobility 1086 Solutions", Meeting #12, Working Paper 6, Bangkok, Thailand, 1087 January 2007. 1089 [16] ICAO, "Threat and Error Management (TEM) in Air Traffic 1090 Control", ICAO Preliminary Edition, October 2005. 1092 [17] Baldessari, R., "C2C-C Consortium Requirements for NEMO Route 1093 Optimization", draft-baldessari-c2ccc-nemo-req-01 (work in 1094 progress), July 2007. 1096 [18] Ng, C., "Consumer Electronics Requirements for Network Mobility 1097 Route Optimization", draft-ng-nemo-ce-req-00 (work in 1098 progress), July 2007. 1100 [19] CCSDS, "Cislunar Space Internetworking: Architecture", CCCSDS 1101 000.0-G-1 Draft Green Book, December 2006. 1103 [20] NASA Space Communication Architecture Working Group, "NASA 1104 Space Communication and Navigation Architecture Recommendations 1105 for 2005-2030", SCAWG Final Report, May 2006. 1107 Appendix A. Basics of IP-based Aeronautical Networking 1109 The current standards for aeronautical networking are based on the 1110 ISO OSI networking stack and are referred to as the Aeronautical 1111 Telecommunications Network (ATN). While standardized, the ATN has 1112 not been fully deployed and seems to be in only limited use compared 1113 to its full vision and potential. The International Civil Aviation 1114 Organization (ICAO) is a part of the United Nations that produces 1115 standards for aeronautical communications. The ICAO has recognized 1116 that an ATN based on OSI lacks the widespread commercial network 1117 support required for the successful deployment of new more bandwidth- 1118 intensive ATN applications, and has recently been working towards a 1119 new IP-based version of the ATN. 1121 Supporting mobility in an IP-based network may be vastly different 1122 than it is in the OSI-based ATN which uses the Inter-Domain Routing 1123 Protocol (IDRP) to recompute routing tables as mobile networks change 1124 topological points of attachment. ICAO recognizes this and has 1125 studied various mobility techniques based on link, network, 1126 transport, routing, and application protocols [15]. 1128 Work done within ICAO has identified the NEMO technology as a 1129 promising candidate for use in supporting global IP-based mobile 1130 networking. The main concerns with NEMO have been with its current 1131 lack of route optimization support and its potentially complex 1132 configuration requirements in a large airport environment with 1133 multiple service providers and 25 or more airlines sharing the same 1134 infrastructure. 1136 Appendix B. Basics of IP-based Space Networking 1138 IP itself is only in limited operational use for communicating with 1139 spacecraft currently (e.g. the Surry Satellite Technology Limited 1140 (SSTL) Disaster Monitoring Constellation (DMC) satellites are one 1141 example). Future communications architectures include IP-based 1142 networking as an essential building-block, however. The Consultative 1143 Committee for Space Data Systems (CCSDS) has a working group that is 1144 producing a network architecture for using IP-based communications in 1145 both manned and unmanned near-Earth missions, and has international 1146 participation towards this goal [19]. NASA's Space Communications 1147 Architecture Working Group (SCAWG) also has developed an IP-based 1148 multi-mission networking architecture [20]. Neither of these is 1149 explicitly based on Mobile IP technologies, but NEMO is usable within 1150 these architectures, and they may be extended to include NEMO when/if 1151 the need becomes apparent. 1153 Authors' Addresses 1155 Wesley M. Eddy 1156 Verizon Federal Network Systems 1157 NASA Glenn Research Center 1158 21000 Brookpark Road, MS 54-5 1159 Cleveland, OH 44135 1160 USA 1162 Email: weddy@grc.nasa.gov 1164 Will Ivancic 1165 NASA Glenn Research Center 1166 21000 Brookpark Road, MS 54-5 1167 Cleveland, OH 44135 1168 USA 1170 Phone: +1-216-433-3494 1171 Email: William.D.Ivancic@grc.nasa.gov 1172 Terry Davis 1173 Boeing Commercial Airplanes 1174 P.O.Box 3707 MC 07-25 1175 Seattle, WA 98124-2207 1176 USA 1178 Phone: 206-280-3715 1179 Email: Terry.L.Davis@boeing.com 1181 Full Copyright Statement 1183 Copyright (C) The IETF Trust (2008). 1185 This document is subject to the rights, licenses and restrictions 1186 contained in BCP 78, and except as set forth therein, the authors 1187 retain all their rights. 1189 This document and the information contained herein are provided on an 1190 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1191 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1192 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1193 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1194 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1195 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1197 Intellectual Property 1199 The IETF takes no position regarding the validity or scope of any 1200 Intellectual Property Rights or other rights that might be claimed to 1201 pertain to the implementation or use of the technology described in 1202 this document or the extent to which any license under such rights 1203 might or might not be available; nor does it represent that it has 1204 made any independent effort to identify any such rights. Information 1205 on the procedures with respect to rights in RFC documents can be 1206 found in BCP 78 and BCP 79. 1208 Copies of IPR disclosures made to the IETF Secretariat and any 1209 assurances of licenses to be made available, or the result of an 1210 attempt made to obtain a general license or permission for the use of 1211 such proprietary rights by implementers or users of this 1212 specification can be obtained from the IETF on-line IPR repository at 1213 http://www.ietf.org/ipr. 1215 The IETF invites any interested party to bring to its attention any 1216 copyrights, patents or patent applications, or other proprietary 1217 rights that may cover technology that may be required to implement 1218 this standard. Please address the information to the IETF at 1219 ietf-ipr@ietf.org. 1221 Acknowledgment 1223 Funding for the RFC Editor function is provided by the IETF 1224 Administrative Support Activity (IASA).