--- 1/draft-templin-atn-bgp-07.txt 2018-08-16 14:13:08.025711587 -0700 +++ 2/draft-templin-atn-bgp-08.txt 2018-08-16 14:13:08.049711932 -0700 @@ -1,23 +1,24 @@ Network Working Group F. Templin, Ed. Internet-Draft G. Saccone Intended status: Informational Boeing Research & Technology -Expires: December 2, 2018 G. Dawra +Expires: February 17, 2019 G. Dawra LinkedIn A. Lindem + V. Moreno Cisco Systems, Inc. - May 31, 2018 + August 16, 2018 A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network - draft-templin-atn-bgp-07.txt + draft-templin-atn-bgp-08.txt Abstract The International Civil Aviation Organization (ICAO) is investigating mobile routing solutions for a worldwide Aeronautical Telecommunications Network with Internet Protocol Services (ATN/IPS). The ATN/IPS will eventually replace existing communication services with an IPv6-based service supporting pervasive Air Traffic Management (ATM) for Air Traffic Controllers (ATC), Airline Operations Controllers (AOC), and all commercial aircraft worldwide. @@ -33,21 +34,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 2, 2018. + This Internet-Draft will expire on February 17, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -65,28 +66,29 @@ 4. ATN/IPS Radio Access Network (RAN) Model . . . . . . . . . . 9 5. ATN/IPS Route Optimization . . . . . . . . . . . . . . . . . 11 6. BGP Protocol Considerations . . . . . . . . . . . . . . . . . 13 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 16 + Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction The worldwide Air Traffic Management (ATM) system today uses a service known as Aeronautical Telecommunications Network based on Open Systems Interconnection (ATN/OSI). The service is used to - augment controller to pilot voice communications with rudimenatary + augment controller to pilot voice communications with rudimentary short text command and control messages. The service has seen successful deployment in a limited set of worldwide ATM domains. The International Civil Aviation Organization [ICAO] is now undertaking the development of a next-generation replacement for ATN/ OSI known as Aeronautical Telecommunications Network with Internet Protocol Services (ATN/IPS). ATN/IPS will eventually provide an IPv6-based [RFC8200] service supporting pervasive ATM for Air Traffic Controllers (ATC), Airline Operations Controllers (AOC), and all commercial aircraft worldwide. As part of the ATN/IPS undertaking, a @@ -113,33 +115,37 @@ communications. The Internetworking underlay could be manifested as a private collection of long-haul backbone links (e.g., fiberoptics, copper, SATCOM, etc.) interconnected by high-performance networking gear such as bridges, switches, and routers. Such a private network would need to connect all ATN/IPS participants worldwide, and could therefore present a considerable cost for a large-scale deployment of new infrastructure. Alternatively, the ATN/IPS could be deployed as a secured overlay over the existing global public Internet. For example, ATN/IPS nodes could be deployed as part of an SD-WAN or an MPLS-WAN that rides over the public Internet via secured tunnels. + Further details of the Internetworking underlay design are out of + scope for this document. The ATN/IPS further assumes that each aircraft will receive an IPv6 Mobile Network Prefix (MNP) that accompanies the aircraft wherever it - travels. ATCs and AOCs will likewise receive IPv6 prefixes, but they - would typically appear in static (not mobile) deployments such as air - traffic control towers, airline headquarters, etc. Throughout the - rest of this document, we therefore use the term "MNP" when - discussing an IPv6 prefix that is delegated to any ATN/IPS end - system, including ATCs, AOCs, and aircraft. We also use the term - Mobility Service Prefix (MSP) to refer to an aggregated prefix - assigned to the ATN/IPS by an Internet assigned numbers authority, - and from which all MNPs are delegated (e.g., up to 2**32 IPv6 /64 - MNPs could be delegated from the MSP 2001:db8::/32). + travels. ICAO is further proposing to assign each aircraft an entire + /56 MNP for numbering its on-board networks. ATCs and AOCs will + likewise receive IPv6 prefixes, but they would typically appear in + static (not mobile) deployments such as air traffic control towers, + airline headquarters, etc. Throughout the rest of this document, we + therefore use the term "MNP" when discussing an IPv6 prefix that is + delegated to any ATN/IPS end system, including ATCs, AOCs, and + aircraft. We also use the term Mobility Service Prefix (MSP) to + refer to an aggregated prefix assigned to the ATN/IPS by an Internet + assigned numbers authority, and from which all MNPs are delegated + (e.g., up to 2**32 IPv6 /56 MNPs could be delegated from an IPv6 /24 + MSP). Connexion By Boeing [CBB] was an early aviation mobile routing service based on dynamic updates in the global public Internet BGP routing system. Practical experience with the approach has shown that frequent injections and withdrawals of MNPs in the Internet routing system can result in excessive BGP update messaging, slow routing table convergence times, and extended outages when no route is available. This is due to both conservative default BGP protocol timing parameters (see Section 6) and the complex peering interconnections of BGP routers within the global Internet @@ -154,21 +160,21 @@ private BGP instance does not interact with the native BGP routing system in the connected Internetworking underlay, and BGP updates are unidirectional from "stub" ASBRs (s-ASBRs) to a small set of "core" ASBRs (c-ASBRs) in a hub-and-spokes topology. No extensions to the BGP protocol are necessary. The s-ASBRs for each stub AS connect to a small number of c-ASBRs via dedicated high speed links and/or tunnels across the Internetworking underlay using industry-standard encapsulations (e.g., Generic Routing Encapsulation (GRE) [RFC2784], IPsec [RFC4301], etc.). In - particular, tunneling must be used when neighboringing ASBRs are + particular, tunneling must be used when neighboring ASBRs are separated by many Internetworking underlay hops. The s-ASBRs engage in external BGP (eBGP) peerings with their respective c-ASBRs, and only maintain routing table entries for the MNPs currently active within the stub AS. The s-ASBRs send BGP updates for MNP injections or withdrawals to c-ASBRs but do not receive any BGP updates from c-ASBRs. Instead, the s-ASBRs maintain default routes with their c-ASBRs as the next hop, and therefore hold only partial topology information. @@ -186,21 +192,21 @@ The remainder of this document discusses the proposed BGP-based ATN/ IPS mobile routing service. 2. Terminology The terms Autonomous System (AS) and Autonomous System Border Router (ASBR) are the same as defined in [RFC4271]. The following terms are defined for the purposes of this document: - Air Traffic Managemnet (ATM) + Air Traffic Management (ATM) The worldwide service for coordinating safe aviation operations. Air Traffic Controller (ATC) A government agent responsible for coordinating with aircraft within a defined operational region via voice and/or data Command and Control messaging. Airline Operations Controller (AOC) An airline agent responsible for tracking and coordinating with aircraft within their fleet. @@ -211,21 +217,21 @@ aircraft operating worldwide. The ATN/IPS will be an IPv6-based overlay network service that connects access networks via tunneling over an Internetworking underlay. Internetworking underlay A connected wide-area network that supports overlay network tunneling and connects Radio Access Networks to the rest of the ATN/IPS. Radio Access Network (RAN) An aviation radio data link service provider's network, including - radio transmitters and receivers as well as suppporting ground- + radio transmitters and receivers as well as supporting ground- domain infrastructure needed to convey a customer's data packets to the outside world. The term RAN is intended in the same spirit as for cellular operator networks and other radio-based Internet service provider networks. For simplicity, we also use the term RAN to refer to ground-domain networks that connect AOCs and ATCs without any aviation radio communications. Core Autonomous System Border Router (c-ASBR) A BGP router located in the hub of the ATN/IPS hub-and-spokes overlay network topology. @@ -248,46 +254,43 @@ Proxy presents the appearance that the Client is communicating directly with the s-ASBR. From the s-ASBR's perspective, the Proxy presents the appearance that the s-ASBR is communicating directly with the Client. Mobile Network Prefix (MNP) An IPv6 prefix that is delegated to any ATN/IPS end system, including ATCs, AOCs, and aircraft. Mobility Service Prefix (MSP) An aggregated prefix assigned to the ATN/IPS by an Internet assigned numbers authority, and from which - all MNPs are delegated (e.g., up to 2**32 IPv6 /64 MNPs could be - delegated from the MSP 2001:db8::/32). + all MNPs are delegated (e.g., up to 2**32 IPv6 /56 MNPs could be + delegated from a /24 MSP). 3. ATN/IPS Routing System The proposed ATN/IPS routing system comprises a private BGP instance coordinated in an overlay network via tunnels between neighboring ASBRs over the Internetworking underlay. The overlay does not interact with the native BGP routing system in the connected - undelying Internetwork, and each c-ASBR advertises only a small and + underlying Internetwork, and each c-ASBR advertises only a small and unchanging set of MSPs into the Internetworking underlay routing system instead of the full dynamically changing set of MNPs. (For example, when the Internetworking underlay is the global public Internet the c-ASBRs advertise the MSPs in the public BGP Internet routing system.) In a reference deployment, one or more s-ASBRs connect each stub AS to the overlay using a shared stub AS Number (ASN). Each s-ASBR further uses eBGP to peer with one or more c-ASBRs. All c-ASBRs are - members of the same core AS, and use a shared core ASN. Since the - private BGP instance is separate from the global public Internet BGP - routing system, the ASBRs can use either a private ASN per [RFC6996] - or simply use public ASNs noting that the ASNs may overlap with those - already assigned in the Internet. (A third alternative would be to - procure globally-unique public ASNs, but cost and maintenance - requirements must be conisdered.) + members of the same core AS, and use a shared core ASN. Globally- + unique public ASNs could be assigned, e.g., either according to the + standard 16-bit ASN format or the 32-bit ASN scheme defined in + [RFC6793]. The c-ASBRs use iBGP to maintain a synchronized consistent view of all active MNPs currently in service. Figure 1 below represents the reference deployment. (Note that the figure shows details for only two s-ASBRs (s-ASBR1 and s-ASBR2) due to space constraints, but the other s-ASBRs should be understood to have similar Stub AS, MNP and eBGP peering arrangements.) The solution described in this document is flexible enough to extend to these topologies. ........................................................... @@ -354,38 +358,43 @@ study showed that BGP routers in the global public Internet at that time carried more than 500K routes with linear growth and no signs of router resource exhaustion [BGP]. A more recent network emulation study also showed that a single c-ASBR can accommodate at least 1M dynamically changing BGP routes even on a lightweight virtual machine. Commercially-available high-performance dedicated router hardware can support many millions of routes. Therefore, assuming each c-ASBR can carry 1M or more routes, this means that at least 1M ATN/IPS end system MNPs can be serviced by a - single set of c-ASBRs and that number could be furhter increased by - using RRs. Another means of increasing scale would be to assign a - different set of c-ASBRs for each set of MSPs. In that case, each - s-ASBR still peers with one or more c-ASBRs from each set of c-ASBRs, - but the s-ASBR institutes route filters so that it only sends BGP - updates to the specific set of c-ASBRs that aggregate the MSP. For - example, if the MSP for the ATN/IPS deployment is 2001:db8::/32, a - first set of c-ASBRs could service the MSP segment 2001:db8::/40, a - second set could service 2001:db8:0100::/40, a third set could - service 2001:db8:0200::/40, etc. + single set of c-ASBRs and that number could be further increased by + using RRs and/or more powerful routers. Another means of increasing + scale would be to assign a different set of c-ASBRs for each set of + MSPs. In that case, each s-ASBR still peers with one or more c-ASBRs + from each set of c-ASBRs, but the s-ASBR institutes route filters so + that it only sends BGP updates to the specific set of c-ASBRs that + aggregate the MSP. In this way, each set of c-ASBRs maintains + separate routing and forwarding tables so that scaling is distributed + across multiple c-ASBR sets instead of concentrated in a single + c-ASBR set. For example, a first c-ASBR set could aggregate an MSP + segment A::/32, a second set could aggregate B::/32, a third could + aggregate C::/32, etc. The union of all MSP segments would then + constitute the collective MSP(s) for the entire ATN/IPS. In this way, each set of c-ASBRs services a specific set of MSPs that they inject into the Internetworking underlay native routing system, and each s-ASBR configures MSP-specific routes that list the correct - set of c-ASBRs as next hops. This BGP routing design also allows for - natural incremental deployment, and can support initial small-scale + set of c-ASBRs as next hops. This design also allows for natural + incremental deployment, and can support initial medium-scale deployments followed by dynamic deployment of additional ATN/IPS infrastructure elements without disturbing the already-deployed base. + For example, a few more c-ASBRs could be added if the MNP service + demand ever outgrows the initial deployment. 4. ATN/IPS Radio Access Network (RAN) Model Radio Access Networks (RANs) connect end system Clients such as aircraft, ATCs, AOCs etc. to the ATN/IPS routing system. Clients may connect to multiple RANs at once, for example, when they have both satellite and cellular data links activated simultaneously. Clients may further move between RANs in a manner that is perceived as a network layer mobility event. Clients could therefore employ a multilink/mobility routing service such as that discussed in @@ -465,21 +474,21 @@ accommodated by including multiple tunnel segments in the forwarding path. In many cases, it would be desirable to eliminate extraneous tunnel segments from this "dogleg" route so that packets can traverse a minimum number of tunneling hops across the Internetworking underlay. ATN/IPS end systems could therefore employ a route optimization service such as that discussed in [I-D.templin-aerolink]. A route optimization example is shown in Figure 3 and Figure 4 below. In the first figure, multiple tunneled segments between Proxys and - ASBRs are necessary to convey packets between Clients associted with + ASBRs are necessary to convey packets between Clients associated with different s-ASBRs. In the second figure, the optimized route tunnels packets directly between Proxys without involving the ASBRs. +---------+ +---------+ | Client1 | | Client2 | +---v-----+ +-----^---+ * * * * (:::)-. (:::)-. .-(:::::::::) <- Radio Access Networks -> .-(:::::::::) @@ -681,23 +690,39 @@ [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . - [RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for - Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July - 2013, . + [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet + Autonomous System (AS) Number Space", RFC 6793, + DOI 10.17487/RFC6793, December 2012, + . + +Appendix A. Change Log + + << RFC Editor - remove prior to publication >> + + Changes from -07 to -08: + + o Removed suggestion to use private ASNs + + o Ran spelling checker and corrected errors + + o Re-worked Section 3 final two paragraphs on scaling + + o Stated Internetwork underlay as being out of scope for this + document Authors' Addresses Fred L. Templin (editor) Boeing Research & Technology P.O. Box 3707 Seattle, WA 98124 USA Email: fltemplin@acm.org @@ -714,10 +739,15 @@ LinkedIn USA Email: gdawra.ietf@gmail.com Acee Lindem Cisco Systems, Inc. USA Email: acee@cisco.com + Victor Moreno + Cisco Systems, Inc. + USA + + Email: vimoreno@cisco.com