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