idnits 2.17.00 (12 Aug 2021) /tmp/idnits4015/draft-ietf-rtgwg-atn-bgp-08.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 18, 2020) is 519 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ULA' is mentioned on line 726, but not defined == Unused Reference: 'RFC2784' is defined on line 886, but no explicit reference was found in the text == Unused Reference: 'RFC6793' is defined on line 904, 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 (~~), 7 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 21, 2021 G. Dawra 6 LinkedIn 7 A. Lindem 8 V. Moreno 9 Cisco Systems, Inc. 10 December 18, 2020 12 A Simple BGP-based Mobile Routing System for the Aeronautical 13 Telecommunications Network 14 draft-ietf-rtgwg-atn-bgp-08 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 21, 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 . . . . . . . . . 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, one or more s-ASBRs connect each stub AS 349 to the INET partition core using a shared 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 16-bit 353 ASN format [RFC4271], where each ASBR assigns an ASN that matches its 354 ADM-ULA suffix. 356 The c-ASBRs use iBGP to maintain a synchronized consistent view of 357 all active MNP-ULAs currently in service within the INET partition. 358 Figure 1 below represents the reference INET partition deployment. 359 (Note that the figure shows details for only two s-ASBRs (s-ASBR1 and 360 s-ASBR2) due to space constraints, but the other s-ASBRs should be 361 understood to have similar Stub AS, MNP and eBGP peering 362 arrangements.) The solution described in this document is flexible 363 enough to extend to these topologies. 365 ........................................................... 366 . . 367 . (:::)-. <- Stub ASes -> (:::)-. . 368 . MNPs-> .-(:::::::::) .-(:::::::::) <-MNPs . 369 . `-(::::)-' `-(::::)-' . 370 . +-------+ +-------+ . 371 . |s-ASBR1+-----+ +-----+s-ASBR2| . 372 . +--+----+ eBGP \ / eBGP +-----+-+ . 373 . \ \/ / . 374 . \eBGP / \ /eBGP . 375 . \ / \ / . 376 . +-------+ +-------+ . 377 . eBGP+-----+c-ASBR |...|c-ASBR +-----+eBGP . 378 . +-------+ / +--+----+ +-----+-+ \ +-------+ . 379 . |s-ASBR +/ iBGP\ (:::)-. /iBGP \+s-ASBR | . 380 . +-------+ .-(::::::::) +-------+ . 381 . . .-(::::::::::::::)-. . . 382 . . (:::: Core AS :::) . . 383 . +-------+ `-(:::::::::::::)-' +-------+ . 384 . |s-ASBR +\ iBGP/`-(:::::::-'\iBGP /+s-ASBR | . 385 . +-------+ \ +-+-----+ +----+--+ / +-------+ . 386 . eBGP+-----+c-ASBR |...|c-ASBR +-----+eBGP . 387 . +-------+ +-------+ . 388 . / \ . 389 . /eBGP \eBGP . 390 . / \ . 391 . +---+---+ +-----+-+ . 392 . |s-ASBR | |s-ASBR | . 393 . +-------+ +-------+ . 394 . . 395 . . 396 . <----------------- INET Partition -------------------> . 397 ............................................................ 399 Figure 1: INET Partition Reference Deployment 401 In the reference deployment, each s-ASBR maintains routes for active 402 MNP-ULAs that currently belong to its stub AS. In response to 403 "Inter-domain" mobility events, each s-ASBR will dynamically 404 announces new MNP-ULAs and withdraws departed MNP-ULAs in its eBGP 405 updates to c-ASBRs. Since ATN/IPS end systems are expected to remain 406 within the same stub AS for extended timeframes, however, intra- 407 domain mobility events (such as an aircraft handing off between cell 408 towers) are handled within the stub AS instead of being propagated as 409 inter-domain eBGP updates. 411 Each c-ASBR configures a black-hole route for each of its MSPs. By 412 black-holing the MSPs, the c-ASBR will maintain forwarding table 413 entries only for the MNP-ULAs that are currently active, and packets 414 destined to all other MNP-ULAs will correctly incur ICMPv6 415 Destination Unreachable messages [RFC4443] due to the black hole 416 route. (This is the same behavior as for ordinary BGP routers in the 417 Internet when they receive packets for which there is no route 418 available.) The c-ASBRs do not send eBGP updates for MNP-ULAs to 419 s-ASBRs, but instead originate a default route. In this way, s-ASBRs 420 have only partial topology knowledge (i.e., they know only about the 421 active MNP-ULAs currently within their stub ASes) and they forward 422 all other packets to c-ASBRs which have full topology knowledge. 424 Each s-ASBR and c-ASBR configures an ADM-ULA that is aggregatable 425 within an INET partition, and each partition configures a unique ADM- 426 ULA prefix that is permanently announced into the routing system. 427 The core ASes of each INET partition are joined together through 428 external BGP peerings. The c-ASBRs of each partition establish 429 external peerings with the c-ASBRs of other partitions to form a 430 "core-of-cores" OMNI link AS. The OMNI link AS contains the global 431 knowledge of all MNP-ULAs deployed worldwide, and supports ATN/IPS 432 overlay communications between nodes located in different INET 433 partitions by virtue of OAL encapsulation. OMNI link nodes can then 434 navigate to ASBRs by including an ADM-ULA or directly to an end 435 system by including an MNP-ULA in the destination address of an OAL- 436 encapsulated packet (see: [I-D.templin-intarea-6706bis]) . Figure 2 437 shows a reference OAL topology. 439 . . . . . . . . . . . . . . . . . . . . . . . . . 440 . . 441 . .-(::::::::) . 442 . .-(::::::::::::)-. +------+ . 443 . (::: Partition 1 ::)--|c-ASBR|---+ . 444 . `-(::::::::::::)-' +------+ | . 445 . `-(::::::)-' | . 446 . | . 447 . .-(::::::::) | . 448 . .-(::::::::::::)-. +------+ | . 449 . (::: Partition 2 ::)--|c-ASBR|---+ . 450 . `-(::::::::::::)-' +------+ | . 451 . `-(::::::)-' | . 452 . | . 453 . .-(::::::::) | . 454 . .-(::::::::::::)-. +------+ | . 455 . (::: Partition 3 ::)--|c-ASBR|---+ . 456 . `-(::::::::::::)-' +------+ | . 457 . `-(::::::)-' | . 458 . | . 459 . ..(etc).. x . 460 . . 461 . . 462 . <- ATN/IPS Overlay Bridged by the OAL AS -> . 463 . . . . . . . . . . . . . .. . . . . . . . . . . . 465 Figure 2: Spanning Partitions with the OAL 467 Scaling properties of this ATN/IPS routing system are limited by the 468 number of BGP routes that can be carried by the c-ASBRs. A 2015 469 study showed that BGP routers in the global public Internet at that 470 time carried more than 500K routes with linear growth and no signs of 471 router resource exhaustion [BGP]. A more recent network emulation 472 study also showed that a single c-ASBR can accommodate at least 1M 473 dynamically changing BGP routes even on a lightweight virtual 474 machine. Commercially-available high-performance dedicated router 475 hardware can support many millions of routes. 477 Therefore, assuming each c-ASBR can carry 1M or more routes, this 478 means that at least 1M ATN/IPS end system MNP-ULAs can be serviced by 479 a single set of c-ASBRs and that number could be further increased by 480 using RRs and/or more powerful routers. Another means of increasing 481 scale would be to assign a different set of c-ASBRs for each set of 482 MSPs. In that case, each s-ASBR still peers with one or more c-ASBRs 483 from each set of c-ASBRs, but the s-ASBR institutes route filters so 484 that it only sends BGP updates to the specific set of c-ASBRs that 485 aggregate the MSP. In this way, each set of c-ASBRs maintains 486 separate routing and forwarding tables so that scaling is distributed 487 across multiple c-ASBR sets instead of concentrated in a single 488 c-ASBR set. For example, a first c-ASBR set could aggregate an MSP 489 segment A::/32, a second set could aggregate B::/32, a third could 490 aggregate C::/32, etc. The union of all MSP segments would then 491 constitute the collective MSP(s) for the entire ATN/IPS, with 492 potential for supporting many millions of mobile networks or more. 494 In this way, each set of c-ASBRs services a specific set of MSPs, and 495 each s-ASBR configures MSP-specific routes that list the correct set 496 of c-ASBRs as next hops. This design also allows for natural 497 incremental deployment, and can support initial medium-scale 498 deployments followed by dynamic deployment of additional ATN/IPS 499 infrastructure elements without disturbing the already-deployed base. 500 For example, a few more c-ASBRs could be added if the MNP service 501 demand ever outgrows the initial deployment. For larger-scale 502 applications (such as unmanned air vehicles and terrestrial vehicles) 503 even larger scales can be accommodated by adding more c-ASBRs. 505 4. ATN/IPS (Radio) Access Network (ANET) Model 507 (Radio) Access Networks (ANETs) connect end system Clients such as 508 aircraft, ATCs, AOCs etc. to the ATN/IPS routing system. Clients may 509 connect to multiple ANETs at once, for example, when they have both 510 satellite and cellular data links activated simultaneously. Clients 511 configure an Overlay Multilink Network (OMNI) Interface 512 [I-D.templin-6man-omni-interface] over their underlying ANET 513 interfaces as a connection to an NBMA virtual link (manifested by the 514 OAL) that spans the entire ATN/IPS. Clients may further move between 515 ANETs in a manner that is perceived as a network layer mobility 516 event. Clients could therefore employ a multilink/mobility routing 517 service such as those discussed in Section 7. 519 Clients register all of their active data link connections with their 520 serving s-ASBRs as discussed in Section 3. Clients may connect to 521 s-ASBRs either directly, or via a Proxy at the ANET/INET boundary. 523 Figure 3 shows the ATN/IPS ANET model where Clients connect to ANETs 524 via aviation data links. Clients register their ANET addresses with 525 a nearby s-ASBR, where the registration process may be brokered by a 526 Proxy at the edge of the ANET. 528 +-----------------+ 529 | Client | 530 Data Link "A" +-----------------+ Data Link "B" 531 +----- | OMNI Interface |--------+ 532 / +-----------------+ \ 533 / \ 534 / \ 535 (:::)-. (:::)-. 536 .-(:::::::::)<- (Radio) Access Networks ->.-(:::::::::) 537 `-(::::)-' `-(::::)-' 538 +-------+ +-------+ 539 ... | Proxy | ............................ | Proxy | ... 540 . +-------+ +-------+ . 541 . ^^ ^^ . 542 . || || . 543 . || +--------+ || . 544 . ++============> | s-ASBR | <============++ . 545 . +--------+ . 546 . | eBGP . 547 . (:::)-. . 548 . .-(::::::::) . 549 . .-(::: ATN/IPS :::)-. . 550 . (::::: BGP Routing ::::) . 551 . `-(:: System ::::)-' . 552 . `-(:::::::-' . 553 . . 554 . . 555 . <------- OMNI virtual link bridged by the OAL --------> . 556 ............................................................ 558 Figure 3: ATN/IPS ANET Architecture 560 When a Client logs into an ANET it specifies a nearby s-ASBR that it 561 has selected to connect to the ATN/IPS. (Selection of a nearby 562 s-ASBR could be through consulting a geographically-keyed static host 563 file, through a DNS lookup, through a network query response, etc.) 564 The login process is transparently brokered by a Proxy at the border 565 of the ANET, which then conveys the connection request to the s-ASBR 566 via tunneling across the OMNI virtual link. The s-ASBR then 567 registers the address of the Proxy as the address for the Client, and 568 the Proxy forwards the s-ASBR's reply to the Client. If the Client 569 connects to multiple ANETs, the s-ASBR will register the addresses of 570 all Proxies as addresses through which the Client can be reached. 572 The s-ASBR represents all of its active Clients as MNP-ULA routes in 573 the ATN/IPS BGP routing system. The s-ASBR's stub AS therefore 574 consists of the set of all of its active Clients (i.e., the stub AS 575 is a logical construct and not a physical construct). The s-ASBR 576 injects the MNP-ULAs of its active Clients and withdraws the MNP-ULAs 577 of its departed Clients via BGP updates to c-ASBRs, which further 578 propagate the MNP-ULAs to other c-ASBRs within the OAL AS. Since 579 Clients are expected to remain associated with their current s-ASBR 580 for extended periods, the level of MNP-ULA injections and withdrawals 581 in the BGP routing system will be on the order of the numbers of 582 network joins, leaves and s-ASBR handovers for aircraft operations 583 (see: Section 6). It is important to observe that fine-grained 584 events such as Client mobility and Quality of Service (QoS) signaling 585 are coordinated only by Proxies and the Client's current s-ASBRs, and 586 do not involve other ASBRs in the routing system. In this way, 587 intradomain routing changes within the stub AS are not propagated 588 into the rest of the ATN/IPS BGP routing system. 590 5. ATN/IPS Route Optimization 592 ATN/IPS end systems will frequently need to communicate with 593 correspondents associated with other s-ASBRs. In the BGP peering 594 topology discussed in Section 3, this can initially only be 595 accommodated by including multiple tunnel segments in the forwarding 596 path. In many cases, it would be desirable to eliminate extraneous 597 tunnel segments from this "dogleg" route so that packets can traverse 598 a minimum number of tunneling hops across the OMNI virtual link. 599 ATN/IPS end systems could therefore employ a route optimization 600 service according to the mobility service employed (see: Section 7). 602 A route optimization example is shown in Figure 4 and Figure 5 below. 603 In the first figure, multiple tunneled segments between Proxys and 604 ASBRs are necessary to convey packets between Clients associated with 605 different s-ASBRs. In the second figure, the optimized route tunnels 606 packets directly between Proxys without involving the ASBRs. 608 +---------+ +---------+ 609 | Client1 | | Client2 | 610 +---v-----+ +-----^---+ 611 * * 612 * * 613 (:::)-. (:::)-. 614 .-(:::::::::)<- (Radio) Access Networks ->.-(:::::::::) 615 `-(::::)-' `-(::::)-' 616 +--------+ +--------+ 617 ... | Proxy1 | .......................... | Proxy2 | ... 618 . +--------+ +--------+ . 619 . ** ** . 620 . ** ** . 621 . ** ** . 622 . +---------+ +---------+ . 623 . | s-ASBR1 | | s-ASBR2 | . 624 . +--+------+ +-----+---+ . 625 . \ ** Dogleg ** / . 626 . eBGP\ ** Route ** /eBGP . 627 . \ **==============** / . 628 . +---------+ +---------+ . 629 . | c-ASBR1 | | c-ASBR2 | . 630 . +---+-----+ +----+----+ . 631 . +--------------+ . 632 . iBGP . 633 . . 634 . <------- OMNI virtual link bridged by the OAL --------> . 635 ............................................................ 637 Figure 4: Dogleg Route Before Optimization 639 +---------+ +---------+ 640 | Client1 | | Client2 | 641 +---v-----+ +-----^---+ 642 * * 643 * * 644 (:::)-. (:::)-. 645 .-(:::::::::) <- (Radio) Access Networks ->.-(:::::::::) 646 `-(::::)-' `-(::::)-' 647 +--------+ +--------+ 648 ... | Proxy1 | .......................... | Proxy2 | ... 649 . +------v-+ +--^-----+ . 650 . * * . 651 . *================================* . 652 . . 653 . +---------+ +---------+ . 654 . | s-ASBR1 | | s-ASBR2 | . 655 . +--+------+ +-----+---+ . 656 . \ / . 657 . eBGP\ /eBGP . 658 . \ / . 659 . +---------+ +---------+ . 660 . | c-ASBR1 | | c-ASBR2 | . 661 . +---+-----+ +----+----+ . 662 . +--------------+ . 663 . iBGP . 664 . . 665 . <------- OMNI virtual link bridged by the OAL --------> . 666 ............................................................ 668 Figure 5: Optimized Route 670 6. BGP Protocol Considerations 672 The number of eBGP peering sessions that each c-ASBR must service is 673 proportional to the number of s-ASBRs in its local partition. 674 Network emulations with lightweight virtual machines have shown that 675 a single c-ASBR can service at least 100 eBGP peerings from s-ASBRs 676 that each advertise 10K MNP-ULA routes (i.e., 1M total). It is 677 expected that robust c-ASBRs can service many more peerings than this 678 - possibly by multiple orders of magnitude. But even assuming a 679 conservative limit, the number of s-ASBRs could be increased by also 680 increasing the number of c-ASBRs. Since c-ASBRs also peer with each 681 other using iBGP, however, larger-scale c-ASBR deployments may need 682 to employ an adjunct facility such as BGP Route Reflectors 683 (RRs)[RFC4456]. 685 The number of aircraft in operation at a given time worldwide is 686 likely to be significantly less than 1M, but we will assume this 687 number for a worst-case analysis. Assuming a worst-case average 1 688 hour flight profile from gate-to-gate with 10 service region 689 transitions per flight, the entire system will need to service at 690 most 10M BGP updates per hour (2778 updates per second). This number 691 is within the realm of the peak BGP update messaging seen in the 692 global public Internet today [BGP2]. Assuming a BGP update message 693 size of 100 bytes (800bits), the total amount of BGP control message 694 traffic to a single c-ASBR will be less than 2.5Mbps which is a 695 nominal rate for modern data links. 697 Industry standard BGP routers provide configurable parameters with 698 conservative default values. For example, the default hold time is 699 90 seconds, the default keepalive time is 1/3 of the hold time, and 700 the default MinRouteAdvertisementinterval is 30 seconds for eBGP 701 peers and 5 seconds for iBGP peers (see Section 10 of [RFC4271]). 702 For the simple mobile routing system described herein, these 703 parameters can be set to more aggressive values to support faster 704 neighbor/link failure detection and faster routing protocol 705 convergence times. For example, a hold time of 3 seconds and a 706 MinRouteAdvertisementinterval of 0 seconds for both iBGP and eBGP. 708 Instead of adjusting BGP default time values, BGP routers can use the 709 Bidirectional Forwarding Detection (BFD) protocol [RFC5880] to 710 quickly detect link failures that don't result in interface state 711 changes, BGP peer failures, and administrative state changes. BFD is 712 important in environments where rapid response to failures is 713 required for routing reconvergence and, hence, communications 714 continuity. 716 Each c-ASBR will be using eBGP both in the ATN/IPS and the INET with 717 the ATN/IPS unicast IPv6 routes resolving over INET routes. 718 Consequently, c-ASBRs and potentially s-ASBRs will need to support 719 separate local ASes for the two BGP routing domains and routing 720 policy or assure routes are not propagated between the two BGP 721 routing domains. From a conceptual and operational standpoint, the 722 implementation should provide isolation between the two BGP routing 723 domains (e.g., separate BGP instances). 725 ADM-ULAs and MNP-ULAs begin with fd00::/8 followed by a pseudo-random 726 40-bit global ID to form the prefix [ULA]::/48, along with a 16-bit 727 OMNI link identifier '*' to form the prefix [ULA*]::/64. Each 728 individual address taken from [ULA*]::/64 includes additional routing 729 information in the interface identifier. For example, for the MNP 730 2001:db8:1:0::/56, the resulting MNP-ULA is [ULA*]:2001:db8:1:0/120, 731 and for the administrative address 1001/8 the ADM-ULA is 732 [ULA*]::1001/120 (see: [I-D.templin-6man-omni-interface] for further 733 details). This gives rise to a BGP routing system that must 734 accommodate large numbers of long and non-aggregatable MNP-ULA 735 prefixes as well as moderate numbers of long and semi-aggregatable 736 ADM-ULA prefixes. The system is kept stable and scalable through the 737 s-ASBR / c-ASBR hub-and-spokes topology which ensures that mobility- 738 related churn is not exposed to the core. 740 7. Stub AS Mobile Routing Services 742 Stub ASes maintain intradomain routing information for mobile node 743 clients, and are responsible for all localized mobility signaling 744 without disturbing the BGP routing system. Clients can enlist the 745 services of a candidate mobility service such as Mobile IPv6 (MIPv6) 746 [RFC6275], LISP [I-D.ietf-lisp-rfc6830bis] and AERO 747 [I-D.templin-intarea-6706bis] according to the service offered by the 748 stub AS. Further details of mobile routing services are out of scope 749 for this document. 751 8. Implementation Status 753 The BGP routing topology described in this document has been modeled 754 in realistic network emulations showing that at least 1 million MNP- 755 ULAs can be propagated to each c-ASBR even on lightweight virtual 756 machines. No BGP routing protocol extensions need to be adopted. 758 9. IANA Considerations 760 This document does not introduce any IANA considerations. 762 10. Security Considerations 764 ATN/IPS ASBRs on the open Internet are susceptible to the same attack 765 profiles as for any Internet nodes. For this reason, ASBRs should 766 employ physical security and/or IP securing mechanisms such as IPsec 767 [RFC4301], TLS [RFC5246], etc. 769 ATN/IPS ASBRs present targets for Distributed Denial of Service 770 (DDoS) attacks. This concern is no different than for any node on 771 the open Internet, where attackers could send spoofed packets to the 772 node at high data rates. This can be mitigated by connecting ATN/IPS 773 ASBRs over dedicated links with no connections to the Internet and/or 774 when ASBR connections to the Internet are only permitted through 775 well-managed firewalls. 777 ATN/IPS s-ASBRs should institute rate limits to protect low data rate 778 aviation data links from receiving DDoS packet floods. 780 BGP protocol message exchanges and control message exchanges used for 781 route optimization must be secured to ensure the integrity of the 782 system-wide routing information base. 784 This document does not include any new specific requirements for 785 mitigation of DDoS. 787 11. Acknowledgements 789 This work is aligned with the FAA as per the SE2025 contract number 790 DTFAWA-15-D-00030. 792 This work is aligned with the NASA Safe Autonomous Systems Operation 793 (SASO) program under NASA contract number NNA16BD84C. 795 This work is aligned with the Boeing Commercial Airplanes (BCA) 796 Internet of Things (IoT) and autonomy programs. 798 This work is aligned with the Boeing Information Technology (BIT) 799 MobileNet program. 801 The following individuals contributed insights that have improved the 802 document: Ahmad Amin, Erik Kline, Hubert Kuenig, Tony Li, Alexandre 803 Petrescu, Pascal Thubert, Tony Whyman. 805 12. References 807 12.1. Normative References 809 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 810 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 811 December 1998, . 813 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 814 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 815 . 817 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 818 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 819 DOI 10.17487/RFC4271, January 2006, 820 . 822 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 823 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 824 2006, . 826 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 827 Control Message Protocol (ICMPv6) for the Internet 828 Protocol Version 6 (IPv6) Specification", STD 89, 829 RFC 4443, DOI 10.17487/RFC4443, March 2006, 830 . 832 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 833 Reflection: An Alternative to Full Mesh Internal BGP 834 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 835 . 837 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 838 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 839 . 841 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 842 (IPv6) Specification", STD 86, RFC 8200, 843 DOI 10.17487/RFC8200, July 2017, 844 . 846 12.2. Informative References 848 [ATN] Maiolla, V., "The OMNI Interface - An IPv6 Air/Ground 849 Interface for Civil Aviation, IETF Liaison Statement 850 #1676, https://datatracker.ietf.org/liaison/1676/", March 851 2020. 853 [ATN-IPS] WG-I, ICAO., "ICAO Document 9896 (Manual on the 854 Aeronautical Telecommunication Network (ATN) using 855 Internet Protocol Suite (IPS) Standards and Protocol), 856 Draft Edition 3 (work-in-progress)", December 2020. 858 [BGP] Huston, G., "BGP in 2015, http://potaroo.net", January 859 2016. 861 [BGP2] Huston, G., "BGP Instability Report, 862 http://bgpupdates.potaroo.net/instability/bgpupd.html", 863 May 2017. 865 [CBB] Dul, A., "Global IP Network Mobility using Border Gateway 866 Protocol (BGP), http://www.quark.net/docs/ 867 Global_IP_Network_Mobility_using_BGP.pdf", March 2006. 869 [I-D.ietf-lisp-rfc6830bis] 870 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 871 Cabellos-Aparicio, "The Locator/ID Separation Protocol 872 (LISP)", draft-ietf-lisp-rfc6830bis-36 (work in progress), 873 November 2020. 875 [I-D.templin-6man-omni-interface] 876 Templin, F. and T. Whyman, "Transmission of IP Packets 877 over Overlay Multilink Network (OMNI) Interfaces", draft- 878 templin-6man-omni-interface-61 (work in progress), 879 December 2020. 881 [I-D.templin-intarea-6706bis] 882 Templin, F., "Asymmetric Extended Route Optimization 883 (AERO)", draft-templin-intarea-6706bis-80 (work in 884 progress), December 2020. 886 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 887 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 888 DOI 10.17487/RFC2784, March 2000, 889 . 891 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 892 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 893 December 2005, . 895 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 896 (TLS) Protocol Version 1.2", RFC 5246, 897 DOI 10.17487/RFC5246, August 2008, 898 . 900 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 901 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 902 2011, . 904 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 905 Autonomous System (AS) Number Space", RFC 6793, 906 DOI 10.17487/RFC6793, December 2012, 907 . 909 Appendix A. BGP Convergence Considerations 911 Experimental evidence has shown that BGP convergence time required 912 for when an MNP-ULA is asserted at a new location or withdrawn from 913 an old location can be several hundred milliseconds even under 914 optimal AS peering arrangements. This means that packets in flight 915 destined to an MNP-ULA route that has recently been changed can be 916 (mis)delivered to an old s-ASBR after a Client has moved to a new 917 s-ASBR. 919 To address this issue, the old s-ASBR can maintain temporary state 920 for a "departed" Client that includes an OAL address for the new 921 s-ASBR. The OAL address never changes since ASBRs are fixed 922 infrastructure elements that never move. Hence, packets arriving at 923 the old s-ASBR can be forwarded to the new s-ASBR while the BGP 924 routing system is still undergoing reconvergence. Therefore, as long 925 as the Client associates with the new s-ASBR before it departs from 926 the old s-ASBR (while informing the old s-ASBR of its new location) 927 packets in flight during the BGP reconvergence window are 928 accommodated without loss. 930 Appendix B. Change Log 932 << RFC Editor - remove prior to publication >> 934 Changes from -05 to -06: 936 o OMNI interface introduced 938 o Version and reference update. 940 Changes from -04 to -05: 942 o Version and reference update. 944 Changes from -03 to -04: 946 o added discussion of Bidirectional Forwarding Detection (BFD). 948 Changes from -02 to -03: 950 o added reference to ICAO A/G interface specification. 952 Changes from -01 to -02: 954 o introduced the SPAN and the concept of Internetwork partitioning 956 o new terms "ANET" (for (Radio) Access Network) and "INET" (for 957 Internetworking underlay) 959 o new appendix on BGP convergence considerations 961 Changes from -00 to -01: 963 o incorporated clarifications due to list comments and questions. 965 o new section 7 on Stub AS Mobile Routing Services 967 o updated references, and included new reference for MIPv6 and LISP 969 Status as of 08/30/2018: 971 o 'draft-templin-atn-bgp' becomes 'draft-ietf-rtgwg-atn-bgp' 973 Authors' Addresses 974 Fred L. Templin (editor) 975 Boeing Research & Technology 976 P.O. Box 3707 977 Seattle, WA 98124 978 USA 980 Email: fltemplin@acm.org 982 Greg Saccone 983 Boeing Research & Technology 984 P.O. Box 3707 985 Seattle, WA 98124 986 USA 988 Email: gregory.t.saccone@boeing.com 990 Gaurav Dawra 991 LinkedIn 992 USA 994 Email: gdawra.ietf@gmail.com 996 Acee Lindem 997 Cisco Systems, Inc. 998 USA 1000 Email: acee@cisco.com 1002 Victor Moreno 1003 Cisco Systems, Inc. 1004 USA 1006 Email: vimoreno@cisco.com