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