< draft-ietf-rtgwg-atn-bgp-01.txt   draft-ietf-rtgwg-atn-bgp-02.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 15, 2019 G. Dawra Expires: November 15, 2019 G. Dawra
LinkedIn LinkedIn
A. Lindem A. Lindem
V. Moreno V. Moreno
Cisco Systems, Inc. Cisco Systems, Inc.
January 11, 2019 May 14, 2019
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-01.txt draft-ietf-rtgwg-atn-bgp-02.txt
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 15, 2019. This Internet-Draft will expire on November 15, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . 6 3. ATN/IPS Routing System . . . . . . . . . . . . . . . . . . . 7
4. ATN/IPS Radio Access Network (RAN) Model . . . . . . . . . . 9 4. ATN/IPS (Radio) Access Network (ANET) Model . . . . . . . . . 10
5. ATN/IPS Route Optimization . . . . . . . . . . . . . . . . . 11 5. ATN/IPS Route Optimization . . . . . . . . . . . . . . . . . 12
6. BGP Protocol Considerations . . . . . . . . . . . . . . . . . 13 6. BGP Protocol Considerations . . . . . . . . . . . . . . . . . 14
7. Stub AS Mobile Routing Services . . . . . . . . . . . . . . . 14 7. Stub AS Mobile Routing Services . . . . . . . . . . . . . . . 15
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. BGP Convergence Considerations . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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 24 skipping to change at page 3, line 25
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 that assumes a worldwide The ATN/IPS is an IPv6-based overlay network configured over one or
connected Internetworking underlay for carrying tunneled ATM more Internetworking underlays ("INETs") maintained by aeronautical
communications. The Internetworking underlay could be manifested as network service providers such as ARINC, SITA and Inmarsat. Each
a private collection of long-haul backbone links (e.g., fiber optics, INET comprises one or more "partitions" where all nodes within a
copper, SATCOM, etc.) interconnected by high-performance networking partition can exchange packets with all other nodes, i.e., the
gear such as bridges, switches, and routers. Such a private network partition is connected internally. There is no requirement that any
would need to connect all ATN/IPS participants worldwide, and could two INET partitions use the same IP protocol version nor have
therefore present a considerable cost for a large-scale deployment of consistent IP addressing plans in comparison with other partitions.
new infrastructure. Alternatively, the ATN/IPS could be deployed as Instead, the ATN/IPS IPv6 overlay sees each partition as a "segment"
a secured overlay over the existing global public Internet. For of a link-layer topology manifested through a (virtual) bridging
example, ATN/IPS nodes could be deployed as part of an SD-WAN or an service known as "Spanning Partitioned Aeronautical Networks (SPAN)".
MPLS-WAN that rides over the public Internet via secured tunnels. Further discussion of the SPAN is found in the following sections of
Further details of the Internetworking underlay design are out of this document, with reference to [I-D.templin-intarea-6706bis].
scope for this document.
The ATN/IPS further assumes that each aircraft will receive an IPv6 The ATN/IPS further assumes that each aircraft will receive an IPv6
Mobile Network Prefix (MNP) that accompanies the aircraft wherever it Mobile Network Prefix (MNP) that accompanies the aircraft wherever it
travels. ICAO is further proposing to assign each aircraft an entire travels. ICAO is further proposing to assign each aircraft an entire
/56 MNP for numbering its on-board networks. ATCs and AOCs will /56 MNP for numbering its on-board networks. ATCs and AOCs will
likewise receive IPv6 prefixes, but they would typically appear in likewise receive IPv6 prefixes, but they would typically appear in
static (not mobile) deployments such as air traffic control towers, static (not mobile) deployments such as air traffic control towers,
airline headquarters, etc. Throughout the rest of this document, we airline headquarters, etc. Throughout the rest of this document, we
therefore use the term "MNP" when discussing an IPv6 prefix that is therefore use the term "MNP" when discussing an IPv6 prefix that is
delegated to any ATN/IPS end system, including ATCs, AOCs, and delegated to any ATN/IPS end system, including ATCs, AOCs, and
skipping to change at page 4, line 25 skipping to change at page 4, line 25
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
system in the connected Internetworking underlay, and BGP updates are systems in underlying INETs, and BGP updates are unidirectional from
unidirectional from "stub" ASBRs (s-ASBRs) to a small set of "core" "stub" ASBRs (s-ASBRs) to a small set of "core" ASBRs (c-ASBRs) in a
ASBRs (c-ASBRs) in a hub-and-spokes topology. No extensions to the hub-and-spokes topology. No extensions to the BGP protocol are
BGP protocol are necessary. necessary.
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 Internetworking dedicated high speed links and/or tunnels across the INET using
underlay using industry-standard encapsulations (e.g., Generic industry-standard encapsulations (e.g., Generic Routing Encapsulation
Routing Encapsulation (GRE) [RFC2784], IPsec [RFC4301], etc.). In (GRE) [RFC2784], IPsec [RFC4301], etc.). In particular, tunneling
particular, tunneling must be used when neighboring ASBRs are must be used when neighboring ASBRs are separated by multiple INET
separated by multiple Internetworking underlay 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 MNPs 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 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 using internal BGP (iBGP) The c-ASBRs connect to other c-ASBRs within the same partition using
peerings over which they collaboratively maintain a full routing internal BGP (iBGP) peerings over which they collaboratively maintain
table for all active MNPs currently in service. Therefore, only the a full routing table for all active MNPs currently in service within
c-ASBRs maintain a full BGP routing table and never send any BGP the partition. Therefore, only the c-ASBRs maintain a full BGP
updates to s-ASBRs. This simple routing model therefore greatly routing table and never send any BGP updates to s-ASBRs. This simple
reduces the number of BGP updates that need to be synchronized among routing model therefore greatly reduces the number of BGP updates
peers, and the number is reduced further still when intradomain that need to be synchronized among peers, and the number is reduced
routing changes within stub ASes are processed within the AS instead further still when intradomain routing changes within stub ASes are
of being propagated to the core. BGP Route Reflectors (RRs) processed within the AS instead of being propagated to the core. BGP
[RFC4456] can also be used to support increased scaling properties. 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 MNPs for all partitions are known globally among
all of the c-ASBRs. Each c/s-ASBR further configures a "SPAN
address" which is taken from a global or unique-local IPv6 "SPAN
prefix" assigned to each partition, as well as static forwarding
table entries for all other prefixes in the SPAN. The SPAN addresses
are used for nested encapsulation where the inner IPv6 packet is
encapsulated in a SPAN header which is then encapsulated in an IP
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].
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 5, line 35 skipping to change at page 5, line 47
Airline Operations Controller (AOC) Airline Operations Controller (AOC)
An airline agent responsible for tracking and coordinating with An airline agent responsible for tracking and coordinating with
aircraft within their fleet. aircraft within their fleet.
Aeronautical Telecommunications Network with Internet Protocol Aeronautical Telecommunications Network with Internet Protocol
Services (ATN/IPS) Services (ATN/IPS)
A future aviation network for ATCs and AOCs to coordinate with all A future aviation network for ATCs and AOCs to coordinate with all
aircraft operating worldwide. The ATN/IPS will be an IPv6-based aircraft operating worldwide. The ATN/IPS will be an IPv6-based
overlay network service that connects access networks via overlay network service that connects access networks via
tunneling over an Internetworking underlay. tunneling over one or more Internetworking underlays.
Internetworking underlay A connected wide-area network that supports Internetworking underlay ("INET")
overlay network tunneling and connects Radio Access Networks to A wide-area network that supports overlay network tunneling and
the rest of the ATN/IPS. connects Radio Access Networks to the rest of the ATN/IPS.
Radio Access Network (RAN) Example INET service providers for civil aviation include ARINC,
SITA and Inmarsat.
(Radio) Access Network ("ANET")
An aviation radio data link service provider's network, including An aviation radio data link service provider's network, including
radio transmitters and receivers as well as supporting ground- radio transmitters and receivers as well as supporting ground-
domain infrastructure needed to convey a customer's data packets domain infrastructure needed to convey a customer's data packets
to the outside world. The term RAN is intended in the same spirit to outside INETs. The term ANET is intended in the same spirit as
as for cellular operator networks and other radio-based Internet for radio-based Internet service provider networks (e.g., cellular
service provider networks. For simplicity, we also use the term operators), but can also refer to ground-domain networks that
RAN to refer to ground-domain networks that connect AOCs and ATCs connect AOCs and ATCs.
without any aviation radio communications.
Core Autonomous System Border Router (c-ASBR) A BGP router located partition (or "segment")
in the hub of the ATN/IPS hub-and-spokes overlay network topology. A fully-connected internal subnetwork of an INET in which all
nodes can communicate with all other nodes within the same
partition using the same IP protocol version and addressing plan.
Each INET consists of one or more partitions.
Core Autonomous System The "hub" autonomous system maintained by all Spanning Partitioned Aeronautical Networks (SPAN)
c-ASBRs. A virtual layer 2 bridging service that presents a unified link
view to the ATN/IPS overlay even though the underlay may consist
of multiple INET partitions. The SPAN is manifested through
nested encapsulation in which IPv6 packets from the ATN/IPS are
first encapsulated in SPAN headers which are then encapsulated in
INET headers. In this way, packets sent from a source can be
conveyed over the SPAN even though there may be many underlying
INET partitions in the path to the destination.
Stub Autonomous System Border Router (s-ASBR) A BGP router SPAN Autonomous System
configured as a spoke in the ATN/IPS hub-and-spokes overlay A "hub-of-hubs" autonomous system maintained through peerings
network topology. between the core autonomous systems of different SPAN partitions.
Stub Autonomous System A logical grouping that includes all Clients Core Autonomous System Border Router (c-ASBR)
currently associated with a given s-ASBR. A BGP router located in the hub of the INET partition hub-and-
spokes overlay network topology.
Client An ATC, AOC or aircraft that connects to the ATN/IPS as a Core Autonomous System
leaf node. The Client could be a singleton host, or a router that The "hub" autonomous system maintained by all c-ASBRs within the
connects a mobile network. same partition.
Proxy A node at the edge of a RAN that acts as a transparent Stub Autonomous System Border Router (s-ASBR)
intermediary between Clients and s-ASBRs. From the Client's A BGP router configured as a spoke in the INET partition hub-and-
perspective, the Proxy presents the appearance that the Client is spokes overlay network topology.
communicating directly with the s-ASBR. From the s-ASBR's
perspective, the Proxy presents the appearance that the s-ASBR is
communicating directly with the Client.
Mobile Network Prefix (MNP) An IPv6 prefix that is delegated to any Stub Autonomous System
ATN/IPS end system, including ATCs, AOCs, and aircraft. A logical grouping that includes all Clients currently associated
with a given s-ASBR.
Mobility Service Prefix (MSP) An aggregated prefix assigned to the Client
ATN/IPS by an Internet assigned numbers authority, and from which An ATC, AOC or aircraft that connects to the ATN/IPS as a leaf
all MNPs are delegated (e.g., up to 2**32 IPv6 /56 MNPs could be node. The Client could be a singleton host, or a router that
delegated from a /24 MSP). connects a mobile or fixed network.
Proxy
An ANET/INET border node that acts as a transparent intermediary
between Clients and s-ASBRs. From the Client's perspective, the
Proxy presents the appearance that the Client is communicating
directly with the s-ASBR. From the s-ASBR's perspective, the
Proxy presents the appearance that the s-ASBR is communicating
directly with the Client.
Mobile Network Prefix (MNP)
An IPv6 prefix that is delegated to any ATN/IPS end system,
including ATCs, AOCs, and aircraft.
Mobility Service Prefix (MSP)
An aggregated prefix assigned to the ATN/IPS by an Internet
assigned numbers authority, and from which all MNPs are delegated
(e.g., up to 2**32 IPv6 /56 MNPs could be delegated from a /24
MSP).
3. ATN/IPS Routing System 3. ATN/IPS Routing System
The proposed ATN/IPS routing system comprises a private BGP instance The ATN/IPS routing system comprises a private BGP instance
coordinated in an overlay network via tunnels between neighboring coordinated in an overlay network via tunnels between neighboring
ASBRs over the Internetworking underlay. The overlay does not ASBRs over one or more underlying INETs. The overlay does not
interact with the native BGP routing system in the connected interact with the underlying INET BGP routing systems, and only a
underlying Internetwork, and each c-ASBR advertises only a small and small and unchanging set of MSPs are advertised externally instead of
unchanging set of MSPs into the Internetworking underlay routing the full dynamically changing set of MNPs.
system instead of the full dynamically changing set of MNPs. (For
example, when the Internetworking underlay is the global public
Internet the c-ASBRs advertise the MSPs in the public BGP Internet
routing system.)
In a reference deployment, one or more s-ASBRs connect each stub AS Within each INET partition, one or more s-ASBRs connect each stub AS
to the overlay using a shared stub AS Number (ASN). Each s-ASBR to the INET partition core using a shared stub AS Number (ASN). Each
further uses eBGP to peer with one or more c-ASBRs. All c-ASBRs are s-ASBR further uses eBGP to peer with one or more c-ASBRs. All
members of the same core AS, and use a shared core ASN. Globally- c-ASBRs are members of the INET partition core AS, and use a shared
unique public ASNs could be assigned, e.g., either according to the core ASN. Globally-unique public ASNs could be assigned, e.g.,
standard 16-bit ASN format or the 32-bit ASN scheme defined in either according to the standard 16-bit ASN format or the 32-bit ASN
[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. Figure 1 below represents the all active MNPs currently in service within the INET partition.
reference deployment. (Note that the figure shows details for only Figure 1 below represents the reference INET partition deployment.
two s-ASBRs (s-ASBR1 and s-ASBR2) due to space constraints, but the (Note that the figure shows details for only two s-ASBRs (s-ASBR1 and
other s-ASBRs should be understood to have similar Stub AS, MNP and s-ASBR2) due to space constraints, but the other s-ASBRs should be
eBGP peering arrangements.) The solution described in this document understood to have similar Stub AS, MNP and eBGP peering
is flexible enough to extend to these topologies. arrangements.) The solution described in this document is flexible
enough to extend to these topologies.
........................................................... ...........................................................
. . . .
. (:::)-. <- Stub ASes -> (:::)-. . . (:::)-. <- Stub ASes -> (:::)-. .
. MNPs-> .-(:::::::::) .-(:::::::::) <-MNPs . . MNPs-> .-(:::::::::) .-(:::::::::) <-MNPs .
. `-(::::)-' `-(::::)-' . . `-(::::)-' `-(::::)-' .
. +-------+ +-------+ . . +-------+ +-------+ .
. |s-ASBR1+-----+ +-----+s-ASBR2| . . |s-ASBR1+-----+ +-----+s-ASBR2| .
. +--+----+ eBGP \ / eBGP +-----+-+ . . +--+----+ eBGP \ / eBGP +-----+-+ .
. \ \/ / . . \ \/ / .
skipping to change at page 7, line 48 skipping to change at page 8, line 36
. eBGP+-----+c-ASBR |...|c-ASBR +-----+eBGP . . eBGP+-----+c-ASBR |...|c-ASBR +-----+eBGP .
. +-------+ +-------+ . . +-------+ +-------+ .
. / \ . . / \ .
. /eBGP \eBGP . . /eBGP \eBGP .
. / \ . . / \ .
. +---+---+ +-----+-+ . . +---+---+ +-----+-+ .
. |s-ASBR | |s-ASBR | . . |s-ASBR | |s-ASBR | .
. +-------+ +-------+ . . +-------+ +-------+ .
. . . .
. . . .
. <------------ Internetworking Underlay --------------> . . <----------------- INET Partition -------------------> .
............................................................ ............................................................
Figure 1: 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- MNPs that currently belong to its stub AS. In response to "Inter-
domain" mobility events, each s-ASBR will dynamically announces new domain" mobility events, each s-ASBR will dynamically announces new
MNPs and withdraws departed MNPs in its eBGP updates to c-ASBRs. MNPs and withdraws departed MNPs in its eBGP updates to c-ASBRs.
Since ATN/IPS end systems are expected to remain within the same stub Since ATN/IPS end systems are expected to remain within the same stub
AS for extended timeframes, however, intra-domain mobility events AS for extended timeframes, however, intra-domain mobility events
(such as an aircraft handing off between cell towers) are handled (such as an aircraft handing off between cell towers) are handled
within the stub AS instead of being propagated as inter-domain eBGP within the stub AS instead of being propagated as inter-domain eBGP
updates. updates.
skipping to change at page 8, line 28 skipping to change at page 9, line 15
destined to all other MNPs will correctly incur ICMPv6 Destination destined to all other MNPs will correctly incur ICMPv6 Destination
Unreachable messages [RFC4443] due to the black hole route. (This is Unreachable messages [RFC4443] due to the black hole route. (This is
the same behavior as for ordinary BGP routers in the Internet when the same behavior as for ordinary BGP routers in the Internet when
they receive packets for which there is no route available.) The they receive packets for which there is no route available.) The
c-ASBRs do not send eBGP updates for MNPs to s-ASBRs, but instead c-ASBRs do not send eBGP updates for MNPs to s-ASBRs, but instead
originate a default route. In this way, s-ASBRs have only partial originate a default route. In this way, s-ASBRs have only partial
topology knowledge (i.e., they know only about the active MNPs topology knowledge (i.e., they know only about the active MNPs
currently within their stub ASes) and they forward all other packets currently within their stub ASes) and they forward all other packets
to c-ASBRs which have full topology knowledge. to c-ASBRs which have full topology knowledge.
The core ASes of each INET partition are joined together through
external BGP peerings. The c-ASBRs of each partition establish
external peerings with the c-ASBRs of other partitions to form a
"core-of-cores" SPAN AS. The SPAN AS contains the global knowledge
of all MNPs deployed worldwide, and supports ATN/IPS overlay
communications between nodes located in different INET partitions by
virtue of SPAN encapsulation. Figure 2 shows a reference SPAN
topology.
. . . . . . . . . . . . . . . . . . . . . . . . .
. .
. .-(::::::::) .
. .-(::::::::::::)-. +------+ .
. (::: Partition 1 ::)--|c-ASBR|---+ .
. `-(::::::::::::)-' +------+ | .
. `-(::::::)-' | .
. | .
. .-(::::::::) | .
. .-(::::::::::::)-. +------+ | .
. (::: Partition 2 ::)--|c-ASBR|---+ .
. `-(::::::::::::)-' +------+ | .
. `-(::::::)-' | .
. | .
. .-(::::::::) | .
. .-(::::::::::::)-. +------+ | .
. (::: Partition 3 ::)--|c-ASBR|---+ .
. `-(::::::::::::)-' +------+ | .
. `-(::::::)-' | .
. | .
. ..(etc).. x .
. .
. .
. <- ATN/IPS Overlay Bridged by the SPAN AS -> .
. . . . . . . . . . . . . .. . . . . . . . . . . .
Figure 2: The SPAN
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.
skipping to change at page 8, line 52 skipping to change at page 10, line 29
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
aggregate C::/32, etc. The union of all MSP segments would then aggregate C::/32, etc. The union of all MSP segments would then
constitute the collective MSP(s) for the entire ATN/IPS. constitute the collective MSP(s) for the entire ATN/IPS, with
potential for supporting many millions of mobile networks or more.
In this way, each set of c-ASBRs services a specific set of MSPs that In this way, each set of c-ASBRs services a specific set of MSPs, and
they inject into the Internetworking underlay native routing system, each s-ASBR configures MSP-specific routes that list the correct set
and each s-ASBR configures MSP-specific routes that list the correct of c-ASBRs as next hops. This design also allows for natural
set of c-ASBRs as next hops. This design also allows for natural
incremental deployment, and can support initial medium-scale incremental deployment, and can support initial medium-scale
deployments followed by dynamic deployment of additional ATN/IPS deployments followed by dynamic deployment of additional ATN/IPS
infrastructure elements without disturbing the already-deployed base. infrastructure elements without disturbing the already-deployed base.
For example, a few more c-ASBRs could be added if the MNP service For example, a few more c-ASBRs could be added if the MNP service
demand ever outgrows the initial deployment. For larger-scale demand ever outgrows the initial deployment. For larger-scale
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 (RAN) Model 4. ATN/IPS (Radio) Access Network (ANET) Model
Radio Access Networks (RANs) 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 RANs 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
may further move between RANs in a manner that is perceived as a may further move between ANETs in a manner that is perceived as a
network layer mobility event. Clients could therefore employ a network layer mobility event. Clients could therefore employ a
multilink/mobility routing service such as those discussed in multilink/mobility routing service such as those discussed in
Section 7. 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 edge of the RAN. s-ASBRs either directly, or via a Proxy at the ANET/INET boundary.
Figure 2 shows the ATN/IPS RAN model where Clients connect to RANs Figure 3 shows the ATN/IPS ANET model where Clients connect to ANETs
via aviation data links. Clients register their RAN addresses with a via aviation data links. Clients register their ANET addresses with
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 RAN. Proxy at the edge of the ANET.
Data Link "A" +--------+ Data Link "B" Data Link "A" +--------+ Data Link "B"
+----------- | Client |-----------+ +----------- | Client |-----------+
/ +--------+ \ / +--------+ \
/ \ / \
/ \ / \
(:::)-. (:::)-. (:::)-. (:::)-.
.-(:::::::::) <- Radio Access Networks -> .-(:::::::::) .-(:::::::::)<- (Radio) Access Networks ->.-(:::::::::)
`-(::::)-' `-(::::)-' `-(::::)-' `-(::::)-'
+-------+ +-------+ +-------+ +-------+
... | Proxy | ............................ | Proxy | ... ... | Proxy | ............................ | Proxy | ...
. +-------+ +-------+ . . +-------+ +-------+ .
. ^^ ^^ . . ^^ ^^ .
. || || . . || || .
. || +--------+ || . . || +--------+ || .
. ++============> | s-ASBR | <============++ . . ++============> | s-ASBR | <============++ .
. +--------+ . . +--------+ .
. | eBGP . . | eBGP .
. (:::)-. . . (:::)-. .
. .-(::::::::) . . .-(::::::::) .
. .-(::: ATN/IPS :::)-. . . .-(::: ATN/IPS :::)-. .
. (::::: BGP Routing ::::) . . (::::: BGP Routing ::::) .
. `-(:: System ::::)-' . . `-(:: System ::::)-' .
. `-(:::::::-' . . `-(:::::::-' .
. . . .
. . . .
. <------------- Internetworking Underlay -------------> . . <------- ATN/IPS Overlay bridged by the SPAN --------> .
............................................................ ............................................................
Figure 2: ATN/IPS RAN Architecture Figure 3: ATN/IPS ANET Architecture
When a Client logs into a RAN, 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, etc.) The login process is transparently file, through a DNS lookup, through a network query response, etc.)
brokered by a Proxy at the border of the RAN, which then conveys the The login process is transparently brokered by a Proxy at the border
connection request to the s-ASBR via tunneling across the of the ANET, which then conveys the connection request to the s-ASBR
Internetworking underlay. The s-ASBR then registers the address of via tunneling across the SPAN. The s-ASBR then registers the address
the Proxy as the address for the Client, and the Proxy forwards the of the Proxy as the address for the Client, and the Proxy forwards
s-ASBR's reply to the Client. If the Client connects to multiple the s-ASBR's reply to the Client. If the Client connects to multiple
RANs, the s-ASBR will register the addresses of all Proxies as ANETs, the s-ASBR will register the addresses of all Proxies as
addresses through which the Client can be reached. 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 routes in the
ATN/IPS BGP routing system. The s-ASBR's stub AS therefore consists 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 is a 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 injects logical construct and not a physical construct). The s-ASBR injects
the MNPs of its active Clients and withdraws the MNPs of its departed the MNPs of its active Clients and withdraws the MNPs of its departed
Clients via BGP updates to c-ASBRs. Since Clients are expected to Clients via BGP updates to c-ASBRs, which further propagate the MNPs
to other c-ASBRs within the SPAN AS. Since Clients are expected to
remain associated with their current s-ASBR for extended periods, the remain associated with their current s-ASBR for extended periods, the
level of MNP injections and withdrawals in the BGP routing system level of MNP injections and withdrawals in the BGP routing system
will be on the order of the numbers of network joins, leaves and will be on the order of the numbers of network joins, leaves and
s-ASBR handovers for aircraft operations (see: Section 6). It is s-ASBR handovers for aircraft operations (see: Section 6). It is
important to observe that fine-grained events such as Client mobility important to observe that fine-grained events such as Client mobility
and Quality of Service (QoS) signaling are coordinated only by and Quality of Service (QoS) signaling are coordinated only by
Proxies and the Client's current s-ASBRs, and do not involve other Proxies and the Client's current s-ASBRs, and do not involve other
ASBRs in the routing system. In this way, intradomain routing ASBRs in the routing system. In this way, intradomain routing
changes within the stub AS are not propagated into the rest of the changes within the stub AS are not propagated into the rest of the
ATN/IPS BGP routing system. ATN/IPS BGP routing system.
5. ATN/IPS Route Optimization 5. ATN/IPS Route Optimization
ATN/IPS end systems will frequently need to communicate with ATN/IPS end systems will frequently need to communicate with
correspondents associated with other s-ASBRs. In the BGP peering correspondents associated with other s-ASBRs. In the BGP peering
topology discussed in Section 3, this can initially only be topology discussed in Section 3, this can initially only be
accommodated by including multiple 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 Internetworking a minimum number of tunneling hops across the SPAN. ATN/IPS end
underlay. ATN/IPS end systems could therefore employ a route systems could therefore employ a route optimization service according
optimization service according to the mobility service employed (see: to the mobility service employed (see: Section 7).
Section 7).
A route optimization example is shown in Figure 3 and Figure 4 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-----+ +-----^---+
* * * *
* * * *
(:::)-. (:::)-. (:::)-. (:::)-.
.-(:::::::::) <- Radio Access Networks -> .-(:::::::::) .-(:::::::::)<- (Radio) Access Networks ->.-(:::::::::)
`-(::::)-' `-(::::)-' `-(::::)-' `-(::::)-'
+--------+ +--------+ +--------+ +--------+
... | Proxy1 | .......................... | Proxy2 | ... ... | Proxy1 | .......................... | Proxy2 | ...
. +--------+ +--------+ . . +--------+ +--------+ .
. ** ** . . ** ** .
. ** ** . . ** ** .
. ** ** . . ** ** .
. +---------+ +---------+ . . +---------+ +---------+ .
. | s-ASBR1 | | s-ASBR2 | . . | s-ASBR1 | | s-ASBR2 | .
. +--+------+ +-----+---+ . . +--+------+ +-----+---+ .
. \ ** Dogleg ** / . . \ ** Dogleg ** / .
. eBGP\ ** Route ** /eBGP . . eBGP\ ** Route ** /eBGP .
. \ **==============** / . . \ **==============** / .
. +---------+ +---------+ . . +---------+ +---------+ .
. | c-ASBR1 | | c-ASBR2 | . . | c-ASBR1 | | c-ASBR2 | .
. +---+-----+ +----+----+ . . +---+-----+ +----+----+ .
. +--------------+ . . +--------------+ .
. iBGP . . iBGP .
. . . .
. <------------- Internetworking Underlay -------------> . . <------- ATN/IPS Overlay bridged by the SPAN --------> .
............................................................ ............................................................
Figure 3: Dogleg Route Before Optimization Figure 4: Dogleg Route Before Optimization
+---------+ +---------+ +---------+ +---------+
| Client1 | | Client2 | | Client1 | | Client2 |
+---v-----+ +-----^---+ +---v-----+ +-----^---+
* * * *
* * * *
(:::)-. (:::)-. (:::)-. (:::)-.
.-(:::::::::) <- Radio Access Networks -> .-(:::::::::) .-(:::::::::) <- (Radio) Access Networks ->.-(:::::::::)
`-(::::)-' `-(::::)-' `-(::::)-' `-(::::)-'
+--------+ +--------+ +--------+ +--------+
... | Proxy1 | .......................... | Proxy2 | ... ... | Proxy1 | .......................... | Proxy2 | ...
. +------v-+ +--^-----+ . . +------v-+ +--^-----+ .
. * * . . * * .
. *================================* . . *================================* .
. . . .
. +---------+ +---------+ . . +---------+ +---------+ .
. | s-ASBR1 | | s-ASBR2 | . . | s-ASBR1 | | s-ASBR2 | .
. +--+------+ +-----+---+ . . +--+------+ +-----+---+ .
. \ / . . \ / .
. eBGP\ /eBGP . . eBGP\ /eBGP .
. \ / . . \ / .
. +---------+ +---------+ . . +---------+ +---------+ .
. | c-ASBR1 | | c-ASBR2 | . . | c-ASBR1 | | c-ASBR2 | .
. +---+-----+ +----+----+ . . +---+-----+ +----+----+ .
. +--------------+ . . +--------------+ .
. iBGP . . iBGP .
. . . .
. <------------- Internetworking Underlay -------------> . . <------- ATN/IPS Overlay bridged by the SPAN --------> .
............................................................ ............................................................
Figure 4: 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 the system. Network proportional to the number of s-ASBRs in its local partition.
emulations with lightweight virtual machines have shown that a single Network emulations with lightweight virtual machines have shown that
c-ASBR can service at least 100 eBGP peerings from s-ASBRs that each a single c-ASBR can service at least 100 eBGP peerings from s-ASBRs
advertise 10K MNP routes (i.e., 1M total). It is expected that that each advertise 10K MNP routes (i.e., 1M total). It is expected
robust c-ASBRs can service many more peerings than this - possibly by that robust c-ASBRs can service many more peerings than this -
multiple orders of magnitude. But even assuming a conservative possibly by multiple orders of magnitude. But even assuming a
limit, the number of s-ASBRs could be increased by also increasing conservative limit, the number of s-ASBRs could be increased by also
the number of c-ASBRs. Since c-ASBRs also peer with each other using increasing the number of c-ASBRs. Since c-ASBRs also peer with each
iBGP, however, larger-scale c-ASBR deployments may need to employ an other using iBGP, however, larger-scale c-ASBR deployments may need
adjunct facility such as BGP Route Reflectors (RRs)[RFC4456]. to employ an adjunct facility such as BGP Route Reflectors
(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
transitions per flight, the entire system will need to service at transitions per flight, the entire system will need to service at
most 10M BGP updates per hour (2778 updates per second). This number most 10M BGP updates per hour (2778 updates per second). This number
is within the realm of the peak BGP update messaging seen in the is within the realm of the peak BGP update messaging seen in the
global public Internet today [BGP2]. Assuming a BGP update message global public Internet today [BGP2]. Assuming a BGP update message
size of 100 bytes (800bits), the total amount of BGP control message size of 100 bytes (800bits), the total amount of BGP control message
skipping to change at page 14, line 24 skipping to change at page 15, line 25
conservative default values. For example, the default hold time is conservative default values. For example, the default hold time is
90 seconds, the default keepalive time is 1/3 of the hold time, and 90 seconds, the default keepalive time is 1/3 of the hold time, and
the default MinRouteAdvertisementinterval is 30 seconds for eBGP the default MinRouteAdvertisementinterval is 30 seconds for eBGP
peers and 5 seconds for iBGP peers (see Section 10 of [RFC4271]). peers and 5 seconds for iBGP peers (see Section 10 of [RFC4271]).
For the simple mobile routing system described herein, these For the simple mobile routing system described herein, these
parameters can and should be set to more aggressive values to support parameters can and should be set to more aggressive values to support
faster neighbor/link failure detection and faster routing protocol faster neighbor/link failure detection and faster routing protocol
convergence times. For example, a hold time of 3 seconds and a convergence times. For example, a hold time of 3 seconds and a
MinRouteAdvertisementinterval of 0 seconds for both iBGP and eBGP. MinRouteAdvertisementinterval of 0 seconds for both iBGP and eBGP.
Each c-ASBR will be using eBGP both in the ATN/IPS and the Each c-ASBR will be using eBGP both in the ATN/IPS and the INET with
Internetworking Underlay with the ATN/IPS unicast IPv6 routes the ATN/IPS unicast IPv6 routes resolving over INET routes.
resolving over Internetworking Underlay routes. Consequently, Consequently, c-ASBRs and potentially s-ASBRs will need to support
c-ASBRs and potentially s-ASBRs will need to support separate local separate local ASes for the two BGP routing domains and routing
ASes for the two BGP routing domains and routing policy or assure policy or assure routes are not propagated between the two BGP
routes are not propagated between the two BGP routing domains. From routing domains. From a conceptual and operational standpoint, the
a conceptual and operational standpoint, the implementation should implementation should provide isolation between the two BGP routing
provide isolation between the two BGP routing domains (e.g., separate domains (e.g., separate BGP instances).
BGP instances).
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-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
skipping to change at page 15, line 27 skipping to change at page 16, line 27
(DDoS) attacks. This concern is no different than for any node on (DDoS) attacks. This concern is no different than for any node on
the open Internet, where attackers could send spoofed packets to the the open Internet, where attackers could send spoofed packets to the
node at high data rates. This can be mitigated by connecting ATN/IPS node at high data rates. This can be mitigated by connecting ATN/IPS
ASBRs over dedicated links with no connections to the Internet and/or ASBRs over dedicated links with no connections to the Internet and/or
when ASBR connections to the Internet are only permitted through when ASBR connections to the Internet are only permitted through
well-managed firewalls. well-managed firewalls.
ATN/IPS s-ASBRs should institute rate limits to protect low data rate ATN/IPS s-ASBRs should institute rate limits to protect low data rate
aviation data links from receiving DDoS packet floods. aviation data links from receiving DDoS packet floods.
BGP protocol message exchanges and control message exchanges used for
route optimization must be secured to ensure the integrity of the
system-wide routing information base.
This document does not include any new specific requirements for This document does not include any new specific requirements for
mitigation of DDoS. mitigation of DDoS.
11. Acknowledgements 11. Acknowledgements
This work is aligned with the FAA as per the SE2025 contract number This work is aligned with the FAA as per the SE2025 contract number
DTFAWA-15-D-00030. DTFAWA-15-D-00030.
This work is aligned with the NASA Safe Autonomous Systems Operation This work is aligned with the NASA Safe Autonomous Systems Operation
(SASO) program under NASA contract number NNA16BD84C. (SASO) program under NASA contract number NNA16BD84C.
This work is aligned with the Boeing Information Technology (BIT) This work is aligned with the Boeing Information Technology (BIT)
MobileNet program. MobileNet program.
The following individuals contributed insights that have improved the The following individuals contributed insights that have improved the
document: Erik Kline, Tony Li, Alexandre Petrescu, Pascal Thubert. document: Erik Kline, Hubert Kuenig, Tony Li, Alexandre Petrescu,
Pascal Thubert, Tony Whyman.
12. References 12. References
12.1. Normative References 12.1. Normative References
[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>.
skipping to change at page 16, line 42 skipping to change at page 17, line 51
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-26 (work in progress), (LISP)", draft-ietf-lisp-rfc6830bis-26 (work in progress),
November 2018. November 2018.
[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-03 (work in (AERO)", draft-templin-intarea-6706bis-12 (work in
progress), December 2018. progress), May 2019.
[ICAO] ICAO, I., "http://www.icao.int/Pages/default.aspx", [ICAO] ICAO, I., "http://www.icao.int/Pages/default.aspx",
February 2017. 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
skipping to change at page 17, line 23 skipping to change at page 18, line 31
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
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. Change Log Appendix A. BGP Convergence Considerations
Experimental evidence has shown that BGP convergence time required
for when an MNP is asserted at a new location or withdrawn from an
old location can be several hundred milliseconds even under optimal
AS peering arrangements. This means that packets in flight destined
to an MNP route that has recently been changed can be (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
for a "departed" Client that includes a SPAN address for the new
s-ASBR. The SPAN address never changes since ASBRs are fixed
infrastructure elements that never move. Hence, packets arriving at
the old s-ASBR can be forwarded to the new s-ASBR while the BGP
routing system is still undergoing reconvergence. Therefore, as long
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)
packets in flight during the BGP reconvergence window are
accommodated without loss.
Appendix B. Change Log
<< RFC Editor - remove prior to publication >> << RFC Editor - remove prior to publication >>
Changes from -01 to -02:
o introduced the SPAN and the concept of Internetwork partitioning
o new terms "ANET" (for (Radio) Access Network) and "INET" (for
Internetworking underlay)
o new appendix on BGP convergence considerations
Changes from -00 to -01: Changes from -00 to -01:
o incorporated clarifications due to list comments and questions. o incorporated clarifications due to list comments and questions.
o new section 7 on Stub AS Mobile Routing Services o new section 7 on Stub AS Mobile Routing Services
o updated references, and included new reference for MIPv6 and LISP o updated references, and included new reference for MIPv6 and LISP
Status as of 08/30/2018: Status as of 08/30/2018:
 End of changes. 58 change blocks. 
170 lines changed or deleted 279 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/