idnits 2.17.1 draft-eddy-nemo-aero-reqs-00.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 951. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 962. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 969. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 975. 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 (April 11, 2007) is 6217 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '17' is defined on line 867, but no explicit reference was found in the text -- No information found for draft-davis-mip-aviationreq - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '6') (Obsoleted by RFC 6275) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NEMO Working Group W. Eddy 3 Internet-Draft Verizon 4 Intended status: Informational W. Ivancic 5 Expires: October 13, 2007 NASA 6 T. Davis 7 Boeing 8 April 11, 2007 10 NEMO Route Optimization Requirements for Operational Use in Aeronautics 11 and Space Exploration Mobile Networks 12 draft-eddy-nemo-aero-reqs-00 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 October 13, 2007. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This document describes the requirements and desired properties of 46 NEMO Route Optimization techniques for use in global networked 47 communications systems for aeronautics and space exploration. 49 THE PRESENT VERSION OF THIS DOCUMENT HAS NOT YET BEEN OFFICIALLY 50 REVIEWED OR APPROVED BY ICAO OR ANY OTHER AERONAUTICAL OR SPACE 51 COMMUNICATIONS STANDARDS BODY. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. NEMO RO Scenarios . . . . . . . . . . . . . . . . . . . . . . 5 57 2.1. Aeronautical Communications Scenarios . . . . . . . . . . 5 58 2.2. Space Exploration Scenarios . . . . . . . . . . . . . . . 8 59 3. Required Characteristics . . . . . . . . . . . . . . . . . . . 10 60 3.1. Req1 - Separability . . . . . . . . . . . . . . . . . . . 11 61 3.2. Req2 - Multihoming . . . . . . . . . . . . . . . . . . . . 12 62 3.3. Req3 - Latency . . . . . . . . . . . . . . . . . . . . . . 12 63 3.4. Req4 - Availability . . . . . . . . . . . . . . . . . . . 13 64 3.5. Req5 - Integrity . . . . . . . . . . . . . . . . . . . . . 13 65 3.6. Req6 - Scalability . . . . . . . . . . . . . . . . . . . . 14 66 3.7. Req7 - Throughput . . . . . . . . . . . . . . . . . . . . 14 67 3.8. Req8 - Security . . . . . . . . . . . . . . . . . . . . . 15 68 3.9. Req9 - Adaptability . . . . . . . . . . . . . . . . . . . 15 69 4. Desirable Characteristics . . . . . . . . . . . . . . . . . . 16 70 4.1. Des1 - Configuration . . . . . . . . . . . . . . . . . . . 16 71 4.2. Des2 - Nesting . . . . . . . . . . . . . . . . . . . . . . 16 72 4.3. Des3 - System Impact . . . . . . . . . . . . . . . . . . . 17 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 75 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 76 8. Informative References . . . . . . . . . . . . . . . . . . . . 18 77 Appendix A. Basics of IP-based Aeronautical Networking . . . . . 19 78 Appendix B. Basics of IP-based Space Networking . . . . . . . . . 20 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 80 Intellectual Property and Copyright Statements . . . . . . . . . . 22 82 1. Introduction 84 As background the NEMO terminology and NEMO goals and requirements 85 documents are suggested reading [1] [2]. The drafts produced as part 86 of the Mobile Platform Internet (MPI) effort are also of relevence, 87 and some of the material in this document is borrowed from the MPI 88 drafts [3] [4]. 90 The base NEMO standard [5] allows Mobile IPv6 [6] to be used by 91 mobile routers, although NEMO does not support Mobile IPv6's Route 92 Optimization (RO) features. NEMO allows mobile networks to 93 efficiently remain reachable via fixed IP address prefixes no matter 94 where they relocate within the network topology. This is 95 accomplished through the maintenance of a bidirectional tunnel 96 between a NEMO Mobile Router (MR) and a NEMO Home Agent (HA) placed 97 at some relatively stable point in the network. Corresponding Nodes 98 (CNs) that communicate with Mobile Network Nodes (MNNs) behind an MR 99 do so through the HA and MRHA tunnel in both directions. Since the 100 use of this tunnel may have significant drawbacks [7], RO techniques 101 that allow a more direct path between the CN and MR to be used are 102 highly desirable. 104 For decades, mobile networks of some form have been used for 105 communications with people and avionics equipment onboard aircraft 106 and spacecraft. These have not typically used IP, although 107 architectures are being devised and deployed based on IP in both the 108 aeronautics and space exploration communities (see Appendix A and 109 Appendix B for more information). An aircraft or spacecraft 110 generally contains a network of many computing nodes, sensors, and 111 other devices that are possible to address individually with IPv6. 112 This is desirable to support network-centric operations concepts. 113 Given that a craft has only a small number of access links, it is 114 very natural to use NEMO MRs to localize the functions needed to 115 manage the large onboard network's reachability over the few dynamic 116 access links. 118 Many properties of the aeronautics and space environments amplify the 119 known issues with NEMO bidirectional MRHA tunnels [7] even further. 121 Longer routes leading to increased delay and additional 122 infrastructure load - In aeronautical networks (e.g. using Plain 123 Old ACARS or ACARS over VDL mode 2 ) the queueing delays are often 124 long due to ARQ mechanisms and underprovisioned radio links. 125 Furthermore, for aeronautical communications systems that pass 126 through geosynchronous satellites, and for space exploration, the 127 propagation delays are also long. These delays combined with the 128 additional need to cross continents in order to transport packets 129 between ground stations and CNs means that delays are already 130 quite high in aeronautical and space networks without the addition 131 of an MRHA tunnel. The increased delays caused by MRHA tunnels 132 may be unacceptable in meeting Required Communication Performance 133 [8]. 135 Increased packet overhead - Given the constrained link bandwidths 136 available in even future communications systems for aeronautics 137 and space exploration, planners are extremely adverse to header 138 overhead. Since any amount of available link capacity can be 139 utilized for extra situational awareness, science data, etc., 140 every byte of header/tunnel overhead displaces a byte of useful 141 data. 143 Increased chances of packet fragmentation - Packet fragmentation 144 exacerbates the issue with header overhead and adds to 145 unreliability and possibly the need for end-to-end retransmission 146 if fragments are lost. Since error-prone radio links are 147 sometimes used in the aeronautical and space environments, loss of 148 fragments resulting in loss of entire packets is possible. The 149 odds of packets requiring fragmentation must be minimized in 150 aeronautical and space networks. 152 Increased susceptibility to failure - The additional likelihood of 153 either a single link failure disrupting all communications or an 154 HA failure disrupting all communications is problematic when using 155 MRHA tunnels for command and control applications that require 156 high availability for safety-of-life or safety-of-mission. 158 For these reasons, an RO extension to NEMO is highly desirable for 159 use in aeronautical and space networking. In fact, a standard RO 160 mechanism may even be necessary before some planners will seriously 161 consider advancing use of the NEMO technology from experimental 162 demonstrations to operational use within their communications 163 architectures. 165 In Section 2 we describe the relevent high-level features of the 166 access and onboard networks envisioned for use in aeronautics and 167 space exploration, as they influence the properties of usable NEMO RO 168 solutions. Section 3 then lists the technical and functional 169 characteristics that are absolutely required of a NEMO RO solution 170 for these environments, while Section 4 lists some additional 171 characteristics that are desired, but not necessarily required. In 172 Appendix A and Appendix B we provide brief primers on the specific 173 operational concepts used in aeronautics and space exploration 174 respectively for IP-based network architectures. 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in RFC 2119. Although 179 this document does not specify an actual protocol, but rather just 180 the requirements for a protocol, it still uses the RFC 2119 language 181 to make the requirements clear. 183 2. NEMO RO Scenarios 185 To motivate and drive the development of the requirements and 186 desirable features for NEMO RO solutions, in this section some 187 operational characteristics are described to explain how access 188 networks, HAs, and CNs are configured and distributed geographically 189 and topologically in aeronautical and space network architectures. 191 2.1. Aeronautical Communications Scenarios 193 Since aircraft may be simultaneously connected to multiple ground 194 access networks using diverse technologies with different coverage 195 properties, it is difficult to say much in general about the rate of 196 changes in active access links and care-of addresses (CoAs). As one 197 data point, for using VDL mode 2 data links, the length of time spent 198 on a single access channel varies depending on the stage of flight. 199 On the airport surface, VDL mode 2 access is stable while a plane is 200 unloaded, loaded, refueled, etc., but other wired and wireless LAN 201 links (e.g. the Gatelink system) may come and go. Immediately after 202 takeoff and before landing, planes are in the terminal maneuvering 203 area for approximately 10 minutes and stably use another VDL mode 2 204 channel. During en-route flight, handovers between VDL mode 2 205 channels may occur every 30 to 60 minutes, depending on the exact 206 flight plan and layout of towers, cells, and sectors used by a 207 service provider. 209 The characteristics of a data flow between a CN and MNN varies both 210 depending on the data flow's domain, and the particular application 211 within the domain. 213 2.1.1. Air Traffic Services Domain 215 The MNNs involved in Air Traffic Services (ATS) consist of pieces of 216 avoinics hardware onboard an aircraft used to provide navigation, 217 control, and situational awareness. The applications run by these 218 MNNs are mostly critical to the safety of the lives of the passengers 219 and crew. The MNN equipment may consist of a range of devices from 220 typical laptop computers to very specialized avionics devices. These 221 MNNs will mostly be Local Fixed Nodes (LFNs), with a few Local Mobile 222 Nodes (LMNs) to support Electronic Flight Bags, for instance. It can 223 be assumed that Visiting Mobile Nodes (VMNs) are never used within 224 the ATS domain. 226 An MR used for ATS will be capable of using multiple data links (at 227 least VHF-based, satellite, HF-based, and wired), and will likely be 228 supported by a backup unit in the case of failure, leading to a case 229 of a multi-homed MR that is at least multi-interfaced and possibly 230 multi-prefixed as well, in NEMO terminology. 232 Since for ATS, the MRs and MNNs are under regulatory control and are 233 actively tested and maintained, it is not unreasonable to assume that 234 special patches or software be running on these devices to enable 235 NEMO RO. In fact, since these devices are accessed by skilled 236 technicians and professionals, it may be acceptable even if complex 237 configuration is required for NEMO RO. Of course simplicity in setup 238 and configuration is desirable, however. 240 Data flows from the ATS domain may be assumed to consist mainly of 241 short transactional exchanges such as clearance requests and grants. 242 The majority of these exchanges are between the MNNs and a very small 243 set of CNs at any time due to the full transfer of control as a plane 244 moves across sectors of airspace. The set of CNs may be assumed to 245 all share the same network prefix. These CNs are also involved in 246 other data flows over the same access network that the MR is attached 247 to, managing other flights within the sector. These CNs are often 248 geographically and topologically much closer to the MR in comparison 249 to a single fixed HA. 251 2.1.2. Airline Operational Services Domain 253 Data flows for Airline Operational Services (AOS) are not critical to 254 the safety of the passengers or aircraft, but are needed for the 255 business operations of airlines operating flights, and may affect the 256 profitability of an airline's flights. Most of these data flows are 257 sourced by MNNs that are part of the flight management system or 258 sensor nodes on an aircraft, and are terminated at CNs located near 259 an airline's headquarters. These flows are usually short messages 260 that record the timing of events of a flight, engine performance 261 data, etc., but may be longer flows that upload weather data or 262 alternate flight plans with supplementary data to an aircraft. In 263 addition, a small amount of email-like interactive messaging may be 264 used to arrange for arrival-gate services to be available for 265 handicapped passengers, refueling, etc., but are only likely to be 266 used in the terminal maneuvering area within 10 minutes of landing. 268 The equipment comprising these MNNs and CNs has similar 269 considerations to the equipment used for the ATS domain. A key 270 difference between ATS and AOS is that AOS data flows are routed to 271 CNs that may be much more geographically remote to the aircraft than 272 CNs used by ATS flows, as AOS CNs will probably be located at an 273 airline's corporate data center or headquarters. The AOS CNs will 274 also probably be static for the lifetime of the flight, rather than 275 dynamic like the ATS CNs. An HA used for AOS may be fairly close 276 topologically to the CNs, and RO may not be as big of a benefit for 277 AOS, since simple event logging is more typical than time-critical 278 interactive messaging. For the small number of messaging flows, 279 however, the CNs are geographically (but not necessarily 280 topologically) very close to the aircraft. Additionally, since AOS 281 communication is more advisory in nature than ATS, rather than 282 safety-critical, AOS flows are less sensitive to tunnel 283 inefficiencies than ATS flows. For these reasons, in this document, 284 we consider AOS data flow concerns with RO mechanisms to not be full 285 requirements, but instead consider them under the desirable 286 properties in Section 4. 288 2.1.3. Passenger Services Domain 290 The MNNs involved in the Passenger Information and Entertainment 291 Services (PIES) domain are mostly beyond the direct control of any 292 single authority. The majority of these MNNs are VMNs and personal 293 property brought onboard by passengers for the duration of a flight, 294 and thus it is unreasonable to assume that they be preloaded with 295 special software or operating systems. These MNNs run stock Internet 296 applications like web browsing, email, and file transfer, often 297 through VPN tunnels. The MNNs themselves are portable electronics 298 such as laptop computers and mobile smartphones capable of connecting 299 to an onboard wireless access network (e.g. using 802.11). To these 300 MNN devices and users, connecting to the onboard network is identical 301 to connecting to any other terrestrial "hotspot" or typical wireless 302 LAN. The MNNs are completely oblivious to the fact that this access 303 network is on an airplane and possibly moving around the globe. The 304 users are not always technically-proficient and may not be capable of 305 performing any special configuration of their MNNs or applications. 307 A small number of PIES MNNs may be LFNs that store and distribute 308 cached media content (e.g. movies and music), or may provide gaming 309 services to passengers. Due to the great size of the data stored on 310 these LFNs compared to the anemic bandwidth available air-to-ground, 311 these LFNs will probably not attempt to communicate off-board at all 312 during the course of a flight, but will wait to update their content 313 via either high-speed links are available on the ground, or via 314 removable media inserted by the flight crew. Any data flow needed 315 for billing passengers for access to content can probably also be 316 performed after landing. Since it seems like these LFNs are unlikely 317 to require off-board communications during the course of a flight, we 318 do not consider them in this document. 320 The PIES domain is not critical to safety-of-life, but is merely an 321 added comfort or business service to passengers. Since PIES 322 applications may consume much more bandwidth than the available links 323 used in other domains, the PIES MNNs may have their packets routed 324 through a separate high-bandwidth link, that is not used by the ATS 325 data flows (e.g. the Connexion by Boeing system). Due to the lack of 326 criticality and the likelihood of being treated separately, in this 327 document, PIES MNN concerns are not considered as input to 328 requirements in Section 3. 330 With this in consideration, the PIES domain is also the most likely 331 to utilize NEMO for communications in the near-term since 332 relatatively little regulations and beaurocracy are involved in 333 deploying new technology in this domain, and IP-based PIES systems 334 have previously been developed and deployed (although not using NEMO) 335 [9]. For these reasons, PIES concerns factor heavily into the 336 desirable properties in Section 4 outside of the mandatory 337 requirements. 339 2.2. Space Exploration Scenarios 341 This section describes some features of the network environments 342 found in space exploration that are relevent to selecting an 343 appropriate NEMO RO mechanism. It should be noted that IPv4-based 344 mobile routing has been demonstrated onboard the UK-DMC satellite and 345 that the documentation on this serves as a useful reference for 346 understanding some of the goals and configuration issues for certain 347 types of space use of NEMO [10]. This section assumes space use of 348 NEMO within the "near-Earth" range of space (i.e. not for 349 communications between the Earth and Mars, or other "deep-space" 350 locations). No strong distinction is made here between civilian 351 versus military use, or exploration mission versus Earth-observing or 352 other mission types; our focus is on civilian exploration missions, 353 but we believe that many of the same basic concerns are relevent to 354 these other mission types. 356 In space communications, a high degree of bandwidth asymmetry is 357 often present, with the uplink from the ground to a craft typically 358 being multiple orders of magnitude slower than the downlink from the 359 craft to the ground. This means that the RO overhead may be 360 negligible on the downlink but significant for the uplink. An RO 361 scheme that minimizes the amount of signaling from CNs to an MN is 362 desirable, since these uplinks may be low-bandwidth to begin with 363 (possibly only several kilobits per second). Since the uplink is 364 used for sending commands, it should not be blocked for long periods 365 while serializing long RO signaling packets; any RO signaling from 366 the CN to MNNs must not involve large packets. 368 For unmanned space flight, the MNNs onboard a spacecraft consist 369 almost entirely of LFN sensing devices and processing devices that 370 send telemetry and science data to CNs on the ground and actuator 371 devices that are commanded from the ground in order to control the 372 craft. Robotic lunar rovers may serve as VMNs behind an MR located 373 on a lander or orbiter, but these rovers will contain many 374 independent instruments and could probably configured as an MR and 375 LFNs instead of using a single VMN address. 377 It can be assumed that for manned spaceflight, at least, multiple MRs 378 will be present and on-line simultaneously for fast failover. These 379 will usually be multihomed over space links in diverse frequency 380 bands, and so multiple-prefixes can be expected, especially since 381 some links will be direct to ground stations while others may be 382 bent-pipe repeated through satellite relays like TDRSS. For unmanned 383 missions, if low weight and power are more critical, it is likely 384 that only a single MR and single link/prefix may be present. 386 In some modes of spacecraft operation, all communications may go 387 through a single onboard computer (or a Command and Data Handling 388 system as on the International Space Station) rather than directly to 389 the MNNs themselves, so there is only ever one MNN behind an MR that 390 is in direct contact with off-board CNs. In this case removing the 391 MR and using simple host-based Mobile IPv6 rather than NEMO is 392 possible, but an MR is more desirable because it could be part of a 393 modular communications adapter that is used in multiple diverse 394 missions to bridge on-board buses and intelligently manage space 395 links, rather than re-creating these capabilities per-mission if 396 using simple Mobile IPv6 with a single Command and Data Handling node 397 that varies widely between spacecraft. Also, all visions for the 398 future involve network-centric operations where the direct 399 addressability and accessibility of end devices and data is crucial. 400 As network-centric operations become more prevalent, application of 401 NEMO is likely to be needed to increase the flexibility of data flow. 403 The MRs and MNNs onboard a spacecraft are highly-customized computing 404 platforms, and adding custom code or complex configurations in order 405 to obtain NEMO RO capabilities is feasible, although it should not be 406 assumed that any amount of code or configuration maintenance is 407 possible after launch. The RO scheme as it is initially configured 408 should continue to function throughout the lifetime of an asset. 410 For manned space flight, additional MNNs on spacesuits and astronauts 411 may be present and used for applications like two-way voice 412 conversation or video-downlink. These MNNs could be reusable and 413 reconfigured per-flight for different craft or mission network 414 designs, but it is still desirable for them to be able to 415 autoconfigure themselves and they may move between nested or non- 416 nested MRs during a mission. For instance, if astonauts move between 417 two docked spacecraft, each craft may have its own local MR and 418 wireless coverage that the suit MNNs will have to reconfigure for. 419 It is desirable if a RO solution can respond appropriately to this 420 change in locality, and not cause high levels of packet loss during 421 the transitional period. It is also likely that these MNNs will be 422 part of Personal Area Networks (PANs), and so may appear either 423 directly as MNNs behind the main MR onboard, or might have their own 424 MR within the PAN and thus create a nested (or even multi-level 425 nested) NEMO configuration. 427 3. Required Characteristics 429 This section lists requirements that specify the absolute minimal 430 technical and/or functional properties that a NEMO RO mechanism must 431 possess to be usable for aeronautical and space communications. 433 In the recent work done by the International Civial Aviation 434 Organization (ICAO) to identify viable mobility technologies for 435 providing IP services to aircraft, a set of technical criteria was 436 developed [4] [11]. The nine required characteristics listed in this 437 document can be seen as directly descended from these ICAO criteria, 438 except made much more specific and focused for the NEMO technology, 439 whereas the ICAO criteria were very general for comparing the 440 features of different solutions (e.g. mobility techniques based on 441 routing protocols versus transport protocols versus Mobile IP, etc.). 442 Within the text describing each requirement in this section, we 443 provide the high-level ICAO criteria from which it evolved. 445 The one-line summarized requirements that are discussed in this 446 section are: 448 Req1 - An RO scheme MUST have the ability to be bypassed by 449 applications that desire to use bidirectional tunnels through an 450 HA. (Separability) 452 Req2 - RO schemes MUST allow an MR to be simultaneously connected 453 to multiple access networks, having multiple prefixes and Care-Of 454 Addresses in a MONAMI6 context. (Multihoming) 456 Req3 - An RO solution MUST be capable of configuring and 457 reconfiguring itself without blocking unoptimized packet flow 458 during its initiation and before or after transitions in the 459 active access links. (Latency) 461 Req4 - An RO solution MUST NOT imply a single point of failure, 462 whether that be a single MR, or other point within the ground 463 network. (Availability) 464 Req5 - An RO scheme MUST NOT cause packets to be dropped at any 465 point in operation, when they would not normally have been dropped 466 in a non-RO configuration. (Integrity) 468 Req6 - An RO scheme MUST be simultaneously usable by ten thousand 469 nodes without overloading the ground network or routing system. 470 (Scalability) 472 Req7 - An RO scheme MUST be capable of operating on traffic 473 streams with individual rates up to 5 Mbps, and aggregates of 50 474 Mbps, while accounting for less than 9.6 kbps of bandwidth for its 475 own signaling overhead. (Throughput) 477 Req8 - IPsec MUST be usable over the RO scheme, and the data used 478 to make RO decisions MUST be authenticable using some form of 479 IPsec. (Security) 481 Req9 - New applications, potentially using new transport protocols 482 or IP options MUST be possible within an RO scheme. 483 (Adaptability) 485 These requirements for aeronautics are generally similar to or in 486 excess of the requirements for space exploration, so we do not add 487 any additional requirements specifically for space exploration. In 488 addition, the lack of a standards body regulating performance and 489 safety requirements for space exploration means that the requirements 490 for aviation are much easier to agree upon and base within existing 491 requirements frameworks. After consideration, we believe that the 492 set of aviation-based requirements outlined here also fully suffices 493 for space exploration. 495 3.1. Req1 - Separability 497 For some traffic, there may be a concern with taking the path 498 selected by a RO mechanism, since this may be considered a less 499 trustworthy or less reliable path for some reason than the MRHA 500 tunnel that represents a more-known quantity, or for capacity 501 properties or regulatory reasons. This is not to say that the RO- 502 selected path really is less safe to use, just that it may be 503 perceived as such due to a lack of prior probing or unknown 504 information about its delay or capacity properties. Since the MRHA 505 tunnel's path has known properties, it may be preferred over an 506 unknown RO-selected path for certain restricted classes of data flows 507 (e.g. ATS or spacecraft command and control). 509 For this reason, an RO scheme must have the ability to be bypassed by 510 applications that desire to use bidirectional tunnels through an HA. 511 This desire could be expressed through a policy database similar to 512 the Security Policy Database used by IPsec, for instance, but the 513 specific means of signaling or configuring the expression of this 514 desire by applications is left as a detail for the specific RO 515 specifications. 517 This requirement was derived from ICAO's TC-1 - "The approach should 518 provide a means to define data communications that can be carried 519 only over authorized paths for the traffic type and category 520 specified by the user." 522 3.2. Req2 - Multihoming 524 Multiple factors drive a requirement for multihoming capabilities. 525 For ATS safety-of-life critical traffic, the need for high 526 availability suggests a basic multihoming requirement. The 527 regulatory and operational difficulty in deploying new systems and 528 transitioning away from old ones also implies that a mix of access 529 technologies may be in use at any given time, and may require 530 simultaneous use. Another factor is that the multiple domains of 531 applications onboard may actually be restricted in what data links 532 they are allowed to use based on regulations and policy, so at 533 certain times or locations, PIES data flows may have to use distinct 534 access links from those used by ATS data flows. 536 This drives the requirement that an RO solution MUST allow for an MR 537 to be connected to multiple access networks simultaneously and have 538 multiple CoAs in use simultaneously. The selection of a proper CoA 539 and access link to use per-packet may be either within or outside the 540 scope of the RO solution. As a minimum, if an RO solution is 541 integrable with the MONAMI6 basic extensions, and does not preclude 542 their use, then this requirement can be considered to be satisfied. 544 This requirement was derived from ICAO's TC-2 - "The approach should 545 enable an aircraft to both roam between and to be simultaneously 546 connected to multiple independent air-ground networks." 548 3.3. Req3 - Latency 550 It is possible that an RO scheme may take longer to setup or involve 551 more signaling than the basic NEMO MRHA tunnel maintenance that 552 occurs during an update to the MR's active CoAs when the set of 553 usable access links changes. During this period of flux, it may be 554 important for applications to be able to immediately get packets onto 555 the ground network, especially considering that connectivity may have 556 been blocked for some period of time while link-layer and NEMO 557 proceedures for dealing with the transition occurred. Also, when an 558 application starts for the first time, the RO scheme may not have 559 previous knowledge related to the CN and may need to perform some 560 setup before an optimized path is available. If the RO scheme blocks 561 packets either through queueing or dropping while it is configuring 562 itself, this could result in unacceptable delays. 564 Thus, when transitions in the MR's set of active access links occurs, 565 the RO scheme MUST NOT block packets from using the MRHA tunnel if 566 the RO scheme requires more time to setup or configure itself than 567 the basic NEMO tunnel maintenance. Additionally, when an application 568 flow is started, the RO scheme MUST allow packets to immediately be 569 sent, perhaps without the full benefit of RO, if the RO scheme 570 requires additional time to configure a more optimal path to the CN. 572 This requirement was derived from ICAO's TC-3 - "The approach should 573 minimize latency during establishment of initial paths to an 574 aircraft, during handoff, and during transfer of individual data 575 packets." 577 3.4. Req4 - Availability 579 A need for high availability of connectivity to ground networks 580 arises from the use of IP networking for carrying safety-of-life 581 critical traffic. For this reason, single points of failure need to 582 be avoided. If an RO solution assumes either a single MR onboard, a 583 single HA, or some similar vulnerable point, and is not usable when 584 redundant elements are present and in use then it will not be 585 acceptable. An RO solution also MUST NOT itself imply a single point 586 of failure. 588 This does not mention specific redundancy mechanisms for MRs, HAs, or 589 other networking elements, so as long as some reasonable method for 590 making each component redundant fits within the assumptions of the RO 591 mechanism, this requirement can be considered satisfied. 593 This requirement was derived from ICAO's TC-4 - "The approach should 594 have high availability which includes not having a single point of 595 failure." 597 3.5. Req5 - Integrity 599 It is possible that some RO schemes could cause data packets to be 600 lost during transitions in RO state or due to unforseen packet 601 filters along the RO-selected path. This could be difficult for an 602 application to detect and respond to in time. For this reason, an RO 603 scheme MUST NOT cause packets to be dropped at any point in 604 operation, when they would not normally have been dropped in a non-RO 605 configuration. If duplicating a small number of packets sent over 606 both the MRHA tunnel and the optimized path is possible until the 607 optimized path can be verified to function for a particular data 608 flow, then this could be sufficient to meet this requirement (it is 609 safe to assume that the applications are robust to this duplication). 611 This requirement does not necessarily imply make-before-break in 612 transitioning between links. The intention is that during the 613 handoff period, the RO scheme itself should not produce losses that 614 would not have occurred if RO had been disabled. 616 This requirement was derived from ICAO's TC-5 - "The approach should 617 not negatively impact end-to-end data integrity, for example, by 618 introducing packet loss during path establishment, handoff, or data 619 transfer." 621 3.6. Req6 - Scalability 623 Several thousand aircraft may be in operation at some time, each with 624 perhaps several hundred MNNs onboard. The number of active 625 spacecraft using IP will be multiple orders of magnitude smaller than 626 this over at least the next decade, so the aeronautical needs are 627 more stringent in terms of scalability to large numbers of MRs. It 628 would be a non-starter if the combined use of an RO technique by all 629 of the MRs in the network caused ground networks provisioned within 630 the realm of typical long-haul private telecommunications networks 631 (like the FAA's Telecommunications Infrastructure (FTI) or NASA's 632 NISN) to be overloaded or melt-down under the RO signaling load or 633 amount of rapid path changes for multiple data flows. 635 Thus, an RO scheme MUST be simultaneously usable by ten thousand 636 nodes without overloading the ground network or routing system. 638 This requirement was derived from ICAO's TC-6 - "The approach should 639 be scaleable to accomodate anticipated levels of aircraft equipage." 641 3.7. Req7 - Throughput 643 The amount of bandwidth available for aeronautical and space 644 communications has historically been quite small in comparison to the 645 desired bandwidth. This situation is expected to persist for at 646 least several more years. Links tend to be provisioned based on 647 estimates of application needs (which could well prove wrong if 648 either demand or the applications in-use themselves do not follow 649 expectations), and do not leave much room for additional networking 650 protocol overhead. Since every byte of available air-ground link 651 capacity that is used by signaling for NEMO RO is likely to delay 652 bytes of application data and reduce application throughput, it is 653 important that the NEMO RO scheme's signaling overhead scales up much 654 more slowly than the throughput of the flows RO is being performed 655 on. This way as higher-rate datalinks are deployed along with more 656 bandwidth-hungry applications, the NEMO RO scheme will be able to 657 safely be discounted in capacity planning. 659 If the bandwidth needed for NEMO RO signaling is constant, or 660 irrespective of the application data rate for flows using RO, then 661 this requirement is satisfied. If the bandwidth needed grows with 662 the application data rate, but with an asymptotically slower rate of 663 growth, this is also acceptable (for instance, if the application 664 data rate doubles, but the RO signaling overhead only increases by 665 10%). 667 The one-line summary of this requirement listed above uses specific 668 values of up to 5 Mbps for an individual flow, and 50 Mbps aggregate 669 through an MR, with a limit of 9.6 kbps used for RO signaling as a 670 target. These numbers were chosen somewhat arbitrarily simply to 671 provide a concrete and measurable requirement, and may be subject to 672 revision. 674 This requirement was derived from ICAO's TC-7 - "The approach should 675 result in throughput which accommodates anticipated levels of 676 aircraft equipage." 678 3.8. Req8 - Security 680 Security based on IPsec is widely understood and modules qualified 681 for use in aeronautical and space exploration environments are 682 currently available off-the-shelf due to the US Department of Defense 683 HAIPE work. Other security frameworks may not be as attractive due 684 to a lack of familiarity or available flight-qualified systems. If 685 an RO solution precludes the use of IPsec by applications, this would 686 make it undesirable or unusable. Likewise, since the IPsec standards 687 seem to be the only agreed upon framework for implementing packet 688 authentication and other security services, the use of IPsec to 689 authenticate or otherwise secure RO signaling and other data used in 690 the RO process is required. 692 These issues motivate the requirement that IPsec MUST be usable by 693 applications utilizing the RO scheme, and the data used to make RO 694 decisions MUST be authenticable using IPsec. 696 This requirement was extrapolated from ICAO's TC-8 - "The approach 697 should be secure." 699 3.9. Req9 - Adaptability 701 The concepts of operations are not fully developed for network- 702 centric command and control and other uses of IP-based networks in 703 aeronautical and space environments. The exact application 704 protocols, data flow characteristics, and even transport protocols 705 that will be used in either transitional and final operational 706 concepts are not completely defined yet, and may even change with 707 deployment experience. If the RO solution assumes that some amount 708 of preconfiguration of flow properties (port number ranges, etc.) is 709 required, this could make the integration of new applications or 710 protocols difficult. An RO scheme might assume this in order to 711 classify between flows that prefer the MRHA tunnel to an optimized 712 path per requirement Req1, for instance, among other reasons. Since 713 flag days or other such large-scale synchronized configuration 714 updates are to be avoided to ensure high availability, the RO scheme 715 MUST NOT fail on the use of unexpected higher layer protocols 716 (transport and above). 718 This drives the requirement that new applications, potentially using 719 new transport protocols must be usable within an RO scheme, and MUST 720 NOT involve global reconfiguration events for MRs. 722 This requirement was derived from ICAO's TC-9 - "The approach should 723 be scalable to accomodate anticipated transition to new IP-based 724 communication protocols." 726 4. Desirable Characteristics 728 In this section, we identify some of the properties of the system 729 that are not strict requirements due to either being difficult to 730 quantify or to being features that are not immediately needed, but 731 may provide additional benefits that would help encourage adoption. 733 4.1. Des1 - Configuration 735 For ATS systems, complex configurations are known to increase 736 uncertainty in context, human error and the potential for undesirable 737 (unsafe) states to be reached [12]. Since RO alters the 738 communications context between an MNN and CN, it is desirable that a 739 NEMO RO solution be as simple to configure as possible and also easy 740 to automatically disable if an undesirable state is reached. 742 4.2. Des2 - Nesting 744 It is desirable if the RO mechanism supports RO for nested MRs, since 745 it is possible that for PIES and astronaut spacesuits, that PANs with 746 MRs will need to be supported. For oceanic flight, ATS and AOS may 747 also benefit from the capability of nesting MRs between multiple 748 planes to provide a "reachback" to terrestrial groundstations rather 749 than relying solely on lower rate HF or satellite systems. In either 750 case, this mode of operation is beyond current strict requirements 751 and is merely desirable. 753 4.3. Des3 - System Impact 755 Low complexity in systems engineering and configuration management is 756 desirable in building and maintaining systems using the RO mechanism. 757 This property may be difficult to quantify, judge, and compare 758 between different RO techniques, but a mechanism that is perceived to 759 have lower impact on the complexity of the network communications 760 system should be favored over an otherwise equivalent mechanism (with 761 regards to the requirements listed above). This is somewhat 762 different than Des1 (Configuration), in that Des1 refers to operation 763 and maintenance of the system once deployed, whereas Des3 is 764 concerned with the initial design, deployment, transition, and later 765 upgrade path of the system. 767 5. Security Considerations 769 This document does not create any security concerns in and of itself. 770 The security properties of any NEMO RO scheme that is to be used in 771 aeronautics and space exploration are probably much more stringent 772 than for more general NEMO use, due to the safety-of-life and/or 773 national security issues involved. The required security properties 774 are described under Req8 of Section 3 within this document. 776 When deploying in operational networks where network layer security 777 may be mandated (e.g. virtual private networks), the interaction 778 between this and NEMO RO techniques should be carefully considered to 779 ensure that the security mechanisms do not undo the route 780 optimization by forcing packets through a less-optimal overlay or 781 underlay. 783 6. IANA Considerations 785 This document neither creates nor updates any IANA registries. 787 7. Acknowledgments 789 Input from several parties is indirectly included in this document. 790 Participants in the MPI mailing list and BoF efforts helped to shape 791 the document. The NEMO and MONAMI6 working group participants were 792 instrumental in completing this document. Specific suggestions from 793 Steve Bretmersky, Thierry Ernst, Tony Li, and Jari Arkko were 794 incorporated into this document. 796 Wesley Eddy's work on this document was performed at NASA's Glenn 797 Research Center, while in support of NASA's Advanced Communications 798 Navigations and Surveillance Architectures and System Technologies 799 (ACAST) project, and the NASA Space Communications Architecture 800 Working Group (SCAWG). 802 8. Informative References 804 [1] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 805 draft-ietf-nemo-terminology-06 (work in progress), 806 November 2006. 808 [2] Ernst, T., "Network Mobility Support Goals and Requirements", 809 draft-ietf-nemo-requirements-06 (work in progress), 810 November 2006. 812 [3] Ivancic, W., "Multi-Domained, Multi-Homed Mobile Networks", 813 draft-ivancic-mobile-platforms-problem-00 (work in progress), 814 September 2006. 816 [4] Davis, T., "Mobile Internet Platform Aviation Requirements", 817 draft-davis-mip-aviationreq-00 (work in progress), 818 September 2006. 820 [5] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 821 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 822 January 2005. 824 [6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 825 IPv6", RFC 3775, June 2004. 827 [7] Ng, C., "Network Mobility Route Optimization Problem 828 Statement", draft-ietf-nemo-ro-problem-statement-03 (work in 829 progress), September 2006. 831 [8] ICAO Asia/Pacific Regional Office, "Required Communication 832 Performance (RCP) Concepts - An Introduction", Informal South 833 Pacific ATS Coordinating Group 20th meeting, Agenda Item 7, 834 January 2006. 836 [9] Dul, A., "Global IP Network Mobility", presentation at IETF 62 837 plenary , March 2005. 839 [10] Ivancic, W., Paulsen, P., Stewart, D., Shell, D., Wood, L., 840 Jackson, C., Hodgson, D., Northam, J., Bean, N., Miller, E., 841 Graves, M., and L. Kurisaki, "Secure, Network-centric 842 Operations of a Space-based Asset: Cisco Router in Low Earth 843 Orbit (CLEO) and Virtual Mission Operations Center (VMOC)", 844 NASA Technical Memorandum TM-2005-213556, May 2005. 846 [11] ICAO WG-N SWG1, "Analysis of Candidate ATN IPS Mobility 847 Solutions", Meeting #12, Working Paper 6, Bangkok, Thailand, 848 January 2007. 850 [12] ICAO, "Threat and Error Management (TEM) in Air Traffic 851 Control", ICAO Preliminary Edition, October 2005. 853 [13] Eurocontrol, "Deliverable D3/D4 - Mobility and Security in the 854 FCS", EATM - DAP/CSP Report, January 2007. 856 [14] Eddy, W., Ivancic, W., and J. Ishac, "Analysis of IPv6 Features 857 and Usability", IPv6 Forum / North American IPv6 Task 858 Force White Paper, September 2006. 860 [15] CCSDS, "Cislunar Space Internetworking: Architecture", CCCSDS 861 000.0-G-1 Draft Green Book, December 2006. 863 [16] NASA Space Communication Architecture Working Group, "NASA 864 Space Communication and Navigation Architecture Recommendations 865 for 2005-2030", SCAWG Final Report, May 2006. 867 [17] Bradner, S., "Key words for use in RFCs to Indicate Requirement 868 Levels", BCP 14, RFC 2119, March 1997. 870 Appendix A. Basics of IP-based Aeronautical Networking 872 The current standards for aeronautical networking are based on the 873 ISO OSI networking stack and are referred to as the Aeronautical 874 Telecommunications Network (ATN). While standardized, the ATN has 875 not been fully deployed and seems to be in only limited use compared 876 to its full vision and potential. The International Civil Aviation 877 Organization (ICAO) is a part of the United Nations that produces 878 standards for aeronautical communications. The ICAO has recognized 879 that the ATN basis in OSI rather than IP was a mistake, and has 880 recently been working towards a new IP-based version of the ATN. 882 Supporting mobility in an IP-based network may be vastly different 883 than it is in the OSI-based ATN which uses the IDRP interdomain 884 routing protocol to recompute routing tables as mobile networks 885 change topological points of attachment. ICAO recognizes this and 886 has studied various mobility techniques based on link, network, 887 transport, routing, and application protocols [11]. 889 Work done within ICAO has identified the NEMO technology as a 890 promising candidate for use in supporting global IP-based mobile 891 networking. The main criticism of NEMO has been largely based on 892 concerns with IPv6 deployment [13]. Examination of the facts 893 concerning IPv6 usability reveal that these concerns are basically 894 invalid and erroneous [14]. 896 Appendix B. Basics of IP-based Space Networking 898 IP itself is only in limited operational use for communicating with 899 spacecraft currently (e.g. the SSTL DMC satellites are one example). 900 Future communications architectures include IP-based networking as an 901 essential building-block, however. The Consultative Committee for 902 Space Data Systems (CCSDS) has a working group that is producing a 903 network architecture for using IP-based communications in both manned 904 and unmanned near-Earth missions, and has international participation 905 towards this goal [15]. NASA's Space Communications Architecture 906 Working Group (SCAWG) also has developed an IP-based multi-mission 907 networking architecture [16]. Neither of these is explicitly based 908 on Mobile IP technologies, but NEMO is usable within these 909 architectures, and they may be extended to include NEMO when/if the 910 need becomes apparent. 912 Authors' Addresses 914 Wesley M. Eddy 915 Verizon Federal Network Systems 916 NASA Glenn Research Center 917 21000 Brookpark Road, MS 54-5 918 Cleveland, OH 44135 919 USA 921 Email: weddy@grc.nasa.gov 923 Will Ivancic 924 NASA Glenn Research Center 925 21000 Brookpark Road, MS 54-5 926 Cleveland, OH 44135 927 USA 929 Phone: +1-216-433-3494 930 Email: William.D.Ivancic@grc.nasa.gov 931 Terry Davis 932 Boeing Commercial Airplanes 934 Phone: 206-280-3715 935 Email: Terry.L.Davis@boeing.com 937 Full Copyright Statement 939 Copyright (C) The IETF Trust (2007). 941 This document is subject to the rights, licenses and restrictions 942 contained in BCP 78, and except as set forth therein, the authors 943 retain all their rights. 945 This document and the information contained herein are provided on an 946 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 947 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 948 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 949 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 950 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 951 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 953 Intellectual Property 955 The IETF takes no position regarding the validity or scope of any 956 Intellectual Property Rights or other rights that might be claimed to 957 pertain to the implementation or use of the technology described in 958 this document or the extent to which any license under such rights 959 might or might not be available; nor does it represent that it has 960 made any independent effort to identify any such rights. Information 961 on the procedures with respect to rights in RFC documents can be 962 found in BCP 78 and BCP 79. 964 Copies of IPR disclosures made to the IETF Secretariat and any 965 assurances of licenses to be made available, or the result of an 966 attempt made to obtain a general license or permission for the use of 967 such proprietary rights by implementers or users of this 968 specification can be obtained from the IETF on-line IPR repository at 969 http://www.ietf.org/ipr. 971 The IETF invites any interested party to bring to its attention any 972 copyrights, patents or patent applications, or other proprietary 973 rights that may cover technology that may be required to implement 974 this standard. Please address the information to the IETF at 975 ietf-ipr@ietf.org. 977 Acknowledgment 979 Funding for the RFC Editor function is provided by the IETF 980 Administrative Support Activity (IASA).