< draft-ietf-rtgwg-atn-bgp-05.txt   draft-ietf-rtgwg-atn-bgp-06.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 4, 2020 G. Dawra Expires: January 1, 2021 G. Dawra
LinkedIn LinkedIn
A. Lindem A. Lindem
V. Moreno V. Moreno
Cisco Systems, Inc. Cisco Systems, Inc.
January 01, 2020 June 30, 2020
A Simple BGP-based Mobile Routing System for the Aeronautical A Simple BGP-based Mobile Routing System for the Aeronautical
Telecommunications Network Telecommunications Network
draft-ietf-rtgwg-atn-bgp-05 draft-ietf-rtgwg-atn-bgp-06
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 4, 2020. This Internet-Draft will expire on January 1, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. ATN/IPS Routing System . . . . . . . . . . . . . . . . . . . 7 3. ATN/IPS Routing System . . . . . . . . . . . . . . . . . . . 7
4. ATN/IPS (Radio) Access Network (ANET) Model . . . . . . . . . 10 4. ATN/IPS (Radio) Access Network (ANET) Model . . . . . . . . . 11
5. ATN/IPS Route Optimization . . . . . . . . . . . . . . . . . 12 5. ATN/IPS Route Optimization . . . . . . . . . . . . . . . . . 13
6. BGP Protocol Considerations . . . . . . . . . . . . . . . . . 14 6. BGP Protocol Considerations . . . . . . . . . . . . . . . . . 15
7. Stub AS Mobile Routing Services . . . . . . . . . . . . . . . 15 7. Stub AS Mobile Routing Services . . . . . . . . . . . . . . . 16
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
12.1. Normative References . . . . . . . . . . . . . . . . . . 17 12.1. Normative References . . . . . . . . . . . . . . . . . . 18
12.2. Informative References . . . . . . . . . . . . . . . . . 17 12.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. BGP Convergence Considerations . . . . . . . . . . . 18 Appendix A. BGP Convergence Considerations . . . . . . . . . . . 19
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 19 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The worldwide Air Traffic Management (ATM) system today uses a The worldwide Air Traffic Management (ATM) system today uses a
service known as Aeronautical Telecommunications Network based on service known as Aeronautical Telecommunications Network based on
Open Systems Interconnection (ATN/OSI). The service is used to Open Systems Interconnection (ATN/OSI). The service is used to
augment controller to pilot voice communications with rudimentary augment controller to pilot voice communications with rudimentary
short text command and control messages. The service has seen short text command and control messages. The service has seen
successful deployment in a limited set of worldwide ATM domains. successful deployment in a limited set of worldwide ATM domains.
skipping to change at page 3, line 39 skipping to change at page 3, line 39
partition can exchange packets with all other nodes, i.e., the partition can exchange packets with all other nodes, i.e., the
partition is connected internally. There is no requirement that any partition is connected internally. There is no requirement that any
two INET partitions use the same IP protocol version nor have two INET partitions use the same IP protocol version nor have
consistent IP addressing plans in comparison with other partitions. consistent IP addressing plans in comparison with other partitions.
Instead, the ATN/IPS IPv6 overlay sees each partition as a "segment" Instead, the ATN/IPS IPv6 overlay sees each partition as a "segment"
of a link-layer topology manifested through a (virtual) bridging of a link-layer topology manifested through a (virtual) bridging
service known as "Spanning Partitioned Aeronautical Networks (SPAN)". service known as "Spanning Partitioned Aeronautical Networks (SPAN)".
Further discussion of the SPAN is found in the following sections of Further discussion of the SPAN is found in the following sections of
this document, with reference to [I-D.templin-intarea-6706bis]. this document, with reference to [I-D.templin-intarea-6706bis].
Each aircraft connects to the ATN/IPS overlay via an Overlay
Multilink Network (OMNI) Interface [I-D.templin-6man-omni-interface]
configured over the aircraft's underlying physical and/or virtual
access network interfaces. The OMNI interface connects to a Non-
Broadcast, Multiple Access (NBMA) virtual link that spans the entire
ATN/IPS.
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
aircraft. We also use the term Mobility Service Prefix (MSP) to aircraft. We also use the term Mobility Service Prefix (MSP) to
skipping to change at page 10, line 49 skipping to change at page 11, line 28
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 (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
may further move between ANETs in a manner that is perceived as a configure an Overlay Multilink Network (OMNI) Interface
network layer mobility event. Clients could therefore employ a [I-D.templin-6man-omni-interface] over their underlying ANET
multilink/mobility routing service such as those discussed in interfaces as a connection to an NBMA virtual link that spans the
Section 7. entire ATN/IPS. Clients may further move between ANETs in a manner
that is perceived as a network layer mobility event. Clients could
therefore employ a multilink/mobility routing service such as those
discussed in Section 7.
Clients register all of their active data link connections with their Clients register all of their active data link connections with their
serving s-ASBRs as discussed in Section 3. Clients may connect to serving s-ASBRs as discussed in Section 3. Clients may connect to
s-ASBRs either directly, or via a Proxy at the ANET/INET boundary. s-ASBRs either directly, or via a Proxy at the ANET/INET boundary.
Figure 3 shows the ATN/IPS ANET model where Clients connect to ANETs Figure 3 shows the ATN/IPS ANET model where Clients connect to ANETs
via aviation data links. Clients register their ANET addresses with via aviation data links. Clients register their ANET addresses with
a nearby s-ASBR, where the registration process may be brokered by a a nearby s-ASBR, where the registration process may be brokered by a
Proxy at the edge of the ANET. Proxy at the edge of the ANET.
Data Link "A" +--------+ Data Link "B" +-----------------+
+----------- | Client |-----------+ | Client |
/ +--------+ \ Data Link "A" +-----------------+ Data Link "B"
+----- | OMNI Interface |--------+
/ +-----------------+ \
/ \ / \
/ \ / \
(:::)-. (:::)-. (:::)-. (:::)-.
.-(:::::::::)<- (Radio) Access Networks ->.-(:::::::::) .-(:::::::::)<- (Radio) Access Networks ->.-(:::::::::)
`-(::::)-' `-(::::)-' `-(::::)-' `-(::::)-'
+-------+ +-------+ +-------+ +-------+
... | Proxy | ............................ | Proxy | ... ... | Proxy | ............................ | Proxy | ...
. +-------+ +-------+ . . +-------+ +-------+ .
. ^^ ^^ . . ^^ ^^ .
. || || . . || || .
skipping to change at page 11, line 44 skipping to change at page 12, line 37
. (::::: BGP Routing ::::) . . (::::: BGP Routing ::::) .
. `-(:: System ::::)-' . . `-(:: System ::::)-' .
. `-(:::::::-' . . `-(:::::::-' .
. . . .
. . . .
. <------- ATN/IPS Overlay bridged by the SPAN --------> . . <------- ATN/IPS Overlay bridged by the SPAN --------> .
............................................................ ............................................................
Figure 3: ATN/IPS ANET Architecture Figure 3: ATN/IPS ANET Architecture
The Client uses an Air-to-Ground (A/G) interface to log into
individual ANETs. The A/G interface specification for the ATN/IPS is
under development in an ancillary document
[I-D.templin-atn-aero-interface].
When a Client logs into an ANET it specifies a nearby s-ASBR that it When a Client logs into an ANET it specifies a nearby s-ASBR that it
has selected to connect to the ATN/IPS. (Selection of a nearby has selected to connect to the ATN/IPS. (Selection of a nearby
s-ASBR could be through consulting a geographically-keyed static host s-ASBR could be through consulting a geographically-keyed static host
file, through a DNS lookup, through a network query response, etc.) file, through a DNS lookup, through a network query response, etc.)
The login process is transparently brokered by a Proxy at the border The login process is transparently brokered by a Proxy at the border
of the ANET, which then conveys the connection request to the s-ASBR of the ANET, which then conveys the connection request to the s-ASBR
via tunneling across the SPAN. The s-ASBR then registers the address via tunneling across the SPAN. The s-ASBR then registers the address
of the Proxy as the address for the Client, and the Proxy forwards 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 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 ANETs, the s-ASBR will register the addresses of all Proxies as
skipping to change at page 18, line 8 skipping to change at page 19, line 8
http://bgpupdates.potaroo.net/instability/bgpupd.html", http://bgpupdates.potaroo.net/instability/bgpupd.html",
May 2017. May 2017.
[CBB] Dul, A., "Global IP Network Mobility using Border Gateway [CBB] Dul, A., "Global IP Network Mobility using Border Gateway
Protocol (BGP), http://www.quark.net/docs/ Protocol (BGP), http://www.quark.net/docs/
Global_IP_Network_Mobility_using_BGP.pdf", March 2006. Global_IP_Network_Mobility_using_BGP.pdf", March 2006.
[I-D.ietf-lisp-rfc6830bis] [I-D.ietf-lisp-rfc6830bis]
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos-Aparicio, "The Locator/ID Separation Protocol Cabellos-Aparicio, "The Locator/ID Separation Protocol
(LISP)", draft-ietf-lisp-rfc6830bis-28 (work in progress), (LISP)", draft-ietf-lisp-rfc6830bis-32 (work in progress),
November 2019. March 2020.
[I-D.templin-atn-aero-interface] [I-D.templin-6man-omni-interface]
Templin, F. and T. Whyman, "Transmission of IPv6 Packets Templin, F. and T. Whyman, "Transmission of IPv6 Packets
over Aeronautical ("aero") Interfaces", draft-templin-atn- over Overlay Multilink Network (OMNI) Interfaces", draft-
aero-interface-08 (work in progress), December 2019. templin-6man-omni-interface-26 (work in progress), June
2020.
[I-D.templin-intarea-6706bis] [I-D.templin-intarea-6706bis]
Templin, F., "Asymmetric Extended Route Optimization Templin, F., "Asymmetric Extended Route Optimization
(AERO)", draft-templin-intarea-6706bis-17 (work in (AERO)", draft-templin-intarea-6706bis-58 (work in
progress), August 2019. progress), June 2020.
[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 19, line 22 skipping to change at page 20, line 23
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 -05 to -06:
o OMNI interface introduced
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.
Changes from -03 to -04: Changes from -03 to -04:
o added discussion of Bidirectional Forwarding Detection (BFD). o added discussion of Bidirectional Forwarding Detection (BFD).
Changes from -02 to -03: Changes from -02 to -03:
 End of changes. 14 change blocks. 
37 lines changed or deleted 51 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/