idnits 2.17.1 draft-ietf-mext-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 1069. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1080. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1087. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1093. 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 (December 12, 2007) is 5973 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '17' is defined on line 977, 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) == Outdated reference: A later version (-02) exists of draft-ng-nemo-ce-req-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 9 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: June 14, 2008 NASA 6 T. Davis 7 Boeing 8 December 12, 2007 10 NEMO Route Optimization Requirements for Operational Use in Aeronautics 11 and Space Exploration Mobile Networks 12 draft-ietf-mext-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 June 14, 2008. 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 This version has been review by members of the International Civil 50 Aviation Orgnanization (ICAO) and other aeronautical communications 51 standards bodies. 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 . . . . . . . . . . . . . . . 9 59 3. Required Characteristics . . . . . . . . . . . . . . . . . . . 11 60 3.1. Req1 - Separability . . . . . . . . . . . . . . . . . . . 11 61 3.2. Req2 - Multihoming . . . . . . . . . . . . . . . . . . . . 12 62 3.3. Req3 - Latency . . . . . . . . . . . . . . . . . . . . . . 13 63 3.4. Req4 - Availability . . . . . . . . . . . . . . . . . . . 13 64 3.5. Req5 - Packet Loss . . . . . . . . . . . . . . . . . . . . 14 65 3.6. Req6 - Scalability . . . . . . . . . . . . . . . . . . . . 15 66 3.7. Req7 - Efficient Signaling . . . . . . . . . . . . . . . . 15 67 3.8. Req8 - Security . . . . . . . . . . . . . . . . . . . . . 16 68 3.9. Req9 - Adaptability . . . . . . . . . . . . . . . . . . . 17 69 4. Desirable Characteristics . . . . . . . . . . . . . . . . . . 17 70 4.1. Des1 - Configuration . . . . . . . . . . . . . . . . . . . 17 71 4.2. Des2 - Nesting . . . . . . . . . . . . . . . . . . . . . . 18 72 4.3. Des3 - System Impact . . . . . . . . . . . . . . . . . . . 18 73 4.4. Des4 - VMN Support . . . . . . . . . . . . . . . . . . . . 18 74 4.5. Des5 - Generality . . . . . . . . . . . . . . . . . . . . 19 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 77 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 78 8. Changes from draft-eddy-nemo-aero-reqs-02 . . . . . . . . . . 20 79 9. Informative References . . . . . . . . . . . . . . . . . . . . 20 80 Appendix A. Basics of IP-based Aeronautical Networking . . . . . 21 81 Appendix B. Basics of IP-based Space Networking . . . . . . . . . 22 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 83 Intellectual Property and Copyright Statements . . . . . . . . . . 24 85 1. Introduction 87 As background the NEMO terminology and NEMO goals and requirements 88 documents are suggested reading [1] [2]. The drafts produced as part 89 of the Mobile Platform Internet (MPI) effort are also of relevence, 90 and some of the material in this document is borrowed from the MPI 91 drafts [3] [4]. 93 The base NEMO standard [5] allows Mobile IPv6 [6] to be used by 94 mobile routers, although NEMO does not support Mobile IPv6's Route 95 Optimization (RO) features. NEMO allows mobile networks to 96 efficiently remain reachable via fixed IP address prefixes no matter 97 where they relocate within the network topology. This is 98 accomplished through the maintenance of a bidirectional tunnel 99 between a NEMO Mobile Router (MR) and a NEMO Home Agent (HA) placed 100 at some relatively stable point in the network. Corresponding Nodes 101 (CNs) that communicate with Mobile Network Nodes (MNNs) behind an MR 102 do so through the HA and MRHA tunnel in both directions. Since the 103 use of this tunnel may have significant drawbacks [7], RO techniques 104 that allow a more direct path between the CN and MR to be used are 105 highly desirable. 107 For decades, mobile networks of some form have been used for 108 communications with people and avionics equipment onboard aircraft 109 and spacecraft. These have not typically used IP, although 110 architectures are being devised and deployed based on IP in both the 111 aeronautics and space exploration communities (see Appendix A and 112 Appendix B for more information). An aircraft or spacecraft 113 generally contains many computing nodes, sensors, and other devices 114 that are possible to address individually with IPv6. This is 115 desirable to support network-centric operations concepts. Given that 116 a craft has only a small number of access links, it is very natural 117 to use NEMO MRs to localize the functions needed to manage the large 118 onboard network's reachability over the few dynamic access links. On 119 an aircraft, the nodes are arranged in multiple independent networks, 120 based on their functions. These multiple networks are required for 121 regulatory reasons to have different treatments of their air-ground 122 traffic, and often must use distinct air-ground links and service 123 providers. 125 Many properties of the aeronautics and space environments amplify the 126 known issues with NEMO bidirectional MRHA tunnels [7] even further. 128 Longer routes leading to increased delay and additional 129 infrastructure load - In aeronautical networks (e.g. using Plain 130 Old Aircraft Communication Addressing and Reporting System (ACARS) 131 or ACARS over VHF Data Link (VDL) mode 2 ) the queueing delays are 132 often long due to ARQ mechanisms and underprovisioned radio links. 134 Furthermore, for aeronautical communications systems that pass 135 through geosynchronous satellites, and for space exploration, the 136 propagation delays are also long. These delays combined with the 137 additional need to cross continents in order to transport packets 138 between ground stations and CNs means that delays are already 139 quite high in aeronautical and space networks without the addition 140 of an MRHA tunnel. The increased delays caused by MRHA tunnels 141 may be unacceptable in meeting Required Communication Performance 142 [8]. 144 Increased packet overhead - Given the constrained link bandwidths 145 available in even future communications systems for aeronautics 146 and space exploration, planners are extremely adverse to header 147 overhead. Since any amount of available link capacity can be 148 utilized for extra situational awareness, science data, etc., 149 every byte of header/tunnel overhead displaces a byte of useful 150 data. 152 Increased chances of packet fragmentation - Packet fragmentation 153 exacerbates the issue with header overhead and adds to 154 unreliability and possibly the need for end-to-end retransmission 155 if fragments are lost. Since error-prone radio links are 156 sometimes used in the aeronautical and space environments, loss of 157 fragments resulting in loss of entire packets is possible. The 158 odds of packets requiring fragmentation must be minimized in 159 aeronautical and space networks. 161 Increased susceptibility to failure - The additional likelihood of 162 either a single link failure disrupting all communications or an 163 HA failure disrupting all communications is problematic when using 164 MRHA tunnels for command and control applications that require 165 high availability for safety-of-life or safety-of-mission. 167 For these reasons, an RO extension to NEMO is highly desirable for 168 use in aeronautical and space networking. In fact, a standard RO 169 mechanism may even be necessary before some planners will seriously 170 consider advancing use of the NEMO technology from experimental 171 demonstrations to operational use within their communications 172 architectures. Without an RO solution, NEMO is difficult to justify 173 for realistic operational consideration. 175 In Section 2 we describe the relevent high-level features of the 176 access and onboard networks envisioned for use in aeronautics and 177 space exploration, as they influence the properties of usable NEMO RO 178 solutions. Section 3 then lists the technical and functional 179 characteristics that are absolutely required of a NEMO RO solution 180 for these environments, while Section 4 lists some additional 181 characteristics that are desired, but not necessarily required. In 182 Appendix A and Appendix B we provide brief primers on the specific 183 operational concepts used in aeronautics and space exploration 184 respectively for IP-based network architectures. 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in RFC 2119. Although 189 this document does not specify an actual protocol, but rather just 190 the requirements for a protocol, it still uses the RFC 2119 language 191 to make the requirements clear. 193 2. NEMO RO Scenarios 195 To motivate and drive the development of the requirements and 196 desirable features for NEMO RO solutions, in this section some 197 operational characteristics are described to explain how access 198 networks, HAs, and CNs are configured and distributed geographically 199 and topologically in aeronautical and space network architectures. 201 2.1. Aeronautical Communications Scenarios 203 Since aircraft may be simultaneously connected to multiple ground 204 access networks using diverse technologies with different coverage 205 properties, it is difficult to say much in general about the rate of 206 changes in active access links and care-of addresses (CoAs). As one 207 data point, for using VDL mode 2 data links, the length of time spent 208 on a single access channel varies depending on the stage of flight. 209 On the airport surface, VDL mode 2 access is stable while a plane is 210 unloaded, loaded, refueled, etc., but other wired and wireless LAN 211 links (e.g. the Gatelink system) may come and go. Immediately after 212 takeoff and before landing, planes are in the terminal maneuvering 213 area for approximately 10 minutes and stably use another VDL mode 2 214 channel. During en-route flight, handovers between VDL mode 2 215 channels may occur every 30 to 60 minutes, depending on the exact 216 flight plan and layout of towers, cells, and sectors used by a 217 service provider. 219 The characteristics of a data flow between a CN and MNN varies both 220 depending on the data flow's domain, and the particular application 221 within the domain. Even within the three aeronautical domains 222 described below, there are varying classes of service that are 223 regulated differently, but this level of detail has been abstracted 224 out for the purposes of this document. It is assumed that any viable 225 NEMO RO solution will be able to support a granularity of 226 configuration with many sub-classes of traffic within each of the 227 specific domains listed here. 229 2.1.1. Air Traffic Services Domain 231 The MNNs involved in Air Traffic Services (ATS) consist of pieces of 232 avoinics hardware onboard an aircraft used to provide navigation, 233 control, and situational awareness. The applications run by these 234 MNNs are mostly critical to the safety of the lives of the passengers 235 and crew. The MNN equipment may consist of a range of devices from 236 typical laptop computers to very specialized avionics devices. These 237 MNNs will mostly be Local Fixed Nodes (LFNs), with a few Local Mobile 238 Nodes (LMNs) to support Electronic Flight Bags, for instance. It can 239 be assumed that Visiting Mobile Nodes (VMNs) are never used within 240 the ATS domain. 242 An MR used for ATS will be capable of using multiple data links (at 243 least VHF-based, satellite, HF-based, and wired), and will likely be 244 supported by a backup unit in the case of failure, leading to a case 245 of a multi-homed MR that is at least multi-interfaced and possibly 246 multi-prefixed as well, in NEMO terminology. 248 Since for ATS, the MRs and MNNs are under regulatory control and are 249 actively tested and maintained, it is not unreasonable to assume that 250 special patches or software be running on these devices to enable 251 NEMO RO. In fact, since these devices are accessed by skilled 252 technicians and professionals, it may be acceptable even if complex 253 configuration is required for NEMO RO. Of course simplicity in setup 254 and configuration is desirable, however. 256 Data flows from the ATS domain may be assumed to consist mainly of 257 short transactional exchanges such as clearance requests and grants. 258 Future ATS communications are likely to include longer messages and 259 higher message frequencies for positional awareness and trajectory 260 intent of all vehicles in motion at the airport and all aircraft 261 within a thirty mile range during flight. Many of these may be 262 aircraft-to-aircraft, but the majority of current exchanges are 263 between the MNNs and a very small set of CNs within a control 264 facility at any time due to the full transfer of control as a plane 265 moves across sectors of airspace. The set of CNs may be assumed to 266 all share the same network prefix. These CNs are also involved in 267 other data flows over the same access network that the MR is attached 268 to, managing other flights within the sector. These CNs are often 269 geographically and topologically much closer to the MR in comparison 270 to a single fixed HA. 272 2.1.2. Airline Operational Services Domain 274 Data flows for Airline Operational Services (AOS) are not critical to 275 the safety of the passengers or aircraft, but are needed for the 276 business operations of airlines operating flights, and may affect the 277 profitability of an airline's flights. Most of these data flows are 278 sourced by MNNs that are part of the flight management system or 279 sensor nodes on an aircraft, and are terminated at CNs located near 280 an airline's headquarters or operations center. AOS traffic may 281 include detailed electronic passenger manifests, passenger ticketing 282 and rebooking traffic, and complete electronic baggage manifests. 283 When suitable bandwidth is available (currently on the surface when 284 connected to a wired Gatelink system), "airplane health information" 285 data transfers of between 10 and several-hundred megabytes of data 286 are likely, and in the future, it is expected that the In-Flight 287 Entertainment (IFE) systems may receive movie refreshes of data 288 running into the gigabyte range. 290 Currently, these flows are often short messages that record the 291 timing of events of a flight, engine performance data, etc., but may 292 be longer flows that upload weather or other supplementary data to an 293 aircraft. In addition, email-like interactive messaging may be used 294 at any time during a flight. For instance, messages can be exchanged 295 before landing to arrange for arrival-gate services to be available 296 for handicapped passengers, refueling, food and beverage stocking, 297 and other needs. This messaging is not limited to landing 298 preparation, though, and may occur at any stage of flight. 300 The equipment comprising these MNNs and CNs has similar 301 considerations to the equipment used for the ATS domain. A key 302 difference between ATS and AOS is that AOS data flows are routed to 303 CNs that may be much more geographically remote to the aircraft than 304 CNs used by ATS flows, as AOS CNs will probably be located at an 305 airline's corporate data center or headquarters. The AOS CNs will 306 also probably be static for the lifetime of the flight, rather than 307 dynamic like the ATS CNs. An HA used for AOS may be fairly close 308 topologically to the CNs, and RO may not be as big of a benefit for 309 AOS, since simple event logging is more typical than time-critical 310 interactive messaging. For the small number of messaging flows, 311 however, the CNs are geographically (but not necessarily 312 topologically) very close to the aircraft. Additionally, since AOS 313 communication is more advisory in nature than ATS, rather than 314 safety-critical, AOS flows are less sensitive to tunnel 315 inefficiencies than ATS flows. For these reasons, in this document, 316 we consider AOS data flow concerns with RO mechanisms to not be full 317 requirements, but instead consider them under the desirable 318 properties in Section 4. 320 2.1.3. Passenger Services Domain 322 The MNNs involved in the Passenger Information and Entertainment 323 Services (PIES) domain are mostly beyond the direct control of any 324 single authority. The majority of these MNNs are VMNs and personal 325 property brought onboard by passengers for the duration of a flight, 326 and thus it is unreasonable to assume that they be preloaded with 327 special software or operating systems. These MNNs run stock Internet 328 applications like web browsing, email, and file transfer, often 329 through VPN tunnels. The MNNs themselves are portable electronics 330 such as laptop computers and mobile smartphones capable of connecting 331 to an onboard wireless access network (e.g. using 802.11). To these 332 MNN devices and users, connecting to the onboard network is identical 333 to connecting to any other terrestrial "hotspot" or typical wireless 334 LAN. The MNNs are completely oblivious to the fact that this access 335 network is on an airplane and possibly moving around the globe. The 336 users are not always technically-proficient and may not be capable of 337 performing any special configuration of their MNNs or applications. 339 A small number of PIES MNNs may be LFNs that store and distribute 340 cached media content (e.g. movies and music), or may provide gaming 341 services to passengers. Due to the great size of the data stored on 342 these LFNs compared to the anemic bandwidth available air-to-ground, 343 these LFNs will probably not attempt to communicate off-board at all 344 during the course of a flight, but will wait to update their content 345 via either high-speed links are available on the ground, or via 346 removable media inserted by the flight crew. Any data flow needed 347 for billing passengers for access to content can probably also be 348 performed after landing. Since it seems like these LFNs are unlikely 349 to require off-board communications during the course of a flight, we 350 do not consider them in this document. 352 The PIES domain is not critical to safety-of-life, but is merely an 353 added comfort or business service to passengers. Since PIES 354 applications may consume much more bandwidth than the available links 355 used in other domains, the PIES MNNs may have their packets routed 356 through a separate high-bandwidth link, that is not used by the ATS 357 data flows. For instance, several service providers are planning to 358 offer passenger Internet access during flight at DSL-like rates, just 359 as the Connexion by Boeing system did. Several airlines also plan to 360 offer onboard cellular service to their passengers, possibly 361 utilizing Voice-over-IP for transport. Due to the lack of 362 criticality and the likelihood of being treated independently, in 363 this document, PIES MNN concerns are not considered as input to 364 requirements in Section 3. The RO solution should be optimized for 365 ATS and AOS needs, and consider PIES as a secondary concern. 367 With this in consideration, the PIES domain is also the most likely 368 to utilize NEMO for communications in the near-term since 369 relatatively little regulations and beaurocracy are involved in 370 deploying new technology in this domain, and IP-based PIES systems 371 have previously been developed and deployed (although not using NEMO) 372 [9]. For these reasons, PIES concerns factor heavily into the 373 desirable properties in Section 4 outside of the mandatory 374 requirements. 376 Some PIES nodes are currently using 2.5G/3G links for mobile data 377 services, and these may be able to migrate to an IP-based onboard 378 mobile network, when available. 380 2.2. Space Exploration Scenarios 382 This section describes some features of the network environments 383 found in space exploration that are relevent to selecting an 384 appropriate NEMO RO mechanism. It should be noted that IPv4-based 385 mobile routing has been demonstrated onboard the UK-DMC satellite and 386 that the documentation on this serves as a useful reference for 387 understanding some of the goals and configuration issues for certain 388 types of space use of NEMO [10]. This section assumes space use of 389 NEMO within the "near-Earth" range of space (i.e. not for 390 communications between the Earth and Mars, or other "deep-space" 391 locations). Note, that NEMO is currently being considered for use 392 out to Lunar distances. No strong distinction is made here between 393 civilian versus military use, or exploration mission versus Earth- 394 observing or other mission types; our focus is on civilian 395 exploration missions, but we believe that many of the same basic 396 concerns are relevent to these other mission types. 398 In space communications, a high degree of bandwidth asymmetry is 399 often present, with the uplink from the ground to a craft typically 400 being multiple orders of magnitude slower than the downlink from the 401 craft to the ground. This means that the RO overhead may be 402 negligible on the downlink but significant for the uplink. An RO 403 scheme that minimizes the amount of signaling from CNs to an MN is 404 desirable, since these uplinks may be low-bandwidth to begin with 405 (possibly only several kilobits per second). Since the uplink is 406 used for sending commands, it should not be blocked for long periods 407 while serializing long RO signaling packets; any RO signaling from 408 the CN to MNNs must not involve large packets. 410 For unmanned space flight, the MNNs onboard a spacecraft consist 411 almost entirely of LFN sensing devices and processing devices that 412 send telemetry and science data to CNs on the ground and actuator 413 devices that are commanded from the ground in order to control the 414 craft. Robotic lunar rovers may serve as VMNs behind an MR located 415 on a lander or orbiter, but these rovers will contain many 416 independent instruments and could probably configured as an MR and 417 LFNs instead of using a single VMN address. 419 It can be assumed that for manned spaceflight, at least, multiple MRs 420 will be present and on-line simultaneously for fast failover. These 421 will usually be multihomed over space links in diverse frequency 422 bands, and so multiple-prefixes can be expected, especially since 423 some links will be direct to ground stations while others may be 424 bent-pipe repeated through satellite relays like TDRSS. For unmanned 425 missions, if low weight and power are more critical, it is likely 426 that only a single MR and single link/prefix may be present. 428 In some modes of spacecraft operation, all communications may go 429 through a single onboard computer (or a Command and Data Handling 430 system as on the International Space Station) rather than directly to 431 the MNNs themselves, so there is only ever one MNN behind an MR that 432 is in direct contact with off-board CNs. In this case removing the 433 MR and using simple host-based Mobile IPv6 rather than NEMO is 434 possible, but an MR is more desirable because it could be part of a 435 modular communications adapter that is used in multiple diverse 436 missions to bridge on-board buses and intelligently manage space 437 links, rather than re-creating these capabilities per-mission if 438 using simple Mobile IPv6 with a single Command and Data Handling node 439 that varies widely between spacecraft. Also, all visions for the 440 future involve network-centric operations where the direct 441 addressability and accessibility of end devices and data is crucial. 442 As network-centric operations become more prevalent, application of 443 NEMO is likely to be needed to increase the flexibility of data flow. 445 The MRs and MNNs onboard a spacecraft are highly-customized computing 446 platforms, and adding custom code or complex configurations in order 447 to obtain NEMO RO capabilities is feasible, although it should not be 448 assumed that any amount of code or configuration maintenance is 449 possible after launch. The RO scheme as it is initially configured 450 should continue to function throughout the lifetime of an asset. 452 For manned space flight, additional MNNs on spacesuits and astronauts 453 may be present and used for applications like two-way voice 454 conversation or video-downlink. These MNNs could be reusable and 455 reconfigured per-flight for different craft or mission network 456 designs, but it is still desirable for them to be able to 457 autoconfigure themselves and they may move between nested or non- 458 nested MRs during a mission. For instance, if astonauts move between 459 two docked spacecraft, each craft may have its own local MR and 460 wireless coverage that the suit MNNs will have to reconfigure for. 461 It is desirable if a RO solution can respond appropriately to this 462 change in locality, and not cause high levels of packet loss during 463 the transitional period. It is also likely that these MNNs will be 464 part of Personal Area Networks (PANs), and so may appear either 465 directly as MNNs behind the main MR onboard, or might have their own 466 MR within the PAN and thus create a nested (or even multi-level 467 nested) NEMO configuration. 469 3. Required Characteristics 471 This section lists requirements that specify the absolute minimal 472 technical and/or functional properties that a NEMO RO mechanism must 473 possess to be usable for aeronautical and space communications. 475 In the recent work done by the International Civial Aviation 476 Organization (ICAO) to identify viable mobility technologies for 477 providing IP services to aircraft, a set of technical criteria was 478 developed [4] [11]. The nine required characteristics listed in this 479 document can be seen as directly descended from these ICAO criteria, 480 except here we have made them much more specific and focused for the 481 NEMO technology. The original ICAO criteria were more general and 482 used for comparing the features of different mobility solutions (e.g. 483 mobility techniques based on routing protocols versus transport 484 protocols versus Mobile IP, etc.). Within the text describing each 485 requirement in this section, we provide the high-level ICAO criteria 486 from which it evolved. 488 These requirements for aeronautics are generally similar to or in 489 excess of the requirements for space exploration, so we do not add 490 any additional requirements specifically for space exploration. In 491 addition, the lack of a standards body regulating performance and 492 safety requirements for space exploration means that the requirements 493 for aviation are much easier to agree upon and base within existing 494 requirements frameworks. After consideration, we believe that the 495 set of aviation-based requirements outlined here also fully suffices 496 for space exploration. 498 3.1. Req1 - Separability 500 An RO scheme MUST have the ability to be bypassed by traffic types 501 that desire to use bidirectional tunnels through an HA. 503 3.1.1. Rationale for Aeronautics - Separability 505 For the aeronautics community there are basically three types of 506 traffic (classes of service): "critical traffic" used for air traffic 507 control and safety of flight, "signaling traffic" used for air 508 operations management, and "user traffic" used by passenger services. 510 For critical and signaling traffic, there may be a concern with 511 taking the path selected by a RO mechanism, since this may be 512 considered a less trustworthy or less reliable path for some reason 513 than the MRHA tunnel that represents a more-known quantity, or for 514 capacity properties or regulatory reasons. This is not to say that 515 the RO-selected path really is less safe to use, just that it may be 516 perceived as such due to a lack of prior probing or unknown 517 information about its delay or capacity properties. Since the MRHA 518 tunnel's path has known properties, it may be preferred over an 519 unknown RO-selected path for certain restricted classes of data flows 520 (e.g. ATS or spacecraft command and control). 522 For this reason, an RO scheme must have the ability to be bypassed by 523 applications that desire to use bidirectional tunnels through an HA. 524 This desire could be expressed through a policy database similar to 525 the Security Policy Database used by IPsec, for instance, but the 526 specific means of signaling or configuring the expression of this 527 desire by applications is left as a detail for the specific RO 528 specifications. 530 This requirement was derived from ICAO's TC-1 - "The approach should 531 provide a means to define data communications that can be carried 532 only over authorized paths for the traffic type and category 533 specified by the user." 535 3.2. Req2 - Multihoming 537 Req2 - RO schemes MUST permit an MR to be simultaneously connected to 538 multiple access networks, having multiple prefixes and Care-Of 539 Addresses in a MONAMI6 context. 541 3.2.1. Rationale for Aeronautics - Multihoming 543 Multiple factors drive a requirement for multihoming capabilities. 544 For ATS safety-of-life critical traffic, the need for high 545 availability suggests a basic multihoming requirement. The 546 regulatory and operational difficulty in deploying new systems and 547 transitioning away from old ones also implies that a mix of access 548 technologies may be in use at any given time, and may require 549 simultaneous use. Another factor is that the multiple domains of 550 applications onboard may actually be restricted in what data links 551 they are allowed to use based on regulations and policy, so at 552 certain times or locations, PIES data flows may have to use distinct 553 access links from those used by ATS data flows. 555 This drives the requirement that an RO solution MUST allow for an MR 556 to be connected to multiple access networks simultaneously and have 557 multiple CoAs in use simultaneously. The selection of a proper CoA 558 and access link to use per-packet may be either within or outside the 559 scope of the RO solution. As a minimum, if an RO solution is 560 integrable with the MONAMI6 basic extensions, and does not preclude 561 their use, then this requirement can be considered to be satisfied. 563 It is not this requirement's intention that an RO scheme itself 564 provide multihoming, but rather simply to exclude RO techniques whose 565 use is not possible in multihomed scenarios. 567 This requirement was derived from ICAO's TC-2 - "The approach should 568 enable an aircraft to both roam between and to be simultaneously 569 connected to multiple independent air-ground networks." 571 3.3. Req3 - Latency 573 Req3 - An RO solution MUST be capable of configuring itself (and 574 reconfiguring after mobility events) without blocking unoptimized 575 packet flow during its initiation and before or after transitions in 576 the active access links. 578 3.3.1. Rationale for Aeronautics - Latency 580 It is possible that an RO scheme may take longer to setup or involve 581 more signaling than the basic NEMO MRHA tunnel maintenance that 582 occurs during an update to the MR's active CoAs when the set of 583 usable access links changes. During this period of flux, it may be 584 important for applications to be able to immediately get packets onto 585 the ground network, especially considering that connectivity may have 586 been blocked for some period of time while link-layer and NEMO 587 proceedures for dealing with the transition occurred. Also, when an 588 application starts for the first time, the RO scheme may not have 589 previous knowledge related to the CN and may need to perform some 590 setup before an optimized path is available. If the RO scheme blocks 591 packets either through queueing or dropping while it is configuring 592 itself, this could result in unacceptable delays. 594 Thus, when transitions in the MR's set of active access links occurs, 595 the RO scheme MUST NOT block packets from using the MRHA tunnel if 596 the RO scheme requires more time to setup or configure itself than 597 the basic NEMO tunnel maintenance. Additionally, when an application 598 flow is started, the RO scheme MUST allow packets to immediately be 599 sent, perhaps without the full benefit of RO, if the RO scheme 600 requires additional time to configure a more optimal path to the CN. 602 This requirement was derived from ICAO's TC-3 - "The approach should 603 minimize latency during establishment of initial paths to an 604 aircraft, during handoff, and during transfer of individual data 605 packets." 607 3.4. Req4 - Availability 609 Req4 - An RO solution MUST NOT imply a single point of failure, 610 whether that be a single MR, a single HA, or other point within the 611 ground network. 613 3.4.1. Rationale for Aeronautics - Availability 615 A need for high availability of connectivity to ground networks 616 arises from the use of IP networking for carrying safety-of-life 617 critical traffic. For this reason, single points of failure need to 618 be avoided. If an RO solution assumes either a single MR onboard, a 619 single HA, or some similar vulnerable point, and is not usable when 620 redundant elements are present and in use then it will not be 621 acceptable. An RO solution also MUST NOT itself imply a single point 622 of failure. 624 This does not mention specific redundancy mechanisms for MRs, HAs, or 625 other networking elements, so as long as some reasonable method for 626 making each component redundant fits within the assumptions of the RO 627 mechanism, this requirement can be considered satisfied. 629 There is no intention to support "Internet-less" operation through 630 this requirement. When an MR is completely disconnected from the 631 majority of the network it is intended to communicate, including its 632 HA, there is no requirement for it to be able to retain any 633 communications involving parties outside the mobile networks managed 634 by itself. 636 This requirement was derived from ICAO's TC-4 - "The approach should 637 have high availability which includes not having a single point of 638 failure." 640 3.5. Req5 - Packet Loss 642 Req5 - An RO scheme MUST NOT cause packets to be dropped at any point 643 in operation, when they would not normally have been dropped in a 644 non-RO configuration. (Integrity) 646 3.5.1. Rationale for Aeronautics - Packet Loss 648 It is possible that some RO schemes could cause data packets to be 649 lost during transitions in RO state or due to unforseen packet 650 filters along the RO-selected path. This could be difficult for an 651 application to detect and respond to in time. For this reason, an RO 652 scheme MUST NOT cause packets to be dropped at any point in 653 operation, when they would not normally have been dropped in a non-RO 654 configuration. If duplicating a small number of packets sent over 655 both the MRHA tunnel and the optimized path is possible until the 656 optimized path can be verified to function for a particular data 657 flow, then this could be sufficient to meet this requirement (it is 658 safe to assume that the applications are robust to this duplication). 660 This requirement does not necessarily imply make-before-break in 661 transitioning between links. The intention is that during the 662 handoff period, the RO scheme itself should not produce losses that 663 would not have occurred if RO had been disabled. 665 This requirement was derived from ICAO's TC-5 - "The approach should 666 not negatively impact end-to-end data integrity, for example, by 667 introducing packet loss during path establishment, handoff, or data 668 transfer." 670 It is understood that this may be a requirement that is not easily 671 implementable with regards to RO. Furthermore Req1, Separability, 672 may be sufficient. In addition, the ability for a RO implementation 673 to determine the appropriate path for particular systems is probably 674 out of scope. Regardless, this requirment is currently being 675 retained in order to ensure it gets addressed in some manner via 676 either RO or elsewhere. This requirment is likely to be removed, but 677 we do not wish to loose the thought at this time. 679 3.6. Req6 - Scalability 681 Req6 - An RO scheme MUST be simultaneously usable by ten thousand 682 nodes without overloading the ground network or routing system. 684 3.6.1. Rationale for Aeronautics - Scalability 686 Several thousand aircraft may be in operation at some time, each with 687 perhaps several hundred MNNs onboard. The number of active 688 spacecraft using IP will be multiple orders of magnitude smaller than 689 this over at least the next decade, so the aeronautical needs are 690 more stringent in terms of scalability to large numbers of MRs. It 691 would be a non-starter if the combined use of an RO technique by all 692 of the MRs in the network caused ground networks provisioned within 693 the realm of typical long-haul private telecommunications networks 694 (like the FAA's Telecommunications Infrastructure (FTI) or NASA's 695 NISN) to be overloaded or melt-down under the RO signaling load or 696 amount of rapid path changes for multiple data flows. 698 Thus, an RO scheme MUST be simultaneously usable by ten thousand 699 nodes without overloading the ground network or routing system. 701 This requirement was derived from ICAO's TC-6 - "The approach should 702 be scaleable to accomodate anticipated levels of aircraft equipage." 704 3.7. Req7 - Efficient Signaling 706 An RO scheme MUST be capable of efficient signaling 708 3.7.1. Rationale for Aeronautics - Efficient Signaling 710 The amount of bandwidth available for aeronautical and space 711 communications has historically been quite small in comparison to the 712 desired bandwidth (e.g. in the case of VDL links the bandwidth is 8 713 kbps of shared resources). This situation is expected to persist for 714 at least several more years. Links tend to be provisioned based on 715 estimates of application needs (which could well prove wrong if 716 either demand or the applications in-use themselves do not follow 717 expectations), and do not leave much room for additional networking 718 protocol overhead. Since every byte of available air-ground link 719 capacity that is used by signaling for NEMO RO is likely to delay 720 bytes of application data and reduce application throughput, it is 721 important that the NEMO RO scheme's signaling overhead scales up much 722 more slowly than the throughput of the flows RO is being performed 723 on. This way as higher-rate datalinks are deployed along with more 724 bandwidth-hungry applications, the NEMO RO scheme will be able to 725 safely be discounted in capacity planning. 727 This requirement was derived from ICAO's TC-7 - "The approach should 728 result in throughput which accommodates anticipated levels of 729 aircraft equipage." 731 3.8. Req8 - Security 733 Req8 - IPsec MUST be usable over the RO scheme, and the data used to 734 make RO decisions MUST be authenticable, perhaps using some form of 735 IPsec. 737 3.8.1. Rationale for Aeronatics - Security 739 Security based on IPsec is widely understood and modules qualified 740 for use in aeronautical and space exploration environments are 741 currently available off-the-shelf due to the US Department of Defense 742 HAIPE work. Other security frameworks may not be as attractive due 743 to a lack of familiarity or available flight-qualified systems. If 744 an RO solution precludes the use of IPsec by applications, this would 745 make it undesirable or unusable. Likewise, since the IPsec standards 746 seem to be the only widely-agreed upon framework for implementing 747 packet authentication and other security services, the use of IPsec 748 to authenticate or otherwise secure RO signaling and other data used 749 in the RO process is also desirable, but other reasonable 750 authentication mechanisms may be acceptable for RO signalling. 752 These issues motivate the requirement that IPsec MUST be usable by 753 applications utilizing the RO scheme, and the data used to make RO 754 decisions MAY be authenticable using IPsec. 756 This requirement was extrapolated from ICAO's TC-8 - "The approach 757 should be secure." 759 3.9. Req9 - Adaptability 761 Req9 - New applications, potentially using new transport protocols or 762 IP options MUST be possible within an RO scheme. 764 3.9.1. Rationale for Aeronatics - Adaptability 766 The concepts of operations are not fully developed for network- 767 centric command and control and other uses of IP-based networks in 768 aeronautical and space environments. The exact application 769 protocols, data flow characteristics, and even transport protocols 770 that will be used in either transitional and final operational 771 concepts are not completely defined yet, and may even change with 772 deployment experience. If the RO solution assumes that some amount 773 of preconfiguration of flow properties (port number ranges, etc.) is 774 required, this could make the integration of new applications or 775 protocols difficult. An RO scheme might assume this in order to 776 classify between flows that prefer the MRHA tunnel to an optimized 777 path per requirement Req1, for instance, among other reasons. Since 778 flag days or other such large-scale synchronized configuration 779 updates are to be avoided to ensure high availability, the RO scheme 780 MUST NOT fail on the use of unexpected higher layer protocols 781 (transport and above). 783 This drives the requirement that new applications, potentially using 784 new transport protocols must be usable within an RO scheme, and MUST 785 NOT involve global reconfiguration events for MRs. 787 This requirement was derived from ICAO's TC-9 - "The approach should 788 be scalable to accomodate anticipated transition to new IP-based 789 communication protocols." 791 4. Desirable Characteristics 793 In this section, we identify some of the properties of the system 794 that are not strict requirements due to either being difficult to 795 quantify or to being features that are not immediately needed, but 796 may provide additional benefits that would help encourage adoption. 798 4.1. Des1 - Configuration 800 For ATS systems, complex configurations are known to increase 801 uncertainty in context, human error and the potential for undesirable 802 (unsafe) states to be reached [12]. Since RO alters the 803 communications context between an MNN and CN, it is desirable that a 804 NEMO RO solution be as simple to configure as possible and also easy 805 to automatically disable if an undesirable state is reached. 807 For CNs at large airports, the Binding Cache state management 808 functions may be simultaneously dealing with hundreds of airplanes 809 with multiple service providers, and a volume of mobility events due 810 to arrivals and departures. The ability to have simple interfaces 811 for humans to access the Binding Cache configuration and alter it in 812 case of errors are desirable, if this does not interfere with the RO 813 protocol mechanisms themselves. 815 4.2. Des2 - Nesting 817 It is desirable if the RO mechanism supports RO for nested MRs, since 818 it is possible that for PIES and astronaut spacesuits, that PANs with 819 MRs will need to be supported. For oceanic flight, ATS and AOS may 820 also benefit from the capability of nesting MRs between multiple 821 planes to provide a "reachback" to terrestrial groundstations rather 822 than relying solely on lower rate HF or satellite systems. In either 823 case, this mode of operation is beyond current strict requirements 824 and is merely desirable. 826 4.3. Des3 - System Impact 828 Low complexity in systems engineering and configuration management is 829 desirable in building and maintaining systems using the RO mechanism. 830 This property may be difficult to quantify, judge, and compare 831 between different RO techniques, but a mechanism that is perceived to 832 have lower impact on the complexity of the network communications 833 system should be favored over an otherwise equivalent mechanism (with 834 regards to the requirements listed above). This is somewhat 835 different than Des1 (Configuration), in that Des1 refers to operation 836 and maintenance of the system once deployed, whereas Des3 is 837 concerned with the initial design, deployment, transition, and later 838 upgrade path of the system. 840 4.4. Des4 - VMN Support 842 At least LFNs and LMNs MUST be supported by a viable RO solution for 843 aeronautics, as these local nodes are within the ATS and AOS domains. 844 VMNs within the PIES domain are expected to be numerous, and it is 845 strongly desirable for them to be supported by the RO technique, but 846 not strictly required. 848 4.5. Des5 - Generality 850 An RO mechanism that is "general purpose", in that it is also readily 851 usable in other contexts outside of aeronautics and space 852 exploration, is desirable. For instance, a RO solution that is 853 usable within VANETs [13] or consumer electronics equipment [14] 854 could satisfy this. The goal is for the technology to be more 855 widely-used and maintained outside the relatively-small aeronautical 856 networking community and its vendors, in order to make acquisitions 857 and training faster, easier, and cheaper. This could also allow 858 aeronautical networking to possibly benefit from future RO scheme 859 optimizations and developments whose research and development is 860 funded and performed externally by the broader industry and academic 861 communities. 863 5. Security Considerations 865 This document does not create any security concerns in and of itself. 866 The security properties of any NEMO RO scheme that is to be used in 867 aeronautics and space exploration are probably much more stringent 868 than for more general NEMO use, due to the safety-of-life and/or 869 national security issues involved. The required security properties 870 are described under Req8 of Section 3 within this document. 872 When deploying in operational networks where network layer security 873 may be mandated (e.g. virtual private networks), the interaction 874 between this and NEMO RO techniques should be carefully considered to 875 ensure that the security mechanisms do not undo the route 876 optimization by forcing packets through a less-optimal overlay or 877 underlay. For instance, when IPsec tunnel use is required, the 878 locations of the tunnel endpoints can force sub-optimal end-to-end 879 paths to be taken. 881 6. IANA Considerations 883 This document neither creates nor updates any IANA registries. 885 7. Acknowledgments 887 Input from several parties is indirectly included in this document. 888 Participants in the MPI mailing list and BoF efforts helped to shape 889 the document. The NEMO and MONAMI6 working group participants were 890 instrumental in completing this document. Specific suggestions from 891 Steve Bretmersky, Thierry Ernst, Tony Li, Jari Arkko, Phillip Watson, 892 Roberto Baldessari, Carlos Jesus Bernardos Cano, and Eivan Cerasi 893 were incorporated into this document. 895 Wesley Eddy's work on this document was performed at NASA's Glenn 896 Research Center, while in support of NASA's Advanced Communications 897 Navigations and Surveillance Architectures and System Technologies 898 (ACAST) project, and the NASA Space Communications Architecture 899 Working Group (SCAWG). 901 8. Changes from draft-eddy-nemo-aero-reqs-02 903 Note, this section will be removed upon publication as an RFC. 905 At the IETF70 mext the aeronautics community indicated we would 906 change the nemo-aero-req-02 document into a mext document with 907 little modification. This the the corresponding document. 909 Any Undefined Acronyms have been defined during first use. 911 9. Informative References 913 [1] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 914 draft-ietf-nemo-terminology-06 (work in progress), 915 November 2006. 917 [2] Ernst, T., "Network Mobility Support Goals and Requirements", 918 draft-ietf-nemo-requirements-06 (work in progress), 919 November 2006. 921 [3] Ivancic, W., "Multi-Domained, Multi-Homed Mobile Networks", 922 draft-ivancic-mobile-platforms-problem-00 (work in progress), 923 September 2006. 925 [4] Davis, T., "Mobile Internet Platform Aviation Requirements", 926 draft-davis-mip-aviationreq-00 (work in progress), 927 September 2006. 929 [5] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 930 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 931 January 2005. 933 [6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 934 IPv6", RFC 3775, June 2004. 936 [7] Ng, C., "Network Mobility Route Optimization Problem 937 Statement", draft-ietf-nemo-ro-problem-statement-03 (work in 938 progress), September 2006. 940 [8] ICAO Asia/Pacific Regional Office, "Required Communication 941 Performance (RCP) Concepts - An Introduction", Informal South 942 Pacific ATS Coordinating Group 20th meeting, Agenda Item 7, 943 January 2006. 945 [9] Dul, A., "Global IP Network Mobility", presentation at IETF 62 946 plenary , March 2005. 948 [10] Ivancic, W., Paulsen, P., Stewart, D., Shell, D., Wood, L., 949 Jackson, C., Hodgson, D., Northam, J., Bean, N., Miller, E., 950 Graves, M., and L. Kurisaki, "Secure, Network-centric 951 Operations of a Space-based Asset: Cisco Router in Low Earth 952 Orbit (CLEO) and Virtual Mission Operations Center (VMOC)", 953 NASA Technical Memorandum TM-2005-213556, May 2005. 955 [11] ICAO WG-N SWG1, "Analysis of Candidate ATN IPS Mobility 956 Solutions", Meeting #12, Working Paper 6, Bangkok, Thailand, 957 January 2007. 959 [12] ICAO, "Threat and Error Management (TEM) in Air Traffic 960 Control", ICAO Preliminary Edition, October 2005. 962 [13] Baldessari, R., "C2C-C Consortium Requirements for NEMO Route 963 Optimization", draft-baldessari-c2ccc-nemo-req-01 (work in 964 progress), July 2007. 966 [14] Ng, C., "Consumer Electronics Requirements for Network Mobility 967 Route Optimization", draft-ng-nemo-ce-req-00 (work in 968 progress), July 2007. 970 [15] CCSDS, "Cislunar Space Internetworking: Architecture", CCCSDS 971 000.0-G-1 Draft Green Book, December 2006. 973 [16] NASA Space Communication Architecture Working Group, "NASA 974 Space Communication and Navigation Architecture Recommendations 975 for 2005-2030", SCAWG Final Report, May 2006. 977 [17] Bradner, S., "Key words for use in RFCs to Indicate Requirement 978 Levels", BCP 14, RFC 2119, March 1997. 980 Appendix A. Basics of IP-based Aeronautical Networking 982 The current standards for aeronautical networking are based on the 983 ISO OSI networking stack and are referred to as the Aeronautical 984 Telecommunications Network (ATN). While standardized, the ATN has 985 not been fully deployed and seems to be in only limited use compared 986 to its full vision and potential. The International Civil Aviation 987 Organization (ICAO) is a part of the United Nations that produces 988 standards for aeronautical communications. The ICAO has recognized 989 that an ATN based on OSI lacks the widespread commercial network 990 support required for the successful deployment of new more bandwidth- 991 intensive ATN applications, and has recently been working towards a 992 new IP-based version of the ATN. 994 Supporting mobility in an IP-based network may be vastly different 995 than it is in the OSI-based ATN which uses the Inter-Domain Routing 996 Protocol (IDRP) to recompute routing tables as mobile networks change 997 topological points of attachment. ICAO recognizes this and has 998 studied various mobility techniques based on link, network, 999 transport, routing, and application protocols [11]. 1001 Work done within ICAO has identified the NEMO technology as a 1002 promising candidate for use in supporting global IP-based mobile 1003 networking. The main concerns with NEMO have been with its current 1004 lack of route optimization support and its potentially complex 1005 configuration requirements in a large airport environment with 1006 multiple service providers and 25 or more airlines sharing the same 1007 infrastructure. 1009 Appendix B. Basics of IP-based Space Networking 1011 IP itself is only in limited operational use for communicating with 1012 spacecraft currently (e.g. the Surry Satellite Technology Limited 1013 (SSTL) Disaster Monitoring Constellation (DMC) satellites are one 1014 example). Future communications architectures include IP-based 1015 networking as an essential building-block, however. The Consultative 1016 Committee for Space Data Systems (CCSDS) has a working group that is 1017 producing a network architecture for using IP-based communications in 1018 both manned and unmanned near-Earth missions, and has international 1019 participation towards this goal [15]. NASA's Space Communications 1020 Architecture Working Group (SCAWG) also has developed an IP-based 1021 multi-mission networking architecture [16]. Neither of these is 1022 explicitly based on Mobile IP technologies, but NEMO is usable within 1023 these architectures, and they may be extended to include NEMO when/if 1024 the need becomes apparent. 1026 Authors' Addresses 1028 Wesley M. Eddy 1029 Verizon Federal Network Systems 1030 NASA Glenn Research Center 1031 21000 Brookpark Road, MS 54-5 1032 Cleveland, OH 44135 1033 USA 1035 Email: weddy@grc.nasa.gov 1037 Will Ivancic 1038 NASA Glenn Research Center 1039 21000 Brookpark Road, MS 54-5 1040 Cleveland, OH 44135 1041 USA 1043 Phone: +1-216-433-3494 1044 Email: William.D.Ivancic@grc.nasa.gov 1046 Terry Davis 1047 Boeing Commercial Airplanes 1048 P.O.Box 3707 MC 07-25 1049 Seattle, WA 98124-2207 1050 USA 1052 Phone: 206-280-3715 1053 Email: Terry.L.Davis@boeing.com 1055 Full Copyright Statement 1057 Copyright (C) The IETF Trust (2007). 1059 This document is subject to the rights, licenses and restrictions 1060 contained in BCP 78, and except as set forth therein, the authors 1061 retain all their rights. 1063 This document and the information contained herein are provided on an 1064 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1065 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1066 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1067 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1068 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1069 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1071 Intellectual Property 1073 The IETF takes no position regarding the validity or scope of any 1074 Intellectual Property Rights or other rights that might be claimed to 1075 pertain to the implementation or use of the technology described in 1076 this document or the extent to which any license under such rights 1077 might or might not be available; nor does it represent that it has 1078 made any independent effort to identify any such rights. Information 1079 on the procedures with respect to rights in RFC documents can be 1080 found in BCP 78 and BCP 79. 1082 Copies of IPR disclosures made to the IETF Secretariat and any 1083 assurances of licenses to be made available, or the result of an 1084 attempt made to obtain a general license or permission for the use of 1085 such proprietary rights by implementers or users of this 1086 specification can be obtained from the IETF on-line IPR repository at 1087 http://www.ietf.org/ipr. 1089 The IETF invites any interested party to bring to its attention any 1090 copyrights, patents or patent applications, or other proprietary 1091 rights that may cover technology that may be required to implement 1092 this standard. Please address the information to the IETF at 1093 ietf-ipr@ietf.org. 1095 Acknowledgment 1097 Funding for the RFC Editor function is provided by the IETF 1098 Administrative Support Activity (IASA).