< draft-ietf-rtgwg-atn-bgp-10.txt   draft-ietf-rtgwg-atn-bgp-11.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: July 5, 2021 G. Dawra Expires: January 7, 2022 G. Dawra
LinkedIn LinkedIn
A. Lindem A. Lindem
V. Moreno V. Moreno
Cisco Systems, Inc. Cisco Systems, Inc.
January 1, 2021 July 6, 2021
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-10 draft-ietf-rtgwg-atn-bgp-11
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 July 5, 2021. This Internet-Draft will expire on January 7, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. ATN/IPS Routing System . . . . . . . . . . . . . . . . . . . 8 3. ATN/IPS Routing System . . . . . . . . . . . . . . . . . . . 8
4. ATN/IPS (Radio) Access Network (ANET) Model . . . . . . . . . 12 4. ATN/IPS (Radio) Access Network (ANET) Model . . . . . . . . . 12
5. ATN/IPS Route Optimization . . . . . . . . . . . . . . . . . 14 5. ATN/IPS Route Optimization . . . . . . . . . . . . . . . . . 14
6. BGP Protocol Considerations . . . . . . . . . . . . . . . . . 16 6. BGP Protocol Considerations . . . . . . . . . . . . . . . . . 16
7. Stub AS Mobile Routing Services . . . . . . . . . . . . . . . 18 7. Stub AS Mobile Routing Services . . . . . . . . . . . . . . . 18
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. BGP Convergence Considerations . . . . . . . . . . . 21 Appendix A. BGP Convergence Considerations . . . . . . . . . . . 21
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 22 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
The worldwide Air Traffic Management (ATM) system today uses a The worldwide Air Traffic Management (ATM) system today uses a
service known as Aeronautical Telecommunications Network based on service known as Aeronautical Telecommunications Network based on
Open Systems Interconnection (ATN/OSI). The service is used to Open Systems Interconnection (ATN/OSI). The service is used to
augment controller to pilot voice communications with rudimentary augment controller to pilot voice communications with rudimentary
short text command and control messages. The service has seen short text command and control messages. The service has seen
successful deployment in a limited set of worldwide ATM domains. successful deployment in a limited set of worldwide ATM domains.
skipping to change at page 3, line 30 skipping to change at page 3, line 30
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. The network service providers such as ARINC, SITA and Inmarsat. The
overlay provides an Overlay Multilink Network Interface (OMNI) overlay provides an Overlay Multilink Network Interface (OMNI)
virtual link layer [I-D.templin-6man-omni-interface] as a Non- virtual link layer [I-D.templin-6man-omni] as a Non-Broadcast,
Broadcast, Multiple Access (NBMA) virtual link that spans the entire Multiple Access (NBMA) virtual link that spans the entire ATN/IPS.
ATN/IPS. Each aircraft connects to the OMNI link via an OMNI Each aircraft connects to the OMNI link via an OMNI interface
interface configured over the aircraft's underlying physical and/or configured over the aircraft's underlying physical and/or virtual
virtual access network interfaces. access network interfaces.
Each underlying INET comprises one or more "partitions" where all Each underlying INET comprises one or more "partitions" where all
nodes within a partition can exchange packets with all other nodes, nodes within a partition can exchange packets with all other nodes,
i.e., the partition is connected internally. There is no requirement i.e., the partition is connected internally. There is no requirement
that any two INET partitions use the same IP protocol version nor that any two INET partitions use the same IP protocol version nor
have consistent IP addressing plans in comparison with other have consistent IP addressing plans in comparison with other
partitions. Instead, the OMNI link sees each partition as a partitions. Instead, the OMNI link sees each partition as a
"segment" of a link-layer topology manifested through a (virtual) "segment" of a link-layer topology manifested through a (virtual)
bridging service based on IPv6 encapsulation [RFC2473] known as the bridging service based on IPv6 encapsulation [RFC2473] known as the
OMNI Adaptation Layer (OAL) OMNI Adaptation Layer (OAL)
[I-D.templin-6man-omni-interface][I-D.templin-intarea-6706bis]. [I-D.templin-6man-omni][I-D.templin-6man-aero].
The IPv6 addressing architecture provides different classes of The IPv6 addressing architecture provides different classes of
addresses, including Global Unicast Addresses (GUAs), Unique Local addresses, including Global Unicast Addresses (GUAs), Unique Local
Addresses (ULAs) and Link-Local Addresses (LLAs) [RFC4291][RFC4193]. Addresses (ULAs) and Link-Local Addresses (LLAs) [RFC4291][RFC4193].
The ATN/IPS receives an IPv6 GUA Mobility Service Prefix (MSP) from The ATN/IPS receives an IPv6 GUA Mobility Service Prefix (MSP) from
an Internet assigned numbers authority, and each aircraft will an Internet assigned numbers authority, and each aircraft will
receive a Mobile Network Prefix (MNP) delegation from the MSP that receive a Mobile Network Prefix (MNP) delegation from the MSP that
accompanies the aircraft wherever it travels. ATCs and AOCs will accompanies the aircraft wherever it travels. ATCs and AOCs will
likewise receive MNPs, but they would typically appear in static (not likewise receive MNPs, but they would typically appear in static (not
mobile) deployments such as air traffic control towers, airline mobile) deployments such as air traffic control towers, airline
headquarters, etc. headquarters, etc.
The OAL uses ULAs in the source and destination addresses of IPv6 The OAL uses ULAs in the source and destination addresses of IPv6
encapsulation headers. Each ULA includes an MNP in the interface encapsulation headers. Each ULA includes an MNP in the interface
identifier ("MNP-ULA") as discussed in identifier ("MNP-ULA") as discussed in [I-D.templin-6man-omni]. Due
[I-D.templin-6man-omni-interface]. Due to MNP delegation policies to MNP delegation policies and random MN mobility properties, MNP-
and random MN mobility properties, MNP-ULAs are generally not ULAs are generally not aggregatable in the BGP routing service and
aggregatable in the BGP routing service. In addition, OMNI link are represented as many more-specific prefixes instead of a smaller
service nodes configure administratively-assigned ULAs ("ADM-ULA") number of aggregated prefixes. In addition, OMNI link service nodes
that are statically-assigned and derived from a shorter ADM-ULA configure administratively-assigned ULAs ("ADM-ULA") that are
prefix assigned to their OMNI link partition statically-assigned and derived from a shorter ADM-ULA prefix
[I-D.templin-6man-omni-interface]. Unlike MNP-ULAs, the ADM-ULAs are assigned to their OMNI link partition [I-D.templin-6man-omni].
persistently present and unchanging in the routing system. The BGP Unlike MNP-ULAs, the ADM-ULAs are persistently present and unchanging
routing services therefore perform forwarding based on these MNP-ULAs in the routing system. The BGP routing services therefore perform
and ADM-ULAs instead of based on the GUA MNPs themselves. forwarding based on these MNP-ULAs and ADM-ULAs instead of based on
the GUA 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 prefixes in the Internet that frequent injections and withdrawals of prefixes in the Internet
routing system can result in excessive BGP update messaging, slow routing system can result in excessive BGP update messaging, slow
routing table convergence times, and extended outages when no route routing table convergence times, and extended outages when no route
is available. This is due to both conservative default BGP protocol is available. This is due to both conservative default BGP protocol
timing parameters (see Section 6) and the complex peering timing parameters (see Section 6) and the complex peering
interconnections of BGP routers within the global Internet interconnections of BGP routers within the global Internet
skipping to change at page 4, line 47 skipping to change at page 4, line 48
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. BGP routing is based on the ULAs found in OAL headers, necessary. BGP routing is based on the ULAs found in OAL headers,
i.e., it provides an adaptation layer forwarding service instead of a i.e., it provides an adaptation layer forwarding service instead of a
networking layer services. networking layer routing service.
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 secured encapsulations (e.g., IPsec [RFC4301], industry-standard secured encapsulations (e.g., IPsec [RFC4301],
Wireguard, etc.). In particular, tunneling must be used when Wireguard, etc.). In particular, tunneling must be used when
neighboring ASBRs are separated by multiple INET hops. neighboring ASBRs are separated by multiple INET 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
MNP-ULAs currently active within the stub AS. The s-ASBRs send BGP MNP-ULAs currently active within the stub AS. The s-ASBRs send BGP
skipping to change at page 5, line 31 skipping to change at page 5, line 32
updates that need to be synchronized among peers, and the number is updates that need to be synchronized among peers, and the number is
reduced further still when intradomain routing changes within stub reduced further still when intradomain routing changes within stub
ASes are processed within the AS instead of being propagated to the ASes are processed within the AS instead of being propagated to the
core. BGP Route Reflectors (RRs) [RFC4456] can also be used to core. BGP Route Reflectors (RRs) [RFC4456] can also be used to
support 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 ULAs 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 an ADM-ULA all of the c-ASBRs. Each c/s-ASBR further configures an ADM-ULA
which is taken from a ADM-ULA prefix assigned to each partition, as which is taken from an ADM-ULA prefix assigned to each partition, 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
plane spanning tree is established that properly covers the entire
operating domain. All nodes in the network can be visited using
strict spanning tree hops, but in many instances this may result in
longer paths than are necessary. The AERO and OMNI services
[I-D.templin-6man-aero][I-D.templin-6man-omni] provide mechanisms for
discovering and utilizing (route-optimized) shortcuts that do not
always follow strict spanning tree paths.
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].
The following terms are defined for the purposes of this document: The following terms are defined for the purposes of this document:
skipping to change at page 7, line 12 skipping to change at page 7, line 21
is therefore based on ULAs instead of GUAs. In this way, packets 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 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 though there may be many underlying INET partitions in the path to
the destination. the destination.
OMNI Adaptation Layer (OAL) OMNI Adaptation Layer (OAL)
A middle layer below the IPv6 layer but above the INET layer that A middle layer below the IPv6 layer but above the INET layer that
applies IPv6-in-IPv6 encapsulation prior to INET encapsulation. applies IPv6-in-IPv6 encapsulation prior to INET encapsulation.
The IPv6 encapsulation header inserted by the OAL uses ULAs The IPv6 encapsulation header inserted by the OAL uses ULAs
instead of GUAs. Further details on OMNI and the OAL are found in instead of GUAs. Further details on OMNI and the OAL are found in
[I-D.templin-6man-omni-interface]. [I-D.templin-6man-omni].
OAL Autonomous System 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 OMNI virtual link between the core autonomous systems of different OMNI virtual link
partitions. partitions.
Core Autonomous System Border Router (c-ASBR) Core Autonomous System Border Router (c-ASBR)
A BGP router located in the hub of the INET partition hub-and- A BGP router located in the hub of the INET partition hub-and-
spokes overlay network topology. spokes overlay network topology.
skipping to change at page 10, line 27 skipping to change at page 10, line 27
ULA prefix that is permanently announced into the routing system. ULA prefix that is permanently announced into the routing system.
The core ASes of each INET partition are joined together through The core ASes of each INET partition are joined together through
external BGP peerings. The c-ASBRs of each partition establish external BGP peerings. The c-ASBRs of each partition establish
external peerings with the c-ASBRs of other partitions to form a external peerings with the c-ASBRs of other partitions to form a
"core-of-cores" OMNI link AS. The OMNI link AS contains the global "core-of-cores" OMNI link AS. The OMNI link AS contains the global
knowledge of all MNP-ULAs deployed worldwide, and supports ATN/IPS knowledge of all MNP-ULAs deployed worldwide, and supports ATN/IPS
overlay communications between nodes located in different INET overlay communications between nodes located in different INET
partitions by virtue of OAL encapsulation. OMNI link nodes can then partitions by virtue of OAL encapsulation. OMNI link nodes can then
navigate to ASBRs by including an ADM-ULA or directly to an end navigate to ASBRs by including an ADM-ULA or directly to an end
system by including an MNP-ULA in the destination address of an OAL- system by including an MNP-ULA in the destination address of an OAL-
encapsulated packet (see: [I-D.templin-intarea-6706bis]) . Figure 2 encapsulated packet (see: [I-D.templin-6man-aero]). Figure 2 shows a
shows a reference OAL topology. reference OAL topology.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . .
. .-(::::::::) . . .-(::::::::) .
. .-(::::::::::::)-. +------+ . . .-(::::::::::::)-. +------+ .
. (::: Partition 1 ::)--|c-ASBR|---+ . . (::: Partition 1 ::)--|c-ASBR|---+ .
. `-(::::::::::::)-' +------+ | . . `-(::::::::::::)-' +------+ | .
. `-(::::::)-' | . . `-(::::::)-' | .
. | . . | .
. .-(::::::::) | . . .-(::::::::) | .
skipping to change at page 12, line 29 skipping to change at page 12, line 29
applications (such as unmanned air vehicles and terrestrial vehicles) applications (such as unmanned air vehicles and terrestrial vehicles)
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] over their underlying ANET interfaces as a
interfaces as a connection to an NBMA virtual link (manifested by the connection to an NBMA virtual link (manifested by the OAL) that spans
OAL) that spans the entire ATN/IPS. Clients may further move between the entire ATN/IPS. Clients may further move between ANETs in a
ANETs in a manner that is perceived as a network layer mobility manner that is perceived as a network layer mobility event. Clients
event. Clients could therefore employ a multilink/mobility routing could therefore employ a multilink/mobility routing service such as
service such as those discussed in Section 7. those discussed in Section 7.
Clients register all of their active data link connections with their Clients register all of their active data link connections with their
serving s-ASBRs as discussed in Section 3. Clients may connect to serving s-ASBRs as discussed in Section 3. Clients may connect to
s-ASBRs either directly, or via a Proxy 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 13, line 38 skipping to change at page 13, line 38
. `-(:: System ::::)-' . . `-(:: System ::::)-' .
. `-(:::::::-' . . `-(:::::::-' .
. . . .
. . . .
. <------- OMNI virtual link bridged by the OAL --------> . . <------- 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. The login process is
s-ASBR could be through consulting a geographically-keyed static host transparently brokered by a Proxy at the border of the ANET which
file, through a DNS lookup, through a network query response, etc.) then conveys the connection request to the s-ASBR via tunneling
The login process is transparently brokered by a Proxy at the border across the OMNI virtual link. Each ANET border Proxy is also equally
of the ANET, which then conveys the connection request to the s-ASBR capable of serving in the s-ASBR role so that a first on-link Proxy
via tunneling across the OMNI virtual link. The s-ASBR then can be selected as the s-ASBR while all others perform the Proxy role
registers the address of the Proxy as the address for the Client, and in a hub-and-spokes arrangement. An on-link Proxy is selected to
the Proxy forwards the s-ASBR's reply to the Client. If the Client serve the s-ASBR role when it receives a control message from a
connects to multiple ANETs, the s-ASBR will register the addresses of Client requesting that service.
all Proxies as addresses through which the Client can be reached.
A network-based s-ASBR can also be selected when the ANET does not
provide a Proxy, or when a different ANET Proxy has already been
selected. Selection of a network-based s-ASBR could be through an
address discovered through a first ANET Proxy, through consulting a
geographically-keyed static host file, through a DNS lookup, through
a network query response, etc. The s-ASBR then registers the address
of the Proxy as the address for the Client, and the Proxy forwards
the s-ASBR's reply to the Client. If the Client connects to multiple
ANETs, the s-ASBR will register the addresses of all Proxies as
addresses through which the Client can be reached.
The s-ASBR represents all of its active Clients as MNP-ULA routes in The s-ASBR represents all of its active Clients as MNP-ULA routes in
the ATN/IPS BGP routing system. The s-ASBR's stub AS therefore the ATN/IPS BGP routing system. The s-ASBR's stub AS therefore
consists of the set of all of its active Clients (i.e., the stub AS consists of the set of all of its active Clients (i.e., the stub AS
is a logical construct and not a physical construct). The s-ASBR is a logical construct and not a physical construct). The s-ASBR
injects the MNP-ULAs of its active Clients and withdraws the MNP-ULAs injects the MNP-ULAs of its active Clients and withdraws the MNP-ULAs
of its departed Clients via BGP updates to c-ASBRs, which further of its departed Clients via BGP updates to c-ASBRs, which further
propagate the MNP-ULAs to other c-ASBRs within the OAL AS. Since propagate the MNP-ULAs to other c-ASBRs within the OAL AS. Since
Clients are expected to remain associated with their current s-ASBR Clients are expected to remain associated with their current s-ASBR
for extended periods, the level of MNP-ULA injections and withdrawals for extended periods, the level of MNP-ULA injections and withdrawals
skipping to change at page 14, line 23 skipping to change at page 14, line 33
are coordinated only by Proxies and the Client's current s-ASBRs, and are coordinated only by Proxies and the Client's current s-ASBRs, and
do not involve other ASBRs in the routing system. In this way, do not involve other ASBRs in the routing system. In this way,
intradomain routing changes within the stub AS are not propagated intradomain routing changes within the stub AS are not propagated
into the rest of the 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 spanning tree segments in the
path. In many cases, it would be desirable to eliminate extraneous forwarding path. In many cases, it would be desirable to eliminate
tunnel segments from this "dogleg" route so that packets can traverse extraneous spanning tree segments from this "dogleg" route so that
a minimum number of tunneling hops across the OMNI virtual link. packets can traverse a minimum number of tunneling hops across the
ATN/IPS end systems could therefore employ a route optimization OMNI virtual link. ATN/IPS end systems could therefore employ a
service according to the mobility service employed (see: Section 7). route optimization 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 spanning tree segments between Proxys
ASBRs are necessary to convey packets between Clients associated with and ASBRs are necessary to convey packets between Clients associated
different s-ASBRs. In the second figure, the optimized route tunnels with different s-ASBRs. In the second figure, the optimized route
packets directly between Proxys without involving the ASBRs. tunnels packets directly between Proxys without involving the ASBRs.
+---------+ +---------+ +---------+ +---------+
| Client1 | | Client2 | | Client1 | | Client2 |
+---v-----+ +-----^---+ +---v-----+ +-----^---+
* * * *
* * * *
(:::)-. (:::)-. (:::)-. (:::)-.
.-(:::::::::)<- (Radio) Access Networks ->.-(:::::::::) .-(:::::::::)<- (Radio) Access Networks ->.-(:::::::::)
`-(::::)-' `-(::::)-' `-(::::)-' `-(::::)-'
+--------+ +--------+ +--------+ +--------+
skipping to change at page 17, line 49 skipping to change at page 17, line 49
implementation should provide isolation between the two BGP routing implementation should provide isolation between the two BGP routing
domains (e.g., separate BGP instances). domains (e.g., separate BGP instances).
ADM-ULAs and MNP-ULAs begin with fd00::/8 followed by a pseudo-random ADM-ULAs and MNP-ULAs begin with fd00::/8 followed by a pseudo-random
40-bit global ID to form the prefix [ULA]::/48, along with a 16-bit 40-bit global ID to form the prefix [ULA]::/48, along with a 16-bit
OMNI link identifier '*' to form the prefix [ULA*]::/64. Each OMNI link identifier '*' to form the prefix [ULA*]::/64. Each
individual address taken from [ULA*]::/64 includes additional routing individual address taken from [ULA*]::/64 includes additional routing
information in the interface identifier. For example, for the MNP information in the interface identifier. For example, for the MNP
2001:db8:1:0::/56, the resulting MNP-ULA is [ULA*]:2001:db8:1:0/120, 2001:db8:1:0::/56, the resulting MNP-ULA is [ULA*]:2001:db8:1:0/120,
and for the administrative address 1001:2002/16 the ADM-ULA is and for the administrative address 1001:2002/16 the ADM-ULA is
[ULA*]::1001:2002/112 (see: [I-D.templin-6man-omni-interface] for [ULA*]::1001:2002/112 (see: [I-D.templin-6man-omni] for further
further details). This gives rise to a BGP routing system that must details). This gives rise to a BGP routing system that must
accommodate large numbers of long and non-aggregatable MNP-ULA accommodate large numbers of long and non-aggregatable MNP-ULA
prefixes as well as moderate numbers of long and semi-aggregatable prefixes as well as moderate numbers of long and semi-aggregatable
ADM-ULA prefixes. The system is kept stable and scalable through the ADM-ULA prefixes. The system is kept stable and scalable through the
s-ASBR / c-ASBR hub-and-spokes topology which ensures that mobility- s-ASBR / c-ASBR hub-and-spokes topology which ensures that mobility-
related churn is not exposed to the core. related churn is not exposed to the core.
7. Stub AS Mobile Routing Services 7. Stub AS Mobile Routing Services
Stub ASes maintain intradomain routing information for mobile node Stub ASes maintain intradomain routing information for mobile node
clients, and are responsible for all localized mobility signaling clients, and are responsible for all localized mobility signaling
without disturbing the BGP routing system. Clients can enlist the without disturbing the BGP routing system. Clients can enlist the
services of a candidate mobility service such as Mobile IPv6 (MIPv6) services of a candidate mobility service such as Mobile IPv6 (MIPv6)
[RFC6275], LISP [I-D.ietf-lisp-rfc6830bis] 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-6man-aero] according to the service offered by the stub
stub AS. Further details of mobile routing services are out of scope AS. Further details of mobile routing services are out of scope for
for this document. this document.
8. Implementation Status 8. Implementation Status
The BGP routing topology described in this document has been modeled The BGP routing topology described in this document has been modeled
in realistic network emulations showing that at least 1 million MNP- in realistic network emulations showing that at least 1 million MNP-
ULAs 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
skipping to change at page 20, line 44 skipping to change at page 20, line 44
[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, "The Locator/ID Separation Protocol (LISP)",
(LISP)", draft-ietf-lisp-rfc6830bis-36 (work in progress), draft-ietf-lisp-rfc6830bis-36 (work in progress), November
November 2020. 2020.
[I-D.templin-6man-omni-interface] [I-D.templin-6man-aero]
Templin, F. and T. Whyman, "Transmission of IP Packets Templin, F. L., "Automatic Extended Route Optimization
over Overlay Multilink Network (OMNI) Interfaces", draft- (AERO)", draft-templin-6man-aero-01 (work in progress),
templin-6man-omni-interface-67 (work in progress), April 2021.
December 2020.
[I-D.templin-intarea-6706bis] [I-D.templin-6man-omni]
Templin, F., "Asymmetric Extended Route Optimization Templin, F. L. and T. Whyman, "Transmission of IP Packets
(AERO)", draft-templin-intarea-6706bis-86 (work in over Overlay Multilink Network (OMNI) Interfaces", draft-
progress), December 2020. templin-6man-omni-03 (work in progress), April 2021.
[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 22, line 9 skipping to change at page 22, line 9
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
<< RFC Editor - remove prior to publication >> << RFC Editor - remove prior to publication >>
Changes from -10 to -11:
o Introduced notion of the spanning tree
o Discussed Proxy/s-ASBR arrangement options.
Changes from -05 to -06: Changes from -05 to -06:
o OMNI interface introduced o OMNI interface introduced
o Version and reference update. o Version and reference update.
Changes from -04 to -05: Changes from -04 to -05:
o Version and reference update. o Version and reference update.
 End of changes. 24 change blocks. 
71 lines changed or deleted 97 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/