< draft-ietf-rtgwg-atn-bgp-06.txt   draft-ietf-rtgwg-atn-bgp-07.txt >
Network Working Group F. Templin, Ed. Network Working Group F. Templin, Ed.
Internet-Draft G. Saccone Internet-Draft G. Saccone
Intended status: Informational Boeing Research & Technology Intended status: Informational Boeing Research & Technology
Expires: January 1, 2021 G. Dawra Expires: June 20, 2021 G. Dawra
LinkedIn LinkedIn
A. Lindem A. Lindem
V. Moreno V. Moreno
Cisco Systems, Inc. Cisco Systems, Inc.
June 30, 2020 December 17, 2020
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-06 draft-ietf-rtgwg-atn-bgp-07
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 IPv6-based service supporting pervasive Air Traffic with an IPv6-based service supporting pervasive Air Traffic
Management (ATM) for Air Traffic Controllers (ATC), Airline Management (ATM) for Air Traffic Controllers (ATC), Airline
Operations Controllers (AOC), and all commercial aircraft worldwide. Operations Controllers (AOC), and all commercial aircraft worldwide.
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 January 1, 2021. This Internet-Draft will expire on June 20, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. ATN/IPS Routing System . . . . . . . . . . . . . . . . . . . 7 3. ATN/IPS Routing System . . . . . . . . . . . . . . . . . . . 8
4. ATN/IPS (Radio) Access Network (ANET) Model . . . . . . . . . 11 4. ATN/IPS (Radio) Access Network (ANET) Model . . . . . . . . . 11
5. ATN/IPS Route Optimization . . . . . . . . . . . . . . . . . 13 5. ATN/IPS Route Optimization . . . . . . . . . . . . . . . . . 13
6. BGP Protocol Considerations . . . . . . . . . . . . . . . . . 15 6. BGP Protocol Considerations . . . . . . . . . . . . . . . . . 15
7. Stub AS Mobile Routing Services . . . . . . . . . . . . . . . 16 7. Stub AS Mobile Routing Services . . . . . . . . . . . . . . . 16
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
12.1. Normative References . . . . . . . . . . . . . . . . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . . 18
12.2. Informative References . . . . . . . . . . . . . . . . . 18 12.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. BGP Convergence Considerations . . . . . . . . . . . 19 Appendix A. BGP Convergence Considerations . . . . . . . . . . . 20
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 20 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
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.
The International Civil Aviation Organization [ICAO] is now The International Civil Aviation Organization (ICAO) is now
undertaking the development of a next-generation replacement for ATN/ undertaking the development of a next-generation replacement for ATN/
OSI known as Aeronautical Telecommunications Network with Internet OSI known as Aeronautical Telecommunications Network with Internet
Protocol Services (ATN/IPS). ATN/IPS will eventually provide an Protocol Services (ATN/IPS) [ATN][ATN-IPS]. ATN/IPS will eventually
IPv6-based [RFC8200] service supporting pervasive ATM for Air Traffic provide an IPv6-based [RFC8200] service supporting pervasive ATM for
Controllers (ATC), Airline Operations Controllers (AOC), and all Air Traffic Controllers (ATC), Airline Operations Controllers (AOC),
commercial aircraft worldwide. As part of the ATN/IPS undertaking, a and all commercial aircraft worldwide. As part of the ATN/IPS
new mobile routing service will be needed. This document presents an undertaking, a new mobile routing service will be needed. This
approach based on the Border Gateway Protocol (BGP) [RFC4271]. document presents an approach based on the Border Gateway Protocol
(BGP) [RFC4271].
Aircraft communicate via wireless aviation data links that typically Aircraft communicate via wireless aviation data links that typically
support much lower data rates than terrestrial wireless and wired- support much lower data rates than terrestrial wireless and wired-
line communications. For example, some Very High Frequency (VHF)- line communications. For example, some Very High Frequency (VHF)-
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.
The ATN/IPS is an IPv6-based overlay network configured over one or The ATN/IPS is an IPv6-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. Each network service providers such as ARINC, SITA and Inmarsat. The
INET comprises one or more "partitions" where all nodes within a overlay provides an Overlay Multilink Network Interface (OMNI)
partition can exchange packets with all other nodes, i.e., the virtual link layer as discussed in [I-D.templin-6man-omni-interface].
partition is connected internally. There is no requirement that any Each aircraft connects to the OMNI link via an OMNI Interface
two INET partitions use the same IP protocol version nor have
consistent IP addressing plans in comparison with other partitions.
Instead, the ATN/IPS IPv6 overlay sees each partition as a "segment"
of a link-layer topology manifested through a (virtual) bridging
service known as "Spanning Partitioned Aeronautical Networks (SPAN)".
Further discussion of the SPAN is found in the following sections of
this document, with reference to [I-D.templin-intarea-6706bis].
Each aircraft connects to the ATN/IPS overlay via an Overlay
Multilink Network (OMNI) Interface [I-D.templin-6man-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. The OMNI interface connects to a Non- access network interfaces. The OMNI interface connects to a Non-
Broadcast, Multiple Access (NBMA) virtual link that spans the entire Broadcast, Multiple Access (NBMA) virtual link that spans the entire
ATN/IPS. ATN/IPS.
The ATN/IPS further assumes that each aircraft will receive an IPv6 Each underlying INET comprises one or more "partitions" where all
Mobile Network Prefix (MNP) that accompanies the aircraft wherever it nodes within a partition can exchange packets with all other nodes,
travels. ICAO is further proposing to assign each aircraft an entire i.e., the partition is connected internally. There is no requirement
/56 MNP for numbering its on-board networks. ATCs and AOCs will that any two INET partitions use the same IP protocol version nor
likewise receive IPv6 prefixes, but they would typically appear in have consistent IP addressing plans in comparison with other
static (not mobile) deployments such as air traffic control towers, partitions. Instead, the OMNI link sees each partition as a
airline headquarters, etc. Throughout the rest of this document, we "segment" of a link-layer topology manifested through a (virtual)
therefore use the term "MNP" when discussing an IPv6 prefix that is bridging service based on IPv6 encapsulation [RFC2473] known as the
delegated to any ATN/IPS end system, including ATCs, AOCs, and OMNI Adaptation Layer (OAL). Further discussion of the OAL is found
aircraft. We also use the term Mobility Service Prefix (MSP) to in the following sections of this document, with reference to
refer to an aggregated prefix assigned to the ATN/IPS by an Internet [I-D.templin-6man-omni-interface][I-D.templin-intarea-6706bis].
assigned numbers authority, and from which all MNPs are delegated
(e.g., up to 2^32 IPv6 /56 MNPs could be delegated from an IPv6 /24 The IPv6 addressing architecture provides different classes of
MSP). addresses, including Global Unicast Addresses (GUAs), Unique Local
Addresses (ULAs) and Link-Local Addresses (LLAs) [RFC4291][RFC4193].
The ATN/IPS receives an IPv6 GUA Mobility Service Prefix (MSP) from
an Internet assigned numbers authority, and each aircraft will
receive a Mobile Network Prefix (MNP) delegation from the MSP that
accompanies the aircraft wherever it travels. ATCs and AOCs will
likewise receive MNPs, but they would typically appear in static (not
mobile) deployments such as air traffic control towers, airline
headquarters, etc. The OAL conversely uses ULAs in the source and
destination addresses of IPv6 encapsulation headers. Each ULA
includes an MNP in the interface identifier as discussed in
[I-D.templin-6man-omni-interface], and the BGP routing services
performs forwarding based on these "MNP-ULAs" instead of based on the
MNPs themselves.
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 MNPs 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
infrastructure. The situation is further exacerbated by frequent infrastructure. The situation is further exacerbated by frequent
aircraft mobility events that each result in BGP updates that must be aircraft mobility events that each result in BGP updates that must be
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. necessary. BGP routing is based on the ULAs found in OAL headers,
i.e., it provides an adaptation layer forwarding service instead of a
networking layer services.
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 tunnels across the INET using dedicated high speed links and/or tunnels across the INET using
industry-standard encapsulations (e.g., Generic Routing Encapsulation industry-standard secured encapsulations (e.g., IPsec [RFC4301],
(GRE) [RFC2784], IPsec [RFC4301], etc.). In particular, tunneling Wireguard, etc.). In particular, tunneling must be used when
must be used when neighboring ASBRs are separated by multiple INET neighboring ASBRs are separated by multiple INET hops.
hops.
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 MNPs for all partitions are known globally among that the full set of ULAs for all partitions are known globally among
all of the c-ASBRs. Each c/s-ASBR further configures a "SPAN all of the c-ASBRs. Each c/s-ASBR further configures an
address" which is taken from a global or unique-local IPv6 "SPAN administratively-assigned "ADM-ULA" (see:
prefix" assigned to each partition, as well as static forwarding [I-D.templin-6man-omni-interface]) which is taken from a ADM-ULA
table entries for all other prefixes in the SPAN. The SPAN addresses prefix assigned to each partition, as well as static forwarding table
are used for nested encapsulation where the inner IPv6 packet is entries for all other OMNI link partition prefixes. Both ADM-ULAs
encapsulated in a SPAN header which is then encapsulated in an IP and MNP-ULAs are used by the OAL for nested encapsulation where the
inner IPv6 packet is encapsulated in an IPv6 OAL header with ULA
source and destination addresses, which is then encapsulated in an IP
header specific to the INET partition. header specific to the INET partition.
The remainder of this document discusses the proposed BGP-based ATN/ The remainder of this document discusses the proposed BGP-based ATN/
IPS mobile routing service. IPS mobile routing service.
2. Terminology 2. Terminology
The terms Autonomous System (AS) and Autonomous System Border Router The terms Autonomous System (AS) and Autonomous System Border Router
(ASBR) are the same as defined in [RFC4271]. (ASBR) are the same as defined in [RFC4271].
skipping to change at page 6, line 30 skipping to change at page 6, line 35
for radio-based Internet service provider networks (e.g., cellular for radio-based Internet service provider networks (e.g., cellular
operators), but can also refer to ground-domain networks that operators), but can also refer to ground-domain networks that
connect AOCs and ATCs. connect AOCs and ATCs.
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.
Spanning Partitioned Aeronautical Networks (SPAN) Overlay Multilink Network Interface (OMNI)
A virtual layer 2 bridging service that presents a unified link A virtual layer 2 bridging service that presents an ATN/IPS
view to the ATN/IPS overlay even though the underlay may consist overlay unified link view even though the underlay may consist of
of multiple INET partitions. The SPAN is manifested through multiple INET partitions. The OMNI virtual link is manifested
nested encapsulation in which IPv6 packets from the ATN/IPS are through nested encapsulation in which GUA-addessed IPv6 packets
first encapsulated in SPAN headers which are then encapsulated in from the ATN/IPS are first encapsulated in ULA-addressed IPv6
INET headers. In this way, packets sent from a source can be headers which are then forwarded to the next hop using INET
conveyed over the SPAN even though there may be many underlying encapsulation if necessary. Forwarding over the OMNI virtual link
INET partitions in the path to the destination. is therefore based on ULAs instead of GUAs. In this way, packets
sent from a source can be conveyed over the OMNI virtual link even
though there may be many underlying INET partitions in the path to
the destination.
SPAN Autonomous System OMNI Adaptation Layer (OAL)
A middle layer below the IPv6 layer but above the INET layer that
applies IPv6-in-IPv6 encapsulation prior to INET encapsulation.
The IPv6 encapsulation header inserted by the OAL uses ULAs
instead of GUAs. Further details on OMNI and the OAL are found in
[I-D.templin-6man-omni-interface].
OAL Autonomous System
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 SPAN partitions. between the core autonomous systems of different OMNI virtual link
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-
spokes overlay network topology. spokes overlay network topology.
Core Autonomous System Core Autonomous System
The "hub" autonomous system maintained by all c-ASBRs within the The "hub" autonomous system maintained by all c-ASBRs within the
same partition. same partition.
Stub Autonomous System Border Router (s-ASBR) Stub Autonomous System Border Router (s-ASBR)
skipping to change at page 8, line 6 skipping to change at page 8, line 23
Within each INET partition, one or more s-ASBRs connect each stub AS Within each INET partition, one or more s-ASBRs connect each stub AS
to the INET partition core using a shared stub AS Number (ASN). Each to the INET partition core using a shared stub AS Number (ASN). Each
s-ASBR further uses eBGP to peer with one or more c-ASBRs. All s-ASBR further uses eBGP to peer with one or more c-ASBRs. All
c-ASBRs are members of the INET partition core AS, and use a shared c-ASBRs are members of the INET partition core AS, and use a shared
core ASN. Globally-unique public ASNs could be assigned, e.g., core ASN. Globally-unique public ASNs could be assigned, e.g.,
either according to the standard 16-bit ASN format or the 32-bit ASN either according to the standard 16-bit ASN format or the 32-bit ASN
scheme defined in [RFC6793]. scheme defined in [RFC6793].
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 1 below represents the reference INET partition deployment. Figure 1 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 8, line 51 skipping to change at page 9, line 42
. |s-ASBR | |s-ASBR | . . |s-ASBR | |s-ASBR | .
. +-------+ +-------+ . . +-------+ +-------+ .
. . . .
. . . .
. <----------------- INET Partition -------------------> . . <----------------- INET Partition -------------------> .
............................................................ ............................................................
Figure 1: INET Partition Reference Deployment Figure 1: 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 will dynamically announces new "Inter-domain" mobility events, each s-ASBR will dynamically
MNPs and withdraws departed MNPs in its eBGP updates to c-ASBRs. announces new MNP-ULAs and withdraws departed MNP-ULAs in its eBGP
Since ATN/IPS end systems are expected to remain within the same stub updates to c-ASBRs. Since ATN/IPS end systems are expected to remain
AS for extended timeframes, however, intra-domain mobility events within the same stub AS for extended timeframes, however, intra-
(such as an aircraft handing off between cell towers) are handled domain mobility events (such as an aircraft handing off between cell
within the stub AS instead of being propagated as inter-domain eBGP towers) are handled within the stub AS instead of being propagated as
updates. 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 will maintain forwarding table black-holing the MSPs, the c-ASBR will maintain forwarding table
entries only for the MNPs that are currently active, and packets entries only for the MNP-ULAs that are currently active, and packets
destined to all other MNPs will correctly incur ICMPv6 Destination destined to all other MNP-ULAs will correctly incur ICMPv6
Unreachable messages [RFC4443] due to the black hole route. (This is Destination Unreachable messages [RFC4443] due to the black hole
the same behavior as for ordinary BGP routers in the Internet when route. (This is the same behavior as for ordinary BGP routers in the
they receive packets for which there is no route available.) The Internet when they receive packets for which there is no route
c-ASBRs do not send eBGP updates for MNPs to s-ASBRs, but instead available.) The c-ASBRs do not send eBGP updates for MNP-ULAs to
originate a default route. In this way, s-ASBRs have only partial s-ASBRs, but instead originate a default route. In this way, s-ASBRs
topology knowledge (i.e., they know only about the active MNPs have only partial topology knowledge (i.e., they know only about the
currently within their stub ASes) and they forward all other packets active MNP-ULAs currently within their stub ASes) and they forward
to c-ASBRs which have full topology knowledge. all other packets to c-ASBRs which have full topology knowledge.
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" SPAN AS. The SPAN AS contains the global knowledge "core-of-cores" OAL AS. The OAL AS contains the global knowledge of
of all MNPs deployed worldwide, and supports ATN/IPS overlay all MNP-ULAs deployed worldwide, and supports ATN/IPS overlay
communications between nodes located in different INET partitions by communications between nodes located in different INET partitions by
virtue of SPAN encapsulation. Figure 2 shows a reference SPAN virtue of OAL encapsulation. Figure 2 shows a reference OAL
topology. topology.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . .
. .-(::::::::) . . .-(::::::::) .
. .-(::::::::::::)-. +------+ . . .-(::::::::::::)-. +------+ .
. (::: Partition 1 ::)--|c-ASBR|---+ . . (::: Partition 1 ::)--|c-ASBR|---+ .
. `-(::::::::::::)-' +------+ | . . `-(::::::::::::)-' +------+ | .
. `-(::::::)-' | . . `-(::::::)-' | .
. | . . | .
skipping to change at page 10, line 28 skipping to change at page 10, line 47
. | . . | .
. .-(::::::::) | . . .-(::::::::) | .
. .-(::::::::::::)-. +------+ | . . .-(::::::::::::)-. +------+ | .
. (::: Partition 3 ::)--|c-ASBR|---+ . . (::: Partition 3 ::)--|c-ASBR|---+ .
. `-(::::::::::::)-' +------+ | . . `-(::::::::::::)-' +------+ | .
. `-(::::::)-' | . . `-(::::::)-' | .
. | . . | .
. ..(etc).. x . . ..(etc).. x .
. . . .
. . . .
. <- ATN/IPS Overlay Bridged by the SPAN AS -> . . <- ATN/IPS Overlay Bridged by the OAL AS -> .
. . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . .
Figure 2: The SPAN Figure 2: 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.
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 11, line 30 skipping to change at page 11, line 51
even larger scales can be accommodated by adding more c-ASBRs. even larger scales can be accommodated by adding more c-ASBRs.
4. ATN/IPS (Radio) Access Network (ANET) Model 4. ATN/IPS (Radio) Access Network (ANET) Model
(Radio) Access Networks (ANETs) connect end system Clients such as (Radio) Access Networks (ANETs) connect end system Clients such as
aircraft, ATCs, AOCs etc. to the ATN/IPS routing system. Clients may aircraft, ATCs, AOCs etc. to the ATN/IPS routing system. Clients may
connect to multiple ANETs at once, for example, when they have both connect to multiple ANETs at once, for example, when they have both
satellite and cellular data links activated simultaneously. Clients satellite and cellular data links activated simultaneously. Clients
configure an Overlay Multilink Network (OMNI) Interface configure an Overlay Multilink Network (OMNI) Interface
[I-D.templin-6man-omni-interface] over their underlying ANET [I-D.templin-6man-omni-interface] over their underlying ANET
interfaces as a connection to an NBMA virtual link that spans the interfaces as a connection to an NBMA virtual link (manifested by the
entire ATN/IPS. Clients may further move between ANETs in a manner OAL) that spans the entire ATN/IPS. Clients may further move between
that is perceived as a network layer mobility event. Clients could ANETs in a manner that is perceived as a network layer mobility
therefore employ a multilink/mobility routing service such as those event. Clients could therefore employ a multilink/mobility routing
discussed in Section 7. service such as 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 at the ANET/INET boundary. s-ASBRs either directly, or via a Proxy at the ANET/INET boundary.
Figure 3 shows the ATN/IPS ANET model where Clients connect to ANETs Figure 3 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 at the edge of the ANET. Proxy at the edge of the ANET.
skipping to change at page 12, line 32 skipping to change at page 12, line 44
. +--------+ . . +--------+ .
. | eBGP . . | eBGP .
. (:::)-. . . (:::)-. .
. .-(::::::::) . . .-(::::::::) .
. .-(::: ATN/IPS :::)-. . . .-(::: ATN/IPS :::)-. .
. (::::: BGP Routing ::::) . . (::::: BGP Routing ::::) .
. `-(:: System ::::)-' . . `-(:: System ::::)-' .
. `-(:::::::-' . . `-(:::::::-' .
. . . .
. . . .
. <------- ATN/IPS Overlay bridged by the SPAN --------> . . <------- OMNI virtual link bridged by the OAL --------> .
............................................................ ............................................................
Figure 3: ATN/IPS ANET Architecture Figure 3: ATN/IPS ANET Architecture
When a Client logs into an ANET it specifies a nearby s-ASBR that it When a Client logs into an ANET it specifies a nearby s-ASBR that it
has selected to connect to the ATN/IPS. (Selection of a nearby has selected to connect to the ATN/IPS. (Selection of a nearby
s-ASBR could be through consulting a geographically-keyed static host s-ASBR could be through consulting a geographically-keyed static host
file, through a DNS lookup, through a network query response, etc.) file, through a DNS lookup, through a network query response, etc.)
The login process is transparently brokered by a Proxy at the border The login process is transparently brokered by a Proxy at the border
of the ANET, which then conveys the connection request to the s-ASBR of the ANET, which then conveys the connection request to the s-ASBR
via tunneling across the SPAN. The s-ASBR then registers the address via tunneling across the OMNI virtual link. The s-ASBR then
of the Proxy as the address for the Client, and the Proxy forwards registers the address of the Proxy as the address for the Client, and
the s-ASBR's reply to the Client. If the Client connects to multiple the Proxy forwards the s-ASBR's reply to the Client. If the Client
ANETs, the s-ASBR will register the addresses of all Proxies as connects to multiple ANETs, the s-ASBR will register the addresses of
addresses through which the Client can be reached. all Proxies as addresses through which the Client can be reached.
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 therefore consists the ATN/IPS BGP routing system. The s-ASBR's stub AS therefore
of the set of all of its active Clients (i.e., the stub AS is a consists of the set of all of its active Clients (i.e., the stub AS
logical construct and not a physical construct). The s-ASBR injects is a logical construct and not a physical construct). The s-ASBR
the MNPs of its active Clients and withdraws the MNPs of its departed injects the MNP-ULAs of its active Clients and withdraws the MNP-ULAs
Clients via BGP updates to c-ASBRs, which further propagate the MNPs of its departed Clients via BGP updates to c-ASBRs, which further
to other c-ASBRs within the SPAN AS. Since Clients are expected to propagate the MNP-ULAs to other c-ASBRs within the OAL AS. Since
remain associated with their current s-ASBR for extended periods, the Clients are expected to remain associated with their current s-ASBR
level of MNP injections and withdrawals in the BGP routing system for extended periods, the level of MNP-ULA injections and withdrawals
will be on the order of the numbers of network joins, leaves and in the BGP routing system will be on the order of the numbers of
s-ASBR handovers for aircraft operations (see: Section 6). It is network joins, leaves and s-ASBR handovers for aircraft operations
important to observe that fine-grained events such as Client mobility (see: Section 6). It is important to observe that fine-grained
and Quality of Service (QoS) signaling are coordinated only by events such as Client mobility and Quality of Service (QoS) signaling
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 tunnel segments in the forwarding accommodated by including multiple tunnel segments in the forwarding
path. In many cases, it would be desirable to eliminate extraneous path. In many cases, it would be desirable to eliminate extraneous
tunnel segments from this "dogleg" route so that packets can traverse tunnel segments from this "dogleg" route so that packets can traverse
a minimum number of tunneling hops across the SPAN. ATN/IPS end a minimum number of tunneling hops across the OMNI virtual link.
systems could therefore employ a route optimization service according ATN/IPS end systems could therefore employ a route optimization
to the mobility service employed (see: Section 7). service according to the mobility service employed (see: Section 7).
A route optimization example is shown in Figure 4 and Figure 5 below. A route optimization example is shown in Figure 4 and Figure 5 below.
In the first figure, multiple tunneled segments between Proxys and In the first figure, multiple tunneled segments between Proxys and
ASBRs are necessary to convey packets between Clients associated with ASBRs are necessary to convey packets between Clients associated with
different s-ASBRs. In the second figure, the optimized route tunnels different s-ASBRs. In the second figure, the optimized route tunnels
packets directly between Proxys without involving the ASBRs. packets directly between Proxys without involving the ASBRs.
+---------+ +---------+ +---------+ +---------+
| Client1 | | Client2 | | Client1 | | Client2 |
+---v-----+ +-----^---+ +---v-----+ +-----^---+
skipping to change at page 14, line 31 skipping to change at page 14, line 31
. +--+------+ +-----+---+ . . +--+------+ +-----+---+ .
. \ ** Dogleg ** / . . \ ** Dogleg ** / .
. eBGP\ ** Route ** /eBGP . . eBGP\ ** Route ** /eBGP .
. \ **==============** / . . \ **==============** / .
. +---------+ +---------+ . . +---------+ +---------+ .
. | c-ASBR1 | | c-ASBR2 | . . | c-ASBR1 | | c-ASBR2 | .
. +---+-----+ +----+----+ . . +---+-----+ +----+----+ .
. +--------------+ . . +--------------+ .
. iBGP . . iBGP .
. . . .
. <------- ATN/IPS Overlay bridged by the SPAN --------> . . <------- OMNI virtual link bridged by the OAL --------> .
............................................................ ............................................................
Figure 4: Dogleg Route Before Optimization Figure 4: Dogleg Route Before Optimization
+---------+ +---------+ +---------+ +---------+
| Client1 | | Client2 | | Client1 | | Client2 |
+---v-----+ +-----^---+ +---v-----+ +-----^---+
* * * *
* * * *
(:::)-. (:::)-. (:::)-. (:::)-.
skipping to change at page 15, line 31 skipping to change at page 15, line 31
. +--+------+ +-----+---+ . . +--+------+ +-----+---+ .
. \ / . . \ / .
. eBGP\ /eBGP . . eBGP\ /eBGP .
. \ / . . \ / .
. +---------+ +---------+ . . +---------+ +---------+ .
. | c-ASBR1 | | c-ASBR2 | . . | c-ASBR1 | | c-ASBR2 | .
. +---+-----+ +----+----+ . . +---+-----+ +----+----+ .
. +--------------+ . . +--------------+ .
. iBGP . . iBGP .
. . . .
. <------- ATN/IPS Overlay bridged by the SPAN --------> . . <------- OMNI virtual link bridged by the OAL --------> .
............................................................ ............................................................
Figure 5: Optimized Route Figure 5: 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 17, line 8 skipping to change at page 17, line 8
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] and AERO [RFC6275], LISP [I-D.ietf-lisp-rfc6830bis] and AERO
[I-D.templin-intarea-6706bis] according to the service offered by the [I-D.templin-intarea-6706bis] according to the service offered by the
stub AS. Further details of mobile routing services are out of scope stub AS. Further details of mobile routing services are out of scope
for this document. for 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 18, line 16 skipping to change at page 18, line 16
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, Erik Kline, Hubert Kuenig, Tony Li, Alexandre document: Ahmad Amin, Erik Kline, Hubert Kuenig, Tony Li, Alexandre
Petrescu, Pascal Thubert, Tony Whyman. Petrescu, Pascal Thubert, Tony Whyman.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <https://www.rfc-editor.org/info/rfc2473>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89, Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>. <https://www.rfc-editor.org/info/rfc4443>.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<https://www.rfc-editor.org/info/rfc4456>. <https://www.rfc-editor.org/info/rfc4456>.
skipping to change at page 18, line 43 skipping to change at page 19, line 7
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>. <https://www.rfc-editor.org/info/rfc5880>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
12.2. Informative References 12.2. Informative References
[ATN] Maiolla, V., "The OMNI Interface - An IPv6 Air/Ground
Interface for Civil Aviation, IETF Liaison Statement
#1676, https://datatracker.ietf.org/liaison/1676/", March
2020.
[ATN-IPS] WG-I, ICAO., "ICAO Document 9896 (Manual on the
Aeronautical Telecommunication Network (ATN) using
Internet Protocol Suite (IPS) Standards and Protocol),
Draft Edition 3 (work-in-progress)", December 2020.
[BGP] Huston, G., "BGP in 2015, http://potaroo.net", January [BGP] Huston, G., "BGP in 2015, http://potaroo.net", January
2016. 2016.
[BGP2] Huston, G., "BGP Instability Report, [BGP2] Huston, G., "BGP Instability Report,
http://bgpupdates.potaroo.net/instability/bgpupd.html", http://bgpupdates.potaroo.net/instability/bgpupd.html",
May 2017. May 2017.
[CBB] Dul, A., "Global IP Network Mobility using Border Gateway [CBB] Dul, A., "Global IP Network Mobility using Border Gateway
Protocol (BGP), http://www.quark.net/docs/ Protocol (BGP), http://www.quark.net/docs/
Global_IP_Network_Mobility_using_BGP.pdf", March 2006. Global_IP_Network_Mobility_using_BGP.pdf", March 2006.
[I-D.ietf-lisp-rfc6830bis] [I-D.ietf-lisp-rfc6830bis]
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos-Aparicio, "The Locator/ID Separation Protocol Cabellos-Aparicio, "The Locator/ID Separation Protocol
(LISP)", draft-ietf-lisp-rfc6830bis-32 (work in progress), (LISP)", draft-ietf-lisp-rfc6830bis-36 (work in progress),
March 2020. November 2020.
[I-D.templin-6man-omni-interface] [I-D.templin-6man-omni-interface]
Templin, F. and T. Whyman, "Transmission of IPv6 Packets Templin, F. and T. Whyman, "Transmission of IP Packets
over Overlay Multilink Network (OMNI) Interfaces", draft- over Overlay Multilink Network (OMNI) Interfaces", draft-
templin-6man-omni-interface-26 (work in progress), June templin-6man-omni-interface-61 (work in progress),
2020. December 2020.
[I-D.templin-intarea-6706bis] [I-D.templin-intarea-6706bis]
Templin, F., "Asymmetric Extended Route Optimization Templin, F., "Asymmetric Extended Route Optimization
(AERO)", draft-templin-intarea-6706bis-58 (work in (AERO)", draft-templin-intarea-6706bis-80 (work in
progress), June 2020. progress), December 2020.
[ICAO] ICAO, I., "http://www.icao.int/Pages/default.aspx",
February 2017.
[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>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>. December 2005, <https://www.rfc-editor.org/info/rfc4301>.
skipping to change at page 19, line 51 skipping to change at page 20, line 22
2011, <https://www.rfc-editor.org/info/rfc6275>. 2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
Autonomous System (AS) Number Space", RFC 6793, Autonomous System (AS) Number Space", RFC 6793,
DOI 10.17487/RFC6793, December 2012, DOI 10.17487/RFC6793, December 2012,
<https://www.rfc-editor.org/info/rfc6793>. <https://www.rfc-editor.org/info/rfc6793>.
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
for when an MNP is asserted at a new location or withdrawn from an for when an MNP-ULA is asserted at a new location or withdrawn from
old location can be several hundred milliseconds even under optimal an old location can be several hundred milliseconds even under
AS peering arrangements. This means that packets in flight destined optimal AS peering arrangements. This means that packets in flight
to an MNP route that has recently been changed can be (mis)delivered destined to an MNP-ULA route that has recently been changed can be
to 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 a SPAN address for the new for a "departed" Client that includes an OAL address for the new
s-ASBR. The SPAN 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
accommodated without loss. accommodated without loss.
Appendix B. Change Log Appendix B. Change Log
 End of changes. 45 change blocks. 
158 lines changed or deleted 197 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/