< draft-templin-atn-bgp-07.txt   draft-templin-atn-bgp-08.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: December 2, 2018 G. Dawra Expires: February 17, 2019 G. Dawra
LinkedIn LinkedIn
A. Lindem A. Lindem
V. Moreno
Cisco Systems, Inc. Cisco Systems, Inc.
May 31, 2018 August 16, 2018
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-templin-atn-bgp-07.txt draft-templin-atn-bgp-08.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 44 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 December 2, 2018. This Internet-Draft will expire on February 17, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 35 skipping to change at page 2, line 35
4. ATN/IPS Radio Access Network (RAN) Model . . . . . . . . . . 9 4. ATN/IPS Radio Access Network (RAN) Model . . . . . . . . . . 9
5. ATN/IPS Route Optimization . . . . . . . . . . . . . . . . . 11 5. ATN/IPS Route Optimization . . . . . . . . . . . . . . . . . 11
6. BGP Protocol Considerations . . . . . . . . . . . . . . . . . 13 6. BGP Protocol Considerations . . . . . . . . . . . . . . . . . 13
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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 rudimenatary augment controller to pilot voice communications with rudimentary
short text command and control messages. The service has seen short text command and control messages. The service has seen
successful deployment in a limited set of worldwide ATM domains. successful deployment in a limited set of worldwide ATM domains.
The International Civil Aviation Organization [ICAO] is now The International Civil Aviation Organization [ICAO] is now
undertaking the development of a next-generation replacement for ATN/ undertaking the development of a next-generation replacement for ATN/
OSI known as Aeronautical Telecommunications Network with Internet OSI known as Aeronautical Telecommunications Network with Internet
Protocol Services (ATN/IPS). ATN/IPS will eventually provide an Protocol Services (ATN/IPS). ATN/IPS will eventually provide an
IPv6-based [RFC8200] service supporting pervasive ATM for Air Traffic IPv6-based [RFC8200] service supporting pervasive ATM for Air Traffic
Controllers (ATC), Airline Operations Controllers (AOC), and all Controllers (ATC), Airline Operations Controllers (AOC), and all
commercial aircraft worldwide. As part of the ATN/IPS undertaking, a commercial aircraft worldwide. As part of the ATN/IPS undertaking, a
skipping to change at page 3, line 25 skipping to change at page 3, line 26
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 that assumes a worldwide
connected Internetworking underlay for carrying tunneled ATM connected Internetworking underlay for carrying tunneled ATM
communications. The Internetworking underlay could be manifested as communications. The Internetworking underlay could be manifested as
a private collection of long-haul backbone links (e.g., fiberoptics, a private collection of long-haul backbone links (e.g., fiber optics,
copper, SATCOM, etc.) interconnected by high-performance networking copper, SATCOM, etc.) interconnected by high-performance networking
gear such as bridges, switches, and routers. Such a private network gear such as bridges, switches, and routers. Such a private network
would need to connect all ATN/IPS participants worldwide, and could would need to connect all ATN/IPS participants worldwide, and could
therefore present a considerable cost for a large-scale deployment of therefore present a considerable cost for a large-scale deployment of
new infrastructure. Alternatively, the ATN/IPS could be deployed as new infrastructure. Alternatively, the ATN/IPS could be deployed as
a secured overlay over the existing global public Internet. For a secured overlay over the existing global public Internet. For
example, ATN/IPS nodes could be deployed as part of an SD-WAN or an example, ATN/IPS nodes could be deployed as part of an SD-WAN or an
MPLS-WAN that rides over the public Internet via secured tunnels. MPLS-WAN that rides over the public Internet via secured tunnels.
Further details of the Internetworking underlay design are out of
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. ATCs and AOCs will likewise receive IPv6 prefixes, but they travels. ICAO is further proposing to assign each aircraft an entire
would typically appear in static (not mobile) deployments such as air /56 MNP for numbering its on-board networks. ATCs and AOCs will
traffic control towers, airline headquarters, etc. Throughout the likewise receive IPv6 prefixes, but they would typically appear in
rest of this document, we therefore use the term "MNP" when static (not mobile) deployments such as air traffic control towers,
discussing an IPv6 prefix that is delegated to any ATN/IPS end airline headquarters, etc. Throughout the rest of this document, we
system, including ATCs, AOCs, and aircraft. We also use the term therefore use the term "MNP" when discussing an IPv6 prefix that is
Mobility Service Prefix (MSP) to refer to an aggregated prefix delegated to any ATN/IPS end system, including ATCs, AOCs, and
assigned to the ATN/IPS by an Internet assigned numbers authority, aircraft. We also use the term Mobility Service Prefix (MSP) to
and from which all MNPs are delegated (e.g., up to 2**32 IPv6 /64 refer to an aggregated prefix assigned to the ATN/IPS by an Internet
MNPs could be delegated from the MSP 2001:db8::/32). assigned numbers authority, and from which all MNPs are delegated
(e.g., up to 2**32 IPv6 /56 MNPs could be delegated from an IPv6 /24
MSP).
Connexion By Boeing [CBB] was an early aviation mobile routing Connexion By Boeing [CBB] was an early aviation mobile routing
service based on dynamic updates in the global public Internet BGP service based on dynamic updates in the global public Internet BGP
routing system. Practical experience with the approach has shown routing system. Practical experience with the approach has shown
that frequent injections and withdrawals of MNPs in the Internet that frequent injections and withdrawals of MNPs 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 27 skipping to change at page 4, line 32
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 system in the connected Internetworking underlay, and BGP updates are
unidirectional from "stub" ASBRs (s-ASBRs) to a small set of "core" 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 ASBRs (c-ASBRs) in a hub-and-spokes topology. No extensions to the
BGP protocol are necessary. BGP protocol are 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 Internetworking
underlay using industry-standard encapsulations (e.g., Generic underlay using industry-standard encapsulations (e.g., Generic
Routing Encapsulation (GRE) [RFC2784], IPsec [RFC4301], etc.). In Routing Encapsulation (GRE) [RFC2784], IPsec [RFC4301], etc.). In
particular, tunneling must be used when neighboringing ASBRs are particular, tunneling must be used when neighboring ASBRs are
separated by many Internetworking underlay hops. separated by many Internetworking underlay 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.
skipping to change at page 5, line 12 skipping to change at page 5, line 15
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:
Air Traffic Managemnet (ATM) Air Traffic Management (ATM)
The worldwide service for coordinating safe aviation operations. The worldwide service for coordinating safe aviation operations.
Air Traffic Controller (ATC) Air Traffic Controller (ATC)
A government agent responsible for coordinating with aircraft A government agent responsible for coordinating with aircraft
within a defined operational region via voice and/or data Command within a defined operational region via voice and/or data Command
and Control messaging. and Control messaging.
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.
skipping to change at page 5, line 37 skipping to change at page 5, line 40
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 an Internetworking underlay.
Internetworking underlay A connected wide-area network that supports Internetworking underlay A connected wide-area network that supports
overlay network tunneling and connects Radio Access Networks to overlay network tunneling and connects Radio Access Networks to
the rest of the ATN/IPS. the rest of the ATN/IPS.
Radio Access Network (RAN) Radio Access Network (RAN)
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 suppporting 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 the outside world. The term RAN is intended in the same spirit
as for cellular operator networks and other radio-based Internet as for cellular operator networks and other radio-based Internet
service provider networks. For simplicity, we also use the term service provider networks. For simplicity, we also use the term
RAN to refer to ground-domain networks that connect AOCs and ATCs RAN to refer to ground-domain networks that connect AOCs and ATCs
without any aviation radio communications. without any aviation radio communications.
Core Autonomous System Border Router (c-ASBR) A BGP router located Core Autonomous System Border Router (c-ASBR) A BGP router located
in the hub of the ATN/IPS hub-and-spokes overlay network topology. in the hub of the ATN/IPS hub-and-spokes overlay network topology.
skipping to change at page 6, line 28 skipping to change at page 6, line 28
Proxy presents the appearance that the Client is communicating Proxy presents the appearance that the Client is communicating
directly with the s-ASBR. From the s-ASBR's perspective, the directly with the s-ASBR. From the s-ASBR's perspective, the
Proxy presents the appearance that the s-ASBR is communicating Proxy presents the appearance that the s-ASBR is communicating
directly with the Client. directly with the Client.
Mobile Network Prefix (MNP) An IPv6 prefix that is delegated to any Mobile Network Prefix (MNP) An IPv6 prefix that is delegated to any
ATN/IPS end system, including ATCs, AOCs, and aircraft. ATN/IPS end system, including ATCs, AOCs, and aircraft.
Mobility Service Prefix (MSP) An aggregated prefix assigned to the Mobility Service Prefix (MSP) An aggregated prefix assigned to the
ATN/IPS by an Internet assigned numbers authority, and from which ATN/IPS by an Internet assigned numbers authority, and from which
all MNPs are delegated (e.g., up to 2**32 IPv6 /64 MNPs could be all MNPs are delegated (e.g., up to 2**32 IPv6 /56 MNPs could be
delegated from the MSP 2001:db8::/32). 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 proposed 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 the Internetworking underlay. The overlay does not
interact with the native BGP routing system in the connected interact with the native BGP routing system in the connected
undelying Internetwork, and each c-ASBR advertises only a small and underlying Internetwork, and each c-ASBR advertises only a small and
unchanging set of MSPs into the Internetworking underlay routing unchanging set of MSPs into the Internetworking underlay routing
system instead of the full dynamically changing set of MNPs. (For system instead of the full dynamically changing set of MNPs. (For
example, when the Internetworking underlay is the global public example, when the Internetworking underlay is the global public
Internet the c-ASBRs advertise the MSPs in the public BGP Internet Internet the c-ASBRs advertise the MSPs in the public BGP Internet
routing system.) routing system.)
In a reference deployment, one or more s-ASBRs connect each stub AS In a reference deployment, one or more s-ASBRs connect each stub AS
to the overlay using a shared stub AS Number (ASN). Each s-ASBR to the overlay using a shared stub AS Number (ASN). Each s-ASBR
further uses eBGP to peer with one or more c-ASBRs. All c-ASBRs are further uses eBGP to peer with one or more c-ASBRs. All c-ASBRs are
members of the same core AS, and use a shared core ASN. Since the members of the same core AS, and use a shared core ASN. Globally-
private BGP instance is separate from the global public Internet BGP unique public ASNs could be assigned, e.g., either according to the
routing system, the ASBRs can use either a private ASN per [RFC6996] standard 16-bit ASN format or the 32-bit ASN scheme defined in
or simply use public ASNs noting that the ASNs may overlap with those [RFC6793].
already assigned in the Internet. (A third alternative would be to
procure globally-unique public ASNs, but cost and maintenance
requirements must be conisdered.)
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. Figure 1 below represents the
reference deployment. (Note that the figure shows details for only reference deployment. (Note that the figure shows details for only
two s-ASBRs (s-ASBR1 and s-ASBR2) due to space constraints, but the two s-ASBRs (s-ASBR1 and s-ASBR2) due to space constraints, but the
other s-ASBRs should be understood to have similar Stub AS, MNP and other s-ASBRs should be understood to have similar Stub AS, MNP and
eBGP peering arrangements.) The solution described in this document eBGP peering arrangements.) The solution described in this document
is flexible enough to extend to these topologies. is flexible enough to extend to these topologies.
........................................................... ...........................................................
skipping to change at page 8, line 40 skipping to change at page 8, line 36
study showed that BGP routers in the global public Internet at that study showed that BGP routers in the global public Internet at that
time carried more than 500K routes with linear growth and no signs of time carried more than 500K routes with linear growth and no signs of
router resource exhaustion [BGP]. A more recent network emulation router resource exhaustion [BGP]. A more recent network emulation
study also showed that a single c-ASBR can accommodate at least 1M study also showed that a single c-ASBR can accommodate at least 1M
dynamically changing BGP routes even on a lightweight virtual dynamically changing BGP routes even on a lightweight virtual
machine. Commercially-available high-performance dedicated router machine. Commercially-available high-performance dedicated router
hardware can support many millions of routes. hardware can support many millions of routes.
Therefore, assuming each c-ASBR can carry 1M or more routes, this Therefore, assuming each c-ASBR can carry 1M or more routes, this
means that at least 1M ATN/IPS end system MNPs can be serviced by a means that at least 1M ATN/IPS end system MNPs can be serviced by a
single set of c-ASBRs and that number could be furhter increased by single set of c-ASBRs and that number could be further increased by
using RRs. Another means of increasing scale would be to assign a using RRs and/or more powerful routers. Another means of increasing
different set of c-ASBRs for each set of MSPs. In that case, each scale would be to assign a different set of c-ASBRs for each set of
s-ASBR still peers with one or more c-ASBRs from each set of c-ASBRs, MSPs. In that case, each s-ASBR still peers with one or more c-ASBRs
but the s-ASBR institutes route filters so that it only sends BGP from each set of c-ASBRs, but the s-ASBR institutes route filters so
updates to the specific set of c-ASBRs that aggregate the MSP. For that it only sends BGP updates to the specific set of c-ASBRs that
example, if the MSP for the ATN/IPS deployment is 2001:db8::/32, a aggregate the MSP. In this way, each set of c-ASBRs maintains
first set of c-ASBRs could service the MSP segment 2001:db8::/40, a separate routing and forwarding tables so that scaling is distributed
second set could service 2001:db8:0100::/40, a third set could across multiple c-ASBR sets instead of concentrated in a single
service 2001:db8:0200::/40, etc. 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
aggregate C::/32, etc. The union of all MSP segments would then
constitute the collective MSP(s) for the entire ATN/IPS.
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 that
they inject into the Internetworking underlay native routing system, they inject into the Internetworking underlay native routing system,
and each s-ASBR configures MSP-specific routes that list the correct and each s-ASBR configures MSP-specific routes that list the correct
set of c-ASBRs as next hops. This BGP routing design also allows for set of c-ASBRs as next hops. This design also allows for natural
natural incremental deployment, and can support initial small-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
demand ever outgrows the initial deployment.
4. ATN/IPS Radio Access Network (RAN) Model 4. ATN/IPS Radio Access Network (RAN) Model
Radio Access Networks (RANs) connect end system Clients such as Radio Access Networks (RANs) 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 RANs 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 RANs 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 that discussed in multilink/mobility routing service such as that discussed in
skipping to change at page 11, line 28 skipping to change at page 11, line 28
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 Internetworking
underlay. ATN/IPS end systems could therefore employ a route underlay. ATN/IPS end systems could therefore employ a route
optimization service such as that discussed in optimization service such as that discussed in
[I-D.templin-aerolink]. [I-D.templin-aerolink].
A route optimization example is shown in Figure 3 and Figure 4 below. A route optimization example is shown in Figure 3 and Figure 4 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 associted 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 -> .-(:::::::::)
skipping to change at page 16, line 45 skipping to change at page 16, line 45
[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>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July Autonomous System (AS) Number Space", RFC 6793,
2013, <https://www.rfc-editor.org/info/rfc6996>. DOI 10.17487/RFC6793, December 2012,
<https://www.rfc-editor.org/info/rfc6793>.
Appendix A. Change Log
<< RFC Editor - remove prior to publication >>
Changes from -07 to -08:
o Removed suggestion to use private ASNs
o Ran spelling checker and corrected errors
o Re-worked Section 3 final two paragraphs on scaling
o Stated Internetwork underlay as being out of scope for this
document
Authors' Addresses Authors' Addresses
Fred L. Templin (editor) Fred L. Templin (editor)
Boeing Research & Technology Boeing Research & Technology
P.O. Box 3707 P.O. Box 3707
Seattle, WA 98124 Seattle, WA 98124
USA USA
Email: fltemplin@acm.org Email: fltemplin@acm.org
skipping to change at line 724 skipping to change at page 18, line 4
LinkedIn LinkedIn
USA USA
Email: gdawra.ietf@gmail.com Email: gdawra.ietf@gmail.com
Acee Lindem Acee Lindem
Cisco Systems, Inc. Cisco Systems, Inc.
USA USA
Email: acee@cisco.com Email: acee@cisco.com
Victor Moreno
Cisco Systems, Inc.
USA
Email: vimoreno@cisco.com
 End of changes. 22 change blocks. 
45 lines changed or deleted 69 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/