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