< draft-ietf-rtgwg-atn-bgp-13.txt   draft-ietf-rtgwg-atn-bgp-14.txt >
Network Working Group F. L. Templin, Ed. Network Working Group F. L. Templin, Ed.
Internet-Draft G. Saccone Internet-Draft G. Saccone
Intended status: Informational Boeing Research & Technology Intended status: Informational Boeing Research & Technology
Expires: 11 August 2022 G. Dawra Expires: 18 August 2022 G. Dawra
LinkedIn LinkedIn
A. Lindem A. Lindem
V. Moreno V. Moreno
Cisco Systems, Inc. Cisco Systems, Inc.
7 February 2022 14 February 2022
A Simple BGP-based Mobile Routing System for the Aeronautical A Simple BGP-based Mobile Routing System for the Aeronautical
Telecommunications Network Telecommunications Network
draft-ietf-rtgwg-atn-bgp-13 draft-ietf-rtgwg-atn-bgp-14
Abstract Abstract
The International Civil Aviation Organization (ICAO) is investigating The International Civil Aviation Organization (ICAO) is investigating
mobile routing solutions for a worldwide Aeronautical mobile routing solutions for a worldwide Aeronautical
Telecommunications Network with Internet Protocol Services (ATN/IPS). Telecommunications Network with Internet Protocol Services (ATN/IPS).
The ATN/IPS will eventually replace existing communication services The ATN/IPS will eventually replace existing communication services
with an IP-based service supporting pervasive Air Traffic Management with an IP-based service supporting pervasive Air Traffic Management
(ATM) for Air Traffic Controllers (ATC), Airline Operations (ATM) for Air Traffic Controllers (ATC), Airline Operations
Controllers (AOC), and all commercial aircraft worldwide. This Controllers (AOC), and all commercial aircraft worldwide. This
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 11 August 2022. This Internet-Draft will expire on 18 August 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. ATN/IPS Routing System . . . . . . . . . . . . . . . . . . . 8 3. ATN/IPS Routing System . . . . . . . . . . . . . . . . . . . 9
4. ATN/IPS (Radio) Access Network (ANET) Model . . . . . . . . . 12 4. ATN/IPS (Radio) Access Network (ANET) Model . . . . . . . . . 14
5. ATN/IPS Route Optimization . . . . . . . . . . . . . . . . . 14 5. ATN/IPS Route Optimization . . . . . . . . . . . . . . . . . 16
6. BGP Protocol Considerations . . . . . . . . . . . . . . . . . 17 6. BGP Protocol Considerations . . . . . . . . . . . . . . . . . 19
7. Stub AS Mobile Routing Services . . . . . . . . . . . . . . . 19 7. Stub AS Mobile Routing Services . . . . . . . . . . . . . . . 21
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 19 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10.1. Public Key Infrastructure (PKI) Considerations . . . . . 20 10.1. Public Key Infrastructure (PKI) Considerations . . . . . 22
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
12.1. Normative References . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . 23
12.2. Informative References . . . . . . . . . . . . . . . . . 22 12.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. BGP Convergence Considerations . . . . . . . . . . . 24 Appendix A. BGP Convergence Considerations . . . . . . . . . . . 26
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 24 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
The worldwide Air Traffic Management (ATM) system today uses a The worldwide Air Traffic Management (ATM) system today uses a
service known as Aeronautical Telecommunications Network based on service known as Aeronautical Telecommunications Network based on
Open Systems Interconnection (ATN/OSI). The service is used to Open Systems Interconnection (ATN/OSI). The service is used to
augment controller to pilot voice communications with rudimentary augment controller to pilot voice communications with rudimentary
short text command and control messages. The service has seen short text command and control messages. The service has seen
successful deployment in a limited set of worldwide ATM domains. successful deployment in a limited set of worldwide ATM domains.
skipping to change at page 3, line 24 skipping to change at page 3, line 24
based data links only support data rates on the order of 32Kbps and based data links only support data rates on the order of 32Kbps and
an emerging L-Band data link that is expected to play a key role in an emerging L-Band data link that is expected to play a key role in
future aeronautical communications only supports rates on the order future aeronautical communications only supports rates on the order
of 1Mbps. Although satellite data links can provide much higher data of 1Mbps. Although satellite data links can provide much higher data
rates during optimal conditions, like any other aviation data link rates during optimal conditions, like any other aviation data link
they are subject to errors, delay, disruption, signal intermittence, they are subject to errors, delay, disruption, signal intermittence,
degradation due to atmospheric conditions, etc. The well-connected degradation due to atmospheric conditions, etc. The well-connected
ground domain ATN/IPS network should therefore treat each safety-of- ground domain ATN/IPS network should therefore treat each safety-of-
flight critical packet produced by (or destined to) an aircraft as a flight critical packet produced by (or destined to) an aircraft as a
precious commodity and strive for an optimized service that provides precious commodity and strive for an optimized service that provides
the highest possible degree of reliability. the highest possible degree of reliability. Furthermore, continuous
performance-intensive control messaging services such as BGP peering
sessions must be carried only over the well-connected ground domain
ATN/IPS network and never over low-end aviation data links.
The ATN/IPS is an IPv6-based overlay network configured over one or The ATN/IPS is an IP-based overlay network configured over one or
more Internetworking underlays ("INETs") maintained by aeronautical more Internetworking underlays ("INETs") maintained by aeronautical
network service providers such as ARINC, SITA and Inmarsat. The network service providers such as ARINC, SITA and Inmarsat. The
Overlay Multilink Network Interface (OMNI) [I-D.templin-6man-omni] Overlay Multilink Network Interface (OMNI) [I-D.templin-6man-omni]
uses an adaptation layer encapsulation to create a Non-Broadcast, uses an adaptation layer encapsulation to create a Non-Broadcast,
Multiple Access (NBMA) virtual link spanning the entire ATN/IPS. Multiple Access (NBMA) virtual link spanning the entire ATN/IPS.
Each aircraft connects to the OMNI link via an OMNI interface Each aircraft connects to the OMNI link via an OMNI interface
configured over the aircraft's underlying physical and/or virtual configured over the aircraft's underlying physical and/or virtual
access network interfaces. access network interfaces.
Each underlying INET comprises one or more "partitions" where all Each underlying INET comprises one or more "partitions" where all
nodes within a partition can exchange packets with all other nodes, nodes within a partition can exchange packets with all other nodes,
i.e., the partition is connected internally. There is no requirement i.e., the partition is connected internally. There is no requirement
that any two INET partitions use the same IP protocol version nor that each INET partition uses the same IP protocol version nor has
have consistent IP addressing plans in comparison with other consistent IP addressing plans in comparison with other partitions.
partitions. Instead, the OMNI link sees each partition as a Instead, the OMNI link sees each partition as a "segment" of a link-
"segment" of a link-layer topology concatenated by a service known as layer topology concatenated by a service known as the OMNI Adaptation
the OMNI Adaptation Layer (OAL) [I-D.templin-6man-omni] based on IPv6 Layer (OAL) [I-D.templin-6man-omni] based on IPv6 encapsulation
encapsulation [RFC2473]. [RFC2473].
The IPv6 addressing architecture provides different classes of The IPv6 addressing architecture provides different classes of
addresses, including Global Unicast Addresses (GUAs), Unique Local addresses, including Global Unicast Addresses (GUAs), Unique Local
Addresses (ULAs) and Link-Local Addresses (LLAs) [RFC4291][RFC4193]. Addresses (ULAs) and Link-Local Addresses (LLAs) [RFC4291][RFC4193].
The ATN/IPS receives an IPv6 GUA Mobility Service Prefix (MSP) from The ATN/IPS receives an IPv6 GUA Mobility Service Prefix (MSP) from
an Internet assigned numbers authority, and each aircraft will an Internet assigned numbers authority, and each aircraft will
receive a Mobile Network Prefix (MNP) delegation from the MSP that receive a Mobile Network Prefix (MNP) delegation from the MSP that
accompanies the aircraft wherever it travels. ATCs and AOCs will accompanies the aircraft wherever it travels. ATCs and AOCs will
likewise receive MNPs, but they would typically appear in static (not likewise receive MNPs, but they would typically appear in static (not
mobile) deployments such as air traffic control towers, airline mobile) deployments such as air traffic control towers, airline
headquarters, etc. (Note that while IPv6 GUAs are assumed for ATN/ headquarters, etc. (Note that while IPv6 GUAs are assumed for ATN/
IPS, IPv4 with public/private address could also be used.) IPS, IPv4 with public/private address could also be used.)
The adaptation layer uses ULAs in the source and destination The adaptation layer uses ULAs in the source and destination
skipping to change at page 4, line 24 skipping to change at page 4, line 28
random node mobility properties, MNP-ULAs are generally not random node mobility properties, MNP-ULAs are generally not
aggregatable in the BGP routing service and are represented as many aggregatable in the BGP routing service and are represented as many
more-specific prefixes instead of a smaller number of aggregated more-specific prefixes instead of a smaller number of aggregated
prefixes. prefixes.
In addition, BGP routing service infrastructure nodes configure In addition, BGP routing service infrastructure nodes configure
administratively-assigned ULAs ("ADM-ULA") that are statically- administratively-assigned ULAs ("ADM-ULA") that are statically-
assigned and derived from a shorter ADM-ULA prefix assigned to their assigned and derived from a shorter ADM-ULA prefix assigned to their
BGP network partitions. Unlike MNP-ULAs, the ADM-ULAs are BGP network partitions. Unlike MNP-ULAs, the ADM-ULAs are
persistently present and unchanging in the routing system. The BGP persistently present and unchanging in the routing system. The BGP
routing services therefore perform forwarding based on these MNP-ULAs routing services therefore establish forwarding table entries based
and ADM-ULAs instead of based on the GUA MNPs themselves. Both ADM- on these MNP-ULAs and ADM-ULAs instead of based on the GUA MNPs
ULAs and MNP-ULAs are used by the OAL for nested encapsulation where themselves. Both ADM-ULAs and MNP-ULAs are used by the OAL for
the inner IPv6 packet is encapsulated in an IPv6 adaptation layer nested encapsulation where the inner IPv6 packet is encapsulated in
header with ULA source and destination addresses, which is then an IPv6 adaptation layer header with ULA source and destination
encapsulated in an IP header specific to the underlying Internetwork addresses, which is then encapsulated in an IP header specific to the
that will carry the actual packet transmission. underlying Internetwork that will carry the actual packet
transmission. A high level ATN/IPS network diagram is shown in
Figure 1:
+------------+ +------------+ +------------+
| Aircraft 1 | | Aircraft 2 | .... | Aircraft N |
+------------+ +------------+ +------------+
(OMNI Interface) (OMNI Interface) (OMNI Interface)
/ \ / \ / \
/ \ Aviation / \ Data Links / \
...........................................................
. .
. (:::)-. .
. .-(::::::::) .
. .-(:::: INET 1 ::)-. .
. (:::: e.g., IPv6 :::) .
. ATN/IPS `-(:::::::::::::)-' IPv6-based .
. `-(:::::::-' .
. OMNI Adaptation BGP Mobile .
. (:::)-. .
. Layer Overlay .-(::::::::) Routing Service .
. .-(:::: INET 2 ::)-. .
. (IPv6 GUAs) (:::: e.g., IPv4 :::) (IPv6 ULAs) .
. `-(:::::::::::::)-' .
. `-(:::::::-' .
. .
.............................................................
| Fixed | Data Links |
| | |
(OMNI Interface) (OMNI Interface) (OMNI Interface)
+------------+ +------------+ +------------+
| ATC/AOC 1 | | ATC/AOC 2 | .... | ATC/AOC M |
+------------+ +------------+ +------------+
Figure 1: ATN/IPS Network Diagram
Connexion By Boeing [CBB] was an early aviation mobile routing Connexion By Boeing [CBB] was an early aviation mobile routing
service based on dynamic updates in the global public Internet BGP service based on dynamic updates in the global public Internet BGP
routing system. Practical experience with the approach has shown routing system. Practical experience with the approach has shown
that frequent injections and withdrawals of prefixes in the Internet that frequent injections and withdrawals of prefixes in the Internet
routing system can result in excessive BGP update messaging, slow routing system can result in excessive BGP update messaging, slow
routing table convergence times, and extended outages when no route routing table convergence times, and extended outages when no route
is available. This is due to both conservative default BGP protocol is available. This is due to both conservative default BGP protocol
timing parameters (see Section 6) and the complex peering timing parameters (see Section 6) and the complex peering
interconnections of BGP routers within the global Internet interconnections of BGP routers within the global Internet
skipping to change at page 7, line 19 skipping to change at page 8, line 24
partition (or "segment") partition (or "segment")
A fully-connected internal subnetwork of an INET in which all A fully-connected internal subnetwork of an INET in which all
nodes can communicate with all other nodes within the same nodes can communicate with all other nodes within the same
partition using the same IP protocol version and addressing plan. partition using the same IP protocol version and addressing plan.
Each INET consists of one or more partitions. Each INET consists of one or more partitions.
Overlay Multilink Network Interface (OMNI) Overlay Multilink Network Interface (OMNI)
A virtual layer 2 bridging service that presents an ATN/IPS A virtual layer 2 bridging service that presents an ATN/IPS
overlay unified link view even though the underlay may consist of overlay unified link view even though the underlay may consist of
multiple INET partitions. The OMNI virtual link is manifested multiple INET partitions. The OMNI virtual link is manifested
through nested encapsulation in which GUA-addressed IPv6 packets through nested encapsulation in which original IP packets from the
from the ATN/IPS are first encapsulated in ULA-addressed IPv6 ATN/IPS are first encapsulated in ULA-addressed IPv6 headers which
headers which are then forwarded to the next hop using INET are then forwarded to the next hop using INET encapsulation if
encapsulation if necessary. Forwarding over the OMNI virtual link necessary. Forwarding over the OMNI virtual link is therefore
is therefore based on ULAs instead of GUAs. In this way, packets based on ULAs instead of the original IP addresses. In this way,
sent from a source can be conveyed over the OMNI virtual link even packets sent from a source can be conveyed over the OMNI virtual
though there may be many underlying INET partitions in the path to link even though there may be many underlying INET partitions in
the destination. the path to the destination.
OMNI Adaptation Layer (OAL) OMNI Adaptation Layer (OAL)
A middle layer below the IPv6 layer but above the INET layer that A middle layer below the IP layer but above the INET layer that
applies IPv6-in-IPv6 encapsulation prior to INET encapsulation. applies IP-in-IPv6 encapsulation prior to INET encapsulation. The
The IPv6 encapsulation header inserted by the OAL uses ULAs IPv6 encapsulation header inserted by the OAL uses ULAs instead of
instead of GUAs. End systems that configure OMNI interfaces act GUAs. End systems that configure OMNI interfaces act as OAL
as OAL ingress and egress points, while intermediate systems with ingress and egress points, while intermediate systems with OMNI
OMNI interfaces act as OAL forwarding nodes. There may be zero, interfaces act as OAL forwarding nodes. There may be zero, one or
one or many intermediate nodes between the OAL ingress and egress, many intermediate nodes between the OAL ingress and egress, but
but the upper layer IPv6 Hop Limit is not decremented during (OAL the upper layer IPv6 Hop Limit is not decremented during (OAL
layer) forwarding. Further details on OMNI and the OAL are found layer) forwarding. Further details on OMNI and the OAL are found
in [I-D.templin-6man-omni]. in [I-D.templin-6man-omni].
OAL Autonomous System (OAL AS) OAL Autonomous System (OAL AS)
A "hub-of-hubs" autonomous system maintained through peerings A "hub-of-hubs" autonomous system maintained through peerings
between the core autonomous systems of different OMNI virtual link between the core autonomous systems of different OMNI virtual link
partitions. partitions.
Core Autonomous System Border Router (c-ASBR) Core Autonomous System Border Router (c-ASBR)
A BGP router located in the hub of the INET partition hub-and- A BGP router located in the hub of the INET partition hub-and-
skipping to change at page 8, line 31 skipping to change at page 9, line 35
Proxy/Server presents the appearance that the Client is Proxy/Server presents the appearance that the Client is
communicating directly with the s-ASBR. From the s-ASBR's communicating directly with the s-ASBR. From the s-ASBR's
perspective, the Proxy/Server presents the appearance that the perspective, the Proxy/Server presents the appearance that the
s-ASBR is communicating directly with the Client. s-ASBR is communicating directly with the Client.
Mobile Network Prefix (MNP) Mobile Network Prefix (MNP)
An IPv6 prefix that is delegated to any ATN/IPS end system, An IPv6 prefix that is delegated to any ATN/IPS end system,
including ATCs, AOCs, and aircraft. including ATCs, AOCs, and aircraft.
Mobility Service Prefix (MSP) Mobility Service Prefix (MSP)
An aggregated prefix assigned to the ATN/IPS by an Internet An aggregated IP prefix assigned to the ATN/IPS by an Internet
assigned numbers authority, and from which all MNPs are delegated assigned numbers authority, and from which all MNPs are delegated
(e.g., up to 2**32 IPv6 /56 MNPs could be delegated from a /24 (e.g., up to 2**32 IPv6 /56 MNPs could be delegated from a /24
MSP). MSP).
3. ATN/IPS Routing System 3. ATN/IPS Routing System
The ATN/IPS routing system comprises a private BGP instance The ATN/IPS routing system comprises a private BGP instance
coordinated in an overlay network via tunnels between neighboring coordinated in an overlay network via tunnels between neighboring
ASBRs over one or more underlying INETs. The ATN/IPS routing system ASBRs over one or more underlying INETs. The ATN/IPS routing system
interacts with underlying INET BGP routing systems only through the interacts with underlying INET BGP routing systems only through the
skipping to change at page 9, line 11 skipping to change at page 10, line 15
ASN format [RFC4271][RFC6793]. Since the BGP instance does not ASN format [RFC4271][RFC6793]. Since the BGP instance does not
connect with any INET BGP routing systems, the ASNs can be assigned connect with any INET BGP routing systems, the ASNs can be assigned
from the [RFC6996] 32-bit ASN space which reserves 94,967,295 numbers from the [RFC6996] 32-bit ASN space which reserves 94,967,295 numbers
for private use. The ASNs must be allocated and managed by an ATN/ for private use. The ASNs must be allocated and managed by an ATN/
IPS assigned numbers authority established by ICAO, which must ensure IPS assigned numbers authority established by ICAO, which must ensure
that ASNs are responsibly distributed without duplication and/or that ASNs are responsibly distributed without duplication and/or
overlap. overlap.
The c-ASBRs use iBGP to maintain a synchronized consistent view of The c-ASBRs use iBGP to maintain a synchronized consistent view of
all active MNP-ULAs currently in service within the INET partition. all active MNP-ULAs currently in service within the INET partition.
Figure 1 below represents the reference INET partition deployment. Figure 2 below represents the reference INET partition deployment.
(Note that the figure shows details for only two s-ASBRs (s-ASBR1 and (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 s-ASBR2) due to space constraints, but the other s-ASBRs should be
understood to have similar Stub AS, MNP and eBGP peering understood to have similar Stub AS, MNP and eBGP peering
arrangements.) The solution described in this document is flexible arrangements.) The solution described in this document is flexible
enough to extend to these topologies. enough to extend to these topologies.
........................................................... ...........................................................
. . . .
. (:::)-. <- Stub ASes -> (:::)-. . . (:::)-. <- Stub ASes -> (:::)-. .
. MNPs-> .-(:::::::::) .-(:::::::::) <-MNPs . . MNPs-> .-(:::::::::) .-(:::::::::) <-MNPs .
skipping to change at page 10, line 5 skipping to change at page 11, line 39
. /eBGP \eBGP . . /eBGP \eBGP .
. / \ . . / \ .
. +---+---+ +-----+-+ . . +---+---+ +-----+-+ .
. |s-ASBR | |s-ASBR | . . |s-ASBR | |s-ASBR | .
. +-------+ +-------+ . . +-------+ +-------+ .
. . . .
. . . .
. <----------------- INET Partition -------------------> . . <----------------- INET Partition -------------------> .
............................................................ ............................................................
Figure 1: INET Partition Reference Deployment Figure 2: INET Partition Reference Deployment
In the reference deployment, each s-ASBR maintains routes for active In the reference deployment, each s-ASBR maintains routes for active
MNP-ULAs that currently belong to its stub AS. In response to MNP-ULAs that currently belong to its stub AS. In response to
"Inter-domain" mobility events, each s-ASBR dynamically announces new "Inter-domain" mobility events, each s-ASBR dynamically announces new
MNP-ULAs and withdraws departed MNP-ULAs in its eBGP updates to MNP-ULAs and withdraws departed MNP-ULAs in its eBGP updates to
c-ASBRs. Since ATN/IPS end systems are expected to remain within the c-ASBRs. Since ATN/IPS end systems are expected to remain within the
same stub AS for extended timeframes, however, intra-domain mobility same stub AS for extended timeframes, however, intra-domain mobility
events (such as an aircraft handing off between cell towers) are events (such as an aircraft handing off between cell towers) are
handled within the stub AS instead of being propagated as inter- handled within the stub AS instead of being propagated as inter-
domain eBGP updates. domain eBGP updates.
Each c-ASBR configures a black-hole route for each of its MSPs. By Each c-ASBR configures a black-hole route for each of its MSPs. By
black-holing the MSPs, the c-ASBR maintains forwarding table entries black-holing the MSPs, the c-ASBR maintains forwarding table entries
only for the MNP-ULAs that are currently active. If an arriving only for the MNP-ULAs that are currently active. If an arriving
packet matches a black-hole route without matching an MNP-ULA, the packet matches a black-hole route without matching an MNP-ULA, the
c-ASBR should drop the packet and generate an ICMPv6 Destination c-ASBR should drop the packet and may also generate an ICMPv6
Unreachable message [RFC4443], i.e., without forwarding the packet Destination Unreachable message [RFC4443], i.e., without forwarding
outside of the ATN/IPS overlay based on a less-specific route. the packet outside of the ATN/IPS overlay based on a less-specific
route.
The c-ASBRs do not send BGP updates for MNP-ULAs to s-ASBRs, but The c-ASBRs do not send BGP updates for MNP-ULAs to s-ASBRs, but
instead originate a default route. In this way, s-ASBRs have only instead originate a default route. In this way, s-ASBRs have only
partial topology knowledge (i.e., they know only about the active partial topology knowledge (i.e., they know only about the active
MNP-ULAs currently within their stub ASes) and they forward all other MNP-ULAs currently within their stub ASes) and they forward all other
packets to c-ASBRs which have full topology knowledge. packets to c-ASBRs which have full topology knowledge.
Each s-ASBR and c-ASBR configures an ADM-ULA that is aggregatable Each s-ASBR and c-ASBR configures an ADM-ULA that is aggregatable
within an INET partition, and each partition configures a unique ADM- within an INET partition, and each partition configures a unique ADM-
ULA prefix that is permanently announced into the routing system. ULA prefix that is permanently announced into the routing system.
The core ASes of each INET partition are joined together through The core ASes of each INET partition are joined together through
external BGP peerings. The c-ASBRs of each partition establish external BGP peerings. The c-ASBRs of each partition establish
external peerings with the c-ASBRs of other partitions to form a external peerings with the c-ASBRs of other partitions to form a
"core-of-cores" OMNI link AS. The OMNI link AS contains the global "core-of-cores" OMNI link AS. The OMNI link AS contains the global
knowledge of all MNP-ULAs deployed worldwide, and supports ATN/IPS knowledge of all MNP-ULAs deployed worldwide, and supports ATN/IPS
overlay communications between nodes located in different INET overlay communications between nodes located in different INET
partitions by virtue of OAL encapsulation. OMNI link nodes can then partitions by virtue of OAL encapsulation. OMNI link nodes can then
navigate to ASBRs by including an ADM-ULA or directly to an end navigate to ASBRs by including an ADM-ULA or directly to an end
system by including an MNP-ULA in the destination address of an OAL- system by including an MNP-ULA in the destination address of an OAL-
encapsulated packet (see: [I-D.templin-6man-aero]). Figure 2 shows a encapsulated packet (see: [I-D.templin-6man-aero]). Figure 3 shows a
reference OAL topology. reference OAL topology.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . .
. .-(::::::::) . . .-(::::::::) .
. .-(::::::::::::)-. +------+ . . .-(::::::::::::)-. +------+ .
. (::: Partition 1 ::)--|c-ASBR|---+ . . (::: Partition 1 ::)--|c-ASBR|---+ .
. `-(::::::::::::)-' +------+ | . . `-(::::::::::::)-' +------+ | .
. `-(::::::)-' | . . `-(::::::)-' | .
. | . . | .
skipping to change at page 11, line 31 skipping to change at page 13, line 31
. (::: Partition 3 ::)--|c-ASBR|---+ . . (::: Partition 3 ::)--|c-ASBR|---+ .
. `-(::::::::::::)-' +------+ | . . `-(::::::::::::)-' +------+ | .
. `-(::::::)-' | . . `-(::::::)-' | .
. | . . | .
. ..(etc).. x . . ..(etc).. x .
. . . .
. . . .
. <- ATN/IPS Overlay Bridged by the OAL AS -> . . <- ATN/IPS Overlay Bridged by the OAL AS -> .
. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . .
Figure 2: Spanning Partitions with the OAL Figure 3: Spanning Partitions with the OAL
Scaling properties of this ATN/IPS routing system are limited by the Scaling properties of this ATN/IPS routing system are limited by the
number of BGP routes that can be carried by the c-ASBRs. A 2015 number of BGP routes that can be carried by the c-ASBRs. A 2015
study showed that BGP routers in the global public Internet at that 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 time carried more than 500K routes with linear growth and no signs of
router resource exhaustion [BGP]. A more recent network emulation router resource exhaustion [BGP]. A more recent network emulation
study also showed that a single c-ASBR can accommodate at least 1M study also showed that a single c-ASBR can accommodate at least 1M
dynamically changing BGP routes even on a lightweight virtual dynamically changing BGP routes even on a lightweight virtual
machine. Commercially-available high-performance dedicated router machine. Commercially-available high-performance dedicated router
hardware can support many millions of routes. hardware can support many millions of routes.
skipping to change at page 12, line 41 skipping to change at page 14, line 41
the entire ATN/IPS. Clients may further move between ANETs in a the entire ATN/IPS. Clients may further move between ANETs in a
manner that is perceived as a network layer mobility event. Clients manner that is perceived as a network layer mobility event. Clients
could therefore employ a multilink/mobility routing service such as could therefore employ a multilink/mobility routing service such as
those discussed in Section 7. those discussed in Section 7.
Clients register all of their active data link connections with their Clients register all of their active data link connections with their
serving s-ASBRs as discussed in Section 3. Clients may connect to serving s-ASBRs as discussed in Section 3. Clients may connect to
s-ASBRs either directly, or via a Proxy/Server at the ANET/INET s-ASBRs either directly, or via a Proxy/Server at the ANET/INET
boundary. boundary.
Figure 3 shows the ATN/IPS ANET model where Clients connect to ANETs Figure 4 shows the ATN/IPS ANET model where Clients connect to ANETs
via aviation data links. Clients register their ANET addresses with via aviation data links. Clients register their ANET addresses with
a nearby s-ASBR, where the registration process may be brokered by a a nearby s-ASBR, where the registration process may be brokered by a
Proxy/Server at the edge of the ANET. Proxy/Server at the edge of the ANET.
+-----------------+ +-----------------+
| Client | | Client |
Data Link "A" +-----------------+ Data Link "B" Data Link "A" +-----------------+ Data Link "B"
+----- | OMNI Interface |--------+ +----- | OMNI Interface |--------+
/ +-----------------+ \ / +-----------------+ \
/ \ / \
skipping to change at page 13, line 35 skipping to change at page 15, line 35
. .-(::::::::) . . .-(::::::::) .
. .-(::: ATN/IPS :::)-. . . .-(::: ATN/IPS :::)-. .
. (::::: BGP Routing ::::) . . (::::: BGP Routing ::::) .
. `-(:: System ::::)-' . . `-(:: System ::::)-' .
. `-(:::::::-' . . `-(:::::::-' .
. . . .
. . . .
. <------- OMNI virtual link bridged by the OAL --------> . . <------- OMNI virtual link bridged by the OAL --------> .
............................................................ ............................................................
Figure 3: ATN/IPS ANET Architecture Figure 4: ATN/IPS ANET Architecture
When a Client connects to an ANET it specifies a nearby s-ASBR that When a Client connects to an ANET it specifies a nearby s-ASBR that
it has selected to connect to the ATN/IPS. The login process is it has selected to connect to the ATN/IPS. The login process is
transparently brokered by a Proxy/Server at the border of the ANET transparently brokered by a Proxy/Server at the border of the ANET
which then conveys the connection request to the s-ASBR via tunneling which then conveys the connection request to the s-ASBR via tunneling
across the OMNI virtual link. Each ANET border Proxy/Server is also across the OMNI virtual link. Each ANET border Proxy/Server is also
equally capable of serving in the s-ASBR role so that a first on-link equally capable of serving in the s-ASBR role so that a first on-link
Proxy/Server can be selected as the s-ASBR while all others perform Proxy/Server can be selected as the s-ASBR while all others perform
the Proxy/Server role in a hub-and-spokes arrangement. An on-link the Proxy/Server role in a hub-and-spokes arrangement. An on-link
Proxy/Server is selected to serve the s-ASBR role when it receives a Proxy/Server is selected to serve the s-ASBR role when it receives a
skipping to change at page 15, line 17 skipping to change at page 17, line 17
other Clients. As a designated router, the s-ASBR advertises the other Clients. As a designated router, the s-ASBR advertises the
MNPs of each of its active Clients into the ATN/IPS routing system MNPs of each of its active Clients into the ATN/IPS routing system
and provides basic (unoptimized) forwarding services when necessary. and provides basic (unoptimized) forwarding services when necessary.
An s-ASBR could be the first-hop ATN/IPS service access point for An s-ASBR could be the first-hop ATN/IPS service access point for
some, all or none of a Client's underlying interfaces, while the some, all or none of a Client's underlying interfaces, while the
Client's other underlying interfaces employ the Proxy/Server function Client's other underlying interfaces employ the Proxy/Server function
of other s-ASBRs. Route optimization allows Client-to-Client of other s-ASBRs. Route optimization allows Client-to-Client
communications while bypassing s-ASBR designated routing services communications while bypassing s-ASBR designated routing services
whenever possible. whenever possible.
A route optimization example is shown in Figure 4 and Figure 5 below. A route optimization example is shown in Figure 5 and Figure 6 below.
In the first figure, multiple spanning tree segments between Proxy/ In the first figure, multiple spanning tree segments between Proxy/
Servers and ASBRs are necessary to convey packets between Clients Servers and ASBRs are necessary to convey packets between Clients
associated with different s-ASBRs. In the second figure, the associated with different s-ASBRs. In the second figure, the
optimized route tunnels packets directly between Proxy/Servers optimized route tunnels packets directly between Proxy/Servers
without involving the ASBRs. without involving the ASBRs.
These route optimized paths are established through secured control These route optimized paths are established through secured control
plane messaging (i.e., over secured tunnels and/or using higher-layer plane messaging (i.e., over secured tunnels and/or using higher-layer
control message authentications) but do not provide lower-layer control message authentications) but do not provide lower-layer
security for the data plane. Data communications over these route security for the data plane. Data communications over these route
skipping to change at page 16, line 34 skipping to change at page 18, line 34
. \ **==============** / . . \ **==============** / .
. +---------+ +---------+ . . +---------+ +---------+ .
. | c-ASBR1 | | c-ASBR2 | . . | c-ASBR1 | | c-ASBR2 | .
. +---+-----+ +----+----+ . . +---+-----+ +----+----+ .
. +--------------+ . . +--------------+ .
. iBGP . . iBGP .
. . . .
. <------- OMNI virtual link bridged by the OAL --------> . . <------- OMNI virtual link bridged by the OAL --------> .
............................................................ ............................................................
Figure 4: Dogleg Route Before Optimization Figure 5: Dogleg Route Before Optimization
+---------+ +---------+ +---------+ +---------+
| Client1 | | Client2 | | Client1 | | Client2 |
+---v-----+ +-----^---+ +---v-----+ +-----^---+
* * * *
* * * *
(:::)-. (:::)-. (:::)-. (:::)-.
.-(:::::::::) <- (Radio) Access Networks ->.-(:::::::::) .-(:::::::::) <- (Radio) Access Networks ->.-(:::::::::)
`-(::::)-' `-(::::)-' `-(::::)-' `-(::::)-'
+--------+ +--------+ +--------+ +--------+
skipping to change at page 17, line 34 skipping to change at page 19, line 34
. \ / . . \ / .
. +---------+ +---------+ . . +---------+ +---------+ .
. | c-ASBR1 | | c-ASBR2 | . . | c-ASBR1 | | c-ASBR2 | .
. +---+-----+ +----+----+ . . +---+-----+ +----+----+ .
. +--------------+ . . +--------------+ .
. iBGP . . iBGP .
. . . .
. <------- OMNI virtual link bridged by the OAL --------> . . <------- OMNI virtual link bridged by the OAL --------> .
............................................................ ............................................................
Figure 5: Optimized Route Figure 6: Optimized Route
6. BGP Protocol Considerations 6. BGP Protocol Considerations
The number of eBGP peering sessions that each c-ASBR must service is The number of eBGP peering sessions that each c-ASBR must service is
proportional to the number of s-ASBRs in its local partition. proportional to the number of s-ASBRs in its local partition.
Network emulations with lightweight virtual machines have shown that Network emulations with lightweight virtual machines have shown that
a single c-ASBR can service at least 100 eBGP peerings from s-ASBRs a single c-ASBR can service at least 100 eBGP peerings from s-ASBRs
that each advertise 10K MNP-ULA routes (i.e., 1M total). It is that each advertise 10K MNP-ULA routes (i.e., 1M total). It is
expected that robust c-ASBRs can service many more peerings than this expected that robust c-ASBRs can service many more peerings than this
- possibly by multiple orders of magnitude. But even assuming a - possibly by multiple orders of magnitude. But even assuming a
skipping to change at page 21, line 22 skipping to change at page 23, line 22
This work is aligned with the Boeing Commercial Airplanes (BCA) This work is aligned with the Boeing Commercial Airplanes (BCA)
Internet of Things (IoT) and autonomy programs. Internet of Things (IoT) and autonomy programs.
This work is aligned with the Boeing Information Technology (BIT) This work is aligned with the Boeing Information Technology (BIT)
MobileNet program. MobileNet program.
The following individuals contributed insights that have improved the The following individuals contributed insights that have improved the
document: Ahmad Amin, Mach Chen, Russ Housley, Erik Kline, Hubert document: Ahmad Amin, Mach Chen, Russ Housley, Erik Kline, Hubert
Kuenig, Tony Li, Gyan Mishra, Alexandre Petrescu, Dave Thaler, Pascal Kuenig, Tony Li, Gyan Mishra, Alexandre Petrescu, Dave Thaler, Pascal
Thubert, Tony Whyman. Thubert, Michael Tuxen, Tony Whyman.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <https://www.rfc-editor.org/info/rfc2473>. December 1998, <https://www.rfc-editor.org/info/rfc2473>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
 End of changes. 24 change blocks. 
66 lines changed or deleted 105 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/