Internet DRAFT - draft-haindl-ground-lisp-atn
draft-haindl-ground-lisp-atn
LISP Working Group B. Haindl
Internet-Draft M. Lindner
Intended status: Informational Frequentis
Expires: April 30, 2018 R. Rahman
M. Portoles
V. Moreno
F. Maino
Cisco Systems
October 27, 2017
Ground-Based LISP for the Aeronautical Telecommunications Network
draft-haindl-ground-lisp-atn-01
Abstract
This document describes the use of the LISP architecture and
protocols to address the requirements of the worldwide Aeronautical
Telecommunications Network with Internet Protocol Services, as
articulated by the International Civil Aviation Organization.
The ground-based LISP overlay provides mobility and multi-homing
services to the IPv6 networks hosted on commercial aircrafts, to
support Air Traffic Management communications with Air Traffic
Controllers and Air Operation Controllers. The proposed architecture
doesn't require support for LISP protocol in the airborne routers,
and can be easily deployed over existing ground infrastructures.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Haindl, et al. Expires April 30, 2018 [Page 1]
Internet-Draft draft-haindl-ground-lisp-atn October 2017
This Internet-Draft will expire on April 30, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 3
4. Basic Protocol Operation . . . . . . . . . . . . . . . . . . 7
4.1. Endsystem Registration . . . . . . . . . . . . . . . . . 7
4.2. Ground to Airborne Traffic Flow . . . . . . . . . . . . . 8
4.3. Airborne to Ground Traffic Flow . . . . . . . . . . . . . 8
4.4. Default forwarding path . . . . . . . . . . . . . . . . . 9
4.5. Traffic symmetry . . . . . . . . . . . . . . . . . . . . 9
5. Multi-Homing and Mobility . . . . . . . . . . . . . . . . . . 9
6. Convergence . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Use of RLOC-probing . . . . . . . . . . . . . . . . . . . 11
6.2. Use of Solicit-Map-Request . . . . . . . . . . . . . . . 11
6.3. Use of LISP pub-sub . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
This document describes the use of the LISP [RFC6830] architecture
and protocols to address the requirements of the worldwide
Aeronautical Telecommunications Network with Internet Protocol
Services (ATN/IPS), as articulated by the International Civil
Aviation Organization (ICAO).
Haindl, et al. Expires April 30, 2018 [Page 2]
Internet-Draft draft-haindl-ground-lisp-atn October 2017
ICAO is proposing to replace the existing aeronautical communication
services with an IPv6 based infrastructure that supports Air Traffic
Management (ATM) between commercial aircrafts, Air Traffic
Controllers (ATC) and Air Operation Controllers (AOC).
This document describes how a LISP overlay can be used to offer
mobility and multi-homing services to the IPv6 networks hosted on
commercial aircrafts without requiring LISP support in the airborne
routers. Use of the LISP protocol is limited to the ground-based
routers, hence the name "ground-based LISP". The material for this
document is derived from [GBL].
2. Definition of Terms
AOC: Airline Operational Control
ATN/IPS: Aeronautical Telecommunications Network with Internet
Protocol Services
AC-R: Access Ground Router
A/G-R: Air/Ground Router
G/G-R: Ground/Ground Router
A-R: Airborne Router
A-E: Airborne Endsystem
ATS-E: ATS Endsystem
For definitions of other terms, notably Map-Register, Map-Request,
Map-Reply, Routing Locator (RLOC), Solicit-Map-Request (SMR), Ingress
Tunnel Router (ITR), Egress Tunnel Router (ETR), xTR (ITR or ETR),
Map-Server (MS), and Map-Resolver (MR) please consult the LISP
specification [RFC6830].
3. Design Overview
In the ATN/IPS architecture the airborne endsystems hosted on an
aircraft are part of an IPV6 network connected to the ground network
by one or more Airborne Routers (A-R). A-Rs have multiple radio
interfaces that connects them via various radios infrastructures
(e.g. SATCOM, LDACS, AeroMACS) to a given radio region, also known
as subnetwork, on the ground. Typically an A-R has a corresponding
ground based Access Router (AC-R) that terminates the radio protocol
with the A-R and provides access services to the ground based portion
of the radio network infrastructure. Each radio region is
Haindl, et al. Expires April 30, 2018 [Page 3]
Internet-Draft draft-haindl-ground-lisp-atn October 2017
interconnected with the ATN/IPS ground network via an Air-to-Ground
router (AG-R).
Similarly, the Air Traffic Controllers and Air Operation Controllers
Endsystems (ATS-E and AOC-E) are part of IPv6 networks reachable via
one or more Ground-to-Ground Routers (G/G-Rs).
The ATN/IPS ground network infrastructure is the internetworking
region located between the A/G routers and the G/G routers.
In the ground-based LISP architecture, a LISP overlay is laid over
the ATN/IPS internetworking region (that is in the LISP RLOC space)
and provides connectivity between endsystems (that are in the LISP
EID space) hosted in the aircrafts and in the AOC/ATS regions. The
A/G-Rs and the G/G-Rs assume the role of LISP xTRs supported by a
LISP mapping system infrastructure.
Haindl, et al. Expires April 30, 2018 [Page 4]
Internet-Draft draft-haindl-ground-lisp-atn October 2017
,------,
,---------. : A-E1 :
,' `./'------'
( AIRCRAFT )
`. +-----+ ,'\ ,------,
`-| A-R |-' \: A-E2 :
+-----+ '------'
// \\
// \\
+---+--+ +-+--+--+
.--.-.| AC-R1|'.-. .| AC-R2 |.-.
( +---+--+ ) ( +-+--+--+ )
( __. ( '.
..'SATCOM Region ) .' LDACS Region )
( .'-' ( .'-'
' +-------+ ) ' +-------+ )
'-| A/G-R |-' '-| A/G-R |-''
| | | |
| xTR1 | | xTR2 |
+-------+ +-------+
\ /
\ .--..--. .--. ../
\ ( ' '.--.
.-.' Internetworking '' '-------'
( region )--: MS/MR :
( (RLOC SPACE) '-'' '-------'
._.'--'._.'.-._.'.-._)
/ \
+---+---+ +-+--+--+
-.-.| G/G-R |'. .| G/G-R |.
( | | ) ( | | )
( | xTR3 | ) ( | xTR4 | )
( +---+---+ ) ( +-+--+--+ )
( _._. ( '.
..' ATS Region ) .' AOC Region )
( .'-' ( .'-'
'--'._.'. )\ '--'._.'. )\
/ '--' \ / '--' \
'--------' '--------' '--------' '--------'
: ATS-E1 : : ATS-E2 : : AOC-E1 : : AOC-E2 :
'--------' '--------' '--------' '--------'
Figure 1: ATN/IPS and ground-based LISP overlay
Endsystems in the AOC/ATS regions are mapped in the LISP overlay by
the G/G-Rs, that are responsible for the registration of the AOC/ATS
endsystems to the LISP mapping system. Each G/G-R is basically an
Haindl, et al. Expires April 30, 2018 [Page 5]
Internet-Draft draft-haindl-ground-lisp-atn October 2017
xTR which has direct connections only to the terrestrial regions,
i.e. no direct connection to the radio regions.
Aircrafts will attach to a specific radio region, via the radio
interfaces of the A-Rs. How the radio attachment works is specific
to each particular radio infrastructure, and out of the scope of this
document, see [GBL].
Typically at the end of the attachment phase, the access router (AC-
R) corresponding to the A-R, will announce the reachability of the
EID prefixes corresponding to the attached aircraft (the announcement
is specific to each particular radio infrastructure, and is out of
the scope of this document). A/G-Rs in that particular radio region
are responsible to detect those announcements, and, since they act as
xTRs, register to the LISP mapping systems the corresponding IPv6 EID
prefixes on behalf of the A-R, but with the RLOC of the A/G-R.
The EID prefixes registered by the A/G-Rs are then reachable by any
of the AOC/ATS Endsystems that are part of the ground based LISP
overlay.
The LISP infrastructure is used to support seamless aircraft mobility
from one radio network to another, as well as multi-homing attachment
of an aircraft to multiple radio networks with use of LISP weight and
priorities to load balance traffic directed toward the aircraft.
The rest of this document provides further details on how ground-
based LISP is used to address the requirements of the ATN/IPS use
cases. The main design goals are:
o minimize added complexity on the aircraft
* airborne routers can assume that any ground system is reachable
via any A/G router. Static routing policies can be used on
board
* no need for routing/mobility protocols on board. Routing/
mobility is managed on the ground ATN/IPS network
* on-board outgoing link selection can be done with simple static
policy
o seamless support for aircraft mobility and multi-homing with
minimal traffic overhead on the A/G datalink
o minimize complexity of ground deployment
Haindl, et al. Expires April 30, 2018 [Page 6]
Internet-Draft draft-haindl-ground-lisp-atn October 2017
* ground-based LISP can be easily deployed over existing ATN/IPS
ground infrastructure
* it is based on COTS solutions
* can ease IPv4 to IPv6 transition issues
4. Basic Protocol Operation
Figure 1 provides the reference topology for a description of the
basic operation. A more detailed description of the basic protocol
operation is described in [GBL].
4.1. Endsystem Registration
The following are the steps via which airborne endsystem prefixes are
registered with the LISP mapping system:
1. Each Airborne Endsystem (A-E) is assigned an IPv6 address that is
the endsystem EID. Each EID includes a Network-ID prefix that
comprises (1) an ICAO ID which uniquely identifies the aircraft,
and possibly (2) an aircraft network identifier. Airborne
devices are grouped in one (and possibly several) IPv6 EID
prefixes. As an example an IPv6 EID prefix could be used for all
ATC applications located in a safety critical domain of the
aircraft network, another IPv6 EID prefix could be used for AOC
applications located in a less safety critical domain.
2. After the Airborne Router (A-R) on an aircraft attaches to one
radio region, the corresponding Access Router (AC-R) learns the
IPv6 EID prefixes belonging to the aircraft. The AC-R also
announces reachability of these prefixes in the radio region
(subnetwork) e.g. by using an IGP protocol like OSPF. The
attachment to a radio includes a preference parameter and a
quality parameter, these parameters are used e.g. to calculate
the IGP reachability advertisement metric.
3. The Air/Ground Router (A/G-R) in the subnetwork receives the
radio region announcements which contain reachablity information
for the IPv6 EID prefixes corresponding to the Airborne
Endsystems. Since each A/G-R is also an xTR, the A/G-R registers
the IPv6 EID prefixes with the LISP MS/MR on behalf of the A-R,
but with the RLOC of the A/G-R. The included quality parameter
(e.g. IGP metric) is converted to a LISP priority, so that a
lower quality metric results in a lower LISP priority value.
Ground based endsystems are part of ground subnetworks where the
Ground/Ground Router (G/G-R) is an xTR. Each G/G-R therefore
Haindl, et al. Expires April 30, 2018 [Page 7]
Internet-Draft draft-haindl-ground-lisp-atn October 2017
registers the prefixes corresponding to the AOC endsystems and ATS
endsystems with the LISP mapping system, as specified in [RFC6830].
4.2. Ground to Airborne Traffic Flow
Here is an example of how traffic flows from the ground to the
airborne endsystems, when ATS endsystem 1 (ATS-E1) has traffic
destined to airborne endsystem 1 (A-E1):
1. The default route in the ATS region takes the traffic to xTR3
which is also a Ground/Ground Router (G/G-R).
2. xTR3 sends a Map-Request message for the address of A-E1 to the
LISP mapping system. xTR2 sends a Map-Reply to xTR3 with RLOC set
to its address which is reachable from xTR3 via the
internetworking region.
3. xTR3 encapsulates the traffic to xTR2 using the RLOC information
in the Map-Reply message.
4. xTR2 decapsulates the traffic coming from xTR3. The destination
address of the inner packet belongs to A-E1 which has been
advertised by the AC-R in the same region. The traffic is
therefore forwarded to AC-R2.
5. AC-R2 sends the traffic to the Airborne Router of the aircraft
and the A-R sends it to the endsystem.
4.3. Airborne to Ground Traffic Flow
Here is an example of how traffic flows from the airborne endsystems
to the ground when airborne endsystem 2 (A-E2) has traffic destined
to ATS endsystem 2 (ATS-E2):
1. The default route in the aircraft points to the Airborne Router
(A-R). The latter forwards the traffic over the radio link to
AC-R2.
2. The default route on AC-R2 points to xTR2 (also an A/G-R), so the
traffic is sent from AC-R2 to xTR2.
3. xTR2 sends a Map-Request message for the address of ATS-E2 to the
LISP mapping system. xTR3 sends a Map-Reply to xTR2 with RLOC set
to its address which is reachable from xTR2 via the
internetworking region.
4. xTR2 encapsulates the traffic to xTR3 using the RLOC information
in the Map-Reply message.
Haindl, et al. Expires April 30, 2018 [Page 8]
Internet-Draft draft-haindl-ground-lisp-atn October 2017
5. xTR3 decapsulates the traffic coming from xTR2, and forwards it
to ATS-E2.
4.4. Default forwarding path
When an xTR is waiting for a Map-Reply for an EID, the xTR does not
know how to forward the packets destined to that EID. This means
that the first packets for ground-to-air traffic would get dropped
until the Map-Reply is received and a map-cache entry is created.
However if a device acting as RTR, see
[I-D.ermagan-lisp-nat-traversal], has mappings for all EIDs, the xTR
could use the RTR as default path for packets which have to be
encapsulated. How the RTR gets all the mappings is outside the scope
of this document but one example is the use of LISP pub-sub as
specified in [I-D.rodrigueznatal-lisp-pubsub]. Note that the RTR
does not have to be a new device, the device which has the MS/MR role
can also act as RTR. It is only the RTR which needs to subscribe to
all the aircraft EIDs, the XTRs (i.e. the A/G-Rs and G/G-Rs) do not
need to subscribe.
4.5. Traffic symmetry
The requirements for traffic symmetry are still TBD.
5. Multi-Homing and Mobility
Multi-homing support builds on the procedures described in Section 4:
1. The Airborne Router (A-R) on an aircraft attaches to multiple
radio regions. As an example, and referring to Figure 1, the A-R
attaches to the LDACS and SATCOM regions, via AC-R2 and AC-R1
respectively.
2. Through the preference parameter sent to each region, the A-R has
control over which path (i.e. radio region) ground to air traffic
flows. For example, A-R would indicate preference of the LDACS
region by choosing a better preference value for the LDACS region
compared to the preference value sent to the SATCOM region.
3. Both xTR1 and xTR2 register the IPv6 EID prefixes with the LISP
mapping system using merge semantic, as specified in section 4.6
of [I-D.ietf-lisp-rfc6833bis]. Since the priority used in the
LISP registrations is derived from the preference and quality
parameters, xTR2 would use a lower priority value than xTR1. In
this way the LISP mapping system will favour xTR2 (A/G-R for the
LDACS region) over xTR1 (A/G-R for the SATCOM region), as
specified by the preference and quality parameters.
Haindl, et al. Expires April 30, 2018 [Page 9]
Internet-Draft draft-haindl-ground-lisp-atn October 2017
4. Upon registration the LISP MS/MR will send Map-Notify messages to
both xTR1 and xTR2, to inform that they have reachability to the
aircraft's IPv6 EID prefixes. Both xTRs are notified because
they have both set the merge-request and want-map-notify bits in
their respective Map-Register message.
5. Upstream and downstream traffic flows on the same path, i.e. both
use the LDACS region.
With mobility, the aircraft could want to switch traffic from one
radio link to another. For example while transiting from an area
covered by LDACS to an area covered by SATCOM, the aircraft could
desire to switch all traffic from LDACS to SATCOM. For air-to-ground
traffic, the A-R has complete control over which radio link to use,
and will simply select the SATCOM outgoing interface. For ground-to-
air traffic:
1. The A-R sends a radio advertisement to AC-R1 indicating a better
preference for the SATCOM link.
2. This leads to AC-R1 lowering its quality parameter (e.g. IGP
metric) for the IPv6 EID prefixes.
3. Upon receiving the better preference value, xTR1 registers the
IPv6 EID prefixes with the MS/MR, using a lower priority value
than what xTR2 had used. Both xTR1 and xTR2 receives Map-Notify
messages signaling to xTR2 that xTR1 is now the preferred path
toward the aircraft.
4. xTR3 has a map-cache which still points to xTR2, therefore xTR3
still sends traffic via xTR2. xTR2 sends Solicit-Map-Request
(SMR) to xTR3 who queries the LISP mapping system again. This
results in updating the map-cache on xTR3 which now points to
XTR1 so ground-to-air traffic now flows on the SATCOM radio link.
The procedure for mobility is derived from
[I-D.ietf-lisp-eid-mobility].
6. Convergence
When traffic is flowing on a radio link and that link goes down, the
network has to converge rapidly on the other link available for that
aircraft.
For air-to-ground traffic, once the A-R detects the failure it can
switch immediatly to the other radio link.
Haindl, et al. Expires April 30, 2018 [Page 10]
Internet-Draft draft-haindl-ground-lisp-atn October 2017
For ground-to-air traffic, when a radio link fails, the corresponding
AC-R sends a reachability update that the IPv6 EID prefixes are not
reachable anymore. This leads to the A/G-R (also an xTR) in that
region to unregister the IPv6 EID prefixes with the MS/MR. This
indicates that the xTR in question has no reachability to the EID
prefixes. The notification of the failure should reach all relevant
xTRs as soon as possible. For example, if the LDACS radio link
fails, xTR3 and xTR4 need to learn about the failure so that they
stop sending traffic via xTR2 and use xTR1 instead.
In the sub-sections below, we the use of RLOC-probing, Solicit-Map-
Request, and LISP pub-sub as alternative mechanisms for link failure
notification.
6.1. Use of RLOC-probing
RLOC-probing is described in section 6.3.2 of [RFC6830].
At regular intervals xTR3 sends Map-Request to xTR2 for the
aircraft's EID prefixes. When xTR3 detects via RLOC-probing that it
can not use xTR2 anymore, it sends a Map-Request for the aircraft's
EID prefixes. The corresponding Map-Reply indicates that xTR1 should
now be used. The map-cache on xTR3 is updated and air-to-ground
traffic now goes through xTR1 to use the SATCOM radio link to the
aircraft.
The disadvantage of RLOC-probing is that fast detection becomes more
difficult when the number of EID prefixes is large.
6.2. Use of Solicit-Map-Request
Solicit-Map-Request is used as described in Section 5:
1. xTR3 is still sending traffic to xTR2 since its map-cache has not
been updated yet.
2. Upon detecting that the link is down, and receiving data plane
traffic from the ground network, xTR2 sends an SMR to xTR3 that
sends a Map-Request to update its map-cache. The corresponding
Map-Reply indicates that xTR1 should now be used.
The disadvantage of this approach is that the traffic is delayed
pending control-plane resolution. This method also depends on data
traffic being continuous, in many cases data traffic may be sporadic,
leading to very slow convergence.
Haindl, et al. Expires April 30, 2018 [Page 11]
Internet-Draft draft-haindl-ground-lisp-atn October 2017
6.3. Use of LISP pub-sub
As specified in [I-D.rodrigueznatal-lisp-pubsub], ITRs can subscribe
to changes in the LISP mapping system. So if all ITRs subscribe to
the EID prefixes for which they have traffic, the ITRs will be
notified when there is mapping change.
In the example where the LDACS radio link fails, when xTR2
unregisters the EID prefixes with the MS/MR, xTR3 would be notified
via LISP pub-sub (assuming xTR3 has a map-cache entry for these EID
prefixes).
This mechanism provides the fastest convergence at the cost of more
state in the LISP mapping system.
7. Security Considerations
For LISP control-plane message security, please refer to
[I-D.ietf-lisp-sec]. This addresses the control-plane threats that
target EID-to-RLOC mappings, including manipulations of Map-Request
and Map-Reply messages, and malicious ETR EID prefix overclaiming.
8. IANA Considerations
No IANA considerations.
9. Acknowledgements
The authors would like to thank Dino Farinacci for his review of the
document.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013,
<https://www.rfc-editor.org/info/rfc6830>.
Haindl, et al. Expires April 30, 2018 [Page 12]
Internet-Draft draft-haindl-ground-lisp-atn October 2017
10.2. Informative References
[GBL] Frequentis, "Ground Based LISP for Multilink Operation,
https://www.icao.int/safety/acp/ACPWGF/CP WG-I 19/WP06
Ground_Based_LISP 2016-01-14.pdf", January 2016.
[I-D.ermagan-lisp-nat-traversal]
Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino,
F., and C. White, "NAT traversal for LISP", draft-ermagan-
lisp-nat-traversal-13 (work in progress), September 2017.
[I-D.ietf-lisp-eid-mobility]
Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,
F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
Unified Control Plane", draft-ietf-lisp-eid-mobility-00
(work in progress), May 2017.
[I-D.ietf-lisp-rfc6833bis]
Fuller, V., Farinacci, D., and A. Cabellos-Aparicio,
"Locator/ID Separation Protocol (LISP) Control-Plane",
draft-ietf-lisp-rfc6833bis-06 (work in progress), October
2017.
[I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14
(work in progress), October 2017.
[I-D.rodrigueznatal-lisp-pubsub]
Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F.,
Cabellos-Aparicio, A., Barkai, S., Farinacci, D.,
Boucadair, M., Jacquenet, C., and s.
stefano.secci@lip6.fr, "Publish/Subscribe Functionality
for LISP", draft-rodrigueznatal-lisp-pubsub-01 (work in
progress), October 2017.
Authors' Addresses
Bernhard Haindl
Frequentis
Email: bernhard.haindl@frequentis.com
Manfred Lindner
Frequentis
Email: manfred.lindner@frequentis.com
Haindl, et al. Expires April 30, 2018 [Page 13]
Internet-Draft draft-haindl-ground-lisp-atn October 2017
Reshad Rahman
Cisco Systems
Email: rrahman@cisco.com
Marc Portoles Comeras
Cisco Systems
Email: mportole@cisco.com
Victor Moreno
Cisco Systems
Email: vmoreno@cisco.com
Fabio Maino
Cisco Systems
Email: fmaino@cisco.com
Haindl, et al. Expires April 30, 2018 [Page 14]
