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