idnits 2.17.1 draft-ietf-mext-aero-reqs-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 and authors 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 (January 20, 2009) is 5573 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '3' is defined on line 1198, 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 (==), 4 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: July 24, 2009 NASA 6 T. Davis 7 Boeing 8 January 20, 2009 10 NEMO Route Optimization Requirements for Operational Use in Aeronautics 11 and Space Exploration Mobile Networks 12 draft-ietf-mext-aero-reqs-03 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on July 24, 2009. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. 49 Abstract 51 This document describes the requirements and desired properties of 52 NEMO Route Optimization techniques for use in global networked 53 communications systems for aeronautics and space exploration. 55 This version has been reviewed by members of the International Civil 56 Aviation Orgnanization (ICAO) and other aeronautical communications 57 standards bodies, and contributed to by a number of aeronautical 58 communications experts outside the normal IETF process. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. NEMO RO Scenarios . . . . . . . . . . . . . . . . . . . . . . 5 64 2.1. Aeronautical Communications Scenarios . . . . . . . . . . 5 65 2.2. Space Exploration Scenarios . . . . . . . . . . . . . . . 10 66 3. Required Characteristics . . . . . . . . . . . . . . . . . . . 12 67 3.1. Req1 - Separability . . . . . . . . . . . . . . . . . . . 13 68 3.2. Req2 - Multihoming . . . . . . . . . . . . . . . . . . . . 14 69 3.3. Req3 - Latency . . . . . . . . . . . . . . . . . . . . . . 15 70 3.4. Req4 - Availability . . . . . . . . . . . . . . . . . . . 16 71 3.5. Req5 - Packet Loss . . . . . . . . . . . . . . . . . . . . 17 72 3.6. Req6 - Scalability . . . . . . . . . . . . . . . . . . . . 18 73 3.7. Req7 - Efficient Signaling . . . . . . . . . . . . . . . . 19 74 3.8. Req8 - Security . . . . . . . . . . . . . . . . . . . . . 20 75 3.9. Req9 - Adaptability . . . . . . . . . . . . . . . . . . . 21 76 4. Desirable Characteristics . . . . . . . . . . . . . . . . . . 22 77 4.1. Des1 - Configuration . . . . . . . . . . . . . . . . . . . 22 78 4.2. Des2 - Nesting . . . . . . . . . . . . . . . . . . . . . . 23 79 4.3. Des3 - System Impact . . . . . . . . . . . . . . . . . . . 23 80 4.4. Des4 - VMN Support . . . . . . . . . . . . . . . . . . . . 23 81 4.5. Des5 - Generality . . . . . . . . . . . . . . . . . . . . 24 82 5. Security Considerations . . . . . . . . . . . . . . . . . . . 24 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 84 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 85 8. Changes from draft-eddy-nemo-aero-reqs-02 . . . . . . . . . . 25 86 9. Changes from draft-ietf-mext-aero-reqs-00 . . . . . . . . . . 25 87 10. Changes from draft-ietf-mext-aeor-reqs-01 . . . . . . . . . . 25 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 89 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 90 11.2. Informative References . . . . . . . . . . . . . . . . . . 26 91 Appendix A. Basics of IP-based Aeronautical Networking . . . . . 27 92 Appendix B. Basics of IP-based Space Networking . . . . . . . . . 28 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 95 1. Introduction 97 As background the NEMO terminology and NEMO goals and requirements 98 documents are suggested reading [4] [5]. The drafts produced as part 99 of the Mobile Platform Internet (MPI) effort are also of relevence, 100 and some of the material in this document is borrowed from the MPI 101 drafts [6] [7]. 103 The base NEMO standard [1] allows Mobile IPv6 [2] to be used by 104 mobile routers, although NEMO does not support Mobile IPv6's Route 105 Optimization (RO) features for mobile network nodes other than the 106 NEMO Mobile Router (MR) itself. NEMO allows mobile networks to 107 efficiently remain reachable via fixed IP address prefixes no matter 108 where they relocate within the network topology. This is 109 accomplished through the maintenance of a bidirectional tunnel 110 between a NEMO Mobile Router and a NEMO Home Agent (HA) placed at 111 some relatively stable point in the network. Corresponding Nodes 112 (CNs) that communicate with Mobile Network Nodes (MNNs) behind an MR 113 do so through the HA and MRHA tunnel in both directions. Since the 114 use of this tunnel may have significant drawbacks [8], RO techniques 115 that allow a more direct path between the CN and MR to be used are 116 highly desirable. 118 For decades, mobile networks of some form have been used for 119 communications with people and avionics equipment onboard aircraft 120 and spacecraft. These have not typically used IP, although 121 architectures are being devised and deployed based on IP in both the 122 aeronautics and space exploration communities (see Appendix A and 123 Appendix B for more information). An aircraft or spacecraft 124 generally contains many computing nodes, sensors, and other devices 125 that are possible to address individually with IPv6. This is 126 desirable to support network-centric operations concepts. Given that 127 a craft has only a small number of access links, it is very natural 128 to use NEMO MRs to localize the functions needed to manage the large 129 onboard network's reachability over the few dynamic access links. On 130 an aircraft, the nodes are arranged in multiple independent networks, 131 based on their functions. These multiple networks are required for 132 regulatory reasons to have different treatments of their air-ground 133 traffic, and often must use distinct air-ground links and service 134 providers. 136 For aeronautics, the main disadvantage of using NEMO bidirectional 137 tunnels is that airlines operate flights that traverse multiple 138 continents, and a single plane may fly around the entire world over a 139 span of a couple days. If a plane uses a static HA on a single 140 continent, then for a large percentage of the time when the plane is 141 not on the same continent as the HA, a great amount of delay is 142 imposed by using the MRHA tunnel. Avoiding the delay from 143 unnecessarily forcing packets across multiple continents is the 144 primary goal of pursuing NEMO RO for aeronautics. 146 Other properties of the aeronautics and space environments amplify 147 the known issues with NEMO bidirectional MRHA tunnels [8] even 148 further. 150 Longer routes leading to increased delay and additional 151 infrastructure load - In aeronautical networks (e.g. using Plain 152 Old Aircraft Communication Addressing and Reporting System (ACARS) 153 or ACARS over VHF Data Link (VDL) mode 2 ) the queueing delays are 154 often long due to ARQ mechanisms and underprovisioned radio links. 155 Furthermore, for aeronautical communications systems that pass 156 through geosynchronous satellites, and for space exploration, the 157 propagation delays are also long. These delays combined with the 158 additional need to cross continents in order to transport packets 159 between ground stations and CNs means that delays are already 160 quite high in aeronautical and space networks without the addition 161 of an MRHA tunnel. The increased delays caused by MRHA tunnels 162 may be unacceptable in meeting Required Communication Performance 163 [9]. 165 Increased packet overhead - Given the constrained link bandwidths 166 available in even future communications systems for aeronautics 167 and space exploration, planners are extremely adverse to header 168 overhead. Since any amount of available link capacity can be 169 utilized for extra situational awareness, science data, etc., 170 every byte of header/tunnel overhead displaces a byte of useful 171 data. 173 Increased chances of packet fragmentation - RFC 4888 identifies 174 fragmentation due to encapsulation as an artifact of tunneling. 175 While links used in the aeronautics and space domains are error- 176 prone and may cause loss of fragments on the initial/final hop(s), 177 considerations for fragmentation along the entire tunneled path 178 are the same as for the terrestrial domain. 180 Increased susceptibility to failure - The additional likelihood of 181 either a single link failure disrupting all communications or an 182 HA failure disrupting all communications is problematic when using 183 MRHA tunnels for command and control applications that require 184 high availability for safety-of-life or safety-of-mission. 186 For these reasons, an RO extension to NEMO is highly desirable for 187 use in aeronautical and space networking. In fact, a standard RO 188 mechanism may even be necessary before some planners will seriously 189 consider advancing use of the NEMO technology from experimental 190 demonstrations to operational use within their communications 191 architectures. Without an RO solution, NEMO is difficult to justify 192 for realistic operational consideration. 194 In Section 2 we describe the relevent high-level features of the 195 access and onboard networks envisioned for use in aeronautics and 196 space exploration, as they influence the properties of usable NEMO RO 197 solutions. Section 3 then lists the technical and functional 198 characteristics that are absolutely required of a NEMO RO solution 199 for these environments, while Section 4 lists some additional 200 characteristics that are desired, but not necessarily required. In 201 Appendix A and Appendix B we provide brief primers on the specific 202 operational concepts used in aeronautics and space exploration 203 respectively for IP-based network architectures. 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 207 document are to be interpreted as described in RFC 2119. Although 208 this document does not specify an actual protocol, but rather just 209 the requirements for a protocol, it still uses the RFC 2119 language 210 to make the requirements clear. 212 2. NEMO RO Scenarios 214 To motivate and drive the development of the requirements and 215 desirable features for NEMO RO solutions, in this section some 216 operational characteristics are described to explain how access 217 networks, HAs, and CNs are configured and distributed geographically 218 and topologically in aeronautical and space network architectures. 219 This may be useful in determining which classes of RO techniques 220 within the known solution space [10] are feasible. 222 2.1. Aeronautical Communications Scenarios 224 Since aircraft may be simultaneously connected to multiple ground 225 access networks using diverse technologies with different coverage 226 properties, it is difficult to say much in general about the rate of 227 changes in active access links and care-of addresses (CoAs). As one 228 data point, for using VDL mode 2 data links, the length of time spent 229 on a single access channel varies depending on the stage of flight. 230 On the airport surface, VDL mode 2 access is stable while a plane is 231 unloaded, loaded, refueled, etc., but other wired and wireless LAN 232 links (e.g. the Gatelink system) may come and go. Immediately after 233 takeoff and before landing, planes are in the terminal maneuvering 234 area for approximately 10 minutes and stably use another VDL mode 2 235 channel. During en-route flight, handovers between VDL mode 2 236 channels may occur every 30 to 60 minutes, depending on the exact 237 flight plan and layout of towers, cells, and sectors used by a 238 service provider. These handovers may result in having a different 239 access router and a change in CoA, though the use of local mobility 240 management (e.g. [11]) may limit the changes in CoA to only handovers 241 between different providers or types of data links. 243 The characteristics of a data flow between a CN and MNN varies both 244 depending on the data flow's domain, and the particular application 245 within the domain. Even within the three aeronautical domains 246 described below, there are varying classes of service that are 247 regulated differently (e.g. for emergencies versus nominal 248 operations), but this level of detail has been abstracted out for the 249 purposes of this document. It is assumed that any viable NEMO RO 250 solution will be able to support a granularity of configuration with 251 many sub-classes of traffic within each of the specific domains 252 listed here. 254 2.1.1. Air Traffic Services Domain 256 The MNNs involved in Air Traffic Services (ATS) consist of pieces of 257 avoinics hardware onboard an aircraft used to provide navigation, 258 control, and situational awareness. The applications run by these 259 MNNs are mostly critical to the safety of the lives of the passengers 260 and crew. The MNN equipment may consist of a range of devices from 261 typical laptop computers to very specialized avionics devices. These 262 MNNs will mostly be Local Fixed Nodes (LFNs), with a few Local Mobile 263 Nodes (LMNs) to support Electronic Flight Bags, for instance. It can 264 be assumed that Visiting Mobile Nodes (VMNs) are never used within 265 the ATS domain. 267 An MR used for ATS will be capable of using multiple data links (at 268 least VHF-based, satellite, HF-based, and wired), and will likely be 269 supported by a backup unit in the case of failure, leading to a case 270 of a multi-homed MR that is at least multi-interfaced and possibly 271 multi-prefixed as well, in NEMO terminology. 273 The existing ATS link technologies may be too anemic for a complete 274 IP-based ATS communications architecture. At the time of this 275 writing, the ICAO is pursuing future datalink standards that support 276 higher data rates. Part of the problem is limited spectrum, pursued 277 under ICAO ACP-WG-F, "Spectrum Management", and part of the problem 278 is the datalink protocols themselves, pursued under ICAO ACP-WG-T, 279 "Future Communications Technology". ACP-WG-T has received inputs 280 from studies on a number of potential datalink protocols including 281 B-AMC, AMACS, P34, LDL, WCDMA, and others. Different link 282 technologies may be used in different stages of flight, for instance 283 802.16 in the surface and terminal area, P34 or LDL en-route, and 284 satcom in oceanic flight. Both current and planned datalinks used 285 for PIES and/or AOS, such as the satcom links employed by Connexion 286 by Boeing support much higher data rates than current ATS links. 288 Since for ATS, the MRs and MNNs are under regulatory control and are 289 actively tested and maintained, it is not completely unreasonable to 290 assume that special patches or software be running on these devices 291 to enable NEMO RO. In fact, since these devices are accessed by 292 skilled technicians and professionals, it may tolerable be if some 293 special configuration is required for NEMO RO. Of course simplicity 294 in setup and configuration is highly preferable, however, and the 295 desirable feature labeled "Des1" below in this document prefers 296 solutions with lower configuration state and overhead. To minimize 297 costs of ownership and operations, it is also highly desirable for 298 only widely-available off-the-shelf operating systems or network 299 stacks to be required, but not a full requirement. 301 Data flows from the ATS domain may be assumed to consist mainly of 302 short transactional exchanges such as clearance requests and grants. 303 Future ATS communications are likely to include longer messages and 304 higher message frequencies for positional awareness and trajectory 305 intent of all vehicles in motion at the airport and all aircraft 306 within a thirty mile range during flight. Many of these may be 307 aircraft-to-aircraft, but the majority of current exchanges are 308 between the MNNs and a very small set of CNs within a control 309 facility at any time due to the full transfer of control as a plane 310 moves across sectors of airspace. The set of CNs may be assumed to 311 be topologically close to one another. These CNs are also involved 312 in other data flows over the same access network that the MR is 313 attached to, managing other flights within the sector. These CNs are 314 often geographically and topologically much closer to the MR in 315 comparison to a single fixed HA. 317 The MNNs and CNs used for ATS will support IP services, as IP is the 318 basis of the new ATN architecture being defined by ICAO. Some 319 current ATS ground systems run typical operating systems like 320 Solaris, Linux, and Windows on typical workstation computer hardware. 321 There is some possibility for an RO solution to require minor changes 322 to these CNs, though it is much more desirable if completely off-the- 323 shelf CN machines and operating systems can be used. Later in this 324 document, the security requirements suggest that RO might be 325 performed with mobility anchors that are topologically-close to the 326 CNs, rather than directly to CNs themselves. This could possibly 327 mean that CN modifications are not required. 329 During the course of a flight, there are several events that an RO 330 solution should consider the performance implications of: 332 Initial session creation with an ATS CN (called "Data Link Logon" 333 in the aeronautical jargon). 335 Transfer of control between ATS CNs, resulting in regional 336 differences in where the controlling CN is located. 338 Aircraft-initiated contact with a non-controlling ATS CN, which 339 may be located anywhere, without relation to the controlling CN. 341 Non-controlling ATS CN-initiated contact with the aircraft. 343 Aircraft transition between one access link to another, resulting 344 in change of CoA. 346 Concurrent use of multiple access links with different care-of 347 addresses. 349 2.1.2. Airline Operational Services Domain 351 Data flows for Airline Operational Services (AOS) are not critical to 352 the safety of the passengers or aircraft, but are needed for the 353 business operations of airlines operating flights, and may affect the 354 profitability of an airline's flights. Most of these data flows are 355 sourced by MNNs that are part of the flight management system or 356 sensor nodes on an aircraft, and are terminated at CNs located near 357 an airline's headquarters or operations center. AOS traffic may 358 include detailed electronic passenger manifests, passenger ticketing 359 and rebooking traffic, and complete electronic baggage manifests. 360 When suitable bandwidth is available (currently on the surface when 361 connected to a wired Gatelink system), "airplane health information" 362 data transfers of between 10 and several-hundred megabytes of data 363 are likely, and in the future, it is expected that the In-Flight 364 Entertainment (IFE) systems may receive movie refreshes of data (e.g. 365 television programming or recent news updates) running into the 366 multi-gigabyte range. 368 Currently, these flows are often short messages that record the 369 timing of events of a flight, engine performance data, etc., but may 370 be longer flows that upload weather or other supplementary data to an 371 aircraft. In addition, email-like interactive messaging may be used 372 at any time during a flight. For instance, messages can be exchanged 373 before landing to arrange for arrival-gate services to be available 374 for handicapped passengers, refueling, food and beverage stocking, 375 and other needs. This messaging is not limited to landing 376 preparation, though, and may occur at any stage of flight. 378 The equipment comprising these MNNs and CNs has similar 379 considerations to the equipment used for the ATS domain. A key 380 difference between ATS and AOS is that AOS data flows are routed to 381 CNs that may be much more geographically remote to the aircraft than 382 CNs used by ATS flows, as AOS CNs will probably be located at an 383 airline's corporate data center or headquarters. The AOS CNs will 384 also probably be static for the lifetime of the flight, rather than 385 dynamic like the ATS CNs. An HA used for AOS may be fairly close 386 topologically to the CNs, and RO may not be as big of a benefit for 387 AOS, since simple event logging is more typical than time-critical 388 interactive messaging. For the small number of messaging flows, 389 however, the CNs are geographically (but not necessarily 390 topologically) very close to the aircraft, though this depends on how 391 applications are written; whether they use centralized servers or 392 exchange messages directly. Additionally, since AOS communication is 393 more advisory in nature than ATS, rather than safety-critical, AOS 394 flows are less sensitive to tunnel inefficiencies than ATS flows. 395 For these reasons, in this document, we consider AOS data flow 396 concerns with RO mechanisms to not be full requirements, but instead 397 consider them under the desirable properties in Section 4. 399 Future AOS MNNs and CNs can be expected to implement IPv6 and conform 400 to the new IPv6-based ATN SARPS that ICAO is defining. AOS CNs have 401 similar hardware and software properties as described for ATS above. 403 2.1.3. Passenger Services Domain 405 The MNNs involved in the Passenger Information and Entertainment 406 Services (PIES) domain are mostly beyond the direct control of any 407 single authority. The majority of these MNNs are VMNs and personal 408 property brought onboard by passengers for the duration of a flight, 409 and thus it is unreasonable to assume that they be preloaded with 410 special software or operating systems. These MNNs run stock Internet 411 applications like web browsing, email, and file transfer, often 412 through VPN tunnels. The MNNs themselves are portable electronics 413 such as laptop computers and mobile smartphones capable of connecting 414 to an onboard wireless access network (e.g. using 802.11). To these 415 MNN devices and users, connecting to the onboard network is identical 416 to connecting to any other terrestrial "hotspot" or typical wireless 417 LAN. The MNNs are completely oblivious to the fact that this access 418 network is on an airplane and possibly moving around the globe. The 419 users are not always technically-proficient and may not be capable of 420 performing any special configuration of their MNNs or applications. 422 The largest class of PIES CNs consists of typical web servers and 423 other nodes on the public Internet. It is not reasonable to assume 424 that these can be modified specifically to support a NEMO RO scheme. 425 Presently, these CNs would be mostly IPv4-based, though an increasing 426 number of IPv6 PIES CNs are expected in the future. This document 427 does not consider the problem of IPv4-IPv6 transition, beyond the 428 assumption that either MNNs and CNs are running IPv6 or a transition 429 mechanism exists somewhere within the network. 431 A small number of PIES MNNs may be LFNs that store and distribute 432 cached media content (e.g. movies and music), or may provide gaming 433 services to passengers. Due to the great size of the data stored on 434 these LFNs compared to the anemic bandwidth available air-to-ground, 435 these LFNs will probably not attempt to communicate off-board at all 436 during the course of a flight, but will wait to update their content 437 via either high-speed links are available on the ground, or via 438 removable media inserted by the flight crew. However, if a higher 439 bandwidth link were affordably available, it might be used in-flight 440 for these purposes, but supporting this is not a requirement. Data 441 flows needed for billing passengers for access to content are 442 relatively low bandwidth and are currently done in-flight. The 443 requirements of these data flows are less stringent than those of 444 ATS, however, so they are not specifically considered here. 446 The PIES domain is not critical to safety-of-life, but is merely an 447 added comfort or business service to passengers. Since PIES 448 applications may consume much more bandwidth than the available links 449 used in other domains, the PIES MNNs may have their packets routed 450 through a separate high-bandwidth link, that is not used by the ATS 451 data flows. For instance, several service providers are planning to 452 offer passenger Internet access during flight at DSL-like rates, just 453 as the Connexion by Boeing system did. Several airlines also plan to 454 offer onboard cellular service to their passengers, possibly 455 utilizing Voice-over-IP for transport. Due to the lack of 456 criticality and the likelihood of being treated independently, in 457 this document, PIES MNN concerns are not considered as input to 458 requirements in Section 3. The RO solution should be optimized for 459 ATS and AOS needs, and consider PIES as a secondary concern. 461 With this in consideration, the PIES domain is also the most likely 462 to utilize NEMO for communications in the near-term since 463 relatatively little regulations and beaurocracy are involved in 464 deploying new technology in this domain, and IP-based PIES systems 465 have previously been developed and deployed (although not using NEMO) 466 [12]. For these reasons, PIES concerns factor heavily into the 467 desirable properties in Section 4 outside of the mandatory 468 requirements. 470 Some PIES nodes are currently using 2.5G/3G links for mobile data 471 services, and these may be able to migrate to an IP-based onboard 472 mobile network, when available. 474 2.2. Space Exploration Scenarios 476 This section describes some features of the network environments 477 found in space exploration that are relevent to selecting an 478 appropriate NEMO RO mechanism. It should be noted that IPv4-based 479 mobile routing has been demonstrated onboard the UK-DMC satellite and 480 that the documentation on this serves as a useful reference for 481 understanding some of the goals and configuration issues for certain 482 types of space use of NEMO [13]. This section assumes space use of 483 NEMO within the "near-Earth" range of space (i.e. not for 484 communications between the Earth and Mars, or other "deep-space" 485 locations). Note, that NEMO is currently being considered for use 486 out to Lunar distances. No strong distinction is made here between 487 civilian versus military use, or exploration mission versus Earth- 488 observing or other mission types; our focus is on civilian 489 exploration missions, but we believe that many of the same basic 490 concerns are relevent to these other mission types. 492 In space communications, a high degree of bandwidth asymmetry is 493 often present, with the uplink from the ground to a craft typically 494 being multiple orders of magnitude slower than the downlink from the 495 craft to the ground. This means that the RO overhead may be 496 negligible on the downlink but significant for the uplink. An RO 497 scheme that minimizes the amount of signaling from CNs to an MN is 498 desirable, since these uplinks may be low-bandwidth to begin with 499 (possibly only several kilobits per second). Since the uplink is 500 used for sending commands, it should not be blocked for long periods 501 while serializing long RO signaling packets; any RO signaling from 502 the CN to MNNs must not involve large packets. 504 For unmanned space flight, the MNNs onboard a spacecraft consist 505 almost entirely of LFN sensing devices and processing devices that 506 send telemetry and science data to CNs on the ground and actuator 507 devices that are commanded from the ground in order to control the 508 craft. Robotic lunar rovers may serve as VMNs behind an MR located 509 on a lander or orbiter, but these rovers will contain many 510 independent instruments and could probably configured as an MR and 511 LFNs instead of using a single VMN address. 513 It can be assumed that for manned spaceflight, at least, multiple MRs 514 will be present and on-line simultaneously for fast failover. These 515 will usually be multihomed over space links in diverse frequency 516 bands, and so multiple access network prefixes can be expected to be 517 in use simultaneously, especially since some links will be direct to 518 ground stations while others may be bent-pipe repeated through 519 satellite relays like TDRSS. This conforms to the (n,1,1) or (n,n,1) 520 NEMO multihoming scenarios [14]. For unmanned missions, if low 521 weight and power are more critical, it is likely that only a single 522 MR and single link/prefix may be present, conforming to the (1,1,1) 523 or (1,n,1) NEMO multihoming scenarios [14]. 525 In some modes of spacecraft operation, all communications may go 526 through a single onboard computer (or a Command and Data Handling 527 system as on the International Space Station) rather than directly to 528 the MNNs themselves, so there is only ever one MNN behind an MR that 529 is in direct contact with off-board CNs. In this case removing the 530 MR and using simple host-based Mobile IPv6 rather than NEMO is 531 possible. However, an MR is more desirable because it could be part 532 of a modular communications adapter that is used in multiple diverse 533 missions to bridge on-board buses and intelligently manage space 534 links. This is cheaper and leads to faster development time than re- 535 creating these capabilities per-mission if using simple Mobile IPv6 536 with a single Command and Data Handling node that varies widely 537 between spacecraft. Also, all visions for the future involve 538 network-centric operations where the direct addressability and 539 accessibility of end devices and data is crucial. As network-centric 540 operations become more prevalent, application of NEMO is likely to be 541 needed to increase the flexibility of data flow. 543 The MRs and MNNs onboard a spacecraft are highly-customized computing 544 platforms, and adding custom code or complex configurations in order 545 to obtain NEMO RO capabilities is feasible, although it should not be 546 assumed that any amount of code or configuration maintenance is 547 possible after launch. The RO scheme as it is initially configured 548 should continue to function throughout the lifetime of an asset. 550 For manned space flight, additional MNNs on spacesuits and astronauts 551 may be present and used for applications like two-way voice 552 conversation or video-downlink. These MNNs could be reusable and 553 reconfigured per-flight for different craft or mission network 554 designs, but it is still desirable for them to be able to 555 autoconfigure themselves and they may move between nested or non- 556 nested MRs during a mission. For instance, if astonauts move between 557 two docked spacecraft, each craft may have its own local MR and 558 wireless coverage that the suit MNNs will have to reconfigure for. 559 It is desirable if a RO solution can respond appropriately to this 560 change in locality, and not cause high levels of packet loss during 561 the transitional period. It is also likely that these MNNs will be 562 part of Personal Area Networks (PANs), and so may appear either 563 directly as MNNs behind the main MR onboard, or might have their own 564 MR within the PAN and thus create a nested (or even multi-level 565 nested) NEMO configuration. 567 3. Required Characteristics 569 This section lists requirements that specify the absolute minimal 570 technical and/or functional properties that a NEMO RO mechanism must 571 possess to be usable for aeronautical and space communications. 573 In the recent work done by the International Civial Aviation 574 Organization (ICAO) to identify viable mobility technologies for 575 providing IP services to aircraft, a set of technical criteria was 576 developed [7] [15]. The nine required characteristics listed in this 577 document can be seen as directly descended from these ICAO criteria, 578 except here we have made them much more specific and focused for the 579 NEMO technology and the problem of RO within NEMO. The original ICAO 580 criteria were more general and used for comparing the features of 581 different mobility solutions (e.g. mobility techniques based on 582 routing protocols versus transport protocols versus Mobile IP, etc.). 583 Within the text describing each requirement in this section, we 584 provide the high-level ICAO criteria from which it evolved. 586 These requirements for aeronautics are generally similar to or in 587 excess of the requirements for space exploration, so we do not add 588 any additional requirements specifically for space exploration. In 589 addition, the lack of a standards body regulating performance and 590 safety requirements for space exploration means that the requirements 591 for aviation are much easier to agree upon and base within existing 592 requirements frameworks. After consideration, we believe that the 593 set of aviation-based requirements outlined here also fully suffices 594 for space exploration. 596 It is understood that different solutions may be needed for 597 supporting different domains. This may mean either different NEMO RO 598 solutions, or different mobility solutions entirely. Divergent 599 solutions amongst the domains are acceptable, though preferably 600 avoided if possible. 602 An underlying requirement that would be assumed by the use of Mobile 603 IP technology for managing mobility (rather than a higher-layer 604 approach) is that IP addresses used both within the mobile network, 605 and by CNs to start new sessions with nodes within the mobile network 606 remain constant throughout the course of flights and operations. For 607 ATS and AOS, this allows the HoAs to serve as node identifiers, 608 rather than just locators, and for PIES it allows common persistent 609 applications (e.g. VoIP clients, VPN clients, etc.) to remain 610 connected throughout a flight. The prior aeronautical network 611 systems like the prior OSI-based ATN and Connexion by Boeing set a 612 precedent for keeping a fixed MNP, though they relied on interdomain 613 routing protocols (IDRP and BGP) to accomplish this, rather than NEMO 614 technology. This requirement applies to the selection in general of 615 a mobility managment technology, and not specifically to an RO 616 solution once NEMO has been decided on for mobility management. 618 3.1. Req1 - Separability 620 Since RO may be inappropriate for some flows, an RO scheme MUST 621 support configuration by a per-domain dynamic RO policy database. 623 Entries in this database can be similar to those used in IPsec 624 security policy databases in order to specify either bypassing or 625 utilizing RO for specific flows. 627 3.1.1. Rationale for Aeronautics - Separability 629 Even if RO is available to increase the performance of a mobile 630 network's traffic, it may not be appropriate for all flows. 632 There may also be a desire to push certain flows through the MRHA 633 path rather than perform RO to enable them to be easily recorded by a 634 central service. 636 For these reasons, an RO scheme must have the ability to be bypassed 637 by applications that desire to use bidirectional tunnels through an 638 HA. This desire could be expressed through a policy database similar 639 to the Security Policy Database used by IPsec, for instance, but the 640 specific means of signaling or configuring the expression of this 641 desire by applications is left as a detail for the specific RO 642 specifications. 644 In addition, it is expected that the use of NEMO technology is 645 decided on a per-domain basis, so that it is possible that for some 646 domains, separate MRs are used, or even non-NEMO mobility techniques. 647 This requirement for an RO policy database only applies to domains 648 that utilize NEMO. 650 This requirement was derived from ICAO's TC-1 - "The approach should 651 provide a means to define data communications that can be carried 652 only over authorized paths for the traffic type and category 653 specified by the user." 655 One suggested approach to traffic separation is multi-addressing of 656 the onboard networks, with treatment of a traffic domain determined 657 by the packet addresses used. However, there are other techniques 658 possible for meeting this requirement, and so multi-addressing is not 659 itself a requirement. The Req1 requirement we describe above is 660 intended for separating the traffic within a domain that makes use of 661 NEMO based on flow properties (e.g. short messaging flows vs. longer 662 file transfers or voice flows). 664 3.2. Req2 - Multihoming 666 An RO solution MUST support an MR having multiple interfaces, and 667 MUST allow a given domain to be bound to a specific interface. It 668 MUST be possible to use different MNPs for different domains. 670 3.2.1. Rationale for Aeronautics - Multihoming 672 Multiple factors drive a requirement for multihoming capabilities. 673 For ATS safety-of-life critical traffic, the need for high 674 availability suggests a basic multihoming requirement. The 675 regulatory and operational difficulty in deploying new systems and 676 transitioning away from old ones also implies that a mix of access 677 technologies may be in use at any given time, and may require 678 simultaneous use. Another factor is that the multiple domains of 679 applications onboard may actually be restricted in what data links 680 they are allowed to use based on regulations and policy, so at 681 certain times or locations, PIES data flows may have to use distinct 682 access links from those used by ATS data flows. 684 This drives the requirement that an RO solution MUST allow for an MR 685 to be connected to multiple access networks simultaneously and have 686 multiple CoAs in use simultaneously. The selection of a proper CoA 687 and access link to use per-packet may be either within or outside the 688 scope of the RO solution. As a minimum, if an RO solution is 689 integrable with the MONAMI6 basic extensions (i.e. registration of 690 multiple CoAs and flow bindings), and does not preclude their use, 691 then this requirement can be considered to be satisfied. 693 It is not this requirement's intention that an RO scheme itself 694 provide multihoming, but rather simply to exclude RO techniques whose 695 use is not possible in multihomed scenarios. 697 In terms of NEMO multihoming scenarios [14], it MUST be possible to 698 support at least the (n,1,n) and (n,n,n) scenarios. 700 This requirement was derived from ICAO's TC-2 - "The approach should 701 enable an aircraft to both roam between and to be simultaneously 702 connected to multiple independent air-ground networks." 704 3.3. Req3 - Latency 706 While an RO solution is in the process of setting up or 707 reconfiguring, packets of specified flows MUST be capable of using 708 the MRHA tunnel. 710 3.3.1. Rationale for Aeronautics - Latency 712 It is possible that an RO scheme may take longer to setup or involve 713 more signaling than the basic NEMO MRHA tunnel maintenance that 714 occurs during an update to the MR's active CoAs when the set of 715 usable access links changes. During this period of flux, it may be 716 important for applications to be able to immediately get packets onto 717 the ground network, especially considering that connectivity may have 718 been blocked for some period of time while link-layer and NEMO 719 proceedures for dealing with the transition occurred. Also, when an 720 application starts for the first time, the RO scheme may not have 721 previous knowledge related to the CN and may need to perform some 722 setup before an optimized path is available. If the RO scheme blocks 723 packets either through queueing or dropping while it is configuring 724 itself, this could result in unacceptable delays. 726 Thus, when transitions in the MR's set of active access links occurs, 727 the RO scheme MUST NOT block packets from using the MRHA tunnel if 728 the RO scheme requires more time to setup or configure itself than 729 the basic NEMO tunnel maintenance. Additionally, when an application 730 flow is started, the RO scheme MUST allow packets to immediately be 731 sent, perhaps without the full benefit of RO, if the RO scheme 732 requires additional time to configure a more optimal path to the CN. 734 This requirement was derived from ICAO's TC-3 - "The approach should 735 minimize latency during establishment of initial paths to an 736 aircraft, during handoff, and during transfer of individual data 737 packets." 739 3.4. Req4 - Availability 741 An RO solution MUST be compatible with network redundancy mechanisms 742 and MUST NOT prevent fall-back to the MRHA tunnel if an element in an 743 optimized path fails. 745 An RO mechanism MUST NOT add any new single point of failure for 746 communications in general. 748 3.4.1. Rationale for Aeronautics - Availability 750 A need for high availability of connectivity to ground networks 751 arises from the use of IP networking for carrying safety-of-life 752 critical traffic. For this reason, single points of failure need to 753 be avoided. If an RO solution assumes either a single MR onboard, a 754 single HA, or some similar vulnerable point, and is not usable when 755 the network includes standard reliability mechanisms for routers, 756 then the RO technique will not be acceptable. An RO solution also 757 MUST NOT itself imply a single point of failure. 759 If a failure occurs in a path selected by an RO technique, then that 760 RO technique MUST NOT prevent fallback to the MRHA path for affected 761 traffic. 763 This does not mention specific redundancy mechanisms for MRs, HAs, or 764 other networking elements, so as long as some reasonable method for 765 making each component redundant fits within the assumptions of the RO 766 mechanism, this requirement can be considered satisfied. 768 There is no intention to support "Internet-less" operation through 769 this requirement. When an MR is completely disconnected from the 770 majority of the network it is intended to communicate, including its 771 HA, there is no requirement for it to be able to retain any 772 communications involving parties outside the mobile networks managed 773 by itself. 775 This requirement was derived from ICAO's TC-4 - "The approach should 776 have high availability which includes not having a single point of 777 failure." 779 3.5. Req5 - Packet Loss 781 An RO scheme SHOULD NOT cause either loss or duplication of data 782 packets during RO path establishment, usage, or transition, above 783 that caused in the NEMO basic support case. An RO scheme MUST NOT 784 itself create non-transient losses and duplications within a packet 785 stream. 787 3.5.1. Rationale for Aeronautics - Packet Loss 789 It is possible that some RO schemes could cause data packets to be 790 lost during transitions in RO state or due to unforseen packet 791 filters along the RO-selected path. This could be difficult for an 792 application to detect and respond to in time. For this reason, an RO 793 scheme SHOULD NOT cause packets to be dropped at any point in 794 operation, when they would not normally have been dropped in a non-RO 795 configuration. 797 As an attempt at optimizing against packet loss, some techniques may 798 for some time duplicate packets sent over both the MRHA tunnel and 799 the optimized path. If this results in duplicate packets being 800 delivered to the application, this is also unacceptable 802 This requirement does not necessarily imply make-before-break in 803 transitioning between links. The intention is that during the 804 handoff period, the RO scheme itself should not produce losses (or 805 duplicates) that would not have occurred if RO had been disabled. 807 This requirement was derived from ICAO's TC-5 - "The approach should 808 not negatively impact end-to-end data integrity, for example, by 809 introducing packet loss during path establishment, handoff, or data 810 transfer." 812 It is understood that this may be a requirement that is not easily 813 implementable with regards to RO. Furthermore Req1, Separability, 814 may be sufficient in allowing loss-sensitive and duplicate-sensitive 815 flows to take the MRHA path. 817 3.6. Req6 - Scalability 819 An RO scheme MUST be simultaneously usable by the MNNs on hundreds of 820 thousands of craft without overloading the ground network or routing 821 system. This explicitly forbids injection of BGP routes into the 822 global Internet for purposes of RO. 824 3.6.1. Rationale for Aeronautics - Scalability 826 Several thousand aircraft may be in operation at some time, each with 827 perhaps several hundred MNNs onboard. The number of active 828 spacecraft using IP will be multiple orders of magnitude smaller than 829 this over at least the next decade, so the aeronautical needs are 830 more stringent in terms of scalability to large numbers of MRs. It 831 would be a non-starter if the combined use of an RO technique by all 832 of the MRs in the network caused ground networks provisioned within 833 the realm of typical long-haul private telecommunications networks 834 (like the FAA's Telecommunications Infrastructure (FTI) or NASA's 835 NISN) to be overloaded or melt-down under the RO signaling load or 836 amount of rapid path changes for multiple data flows. 838 Thus, an RO scheme MUST be simultaneously usable by the MNNs on 839 hundreds of thousands of craft without overloading the ground network 840 or routing system. The scheme must also be tolerant to the delay 841 and/or loss of initial packets which may become more pervasive in 842 future Internet routing and addressing architectures [16]. 844 Since at least one traffic domain (PIES) requires connectivity to the 845 Internet, and it is possible that the Internet would provide 846 transport for other domains at some distant point in the future, this 847 requirement explicitly forbids the use of techniques that are known 848 to scale poorly in terms of their global effects, like BGP, for the 849 purposes of RO. The previous OSI-based ATN system used IDRP and an 850 "island" concept for maintaining connectivity to the mobile network, 851 but was not tested on a large scale deployment. The Connexion by 852 Boeing system used BGP announces and withdrawls as a plane moved 853 across the globe in order to maintain connectivity [12]. This was 854 found to contribute to a significant amount of churn in the global 855 Intenet routing tables, which is undesirable for a number of reasons, 856 and must be avoided in the future. 858 This requirement was derived from ICAO's TC-6 - "The approach should 859 be scaleable to accomodate anticipated levels of aircraft equipage." 861 The specific scaling factor for the number of aircraft used in our 862 version of the requirement is an order of magnitude larger than the 863 estimated equipage cited in an ICAO draft letter-of-intent to ARIN 864 for an IPv6 prefix allocation request. There were several other 865 estimates that different groups had made, and it was felt in the IETF 866 that using a larger estimate was more conservative. It should be 867 noted that even with this difference of an order of magnitude, the 868 raw number is still several orders of magnitude lower than that of 869 cellular telephone estimated users, which might use the same protocol 870 enhancements as they have also adopted Mobile IP standards. 872 3.7. Req7 - Efficient Signaling 874 An RO scheme MUST be capable of efficient signaling in terms of both 875 size and number of individual signaling messages and the ensemble of 876 signaling messages that may simultaneously be triggered by concurrent 877 flows. 879 3.7.1. Rationale for Aeronautics - Efficient Signaling 881 The amount of bandwidth available for aeronautical and space 882 communications has historically been quite small in comparison to the 883 desired bandwidth (e.g. in the case of VDL links the bandwidth is 8 884 kbps of shared resources). This situation is expected to persist for 885 at least several more years. Links tend to be provisioned based on 886 estimates of application needs (which could well prove wrong if 887 either demand or the applications in-use themselves do not follow 888 expectations), and do not leave much room for additional networking 889 protocol overhead. Since every byte of available air-ground link 890 capacity that is used by signaling for NEMO RO is likely to delay 891 bytes of application data and reduce application throughput, it is 892 important that the NEMO RO scheme's signaling overhead scales up much 893 more slowly than the throughput of the flows RO is being performed 894 on. This way as higher-rate datalinks are deployed along with more 895 bandwidth-hungry applications, the NEMO RO scheme will be able to 896 safely be discounted in capacity planning. 898 Note that in meeting this requirement, an RO technique must be 899 efficient in both the size and number of individual messages that it 900 sends, as well as the ensemble of messages sent at one time (for 901 instance, to give RO to multiple ongoing flows following a handover) 902 in order to prevent storms of packets related to RO. 904 This requirement was derived from ICAO's TC-7 - "The approach should 905 result in throughput which accommodates anticipated levels of 906 aircraft equipage." 908 3.8. Req8 - Security 910 For the ATS/AOS domains, there are three security sub-requirements: 912 * The RO scheme MUST NOT further expose MNPs on the wireless link 913 than already is the case for NEMO basic support. 915 * The RO scheme MUST permit the receiver of a BU to validate an MR's 916 ownership of the CoAs claimed by an MR. 918 * The RO scheme MUST ensure that only explicitly authorized MRs are 919 able to perform a binding update for a specific MNP. 921 For the PIES domain, there are no additional requirements beyond 922 those of normal Internet services and the same requirements for 923 normal Mobile IPv6 RO apply. 925 3.8.1. Rationale for Aeronatics - Security 927 The security needs are fairly similar between ATS and AOS, but vary 928 widely between the ATS/AOS domains and PIES. For PIES, the traffic 929 flows are typical of terrestrial Internet use and the security 930 requirements for RO are identical to those of conventional Mobile 931 IPv6 RO. For ATS/AOS, however, there are somewhat more strict 932 requirements, along with some safe assumptions that designers of RO 933 schemes can make. Below, we describe each of these ATS/AOS issues, 934 but do not further discuss PIES RO security. 936 The first security requirement is driven by concerns expressed by ATS 937 communications engineers. The concern is with the air-ground links 938 to a craft, and their current lack of security. If an RO scheme 939 exposes the MNP to eavesdroppers on these links, it may enable 940 attackers to easily send packets towards onboard networks of crafts. 941 The RO scheme should use some reasonable form of encryption (e.g. 942 standard ESP transforms) in order to protect any new RO signalling 943 data that contains the MNP. 945 The second security requirement is driven by the greater risk of 946 flooding attacks that are started by an attacker redirecting an MNP's 947 traffic to some target victim CoA. This is somewhat worse than the 948 case for MIPv6 mobile host RO, because the MNP's traffic is 949 potentially a higher rate than that of a single mobile host's HoA. 950 To protect bindings to bogus CoAs from being sent, the RO scheme must 951 somehow validate that an MR actually possesses any CoAs that it 952 claims. In typical Mobile IPv6 RO, the return routability test 953 provides a form of validation, under certain assumptions. For the 954 purposes of aeronautics, to demonstrate ownership of the CoA, it is 955 safe to assume ingress filtering on the part of the access network 956 providers, in conjunction with the ability to correlate a BU's source 957 address and the decrypted alternate CoA at the end recipient of the 958 BU. (Note: this is particularly subject to MEXT discussion) 960 To protect against "rouge" MRs or abuse of compromised MRs, the RO 961 scheme MUST be capable of checking that an MR is actually authorized 962 to perform a binding update for a specific MNP. To meet this 963 requirement, it can be assumed that some aeronautical organization 964 authority exists who can provide the required authorization, possibly 965 in the form of a certificate that the MR possesses, signed by the 966 aeronautical authority. 968 It is also reasonable to assume trust relationshiops between each MR 969 and a number of mobility anchor points topologically near to its CNs 970 (these anchor points may be owned by the service providers), but it 971 is not reasonable to assume that trust relationships can be 972 established between an MR and any given CN itself. Within the 973 onboard networks for ATS and AOS, it is reasonable to assume that the 974 LFNs and MRs have some trust relationship. 976 It is felt by many individuals that by the time the IP-based ATN 977 grows into production use, there will be a global PKI useable for 978 ATS, though it is agreed that such a PKI does not currently exist, 979 and will take time to develop both technically and politically. This 980 PKI could permit the establishment of trust relationships among any 981 pair of ATS MNNs, MRs, or CNs through certificate paths, in contrast 982 to the more limited amount of trust relationships described in the 983 previous paragraph. While it has been suggested that early test and 984 demonstration deployments with a more limited-scale PKI deployment 985 can be used in the near-term, as a global PKI is developed, some 986 parties still feel that assuming a global PKI may be overly bold in 987 comparison to assuming trust relationships with anchor points. It is 988 always possible to scale the anchor point assumption up if a PKI 989 develops that allows the CNs themselves to become the anchor points. 990 It is not possible to go back down in the other direction if a global 991 PKI never emerges. 993 This requirement was extrapolated from ICAO's TC-8 - "The approach 994 should be secure.", and made more specific with help from the MEXT 995 working group. 997 3.9. Req9 - Adaptability 999 Applications using new transport protocols, IPsec, or new IP options 1000 MUST be possible within an RO scheme. 1002 3.9.1. Rationale for Aeronatics - Adaptability 1004 The concepts of operations are not fully developed for network- 1005 centric command and control and other uses of IP-based networks in 1006 aeronautical and space environments. The exact application 1007 protocols, data flow characteristics, and even transport protocols 1008 that will be used in either transitional and final operational 1009 concepts are not completely defined yet, and may even change with 1010 deployment experience. If the RO solution assumes that some amount 1011 of preconfiguration of flow properties (port number ranges, etc.) is 1012 required, this could make the integration of new applications or 1013 protocols difficult. An RO scheme might assume this in order to 1014 classify between flows that prefer the MRHA tunnel to an optimized 1015 path per requirement Req1, for instance, among other reasons. Since 1016 flag days or other such large-scale synchronized configuration 1017 updates are to be avoided to ensure high availability, the RO scheme 1018 MUST NOT fail on the use of unexpected higher layer protocols 1019 (transport and above). 1021 Specifically, the use of IPsec by applications MUST be possible. 1022 Security based on IPsec is widely understood and modules qualified 1023 for use in aeronautical and space exploration environments are 1024 currently available off-the-shelf. Other security frameworks may not 1025 be as attractive due to a lack of familiarity or available flight- 1026 qualified systems. If an RO solution precludes the use of IPsec by 1027 applications, this would make it undesirable or unusable. 1029 This drives the requirement that new applications, potentially using 1030 new transport protocols must be usable within an RO scheme, and MUST 1031 NOT involve global reconfiguration events for MRs. 1033 This requirement was derived from ICAO's TC-9 - "The approach should 1034 be scalable to accomodate anticipated transition to new IP-based 1035 communication protocols." 1037 4. Desirable Characteristics 1039 In this section, we identify some of the properties of the system 1040 that are not strict requirements due to either being difficult to 1041 quantify or to being features that are not immediately needed, but 1042 may provide additional benefits that would help encourage adoption. 1044 4.1. Des1 - Configuration 1046 For ATS systems, complex configurations are known to increase 1047 uncertainty in context, human error and the potential for undesirable 1048 (unsafe) states to be reached [17]. Since RO alters the 1049 communications context between an MNN and CN, it is desirable that a 1050 NEMO RO solution be as simple to configure as possible and also easy 1051 to automatically disable if an undesirable state is reached. 1053 For CNs at large airports, the Binding Cache state management 1054 functions may be simultaneously dealing with hundreds of airplanes 1055 with multiple service providers, and a volume of mobility events due 1056 to arrivals and departures. The ability to have simple interfaces 1057 for humans to access the Binding Cache configuration and alter it in 1058 case of errors are desirable, if this does not interfere with the RO 1059 protocol mechanisms themselves. 1061 4.2. Des2 - Nesting 1063 It is desirable if the RO mechanism supports RO for nested MRs, since 1064 it is possible that for PIES and astronaut spacesuits, that PANs with 1065 MRs will need to be supported. For oceanic flight, ATS and AOS may 1066 also benefit from the capability of nesting MRs between multiple 1067 planes to provide a "reachback" to terrestrial groundstations rather 1068 than relying solely on lower rate HF or satellite systems. In either 1069 case, this mode of operation is beyond current strict requirements 1070 and is merely desirable. It is also noted that there are other ways 1071 to support these communications scenarios using routing protocols or 1072 other means outside of NEMO. 1074 4.3. Des3 - System Impact 1076 Low complexity in systems engineering and configuration management is 1077 desirable in building and maintaining systems using the RO mechanism. 1078 This property may be difficult to quantify, judge, and compare 1079 between different RO techniques, but a mechanism that is perceived to 1080 have lower impact on the complexity of the network communications 1081 system should be favored over an otherwise equivalent mechanism (with 1082 regards to the requirements listed above). This is somewhat 1083 different than Des1 (Configuration), in that Des1 refers to operation 1084 and maintenance of the system once deployed, whereas Des3 is 1085 concerned with the initial design, deployment, transition, and later 1086 upgrade path of the system. 1088 4.4. Des4 - VMN Support 1090 At least LFNs MUST be supported by a viable RO solution for 1091 aeronautics, as these local nodes are within the ATS and AOS domains. 1092 If Mobile IPv6 becomes a popular technology used by portable consumer 1093 devices, VMNs within the PIES domain are expected to be numerous, and 1094 it is strongly desirable for them to be supported by the RO 1095 technique, but not strictly required. LMNs are potentially present 1096 in future space exploration scenarios, such as Moon and Mars manned 1097 exploration missions. 1099 4.5. Des5 - Generality 1101 An RO mechanism that is "general purpose", in that it is also readily 1102 usable in other contexts outside of aeronautics and space 1103 exploration, is desirable. For instance, a RO solution that is 1104 usable within VANETs [18] or consumer electronics equipment [19] 1105 could satisfy this. The goal is for the technology to be more 1106 widely-used and maintained outside the relatively-small aeronautical 1107 networking community and its vendors, in order to make acquisitions 1108 and training faster, easier, and cheaper. This could also allow 1109 aeronautical networking to possibly benefit from future RO scheme 1110 optimizations and developments whose research and development is 1111 funded and performed externally by the broader industry and academic 1112 communities. 1114 5. Security Considerations 1116 This document does not create any security concerns in and of itself. 1117 The security properties of any NEMO RO scheme that is to be used in 1118 aeronautics and space exploration are probably much more stringent 1119 than for more general NEMO use, due to the safety-of-life and/or 1120 national security issues involved. The required security properties 1121 are described under Req8 of Section 3 within this document. 1123 Under an assumption of closed and secure backbone networks, the air- 1124 ground link is the weakest portion of the network, and most 1125 suseceptible to injection of packets, flooding, and other attacks. 1126 Future air-ground data links that will use IP are being developed 1127 with link-layer security as a concern. This development can assist 1128 in meeting one of this document's listed security requirements (that 1129 MNPs not be exposed on the wireless link), but the other requirements 1130 affect the RO technology more directly without regard to the presence 1131 or absence of air-ground link-layer security. 1133 When deploying in operational networks where network layer security 1134 may be mandated (e.g. virtual private networks), the interaction 1135 between this and NEMO RO techniques should be carefully considered to 1136 ensure that the security mechanisms do not undo the route 1137 optimization by forcing packets through a less-optimal overlay or 1138 underlay. For instance, when IPsec tunnel use is required, the 1139 locations of the tunnel endpoints can force sub-optimal end-to-end 1140 paths to be taken. 1142 6. IANA Considerations 1144 This document neither creates nor updates any IANA registries. 1146 7. Acknowledgments 1148 Input from several parties is indirectly included in this document. 1149 Participants in the MPI mailing list and BoF efforts helped to shape 1150 the document. The NEMO and MONAMI6 working group participants were 1151 instrumental in completing this document. The participants in the 1152 MEXT interim meeting February 7th and 8th of 2008 in Madrid were 1153 critical in solidifying these requirements. Specific suggestions 1154 from Steve Bretmersky, Thierry Ernst, Tony Li, Jari Arkko, Phillip 1155 Watson, Roberto Baldessari, Carlos Jesus Bernardos Cano, Eivan 1156 Cerasi, Marcelo Bagnulo, Serkan Ayaz, Christian Bauer, Fred Templin, 1157 Alexandru Petrescu, Tom Henderson, and Tony Whyman were incorporated 1158 into this document. 1160 Wesley Eddy's work on this document was performed at NASA's Glenn 1161 Research Center, while in support of NASA's Advanced Communications 1162 Navigations and Surveillance Architectures and System Technologies 1163 (ACAST) project, and the NASA Space Communications Architecture 1164 Working Group (SCAWG). 1166 8. Changes from draft-eddy-nemo-aero-reqs-02 1168 Note, this section will be removed upon publication as an RFC. 1170 At the IETF70 mext the aeronautics community indicated we would 1171 change the nemo-aero-req-02 document into a mext document with 1172 little modification. This the the corresponding document. 1174 Any Undefined Acronyms have been defined during first use. 1176 9. Changes from draft-ietf-mext-aero-reqs-00 1178 As output of the MEXT interim meeting in Madrid, several requirements 1179 were re-worded for greater clarity, and the security requirements 1180 were completely rewritten. 1182 10. Changes from draft-ietf-mext-aeor-reqs-01 1184 In response to working group last call comments, a number of 1185 clarifications were made. 1187 11. References 1189 11.1. Normative References 1191 [1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 1192 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1193 January 2005. 1195 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1196 IPv6", RFC 3775, June 2004. 1198 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1199 Levels", BCP 14, RFC 2119, March 1997. 1201 11.2. Informative References 1203 [4] Ernst, T. and H-Y. Lach, "Network Mobility Support 1204 Terminology", RFC 4885, July 2007. 1206 [5] Ernst, T., "Network Mobility Support Goals and Requirements", 1207 RFC 4886, July 2007. 1209 [6] Ivancic, W., "Multi-Domained, Multi-Homed Mobile Networks", 1210 draft-ivancic-mobile-platforms-problem-00 (work in progress), 1211 September 2006. 1213 [7] Davis, T., "Mobile Internet Platform Aviation Requirements", 1214 draft-davis-mip-aviationreq-00 (work in progress), 1215 September 2006. 1217 [8] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility 1218 Route Optimization Problem Statement", RFC 4888, July 2007. 1220 [9] ICAO Asia/Pacific Regional Office, "Required Communication 1221 Performance (RCP) Concepts - An Introduction", Informal South 1222 Pacific ATS Coordinating Group 20th meeting, Agenda Item 7, 1223 January 2006. 1225 [10] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility 1226 Route Optimization Solution Space Analysis", RFC 4889, 1227 July 2007. 1229 [11] Kempf, J., "Goals for Network-Based Localized Mobility 1230 Management (NETLMM)", RFC 4831, April 2007. 1232 [12] Dul, A., "Global IP Network Mobility", presentation at IETF 62 1233 plenary , March 2005. 1235 [13] Ivancic, W., Paulsen, P., Stewart, D., Shell, D., Wood, L., 1236 Jackson, C., Hodgson, D., Northam, J., Bean, N., Miller, E., 1237 Graves, M., and L. Kurisaki, "Secure, Network-centric 1238 Operations of a Space-based Asset: Cisco Router in Low Earth 1239 Orbit (CLEO) and Virtual Mission Operations Center (VMOC)", 1240 NASA Technical Memorandum TM-2005-213556, May 2005. 1242 [14] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of 1243 Multihoming in Network Mobility Support", RFC 4980, 1244 October 2007. 1246 [15] ICAO WG-N SWG1, "Analysis of Candidate ATN IPS Mobility 1247 Solutions", Meeting #12, Working Paper 6, Bangkok, Thailand, 1248 January 2007. 1250 [16] Zhang, L. and S. Brim, "A Taxonomy for New Routing and 1251 Addressing Architecture Designs", draft-rrg-taxonomy-00 (work 1252 in progress), March 2008. 1254 [17] ICAO, "Threat and Error Management (TEM) in Air Traffic 1255 Control", ICAO Preliminary Edition, October 2005. 1257 [18] Baldessari, R., "C2C-C Consortium Requirements for NEMO Route 1258 Optimization", draft-baldessari-c2ccc-nemo-req-01 (work in 1259 progress), July 2007. 1261 [19] Ng, C., "Consumer Electronics Requirements for Network Mobility 1262 Route Optimization", draft-ng-nemo-ce-req-00 (work in 1263 progress), July 2007. 1265 [20] CCSDS, "Cislunar Space Internetworking: Architecture", CCCSDS 1266 000.0-G-1 Draft Green Book, December 2006. 1268 [21] NASA Space Communication Architecture Working Group, "NASA 1269 Space Communication and Navigation Architecture Recommendations 1270 for 2005-2030", SCAWG Final Report, May 2006. 1272 Appendix A. Basics of IP-based Aeronautical Networking 1274 The current standards for aeronautical networking are based on the 1275 ISO OSI networking stack and are referred to as the Aeronautical 1276 Telecommunications Network (ATN). While standardized, the ATN has 1277 not been fully deployed and seems to be in only limited use compared 1278 to its full vision and potential. The International Civil Aviation 1279 Organization (ICAO) is a part of the United Nations that produces 1280 standards for aeronautical communications. The ICAO has recognized 1281 that an ATN based on OSI lacks the widespread commercial network 1282 support required for the successful deployment of new more bandwidth- 1283 intensive ATN applications, and has recently been working towards a 1284 new IPv6-based version of the ATN. 1286 Supporting mobility in an IP-based network may be vastly different 1287 than it is in the OSI-based ATN which uses the Inter-Domain Routing 1288 Protocol (IDRP) to recompute routing tables as mobile networks change 1289 topological points of attachment. ICAO recognizes this and has 1290 studied various mobility techniques based on link, network, 1291 transport, routing, and application protocols [15]. 1293 Work done within ICAO has identified the NEMO technology as a 1294 promising candidate for use in supporting global IP-based mobile 1295 networking. The main concerns with NEMO have been with its current 1296 lack of route optimization support and its potentially complex 1297 configuration requirements in a large airport environment with 1298 multiple service providers and 25 or more airlines sharing the same 1299 infrastructure. 1301 Appendix B. Basics of IP-based Space Networking 1303 IP itself is only in limited operational use for communicating with 1304 spacecraft currently (e.g. the Surry Satellite Technology Limited 1305 (SSTL) Disaster Monitoring Constellation (DMC) satellites are one 1306 example). Future communications architectures include IP-based 1307 networking as an essential building-block, however. The Consultative 1308 Committee for Space Data Systems (CCSDS) has a working group that is 1309 producing a network architecture for using IP-based communications in 1310 both manned and unmanned near-Earth missions, and has international 1311 participation towards this goal [20]. NASA's Space Communications 1312 Architecture Working Group (SCAWG) also has developed an IP-based 1313 multi-mission networking architecture [21]. Neither of these is 1314 explicitly based on Mobile IP technologies, but NEMO is usable within 1315 these architectures, and they may be extended to include NEMO when/if 1316 the need becomes apparent. 1318 Authors' Addresses 1320 Wesley M. Eddy 1321 Verizon Federal Network Systems 1322 NASA Glenn Research Center 1323 21000 Brookpark Road, MS 54-5 1324 Cleveland, OH 44135 1325 USA 1327 Email: weddy@grc.nasa.gov 1329 Will Ivancic 1330 NASA Glenn Research Center 1331 21000 Brookpark Road, MS 54-5 1332 Cleveland, OH 44135 1333 USA 1335 Phone: +1-216-433-3494 1336 Email: William.D.Ivancic@grc.nasa.gov 1338 Terry Davis 1339 Boeing Commercial Airplanes 1340 P.O.Box 3707 MC 07-25 1341 Seattle, WA 98124-2207 1342 USA 1344 Phone: 206-280-3715 1345 Email: Terry.L.Davis@boeing.com