< draft-ietf-rtgwg-atn-bgp-14.txt   draft-ietf-rtgwg-atn-bgp-15.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: 18 August 2022 G. Dawra Expires: 7 October 2022 G. Dawra
LinkedIn LinkedIn
A. Lindem A. Lindem
V. Moreno V. Moreno
Cisco Systems, Inc. Cisco Systems, Inc.
14 February 2022 5 April 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-14 draft-ietf-rtgwg-atn-bgp-15
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 18 August 2022. This Internet-Draft will expire on 7 October 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
skipping to change at page 2, line 38 skipping to change at page 2, line 38
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10.1. Public Key Infrastructure (PKI) Considerations . . . . . 22 10.1. Public Key Infrastructure (PKI) Considerations . . . . . 22
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
12.1. Normative References . . . . . . . . . . . . . . . . . . 23 12.1. Normative References . . . . . . . . . . . . . . . . . . 23
12.2. Informative References . . . . . . . . . . . . . . . . . 24 12.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. BGP Convergence Considerations . . . . . . . . . . . 26 Appendix A. BGP Convergence Considerations . . . . . . . . . . . 26
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 26 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
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 4, line 15 skipping to change at page 4, line 15
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
addresses of adaptation layer IPv6 encapsulation headers. Each ULA addresses of adaptation layer IPv6 encapsulation headers. Each
includes an MNP in the interface identifier ("MNP-ULA"), as discussed aircraft ULA includes an MNP in the interface identifier ("MNP-ULA"),
in [I-D.templin-6man-omni]. Due to MNP delegation policies and as discussed in [I-D.templin-6man-omni]. Due to MNP delegation
random node mobility properties, MNP-ULAs are generally not policies and random node mobility properties, MNPs are generally not
aggregatable in the BGP routing service and are represented as many aggregable 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. The ADM-ULA consists of a 64-bit ULA prefix
persistently present and unchanging in the routing system. The BGP followed by 32 zero bits followed by the 32-bit ADM suffix. The ADM
routing services therefore establish forwarding table entries based route injected into the BGP routing service is therefore 0:0:{ADM-
on these MNP-ULAs and ADM-ULAs instead of based on the GUA MNPs Suffix}::/N. Unlike MNPs, ADM-based routes are persistently present
themselves. Both ADM-ULAs and MNP-ULAs are used by the OAL for and unchanging in the routing system.
nested encapsulation where the inner IPv6 packet is encapsulated in
an IPv6 adaptation layer header with ULA source and destination Both ADM-ULAs and MNP-ULAs are used by the OAL for nested
addresses, which is then encapsulated in an IP header specific to the encapsulation where the inner IPv6 packet is encapsulated in an IPv6
underlying Internetwork that will carry the actual packet adaptation layer header with ULA source and destination addresses,
transmission. A high level ATN/IPS network diagram is shown in which is then encapsulated in an IP header specific to the underlying
Figure 1: Internetwork that will carry the actual packet transmission.
However, the forwarding table entries established by the BGP routing
system will include MNP and/or ADM-Suffix based routes. ATN/IPS
infrastructure elements therefore institute a special form of
forwarding that matches the 64-bit suffix of the OAL destination
address with the forwarding table entry (i.e., and not the 64-bit
prefix).
A high level ATN/IPS network diagram is shown in Figure 1:
+------------+ +------------+ +------------+ +------------+ +------------+ +------------+
| Aircraft 1 | | Aircraft 2 | .... | Aircraft N | | Aircraft 1 | | Aircraft 2 | .... | Aircraft N |
+------------+ +------------+ +------------+ +------------+ +------------+ +------------+
(OMNI Interface) (OMNI Interface) (OMNI Interface) (OMNI Interface) (OMNI Interface) (OMNI Interface)
/ \ / \ / \ / \ / \ / \
/ \ Aviation / \ Data Links / \ / \ Aviation / \ Data Links / \
........................................................... ...........................................................
. . . .
. (:::)-. . . (:::)-. .
skipping to change at page 6, line 12 skipping to change at page 6, line 12
propagated to all BGP routers in the Internet that carry a full propagated to all BGP routers in the Internet that carry a full
routing table. routing table.
We therefore consider an approach using a BGP overlay network routing We therefore consider an approach using a BGP overlay network routing
system where a private BGP routing protocol instance is maintained system where a private BGP routing protocol instance is maintained
between ATN/IPS Autonomous System (AS) Border Routers (ASBRs). The between ATN/IPS Autonomous System (AS) Border Routers (ASBRs). The
private BGP instance does not interact with the native BGP routing private BGP instance does not interact with the native BGP routing
systems in underlying INETs, and BGP updates are unidirectional from systems in underlying INETs, and BGP updates are unidirectional from
"stub" ASBRs (s-ASBRs) to a small set of "core" ASBRs (c-ASBRs) in a "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 hub-and-spokes topology. No extensions to the BGP protocol are
necessary, and BGP routing is based on (intermediate-layer) ULAs necessary, and BGP routing is based on (intermediate-layer) MNP and
instead of upper- or lower-layer public/private IP prefixes. This ADM routes. This allows ASBRs to perform adaptation layer forwarding
allows ASBRs to perform adaptation layer forwarding based on based on intermediate layer IPv6 header information instead of
intermediate layer IPv6 header information instead of network layer network layer forwarding based on upper layer IP header information
forwarding based on upper layer IP header information or link layer or link layer forwarding based on lower layer IP header information.
forwarding based on lower layer IP header information.
The s-ASBRs for each stub AS connect to a small number of c-ASBRs via The s-ASBRs for each stub AS connect to a small number of c-ASBRs via
dedicated high speed links and/or secured tunnels (e.g., IPsec dedicated high speed links and/or secured tunnels (e.g., IPsec
[RFC4301], WireGuard [WG], etc.) over the underlying INET. [RFC4301], WireGuard [WG], etc.) over the underlying INET.
Neighboring ASBRs should use also such IP layer security Neighboring ASBRs should use also such IP layer security
encapsulations over direct physical links to ensure INET layer encapsulations over direct physical links to ensure INET layer
security. security.
The s-ASBRs engage in external BGP (eBGP) peerings with their The s-ASBRs engage in external BGP (eBGP) peerings with their
respective c-ASBRs, and only maintain routing table entries for the respective c-ASBRs, and only maintain routing table entries for the
MNP-ULAs currently active within the stub AS. The s-ASBRs send BGP MNPs currently active within the stub AS. The s-ASBRs send BGP
updates for MNP-ULA injections or withdrawals to c-ASBRs but do not updates for MNP injections or withdrawals to c-ASBRs but do not
receive any BGP updates from c-ASBRs. Instead, the s-ASBRs maintain 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 default routes with their c-ASBRs as the next hop, and therefore hold
only partial topology information. only partial topology information.
The c-ASBRs connect to other c-ASBRs within the same partition using The c-ASBRs connect to other c-ASBRs within the same partition using
internal BGP (iBGP) peerings over which they collaboratively maintain internal BGP (iBGP) peerings over which they collaboratively maintain
a full routing table for all active MNP-ULAs currently in service a full routing table for all active MNPs currently in service within
within the partition. Therefore, only the c-ASBRs maintain a full the partition. Therefore, only the c-ASBRs maintain a full BGP
BGP routing table and never send any BGP updates to s-ASBRs. This routing table and never send any BGP updates to s-ASBRs. This simple
simple routing model therefore greatly reduces the number of BGP routing model therefore greatly reduces the number of BGP updates
updates that need to be synchronized among peers, and the number is that need to be synchronized among peers, and the number is reduced
reduced further still when intradomain routing changes within stub further still when intradomain routing changes within stub ASes are
ASes are processed within the AS instead of being propagated to the processed within the AS instead of being propagated to the core. BGP
core. BGP Route Reflectors (RRs) [RFC4456] can also be used to Route Reflectors (RRs) [RFC4456] can also be used to support
support increased scaling properties. increased scaling properties.
When there are multiple INET partitions, the c-ASBRs of each When there are multiple INET partitions, the c-ASBRs of each
partition use eBGP to peer with the c-ASBRs of other partitions so partition use eBGP to peer with the c-ASBRs of other partitions so
that the full set of ULAs for all partitions are known globally among that the full set of routes for all partitions are known globally
all of the c-ASBRs. Each c/s-ASBR further configures an ADM-ULA among all of the c-ASBRs. Each c/s-ASBR further configures an ADM-
which is taken from an ADM-ULA prefix assigned to each partition, as ULA which is taken from an ADM-ULA prefix assigned to each partition,
well as static forwarding table entries for all other OMNI link as well as static forwarding table entries for all other OMNI link
partition prefixes. Both ADM-ULAs and MNP-ULAs are used by the OAL partition prefixes. Both ADM-ULAs and MNP-ULAs are used by the OAL
for nested encapsulation where the inner IPv6 packet is encapsulated for nested encapsulation where the inner IPv6 packet is encapsulated
in an IPv6 OAL header with ULA source and destination addresses, in an IPv6 OAL header with ULA source and destination addresses,
which is then encapsulated in an IP header specific to the INET which is then encapsulated in an IP header specific to the INET
partition. partition.
With these intra- and inter-INET BGP peerings in place, a forwarding With these intra- and inter-INET BGP peerings in place, a forwarding
plane spanning tree is established that properly covers the entire plane spanning tree is established that properly covers the entire
operating domain. All nodes in the network can be visited using operating domain. All nodes in the network can be visited using
strict spanning tree hops, but in many instances this may result in strict spanning tree hops, but in many instances this may result in
skipping to change at page 10, line 14 skipping to change at page 10, line 14
core ASN. Unique ASNs are assigned according to the standard 32-bit core ASN. Unique ASNs are assigned according to the standard 32-bit
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 MNPs currently in service within the INET partition.
Figure 2 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 -> (:::)-. .
skipping to change at page 11, line 42 skipping to change at page 11, line 42
. |s-ASBR | |s-ASBR | . . |s-ASBR | |s-ASBR | .
. +-------+ +-------+ . . +-------+ +-------+ .
. . . .
. . . .
. <----------------- INET Partition -------------------> . . <----------------- INET Partition -------------------> .
............................................................ ............................................................
Figure 2: 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 MNPs that currently belong to its stub AS. In response to "Inter-
"Inter-domain" mobility events, each s-ASBR dynamically announces new domain" mobility events, each s-ASBR dynamically announces new MNPs
MNP-ULAs and withdraws departed MNP-ULAs in its eBGP updates to and withdraws departed MNPs in its eBGP updates to c-ASBRs. Since
c-ASBRs. Since ATN/IPS end systems are expected to remain within the ATN/IPS end systems are expected to remain within the same stub AS
same stub AS for extended timeframes, however, intra-domain mobility for extended timeframes, however, intra-domain mobility events (such
events (such as an aircraft handing off between cell towers) are as an aircraft handing off between cell towers) are handled within
handled within the stub AS instead of being propagated as inter- 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 MNPs that are currently active. If an arriving packet
packet matches a black-hole route without matching an MNP-ULA, the has an adaptation layer destination address that matches a black-hole
c-ASBR should drop the packet and may also generate an ICMPv6 route without matching an MNP, the c-ASBR should drop the packet and
Destination Unreachable message [RFC4443], i.e., without forwarding may also generate an ICMPv6 Destination Unreachable message
the packet outside of the ATN/IPS overlay based on a less-specific [RFC4443], i.e., without forwarding the packet outside of the ATN/IPS
route. 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 MNPs to s-ASBRs, but instead
instead originate a default route. In this way, s-ASBRs have only originate a default route. In this way, s-ASBRs have only partial
partial topology knowledge (i.e., they know only about the active topology knowledge (i.e., they know only about the active MNPs
MNP-ULAs currently within their stub ASes) and they forward all other currently within their stub ASes) and they forward all other packets
packets to c-ASBRs which have full topology knowledge. 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 with a 32-bit ADM suffix
within an INET partition, and each partition configures a unique ADM- that is unique within the OMNI link, and the core ASes of each INET
ULA prefix that is permanently announced into the routing system. partition are joined together through external BGP peerings. The
The core ASes of each INET partition are joined together through c-ASBRs of each partition establish external peerings with the
external BGP peerings. The c-ASBRs of each partition establish c-ASBRs of other partitions to form a "core-of-cores" OMNI link AS.
external peerings with the c-ASBRs of other partitions to form a The OMNI link AS contains the global knowledge of all MNPs deployed
"core-of-cores" OMNI link AS. The OMNI link AS contains the global worldwide, and supports ATN/IPS overlay communications between nodes
knowledge of all MNP-ULAs deployed worldwide, and supports ATN/IPS located in different INET partitions by virtue of OAL encapsulation.
overlay communications between nodes located in different INET OMNI link nodes can then navigate to ASBRs by including an ADM-ULA or
partitions by virtue of OAL encapsulation. OMNI link nodes can then directly to an end system by including an MNP-ULA in the destination
navigate to ASBRs by including an ADM-ULA or directly to an end address of an OAL-encapsulated packet (see: [I-D.templin-6man-aero]).
system by including an MNP-ULA in the destination address of an OAL- Figure 3 shows a reference OAL topology.
encapsulated packet (see: [I-D.templin-6man-aero]). Figure 3 shows a
reference OAL topology.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . .
. .-(::::::::) . . .-(::::::::) .
. .-(::::::::::::)-. +------+ . . .-(::::::::::::)-. +------+ .
. (::: Partition 1 ::)--|c-ASBR|---+ . . (::: Partition 1 ::)--|c-ASBR|---+ .
. `-(::::::::::::)-' +------+ | . . `-(::::::::::::)-' +------+ | .
. `-(::::::)-' | . . `-(::::::)-' | .
. | . . | .
. .-(::::::::) | . . .-(::::::::) | .
skipping to change at page 13, line 44 skipping to change at page 13, line 44
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.
Therefore, assuming each c-ASBR can carry 1M or more routes, this Therefore, assuming each c-ASBR can carry 1M or more routes, this
means that at least 1M ATN/IPS end system MNP-ULAs can be serviced by means that at least 1M ATN/IPS end system MNPs can be serviced by a
a single set of c-ASBRs and that number could be further increased by single set of c-ASBRs and that number could be further increased by
using RRs and/or more powerful routers. Another means of increasing 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 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 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 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 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 aggregate the MSP. In this way, each set of c-ASBRs maintains
separate routing and forwarding tables so that scaling is distributed separate routing and forwarding tables so that scaling is distributed
across multiple c-ASBR sets instead of concentrated in a single 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 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 segment A::/32, a second set could aggregate B::/32, a third could
skipping to change at page 16, line 10 skipping to change at page 16, line 10
ANETs after it has already coordinated with a first-hop Proxy/Server ANETs after it has already coordinated with a first-hop Proxy/Server
over a first ANET. If the Client connects to multiple ANETs, the over a first ANET. If the Client connects to multiple ANETs, the
s-ASBR will register the individual ANET Proxy/Servers as conduits s-ASBR will register the individual ANET Proxy/Servers as conduits
through which the Client can be reached. The Client then sees the through which the Client can be reached. The Client then sees the
s-ASBR as the "hub" in a "hub-and-spokes" arrangement with the first- s-ASBR as the "hub" in a "hub-and-spokes" arrangement with the first-
hop Proxy/Servers as spokes. Selection of a network-based s-ASBR is hop Proxy/Servers as spokes. Selection of a network-based s-ASBR is
through the discovery methods specified in relevant mobility and through the discovery methods specified in relevant mobility and
virtual link coordination specifications (e.g., see AERO virtual link coordination specifications (e.g., see AERO
[I-D.templin-6man-aero] and OMNI [I-D.templin-6man-omni]). [I-D.templin-6man-aero] and OMNI [I-D.templin-6man-omni]).
The s-ASBR represents all of its active Clients as MNP-ULA routes in The s-ASBR represents all of its active Clients as MNP routes in the
the ATN/IPS BGP routing system. The s-ASBR's stub AS is therefore ATN/IPS BGP routing system. The s-ASBR's stub AS is therefore used
used only to advertise the set of MNPs of all its active Clients to only to advertise the set of MNPs of all its active Clients to its
its BGP peer c-ASBRs and not to peer with other s-ASBRs (i.e., the BGP peer c-ASBRs and not to peer with other s-ASBRs (i.e., the stub
stub AS is a logical construct and not a physical one). The s-ASBR AS is a logical construct and not a physical one). The s-ASBR
injects the MNP-ULAs of its active Clients and withdraws the MNP-ULAs injects the MNPs of its active Clients and withdraws the MNPs of its
of its departed Clients via BGP updates to c-ASBRs, which further departed Clients via BGP updates to c-ASBRs, which further propagate
propagate the MNP-ULAs to other c-ASBRs within the OAL AS. Since the MNPs to other c-ASBRs within the OAL AS. Since Clients are
Clients are expected to remain associated with their current s-ASBR expected to remain associated with their current s-ASBR for extended
for extended periods, the level of MNP-ULA injections and withdrawals periods, the level of MNP injections and withdrawals in the BGP
in the BGP routing system will be on the order of the numbers of routing system will be on the order of the numbers of network joins,
network joins, leaves and s-ASBR handovers for aircraft operations leaves and s-ASBR handovers for aircraft operations (see: Section 6).
(see: Section 6). It is important to observe that fine-grained It is important to observe that fine-grained events such as Client
events such as Client mobility and Quality of Service (QoS) signaling mobility and Quality of Service (QoS) signaling are coordinated only
are coordinated only by Proxies and the Client's current s-ASBRs, and by Proxies and the Client's current s-ASBRs, and do not involve other
do not involve other ASBRs in the routing system. In this way, ASBRs in the routing system. In this way, intradomain routing
intradomain routing changes within the stub AS are not propagated changes within the stub AS are not propagated into the rest of the
into the rest of the ATN/IPS BGP routing system. ATN/IPS BGP routing system.
5. ATN/IPS Route Optimization 5. ATN/IPS Route Optimization
ATN/IPS end systems will frequently need to communicate with ATN/IPS end systems will frequently need to communicate with
correspondents associated with other s-ASBRs. In the BGP peering correspondents associated with other s-ASBRs. In the BGP peering
topology discussed in Section 3, this can initially only be topology discussed in Section 3, this can initially only be
accommodated by including multiple extraneous hops and/or spanning accommodated by including multiple extraneous hops and/or spanning
tree segments in the forwarding path. In many cases, it would be tree segments in the forwarding path. In many cases, it would be
desirable to establish a "short cut" around this "dogleg" route so desirable to establish a "short cut" around this "dogleg" route so
that packets can traverse a minimum number of tunneling hops across that packets can traverse a minimum number of tunneling hops across
skipping to change at page 19, line 42 skipping to change at page 19, line 42
............................................................ ............................................................
Figure 6: 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 routes (i.e., 1M total). It is expected
expected that robust c-ASBRs can service many more peerings than this 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
conservative limit, the number of s-ASBRs could be increased by also conservative limit, the number of s-ASBRs could be increased by also
increasing the number of c-ASBRs. Since c-ASBRs also peer with each increasing the number of c-ASBRs. Since c-ASBRs also peer with each
other using iBGP, however, larger-scale c-ASBR deployments may need other using iBGP, however, larger-scale c-ASBR deployments may need
to employ an adjunct facility such as BGP Route Reflectors to employ an adjunct facility such as BGP Route Reflectors
(RRs)[RFC4456]. (RRs)[RFC4456].
The number of aircraft in operation at a given time worldwide is The number of aircraft in operation at a given time worldwide is
likely to be significantly less than 1M, but we will assume this likely to be significantly less than 1M, but we will assume this
number for a worst-case analysis. Assuming a worst-case average 1 number for a worst-case analysis. Assuming a worst-case average 1
hour flight profile from gate-to-gate with 10 service region hour flight profile from gate-to-gate with 10 service region
skipping to change at page 21, line 4 skipping to change at page 21, line 4
two BGP routing domains (e.g., separate BGP instances). two BGP routing domains (e.g., separate BGP instances).
ADM-ULAs and MNP-ULAs begin with fd00::/8 followed by a pseudo-random ADM-ULAs and MNP-ULAs begin with fd00::/8 followed by a pseudo-random
40-bit global ID to form the prefix [ULA]::/48, along with a 16-bit 40-bit global ID to form the prefix [ULA]::/48, along with a 16-bit
OMNI link identifier '*' to form the prefix [ULA*]::/64. Each OMNI link identifier '*' to form the prefix [ULA*]::/64. Each
individual address taken from [ULA*]::/64 includes additional routing individual address taken from [ULA*]::/64 includes additional routing
information in the interface identifier. For example, for the MNP information in the interface identifier. For example, for the MNP
2001:db8:1:0::/56, the resulting MNP-ULA is [ULA*]:2001:db8:1:0/120, 2001:db8:1:0::/56, the resulting MNP-ULA is [ULA*]:2001:db8:1:0/120,
and for the administrative address 1001:2002/16 the ADM-ULA is and for the administrative address 1001:2002/16 the ADM-ULA is
[ULA*]::1001:2002/112 (see: [I-D.templin-6man-omni] for further [ULA*]::1001:2002/112 (see: [I-D.templin-6man-omni] for further
details). This gives rise to a BGP routing system that must details). But, the routes injected into the routing system are
accommodate large numbers of long and non-aggregatable MNP-ULA configured from the 64-bit MNP/ADM suffix (along with a prefix length
prefixes as well as moderate numbers of long and semi-aggregatable of /64 or shorter), and not from the ULA prefix itself.
ADM-ULA prefixes. The system is kept stable and scalable through the
s-ASBR / c-ASBR hub-and-spokes topology which ensures that mobility- This gives rise to a BGP routing system that must accommodate large
related churn is not exposed to the core. numbers of long and non-aggregable MNPs as well as moderate numbers
of long and semi-aggregable ADM-based routes. Meanwhile, in the
forwarding plane the 64-bit suffixes of ULA destination addresses
(i.e., and not the 64-bit prefixes) are matched against the MNP and
ADM-based forwarding table entries established by the routing system.
The system is kept stable and scalable through the s-ASBR / c-ASBR
hub-and-spokes topology which ensures that mobility-related churn is
not exposed to the core.
7. Stub AS Mobile Routing Services 7. Stub AS Mobile Routing Services
Stub ASes maintain intradomain routing information for mobile node Stub ASes maintain intradomain routing information for mobile node
clients, and are responsible for all localized mobility signaling clients, and are responsible for all localized mobility signaling
without disturbing the BGP routing system. Clients can enlist the without disturbing the BGP routing system. Clients can enlist the
services of a candidate mobility service such as Mobile IPv6 (MIPv6) services of a candidate mobility service such as Mobile IPv6 (MIPv6)
[RFC6275], LISP [I-D.ietf-lisp-rfc6830bis] or AERO [RFC6275], LISP [I-D.ietf-lisp-rfc6830bis] or AERO
[I-D.templin-6man-aero] according to the service offered by the stub [I-D.templin-6man-aero] according to the service offered by the stub
AS. Further details of mobile routing services are out of scope for AS. Further details of mobile routing services are out of scope for
this document. this document.
8. Implementation Status 8. Implementation Status
The BGP routing topology described in this document has been modeled The BGP routing topology described in this document has been modeled
in realistic network emulations showing that at least 1 million MNP- in realistic network emulations showing that at least 1 million MNPs
ULAs can be propagated to each c-ASBR even on lightweight virtual can be propagated to each c-ASBR even on lightweight virtual
machines. No BGP routing protocol extensions need to be adopted. machines. No BGP routing protocol extensions need to be adopted.
9. IANA Considerations 9. IANA Considerations
This document does not introduce any IANA considerations. This document does not introduce any IANA considerations.
10. Security Considerations 10. Security Considerations
ATN/IPS ASBRs on the open Internet are susceptible to the same attack ATN/IPS ASBRs on the open Internet are susceptible to the same attack
profiles as for any Internet nodes. For this reason, ASBRs should profiles as for any Internet nodes. For this reason, ASBRs should
skipping to change at page 25, line 4 skipping to change at page 25, line 16
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos, "The Locator/ID Separation Protocol (LISP)", Cabellos, "The Locator/ID Separation Protocol (LISP)",
Work in Progress, Internet-Draft, draft-ietf-lisp- Work in Progress, Internet-Draft, draft-ietf-lisp-
rfc6830bis-36, 18 November 2020, rfc6830bis-36, 18 November 2020,
<https://www.ietf.org/archive/id/draft-ietf-lisp- <https://www.ietf.org/archive/id/draft-ietf-lisp-
rfc6830bis-36.txt>. rfc6830bis-36.txt>.
[I-D.templin-6man-aero] [I-D.templin-6man-aero]
Templin, F. L., "Automatic Extended Route Optimization Templin, F. L., "Automatic Extended Route Optimization
(AERO)", Work in Progress, Internet-Draft, draft-templin- (AERO)", Work in Progress, Internet-Draft, draft-templin-
6man-aero-38, 31 December 2021, 6man-aero-41, 29 March 2022,
<https://www.ietf.org/archive/id/draft-templin-6man-aero- <https://www.ietf.org/archive/id/draft-templin-6man-aero-
38.txt>. 41.txt>.
[I-D.templin-6man-omni] [I-D.templin-6man-omni]
Templin, F. L. and T. Whyman, "Transmission of IP Packets Templin, F. L., "Transmission of IP Packets over Overlay
over Overlay Multilink Network (OMNI) Interfaces", Work in Multilink Network (OMNI) Interfaces", Work in Progress,
Progress, Internet-Draft, draft-templin-6man-omni-52, 31 Internet-Draft, draft-templin-6man-omni-56, 29 March 2022,
December 2021, <https://www.ietf.org/archive/id/draft- <https://www.ietf.org/archive/id/draft-templin-6man-omni-
templin-6man-omni-52.txt>. 56.txt>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000, DOI 10.17487/RFC2784, March 2000,
<https://www.rfc-editor.org/info/rfc2784>. <https://www.rfc-editor.org/info/rfc2784>.
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
January 2006, <https://www.rfc-editor.org/info/rfc4251>. January 2006, <https://www.rfc-editor.org/info/rfc4251>.
skipping to change at page 26, line 19 skipping to change at page 26, line 28
[RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/info/rfc9001>. <https://www.rfc-editor.org/info/rfc9001>.
[WG] Donenfeld, J., "WireGuard: Fast, Modern, Secure VPN [WG] Donenfeld, J., "WireGuard: Fast, Modern, Secure VPN
Tunnel, https://www.wireguard.com/", February 2022. Tunnel, https://www.wireguard.com/", February 2022.
Appendix A. BGP Convergence Considerations Appendix A. BGP Convergence Considerations
Experimental evidence has shown that BGP convergence time required Experimental evidence has shown that BGP convergence time required
after an MNP-ULA is asserted at a new location or withdrawn from an after an MNP is asserted at a new location or withdrawn from an old
old location can be several hundred milliseconds even under optimal location can be several hundred milliseconds even under optimal AS
AS peering arrangements. This means that packets in flight destined peering arrangements. This means that packets in flight destined to
to an MNP-ULA route that has recently been changed can be an MNP route that has recently been changed can be (mis)delivered to
(mis)delivered to an old s-ASBR after a Client has moved to a new an old s-ASBR after a Client has moved to a new s-ASBR.
s-ASBR.
To address this issue, the old s-ASBR can maintain temporary state To address this issue, the old s-ASBR can maintain temporary state
for a "departed" Client that includes an OAL address for the new for a "departed" Client that includes an OAL address for the new
s-ASBR. The OAL address never changes since ASBRs are fixed s-ASBR. The OAL address never changes since ASBRs are fixed
infrastructure elements that never move. Hence, packets arriving at infrastructure elements that never move. Hence, packets arriving at
the old s-ASBR can be forwarded to the new s-ASBR while the BGP the old s-ASBR can be forwarded to the new s-ASBR while the BGP
routing system is still undergoing reconvergence. Therefore, as long routing system is still undergoing reconvergence. Therefore, as long
as the Client associates with the new s-ASBR before it departs from as the Client associates with the new s-ASBR before it departs from
the old s-ASBR (while informing the old s-ASBR of its new location) the old s-ASBR (while informing the old s-ASBR of its new location)
packets in flight during the BGP reconvergence window are packets in flight during the BGP reconvergence window are
 End of changes. 25 change blocks. 
120 lines changed or deleted 130 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/