draft-ietf-lisp-introduction-06.txt   draft-ietf-lisp-introduction-07.txt 
Network Working Group A. Cabellos Network Working Group A. Cabellos
Internet-Draft UPC-BarcelonaTech Internet-Draft UPC-BarcelonaTech
Intended status: Informational D. Saucez (Ed.) Intended status: Informational D. Saucez (Ed.)
Expires: April 26, 2015 INRIA Expires: April 27, 2015 INRIA
October 23, 2014 October 24, 2014
An Architectural Introduction to the Locator/ID Separation Protocol An Architectural Introduction to the Locator/ID Separation Protocol
(LISP) (LISP)
draft-ietf-lisp-introduction-06.txt draft-ietf-lisp-introduction-07.txt
Abstract Abstract
This document describes the architecture of the Locator/ID Separation This document describes the architecture of the Locator/ID Separation
Protocol (LISP), making it easier to read the rest of the LISP Protocol (LISP), making it easier to read the rest of the LISP
specifications and providing a basis for discussion about the details specifications and providing a basis for discussion about the details
of the LISP protocols. This document is used for introductory of the LISP protocols. This document is used for introductory
purposes, more details can be found in RFC6830, the protocol purposes, more details can be found in RFC6830, the protocol
specification. specification.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 April 26, 2015. This Internet-Draft will expire on April 27, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
3. LISP Architecture . . . . . . . . . . . . . . . . . . . . . . 4 3. LISP Architecture . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Design Principles . . . . . . . . . . . . . . . . . . . . 4 3.1. Design Principles . . . . . . . . . . . . . . . . . . . . 4
3.2. Overview of the Architecture . . . . . . . . . . . . . . 4 3.2. Overview of the Architecture . . . . . . . . . . . . . . 4
3.3. Data-Plane . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Data-Plane . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.1. LISP Encapsulation . . . . . . . . . . . . . . . . . 7 3.3.1. LISP Encapsulation . . . . . . . . . . . . . . . . . 7
3.3.2. LISP Forwarding State . . . . . . . . . . . . . . . . 8 3.3.2. LISP Forwarding State . . . . . . . . . . . . . . . . 8
3.4. Control-Plane . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Control-Plane . . . . . . . . . . . . . . . . . . . . . . 9
3.4.1. LISP Mappings . . . . . . . . . . . . . . . . . . . . 9 3.4.1. LISP Mappings . . . . . . . . . . . . . . . . . . . . 9
3.4.2. Mapping System Interface . . . . . . . . . . . . . . 9 3.4.2. Mapping System Interface . . . . . . . . . . . . . . 9
3.4.3. Mapping System . . . . . . . . . . . . . . . . . . . 10 3.4.3. Mapping System . . . . . . . . . . . . . . . . . . . 10
3.5. Interworking Mechanisms . . . . . . . . . . . . . . . . . 13 3.5. Interworking Mechanisms . . . . . . . . . . . . . . . . . 13
4. LISP Operational Mechanisms . . . . . . . . . . . . . . . . . 13 4. LISP Operational Mechanisms . . . . . . . . . . . . . . . . . 13
4.1. Cache Management . . . . . . . . . . . . . . . . . . . . 14 4.1. Cache Management . . . . . . . . . . . . . . . . . . . . 14
4.2. RLOC Reachability . . . . . . . . . . . . . . . . . . . . 14 4.2. RLOC Reachability . . . . . . . . . . . . . . . . . . . . 14
4.3. ETR Synchronization . . . . . . . . . . . . . . . . . . . 16 4.3. ETR Synchronization . . . . . . . . . . . . . . . . . . . 16
4.4. MTU Handling . . . . . . . . . . . . . . . . . . . . . . 16 4.4. MTU Handling . . . . . . . . . . . . . . . . . . . . . . 16
5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 16
skipping to change at page 2, line 49 skipping to change at page 2, line 49
8.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 19 8.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 19
8.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . 19 8.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . 19
8.3. LISP for Virtual Private Networks . . . . . . . . . . . . 20 8.3. LISP for Virtual Private Networks . . . . . . . . . . . . 20
8.4. LISP for Virtual Machine Mobility in Data Centers . . . . 20 8.4. LISP for Virtual Machine Mobility in Data Centers . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . 22 12.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. A Brief History of Location/Identity Separation . . 23 Appendix A. A Brief History of Location/Identity Separation . . 24
A.1. Old LISP Models . . . . . . . . . . . . . . . . . . . . . 24 A.1. Old LISP Models . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
This document introduces the Locator/ID Separation Protocol (LISP) This document introduces the Locator/ID Separation Protocol (LISP)
[RFC6830] architecture, its main operational mechanisms and its [RFC6830] architecture, its main operational mechanisms and its
design rationale. Fundamentally, LISP is built following a well- design rationale. Fundamentally, LISP is built following a well-
known architectural idea: decoupling the IP address overloaded known architectural idea: decoupling the IP address overloaded
semantics. Indeed and as pointed out by [Chiappa], currently IP semantics. Indeed and as pointed out by [Chiappa], currently IP
skipping to change at page 3, line 39 skipping to change at page 3, line 39
retrieve mappings between identity and location. LISP-capable retrieve mappings between identity and location. LISP-capable
routers exchange packets over the Internet core by encapsulating them routers exchange packets over the Internet core by encapsulating them
to the appropriate location. to the appropriate location.
By taking advantage of such separation between location and identity By taking advantage of such separation between location and identity
LISP offers Traffic Engineering, multihoming, and mobility among LISP offers Traffic Engineering, multihoming, and mobility among
others benefits. Additionally, LISP's approach to solve the routing others benefits. Additionally, LISP's approach to solve the routing
scalability problem [RFC4984] is that with LISP the Internet core is scalability problem [RFC4984] is that with LISP the Internet core is
populated with RLOCs while Traffic Engineering mechanisms are pushed populated with RLOCs while Traffic Engineering mechanisms are pushed
to the Mapping System. With this RLOCs are quasi-static (i.e., low to the Mapping System. With this RLOCs are quasi-static (i.e., low
churn) and hence, the routing system scalable [Quoitin]. churn) and hence, the routing system scalable [Quoitin] while EIDs
can roam anywhere with no churn to the underlying routing system.
This document describes the LISP architecture, its main operational This document describes the LISP architecture, its main operational
mechanisms as its design rationale. It is important to note that mechanisms as its design rationale. It is important to note that
this document does not specify or complement the LISP protocol. The this document does not specify or complement the LISP protocol. The
interested reader should refer to the main LISP specifications interested reader should refer to the main LISP specifications
[RFC6830] and the complementary documents [RFC6831],[RFC6832], [RFC6830] and the complementary documents [RFC6831], [RFC6832],
[RFC6833],[RFC6834],[RFC6835], [RFC6836] for the protocol [RFC6833], [RFC6834], [RFC6835], [RFC6836], [RFC7052] for the
specifications along with the LISP deployment guidelines [RFC7215]. protocol specifications along with the LISP deployment guidelines
[RFC7215].
2. Definition of Terms 2. Definition of Terms
This document describes the LISP architecture and does not define or This document describes the LISP architecture and does not define or
introduce any new term. The reader is referred to introduce any new term. The reader is referred to [RFC6830],
[RFC6830],[RFC6831],[RFC6832],[RFC6833],[RFC6834],[RFC6835], [RFC6831], [RFC6832], [RFC6833], [RFC6834], [RFC6835], [RFC6836],
[RFC6836],[RFC7215] for the LISP definition of terms. [RFC7052], [RFC7215] for the LISP definition of terms.
3. LISP Architecture 3. LISP Architecture
This section presents the LISP architecture, it first details the This section presents the LISP architecture, it first details the
design principles of LISP and then it proceeds to describe its main design principles of LISP and then it proceeds to describe its main
aspects: data-plane, control-plane, and inetrworking mechanisms. aspects: data-plane, control-plane, and inetrworking mechanisms.
3.1. Design Principles 3.1. Design Principles
The LISP architecture is built on top of four basic design The LISP architecture is built on top of four basic design
principles: principles:
o Locator/Identifier split: By decoupling the overloaded semantics o Locator/Identifier split: By decoupling the overloaded semantics
of the current IP addresses the Internet core can be assigned of the current IP addresses the Internet core can be assigned
identity meaningful addresses and hence, can use aggregation to identity meaningful addresses and hence, can use aggregation to
scale. Devices are assigned with identity meaningful addresses scale. Devices are assigned with relatively opaque identity
that are independent of their topological location. meaningful addresses that are independent of their topological
location.
o Overlay architecture: Overlays route packets over the current o Overlay architecture: Overlays route packets over the current
Internet, allowing deployment of new protocols without changing Internet, allowing deployment of new protocols without changing
the current infrastructure hence, resulting into a low deployment the current infrastructure hence, resulting into a low deployment
cost. cost.
o Decoupled data and control-plane: Separating the data-plane from o Decoupled data and control-plane: Separating the data-plane from
the control-plane allows them to scale independently and use the control-plane allows them to scale independently and use
different architectural approaches. This is important given that different architectural approaches. This is important given that
they typically have different requirements. they typically have different requirements and allows for other
data-planes to be added.
o Incremental deployability: This principle ensures that the o Incremental deployability: This principle ensures that the
protocol interoperates with the legacy Internet while providing protocol interoperates with the legacy Internet while providing
some of the targeted benefits to early adopters. some of the targeted benefits to early adopters.
3.2. Overview of the Architecture 3.2. Overview of the Architecture
LISP splits architecturally the core from the edge of the Internet by LISP splits architecturally the core from the edge of the Internet by
creating two separate namespaces: Endpoint Identifiers (EIDs) and creating two separate namespaces: Endpoint Identifiers (EIDs) and
Routing LOCators (RLOC). The edge consists of LISP sites (e.g., an Routing LOCators (RLOCs). The edge consists of LISP sites (e.g., an
Autonomous System) that use EID addresses. EIDs are typically -but Autonomous System) that use EID addresses. EIDs are typically -but
not limited to- IPv4 or IPv6 addresses that uniquely identify not limited to- IPv4 or IPv6 addresses that uniquely identify
communication end-hosts and are assigned and configured by the same communication end-hosts and are assigned and configured by the same
mechanisms that exist at the time of this writing. EIDs do not mechanisms that exist at the time of this writing. EIDs do not
contain inter-domain topological information and can be thought as an contain inter-domain topological information and can be thought as an
analogy to Provider Independent (PI [RFC4116]) addresses. Because of analogy to Provider Independent (PI [RFC4116]) addresses. Because of
this, EIDs are usually only routable at the edge. this, EIDs are usually only routable at the edge with a LISP site.
With LISP, LISP sites (edge) and the core of the Internet are With LISP, LISP sites (edge) and the core of the Internet are
interconnected by means of LISP-capable routers (e.g., border interconnected by means of LISP-capable routers (e.g., border
routers) using tunnels. When packets originated from a LISP site are routers) using tunnels. When packets originated from a LISP site are
flowing towards the core network, they ingress into an encapsulated flowing towards the core network, they ingress into an encapsulated
tunnel via an Ingress Tunnel Router (ITR). When packets flow from tunnel via an Ingress Tunnel Router (ITR). When packets flow from
the core network to a LISP site, they egress from an encapsulated the core network to a LISP site, they egress from an encapsulated
tunnel to an Egress Tunnel Router (ETR). An xTR is a router with can tunnel to an Egress Tunnel Router (ETR). An xTR is a router which
perform both ITR and ETR operations. In this context ITRs can perform both ITR and ETR operations. In this context ITRs
encapsulate packets while ETRs decapsulate them, hence LISP operates encapsulate packets while ETRs decapsulate them, hence LISP operates
as an overlay to the current Internet core. as an overlay on top of the current Internet core.
/-----------------\ --- /-----------------\ ---
| Mapping | | | Mapping | |
. System | | Control . System | | Control
-| |`, | Plane -| |`, | Plane
,' \-----------------/ . | ,' \-----------------/ . |
/ \ --- / \ ---
,.., - _,..--..,, `, ,.., | ,.., - _,..--..,, `, ,.., |
/ ` ,' ,-` `', . / ` | / ` ,' ,-` `', . / ` |
/ \ +-----+ ,' `, +--'--+ / \ | / \ +-----+ ,' `, +--'--+ / \ |
skipping to change at page 5, line 42 skipping to change at page 5, line 44
``''--''`` ``''--''``
LISP Site (Edge) Core LISP Site (Edge) LISP Site (Edge) Core LISP Site (Edge)
Figure 1.- A schema of the LISP Architecture Figure 1.- A schema of the LISP Architecture
With LISP, the core uses RLOCs, an RLOC is typically -but not limited With LISP, the core uses RLOCs, an RLOC is typically -but not limited
to- an IPv4 or IPv6 address assigned to an Internet-facing network to- an IPv4 or IPv6 address assigned to an Internet-facing network
interface of an ITR or ETR. Typically RLOCs are numbered from interface of an ITR or ETR. Typically RLOCs are numbered from
topologically aggregatable blocks assigned to a site at each point to topologically aggregatable blocks assigned to a site at each point to
which it attaches to the global Internet. The topology is defined by which it attaches to the global Internet. The topology is defined by
the connectivity of networks, in this context RLOCs can be though as the connectivity of networks, in this context RLOCs can be thought of
Provider Aggregatable addresses [RFC4116]. Provider Aggregatable addresses [RFC4116].
A typically distributed database, called the Mapping System, stores A typically distributed database, called the Mapping System, stores
mappings between EIDs and RLOCs. Such mappings relate the identity mappings between EIDs and RLOCs. Such mappings relate the identity
of the devices attached to LISP sites (EIDs) to the set of RLOCs of the devices attached to LISP sites (EIDs) to the set of RLOCs
configured at the LISP-capable routers servicing the site. configured at the LISP-capable routers servicing the site.
Furthermore, the mappings also include traffic engineering policies Furthermore, the mappings also include traffic engineering policies
and can be configured to achieve multihoming and load balancing. The and can be configured to achieve multihoming and load balancing. The
LISP Mapping System is conceptually similar to the DNS that would be LISP Mapping System is conceptually similar to the DNS where it is
accessed by ETRs to register mappings and by ITRs to retrieve them. organized as a distributed multi-organization network database. With
LISP, ETRs register mappings while ITRs retrieve them.
Finally, the LISP architecture emphasizes a cost effective Finally, the LISP architecture emphasizes a cost effective
incremental deployment. Given that LISP represents an overlay to the incremental deployment. Given that LISP represents an overlay to the
current Internet architecture, endhosts as well as intra and inter- current Internet architecture, endhosts as well as intra and inter-
domain routers remain unchanged, and the only required changes to the domain routers remain unchanged, and the only required changes to the
existing infrastructure are to routers connecting the EID with the existing infrastructure are to routers connecting the EID with the
RLOC space. Such LISP capable routers, in most cases, only require a RLOC space. Such LISP capable routers, in most cases, only require a
software upgrade. Additionally, LISP requires the deployment of an software upgrade. Additionally, LISP requires the deployment of an
independent Mapping System, such distributed database is a new independent Mapping System, such distributed database is a new
network entity. network entity.
The following describes a simplified packet flow sequence between two The following describes a simplified packet flow sequence between two
nodes that are attached to LISP sites. Client hostA wants to send a nodes that are attached to LISP sites. Client HostA wants to send a
packet to server hostB. packet to server HostB.
/----------------\ /----------------\
| Mapping | | Mapping |
| System | | System |
.| |- .| |-
` \----------------/ `. ` \----------------/ `.
,` \ ,` \
/ `. / `.
,' _,..-..,, ', ,' _,..-..,, ',
/ -` `-, \ / -` `-, \
skipping to change at page 7, line 9 skipping to change at page 7, line 13
Figure 2.- Packet flow sequence in LISP Figure 2.- Packet flow sequence in LISP
1. HostA retrieves the EID_B of HostB (typically querying the DNS) 1. HostA retrieves the EID_B of HostB (typically querying the DNS)
and generates an IP packet as in the Internet, the packet has and generates an IP packet as in the Internet, the packet has
source address EID_A and destination address EID_B. source address EID_A and destination address EID_B.
2. The packet is routed towards ITR_A in the LISP site using 2. The packet is routed towards ITR_A in the LISP site using
standard intra-domain mechanisms. standard intra-domain mechanisms.
3. ITR_A upon receiving the packet queries the Mapping System to 3. ITR_A upon receiving the packet queries the Mapping System to
retrieve the locator of ETR_B that is servicing hostB's EID_B. retrieve the locator of ETR_B that is servicing HostB's EID_B.
In order to do so it uses a LISP control message called Map- In order to do so it uses a LISP control message called Map-
Request, the message contains EID_B as the lookup key. In turn Request, the message contains EID_B as the lookup key. In turn
it receives another LISP control message called Map-Reply, the it receives another LISP control message called Map-Reply, the
message contains two locators: RLOC_B1 and RLOC_B2 along with message contains two locators: RLOC_B1 and RLOC_B2 along with
traffic engineering policies: priority and weight per locator. traffic engineering policies: priority and weight per locator.
ITR_A also stores the mapping in a local cache to speed-up ITR_A also stores the mapping in a local cache to speed-up
forwarding of subsequent packets. forwarding of subsequent packets.
4. ITR_A encapsulates the packet towards RLOC_B1 (chosen according 4. ITR_A encapsulates the packet towards RLOC_B1 (chosen according
to the priorities/weights specified in the mapping). The packet to the priorities/weights specified in the mapping). The packet
skipping to change at page 7, line 31 skipping to change at page 7, line 35
and RLOC_B2 as destination, the inner original header has EID_A and RLOC_B2 as destination, the inner original header has EID_A
as source and EID_B as destination. Furthermore ITR_A adds a as source and EID_B as destination. Furthermore ITR_A adds a
LISP header, more details about LISP encapsulation can be found LISP header, more details about LISP encapsulation can be found
in Section 3.3.1. in Section 3.3.1.
5. The encapsulated packet is forwarded by the Internet core as a 5. The encapsulated packet is forwarded by the Internet core as a
normal IP packet, making the EID invisible from the Internet normal IP packet, making the EID invisible from the Internet
core. core.
6. Upon reception of the encapsulated packet by ETR_B, it 6. Upon reception of the encapsulated packet by ETR_B, it
decapsulates the packet and forwards it to hostB. decapsulates the packet and forwards it to HostB.
3.3. Data-Plane 3.3. Data-Plane
This section provides a high-level description of the LISP data- This section provides a high-level description of the LISP data-
plane, which is specified in detail in [RFC6830]. The LISP data- plane, which is specified in detail in [RFC6830]. The LISP data-
plane is responsible for encapsulating and decapsulating data packets plane is responsible for encapsulating and decapsulating data packets
and caching the appropriate forwarding state. It includes two main and caching the appropriate forwarding state. It includes two main
entities, the ITR and the ETR, both are LISP capable routers that entities, the ITR and the ETR, both are LISP capable routers that
connect the EID with the RLOC space (ITR) and vice versa (ETR). connect the EID with the RLOC space (ITR) and vice versa (ETR).
skipping to change at page 8, line 13 skipping to change at page 8, line 16
xTRs can forward packets more efficiently. xTRs can forward packets more efficiently.
LISP-encapsulated packets also include a LISP header (after the UDP LISP-encapsulated packets also include a LISP header (after the UDP
header and before the original IP header). The LISP header is header and before the original IP header). The LISP header is
prepended by ITRs and striped by ETRs. It carries reachability prepended by ITRs and striped by ETRs. It carries reachability
information (see more details in Section 4.2) and the Instance ID information (see more details in Section 4.2) and the Instance ID
field. The Instance ID field is used to distinguish traffic to/from field. The Instance ID field is used to distinguish traffic to/from
different tenant address spaces at the LISP site and that may use different tenant address spaces at the LISP site and that may use
overlapped but logically separated EID addressing. overlapped but logically separated EID addressing.
Overall, LISP encapsulated data packets carry 4 headers [RFC6830] Overall, LISP works on 4 headers, the inner header the source
("outer" to "inner"): constructed, and the 3 headers a LISP encapsulator prepends ("outer"
to "inner"):
1. Outer IP header containing RLOCs as source and destination 1. Outer IP header containing RLOCs as source and destination
addresses. This header is originated by ITRs and stripped by addresses. This header is originated by ITRs and stripped by
ETRs. ETRs.
2. UDP header (port 4341) with zero checksum. This header is 2. UDP header (port 4341) with zero checksum. This header is
originated by ITRs and stripped by ETRs. originated by ITRs and stripped by ETRs.
3. LISP header that contains various forwarding-plane features (such 3. LISP header that contains various forwarding-plane features (such
as reachability) and an Instance ID field. This header is as reachability) and an Instance ID field. This header is
originated by ITRs and stripped by ETRs. originated by ITRs and stripped by ETRs.
4. Inner IP header containing EIDs as source and destination 4. Inner IP header containing EIDs as source and destination
addresses. This header is created by the source end-host and is addresses. This header is created by the source end-host and is
left unchanged by LISP data plane processing on the ITR and ETR. left unchanged by LISP data plane processing on the ITR and ETR.
Finally, in some scenarios Recursive and/or Re-encapsulating tunnels Finally, in some scenarios Recursive and/or Re-encapsulating tunnels
can be used for Traffic Engineering and re-routing. Re-encapsulating can be used for Traffic Engineering and re-routing. Re-encapsulating
tunnels are consecutive LISP tunnels and occur when an ETR removes a tunnels are consecutive LISP tunnels and occur when a decapsulator
LISP header and then acts as an ITR to prepend another one. On the (an ETR action) removes a LISP header and then acts as an encapsultor
other hand, Recursive tunnels are nested tunnels and are implemented (an ITR action) to prepend another one. On the other hand, Recursive
by using multiple LISP encapsulations on a packet. Typically such tunnels are nested tunnels and are implemented by using multiple LISP
functions are implemented by Reencapsulating Tunnel Routers (RTRs). encapsulations on a packet. Typically such functions are implemented
by Reencapsulating Tunnel Routers (RTRs).
3.3.2. LISP Forwarding State 3.3.2. LISP Forwarding State
ITRs retrieve from the LISP Mapping System mappings between EID ITRs retrieve from the LISP Mapping System mappings between EID
prefixes and RLOCs that are used to encapsulate packets. Such prefixes and RLOCs that are used to encapsulate packets. Such
mappings are stored in a local cache -called the Map-Cache- for mappings are stored in a local cache called the Map-Cache for
subsequent packets addressed to the same EID prefix. Mappings subsequent packets addressed to the same EID prefix. Mappings
include a (Time-to-Live) TTL (set by the ETR). More details about include a (Time-to-Live) TTL (set by the ETR). More details about
the Map-Cache management can be found in Section 4.1. the Map-Cache management can be found in Section 4.1.
3.4. Control-Plane 3.4. Control-Plane
The LISP control-plane, specified in [RFC6833], provides a standard The LISP control-plane, specified in [RFC6833], provides a standard
interface to register, request, and resolve mappings. The LISP interface to register and request mappings. The LISP Mapping System
Mapping System is a database that stores such mappings. The is a database that stores such mappings. The following first
following first describes the mappings, then the standard interface describes the mappings, then the standard interface to the Mapping
to the Mapping System, and finally its architecture. System, and finally its architecture.
3.4.1. LISP Mappings 3.4.1. LISP Mappings
Each mapping includes the bindings between EID prefix(es) and set of Each mapping includes the bindings between EID prefix(es) and set of
RLOCs as well as traffic engineering policies, in the form of RLOCs as well as traffic engineering policies, in the form of
priorities and weights for the RLOCs. Priorities allow the ETR to priorities and weights for the RLOCs. Priorities allow the ETR to
configure active/backup policies while weights are used to load- configure active/backup policies while weights are used to load-
balance traffic among the RLOCs (on a per-flow basis). balance traffic among the RLOCs (on a per-flow basis).
Typical mappings in LISP bind EIDs in the form of IP prefixes with a Typical mappings in LISP bind EIDs in the form of IP prefixes with a
skipping to change at page 9, line 41 skipping to change at page 9, line 47
Map-Server: A network infrastructure component that learns mappings Map-Server: A network infrastructure component that learns mappings
from ETRs and publishes them into the LISP Mapping System. from ETRs and publishes them into the LISP Mapping System.
Typically Map-Servers are not authoritative to reply to queries Typically Map-Servers are not authoritative to reply to queries
and hence, they forward them to the ETR. However they can also and hence, they forward them to the ETR. However they can also
operate in proxy-mode, where the ETRs delegate replying to queries operate in proxy-mode, where the ETRs delegate replying to queries
to Map-Servers. This setup is useful when the ETR has limited to Map-Servers. This setup is useful when the ETR has limited
resources (i.e., CPU or power). resources (i.e., CPU or power).
Map-Resolver: A network infrastructure component that interfaces Map-Resolver: A network infrastructure component that interfaces
ITRs with the Mapping System by proxying queries and -in some ITRs with the Mapping System by proxying queries and in some cases
cases- responses. responses.
The interface defines four LISP control messages which are sent as The interface defines four LISP control messages which are sent as
UDP datagrams (port 4342): UDP datagrams (port 4342):
Map-Register: This message is used by ETRs to register mappings in Map-Register: This message is used by ETRs to register mappings in
the Mapping System and it is authenticated using a shared key the Mapping System and it is authenticated using a shared key
between the ETR and the Map-Server. between the ETR and the Map-Server.
Map-Notify: When requested by the ETR, this message is sent by the Map-Notify: When requested by the ETR, this message is sent by the
Map-Server in response to a Map-Register to acknowledge the Map-Server in response to a Map-Register to acknowledge the
correct reception of the mapping and convey the latest Map-Server correct reception of the mapping and convey the latest Map-Server
state on the EID to RLOC mapping. state on the EID to RLOC mapping. In some cases a Map-Notify can
be sent to the previous RLOCs when an EID is registered by a new
set of RLOCs.
Map-Request: This message is used by ITRs or Map-Resolvers to Map-Request: This message is used by ITRs or Map-Resolvers to
resolve the mapping of a given EID. resolve the mapping of a given EID.
Map-Reply: This message is sent by Map-Servers or ETRs in response Map-Reply: This message is sent by Map-Servers or ETRs in response
to a Map-Request and contains the resolved mapping. Please note to a Map-Request and contains the resolved mapping. Please note
that a Map-Reply may contain a negative reply if, for example, the that a Map-Reply may contain a negative reply if, for example, the
queried EID is not part of the LISP EID space. In such cases the queried EID is not part of the LISP EID space. In such cases the
ITR typically forwards the traffic natively (non encapsulated) to ITR typically forwards the traffic natively (non encapsulated) to
the public Internet, this behavior is defined to support the public Internet, this behavior is defined to support
skipping to change at page 10, line 44 skipping to change at page 10, line 50
(such as MAC addresses), requiring different architectural approaches (such as MAC addresses), requiring different architectural approaches
for scalability. Another important difference between the LISP for scalability. Another important difference between the LISP
control and data-planes is that, and as a result of the local mapping control and data-planes is that, and as a result of the local mapping
cache available at ITR, the Mapping System does not need to operate cache available at ITR, the Mapping System does not need to operate
at line-rate. at line-rate.
The LISP WG has explored application of the following distributed The LISP WG has explored application of the following distributed
system techniques to the Mapping System architecture: graph-based system techniques to the Mapping System architecture: graph-based
databases in the form of LISP+ALT [RFC6836], hierarchical databases databases in the form of LISP+ALT [RFC6836], hierarchical databases
in the form of LISP-DDT [I-D.ietf-lisp-ddt], monolithic databases in in the form of LISP-DDT [I-D.ietf-lisp-ddt], monolithic databases in
the form of LISP-NERD [RFC6837] and flat databases in the form of the form of LISP-NERD [RFC6837], flat databases in the form of LISP-
LISP-DHT [I-D.cheng-lisp-shdht],[I-D.mathy-lisp-dht]. Furthermore it DHT [I-D.cheng-lisp-shdht],[I-D.mathy-lisp-dht] and, a multicast-
is worth noting that, in some scenarios such as private deployments, based database [I-D.curran-lisp-emacs]. Furthermore it is worth
the Mapping System can operate as logically centralized. In such noting that, in some scenarios such as private deployments, the
cases it is typically composed of a single Map-Server/Map-Resolver. Mapping System can operate as logically centralized. In such cases
it is typically composed of a single Map-Server/Map-Resolver.
The following focuses on the two mapping systems that have been The following focuses on the two mapping systems that have been
implemented and deployed (LISP-ALT and LISP+DDT). implemented and deployed (LISP-ALT and LISP+DDT).
3.4.3.1. LISP+ALT 3.4.3.1. LISP+ALT
The LISP Alternative Topology (LISP+ALT) [RFC6836] was the first The LISP Alternative Topology (LISP+ALT) [RFC6836] was the first
Mapping System proposed, developed and deployed on the LISP pilot Mapping System proposed, developed and deployed on the LISP pilot
network. It is based on a distributed BGP overlay participated by network. It is based on a distributed BGP overlay participated by
Map-Servers and Map-Resolvers. The nodes connect to their peers Map-Servers and Map-Resolvers. The nodes connect to their peers
skipping to change at page 13, line 27 skipping to change at page 13, line 27
not announced in the Internet global routing system. As a result not announced in the Internet global routing system. As a result
LISP requires an inetrworking mechanism to allow LISP sites to speak LISP requires an inetrworking mechanism to allow LISP sites to speak
with non-LISP sites and vice versa. LISP inetrworking mechanisms are with non-LISP sites and vice versa. LISP inetrworking mechanisms are
specified in [RFC6832]. specified in [RFC6832].
LISP defines two entities to provide inetrworking: LISP defines two entities to provide inetrworking:
Proxy Ingress Tunnel Router (PITR): PITRs provide connectivity from Proxy Ingress Tunnel Router (PITR): PITRs provide connectivity from
the legacy Internet to LISP sites. PITRs announce in the global the legacy Internet to LISP sites. PITRs announce in the global
routing system blocks of EID prefixes (aggregating when possible) routing system blocks of EID prefixes (aggregating when possible)
to attract traffic. For each incoming data-packet, the PITR LISP- to attract traffic. For each incoming packet from a source not in
encapsulates it towards the RLOC(s) of the appropriate LISP site. a LISP site (a non-EID), the PITR LISP-encapsulates it towards the
The impact of PITRs in the routing table size of the DFZ is, in RLOC(s) of the appropriate LISP site. The impact of PITRs in the
the worst-case, similar to the case in which LISP is not deployed. routing table size of the DFZ is, in the worst-case, similar to
EID-prefixes will be aggregated as much as possible both by the the case in which LISP is not deployed. EID-prefixes will be
PITR and by the global routing system. aggregated as much as possible both by the PITR and by the global
routing system.
Proxy Egress Tunnel Router (PETR): PETRs provide connectivity from Proxy Egress Tunnel Router (PETR): PETRs provide connectivity from
LISP sites to the legacy Internet. In some scenarios, LISP sites LISP sites to the legacy Internet. In some scenarios, LISP sites
may be unable to send encapsulated packets with a local EID may be unable to send encapsulated packets with a local EID
address as a source to the legacy Internet. For instance when address as a source to the legacy Internet. For instance when
Unicast Reverse Path Forwarding (uRPF) is used by Provider Edge Unicast Reverse Path Forwarding (uRPF) is used by Provider Edge
routers, or when an intermediate network between a LISP site and a routers, or when an intermediate network between a LISP site and a
non-LISP site does not support the desired version of IP (IPv4 or non-LISP site does not support the desired version of IP (IPv4 or
IPv6). In both cases the PETR overcomes such limitations by IPv6). In both cases the PETR overcomes such limitations by
encapsulating packets over the network. There is no specified encapsulating packets over the network. There is no specified
skipping to change at page 14, line 23 skipping to change at page 14, line 23
prefix) and contains basically the set of RLOCs with the associated prefix) and contains basically the set of RLOCs with the associated
traffic engineering policies (priorities and weights). traffic engineering policies (priorities and weights).
The Map-Cache, as any other cache, requires cache coherence The Map-Cache, as any other cache, requires cache coherence
mechanisms to maintain up-to-date information. LISP defines three mechanisms to maintain up-to-date information. LISP defines three
main mechanisms for cache coherence: main mechanisms for cache coherence:
Time-To-Live (TTL): Each mapping contains a TTL set by the ETR, upon Time-To-Live (TTL): Each mapping contains a TTL set by the ETR, upon
expiration of the TTL the ITR has to refresh the mapping by expiration of the TTL the ITR has to refresh the mapping by
sending a new Map-Request. Typical values for TTL defined by LISP sending a new Map-Request. Typical values for TTL defined by LISP
are 24h. are 24 hours.
Solicit-Map-Request (SMR): SMR is an explicit mechanism to update Solicit-Map-Request (SMR): SMR is an explicit mechanism to update
mapping information. In particular a special type of Map-Request mapping information. In particular a special type of Map-Request
can be sent on demand by ETRs to request refreshing a mapping. can be sent on demand by ETRs to request refreshing a mapping.
Upon reception of a SMR message, the ITR must refresh the bindings Upon reception of a SMR message, the ITR must refresh the bindings
by sending a Map-Request to the Mapping System. by sending a Map-Request to the Mapping System.
Map-Versioning: This optional mechanism piggybacks in the LISP Map-Versioning: This optional mechanism piggybacks in the LISP
header of data-packets the version number of the mappings used by header of data-packets the version number of the mappings used by
an xTR. This way, when an xTR receives a LISP-encapsulated packet an xTR. This way, when an xTR receives a LISP-encapsulated packet
skipping to change at page 15, line 41 skipping to change at page 15, line 41
determine reachability and, in case of failure, switching to a determine reachability and, in case of failure, switching to a
different locator. Furthermore the mechanism also provides useful different locator. Furthermore the mechanism also provides useful
RTT estimates of the delay of the path that can be used by other RTT estimates of the delay of the path that can be used by other
network algorithms. network algorithms.
Additionally, LISP also recommends inferring reachability of locators Additionally, LISP also recommends inferring reachability of locators
by using information provided by the underlay, in particular: by using information provided by the underlay, in particular:
It is worth noting that RLOC probing and Echo-nonce can work It is worth noting that RLOC probing and Echo-nonce can work
together. Specifically if a nonce is not echoed, an ITR could RLOC- together. Specifically if a nonce is not echoed, an ITR could RLOC-
probe to determine if the path is up because the return bidirectional probe to determine if the path is up when it cannot tell the
path may have failed or the return path is not used, that is there is difference between a failed bidirectional path or the return path is
only a unidirectional path. not used (a unidirectional path).
ICMP signaling: The LISP underlay -the current Internet- uses the ICMP signaling: The LISP underlay -the current Internet- uses the
ICMP protocol to signal unreachability (among other things). LISP ICMP protocol to signal unreachability (among other things). LISP
can take advantage of this and the reception of a ICMP Network can take advantage of this and the reception of a ICMP Network
Unreachable or ICMP Host Unreachable message can be seen as a hint Unreachable or ICMP Host Unreachable message can be seen as a hint
that a locator might be unreachable, this should lead to perform that a locator might be unreachable, this should lead to perform
additional checks. additional checks.
Underlay routing: Both BGP and IBGP carry reachability information, Underlay routing: Both BGP and IBGP carry reachability information,
LISP-capable routers that have access to underlay routing information LISP-capable routers that have access to underlay routing information
skipping to change at page 17, line 6 skipping to change at page 17, line 6
The separation between locators and identifiers in LISP was initially The separation between locators and identifiers in LISP was initially
proposed for traffic engineering purpose where LISP sites can change proposed for traffic engineering purpose where LISP sites can change
their attachment points to the Internet (i.e., RLOCs) without their attachment points to the Internet (i.e., RLOCs) without
impacting endpoints or the Internet core. In this context, the impacting endpoints or the Internet core. In this context, the
border routers operate the xTR functionality and endpoints are not border routers operate the xTR functionality and endpoints are not
aware of the existence of LISP. However, this mode of operation does aware of the existence of LISP. However, this mode of operation does
not allow seamless mobility of endpoints between different LISP sites not allow seamless mobility of endpoints between different LISP sites
as the EID address might not be routable in a visited site. as the EID address might not be routable in a visited site.
Nevertheless, LISP can be used to enable seamless IP mobility when Nevertheless, LISP can be used to enable seamless IP mobility when
LISP is directly implemented in the endpoint. Each endpoint is then LISP is directly implemented in the endpoint or when the endpoint
an xTR and the EID address is the one presented to the network stack roams to an attached xTR. Each endpoint is then an xTR and the EID
used by applications while the RLOC is the address gathered from the address is the one presented to the network stack used by
network when it is visited. applications while the RLOC is the address gathered from the network
when it is visited.
Whenever the device changes of RLOC, the ITR updates the RLOC of its Whenever the device changes of RLOC, the xTR updates the RLOC of its
local mapping and registers it to its Map-Server. To avoid the need local mapping and registers it to its Map-Server. To avoid the need
of a home gateway, the ITR also indicates the RLOC change to all of a home gateway, the ITR also indicates the RLOC change to all
remote devices that have ongoing communications with the device that remote devices that have ongoing communications with the device that
moved. The combination of both methods ensures the scalability of moved. The combination of both methods ensures the scalability of
the system as signaling is strictly limited the Map-Server and to the system as signaling is strictly limited the Map-Server and to
hosts with which communications are ongoing. hosts with which communications are ongoing.
6. Multicast 6. Multicast
LISP also supports transporting IP multicast packets sent from the LISP also supports transporting IP multicast packets sent from the
EID space, the operational changes required to the multicast EID space, the operational changes required to the multicast
protocols are documented in [RFC6831]. protocols are documented in [RFC6831].
In such scenarios, LISP may create multicast state both at the core In such scenarios, LISP may create multicast state both at the core
and at the sites (both source and receiver). When signaling is used and at the sites (both source and receiver). When signaling is used
create multicast state at the sites, LISP routers unicast encapsulate to create multicast state at the sites, LISP routers unicast
PIM Join/Prune messages from receiver to source sites. At the core, encapsulate PIM Join/Prune messages from receiver to source sites.
ETRs build a new PIM Join/Prune message addressed to the RLOC of the At the core, ETRs build a new PIM Join/Prune message addressed to the
ITR servicing the source. An simplified sequence is shown below RLOC of the ITR servicing the source. An simplified sequence is
shown below
1. An end-host willing to join a multicast channel sends an IGMP 1. An end-host willing to join a multicast channel sends an IGMP
report. Multicast PIM routers at the LISP site propagate PIM report. Multicast PIM routers at the LISP site propagate PIM
Join/Prune messages (S-EID, G) towards the ETR. Join/Prune messages (S-EID, G) towards the ETR.
2. The join message flows to the ETR, upon reception the ETR builds 2. The join message flows to the ETR, upon reception the ETR builds
two join messages, the first one unicast LISP-encapsulates the two join messages, the first one unicast LISP-encapsulates the
original join message towards the RLOC of the ITR servicing the original join message towards the RLOC of the ITR servicing the
source. This message creates multicast state at the source site. source. This message creates (S-EID, G) multicast state at the
The second join message contains as destination address the RLOC source site. The second join message contains as destination
of the ITR servicing the source (S-RLOC, G) and creates multicast address the RLOC of the ITR servicing the source (S-RLOC, G) and
state at the core. creates multicast state at the core.
3. Multicast data packets originated by the source (S-EID, G) flow 3. Multicast data packets originated by the source (S-EID, G) flow
from the source to the ITR. The ITR LISP-encapsulates the from the source to the ITR. The ITR LISP-encapsulates the
multicast packets, the outter header includes its own RLOC as the multicast packets, the outter header includes its own RLOC as the
source (S-RLOC) and the original multicast group address (G) as source (S-RLOC) and the original multicast group address (G) as
the destination. Please note that multicast group address are the destination. Please note that multicast group address are
logical and are not resolved by the mapping system. Then the logical and are not resolved by the mapping system. Then the
multicast packet is transmitted through the core towards the multicast packet is transmitted through the core towards the
receiving ETRs that decapsulates the packets and sends them using receiving ETRs that decapsulates the packets and sends them using
the receiver's site multicast state. the receiver's site multicast state.
LISP also support non-PIM mechanisms to maintain multicast state. LISP can also support non-PIM mechanisms to maintain multicast state.
7. Security 7. Security
LISP uses a pull architecture to learn mappings. While in a push LISP uses a pull architecture to learn mappings. While in a push
system, the state necessary to forward packets is learned system, the state necessary to forward packets is learned
independently of the traffic itself, with a pull architecture, the independently of the traffic itself, with a pull architecture, the
system becomes reactive and data-plane events (e.g., the arrival of a system becomes reactive and data-plane events (e.g., the arrival of a
packet for an unknown destination) may trigger control-plane events. packet for an unknown destination) may trigger control-plane events.
This on-demand learning of mappings provides many advantages as This on-demand learning of mappings provides many advantages as
discussed above but may also affect the way security is enforced. discussed above but may also affect the way security is enforced.
Usually, the data-plane is implemented in the fast path of routers to Usually, the data-plane is implemented in the fast path of routers to
provide high performance forwarding capabilities while the control- provide high performance forwarding capabilities while the control-
plane features are implemented in the slow path to offer high plane features are implemented in the slow path to offer high
flexibility and a performance gap of several order of magnitude can flexibility and a performance gap of several order of magnitude can
be observed between the slow and the fast paths. As a consequence, be observed between the slow and the fast paths. As a consequence,
the way data-plane events are notified to the control-plane must be the way data-plane events are notified to the control-plane must be
though carefully so to not overload the slow path and rate limiting thought carefully so to not overload the slow path and rate limiting
should be used as specified in [RFC6830]. should be used as specified in [RFC6830].
Care must also be taken so to not overload the mapping system (i.e., Care must also be taken so to not overload the mapping system (i.e.,
the control plane infrastructure) as the operations to be performed the control plane infrastructure) as the operations to be performed
by the mapping system may be more complex than those on the data- by the mapping system may be more complex than those on the data-
plane, for that reason [RFC6830] recommends to rate limit the sending plane, for that reason [RFC6830] recommends to rate limit the sending
of messages to the mapping system. of messages to the mapping system.
To improve resiliency and reduce the overall number of messages To improve resiliency and reduce the overall number of messages
exchanged, LISP offers the possibility to leak control informations, exchanged, LISP offers the possibility to leak information, such as
such as reachabilty of locators, directly into data plane packets. reachabilty of locators, directly into data plane packets. In
In environments that are not fully trusted, control informations environments that are not fully trusted, control informations gleaned
gleaned from data-plane packets should be verified before using them. from data-plane packets should be verified before using them.
Mappings are the centrepiece of LISP and all precautions must be Mappings are the centrepiece of LISP and all precautions must be
taken to avoid them to be manipulated or misused by malicious taken to avoid them to be manipulated or misused by malicious
entities. Using trustable Map-Servers that strictly respect entities. Using trustable Map-Servers that strictly respect
[RFC6833] and the lightweight authentication mechanism proposed by [RFC6833] and the lightweight authentication mechanism proposed by
LISP-Sec [I-D.ietf-lisp-sec] reduces the risk of attacks to the LISP-Sec [I-D.ietf-lisp-sec] reduces the risk of attacks to the
mapping integrity. In more critical environments, secure measures mapping integrity. In more critical environments, secure measures
may be needed. may be needed.
As with any other tunneling mechanism, middleboxes on the path As with any other tunneling mechanism, middleboxes on the path
skipping to change at page 19, line 22 skipping to change at page 19, line 25
8.1. Traffic Engineering 8.1. Traffic Engineering
BGP is the standard protocol to implement inter-domain routing. With BGP is the standard protocol to implement inter-domain routing. With
BGP, routing informations are propagated along the network and each BGP, routing informations are propagated along the network and each
autonomous system can implement its own routing policy that will autonomous system can implement its own routing policy that will
influence the way routing information are propagated. The direct influence the way routing information are propagated. The direct
consequence is that an autonomous system cannot precisely control the consequence is that an autonomous system cannot precisely control the
way the traffic will enter the network. way the traffic will enter the network.
As opposed to BGP, a LISP site can strictly impose via which ETRs the As opposed to BGP, a LISP site can strictly impose via which ETRs the
traffic must enter the network even though the path followed to reach traffic must enter the the LISP site network even though the path
the ETR is not under the control of the LISP site. This fine control followed to reach the ETR is not under the control of the LISP site.
is implemented with the mappings. When a remote site is willing to This fine control is implemented with the mappings. When a remote
send traffic to a LISP site, it retrieves the mapping associated to site is willing to send traffic to a LISP site, it retrieves the
the destination EID via the mapping system. The mapping is sent mapping associated to the destination EID via the mapping system.
directly by an authoritative ETR of the EID and is not altered by any The mapping is sent directly by an authoritative ETR of the EID and
intermediate network. is not altered by any intermediate network.
A mapping associates a list of RLOCs to an EID prefix. Each RLOC A mapping associates a list of RLOCs to an EID prefix. Each RLOC
corresponds to an interface of an ETR that is able to correctly corresponds to an interface of an ETR (or set of ETRs) that is able
forward packets to EIDs in the prefix. Each RLOC is tagged with a to correctly forward packets to EIDs in the prefix. Each RLOC is
priority and a weight in the mapping. The priority is used to tagged with a priority and a weight in the mapping. The priority is
indicates which RLOCs should be preferred to send packets (the least used to indicates which RLOCs should be preferred to send packets
preferred ones being provided for backup purpose). The weight (the least preferred ones being provided for backup purpose). The
permits to balance the load between the RLOCs with the same priority, weight permits to balance the load between the RLOCs with the same
proportionally to the weight value. priority, proportionally to the weight value.
As mappings are directly issued by the authoritative ETR of the EID As mappings are directly issued by the authoritative ETR of the EID
and are not altered while transmitted to the remote site, it offers and are not altered while transmitted to the remote site, it offers
highly flexible incoming inter-domain traffic engineering with even highly flexible incoming inter-domain traffic engineering with even
the possibility for a site to issue a different mapping for each the possibility for a site to issue a different mapping for each
remote site, implementing so precise routing policies. remote site, implementing so precise routing policies.
8.2. LISP for IPv6 Co-existence 8.2. LISP for IPv6 Co-existence
LISP encapsulations permits to transport packets using EIDs from a LISP encapsulations permits to transport packets using EIDs from a
given address family (e.g., IPv6) with packets with addresses given address family (e.g., IPv6) with packets from other address
belonging to another address family (e.g., IPv4). The absence of families (e.g., IPv4). The absence of correlation between the
correlation between the address family of RLOCs and EIDs makes LISP a address family of RLOCs and EIDs makes LISP a candidate to allow,
candidate to allow, e.g., IPv6 to be deployed when all of the core e.g., IPv6 to be deployed when all of the core network may not have
network may not have IPv6 enabled. IPv6 enabled.
For example, two IPv6-only data centers could be interconnected via For example, two IPv6-only data centers could be interconnected via
the legacy IPv4 Internet. If their border routers are LISP capable, the legacy IPv4 Internet. If their border routers are LISP capable,
sending packets between the data center is done without any form of sending packets between the data center is done without any form of
translation as the native IPv6 packets (in the EID space) will be translation as the native IPv6 packets (in the EID space) will be
LISP encapsulated and transmitted over the IPv4 legacy Internet by LISP encapsulated and transmitted over the IPv4 legacy Internet by
the mean of IPv4 RLOCs. the mean of IPv4 RLOCs.
8.3. LISP for Virtual Private Networks 8.3. LISP for Virtual Private Networks
It is common to operate several virtual networks over the same It is common to operate several virtual networks over the same
physical infrastructure. In such virtual private networks, it is physical infrastructure. In such virtual private networks, it is
essential to distinguish to which virtual network a packet belongs essential to distinguish which virtual network a packet belongs and
and tags or labels are used for that purpose. With LISP, the tags or labels are used for that purpose. With LISP, the distinction
distinction can be made with the Instance ID field. When an ITR can be made with the Instance ID field. When an ITR encapsulates a
encapsulates a packet from a particular virtual network (e.g., known packet from a particular virtual network (e.g., known via the VRF or
via the VRF or VLAN), it tags the encapsulated packet with the VLAN), it tags the encapsulated packet with the Instance ID
Instance ID corresponding to the virtual network of the packet. When corresponding to the virtual network of the packet. When an ETR
an ETR receives a packet tagged with an Instance ID it uses the receives a packet tagged with an Instance ID it uses the Instance ID
Instance ID to determine how to treat the packet. to determine how to treat the packet.
The main advantage of using LISP for virtual networks, on top of the The main advantage of using LISP for virtual networks, on top of the
simplicity of managing the mappings, is that it does not impose any simplicity of managing the mappings, is that it does not impose any
requirement on the underlying network, as long as it is running IP. requirement on the underlying network, as long as it is running IP.
8.4. LISP for Virtual Machine Mobility in Data Centers 8.4. LISP for Virtual Machine Mobility in Data Centers
A way to enable seamless virtual machine mobility in data center is A way to enable seamless virtual machine mobility in data center is
to conceive the datacenter backbone as the RLOC space and the subnet to conceive the datacenter backbone as the RLOC space and the subnet
where servers are hosted as forming the EID space. A LISP router is where servers are hosted as forming the EID space. A LISP router is
placed at the border between the backbone and each subnet. When a placed at the border between the backbone and each subnet. When a
virtual machine is moved to another subnet, it can (temporarily) keep virtual machine is moved to another subnet, it can keep (temporarily)
the address of the subnet it was hosted before the move so to allow the address it had before the move so to continue without a transport
ongoing communications to subsist. When a subnet detects the layer connection reset. When an xTR detects a source address
presence of a host with an address that does not belong to the subnet received on a subnet to be an address not assigned to the subnet, it
(e.g., via a message sent by the hypervisor or traffic inspection), registers the address to the Mapping System.
the LISP router of the new subnet registers the IP address of the
virtual machine as an EID to the Map-Server of the subnet and
associates its own address as RLOC.
To inform the other LISP routers that the machine moved and where, To inform the other LISP routers that the machine moved and where,
and then to avoid detours via the initial subnetwork, mechanisms such and then to avoid detours via the initial subnetwork, mechanisms such
as the Solicit-Map-Request messages are used. as the Solicit-Map-Request messages are used.
9. Security Considerations 9. Security Considerations
This document does not specify any protocol or operational practices This document does not specify any protocol or operational practices
and hence, does not have any security considerations. and hence, does not have any security considerations.
skipping to change at page 22, line 34 skipping to change at page 22, line 34
[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
Routing Locator (RLOC) Database", RFC 6837, January 2013. Routing Locator (RLOC) Database", RFC 6837, January 2013.
[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
UDP Checksums for Tunneled Packets", RFC 6935, April 2013. UDP Checksums for Tunneled Packets", RFC 6935, April 2013.
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement
for the Use of IPv6 UDP Datagrams with Zero Checksums", for the Use of IPv6 UDP Datagrams with Zero Checksums",
RFC 6936, April 2013. RFC 6936, April 2013.
[RFC7052] Schudel, G., Jain, A., and V. Moreno, "Locator/ID
Separation Protocol (LISP) MIB", RFC 7052, October 2013.
[RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
Pascual, J., and D. Lewis, "Locator/Identifier Separation Pascual, J., and D. Lewis, "Locator/Identifier Separation
Protocol (LISP) Network Element Deployment Protocol (LISP) Network Element Deployment
Considerations", RFC 7215, April 2014. Considerations", RFC 7215, April 2014.
12.2. Informative References 12.2. Informative References
[Chiappa] Chiappa, J., "Endpoints and Endpoint names: A Propose [Chiappa] Chiappa, J., "Endpoints and Endpoint names: A Propose
Enhancement to the Internet Architecture, Enhancement to the Internet Architecture,
http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt", 1999. http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt", 1999.
skipping to change at page 23, line 10 skipping to change at page 23, line 10
LISP DDT ROOT, , "http://ddt-root.org/", August 2013. LISP DDT ROOT, , "http://ddt-root.org/", August 2013.
[DFZ] Huston, Geoff., "Growth of the BGP Table - 1994 to Present [DFZ] Huston, Geoff., "Growth of the BGP Table - 1994 to Present
http://bgp.potaroo.net/", August 2013. http://bgp.potaroo.net/", August 2013.
[I-D.cheng-lisp-shdht] [I-D.cheng-lisp-shdht]
Cheng, L. and J. Wang, "LISP Single-Hop DHT Mapping Cheng, L. and J. Wang, "LISP Single-Hop DHT Mapping
Overlay", draft-cheng-lisp-shdht-04 (work in progress), Overlay", draft-cheng-lisp-shdht-04 (work in progress),
July 2013. July 2013.
[I-D.curran-lisp-emacs]
Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID
Mappings Multicast Across Cooperating Systems for LISP",
draft-curran-lisp-emacs-00 (work in progress), November
2007.
[I-D.ietf-lisp-ddt] [I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
Delegated Database Tree", draft-ietf-lisp-ddt-02 (work in Delegated Database Tree", draft-ietf-lisp-ddt-02 (work in
progress), October 2014. progress), October 2014.
[I-D.ietf-lisp-lcaf] [I-D.ietf-lisp-lcaf]
Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", draft-ietf-lisp-lcaf-06 (work in Address Format (LCAF)", draft-ietf-lisp-lcaf-06 (work in
progress), October 2014. progress), October 2014.
 End of changes. 43 change blocks. 
112 lines changed or deleted 131 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/