idnits 2.17.1 draft-ietf-rtgwg-atn-bgp-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 date (December 17, 2020) is 1226 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2784' is defined on line 860, but no explicit reference was found in the text == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-36 == Outdated reference: A later version (-99) exists of draft-templin-6man-omni-interface-61 == Outdated reference: A later version (-99) exists of draft-templin-intarea-6706bis-80 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft G. Saccone 4 Intended status: Informational Boeing Research & Technology 5 Expires: June 20, 2021 G. Dawra 6 LinkedIn 7 A. Lindem 8 V. Moreno 9 Cisco Systems, Inc. 10 December 17, 2020 12 A Simple BGP-based Mobile Routing System for the Aeronautical 13 Telecommunications Network 14 draft-ietf-rtgwg-atn-bgp-07 16 Abstract 18 The International Civil Aviation Organization (ICAO) is investigating 19 mobile routing solutions for a worldwide Aeronautical 20 Telecommunications Network with Internet Protocol Services (ATN/IPS). 21 The ATN/IPS will eventually replace existing communication services 22 with an IPv6-based service supporting pervasive Air Traffic 23 Management (ATM) for Air Traffic Controllers (ATC), Airline 24 Operations Controllers (AOC), and all commercial aircraft worldwide. 25 This informational document describes a simple and extensible mobile 26 routing service based on industry-standard BGP to address the ATN/IPS 27 requirements. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on June 20, 2021. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. ATN/IPS Routing System . . . . . . . . . . . . . . . . . . . 8 66 4. ATN/IPS (Radio) Access Network (ANET) Model . . . . . . . . . 11 67 5. ATN/IPS Route Optimization . . . . . . . . . . . . . . . . . 13 68 6. BGP Protocol Considerations . . . . . . . . . . . . . . . . . 15 69 7. Stub AS Mobile Routing Services . . . . . . . . . . . . . . . 16 70 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 73 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 75 12.1. Normative References . . . . . . . . . . . . . . . . . . 18 76 12.2. Informative References . . . . . . . . . . . . . . . . . 19 77 Appendix A. BGP Convergence Considerations . . . . . . . . . . . 20 78 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 20 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 81 1. Introduction 83 The worldwide Air Traffic Management (ATM) system today uses a 84 service known as Aeronautical Telecommunications Network based on 85 Open Systems Interconnection (ATN/OSI). The service is used to 86 augment controller to pilot voice communications with rudimentary 87 short text command and control messages. The service has seen 88 successful deployment in a limited set of worldwide ATM domains. 90 The International Civil Aviation Organization (ICAO) is now 91 undertaking the development of a next-generation replacement for ATN/ 92 OSI known as Aeronautical Telecommunications Network with Internet 93 Protocol Services (ATN/IPS) [ATN][ATN-IPS]. ATN/IPS will eventually 94 provide an IPv6-based [RFC8200] service supporting pervasive ATM for 95 Air Traffic Controllers (ATC), Airline Operations Controllers (AOC), 96 and all commercial aircraft worldwide. As part of the ATN/IPS 97 undertaking, a new mobile routing service will be needed. This 98 document presents an approach based on the Border Gateway Protocol 99 (BGP) [RFC4271]. 101 Aircraft communicate via wireless aviation data links that typically 102 support much lower data rates than terrestrial wireless and wired- 103 line communications. For example, some Very High Frequency (VHF)- 104 based data links only support data rates on the order of 32Kbps and 105 an emerging L-Band data link that is expected to play a key role in 106 future aeronautical communications only supports rates on the order 107 of 1Mbps. Although satellite data links can provide much higher data 108 rates during optimal conditions, like any other aviation data link 109 they are subject to errors, delay, disruption, signal intermittence, 110 degradation due to atmospheric conditions, etc. The well-connected 111 ground domain ATN/IPS network should therefore treat each safety-of- 112 flight critical packet produced by (or destined to) an aircraft as a 113 precious commodity and strive for an optimized service that provides 114 the highest possible degree of reliability. 116 The ATN/IPS is an IPv6-based overlay network configured over one or 117 more Internetworking underlays ("INETs") maintained by aeronautical 118 network service providers such as ARINC, SITA and Inmarsat. The 119 overlay provides an Overlay Multilink Network Interface (OMNI) 120 virtual link layer as discussed in [I-D.templin-6man-omni-interface]. 121 Each aircraft connects to the OMNI link via an OMNI Interface 122 configured over the aircraft's underlying physical and/or virtual 123 access network interfaces. The OMNI interface connects to a Non- 124 Broadcast, Multiple Access (NBMA) virtual link that spans the entire 125 ATN/IPS. 127 Each underlying INET comprises one or more "partitions" where all 128 nodes within a partition can exchange packets with all other nodes, 129 i.e., the partition is connected internally. There is no requirement 130 that any two INET partitions use the same IP protocol version nor 131 have consistent IP addressing plans in comparison with other 132 partitions. Instead, the OMNI link sees each partition as a 133 "segment" of a link-layer topology manifested through a (virtual) 134 bridging service based on IPv6 encapsulation [RFC2473] known as the 135 OMNI Adaptation Layer (OAL). Further discussion of the OAL is found 136 in the following sections of this document, with reference to 137 [I-D.templin-6man-omni-interface][I-D.templin-intarea-6706bis]. 139 The IPv6 addressing architecture provides different classes of 140 addresses, including Global Unicast Addresses (GUAs), Unique Local 141 Addresses (ULAs) and Link-Local Addresses (LLAs) [RFC4291][RFC4193]. 143 The ATN/IPS receives an IPv6 GUA Mobility Service Prefix (MSP) from 144 an Internet assigned numbers authority, and each aircraft will 145 receive a Mobile Network Prefix (MNP) delegation from the MSP that 146 accompanies the aircraft wherever it travels. ATCs and AOCs will 147 likewise receive MNPs, but they would typically appear in static (not 148 mobile) deployments such as air traffic control towers, airline 149 headquarters, etc. The OAL conversely uses ULAs in the source and 150 destination addresses of IPv6 encapsulation headers. Each ULA 151 includes an MNP in the interface identifier as discussed in 152 [I-D.templin-6man-omni-interface], and the BGP routing services 153 performs forwarding based on these "MNP-ULAs" instead of based on the 154 MNPs themselves. 156 Connexion By Boeing [CBB] was an early aviation mobile routing 157 service based on dynamic updates in the global public Internet BGP 158 routing system. Practical experience with the approach has shown 159 that frequent injections and withdrawals of prefixes in the Internet 160 routing system can result in excessive BGP update messaging, slow 161 routing table convergence times, and extended outages when no route 162 is available. This is due to both conservative default BGP protocol 163 timing parameters (see Section 6) and the complex peering 164 interconnections of BGP routers within the global Internet 165 infrastructure. The situation is further exacerbated by frequent 166 aircraft mobility events that each result in BGP updates that must be 167 propagated to all BGP routers in the Internet that carry a full 168 routing table. 170 We therefore consider an approach using a BGP overlay network routing 171 system where a private BGP routing protocol instance is maintained 172 between ATN/IPS Autonomous System (AS) Border Routers (ASBRs). The 173 private BGP instance does not interact with the native BGP routing 174 systems in underlying INETs, and BGP updates are unidirectional from 175 "stub" ASBRs (s-ASBRs) to a small set of "core" ASBRs (c-ASBRs) in a 176 hub-and-spokes topology. No extensions to the BGP protocol are 177 necessary. BGP routing is based on the ULAs found in OAL headers, 178 i.e., it provides an adaptation layer forwarding service instead of a 179 networking layer services. 181 The s-ASBRs for each stub AS connect to a small number of c-ASBRs via 182 dedicated high speed links and/or tunnels across the INET using 183 industry-standard secured encapsulations (e.g., IPsec [RFC4301], 184 Wireguard, etc.). In particular, tunneling must be used when 185 neighboring ASBRs are separated by multiple INET hops. 187 The s-ASBRs engage in external BGP (eBGP) peerings with their 188 respective c-ASBRs, and only maintain routing table entries for the 189 MNP-ULAs currently active within the stub AS. The s-ASBRs send BGP 190 updates for MNP-ULA injections or withdrawals to c-ASBRs but do not 191 receive any BGP updates from c-ASBRs. Instead, the s-ASBRs maintain 192 default routes with their c-ASBRs as the next hop, and therefore hold 193 only partial topology information. 195 The c-ASBRs connect to other c-ASBRs within the same partition using 196 internal BGP (iBGP) peerings over which they collaboratively maintain 197 a full routing table for all active MNP-ULAs currently in service 198 within the partition. Therefore, only the c-ASBRs maintain a full 199 BGP routing table and never send any BGP updates to s-ASBRs. This 200 simple routing model therefore greatly reduces the number of BGP 201 updates that need to be synchronized among peers, and the number is 202 reduced further still when intradomain routing changes within stub 203 ASes are processed within the AS instead of being propagated to the 204 core. BGP Route Reflectors (RRs) [RFC4456] can also be used to 205 support increased scaling properties. 207 When there are multiple INET partitions, the c-ASBRs of each 208 partition use eBGP to peer with the c-ASBRs of other partitions so 209 that the full set of ULAs for all partitions are known globally among 210 all of the c-ASBRs. Each c/s-ASBR further configures an 211 administratively-assigned "ADM-ULA" (see: 212 [I-D.templin-6man-omni-interface]) which is taken from a ADM-ULA 213 prefix assigned to each partition, as well as static forwarding table 214 entries for all other OMNI link partition prefixes. Both ADM-ULAs 215 and MNP-ULAs are used by the OAL for nested encapsulation where the 216 inner IPv6 packet is encapsulated in an IPv6 OAL header with ULA 217 source and destination addresses, which is then encapsulated in an IP 218 header specific to the INET partition. 220 The remainder of this document discusses the proposed BGP-based ATN/ 221 IPS mobile routing service. 223 2. Terminology 225 The terms Autonomous System (AS) and Autonomous System Border Router 226 (ASBR) are the same as defined in [RFC4271]. 228 The following terms are defined for the purposes of this document: 230 Air Traffic Management (ATM) 231 The worldwide service for coordinating safe aviation operations. 233 Air Traffic Controller (ATC) 234 A government agent responsible for coordinating with aircraft 235 within a defined operational region via voice and/or data Command 236 and Control messaging. 238 Airline Operations Controller (AOC) 239 An airline agent responsible for tracking and coordinating with 240 aircraft within their fleet. 242 Aeronautical Telecommunications Network with Internet Protocol 243 Services (ATN/IPS) 244 A future aviation network for ATCs and AOCs to coordinate with all 245 aircraft operating worldwide. The ATN/IPS will be an IPv6-based 246 overlay network service that connects access networks via 247 tunneling over one or more Internetworking underlays. 249 Internetworking underlay ("INET") 250 A wide-area network that supports overlay network tunneling and 251 connects Radio Access Networks to the rest of the ATN/IPS. 252 Example INET service providers for civil aviation include ARINC, 253 SITA and Inmarsat. 255 (Radio) Access Network ("ANET") 256 An aviation radio data link service provider's network, including 257 radio transmitters and receivers as well as supporting ground- 258 domain infrastructure needed to convey a customer's data packets 259 to outside INETs. The term ANET is intended in the same spirit as 260 for radio-based Internet service provider networks (e.g., cellular 261 operators), but can also refer to ground-domain networks that 262 connect AOCs and ATCs. 264 partition (or "segment") 265 A fully-connected internal subnetwork of an INET in which all 266 nodes can communicate with all other nodes within the same 267 partition using the same IP protocol version and addressing plan. 268 Each INET consists of one or more partitions. 270 Overlay Multilink Network Interface (OMNI) 271 A virtual layer 2 bridging service that presents an ATN/IPS 272 overlay unified link view even though the underlay may consist of 273 multiple INET partitions. The OMNI virtual link is manifested 274 through nested encapsulation in which GUA-addessed IPv6 packets 275 from the ATN/IPS are first encapsulated in ULA-addressed IPv6 276 headers which are then forwarded to the next hop using INET 277 encapsulation if necessary. Forwarding over the OMNI virtual link 278 is therefore based on ULAs instead of GUAs. In this way, packets 279 sent from a source can be conveyed over the OMNI virtual link even 280 though there may be many underlying INET partitions in the path to 281 the destination. 283 OMNI Adaptation Layer (OAL) 284 A middle layer below the IPv6 layer but above the INET layer that 285 applies IPv6-in-IPv6 encapsulation prior to INET encapsulation. 286 The IPv6 encapsulation header inserted by the OAL uses ULAs 287 instead of GUAs. Further details on OMNI and the OAL are found in 288 [I-D.templin-6man-omni-interface]. 290 OAL Autonomous System 291 A "hub-of-hubs" autonomous system maintained through peerings 292 between the core autonomous systems of different OMNI virtual link 293 partitions. 295 Core Autonomous System Border Router (c-ASBR) 296 A BGP router located in the hub of the INET partition hub-and- 297 spokes overlay network topology. 299 Core Autonomous System 300 The "hub" autonomous system maintained by all c-ASBRs within the 301 same partition. 303 Stub Autonomous System Border Router (s-ASBR) 304 A BGP router configured as a spoke in the INET partition hub-and- 305 spokes overlay network topology. 307 Stub Autonomous System 308 A logical grouping that includes all Clients currently associated 309 with a given s-ASBR. 311 Client 312 An ATC, AOC or aircraft that connects to the ATN/IPS as a leaf 313 node. The Client could be a singleton host, or a router that 314 connects a mobile or fixed network. 316 Proxy 317 An ANET/INET border node that acts as a transparent intermediary 318 between Clients and s-ASBRs. From the Client's perspective, the 319 Proxy presents the appearance that the Client is communicating 320 directly with the s-ASBR. From the s-ASBR's perspective, the 321 Proxy presents the appearance that the s-ASBR is communicating 322 directly with the Client. 324 Mobile Network Prefix (MNP) 325 An IPv6 prefix that is delegated to any ATN/IPS end system, 326 including ATCs, AOCs, and aircraft. 328 Mobility Service Prefix (MSP) 329 An aggregated prefix assigned to the ATN/IPS by an Internet 330 assigned numbers authority, and from which all MNPs are delegated 331 (e.g., up to 2**32 IPv6 /56 MNPs could be delegated from a /24 332 MSP). 334 3. ATN/IPS Routing System 336 The ATN/IPS routing system comprises a private BGP instance 337 coordinated in an overlay network via tunnels between neighboring 338 ASBRs over one or more underlying INETs. The overlay does not 339 interact with the underlying INET BGP routing systems, and only a 340 small and unchanging set of MSPs are advertised externally instead of 341 the full dynamically changing set of MNPs. 343 Within each INET partition, one or more s-ASBRs connect each stub AS 344 to the INET partition core using a shared stub AS Number (ASN). Each 345 s-ASBR further uses eBGP to peer with one or more c-ASBRs. All 346 c-ASBRs are members of the INET partition core AS, and use a shared 347 core ASN. Globally-unique public ASNs could be assigned, e.g., 348 either according to the standard 16-bit ASN format or the 32-bit ASN 349 scheme defined in [RFC6793]. 351 The c-ASBRs use iBGP to maintain a synchronized consistent view of 352 all active MNP-ULAs currently in service within the INET partition. 353 Figure 1 below represents the reference INET partition deployment. 354 (Note that the figure shows details for only two s-ASBRs (s-ASBR1 and 355 s-ASBR2) due to space constraints, but the other s-ASBRs should be 356 understood to have similar Stub AS, MNP and eBGP peering 357 arrangements.) The solution described in this document is flexible 358 enough to extend to these topologies. 360 ........................................................... 361 . . 362 . (:::)-. <- Stub ASes -> (:::)-. . 363 . MNPs-> .-(:::::::::) .-(:::::::::) <-MNPs . 364 . `-(::::)-' `-(::::)-' . 365 . +-------+ +-------+ . 366 . |s-ASBR1+-----+ +-----+s-ASBR2| . 367 . +--+----+ eBGP \ / eBGP +-----+-+ . 368 . \ \/ / . 369 . \eBGP / \ /eBGP . 370 . \ / \ / . 371 . +-------+ +-------+ . 372 . eBGP+-----+c-ASBR |...|c-ASBR +-----+eBGP . 373 . +-------+ / +--+----+ +-----+-+ \ +-------+ . 374 . |s-ASBR +/ iBGP\ (:::)-. /iBGP \+s-ASBR | . 375 . +-------+ .-(::::::::) +-------+ . 376 . . .-(::::::::::::::)-. . . 377 . . (:::: Core AS :::) . . 378 . +-------+ `-(:::::::::::::)-' +-------+ . 379 . |s-ASBR +\ iBGP/`-(:::::::-'\iBGP /+s-ASBR | . 380 . +-------+ \ +-+-----+ +----+--+ / +-------+ . 381 . eBGP+-----+c-ASBR |...|c-ASBR +-----+eBGP . 382 . +-------+ +-------+ . 383 . / \ . 384 . /eBGP \eBGP . 385 . / \ . 386 . +---+---+ +-----+-+ . 387 . |s-ASBR | |s-ASBR | . 388 . +-------+ +-------+ . 389 . . 390 . . 391 . <----------------- INET Partition -------------------> . 392 ............................................................ 394 Figure 1: INET Partition Reference Deployment 396 In the reference deployment, each s-ASBR maintains routes for active 397 MNP-ULAs that currently belong to its stub AS. In response to 398 "Inter-domain" mobility events, each s-ASBR will dynamically 399 announces new MNP-ULAs and withdraws departed MNP-ULAs in its eBGP 400 updates to c-ASBRs. Since ATN/IPS end systems are expected to remain 401 within the same stub AS for extended timeframes, however, intra- 402 domain mobility events (such as an aircraft handing off between cell 403 towers) are handled within the stub AS instead of being propagated as 404 inter-domain eBGP updates. 406 Each c-ASBR configures a black-hole route for each of its MSPs. By 407 black-holing the MSPs, the c-ASBR will maintain forwarding table 408 entries only for the MNP-ULAs that are currently active, and packets 409 destined to all other MNP-ULAs will correctly incur ICMPv6 410 Destination Unreachable messages [RFC4443] due to the black hole 411 route. (This is the same behavior as for ordinary BGP routers in the 412 Internet when they receive packets for which there is no route 413 available.) The c-ASBRs do not send eBGP updates for MNP-ULAs to 414 s-ASBRs, but instead originate a default route. In this way, s-ASBRs 415 have only partial topology knowledge (i.e., they know only about the 416 active MNP-ULAs currently within their stub ASes) and they forward 417 all other packets to c-ASBRs which have full topology knowledge. 419 The core ASes of each INET partition are joined together through 420 external BGP peerings. The c-ASBRs of each partition establish 421 external peerings with the c-ASBRs of other partitions to form a 422 "core-of-cores" OAL AS. The OAL AS contains the global knowledge of 423 all MNP-ULAs deployed worldwide, and supports ATN/IPS overlay 424 communications between nodes located in different INET partitions by 425 virtue of OAL encapsulation. Figure 2 shows a reference OAL 426 topology. 428 . . . . . . . . . . . . . . . . . . . . . . . . . 429 . . 430 . .-(::::::::) . 431 . .-(::::::::::::)-. +------+ . 432 . (::: Partition 1 ::)--|c-ASBR|---+ . 433 . `-(::::::::::::)-' +------+ | . 434 . `-(::::::)-' | . 435 . | . 436 . .-(::::::::) | . 437 . .-(::::::::::::)-. +------+ | . 438 . (::: Partition 2 ::)--|c-ASBR|---+ . 439 . `-(::::::::::::)-' +------+ | . 440 . `-(::::::)-' | . 441 . | . 442 . .-(::::::::) | . 443 . .-(::::::::::::)-. +------+ | . 444 . (::: Partition 3 ::)--|c-ASBR|---+ . 445 . `-(::::::::::::)-' +------+ | . 446 . `-(::::::)-' | . 447 . | . 448 . ..(etc).. x . 449 . . 450 . . 451 . <- ATN/IPS Overlay Bridged by the OAL AS -> . 452 . . . . . . . . . . . . . .. . . . . . . . . . . . 454 Figure 2: Spanning Partitions with the OAL 456 Scaling properties of this ATN/IPS routing system are limited by the 457 number of BGP routes that can be carried by the c-ASBRs. A 2015 458 study showed that BGP routers in the global public Internet at that 459 time carried more than 500K routes with linear growth and no signs of 460 router resource exhaustion [BGP]. A more recent network emulation 461 study also showed that a single c-ASBR can accommodate at least 1M 462 dynamically changing BGP routes even on a lightweight virtual 463 machine. Commercially-available high-performance dedicated router 464 hardware can support many millions of routes. 466 Therefore, assuming each c-ASBR can carry 1M or more routes, this 467 means that at least 1M ATN/IPS end system MNP-ULAs can be serviced by 468 a single set of c-ASBRs and that number could be further increased by 469 using RRs and/or more powerful routers. Another means of increasing 470 scale would be to assign a different set of c-ASBRs for each set of 471 MSPs. In that case, each s-ASBR still peers with one or more c-ASBRs 472 from each set of c-ASBRs, but the s-ASBR institutes route filters so 473 that it only sends BGP updates to the specific set of c-ASBRs that 474 aggregate the MSP. In this way, each set of c-ASBRs maintains 475 separate routing and forwarding tables so that scaling is distributed 476 across multiple c-ASBR sets instead of concentrated in a single 477 c-ASBR set. For example, a first c-ASBR set could aggregate an MSP 478 segment A::/32, a second set could aggregate B::/32, a third could 479 aggregate C::/32, etc. The union of all MSP segments would then 480 constitute the collective MSP(s) for the entire ATN/IPS, with 481 potential for supporting many millions of mobile networks or more. 483 In this way, each set of c-ASBRs services a specific set of MSPs, and 484 each s-ASBR configures MSP-specific routes that list the correct set 485 of c-ASBRs as next hops. This design also allows for natural 486 incremental deployment, and can support initial medium-scale 487 deployments followed by dynamic deployment of additional ATN/IPS 488 infrastructure elements without disturbing the already-deployed base. 489 For example, a few more c-ASBRs could be added if the MNP service 490 demand ever outgrows the initial deployment. For larger-scale 491 applications (such as unmanned air vehicles and terrestrial vehicles) 492 even larger scales can be accommodated by adding more c-ASBRs. 494 4. ATN/IPS (Radio) Access Network (ANET) Model 496 (Radio) Access Networks (ANETs) connect end system Clients such as 497 aircraft, ATCs, AOCs etc. to the ATN/IPS routing system. Clients may 498 connect to multiple ANETs at once, for example, when they have both 499 satellite and cellular data links activated simultaneously. Clients 500 configure an Overlay Multilink Network (OMNI) Interface 501 [I-D.templin-6man-omni-interface] over their underlying ANET 502 interfaces as a connection to an NBMA virtual link (manifested by the 503 OAL) that spans the entire ATN/IPS. Clients may further move between 504 ANETs in a manner that is perceived as a network layer mobility 505 event. Clients could therefore employ a multilink/mobility routing 506 service such as those discussed in Section 7. 508 Clients register all of their active data link connections with their 509 serving s-ASBRs as discussed in Section 3. Clients may connect to 510 s-ASBRs either directly, or via a Proxy at the ANET/INET boundary. 512 Figure 3 shows the ATN/IPS ANET model where Clients connect to ANETs 513 via aviation data links. Clients register their ANET addresses with 514 a nearby s-ASBR, where the registration process may be brokered by a 515 Proxy at the edge of the ANET. 517 +-----------------+ 518 | Client | 519 Data Link "A" +-----------------+ Data Link "B" 520 +----- | OMNI Interface |--------+ 521 / +-----------------+ \ 522 / \ 523 / \ 524 (:::)-. (:::)-. 525 .-(:::::::::)<- (Radio) Access Networks ->.-(:::::::::) 526 `-(::::)-' `-(::::)-' 527 +-------+ +-------+ 528 ... | Proxy | ............................ | Proxy | ... 529 . +-------+ +-------+ . 530 . ^^ ^^ . 531 . || || . 532 . || +--------+ || . 533 . ++============> | s-ASBR | <============++ . 534 . +--------+ . 535 . | eBGP . 536 . (:::)-. . 537 . .-(::::::::) . 538 . .-(::: ATN/IPS :::)-. . 539 . (::::: BGP Routing ::::) . 540 . `-(:: System ::::)-' . 541 . `-(:::::::-' . 542 . . 543 . . 544 . <------- OMNI virtual link bridged by the OAL --------> . 545 ............................................................ 547 Figure 3: ATN/IPS ANET Architecture 549 When a Client logs into an ANET it specifies a nearby s-ASBR that it 550 has selected to connect to the ATN/IPS. (Selection of a nearby 551 s-ASBR could be through consulting a geographically-keyed static host 552 file, through a DNS lookup, through a network query response, etc.) 553 The login process is transparently brokered by a Proxy at the border 554 of the ANET, which then conveys the connection request to the s-ASBR 555 via tunneling across the OMNI virtual link. The s-ASBR then 556 registers the address of the Proxy as the address for the Client, and 557 the Proxy forwards the s-ASBR's reply to the Client. If the Client 558 connects to multiple ANETs, the s-ASBR will register the addresses of 559 all Proxies as addresses through which the Client can be reached. 561 The s-ASBR represents all of its active Clients as MNP-ULA routes in 562 the ATN/IPS BGP routing system. The s-ASBR's stub AS therefore 563 consists of the set of all of its active Clients (i.e., the stub AS 564 is a logical construct and not a physical construct). The s-ASBR 565 injects the MNP-ULAs of its active Clients and withdraws the MNP-ULAs 566 of its departed Clients via BGP updates to c-ASBRs, which further 567 propagate the MNP-ULAs to other c-ASBRs within the OAL AS. Since 568 Clients are expected to remain associated with their current s-ASBR 569 for extended periods, the level of MNP-ULA injections and withdrawals 570 in the BGP routing system will be on the order of the numbers of 571 network joins, leaves and s-ASBR handovers for aircraft operations 572 (see: Section 6). It is important to observe that fine-grained 573 events such as Client mobility and Quality of Service (QoS) signaling 574 are coordinated only by Proxies and the Client's current s-ASBRs, and 575 do not involve other ASBRs in the routing system. In this way, 576 intradomain routing changes within the stub AS are not propagated 577 into the rest of the ATN/IPS BGP routing system. 579 5. ATN/IPS Route Optimization 581 ATN/IPS end systems will frequently need to communicate with 582 correspondents associated with other s-ASBRs. In the BGP peering 583 topology discussed in Section 3, this can initially only be 584 accommodated by including multiple tunnel segments in the forwarding 585 path. In many cases, it would be desirable to eliminate extraneous 586 tunnel segments from this "dogleg" route so that packets can traverse 587 a minimum number of tunneling hops across the OMNI virtual link. 588 ATN/IPS end systems could therefore employ a route optimization 589 service according to the mobility service employed (see: Section 7). 591 A route optimization example is shown in Figure 4 and Figure 5 below. 592 In the first figure, multiple tunneled segments between Proxys and 593 ASBRs are necessary to convey packets between Clients associated with 594 different s-ASBRs. In the second figure, the optimized route tunnels 595 packets directly between Proxys without involving the ASBRs. 597 +---------+ +---------+ 598 | Client1 | | Client2 | 599 +---v-----+ +-----^---+ 600 * * 601 * * 602 (:::)-. (:::)-. 603 .-(:::::::::)<- (Radio) Access Networks ->.-(:::::::::) 604 `-(::::)-' `-(::::)-' 605 +--------+ +--------+ 606 ... | Proxy1 | .......................... | Proxy2 | ... 607 . +--------+ +--------+ . 608 . ** ** . 609 . ** ** . 610 . ** ** . 611 . +---------+ +---------+ . 612 . | s-ASBR1 | | s-ASBR2 | . 613 . +--+------+ +-----+---+ . 614 . \ ** Dogleg ** / . 615 . eBGP\ ** Route ** /eBGP . 616 . \ **==============** / . 617 . +---------+ +---------+ . 618 . | c-ASBR1 | | c-ASBR2 | . 619 . +---+-----+ +----+----+ . 620 . +--------------+ . 621 . iBGP . 622 . . 623 . <------- OMNI virtual link bridged by the OAL --------> . 624 ............................................................ 626 Figure 4: Dogleg Route Before Optimization 628 +---------+ +---------+ 629 | Client1 | | Client2 | 630 +---v-----+ +-----^---+ 631 * * 632 * * 633 (:::)-. (:::)-. 634 .-(:::::::::) <- (Radio) Access Networks ->.-(:::::::::) 635 `-(::::)-' `-(::::)-' 636 +--------+ +--------+ 637 ... | Proxy1 | .......................... | Proxy2 | ... 638 . +------v-+ +--^-----+ . 639 . * * . 640 . *================================* . 641 . . 642 . +---------+ +---------+ . 643 . | s-ASBR1 | | s-ASBR2 | . 644 . +--+------+ +-----+---+ . 645 . \ / . 646 . eBGP\ /eBGP . 647 . \ / . 648 . +---------+ +---------+ . 649 . | c-ASBR1 | | c-ASBR2 | . 650 . +---+-----+ +----+----+ . 651 . +--------------+ . 652 . iBGP . 653 . . 654 . <------- OMNI virtual link bridged by the OAL --------> . 655 ............................................................ 657 Figure 5: Optimized Route 659 6. BGP Protocol Considerations 661 The number of eBGP peering sessions that each c-ASBR must service is 662 proportional to the number of s-ASBRs in its local partition. 663 Network emulations with lightweight virtual machines have shown that 664 a single c-ASBR can service at least 100 eBGP peerings from s-ASBRs 665 that each advertise 10K MNP-ULA routes (i.e., 1M total). It is 666 expected that robust c-ASBRs can service many more peerings than this 667 - possibly by multiple orders of magnitude. But even assuming a 668 conservative limit, the number of s-ASBRs could be increased by also 669 increasing the number of c-ASBRs. Since c-ASBRs also peer with each 670 other using iBGP, however, larger-scale c-ASBR deployments may need 671 to employ an adjunct facility such as BGP Route Reflectors 672 (RRs)[RFC4456]. 674 The number of aircraft in operation at a given time worldwide is 675 likely to be significantly less than 1M, but we will assume this 676 number for a worst-case analysis. Assuming a worst-case average 1 677 hour flight profile from gate-to-gate with 10 service region 678 transitions per flight, the entire system will need to service at 679 most 10M BGP updates per hour (2778 updates per second). This number 680 is within the realm of the peak BGP update messaging seen in the 681 global public Internet today [BGP2]. Assuming a BGP update message 682 size of 100 bytes (800bits), the total amount of BGP control message 683 traffic to a single c-ASBR will be less than 2.5Mbps which is a 684 nominal rate for modern data links. 686 Industry standard BGP routers provide configurable parameters with 687 conservative default values. For example, the default hold time is 688 90 seconds, the default keepalive time is 1/3 of the hold time, and 689 the default MinRouteAdvertisementinterval is 30 seconds for eBGP 690 peers and 5 seconds for iBGP peers (see Section 10 of [RFC4271]). 691 For the simple mobile routing system described herein, these 692 parameters can be set to more aggressive values to support faster 693 neighbor/link failure detection and faster routing protocol 694 convergence times. For example, a hold time of 3 seconds and a 695 MinRouteAdvertisementinterval of 0 seconds for both iBGP and eBGP. 697 Instead of adjusting BGP default time values, BGP routers can use the 698 Bidirectional Forwarding Detection (BFD) protocol [RFC5880] to 699 quickly detect link failures that don't result in interface state 700 changes, BGP peer failures, and administrative state changes. BFD is 701 important in environments where rapid response to failures is 702 required for routing reconvergence and, hence, communications 703 continuity. 705 Each c-ASBR will be using eBGP both in the ATN/IPS and the INET with 706 the ATN/IPS unicast IPv6 routes resolving over INET routes. 707 Consequently, c-ASBRs and potentially s-ASBRs will need to support 708 separate local ASes for the two BGP routing domains and routing 709 policy or assure routes are not propagated between the two BGP 710 routing domains. From a conceptual and operational standpoint, the 711 implementation should provide isolation between the two BGP routing 712 domains (e.g., separate BGP instances). 714 7. Stub AS Mobile Routing Services 716 Stub ASes maintain intradomain routing information for mobile node 717 clients, and are responsible for all localized mobility signaling 718 without disturbing the BGP routing system. Clients can enlist the 719 services of a candidate mobility service such as Mobile IPv6 (MIPv6) 720 [RFC6275], LISP [I-D.ietf-lisp-rfc6830bis] and AERO 721 [I-D.templin-intarea-6706bis] according to the service offered by the 722 stub AS. Further details of mobile routing services are out of scope 723 for this document. 725 8. Implementation Status 727 The BGP routing topology described in this document has been modeled 728 in realistic network emulations showing that at least 1 million MNP- 729 ULAs can be propagated to each c-ASBR even on lightweight virtual 730 machines. No BGP routing protocol extensions need to be adopted. 732 9. IANA Considerations 734 This document does not introduce any IANA considerations. 736 10. Security Considerations 738 ATN/IPS ASBRs on the open Internet are susceptible to the same attack 739 profiles as for any Internet nodes. For this reason, ASBRs should 740 employ physical security and/or IP securing mechanisms such as IPsec 741 [RFC4301], TLS [RFC5246], etc. 743 ATN/IPS ASBRs present targets for Distributed Denial of Service 744 (DDoS) attacks. This concern is no different than for any node on 745 the open Internet, where attackers could send spoofed packets to the 746 node at high data rates. This can be mitigated by connecting ATN/IPS 747 ASBRs over dedicated links with no connections to the Internet and/or 748 when ASBR connections to the Internet are only permitted through 749 well-managed firewalls. 751 ATN/IPS s-ASBRs should institute rate limits to protect low data rate 752 aviation data links from receiving DDoS packet floods. 754 BGP protocol message exchanges and control message exchanges used for 755 route optimization must be secured to ensure the integrity of the 756 system-wide routing information base. 758 This document does not include any new specific requirements for 759 mitigation of DDoS. 761 11. Acknowledgements 763 This work is aligned with the FAA as per the SE2025 contract number 764 DTFAWA-15-D-00030. 766 This work is aligned with the NASA Safe Autonomous Systems Operation 767 (SASO) program under NASA contract number NNA16BD84C. 769 This work is aligned with the Boeing Commercial Airplanes (BCA) 770 Internet of Things (IoT) and autonomy programs. 772 This work is aligned with the Boeing Information Technology (BIT) 773 MobileNet program. 775 The following individuals contributed insights that have improved the 776 document: Ahmad Amin, Erik Kline, Hubert Kuenig, Tony Li, Alexandre 777 Petrescu, Pascal Thubert, Tony Whyman. 779 12. References 781 12.1. Normative References 783 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 784 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 785 December 1998, . 787 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 788 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 789 . 791 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 792 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 793 DOI 10.17487/RFC4271, January 2006, 794 . 796 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 797 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 798 2006, . 800 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 801 Control Message Protocol (ICMPv6) for the Internet 802 Protocol Version 6 (IPv6) Specification", STD 89, 803 RFC 4443, DOI 10.17487/RFC4443, March 2006, 804 . 806 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 807 Reflection: An Alternative to Full Mesh Internal BGP 808 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 809 . 811 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 812 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 813 . 815 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 816 (IPv6) Specification", STD 86, RFC 8200, 817 DOI 10.17487/RFC8200, July 2017, 818 . 820 12.2. Informative References 822 [ATN] Maiolla, V., "The OMNI Interface - An IPv6 Air/Ground 823 Interface for Civil Aviation, IETF Liaison Statement 824 #1676, https://datatracker.ietf.org/liaison/1676/", March 825 2020. 827 [ATN-IPS] WG-I, ICAO., "ICAO Document 9896 (Manual on the 828 Aeronautical Telecommunication Network (ATN) using 829 Internet Protocol Suite (IPS) Standards and Protocol), 830 Draft Edition 3 (work-in-progress)", December 2020. 832 [BGP] Huston, G., "BGP in 2015, http://potaroo.net", January 833 2016. 835 [BGP2] Huston, G., "BGP Instability Report, 836 http://bgpupdates.potaroo.net/instability/bgpupd.html", 837 May 2017. 839 [CBB] Dul, A., "Global IP Network Mobility using Border Gateway 840 Protocol (BGP), http://www.quark.net/docs/ 841 Global_IP_Network_Mobility_using_BGP.pdf", March 2006. 843 [I-D.ietf-lisp-rfc6830bis] 844 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 845 Cabellos-Aparicio, "The Locator/ID Separation Protocol 846 (LISP)", draft-ietf-lisp-rfc6830bis-36 (work in progress), 847 November 2020. 849 [I-D.templin-6man-omni-interface] 850 Templin, F. and T. Whyman, "Transmission of IP Packets 851 over Overlay Multilink Network (OMNI) Interfaces", draft- 852 templin-6man-omni-interface-61 (work in progress), 853 December 2020. 855 [I-D.templin-intarea-6706bis] 856 Templin, F., "Asymmetric Extended Route Optimization 857 (AERO)", draft-templin-intarea-6706bis-80 (work in 858 progress), December 2020. 860 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 861 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 862 DOI 10.17487/RFC2784, March 2000, 863 . 865 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 866 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 867 December 2005, . 869 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 870 (TLS) Protocol Version 1.2", RFC 5246, 871 DOI 10.17487/RFC5246, August 2008, 872 . 874 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 875 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 876 2011, . 878 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 879 Autonomous System (AS) Number Space", RFC 6793, 880 DOI 10.17487/RFC6793, December 2012, 881 . 883 Appendix A. BGP Convergence Considerations 885 Experimental evidence has shown that BGP convergence time required 886 for when an MNP-ULA is asserted at a new location or withdrawn from 887 an old location can be several hundred milliseconds even under 888 optimal AS peering arrangements. This means that packets in flight 889 destined to an MNP-ULA route that has recently been changed can be 890 (mis)delivered to an old s-ASBR after a Client has moved to a new 891 s-ASBR. 893 To address this issue, the old s-ASBR can maintain temporary state 894 for a "departed" Client that includes an OAL address for the new 895 s-ASBR. The OAL address never changes since ASBRs are fixed 896 infrastructure elements that never move. Hence, packets arriving at 897 the old s-ASBR can be forwarded to the new s-ASBR while the BGP 898 routing system is still undergoing reconvergence. Therefore, as long 899 as the Client associates with the new s-ASBR before it departs from 900 the old s-ASBR (while informing the old s-ASBR of its new location) 901 packets in flight during the BGP reconvergence window are 902 accommodated without loss. 904 Appendix B. Change Log 906 << RFC Editor - remove prior to publication >> 908 Changes from -05 to -06: 910 o OMNI interface introduced 912 o Version and reference update. 914 Changes from -04 to -05: 916 o Version and reference update. 918 Changes from -03 to -04: 920 o added discussion of Bidirectional Forwarding Detection (BFD). 922 Changes from -02 to -03: 924 o added reference to ICAO A/G interface specification. 926 Changes from -01 to -02: 928 o introduced the SPAN and the concept of Internetwork partitioning 930 o new terms "ANET" (for (Radio) Access Network) and "INET" (for 931 Internetworking underlay) 933 o new appendix on BGP convergence considerations 935 Changes from -00 to -01: 937 o incorporated clarifications due to list comments and questions. 939 o new section 7 on Stub AS Mobile Routing Services 941 o updated references, and included new reference for MIPv6 and LISP 943 Status as of 08/30/2018: 945 o 'draft-templin-atn-bgp' becomes 'draft-ietf-rtgwg-atn-bgp' 947 Authors' Addresses 949 Fred L. Templin (editor) 950 Boeing Research & Technology 951 P.O. Box 3707 952 Seattle, WA 98124 953 USA 955 Email: fltemplin@acm.org 957 Greg Saccone 958 Boeing Research & Technology 959 P.O. Box 3707 960 Seattle, WA 98124 961 USA 963 Email: gregory.t.saccone@boeing.com 964 Gaurav Dawra 965 LinkedIn 966 USA 968 Email: gdawra.ietf@gmail.com 970 Acee Lindem 971 Cisco Systems, Inc. 972 USA 974 Email: acee@cisco.com 976 Victor Moreno 977 Cisco Systems, Inc. 978 USA 980 Email: vimoreno@cisco.com