draft-ietf-lisp-introduction-05.txt   draft-ietf-lisp-introduction-06.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: March 26, 2015 INRIA Expires: April 26, 2015 INRIA
September 22, 2014 October 23, 2014
An Architectural Introduction to the LISP Location-Identity Separation An Architectural Introduction to the Locator/ID Separation Protocol
System (LISP)
draft-ietf-lisp-introduction-05.txt draft-ietf-lisp-introduction-06.txt
Abstract Abstract
This document describes the Locator/ID Separation Protocol (LISP) This document describes the architecture of the Locator/ID Separation
architecture, its main operational mechanisms as well as its design Protocol (LISP), making it easier to read the rest of the LISP
rationale. specifications and providing a basis for discussion about the details
of the LISP protocols. This document is used for introductory
purposes, more details can be found in RFC6830, the protocol
specification.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 40 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 March 26, 2015. This Internet-Draft will expire on April 26, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. LISP Architecture . . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
2.1. Design Principles . . . . . . . . . . . . . . . . . . . . 4 3. LISP Architecture . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Overview of the Architecture . . . . . . . . . . . . . . 4 3.1. Design Principles . . . . . . . . . . . . . . . . . . . . 4
2.3. Data-Plane . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Overview of the Architecture . . . . . . . . . . . . . . 4
2.3.1. LISP encapsulation . . . . . . . . . . . . . . . . . 7 3.3. Data-Plane . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.2. LISP Forwarding State . . . . . . . . . . . . . . . . 8 3.3.1. LISP Encapsulation . . . . . . . . . . . . . . . . . 7
2.4. Control-Plane . . . . . . . . . . . . . . . . . . . . . . 9 3.3.2. LISP Forwarding State . . . . . . . . . . . . . . . . 8
2.4.1. LISP Mappings . . . . . . . . . . . . . . . . . . . . 9 3.4. Control-Plane . . . . . . . . . . . . . . . . . . . . . . 8
2.4.2. Mapping System Interface . . . . . . . . . . . . . . 9 3.4.1. LISP Mappings . . . . . . . . . . . . . . . . . . . . 9
2.4.3. Mapping System . . . . . . . . . . . . . . . . . . . 10 3.4.2. Mapping System Interface . . . . . . . . . . . . . . 9
2.5. Internetworking Mechanisms . . . . . . . . . . . . . . . 13 3.4.3. Mapping System . . . . . . . . . . . . . . . . . . . 10
3. LISP Operational Mechanisms . . . . . . . . . . . . . . . . . 13 3.5. Interworking Mechanisms . . . . . . . . . . . . . . . . . 13
3.1. Cache Management . . . . . . . . . . . . . . . . . . . . 14 4. LISP Operational Mechanisms . . . . . . . . . . . . . . . . . 13
3.2. RLOC Reachability . . . . . . . . . . . . . . . . . . . . 14 4.1. Cache Management . . . . . . . . . . . . . . . . . . . . 14
3.3. ETR Synchronization . . . . . . . . . . . . . . . . . . . 15 4.2. RLOC Reachability . . . . . . . . . . . . . . . . . . . . 14
3.4. MTU Handling . . . . . . . . . . . . . . . . . . . . . . 16 4.3. ETR Synchronization . . . . . . . . . . . . . . . . . . . 16
4. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.4. MTU Handling . . . . . . . . . . . . . . . . . . . . . . 16
5. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 18 8. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.2. LISP for IPv6 Transition . . . . . . . . . . . . . . . . 19 8.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 19
7.3. LISP for Network Virtualization . . . . . . . . . . . . . 19 8.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . 19
7.4. LISP for Virtual Machine Mobility in Data Centers . . . . 20 8.3. LISP for Virtual Private Networks . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8.4. LISP for Virtual Machine Mobility in Data Centers . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . 22 12.1. Normative References . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. A Brief History of Location/Identity Separation . . 23 Appendix A. A Brief History of Location/Identity Separation . . 23
A.1. Old LISP Models . . . . . . . . . . . . . . . . . . . . . 24 A.1. Old LISP Models . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
There is a rough consensus that the Internet routing and addressing This document introduces the Locator/ID Separation Protocol (LISP)
system is facing severe scalability issues [RFC4984]. Specifically, [RFC6830] architecture, its main operational mechanisms and its
the growth in the size of the routing tables of the Default-Free Zone design rationale. Fundamentally, LISP is built following a well-
(DFZ) is accelerating and showing a supra-linear slope [DFZ]. The known architectural idea: decoupling the IP address overloaded
main driving force behind this growth is the de-aggregation of BGP semantics. Indeed and as pointed out by [Chiappa], currently IP
prefixes, which results from the existing BGP multihoming and traffic addresses both identify the topological location of a network
engineering mechanisms that are used -at the time of this writing- on attachment point as well as the node's identity. However, nodes and
the Internet, as well as non-aggregatable address allocations. routing have fundamentally different requirements, routing systems
require that addresses are aggregatable and have topological meaning,
This issue has two profound implications, on the one hand Internet while nodes require to be identified independently of their current
core routers are exposed to the network dynamics of the edge. For location [RFC4984].
instance this typically leads to an increased amount of BGP UPDATE
messages (churn), which results in additional processing requirements
of Internet core routers in order to timely compute the DFZ RIB.
Secondly, the supra-linear growth imposes strong requirements on the
size of the memory storing the DFZ FIB. Both aspects lead to an
increase on the development and production cost of high-end routers,
and it is unclear if the semiconductor and router manufacturer
industries will be able to cope, in the long-term, with such
stringent requirements in a cost-effective way[RFC4984].
Although this important scalability issue is relatively new, the LISP creates two separate namespaces, EIDs (End-host IDentifiers) and
architectural reasons behind it are well-known many years ago. RLOCs (Routing LOCators), both are typically syntactically identical
Indeed, and as pointed out by [Chiappa], IP addresses have overloaded to the current IPv4 and IPv6 addresses. EIDs are used to uniquely
semantics. Currently, IP addresses both identify the topological identify nodes irrespective of their topological location and are
location of a network attachment point as well as the node's typically routed intra-domain. RLOCs are assigned topologically to
identity. However, nodes and routing have fundamentally different network attachment points and are typically routed inter-domain.
requirements, routing systems require that addresses are aggregatable With LISP, the edge of the Internet (where the nodes are connected)
and have topological meaning, while nodes require to be identified and the core (where inter-domain routing occurs) can be logically
independently of their current location. separated and interconnected by LISP-capable routers. LISP also
introduces a database, called the Mapping System, to store and
retrieve mappings between identity and location. LISP-capable
routers exchange packets over the Internet core by encapsulating them
to the appropriate location.
The Locator/ID Separation Protocol (LISP), specified in [RFC6830], is By taking advantage of such separation between location and identity
built on top of this basic idea: decoupling the IP address overloaded LISP offers Traffic Engineering, multihoming, and mobility among
semantics. LISP creates two separate namespaces, EIDs (End-host others benefits. Additionally, LISP's approach to solve the routing
IDentifiers) and RLOCs (Routing LOCators), both are -typically, but scalability problem [RFC4984] is that with LISP the Internet core is
not limited to- syntactically identical to the current IPv4 and IPv6 populated with RLOCs while Traffic Engineering mechanisms are pushed
addresses. EIDs are used to uniquely identify nodes irrespective of to the Mapping System. With this RLOCs are quasi-static (i.e., low
their topological location and are typically routed intra-domain. churn) and hence, the routing system scalable [Quoitin].
RLOCs are assigned topologically to network attachment points and are
typically routed inter-domain. With LISP, the edge of the Internet
-where the nodes are connected- and the core -where inter-domain
routing occurs- are architecturally separated and interconnected by
LISP-capable routers. LISP also introduces a publicly accessible
database, called the Mapping System, to store and retrieve mappings
between identity and location. LISP-capable routers exchange packets
over the Internet core by encapsulating them to the appropriate
location. By taking advantage of such separation between location
and identity, the Internet core is populated with RLOCs which can be
quasi-static and highly aggregatable, hence scalable [Quoitin].
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] for the protocol
specifications along with the LISP deployment guidelines [RFC7215]. specifications along with the LISP deployment guidelines [RFC7215].
2. LISP Architecture 2. Definition of Terms
This section presents the LISP architecture, we first detail the This document describes the LISP architecture and does not define or
design principles of LISP and then we proceed to describe its main introduce any new term. The reader is referred to
aspects: data-plane, control-plane, and internetworking mechanisms. [RFC6830],[RFC6831],[RFC6832],[RFC6833],[RFC6834],[RFC6835],
[RFC6836],[RFC7215] for the LISP definition of terms.
2.1. Design Principles 3. LISP Architecture
This section presents the LISP architecture, it first details the
design principles of LISP and then it proceeds to describe its main
aspects: data-plane, control-plane, and inetrworking mechanisms.
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 with of the current IP addresses the Internet core can be assigned
topological meaningful address and hence, can use aggregation to identity meaningful addresses and hence, can use aggregation to
scale. Devices are assigned with identity meaningful address that scale. Devices are assigned with identity meaningful addresses
are independent of its topological location. 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 to deploy new protocols without changing the Internet, allowing deployment of new protocols without changing
current infrastructure hence, resulting from 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.
o Incremental deployability: This principle ensures that the o Incremental deployability: This principle ensures that the
protocol is compatible 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.
2.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 are LISP sites (e.g., an Routing LOCators (RLOC). 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
endhosts and are assigned and configured by the same mechanisms that communication end-hosts and are assigned and configured by the same
we have at the time of this writing. EIDs can be are typically mechanisms that exist at the time of this writing. EIDs do not
Provider Independent (PI [RFC4116]) addresses and can be thought as contain inter-domain topological information and can be thought as an
they don't contain intra-domain topological information. Because of analogy to Provider Independent (PI [RFC4116]) addresses. Because of
this, EIDs are usually only routable in the edge. this, EIDs are usually only routable at the edge.
With LISP, LISP sites (edge) and the core of the Internet are inter- With LISP, LISP sites (edge) and the core of the Internet are
connected by means of LISP-capable routers (e.g., border routers). interconnected by means of LISP-capable routers (e.g., border
When they provide egress (from the core perspective) to a LISP site routers) using tunnels. When packets originated from a LISP site are
they are called Egress Tunnel Routers (ETR), Ingress Tunnel Routers flowing towards the core network, they ingress into an encapsulated
(ITR) when they provide ingress, and xTR when they provide both. tunnel via an Ingress Tunnel Router (ITR). When packets flow from
ITRs and ETRs exchange packets by encapsulating them, hence LISP the core network to a LISP site, they egress from an encapsulated
operates as an overlay to the current Internet core. tunnel to an Egress Tunnel Router (ETR). An xTR is a router with can
perform both ITR and ETR operations. In this context ITRs
encapsulate packets while ETRs decapsulate them, hence LISP operates
as an overlay to the current Internet core.
/-----------------\ --- /-----------------\ ---
| Mapping | | | Mapping | |
. System | | Control . System | | Control
-| |`, | Plane -| |`, | Plane
,' \-----------------/ . | ,' \-----------------/ . |
/ \ --- / \ ---
,.., - _,..--..,, `, ,.., | ,.., - _,..--..,, `, ,.., |
/ ` ,' ,-` `', . / ` | / ` ,' ,-` `', . / ` |
/ \ +-----+ ,' `, +--'--+ / \ | / \ +-----+ ,' `, +--'--+ / \ |
skipping to change at page 6, line 5 skipping to change at page 5, line 45
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 though as
Provider Aggregatable addresses [RFC4116]. Provider Aggregatable addresses [RFC4116].
A publicly accessible and usually distributed database, called the A typically distributed database, called the Mapping System, stores
Mapping System, stores mappings between EIDs and RLOCs. Such mappings between EIDs and RLOCs. Such mappings relate the identity
mappings relate the identity of the devices attached to LISP sites of the devices attached to LISP sites (EIDs) to the set of RLOCs
(EIDs) to the set of RLOCs configured at the LISP-capable routers configured at the LISP-capable routers servicing the site.
servicing the site. Furthermore, the mappings also include traffic Furthermore, the mappings also include traffic engineering policies
engineering policies and can be configured to achieve multihoming and and can be configured to achieve multihoming and load balancing. The
load balancing. The LISP Mapping System can be thought as the LISP Mapping System is conceptually similar to the DNS that would be
equivalent of a DNS that would be accessed by ETRs to register accessed by ETRs to register mappings and by ITRs to retrieve them.
mappings and by ITRs to retrieve them.
Finally, the LISP architecture has a strong emphasis in cost Finally, the LISP architecture emphasizes a cost effective
effective incremental deployment. Given that LISP represents an incremental deployment. Given that LISP represents an overlay to the
overlay to the current Internet architecture, endhosts as well as current Internet architecture, endhosts as well as intra and inter-
intra and inter-domain routers remain unchanged, and the only domain routers remain unchanged, and the only required changes to the
required changes to the existing infrastructure are to routers existing infrastructure are to routers connecting the EID with the
connecting the EID with the RLOC space. Such LISP capable routers RLOC space. Such LISP capable routers, in most cases, only require a
typically require only a software upgrade. Additionally, LISP software upgrade. Additionally, LISP requires the deployment of an
requires the deployment of an independent Mapping System, this independent Mapping System, such distributed database is a new
distributed database is a new network entity. network entity.
In what follows we describe a simplified packet flow sequence between The following describes a simplified packet flow sequence between two
two nodes that are attached to LISP sites. Client hostA wants to nodes that are attached to LISP sites. Client hostA wants to send a
send a packt to server hostB. packet to server hostB.
/----------------\ /----------------\
| Mapping | | Mapping |
| System | | System |
.| |- .| |-
` \----------------/ `. ` \----------------/ `.
,` \ ,` \
/ `. / `.
,' _,..-..,, ', ,' _,..-..,, ',
/ -` `-, \ / -` `-, \
skipping to change at page 7, line 13 skipping to change at page 7, line 9
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. In order retrieve the locator of ETR_B that is servicing hostB's EID_B.
to do so it uses a LISP control message called Map-Request, the In order to do so it uses a LISP control message called Map-
message contains EID_A as the lookup key, in turn it receives Request, the message contains EID_B as the lookup key. In turn
another LISP control message called Map-Reply, the message it receives another LISP control message called Map-Reply, the
contains two locators: RLOC_B1 and RLOC_B2 along with traffic message contains two locators: RLOC_B1 and RLOC_B2 along with
engineering policies: priority and weight per locator. ITR_A traffic engineering policies: priority and weight per locator.
also stores the mapping in a local cache to speed-up forwarding ITR_A also stores the mapping in a local cache to speed-up
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
contains two IP headers, the outer header has RLOC_A1 as source contains two IP headers, the outer header has RLOC_A1 as source
and RLOC_B2 as destination, the inner header has EID_A as source and RLOC_B2 as destination, the inner original header has EID_A
and EID_B as destination. Furthermore ITR_A adds a LISP header, as source and EID_B as destination. Furthermore ITR_A adds a
more details about LISP encapsulation can be found in LISP header, more details about LISP encapsulation can be found
Section 2.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.
2.3. Data-Plane 3.3. Data-Plane
This section describes the LISP data-plane, which is specified in This section provides a high-level description of the LISP data-
[RFC6830]. The LISP data-plane is responsible of encapsulating and plane, which is specified in detail in [RFC6830]. The LISP data-
decapsulating data packets and caching the appropriate forwarding plane is responsible for encapsulating and decapsulating data packets
state. It includes two main entities, the ITR and the ETR, both are and caching the appropriate forwarding state. It includes two main
LISP capable routers that connect the EID with the RLOC space (ITR) entities, the ITR and the ETR, both are LISP capable routers that
and viceversa (ETR). We first describe how packets are LISP- connect the EID with the RLOC space (ITR) and vice versa (ETR).
encapsulated and then we proceed to explain how ITRs cache forwarding
state.
2.3.1. LISP encapsulation 3.3.1. LISP Encapsulation
ITRs encapsulate data packets towards ETRs. LISP data packets are ITRs encapsulate data packets towards ETRs. LISP data packets are
encapsulated using UDP (port 4341). A particularity of LISP is that encapsulated using UDP (port 4341). A particularity of LISP is that
UDP packets should include a zero checksum [RFC6935] [RFC6936] that UDP packets should include a zero checksum [RFC6935] [RFC6936] that
it is not verified in reception, LISP also supports non-zero it is not verified in reception, LISP also supports non-zero
checksums that may be verified. This decision was made because the checksums that may be verified. This decision was made because the
typical transport protocols used by the applications already include typical transport protocols used by the applications already include
a checksum, by neglecting the additional UDP encapsulation checksum a checksum, by neglecting the additional UDP encapsulation checksum
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). The LISP header is prepended by ITRs and striped by ETRs. header and before the original IP header). The LISP header is
It carries reachability information (see more details in Section 3.2) prepended by ITRs and striped by ETRs. It carries reachability
and the Instance ID field. The Instance ID field is used to information (see more details in Section 4.2) and the Instance ID
distinguish traffic that belongs to multiple tenants inside a LISP field. The Instance ID field is used to distinguish traffic to/from
site, and that may use overlapped but logically separated addressing different tenant address spaces at the LISP site and that may use
space. overlapped but logically separated EID addressing.
Overall, LISP encapsulated data packets carry 4 headers [RFC6830] Overall, LISP encapsulated data packets carry 4 headers [RFC6830]
("outer" to "inner"): ("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 may contain reachability information and an 3. LISP header that contains various forwarding-plane features (such
Instance ID field. This header is originated by ITRs and as reachability) and an Instance ID field. This header is
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 addresses. This header is created by the source end-host and is
remains unchanged. left unchanged by LISP data plane processing on the ITR and ETR.
Finally and in some scenarios Recursive and/or Re-encapsulating Finally, in some scenarios Recursive and/or Re-encapsulating tunnels
tunnels can be used for Traffic Engineering and re-routing. Re- can be used for Traffic Engineering and re-routing. Re-encapsulating
encapsulating tunnels are consecutive LISP tunnels and occur when an tunnels are consecutive LISP tunnels and occur when an ETR removes a
ETR removes a LISP header and then acts as an ITR to prepend another LISP header and then acts as an ITR to prepend another one. On the
one. On the other hand, Recursive tunnels are nested tunnels and are other hand, Recursive tunnels are nested tunnels and are implemented
implemented by using multiple LISP encapsulations on a packet. by using multiple LISP encapsulations on a packet. Typically such
functions are implemented by Reencapsulating Tunnel Routers (RTRs).
2.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- to mappings are stored in a local cache -called the Map-Cache- for
increase the forwarding speed of subsequent packets addressed to the subsequent packets addressed to the same EID prefix. Mappings
same EID prefix. Mappings include a (Time-to-Live) TTL (set by the include a (Time-to-Live) TTL (set by the ETR). More details about
ETR) and are expired according to this value, more details about the the Map-Cache management can be found in Section 4.1.
Map-Cache management can be found in Section 3.1.
2.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, query, and retrieve mappings. The LISP interface to register, request, and resolve mappings. The LISP
Mapping System, is a publicly accessible database that stores such Mapping System is a database that stores such mappings. The
mappings. In what follows we first describe the mappings, then the following first describes the mappings, then the standard interface
standard interface, and finally the Mapping System architecture. to the Mapping System, and finally its architecture.
2.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
set of RLOCs, also in the form of IPs. Such addresses are encoded set of RLOCs, also in the form of IPs. IPv4 and IPv6 addresses are
using a general syntax called LISP Canonical Address Format (LCAF), encoded using the appropriate Address Family Identifier (AFI)
specified in [I-D.ietf-lisp-lcaf]. The syntax is general enough to [RFC3232]. However LISP can also support more general address
support encoding of IPv4 and IPv6 addresses and any other type of encoding by means of the ongoing effort around the LISP Canonical
value. Address Format (LCAF) [I-D.ietf-lisp-lcaf].
With such a general syntax for address encoding in place, LISP aims With such a general syntax for address encoding in place, LISP aims
to provide flexibility to current and future applications. For to provide flexibility to current and future applications. For
instance LCAFs could support MAC addresses, geo-coordinates, ASCII instance LCAFs could support MAC addresses, geo-coordinates, ASCII
names and application specific data. names and application specific data.
2.4.2. Mapping System Interface 3.4.2. Mapping System Interface
LISP defines a standard interface between data and control planes. LISP defines a standard interface between data and control planes.
The interface is specified in [RFC6833] and defines two entities: The interface is specified in [RFC6833] and defines two entities:
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 low 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- responses. cases- 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. correct reception of the mapping and convey the latest Map-Server
state on the EID to RLOC mapping.
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 the queried EID that a Map-Reply may contain a negative reply if, for example, the
is not part of the LISP EID space. In such cases the ITR queried EID is not part of the LISP EID space. In such cases the
typically forwards the traffic natively (non encapsulated) to the ITR typically forwards the traffic natively (non encapsulated) to
public Internet. the public Internet, this behavior is defined to support
incremental deployment of LISP.
2.4.3. Mapping System 3.4.3. Mapping System
LISP architecturally decouples control and data-plane by means of a LISP architecturally decouples control and data-plane by means of a
standard interface. This interface glues the data-plane, routers standard interface. This interface glues the data-plane, routers
responsible of forwarding data-packets, with the LISP Mapping System, responsible for forwarding data-packets, with the LISP Mapping
a publicly accessible database responsible of storing mappings. System, a database responsible for storing mappings.
With this separation in place the data and control-plane can use With this separation in place the data and control-plane can use
different architectures if needed and scale independently. Typically different architectures if needed and scale independently. Typically
the data-plane is optimized to route packets according to the data-plane is optimized to route packets according to
hierarchical IP addresses. However the control-plane may have hierarchical IP addresses. However the control-plane may have
different requirements, for instance and by taking advantage of the different requirements, for instance and by taking advantage of the
LCAFs, the Mapping System may be used store non-hierarchical keys LCAFs, the Mapping System may be used to store non-hierarchical keys
(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 discussed for the Mapping System architecture the The LISP WG has explored application of the following distributed
four main techniques available in distributed systems, namely: graph- system techniques to the Mapping System architecture: graph-based
based databases in the form of LISP+ALT [RFC6836], hierarchical databases in the form of LISP+ALT [RFC6836], hierarchical databases
databases in the form of LISP-DDT [I-D.ietf-lisp-ddt], monolithic in the form of LISP-DDT [I-D.ietf-lisp-ddt], monolithic databases in
databases in the form of LISP-NERD [I-D.lear-lisp-nerd] and flat the form of LISP-NERD [RFC6837] and flat databases in the form of
databases in the form of LISP-DHT LISP-DHT [I-D.cheng-lisp-shdht],[I-D.mathy-lisp-dht]. Furthermore it
[I-D.cheng-lisp-shdht],[I-D.mathy-lisp-dht]. Furthermore it is worth is worth noting that, in some scenarios such as private deployments,
noting that, in some scenarios such as private deployments, the the Mapping System can operate as logically centralized. In such
Mapping System can operate logically centralized. In such cases it cases it is typically composed of a single Map-Server/Map-Resolver.
is typically composed of a single Map-Server/Map-Resolver.
In what follows we focus 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).
2.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. All the network. It is based on a distributed BGP overlay participated by
participating nodes connect to their peers through static tunnels. Map-Servers and Map-Resolvers. The nodes connect to their peers
Every ETR involved in the ALT topology advertises its EID prefixes through static tunnels. Each Map-Server involved in the ALT topology
making the EID routable on the overlay. advertises the EID-prefixes registered by the serviced ETRs, making
the EID routable on the ALT topology.
When an ITR needs a mapping, it sends a Map-Request to a nearby ALT When an ITR needs a mapping it sends a Map-Request to a Map-Resolver
router. The ALT routers then forward the Map-Request on the overlay that, using the ALT topology, forwards the Map-Request towards the
by inspecting their ALT routing tables. When the Map-Request reaches Map-Server responsible for the mapping. Upon reception the Map-
the ETR responsible for the mapping, a Map-Reply is generated and Server forwards the request to the ETR that in turn, replies directly
directly sent to the ITR's RLOC, without using the ALT overlay. to the ITR using the native Internet core.
2.4.3.2. LISP-DDT 3.4.3.2. LISP-DDT
LISP-DDT [I-D.ietf-lisp-ddt] is conceptually similar to the DNS, a LISP-DDT [I-D.ietf-lisp-ddt] is conceptually similar to the DNS, a
hierarchical directory whose internal structure mirrors the hierarchical directory whose internal structure mirrors the
hierarchical nature of the EID address space. The DDT hierarchy is hierarchical nature of the EID address space. The DDT hierarchy is
composed of DDT nodes forming a tree structure, the leafs of the tree composed of DDT nodes forming a tree structure, the leafs of the tree
are Map-Servers. On top of the structure there is the DDT root node are Map-Servers. On top of the structure there is the DDT root node
[DDT-ROOT], which is a particular instance of a DDT node and that [DDT-ROOT], which is a particular instance of a DDT node and that
matches the entire address space. As in the case of DNS, DDT matches the entire address space. As in the case of DNS, DDT
supports multiple redundant DDT nodes and/or DDT roots. The supports multiple redundant DDT nodes and/or DDT roots. Finally,
following figure presents a schematic representation of the DDT Map-Resolvers are the clients of the DDT hierarchy and can query
hierarchy. either the DDT root and/or other DDT nodes.
/---------\ /---------\
| | | |
| DDT Root| | DDT Root|
| /0 | | /0 |
,.\---------/-, ,.\---------/-,
,-'` | `'., ,-'` | `'.,
-'` | `- -'` | `-
/-------\ /-------\ /-------\ /-------\ /-------\ /-------\
| DDT | | DDT | | DDT | | DDT | | DDT | | DDT |
| Node | | Node | | Note | ... | Node | | Node | | Note | ...
| 0/8 | | 1/8 | | 2/8 | | 0/8 | | 1/8 | | 2/8 |
\-------/ \-------/ \-------/ \-------/ \-------/ \-------/
_. _. . -..,,,_ _. _. . -..,,,_
-` -` \ ````''-- -` -` \ ````''--
+------------+ +------------+ +------------+ +------------+ +------------+ +------------+ +------------+ +------------+
| Map-Server | | Map-Server | | Map-Server | | Map-Server | | Map-Server | | Map-Server | | Map-Server | | Map-Server |
| EID-prefix1| | EID-prefix2| | EID-prefix3| | EID-prefix4| | EID-prefix1| | EID-prefix2| | EID-prefix3| | EID-prefix4|
+------------+ +------------+ +------------+ +------------+ +------------+ +------------+ +------------+ +------------+
Figre 3.- An schematic representation of the DDT tree structure, Figure 3.- A schematic representation of the DDT tree structure,
please note that the prefixes and the structure depitected please note that the prefixes and the structure depicted
should be only considered as an example. should be only considered as an example.
The DDT structure does not actually index EID-prefixes but eXtended The DDT structure does not actually index EID-prefixes but eXtended
EID-prefixes (XEID). An XEID-prefix is just the concatenation of the EID-prefixes (XEID). An XEID-prefix is just the concatenation of the
following fields (from most significant bit to less significant bit): following fields (from most significant bit to less significant bit):
Database-ID, Instance ID, Address Family Identifier and the actual Database-ID, Instance ID, Address Family Identifier and the actual
EID-prefix. The Database-ID is provided for possible future EID-prefix. The Database-ID is provided for possible future
requirements of higher levels in the hierarchy and to enable the requirements of higher levels in the hierarchy and to enable the
creation of multiple and separate database trees. creation of multiple and separate database trees.
In order to resolve a query LISP-DDT operates iteratively and in a In order to resolve a query LISP-DDT operates in a similar way to the
similar way to the DNS. DDT clients (usually Map-Resolvers) generate DNS but only supports iterative lookups. DDT clients (usually Map-
Map-Requests to the DDT root node. In response they receive a newly Resolvers) generate Map-Requests to the DDT root node. In response
introduced LISP-control message: a Map-Referral. A Map-Referral they receive a newly introduced LISP-control message: a Map-Referral.
provides the list of RLOCs of the set of DDT nodes matching a A Map-Referral provides the list of RLOCs of the set of DDT nodes
configured XEID delegation. That is, the information contained in matching a configured XEID delegation. That is, the information
the Map-Referral points to the child of the queried DDT node that has contained in the Map-Referral points to the child of the queried DDT
more specific information about the queried XEID-prefix. This node that has more specific information about the queried XEID-
process is repeated until the DDT client walks the tree structure prefix. This process is repeated until the DDT client walks the tree
(downwards) and discovers the Map-Server servicing the queried XEID. structure (downwards) and discovers the Map-Server servicing the
At this point the client sends a Map-Request and receives a Map-Reply queried XEID. At this point the client sends a Map-Request and
containing the mappings. It is important to note that DDT clients receives a Map-Reply containing the mappings. It is important to
can also cache the information contained in Map-Referrals, that is, note that DDT clients can also cache the information contained in
they cache the DDT structure. This is used to reduce the mapping Map-Referrals, that is, they cache the DDT structure. This is used
retrieving latency[Jakab]. to reduce the mapping retrieving latency[Jakab].
The DDT Mapping System relies on manual configuration. That is Map- The DDT Mapping System relies on manual configuration. That is Map-
Resolvers are manually configured with the set of available DDT root Resolvers are manually configured with the set of available DDT root
nodes while DDT nodes are manually configured with the appropriate nodes while DDT nodes are manually configured with the appropriate
XEID delegations. Configuration changes in the DDT nodes are only XEID delegations. Configuration changes in the DDT nodes are only
required when the tree structure changes itself, but it doesn't required when the tree structure changes itself, but it doesn't
depend on EID dynamics (RLOC allocation or traffic engineering policy depend on EID dynamics (RLOC allocation or traffic engineering policy
changes). changes).
2.5. Internetworking Mechanisms 3.5. Interworking Mechanisms
EIDs are typically identical to either IPv4 or IPv6 addresses and EIDs are typically identical to either IPv4 or IPv6 addresses and
they are announced at the LISP Mapping System, however they are they are stored in the LISP Mapping System, however they are usually
usually not announced in the Internet global routing system. As a not announced in the Internet global routing system. As a result
result LISP requires an internetworking mechanism to allow LISP sites LISP requires an inetrworking mechanism to allow LISP sites to speak
to speak with non-LISP sites and viceversa. LISP internetworking with non-LISP sites and vice versa. LISP inetrworking mechanisms are
mechanisms are specified in [RFC6832]. specified in [RFC6832].
LISP defines two entities to provide internetworking: 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 data-packet, the PITR LISP-
encapsulates it towards the RLOC(s) of the appropriate LISP site. encapsulates it towards the RLOC(s) of the appropriate LISP site.
The impact of PITRs in the routing table size of the DFZ is, in The impact of PITRs in the routing table size of the DFZ is, in
the worst-case, similar to the case in which LISP is not deployed. the worst-case, similar to the case in which LISP is not deployed.
EID-prefixes will be aggregated as much as possible both by the EID-prefixes will be aggregated as much as possible both by the
PITR and by the global routing system. PITR and by the global routing system.
Proxy Engress 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 to the legacy Internet. may be unable to send encapsulated packets with a local EID
For instance when Unicast Reverse Path Forwarding (uRPF) is used address as a source to the legacy Internet. For instance when
by Provider Edge routers, or when an intermediate network between Unicast Reverse Path Forwarding (uRPF) is used by Provider Edge
a LISP site and a non-LISP site does not support the desired routers, or when an intermediate network between a LISP site and a
version of IP (IPv4 or IPv6). In both cases the PETR allows to non-LISP site does not support the desired version of IP (IPv4 or
overcome such limitations by encapsulating packets over the IPv6). In both cases the PETR overcomes such limitations by
network. Finally, the RLOC of PETRs must be statically configured encapsulating packets over the network. There is no specified
in ITRs. provision for the distribution of PETR RLOC addresses to the ITRs.
3. LISP Operational Mechanisms 4. LISP Operational Mechanisms
In this section we detail the main operational mechanisms defined in This section details the main operational mechanisms defined in LISP.
LISP.
3.1. Cache Management 4.1. Cache Management
LISP's decoupled control and data-plane, where mappings are stored in LISP's decoupled control and data-plane, where mappings are stored in
the control-plane and used for forwarding in the data plane, requires the control-plane and used for forwarding in the data plane, requires
of a local cache in ITRs to reduce signaling overhead (Map-Request/ of a local cache in ITRs to reduce signaling overhead (Map-Request/
Map-Reply) and increase forwarding speed. The local cache available Map-Reply) and increase forwarding speed. The local cache available
at the ITRs, called Map-Cache, is used by the router to LISP- at the ITRs, called Map-Cache, is used by the router to LISP-
encapsulate packets. The Map-Cache is indexed by (Instance ID, EID- encapsulate packets. The Map-Cache is indexed by (Instance ID, EID-
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 could refresh the mapping by sending expiration of the TTL the ITR has to refresh the mapping by
a new Map-Request. Typical values for TTL defined by LISP are sending a new Map-Request. Typical values for TTL defined by LISP
24h. are 24h.
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
from a remote xTR, it can check whether its own Map-Cache or the from a remote xTR, it can check whether its own Map-Cache or the
one of the remote xTR is outdated. If its Map-Cache is outdated, one of the remote xTR is outdated. If its Map-Cache is outdated,
it sends a Map-Request for the remote EID so to obtain the newest it sends a Map-Request for the remote EID so to obtain the newest
mappings. On the contrary, if it detects that the remote xTR Map- mappings. On the contrary, if it detects that the remote xTR Map-
Cache is outdated, it sends it a SMR to notify it that a new Cache is outdated, it sends a SMR to notify it that a new mapping
mapping is available. is available.
3.2. RLOC Reachability Finally it is worth noting that in some cases an entry in the map-
cache can be proactively refreshed using the mechanisms described in
the section below.
4.2. RLOC Reachability
The LISP architecture is an edge to edge pull architecture, where the The LISP architecture is an edge to edge pull architecture, where the
network state is stored in the control-plane while the data-plane network state is stored in the control-plane while the data-plane
pulls it on demand. On the contrary BGP is a push architecture, pulls it on demand. On the contrary BGP is a push architecture,
where the required network state is pushed by means of BGP UPDATE where the required network state is pushed by means of BGP UPDATE
messages to BGP speakers. In push architectures, reachability messages to BGP speakers. In push architectures, reachability
information is also pushed to the interested routers. However pull information is also pushed to the interested routers. However pull
architectures require of explicit mechanisms to propagate architectures require explicit mechanisms to propagate reachability
reachability information. LISP defines a set of mechanisms to inform information. LISP defines a set of mechanisms to inform ITRs and
ITRs and PITRS about the reachability of the cached RLOCs: PITRS about the reachability of the cached RLOCs:
Locator Status Bits (LSB): LSB is a passive technique, the LSB field Locator Status Bits (LSB): LSB is a passive technique, the LSB field
is carried by data-packets in the LISP header and can be set by a is carried by data-packets in the LISP header and can be set by a
ETRs to specify which RLOCs are up/down. This information can be ETRs to specify which RLOCs of the ETR site are up/down. This
used by the ITRs as a hint about the reachability to perform information can be used by the ITRs as a hint about the reachability
additional checks. Also note that LSB does not provide path to perform additional checks. Also note that LSB does not provide
reachability status, only hints on the status of RLOCs. path reachability status, only hints on the status of RLOCs.
Echo-nonce: This is also a passive technique, that can only operate Echo-nonce: This is also a passive technique, that can only operate
effectively when data flows bi-directionally between two effectively when data flows bi-directionally between two
communicating xTRs. Basically, an ITR piggybacks a random number communicating xTRs. Basically, an ITR piggybacks a random number
(called nonce) in LISP data packets, if the path and the probed (called nonce) in LISP data packets, if the path and the probed
locator are up, the ETR will piggyback the same random number on the locator are up, the ETR will piggyback the same random number on the
next data-packet, if this is not the case the ITR can set the locator next data-packet, if this is not the case the ITR can set the locator
as unreachable. When traffic flow is unidirectional or when the ETR as unreachable. When traffic flow is unidirectional or when the ETR
receiving the traffic is not the same as the ITR that transmits it receiving the traffic is not the same as the ITR that transmits it
back, additional mechanisms are required. back, additional mechanisms are required.
RLOC-probing: This is an active probing algorithm where ITRs send RLOC-probing: This is an active probing algorithm where ITRs send
probes to specific locators, this effectively probes both the locator probes to specific locators, this effectively probes both the locator
and the path. In particular this is done by sending a Map-Request and the path. In particular this is done by sending a Map-Request
(with certain flags activated) on the data-plane and waiting in (with certain flags activated) on the data-plane (RLOC space) and
return a Map-Reply, also sent on the data-plane. The active nature waiting in return a Map-Reply, also sent on the data-plane. The
of RLOC-probing provides an effective mechanism to determine active nature of RLOC-probing provides an effective mechanism to
reachability and, in case of failure, switching to a different determine reachability and, in case of failure, switching to a
locator. Furthermore the mechanism also provides useful RTT different locator. Furthermore the mechanism also provides useful
estimates of the delay of the path that can be used by other network RTT estimates of the delay of the path that can be used by other
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
together. Specifically if a nonce is not echoed, an ITR could RLOC-
probe to determine if the path is up because the return bidirectional
path may have failed or the return path is not used, that is there is
only 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
can use it to determine if a given locator or path are reachable. can use it to determine if a given locator or path are reachable.
3.3. ETR Synchronization 4.3. ETR Synchronization
All the ETRs that are authoritative to a particular EID-prefix must All the ETRs that are authoritative to a particular EID-prefix must
announce the same mapping to the requesters, this means that ETRs announce the same mapping to the requesters, this means that ETRs
must be aware of the status of the RLOCs of the remaining ETRs. This must be aware of the status of the RLOCs of the remaining ETRs. This
is known as ETR synchronization. is known as ETR synchronization.
At the time of this writing LISP does not specify a mechanism to At the time of this writing LISP does not specify a mechanism to
achieve ETR synchronization. Although many well-known techniques achieve ETR synchronization. Although many well-known techniques
could be applied to solve this issue it is still under research, as a could be applied to solve this issue it is still under research, as a
result operators must rely on coherent manual configuration result operators must rely on coherent manual configuration
3.4. MTU Handling 4.4. MTU Handling
Since LISP encapsulates packets it requires dealing with packets that Since LISP encapsulates packets it requires dealing with packets that
exceed the MTU of the path between the ITR and the ETR. Specifically exceed the MTU of the path between the ITR and the ETR. Specifically
LISP defienes two mechanisms: LISP defines two mechanisms:
Stateless: With this mechanism ITRs fragment packets that are too Stateless: With this mechanism the effective MTU is assumed from the
big, typically reassembly is performed at the destination host. ITR's perspective. If a payload packet is too big for the
effective MTU, and can be fragmented, the payload packet is
fragmented on the ITR, such that reassembly is performed at the
destination host.
Stateful: With this mechanism ITRs keep track of the MTU of the Stateful: With this mechanism ITRs keep track of the MTU of the
paths towards the destination locators by parsing the ICMP Too Big paths towards the destination locators by parsing the ICMP Too Big
packets sent by intermediate routers. packets sent by intermediate routers. Additionally ITRs will send
ICMP Too Big messages to inform the sources about the effective
MTU.
In both cases if the packet cannot be framgneted (IPv4 with DF=1 or In both cases if the packet cannot be fragmented (IPv4 with DF=1 or
IPv6) then the ITR drops it and replies with a ICMP Too Big message IPv6) then the ITR drops it and replies with a ICMP Too Big message
to the source. to the source.
4. Mobility 5. Mobility
LISP can also be used to enable mobility of devices not located in The separation between locators and identifiers in LISP was initially
LISP networks. The problem with mobility of such devices is that proposed for traffic engineering purpose where LISP sites can change
their IP address changes whenever they change location, interrupting their attachment points to the Internet (i.e., RLOCs) without
so flows. impacting endpoints or the Internet core. In this context, the
border routers operate the xTR functionality and endpoints are not
aware of the existence of LISP. However, this mode of operation does
not allow seamless mobility of endpoints between different LISP sites
as the EID address might not be routable in a visited site.
To enable mobility on such devices, the device can implement the xTR Nevertheless, LISP can be used to enable seamless IP mobility when
functionality where the IP address presented to applications is an LISP is directly implemented in the endpoint. Each endpoint is then
EID that never changes while the IP address obtained from the network an xTR and the EID address is the one presented to the network stack
is used by the xTR as RLOC. Packets are then transported on the used by applications while the RLOC is the address gathered from the
network using the IP address assigned to the device by the visited network when it is visited.
network while at the application level IP addresses remain
independent of the location of the device.
Whenever the device changes of RLOC, the ITR updates the RLOC of its Whenever the device changes of RLOC, the ITR 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 signalling 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.
5. Multicast 6. Multicast
LISP also supports multicast environments, the operational changes LISP also supports transporting IP multicast packets sent from the
required to the multicast protocols are documented in [RFC6831]. EID space, the operational changes required to the multicast
protocols are documented in [RFC6831].
In such scenarios, LISP creates multicast state both at the core and In such scenarios, LISP may create multicast state both at the core
at the sites (both source and receiver). In order to create and at the sites (both source and receiver). When signaling is used
multicast state at the sites, LISP routers unicast encapsulate PIM create multicast state at the sites, LISP routers unicast encapsulate
Join/Prune messages from receiver to source sites. At the core, ETRs PIM Join/Prune messages from receiver to source sites. At the core,
build a new PIM Join/Prune message addressed to the RLOC of the ITR ETRs build a new PIM Join/Prune message addressed to the RLOC of the
servicing the source. An simplified sequence is shown below: ITR servicing the source. An simplified sequence is shown below
1. An end-host that belongs to a LISP site transmits a PIM Join/ 1. An end-host willing to join a multicast channel sends an IGMP
Prune message (S-EID,G) to join a multicast group. report. Multicast PIM routers at the LISP site propagate PIM
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 multicast state at the source site.
The second join message contains as destination address the RLOC The second join message contains as destination address the RLOC
of the ITR servicing the source (S-RLOC, G) and creates multicast of the ITR servicing the source (S-RLOC, G) and creates multicast
state at the core. 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.
6. Security LISP also support non-PIM mechanisms to maintain multicast state.
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 must be discussed above but may also affect the way security is enforced.
envisioned.
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 though 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 been taken so to not overload the mapping system Care must also be taken so to not overload the mapping system (i.e.,
(i.e., the control plane infrastructure) as the operations to be the control plane infrastructure) as the operations to be performed
performed by the mapping system may be more complex than those on the by the mapping system may be more complex than those on the data-
data-plane, for that reason [RFC6830] recommends to rate limit the plane, for that reason [RFC6830] recommends to rate limit the sending
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 control informations,
such as reachabilty of locators, directly into data plane packets. such as reachabilty of locators, directly into data plane packets.
In environments that are not fully trusted, control informations In environments that are not fully trusted, control informations
gleaned from data-plane packets should be verified before using them. gleaned 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-Server that strictly respect [RFC6833] entities. Using trustable Map-Servers that strictly respect
and the lightweight authentication mechanism proposed by LISP-Sec [RFC6833] and the lightweight authentication mechanism proposed by
[I-D.ietf-lisp-sec] is a possibility to reduce the risk. In more LISP-Sec [I-D.ietf-lisp-sec] reduces the risk of attacks to the
critical environments, stronger authentication may have to be used. mapping integrity. In more critical environments, secure measures
may be needed.
Packets are transported encapsulated with LISP meaning that devices As with any other tunneling mechanism, middleboxes on the path
on the path between an ITR (or PITR) and an ETR (or PETR) cannot between an ITR (or PITR) and an ETR (or PETR) must implement
correctly inspect the content of packets unless they implement mechanisms to strip the LISP encapsulation to correctly inspect the
methods to strip the headers added by LISP. Similarly, mappings content of LISP encapsulated packets.
enable triangular routing (i.e., packets of a flow cross different
border routers depending on their direction) which means that
intermediate boxes may have incomplete view on the traffic they
inspect or manipulate.
More details about security implications of LISP can be found in Like other map-and-encap mechanisms, LISP enables triangular routing
(i.e., packets of a flow cross different border routers depending on
their direction). This means that intermediate boxes may have
incomplete view on the traffic they inspect or manipulate.
More details about security implications of LISP are discussed in
[I-D.ietf-lisp-threats]. [I-D.ietf-lisp-threats].
7. Use Cases 8. Use Cases
7.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 network even though the path followed to reach
the ETR is not under the control of the LISP site. This fine control the ETR is not under the control of the LISP site. This fine control
is implemented with the mappings. When a remote site is willing to is implemented with the mappings. When a remote site is willing to
send traffic to a LISP site, it retrieves the mapping associated to send traffic to a LISP site, it retrieves the mapping associated to
the destination EID via the mapping system. The mapping is sent the destination EID via the mapping system. The mapping is sent
directly by the owner of EID and is not altered by any intermediate directly by an authoritative ETR of the EID and is not altered by any
network. 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 that is able to correctly
forward packets to EIDs in the prefix. Each RLOC is tagged with a forward packets to EIDs in the prefix. Each RLOC is tagged with a
priority and a weight in the mapping. The priority is used to priority and a weight in the mapping. The priority is used to
indicates which RLOCs should be preferred to send packets (the least indicates which RLOCs should be preferred to send packets (the least
preferred ones being provided for backup purpose). The weight preferred ones being provided for backup purpose). The weight
permits to balance the load between the RLOCs with the same priority, permits to balance the load between the RLOCs with the same priority,
proportionally to the weight value. proportionally to the weight value.
As mappings are directly issued by the owner of the EID and not As mappings are directly issued by the authoritative ETR of the EID
altered while transmitted to the remote site, it offers highly and are not altered while transmitted to the remote site, it offers
flexible incoming inter-domain traffic engineering with even the highly flexible incoming inter-domain traffic engineering with even
possibility for a site to issue a different mapping for each remote the possibility for a site to issue a different mapping for each
site, implementing so precise routing policies. remote site, implementing so precise routing policies.
7.2. LISP for IPv6 Transition 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 with addresses
belonging to another address family (e.g., IPv4). The absence of belonging to another address family (e.g., IPv4). The absence of
correlation between the address family of RLOCs and EIDs makes LISP a correlation between the address family of RLOCs and EIDs makes LISP a
candidate to ease the transition to IPv4. candidate to allow, e.g., IPv6 to be deployed when all of the core
network may not have 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.
7.3. LISP for Network Virtualization 8.3. LISP for Virtual Private Networks
It is nowadays common to operate several virtual networks over the
same physical infrastructure. The current approach usually rely on
BGP/MPLS VPNs, where BGP is used to exchange routing information and
MPLS to segregate packets of the different logical networks. This
functionality could be achieved with LISP where the mappings and the
mapping system are used instead of BGP and the LISP encapsulation is
used to replace MPLS.
In virtual networks, it is essential to distinguish to which virtual It is common to operate several virtual networks over the same
network a packet belongs and tags or labels are used for that physical infrastructure. In such virtual private networks, it is
purpose. With LISP, the distinction can be made with the Instance ID essential to distinguish to which virtual network a packet belongs
field. When an ITR encapsulates a packet from a particular virtual and tags or labels are used for that purpose. With LISP, the
network (e.g., known via the VRF or VLAN), it tags the encapsulated distinction can be made with the Instance ID field. When an ITR
packet with the Instance ID corresponding to the virtual network of encapsulates a packet from a particular virtual network (e.g., known
the packet. When an ETR receives a packet tagged with an Instance ID via the VRF or VLAN), it tags the encapsulated packet with the
it uses the Instance ID to determine how to threat the packet. Instance ID corresponding to the virtual network of the packet. When
an ETR receives a packet tagged with an Instance ID it uses the
Instance ID to determine how to treat the packet.
Appart from the simplicity of managing mappings, the advantage of The main advantage of using LISP for virtual networks, on top of the
using LISP for virtual network is that it does not impose any simplicity of managing the mappings, is that it does not impose any
requirement on the underlying network, except running IP. requirement on the underlying network, as long as it is running IP.
7.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 to conceive the datacenter backbone as the RLOC space and the subnet
subnetworks where servers are hosted as forming the EID space. A where servers are hosted as forming the EID space. A LISP router is
LISP router is placed at the border between the backbone and each placed at the border between the backbone and each subnet. When a
sub-network. When a virtual machine is moved to another subnetwork, virtual machine is moved to another subnet, it can (temporarily) keep
it can (temporarily) keep the address of the sub-network it was the address of the subnet it was hosted before the move so to allow
hosted before the move so to allow ongoing communications to subsist. ongoing communications to subsist. When a subnet detects the
When a subnetwork detects the presence of a host with an address that presence of a host with an address that does not belong to the subnet
does not belong to the subnetwork (e.g., via a message sent by the (e.g., via a message sent by the hypervisor or traffic inspection),
hypervisor), the LISP router of the new subnetwork registers the IP the LISP router of the new subnet registers the IP address of the
address of the virtual machine as an EID to the Map-Server of the virtual machine as an EID to the Map-Server of the subnet and
subnetwork and associates its own address as RLOC. 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, every Map- and then to avoid detours via the initial subnetwork, mechanisms such
Server can listen on a predefined multicast address that is used as as the Solicit-Map-Request messages are used.
source address for Map-Register. As a result, the Map-Notify sent
back by the Map-Server will be received by all the LISP routers that
hence automatically learn the new location of the virtual machine.
8. 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.
9. IANA Considerations 10. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
10. Acknowledgements 11. Acknowledgements
To Do. This document was initiated by Noel Chiappa and much of the core
philosophy came from him. The authors acknowledge the important
contributions he has made to this work and thank him for his past
efforts.
11. References The authors would also like to thank Dino Farinacci, Fabio Maino,
Luigi Iannone, Sharon Barakai, Isidoros Kouvelas, Christian Cassar,
Florin Coras, Marc Binderberger, Alberto Rodriguez-Natal, Ronald
Bonica, Chad Hintz, Robert Raszuk, Joel M. Halpern, Darrel Lewis, as
well as every people acknowledged in [RFC6830].
11.1. Normative References 12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002.
[RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V.
Gill, "IPv4 Multihoming Practices and Limitations", RFC Gill, "IPv4 Multihoming Practices and Limitations", RFC
4116, July 2005. 4116, July 2005.
[RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
Workshop on Routing and Addressing", RFC 4984, September Workshop on Routing and Addressing", RFC 4984, September
2007. 2007.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, January Locator/ID Separation Protocol (LISP)", RFC 6830, January
skipping to change at page 21, line 51 skipping to change at page 22, line 24
Separation Protocol (LISP) Map-Versioning", RFC 6834, Separation Protocol (LISP) Map-Versioning", RFC 6834,
January 2013. January 2013.
[RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation
Protocol Internet Groper (LIG)", RFC 6835, January 2013. Protocol Internet Groper (LIG)", RFC 6835, January 2013.
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol Alternative Logical "Locator/ID Separation Protocol Alternative Logical
Topology (LISP+ALT)", RFC 6836, January 2013. Topology (LISP+ALT)", RFC 6836, January 2013.
[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
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.
[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.
11.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.
[DDT-ROOT] [DDT-ROOT]
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.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-03 (work in progress), March 2013.
[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-01 (work in Delegated Database Tree", draft-ietf-lisp-ddt-02 (work in
progress), March 2013. 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-05 (work in Address Format (LCAF)", draft-ietf-lisp-lcaf-06 (work in
progress), May 2014. progress), October 2014.
[I-D.ietf-lisp-sec] [I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-06 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-07
(work in progress), April 2014. (work in progress), October 2014.
[I-D.ietf-lisp-threats] [I-D.ietf-lisp-threats]
Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats
Analysis", draft-ietf-lisp-threats-10 (work in progress), Analysis", draft-ietf-lisp-threats-10 (work in progress),
July 2014. July 2014.
[I-D.lear-lisp-nerd]
Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
draft-lear-lisp-nerd-08 (work in progress), March 2010.
[I-D.mathy-lisp-dht] [I-D.mathy-lisp-dht]
Mathy, L., Iannone, L., and O. Bonaventure, ""LISP-DHT: Mathy, L., Iannone, L., and O. Bonaventure, ""LISP-DHT:
Towards a DHT to map identifiers onto locators" draft- Towards a DHT to map identifiers onto locators" draft-
mathy-lisp-dht-00 (work in progress)", April 2008. mathy-lisp-dht-00 (work in progress)", April 2008.
[Jakab] Jakab, L., Cabellos, A., Saucez, D., and O. Bonaventure, [Jakab] Jakab, L., Cabellos, A., Saucez, D., and O. Bonaventure,
"LISP-TREE: A DNS Hierarchy to Support the LISP Mapping "LISP-TREE: A DNS Hierarchy to Support the LISP Mapping
System, IEEE Journal on Selected Areas in Communications, System, IEEE Journal on Selected Areas in Communications,
vol. 28, no. 8, pp. 1332-1343", October 2010. vol. 28, no. 8, pp. 1332-1343", October 2010.
skipping to change at page 23, line 39 skipping to change at page 24, line 8
Appendix A. A Brief History of Location/Identity Separation Appendix A. A Brief History of Location/Identity Separation
The LISP system for separation of location and identity resulted from The LISP system for separation of location and identity resulted from
the discussions of this topic at the Amsterdam IAB Routing and the discussions of this topic at the Amsterdam IAB Routing and
Addressing Workshop, which took place in October 2006 [RFC4984]. Addressing Workshop, which took place in October 2006 [RFC4984].
A small group of like-minded personnel from various scattered A small group of like-minded personnel from various scattered
locations within Cisco, spontaneously formed immediately after that locations within Cisco, spontaneously formed immediately after that
workshop, to work on an idea that came out of informal discussions at workshop, to work on an idea that came out of informal discussions at
the workshop. The first Internet-Draft on LISP appeared in January, the workshop and on various mailing lists. The first Internet-Draft
2007, along with a LISP mailing list at the IETF. on LISP appeared in January, 2007.
Trial implementations started at that time, with initial trial Trial implementations started at that time, with initial trial
deployments underway since June 2007; the results of early experience deployments underway since June 2007; the results of early experience
have been fed back into the design in a continuous, ongoing process have been fed back into the design in a continuous, ongoing process
over several years. LISP at this point represents a moderately over several years. LISP at this point represents a moderately
mature system, having undergone a long organic series of changes and mature system, having undergone a long organic series of changes and
updates. updates.
LISP transitioned from an IRTF activity to an IETF WG in March 2009, LISP transitioned from an IRTF activity to an IETF WG in March 2009,
and after numerous revisions, the basic specifications moved to and after numerous revisions, the basic specifications moved to
becoming RFCs at the start of 2013 (although work to expand and becoming RFCs at the start of 2013 (although work to expand and
improve it, and find new uses for it, continues, and undoubtly will improve it, and find new uses for it, continues, and undoubtly will
for a long time to come). for a long time to come).
A.1. Old LISP Models A.1. Old LISP Models
LISP, as initilly conceived, had a number of potential operating LISP, as initially conceived, had a number of potential operating
modes, named 'models'. Although they are now obsolete, one modes, named 'models'. Although they are note used anymore, one
occasionally sees mention of them, so they are briefly described occasionally sees mention of them, so they are briefly described
here. here.
LISP 1: EIDs all appear in the normal routing and forwarding tables LISP 1: EIDs all appear in the normal routing and forwarding tables
of the network (i.e. they are 'routable');this property is used to of the network (i.e. they are 'routable');this property is used to
'bootstrap' operation, by using this to load EID->RLOC mappings. 'bootstrap' operation, by using this to load EID->RLOC mappings.
Packets were sent with the EID as the destination in the outer Packets were sent with the EID as the destination in the outer
wrapper; when an ETR saw such a packet, it would send a Map-Reply wrapper; when an ETR saw such a packet, it would send a Map-Reply
to the source ITR, giving the full mapping. to the source ITR, giving the full mapping.
 End of changes. 117 change blocks. 
428 lines changed or deleted 444 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/