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