idnits 2.17.1 draft-ietf-rtgwg-atn-bgp-03.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 (November 22, 2019) is 1616 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-27 == Outdated reference: A later version (-21) exists of draft-templin-atn-aero-interface-07 == Outdated reference: A later version (-99) exists of draft-templin-intarea-6706bis-17 -- 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: May 25, 2020 G. Dawra 6 LinkedIn 7 A. Lindem 8 V. Moreno 9 Cisco Systems, Inc. 10 November 22, 2019 12 A Simple BGP-based Mobile Routing System for the Aeronautical 13 Telecommunications Network 14 draft-ietf-rtgwg-atn-bgp-03.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 May 25, 2020. 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 The Client uses an Air-to-Ground (A/G) interface to log into 520 individual ANETs. The A/G interface specification for the ATN/IPS is 521 under development in an ancillary document 522 [I-D.templin-atn-aero-interface]. 524 When a Client logs into an ANET it specifies a nearby s-ASBR that it 525 has selected to connect to the ATN/IPS. (Selection of a nearby 526 s-ASBR could be through consulting a geographically-keyed static host 527 file, through a DNS lookup, through a network query response, etc.) 528 The login process is transparently brokered by a Proxy at the border 529 of the ANET, which then conveys the connection request to the s-ASBR 530 via tunneling across the SPAN. The s-ASBR then registers the address 531 of the Proxy as the address for the Client, and the Proxy forwards 532 the s-ASBR's reply to the Client. If the Client connects to multiple 533 ANETs, the s-ASBR will register the addresses of all Proxies as 534 addresses through which the Client can be reached. 536 The s-ASBR represents all of its active Clients as MNP routes in the 537 ATN/IPS BGP routing system. The s-ASBR's stub AS therefore consists 538 of the set of all of its active Clients (i.e., the stub AS is a 539 logical construct and not a physical construct). The s-ASBR injects 540 the MNPs of its active Clients and withdraws the MNPs of its departed 541 Clients via BGP updates to c-ASBRs, which further propagate the MNPs 542 to other c-ASBRs within the SPAN AS. Since Clients are expected to 543 remain associated with their current s-ASBR for extended periods, the 544 level of MNP injections and withdrawals in the BGP routing system 545 will be on the order of the numbers of network joins, leaves and 546 s-ASBR handovers for aircraft operations (see: Section 6). It is 547 important to observe that fine-grained events such as Client mobility 548 and Quality of Service (QoS) signaling are coordinated only by 549 Proxies and the Client's current s-ASBRs, and do not involve other 550 ASBRs in the routing system. In this way, intradomain routing 551 changes within the stub AS are not propagated into the rest of the 552 ATN/IPS BGP routing system. 554 5. ATN/IPS Route Optimization 556 ATN/IPS end systems will frequently need to communicate with 557 correspondents associated with other s-ASBRs. In the BGP peering 558 topology discussed in Section 3, this can initially only be 559 accommodated by including multiple tunnel segments in the forwarding 560 path. In many cases, it would be desirable to eliminate extraneous 561 tunnel segments from this "dogleg" route so that packets can traverse 562 a minimum number of tunneling hops across the SPAN. ATN/IPS end 563 systems could therefore employ a route optimization service according 564 to the mobility service employed (see: Section 7). 566 A route optimization example is shown in Figure 4 and Figure 5 below. 567 In the first figure, multiple tunneled segments between Proxys and 568 ASBRs are necessary to convey packets between Clients associated with 569 different s-ASBRs. In the second figure, the optimized route tunnels 570 packets directly between Proxys without involving the ASBRs. 572 +---------+ +---------+ 573 | Client1 | | Client2 | 574 +---v-----+ +-----^---+ 575 * * 576 * * 577 (:::)-. (:::)-. 578 .-(:::::::::)<- (Radio) Access Networks ->.-(:::::::::) 579 `-(::::)-' `-(::::)-' 580 +--------+ +--------+ 581 ... | Proxy1 | .......................... | Proxy2 | ... 582 . +--------+ +--------+ . 583 . ** ** . 584 . ** ** . 585 . ** ** . 586 . +---------+ +---------+ . 587 . | s-ASBR1 | | s-ASBR2 | . 588 . +--+------+ +-----+---+ . 589 . \ ** Dogleg ** / . 590 . eBGP\ ** Route ** /eBGP . 591 . \ **==============** / . 592 . +---------+ +---------+ . 593 . | c-ASBR1 | | c-ASBR2 | . 594 . +---+-----+ +----+----+ . 595 . +--------------+ . 596 . iBGP . 597 . . 598 . <------- ATN/IPS Overlay bridged by the SPAN --------> . 599 ............................................................ 601 Figure 4: Dogleg Route Before Optimization 603 +---------+ +---------+ 604 | Client1 | | Client2 | 605 +---v-----+ +-----^---+ 606 * * 607 * * 608 (:::)-. (:::)-. 609 .-(:::::::::) <- (Radio) Access Networks ->.-(:::::::::) 610 `-(::::)-' `-(::::)-' 611 +--------+ +--------+ 612 ... | Proxy1 | .......................... | Proxy2 | ... 613 . +------v-+ +--^-----+ . 614 . * * . 615 . *================================* . 616 . . 617 . +---------+ +---------+ . 618 . | s-ASBR1 | | s-ASBR2 | . 619 . +--+------+ +-----+---+ . 620 . \ / . 621 . eBGP\ /eBGP . 622 . \ / . 623 . +---------+ +---------+ . 624 . | c-ASBR1 | | c-ASBR2 | . 625 . +---+-----+ +----+----+ . 626 . +--------------+ . 627 . iBGP . 628 . . 629 . <------- ATN/IPS Overlay bridged by the SPAN --------> . 630 ............................................................ 632 Figure 5: Optimized Route 634 6. BGP Protocol Considerations 636 The number of eBGP peering sessions that each c-ASBR must service is 637 proportional to the number of s-ASBRs in its local partition. 638 Network emulations with lightweight virtual machines have shown that 639 a single c-ASBR can service at least 100 eBGP peerings from s-ASBRs 640 that each advertise 10K MNP routes (i.e., 1M total). It is expected 641 that robust c-ASBRs can service many more peerings than this - 642 possibly by multiple orders of magnitude. But even assuming a 643 conservative limit, the number of s-ASBRs could be increased by also 644 increasing the number of c-ASBRs. Since c-ASBRs also peer with each 645 other using iBGP, however, larger-scale c-ASBR deployments may need 646 to employ an adjunct facility such as BGP Route Reflectors 647 (RRs)[RFC4456]. 649 The number of aircraft in operation at a given time worldwide is 650 likely to be significantly less than 1M, but we will assume this 651 number for a worst-case analysis. Assuming a worst-case average 1 652 hour flight profile from gate-to-gate with 10 service region 653 transitions per flight, the entire system will need to service at 654 most 10M BGP updates per hour (2778 updates per second). This number 655 is within the realm of the peak BGP update messaging seen in the 656 global public Internet today [BGP2]. Assuming a BGP update message 657 size of 100 bytes (800bits), the total amount of BGP control message 658 traffic to a single c-ASBR will be less than 2.5Mbps which is a 659 nominal rate for modern data links. 661 Industry standard BGP routers provide configurable parameters with 662 conservative default values. For example, the default hold time is 663 90 seconds, the default keepalive time is 1/3 of the hold time, and 664 the default MinRouteAdvertisementinterval is 30 seconds for eBGP 665 peers and 5 seconds for iBGP peers (see Section 10 of [RFC4271]). 666 For the simple mobile routing system described herein, these 667 parameters can and should be set to more aggressive values to support 668 faster neighbor/link failure detection and faster routing protocol 669 convergence times. For example, a hold time of 3 seconds and a 670 MinRouteAdvertisementinterval of 0 seconds for both iBGP and eBGP. 672 Each c-ASBR will be using eBGP both in the ATN/IPS and the INET with 673 the ATN/IPS unicast IPv6 routes resolving over INET routes. 674 Consequently, c-ASBRs and potentially s-ASBRs will need to support 675 separate local ASes for the two BGP routing domains and routing 676 policy or assure routes are not propagated between the two BGP 677 routing domains. From a conceptual and operational standpoint, the 678 implementation should provide isolation between the two BGP routing 679 domains (e.g., separate BGP instances). 681 7. Stub AS Mobile Routing Services 683 Stub ASes maintain intradomain routing information for mobile node 684 clients, and are responsible for all localized mobility signaling 685 without disturbing the BGP routing system. Clients can enlist the 686 services of a candidate mobility service such as Mobile IPv6 (MIPv6) 687 [RFC6275], LISP [I-D.ietf-lisp-rfc6830bis] and AERO 688 [I-D.templin-intarea-6706bis] according to the service offered by the 689 stub AS. Further details of mobile routing services are out of scope 690 for this document. 692 8. Implementation Status 694 The BGP routing topology described in this document has been modeled 695 in realistic network emulations showing that at least 1 million MNPs 696 can be propagated to each c-ASBR even on lightweight virtual 697 machines. No BGP routing protocol extensions need to be adopted. 699 9. IANA Considerations 701 This document does not introduce any IANA considerations. 703 10. Security Considerations 705 ATN/IPS ASBRs on the open Internet are susceptible to the same attack 706 profiles as for any Internet nodes. For this reason, ASBRs should 707 employ physical security and/or IP securing mechanisms such as IPsec 708 [RFC4301], TLS [RFC5246], etc. 710 ATN/IPS ASBRs present targets for Distributed Denial of Service 711 (DDoS) attacks. This concern is no different than for any node on 712 the open Internet, where attackers could send spoofed packets to the 713 node at high data rates. This can be mitigated by connecting ATN/IPS 714 ASBRs over dedicated links with no connections to the Internet and/or 715 when ASBR connections to the Internet are only permitted through 716 well-managed firewalls. 718 ATN/IPS s-ASBRs should institute rate limits to protect low data rate 719 aviation data links from receiving DDoS packet floods. 721 BGP protocol message exchanges and control message exchanges used for 722 route optimization must be secured to ensure the integrity of the 723 system-wide routing information base. 725 This document does not include any new specific requirements for 726 mitigation of DDoS. 728 11. Acknowledgements 730 This work is aligned with the FAA as per the SE2025 contract number 731 DTFAWA-15-D-00030. 733 This work is aligned with the NASA Safe Autonomous Systems Operation 734 (SASO) program under NASA contract number NNA16BD84C. 736 This work is aligned with the Boeing Information Technology (BIT) 737 MobileNet program. 739 The following individuals contributed insights that have improved the 740 document: Erik Kline, Hubert Kuenig, Tony Li, Alexandre Petrescu, 741 Pascal Thubert, Tony Whyman. 743 12. References 745 12.1. Normative References 747 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 748 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 749 DOI 10.17487/RFC4271, January 2006, 750 . 752 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 753 Control Message Protocol (ICMPv6) for the Internet 754 Protocol Version 6 (IPv6) Specification", STD 89, 755 RFC 4443, DOI 10.17487/RFC4443, March 2006, 756 . 758 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 759 Reflection: An Alternative to Full Mesh Internal BGP 760 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 761 . 763 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 764 (IPv6) Specification", STD 86, RFC 8200, 765 DOI 10.17487/RFC8200, July 2017, 766 . 768 12.2. Informative References 770 [BGP] Huston, G., "BGP in 2015, http://potaroo.net", January 771 2016. 773 [BGP2] Huston, G., "BGP Instability Report, 774 http://bgpupdates.potaroo.net/instability/bgpupd.html", 775 May 2017. 777 [CBB] Dul, A., "Global IP Network Mobility using Border Gateway 778 Protocol (BGP), http://www.quark.net/docs/ 779 Global_IP_Network_Mobility_using_BGP.pdf", March 2006. 781 [I-D.ietf-lisp-rfc6830bis] 782 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 783 Cabellos-Aparicio, "The Locator/ID Separation Protocol 784 (LISP)", draft-ietf-lisp-rfc6830bis-27 (work in progress), 785 June 2019. 787 [I-D.templin-atn-aero-interface] 788 Templin, F., "Transmission of IPv6 Packets over 789 Aeronautical ("aero") Interfaces", draft-templin-atn-aero- 790 interface-07 (work in progress), September 2019. 792 [I-D.templin-intarea-6706bis] 793 Templin, F., "Asymmetric Extended Route Optimization 794 (AERO)", draft-templin-intarea-6706bis-17 (work in 795 progress), August 2019. 797 [ICAO] ICAO, I., "http://www.icao.int/Pages/default.aspx", 798 February 2017. 800 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 801 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 802 DOI 10.17487/RFC2784, March 2000, 803 . 805 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 806 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 807 December 2005, . 809 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 810 (TLS) Protocol Version 1.2", RFC 5246, 811 DOI 10.17487/RFC5246, August 2008, 812 . 814 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 815 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 816 2011, . 818 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 819 Autonomous System (AS) Number Space", RFC 6793, 820 DOI 10.17487/RFC6793, December 2012, 821 . 823 Appendix A. BGP Convergence Considerations 825 Experimental evidence has shown that BGP convergence time required 826 for when an MNP is asserted at a new location or withdrawn from an 827 old location can be several hundred milliseconds even under optimal 828 AS peering arrangements. This means that packets in flight destined 829 to an MNP route that has recently been changed can be (mis)delivered 830 to an old s-ASBR after a Client has moved to a new s-ASBR. 832 To address this issue, the old s-ASBR can maintain temporary state 833 for a "departed" Client that includes a SPAN address for the new 834 s-ASBR. The SPAN address never changes since ASBRs are fixed 835 infrastructure elements that never move. Hence, packets arriving at 836 the old s-ASBR can be forwarded to the new s-ASBR while the BGP 837 routing system is still undergoing reconvergence. Therefore, as long 838 as the Client associates with the new s-ASBR before it departs from 839 the old s-ASBR (while informing the old s-ASBR of its new location) 840 packets in flight during the BGP reconvergence window are 841 accommodated without loss. 843 Appendix B. Change Log 845 << RFC Editor - remove prior to publication >> 847 Changes from -02 to -03: 849 o added reference to ICAO A/G interface specification. 851 Changes from -01 to -02: 853 o introduced the SPAN and the concept of Internetwork partitioning 855 o new terms "ANET" (for (Radio) Access Network) and "INET" (for 856 Internetworking underlay) 858 o new appendix on BGP convergence considerations 860 Changes from -00 to -01: 862 o incorporated clarifications due to list comments and questions. 864 o new section 7 on Stub AS Mobile Routing Services 866 o updated references, and included new reference for MIPv6 and LISP 868 Status as of 08/30/2018: 870 o 'draft-templin-atn-bgp' becomes 'draft-ietf-rtgwg-atn-bgp' 872 Authors' Addresses 874 Fred L. Templin (editor) 875 Boeing Research & Technology 876 P.O. Box 3707 877 Seattle, WA 98124 878 USA 880 Email: fltemplin@acm.org 881 Greg Saccone 882 Boeing Research & Technology 883 P.O. Box 3707 884 Seattle, WA 98124 885 USA 887 Email: gregory.t.saccone@boeing.com 889 Gaurav Dawra 890 LinkedIn 891 USA 893 Email: gdawra.ietf@gmail.com 895 Acee Lindem 896 Cisco Systems, Inc. 897 USA 899 Email: acee@cisco.com 901 Victor Moreno 902 Cisco Systems, Inc. 903 USA 905 Email: vimoreno@cisco.com