The worldwide Air Traffic Management (ATM) system today uses a
service known as Aeronautical Telecommunications Network based on Open
Systems Interconnection (ATN/OSI). The service is used to augment
controller to pilot voice communications with rudimentary short text
command and control messages. The service has seen successful deployment
in a limited set of worldwide ATM domains.¶
The International Civil Aviation Organization (ICAO) is now
undertaking the development of a next-generation replacement for ATN/OSI
known as Aeronautical Telecommunications Network with Internet Protocol
Services (ATN/IPS) [ATN][ATN-IPS]. ATN/IPS
will eventually provide an IPv6-based [RFC8200] service
supporting pervasive ATM for Air Traffic Controllers (ATC), Airline
Operations Controllers (AOC), and all commercial aircraft worldwide. As
part of the ATN/IPS undertaking, a new mobile routing service will be
needed. This document presents an approach based on the Border Gateway
Protocol (BGP) [RFC4271].¶
Aircraft communicate via wireless aviation data links that typically
support much lower data rates than terrestrial wireless and wired-line
communications. For example, some Very High Frequency (VHF)-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 future
aeronautical communications only supports rates on the order of 1Mbps.
Although satellite data links can provide much higher data rates during
optimal conditions, like any other aviation data link they are subject
to errors, delay, disruption, signal intermittence, degradation due to
atmospheric conditions, etc. The well-connected ground domain ATN/IPS
network should therefore treat each safety-of-flight critical packet
produced by (or destined to) an aircraft as a precious commodity and
strive for an optimized service that provides the highest possible
degree of reliability.¶
The ATN/IPS is an IPv6-based overlay network configured over one or
more Internetworking underlays ("INETs") maintained by aeronautical
network service providers such as ARINC, SITA and Inmarsat. The Overlay
Multilink Network Interface (OMNI) [I-D.templin-6man-omni] uses an adaptation layer encapsulation
to create a Non-Broadcast, Multiple Access (NBMA) virtual link spanning
the entire ATN/IPS. Each aircraft connects to the OMNI link via an OMNI
interface configured over the aircraft's underlying physical and/or
virtual access network interfaces.¶
Each underlying INET comprises one or more "partitions" where all
nodes within a partition can exchange packets with all other nodes,
i.e., the partition is connected internally. There is no requirement
that any two INET partitions use the same IP protocol version nor have
consistent IP addressing plans in comparison with other partitions.
Instead, the OMNI link sees each partition as a "segment" of a
link-layer topology concatenated by a service known as the OMNI
Adaptation Layer (OAL) [I-D.templin-6man-omni] based
on IPv6 encapsulation [RFC2473].¶
The IPv6 addressing architecture provides different classes of
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. (Note that while IPv6 GUAs
are assumed for ATN/IPS, IPv4 with public/private address could also
be used.)¶
The adaptation layer uses ULAs in the source and destination addresses
of adaptation layer IPv6 encapsulation headers. Each ULA includes an
MNP in the interface identifier ("MNP-ULA"), as discussed
in [I-D.templin-6man-omni]. Due to MNP delegation policies
and random node mobility properties, MNP-ULAs are generally not
aggregatable in the BGP routing service and are represented as many
more-specific prefixes instead of a smaller number of aggregated prefixes.¶
In addition, BGP routing service infrastructure nodes configure
administratively-assigned ULAs ("ADM-ULA") that are statically-assigned
and derived from a shorter ADM-ULA prefix assigned to their BGP network
partitions. Unlike MNP-ULAs, the ADM-ULAs are persistently present and
unchanging in the routing system. The BGP routing services therefore
perform forwarding based on these MNP-ULAs and ADM-ULAs instead of based
on the GUA MNPs themselves. Both ADM-ULAs and MNP-ULAs are used by the
OAL for nested encapsulation where the inner IPv6 packet is encapsulated
in an IPv6 adaptation layer header with ULA source and destination
addresses, which is then encapsulated in an IP header specific to the
underlying Internetwork that will carry the actual packet transmission.¶
Connexion By Boeing [CBB] was an early aviation mobile
routing service based on dynamic updates in the global public Internet
BGP routing system. Practical experience with the approach has shown
that frequent injections and withdrawals of prefixes in the Internet
routing system can result in excessive BGP update messaging, slow
routing table convergence times, and extended outages when no route is
available. This is due to both conservative default BGP protocol timing
parameters (see Section 6) and the complex peering
interconnections of BGP routers within the global Internet
infrastructure. The situation is further exacerbated by frequent
aircraft mobility events that each result in BGP updates that must be
propagated to all BGP routers in the Internet that carry a full routing
table.¶
We therefore consider an approach using a BGP overlay network routing
system where a private BGP routing protocol instance is maintained
between ATN/IPS Autonomous System (AS) Border Routers (ASBRs). The
private BGP instance does not interact with the native BGP routing
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
hub-and-spokes topology. No extensions to the BGP protocol are
necessary, and BGP routing is based on (intermediate-layer) ULAs instead
of upper- or lower-layer public/private IP prefixes. This allows ASBRs to
perform adaptation layer forwarding based on intermediate layer IPv6
header information instead of network layer forwarding based on upper
layer IP header information or link layer forwarding based on lower
layer IP header information.¶
The s-ASBRs for each stub AS connect to a small number of c-ASBRs
via dedicated high speed links and/or secured tunnels (e.g., IPsec
[RFC4301], WireGuard [WG], etc.) over
the underlying INET. Neighboring ASBRs should use also such IP layer
security encapsulations over direct physical links to ensure INET
layer security.¶
The s-ASBRs engage in external BGP (eBGP) peerings with their
respective c-ASBRs, and only maintain routing table entries for the
MNP-ULAs currently active within the stub AS. The s-ASBRs send BGP
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
default routes with their c-ASBRs as the next hop, and therefore hold
only partial topology information.¶
The c-ASBRs connect to other c-ASBRs within the same partition using
internal BGP (iBGP) peerings over which they collaboratively maintain a
full routing table for all active MNP-ULAs currently in service within
the partition. Therefore, only the c-ASBRs maintain a full BGP routing
table and never send any BGP updates to s-ASBRs. This simple routing
model therefore greatly reduces the number of BGP updates that need to
be synchronized among peers, and the number is reduced further still
when intradomain routing changes within stub ASes are processed within
the AS instead of being propagated to the core. BGP Route Reflectors
(RRs) [RFC4456] can also be used to support increased
scaling properties.¶
When there are multiple INET partitions, the c-ASBRs of each
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 all of
the c-ASBRs. Each c/s-ASBR further configures an ADM-ULA which is taken
from an ADM-ULA prefix assigned to each partition, as well as static
forwarding table entries for all other OMNI link partition prefixes.
Both ADM-ULAs and MNP-ULAs are used by the OAL 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.¶
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. AERO [I-D.templin-6man-aero]
provides an example service 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/IPS mobile routing service.¶