< draft-ietf-rtgwg-atn-bgp-15.txt   draft-ietf-rtgwg-atn-bgp-16.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: 7 October 2022 G. Dawra Expires: 9 October 2022 G. Dawra
LinkedIn LinkedIn
A. Lindem A. Lindem
V. Moreno V. Moreno
Cisco Systems, Inc. Cisco Systems, Inc.
5 April 2022 7 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-15 draft-ietf-rtgwg-atn-bgp-16
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 7 October 2022. This Internet-Draft will expire on 9 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 37 skipping to change at page 2, line 37
7. Stub AS Mobile Routing Services . . . . . . . . . . . . . . . 21 7. Stub AS Mobile Routing Services . . . . . . . . . . . . . . . 21
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 . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 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 addresses of adaptation layer IPv6 encapsulation headers. Each ULA
aircraft ULA includes an MNP in the interface identifier ("MNP-ULA"), includes an MNP in the interface identifier ("MNP-ULA"), as discussed
as discussed in [I-D.templin-6man-omni]. Due to MNP delegation in [I-D.templin-6man-omni]. Due to MNP delegation policies and
policies and random node mobility properties, MNPs are generally not random node mobility properties, MNP-ULAs are generally not
aggregable 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. The ADM-ULA consists of a 64-bit ULA prefix BGP network partitions. Unlike MNP-ULAs, the ADM-ULAs are
followed by 32 zero bits followed by the 32-bit ADM suffix. The ADM persistently present and unchanging in the routing system. The BGP
route injected into the BGP routing service is therefore 0:0:{ADM- routing services therefore establish forwarding table entries based
Suffix}::/N. Unlike MNPs, ADM-based routes are persistently present on these MNP-ULAs and ADM-ULAs instead of based on the GUA MNPs
and unchanging in the routing system. themselves. However, the {ADM,MNP}-ULA 16-bit Subnet ID is always
set to 0 (i.e., the "wildcard" subnet} when the ULA is advertised in
BGP routing exchanges and/or installed in forwarding tables.
Both ADM-ULAs and MNP-ULAs are used by the OAL for nested Both ADM-ULAs and MNP-ULAs are used by the OAL for nested
encapsulation where the inner IPv6 packet is encapsulated in an IPv6 encapsulation where the inner IPv6 packet is encapsulated in an IPv6
adaptation layer header with ULA source and destination addresses, adaptation layer header with ULA source and destination addresses,
which is then encapsulated in an IP header specific to the underlying which is then encapsulated in an IP header specific to the underlying
Internetwork that will carry the actual packet transmission. Internetwork that will carry the actual packet transmission. A high
However, the forwarding table entries established by the BGP routing level ATN/IPS network diagram is shown in Figure 1:
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) MNP and necessary, and BGP routing is based on (intermediate-layer) ULAs
ADM routes. This allows ASBRs to perform adaptation layer forwarding instead of upper- or lower-layer public/private IP prefixes. This
based on intermediate layer IPv6 header information instead of allows ASBRs to perform adaptation layer forwarding based on
network layer forwarding based on upper layer IP header information intermediate layer IPv6 header information instead of network layer
or link layer forwarding based on lower layer IP header information. forwarding based on upper layer IP header information or link layer
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
MNPs currently active within the stub AS. The s-ASBRs send BGP MNP-ULAs currently active within the stub AS. The s-ASBRs send BGP
updates for MNP injections or withdrawals to c-ASBRs but do not updates for MNP-ULA 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 MNPs currently in service within a full routing table for all active MNP-ULAs currently in service
the partition. Therefore, only the c-ASBRs maintain a full BGP within the partition. Therefore, only the c-ASBRs maintain a full
routing table and never send any BGP updates to s-ASBRs. This simple BGP routing table and never send any BGP updates to s-ASBRs. This
routing model therefore greatly reduces the number of BGP updates simple routing model therefore greatly reduces the number of BGP
that need to be synchronized among peers, and the number is reduced updates that need to be synchronized among peers, and the number is
further still when intradomain routing changes within stub ASes are reduced further still when intradomain routing changes within stub
processed within the AS instead of being propagated to the core. BGP ASes are processed within the AS instead of being propagated to the
Route Reflectors (RRs) [RFC4456] can also be used to support core. BGP Route Reflectors (RRs) [RFC4456] can also be used to
increased scaling properties. support 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 routes for all partitions are known globally that the full set of ULAs for all partitions are known globally among
among all of the c-ASBRs. Each c/s-ASBR further configures an ADM- all of the c-ASBRs. Each c/s-ASBR further configures an ADM-ULA
ULA which is taken from an ADM-ULA prefix assigned to each partition, which is taken from an ADM-ULA prefix assigned to each partition, as
as well as static forwarding table entries for all other OMNI link 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 MNPs currently in service within the INET partition. all active MNP-ULAs 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
MNPs that currently belong to its stub AS. In response to "Inter- MNP-ULAs that currently belong to its stub AS. In response to
domain" mobility events, each s-ASBR dynamically announces new MNPs "Inter-domain" mobility events, each s-ASBR dynamically announces new
and withdraws departed MNPs in its eBGP updates to c-ASBRs. Since MNP-ULAs and withdraws departed MNP-ULAs in its eBGP updates to
ATN/IPS end systems are expected to remain within the same stub AS c-ASBRs. Since ATN/IPS end systems are expected to remain within the
for extended timeframes, however, intra-domain mobility events (such same stub AS for extended timeframes, however, intra-domain mobility
as an aircraft handing off between cell towers) are handled within events (such as an aircraft handing off between cell towers) are
the stub AS instead of being propagated as inter-domain eBGP updates. handled within the stub AS instead of being propagated as inter-
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 MNPs that are currently active. If an arriving packet only for the MNP-ULAs that are currently active. If an arriving
has an adaptation layer destination address that matches a black-hole packet matches a black-hole route without matching an MNP-ULA, the
route without matching an MNP, the c-ASBR should drop the packet and c-ASBR should drop the packet and may also generate an ICMPv6
may also generate an ICMPv6 Destination Unreachable message Destination Unreachable message [RFC4443], i.e., without forwarding
[RFC4443], i.e., without forwarding the packet outside of the ATN/IPS the packet outside of the ATN/IPS overlay based on a less-specific
overlay based on a less-specific route. route.
The c-ASBRs do not send BGP updates for MNPs to s-ASBRs, but instead The c-ASBRs do not send BGP updates for MNP-ULAs to s-ASBRs, but
originate a default route. In this way, s-ASBRs have only partial instead originate a default route. In this way, s-ASBRs have only
topology knowledge (i.e., they know only about the active MNPs partial topology knowledge (i.e., they know only about the active
currently within their stub ASes) and they forward all other packets MNP-ULAs currently within their stub ASes) and they forward all other
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 with a 32-bit ADM suffix Each s-ASBR and c-ASBR configures an ADM-ULA that is aggregable
that is unique within the OMNI link, and the core ASes of each INET within an INET partition, and each partition configures a unique ADM-
partition are joined together through external BGP peerings. The ULA prefix that is permanently announced into the routing system.
c-ASBRs of each partition establish external peerings with the The core ASes of each INET partition are joined together through
c-ASBRs of other partitions to form a "core-of-cores" OMNI link AS. external BGP peerings. The c-ASBRs of each partition establish
The OMNI link AS contains the global knowledge of all MNPs deployed external peerings with the c-ASBRs of other partitions to form a
worldwide, and supports ATN/IPS overlay communications between nodes "core-of-cores" OMNI link AS. The OMNI link AS contains the global
located in different INET partitions by virtue of OAL encapsulation. knowledge of all MNP-ULAs deployed worldwide, and supports ATN/IPS
OMNI link nodes can then navigate to ASBRs by including an ADM-ULA or overlay communications between nodes located in different INET
directly to an end system by including an MNP-ULA in the destination partitions by virtue of OAL encapsulation. OMNI link nodes can then
address of an OAL-encapsulated packet (see: [I-D.templin-6man-aero]). navigate to ASBRs by including an ADM-ULA or directly to an end
Figure 3 shows a reference OAL topology. system by including an MNP-ULA in the destination address of an OAL-
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 MNPs can be serviced by a means that at least 1M ATN/IPS end system MNP-ULAs can be serviced by
single set of c-ASBRs and that number could be further increased by a 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 routes in the The s-ASBR represents all of its active Clients as MNP-ULA routes in
ATN/IPS BGP routing system. The s-ASBR's stub AS is therefore used the ATN/IPS BGP routing system. The s-ASBR's stub AS is therefore
only to advertise the set of MNPs of all its active Clients to its used only to advertise the set of MNPs of all its active Clients to
BGP peer c-ASBRs and not to peer with other s-ASBRs (i.e., the stub its BGP peer c-ASBRs and not to peer with other s-ASBRs (i.e., the
AS is a logical construct and not a physical one). The s-ASBR stub AS is a logical construct and not a physical one). The s-ASBR
injects the MNPs of its active Clients and withdraws the MNPs of its injects the MNP-ULAs of its active Clients and withdraws the MNP-ULAs
departed Clients via BGP updates to c-ASBRs, which further propagate of its departed Clients via BGP updates to c-ASBRs, which further
the MNPs to other c-ASBRs within the OAL AS. Since Clients are propagate the MNP-ULAs to other c-ASBRs within the OAL AS. Since
expected to remain associated with their current s-ASBR for extended Clients are expected to remain associated with their current s-ASBR
periods, the level of MNP injections and withdrawals in the BGP for extended periods, the level of MNP-ULA injections and withdrawals
routing system will be on the order of the numbers of network joins, in the BGP routing system will be on the order of the numbers of
leaves and s-ASBR handovers for aircraft operations (see: Section 6). network joins, leaves and s-ASBR handovers for aircraft operations
It is important to observe that fine-grained events such as Client (see: Section 6). It is important to observe that fine-grained
mobility and Quality of Service (QoS) signaling are coordinated only events such as Client mobility and Quality of Service (QoS) signaling
by Proxies and the Client's current s-ASBRs, and do not involve other are coordinated only by Proxies and the Client's current s-ASBRs, and
ASBRs in the routing system. In this way, intradomain routing do not involve other ASBRs in the routing system. In this way,
changes within the stub AS are not propagated into the rest of the intradomain routing changes within the stub AS are not propagated
ATN/IPS BGP routing system. into the rest of the 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 routes (i.e., 1M total). It is expected that each advertise 10K MNP-ULA routes (i.e., 1M total). It is
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
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 20, line 47 skipping to change at page 20, line 47
the ATN/IPS unicast IPv6 routes resolving over INET routes. the ATN/IPS unicast IPv6 routes resolving over INET routes.
Consequently, c-ASBRs and potentially s-ASBRs will need to support Consequently, c-ASBRs and potentially s-ASBRs will need to support
separate local ASes for the two BGP routing domains and routing separate local ASes for the two BGP routing domains and routing
policy or assure routes are not propagated between the two BGP policy or assure routes are not propagated between the two BGP
routing domains. From a conceptual, operational and correctness routing domains. From a conceptual, operational and correctness
standpoint, the implementation should provide isolation between the standpoint, the implementation should provide isolation between the
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 Subnet ID '*' to form the prefix [ULA*]::/64. Each individual
individual address taken from [ULA*]::/64 includes additional routing 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). But, the routes injected into the routing system are details). However, ULA prefixes installed in the BGP routing system
configured from the 64-bit MNP/ADM suffix (along with a prefix length always set the Subnet ID to 0 (i.e., the "wildcard" subnet) since
of /64 or shorter), and not from the ULA prefix itself. OMNI link forwarding decisions are based on the interface identifier
information independently of the Subnet ID.
This gives rise to a BGP routing system that must accommodate large This gives rise to a BGP routing system that must accommodate large
numbers of long and non-aggregable MNPs as well as moderate numbers numbers of long and non-aggregable MNP-ULA prefixes as well as
of long and semi-aggregable ADM-based routes. Meanwhile, in the moderate numbers of long and semi-aggregable ADM-ULA prefixes. The
forwarding plane the 64-bit suffixes of ULA destination addresses system is kept stable and scalable through the s-ASBR / c-ASBR hub-
(i.e., and not the 64-bit prefixes) are matched against the MNP and and-spokes topology which ensures that mobility-related churn is not
ADM-based forwarding table entries established by the routing system. exposed to the core. The forwarding table entries populated through
The system is kept stable and scalable through the s-ASBR / c-ASBR routing updates always set the {ADM,MNP}-ULA Subnet ID to 0, since
hub-and-spokes topology which ensures that mobility-related churn is forwarding is supported across subnet (i.e., OMNI link segment)
not exposed to the core. boundaries.
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 MNPs in realistic network emulations showing that at least 1 million MNP-
can be propagated to each c-ASBR even on lightweight virtual ULAs 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 26, line 28 skipping to change at page 26, line 32
[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 is asserted at a new location or withdrawn from an old after an MNP-ULA is asserted at a new location or withdrawn from an
location can be several hundred milliseconds even under optimal AS old location can be several hundred milliseconds even under optimal
peering arrangements. This means that packets in flight destined to AS peering arrangements. This means that packets in flight destined
an MNP route that has recently been changed can be (mis)delivered to to an MNP-ULA route that has recently been changed can be
an old s-ASBR after a Client has moved to a new s-ASBR. (mis)delivered to an old s-ASBR after a Client has moved to a new
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. 
117 lines changed or deleted 118 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/