draft-ietf-lisp-introduction-12.txt   draft-ietf-lisp-introduction-13.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: August 21, 2015 INRIA Expires: October 4, 2015 INRIA
February 17, 2015 April 02, 2015
An Architectural Introduction to the Locator/ID Separation Protocol An Architectural Introduction to the Locator/ID Separation Protocol
(LISP) (LISP)
draft-ietf-lisp-introduction-12.txt draft-ietf-lisp-introduction-13.txt
Abstract Abstract
This document describes the architecture of the Locator/ID Separation This document describes the architecture of the Locator/ID Separation
Protocol (LISP), making it easier to read the rest of the LISP Protocol (LISP), making it easier to read the rest of the LISP
specifications and providing a basis for discussion about the details specifications and providing a basis for discussion about the details
of the LISP protocols. This document is used for introductory of the LISP protocols. This document is used for introductory
purposes, more details can be found in RFC6830, the protocol purposes, more details can be found in RFC6830, the protocol
specification. specification.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 August 21, 2015. This Internet-Draft will expire on October 4, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 14 skipping to change at page 2, line 14
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
3. LISP Architecture . . . . . . . . . . . . . . . . . . . . . . 5 3. LISP Architecture . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Design Principles . . . . . . . . . . . . . . . . . . . . 5 3.1. Design Principles . . . . . . . . . . . . . . . . . . . . 5
3.2. Overview of the Architecture . . . . . . . . . . . . . . 6 3.2. Overview of the Architecture . . . . . . . . . . . . . . 5
3.3. Data-Plane . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Data-Plane . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1. LISP Encapsulation . . . . . . . . . . . . . . . . . 9 3.3.1. LISP Encapsulation . . . . . . . . . . . . . . . . . 8
3.3.2. LISP Forwarding State . . . . . . . . . . . . . . . . 10 3.3.2. LISP Forwarding State . . . . . . . . . . . . . . . . 10
3.4. Control-Plane . . . . . . . . . . . . . . . . . . . . . . 10 3.4. Control-Plane . . . . . . . . . . . . . . . . . . . . . . 10
3.4.1. LISP Mappings . . . . . . . . . . . . . . . . . . . . 11 3.4.1. LISP Mappings . . . . . . . . . . . . . . . . . . . . 10
3.4.2. Mapping System Interface . . . . . . . . . . . . . . 11 3.4.2. Mapping System Interface . . . . . . . . . . . . . . 11
3.4.3. Mapping System . . . . . . . . . . . . . . . . . . . 12 3.4.3. Mapping System . . . . . . . . . . . . . . . . . . . 11
3.5. Internetworking Mechanisms . . . . . . . . . . . . . . . 15 3.5. Internetworking Mechanisms . . . . . . . . . . . . . . . 14
4. LISP Operational Mechanisms . . . . . . . . . . . . . . . . . 16 4. LISP Operational Mechanisms . . . . . . . . . . . . . . . . . 15
4.1. Cache Management . . . . . . . . . . . . . . . . . . . . 16 4.1. Cache Management . . . . . . . . . . . . . . . . . . . . 15
4.2. RLOC Reachability . . . . . . . . . . . . . . . . . . . . 17 4.2. RLOC Reachability . . . . . . . . . . . . . . . . . . . . 16
4.3. ETR Synchronization . . . . . . . . . . . . . . . . . . . 18 4.3. ETR Synchronization . . . . . . . . . . . . . . . . . . . 17
4.4. MTU Handling . . . . . . . . . . . . . . . . . . . . . . 18 4.4. MTU Handling . . . . . . . . . . . . . . . . . . . . . . 17
5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 20 7.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 19
7.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . 21 7.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . 20
7.3. LISP for Virtual Private Networks . . . . . . . . . . . . 21 7.3. LISP for Virtual Private Networks . . . . . . . . . . . . 20
7.4. LISP for Virtual Machine Mobility in Data Centers . . . . 22 7.4. LISP for Virtual Machine Mobility in Data Centers . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. A Brief History of Location/Identity Separation . . 26 Appendix A. A Brief History of Location/Identity Separation . . 25
A.1. Old LISP Models . . . . . . . . . . . . . . . . . . . . . 27 A.1. Old LISP Models . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
This document introduces the Locator/ID Separation Protocol (LISP) This document introduces the Locator/ID Separation Protocol (LISP)
[RFC6830] architecture, its main operational mechanisms and its [RFC6830] architecture, its main operational mechanisms and its
design rationale. Fundamentally, LISP is built following a well- design rationale. Fundamentally, LISP is built following a well-
known architectural idea: decoupling the IP address overloaded known architectural idea: decoupling the IP address overloaded
semantics. Indeed and as pointed out by the unpublished Internet semantics. Indeed and as pointed out by Noel Chiappa [RFC4984],
Draft by Noel Chiappa [Chiappa], currently IP addresses both identify currently IP addresses both identify the topological location of a
the topological location of a network attachment point as well as the network attachment point as well as the node's identity. However,
node's identity. However, nodes and routing have fundamentally nodes and routing have fundamentally different requirements, routing
different requirements, routing systems require that addresses are systems require that addresses are aggregatable and have topological
aggregatable and have topological meaning, while nodes require to be meaning, while nodes require to be identified independently of their
identified independently of their current location [RFC4984]. current location [RFC4984].
LISP creates two separate namespaces, EIDs (End-host IDentifiers) and LISP creates two separate namespaces, EIDs (End-host IDentifiers) and
RLOCs (Routing LOCators), both are typically syntactically identical RLOCs (Routing LOCators), both are syntactically identical to the
to the current IPv4 and IPv6 addresses. EIDs are used to uniquely current IPv4 and IPv6 addresses. EIDs are used to uniquely identify
identify nodes irrespective of their topological location and are nodes irrespective of their topological location and are typically
typically routed intra-domain. RLOCs are assigned topologically to routed intra-domain. RLOCs are assigned topologically to network
network attachment points and are typically routed inter-domain. attachment points and are typically routed inter-domain. With LISP,
With LISP, the edge of the Internet (where the nodes are connected) the edge of the Internet (where the nodes are connected) and the core
and the core (where inter-domain routing occurs) can be logically (where inter-domain routing occurs) can be logically separated and
separated and interconnected by LISP-capable routers. LISP also interconnected by LISP-capable routers. LISP also introduces a
introduces a database, called the Mapping System, to store and database, called the Mapping System, to store and retrieve mappings
retrieve mappings between identity and location. LISP-capable between identity and location. LISP-capable routers exchange packets
routers exchange packets over the Internet core by encapsulating them over the Internet core by encapsulating them to the appropriate
to the appropriate location. location.
In summary: In summary:
o RLOCs have meaning only in the underlay network, that is the o RLOCs have meaning only in the underlay network, that is the
underlying core routing system. underlying core routing system.
o EIDs have meaning only in the overlay network unless they are o EIDs have meaning only in the overlay network, which is the
leaked into the underlay network. The overlay is the
encapsulation relationship between LISP-capable routers. encapsulation relationship between LISP-capable routers.
Furthermore EIDs are not assigned from the reserved address
blocks.
o The LISP edge maps EIDs to RLOCs o The LISP edge maps EIDs to RLOCs
o Within the underlay network, RLOCs have both locator and o Within the underlay network, RLOCs have both locator and
identifier semantics identifier semantics
o An EID within a LISP site carries both identifier and locator o An EID within a LISP site carries both identifier and locator
semantics to other nodes within that site semantics to other nodes within that site
o An EID within a LISP site carries identifier and limited locator o An EID within a LISP site carries identifier and limited locator
semantics to nodes at other LISP sites (i.e., enough locator semantics to nodes at other LISP sites (i.e., enough locator
information to tell that the EID is external to the site) information to tell that the EID is external to the site)
The relationship described above is not unique to LISP but it is The relationship described above is not unique to LISP but it is
common to other overlay technologies. common to other overlay technologies.
The initial motivation in the LISP effort is to be found in the The initial motivation in the LISP effort is to be found in the
routing scalability problem [RFC4984], where, if LISP is completely routing scalability problem [RFC4984], where, if LISP were to be
deployed, the Internet core is populated with RLOCs while Traffic completely deployed, the Internet core is populated with RLOCs while
Engineering mechanisms are pushed to the Mapping System. In such Traffic Engineering mechanisms are pushed to the Mapping System. In
scenario RLOCs are quasi-static (i.e., low churn), hence making the such scenario RLOCs are quasi-static (i.e., low churn), hence making
routing system scalable [Quoitin], while EIDs can roam anywhere with the routing system scalable [Quoitin], while EIDs can roam anywhere
no churn to the underlying routing system. [RFC7215] discusses the with no churn to the underlying routing system. [RFC7215] discusses
impact of LISP on the global routing system during the transition the impact of LISP on the global routing system during the transition
period. However, the separation between location and identity that period. However, the separation between location and identity that
LISP offers makes it suitable for use in additional scenarios such as LISP offers makes it suitable for use in additional scenarios such as
Traffic Engineering (TE), multihoming, and mobility among others. Traffic Engineering (TE), multihoming, and mobility among others.
This document describes the LISP architecture, its main operational This document describes the LISP architecture and its main
mechanisms as its design rationale. It is important to note that operational mechanisms as well as its design rationale. It is
this document does not specify or complement the LISP protocol. The important to note that this document does not specify or complement
interested reader should refer to the main LISP specifications the LISP protocol. The interested reader should refer to the main
[RFC6830] and the complementary documents [RFC6831], [RFC6832], LISP specifications [RFC6830] and the complementary documents
[RFC6833], [RFC6834], [RFC6835], [RFC6836], [RFC7052] for the [RFC6831], [RFC6832], [RFC6833], [RFC6834], [RFC6835], [RFC6836],
protocol specifications along with the LISP deployment guidelines [RFC7052] for the protocol specifications along with the LISP
[RFC7215]. deployment guidelines [RFC7215].
2. Definition of Terms 2. Definition of Terms
Endpoint IDentifier (EID): EIDs are IPv4 or IPv6 addresses used to Endpoint IDentifier (EID): EIDs are addresses used to uniquely
uniquely identify nodes irrespective of their topological location identify nodes irrespective of their topological location and are
and are typically routed intra-domain. typically routed intra-domain.
Routing LOcator (RLOC): RLOCs are IPv4 or IPv6 addresses assigned Routing LOcator (RLOC): RLOCs are addresses assigned topologically
topologically to network attachment points and typically routed to network attachment points and typically routed inter-domain.
inter-domain.
Ingress Tunnel Router (ITR): A LISP-capable router that encapsulates Ingress Tunnel Router (ITR): A LISP-capable router that encapsulates
packets from a LISP site towards the core network. packets from a LISP site towards the core network.
Egress Tunnel Router (ETR): A LISP-capable router that decapsulates Egress Tunnel Router (ETR): A LISP-capable router that decapsulates
packets from the core of the network towards a LISP site. packets from the core of the network towards a LISP site.
xTR: A router that implements both ITR and ETR functionalities. xTR: A router that implements both ITR and ETR functionalities.
Map-Request: A LISP signaling message used to request an EID-to-RLOC Map-Request: A LISP signaling message used to request an EID-to-RLOC
skipping to change at page 5, line 28 skipping to change at page 5, line 24
aspects: data-plane, control-plane, and internetworking mechanisms. aspects: data-plane, control-plane, and internetworking mechanisms.
3.1. Design Principles 3.1. Design Principles
The LISP architecture is built on top of four basic design The LISP architecture is built on top of four basic design
principles: principles:
o Locator/Identifier split: By decoupling the overloaded semantics o Locator/Identifier split: By decoupling the overloaded semantics
of the current IP addresses the Internet core can be assigned of the current IP addresses the Internet core can be assigned
identity meaningful addresses and hence, can use aggregation to identity meaningful addresses and hence, can use aggregation to
scale. Devices are assigned with relatively opaque identity scale. Devices are assigned with relatively opaque topologically
meaningful addresses that are independent of their topological meaningful addresses that are independent of their topological
location. location.
o Overlay architecture: Overlays route packets over the current o Overlay architecture: Overlays route packets over the current
Internet, allowing deployment of new protocols without changing Internet, allowing deployment of new protocols without changing
the current infrastructure hence, resulting into a low deployment the current infrastructure hence, resulting into a low deployment
cost. cost.
o Decoupled data and control-plane: Separating the data-plane from o Decoupled data and control-plane: Separating the data-plane from
the control-plane allows them to scale independently and use the control-plane allows them to scale independently and use
skipping to change at page 6, line 10 skipping to change at page 5, line 50
o Incremental deployability: This principle ensures that the o Incremental deployability: This principle ensures that the
protocol interoperates with the legacy Internet while providing protocol interoperates with the legacy Internet while providing
some of the targeted benefits to early adopters. some of the targeted benefits to early adopters.
3.2. Overview of the Architecture 3.2. Overview of the Architecture
LISP splits architecturally the core from the edge of the Internet by LISP splits architecturally the core from the edge of the Internet by
creating two separate namespaces: Endpoint Identifiers (EIDs) and creating two separate namespaces: Endpoint Identifiers (EIDs) and
Routing LOCators (RLOCs). The edge consists of LISP sites (e.g., an Routing LOCators (RLOCs). The edge consists of LISP sites (e.g., an
Autonomous System) that use EID addresses. EIDs are typically -but Autonomous System) that use EID addresses. EIDs are IPv4 or IPv6
not limited to- IPv4 or IPv6 addresses that uniquely identify addresses that uniquely identify communication end-hosts and are
communication end-hosts and are assigned and configured by the same assigned and configured by the same mechanisms that exist at the time
mechanisms that exist at the time of this writing. EIDs do not of this writing. EIDs do not contain inter-domain topological
contain inter-domain topological information and because of this, information and because of this, EIDs are usually routable at the
EIDs are usually routable at the edge (within LISP sites) or in the edge (within LISP sites) or in the non-LISP Internet; see Section 3.5
non-LISP Internet; see Section 3.5 for discussion of LISP site for discussion of LISP site internetworking with non-LISP sites and
internetworking with non-LISP sites and domains in the Internet. domains in the Internet.
With LISP, LISP sites (edge) and the core of the Internet are LISP sites (at the edge of the Internet) are connected to the core of
interconnected by means of LISP-capable routers (e.g., border the Internet by means of LISP-capable routers (e.g., border routers).
routers) using tunnels. When packets originated from a LISP site are LISP sites are connected across the core of the Internet using
flowing towards the core network, they ingress into an encapsulated tunnels between the LISP-capable routers. When packets originated
tunnel via an Ingress Tunnel Router (ITR). When packets flow from from a LISP site are flowing towards the core network, they ingress
the core network to a LISP site, they egress from an encapsulated into an encapsulated tunnel via an Ingress Tunnel Router (ITR). When
tunnel to an Egress Tunnel Router (ETR). An xTR is a router which packets flow from the core network to a LISP site, they egress from
can perform both ITR and ETR operations. In this context ITRs an encapsulated tunnel to an Egress Tunnel Router (ETR). An xTR is a
encapsulate packets while ETRs decapsulate them, hence LISP operates router which can perform both ITR and ETR operations. In this
as an overlay on top of the current Internet core. context ITRs encapsulate packets while ETRs decapsulate them, hence
LISP operates as an overlay on top of the current Internet core.
/-----------------\ --- /-----------------\ ---
| Mapping | | | Mapping | |
. System | | Control . System | | Control
-| |`, | Plane -| |`, | Plane
,' \-----------------/ . | ,' \-----------------/ . |
/ | --- / | ---
,.., - _,....,, | ,.., | ,.., - _,....,, | ,.., |
/ ` ,' ,-` `', | / ` | / ` ,' ,-` `', | / ` |
/ \ +-----+ ,' `, +-----+ / \ | / \ +-----+ ,' `, +-----+ / \ |
| EID |-| xTR |--/ RLOC ,--| xTR |-| EID | | Data | EID |-| xTR |--/ RLOC ,--| xTR |-| EID | | Data
| Space |-| |--| Space |--| |-| Space | | Plane | Space |-| |--| Space |--| |-| Space | | Plane
\ / +-----+ . / +-----+ \ / | \ / +-----+ . / +-----+ \ / |
`. .' `. ,' `. .' | `. .' `. ,' `. .' |
`'-` `., ,.' `'-` --- `'-` `., ,.' `'-` ---
``'''`` ``'''``
LISP Site (Edge) Core LISP Site (Edge) LISP Site (Edge) Core LISP Site (Edge)
Figure 1.- A schema of the LISP Architecture Figure 1.- A schema of the LISP Architecture
With LISP, the core uses RLOCs, an RLOC is typically -but not limited With LISP, the core uses RLOCs, an RLOC is an IPv4 or IPv6 address
to- an IPv4 or IPv6 address assigned to an Internet-facing network assigned to an Internet-facing network interface of an ITR or ETR.
interface of an ITR or ETR. Typically RLOCs are numbered from Typically RLOCs are numbered from topologically aggregatable blocks
topologically aggregatable blocks assigned to a site at each point to assigned to a site at each point to which it attaches to the global
which it attaches to the global Internet, the topology is defined by Internet, the topology is defined by the connectivity of networks.
the connectivity of networks.
A typically distributed database, called the Mapping System, stores A database which is typically distributed, called the Mapping System,
mappings between EIDs and RLOCs. Such mappings relate the identity stores mappings between EIDs and RLOCs. Such mappings relate the
of the devices attached to LISP sites (EIDs) to the set of RLOCs identity of the devices attached to LISP sites (EIDs) to the set of
configured at the LISP-capable routers servicing the site. RLOCs configured at the LISP-capable routers servicing the site.
Furthermore, the mappings also include traffic engineering policies Furthermore, the mappings also include traffic engineering policies
and can be configured to achieve multihoming and load balancing. The and can be configured to achieve multihoming and load balancing. The
LISP Mapping System is conceptually similar to the DNS where it is LISP Mapping System is conceptually similar to the DNS where it is
organized as a distributed multi-organization network database. With organized as a distributed multi-organization network database. With
LISP, ETRs register mappings while ITRs retrieve them. LISP, ETRs register mappings while ITRs retrieve them.
Finally, the LISP architecture emphasizes incremental deployment. Finally, the LISP architecture emphasizes incremental deployment.
Given that LISP represents an overlay to the current Internet Given that LISP represents an overlay to the current Internet
architecture, endhosts as well as intra and inter-domain routers architecture, endhosts as well as intra and inter-domain routers
remain unchanged, and the only required changes to the existing remain unchanged, and the only required changes to the existing
infrastructure are to routers connecting the EID with the RLOC space. infrastructure are to routers connecting the EID with the RLOC space.
Such LISP capable routers, in most cases, only require a software Additionally, LISP requires the deployment of an independent Mapping
upgrade. Additionally, LISP requires the deployment of an System, such distributed database is a new network entity.
independent Mapping System, such distributed database is a new
network entity.
The following describes a simplified packet flow sequence between two The following describes a simplified packet flow sequence between two
nodes that are attached to LISP sites. Please note that typical nodes that are attached to LISP sites. Please note that typical
LISP-capable routers are xTRs (both ITR and ETR). Client HostA wants LISP-capable routers are xTRs (both ITR and ETR). Client HostA wants
to send a packet to server HostB. to send a packet to server HostB.
/----------------\ /----------------\
| Mapping | | Mapping |
| System | | System |
.| |- .| |-
skipping to change at page 8, line 26 skipping to change at page 7, line 49
+-----+ | | RLOC_B1+-----+ +-----+ | | RLOC_B1+-----+
HostA | | | RLOC |-------| | HostB HostA | | | RLOC |-------| | HostB
EID_A--|ITR_A|----| Space | |ETR_B|--EID_B EID_A--|ITR_A|----| Space | |ETR_B|--EID_B
| | RLOC_A1 |-------| | | | RLOC_A1 |-------| |
+-----+ | | RLOC_B2+-----+ +-----+ | | RLOC_B2+-----+
, / , /
\ / \ /
`', ,-` `', ,-`
``''-''`` ``''-''``
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 obtaining an A or AAAA record. Then it generates an IP and obtaining an A or AAAA record. Then it generates an IP
packet as in the Internet, the packet has source address EID_A packet as in the Internet, the packet has source address EID_A
and destination address EID_B. 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
skipping to change at page 9, line 29 skipping to change at page 9, line 5
and caching the appropriate forwarding state. It includes two main and caching the appropriate forwarding state. It includes two main
entities, the ITR and the ETR, both are LISP capable routers that entities, the ITR and the ETR, both are LISP capable routers that
connect the EID with the RLOC space (ITR) and vice versa (ETR). connect the EID with the RLOC space (ITR) and vice versa (ETR).
3.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), the source port is usually encapsulated using UDP (port 4341), the source port is usually
selected by the ITR using a 5-tuple hash of the inner header (so to selected by the ITR using a 5-tuple hash of the inner header (so to
be consistent in case of multi-path solutions such as ECMP [RFC2992]) be consistent in case of multi-path solutions such as ECMP [RFC2992])
and ignored on reception. A particularity of LISP is that UDP and ignored on reception. LISP data packets are often encapsulated
packets should include a zero checksum [RFC6935] [RFC6936] that it is in UDP packets that include a zero checksum [RFC6935] [RFC6936] that
not verified in reception, LISP also supports non-zero checksums that is not verified when it is received, because LISP data packets
may be verified. This decision was made because the typical typically include an inner transport protocol header with a non-zero
transport protocols used by the applications already include a checksum. By omitting the additional outer UDP encapsulation
checksum, by neglecting the additional UDP encapsulation checksum checksum, xTRs can forward packets more efficiently. If LISP data
xTRs can forward packets more efficiently. packets are encapsulated in UDP packets with non-zero checksums, the
outer UDP checksums are verified when the UDP packets are received,
as part of normal UDP processing.
LISP-encapsulated packets also include a LISP header (after the UDP LISP-encapsulated packets also include a LISP header (after the UDP
header and before the original IP header). The LISP header is header and before the original IP header). The LISP header is
prepended by ITRs and striped by ETRs. It carries reachability prepended by ITRs and striped by ETRs. It carries reachability
information (see more details in Section 4.2) and the Instance ID information (see more details in Section 4.2) and the Instance ID
field. The Instance ID field is used to distinguish traffic to/from field. The Instance ID field is used to distinguish traffic to/from
different tenant address spaces at the LISP site and that may use different tenant address spaces at the LISP site and that may use
overlapped but logically separated EID addressing. overlapped but logically separated EID addressing.
Overall, LISP works on 4 headers, the inner header the source Overall, LISP works on 4 headers, the inner header the source
skipping to change at page 16, line 30 skipping to change at page 15, line 36
the ITRs, called Map-Cache, is used by the router to LISP-encapsulate the ITRs, called Map-Cache, is used by the router to LISP-encapsulate
packets. The Map-Cache is indexed by (Instance ID, EID-prefix) and packets. The Map-Cache is indexed by (Instance ID, EID-prefix) and
contains basically the set of RLOCs with the associated traffic contains basically the set of RLOCs with the associated traffic
engineering policies (priorities and weights). engineering policies (priorities and weights).
The Map-Cache, as any other cache, requires cache coherence The Map-Cache, as any other cache, requires cache coherence
mechanisms to maintain up-to-date information. LISP defines three mechanisms to maintain up-to-date information. LISP defines three
main mechanisms for cache coherence: main mechanisms for cache coherence:
Time-To-Live (TTL): Each mapping contains a TTL set by the ETR, upon Time-To-Live (TTL): Each mapping contains a TTL set by the ETR, upon
expiration of the TTL the ITR has to refresh the mapping by expiration of the TTL the ITR can't use the mapping until it is
sending a new Map-Request. Typical values for TTL defined by LISP refreshed by sending a new Map-Request. Typical values for TTL
are 24 hours. defined by LISP are 24 hours.
Solicit-Map-Request (SMR): SMR is an explicit mechanism to update Solicit-Map-Request (SMR): SMR is an explicit mechanism to update
mapping information. In particular a special type of Map-Request mapping information. In particular a special type of Map-Request
can be sent on demand by ETRs to request refreshing a mapping. can be sent on demand by ETRs to request refreshing a mapping.
Upon reception of a SMR message, the ITR must refresh the bindings Upon reception of a SMR message, the ITR must refresh the bindings
by sending a Map-Request to the Mapping System. Further uses of by sending a Map-Request to the Mapping System. Further uses of
SMRs are documented in [RFC6830]. SMRs are documented in [RFC6830].
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
skipping to change at page 17, line 11 skipping to change at page 16, line 14
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 a SMR to notify it that a new mapping Cache is outdated, it sends a SMR to notify it that a new mapping
is available. is available.
Finally it is worth noting that in some cases an entry in the map- Finally it is worth noting that in some cases an entry in the map-
cache can be proactively refreshed using the mechanisms described in cache can be proactively refreshed using the mechanisms described in
the section below. the section below.
4.2. RLOC Reachability 4.2. RLOC Reachability
The LISP architecture is an edge to edge pull architecture, where the In most cases LISP operates with a pull-based Mapping System (e.g.,
network state is stored in the control-plane while the data-plane DDT), this results in an edge to edge pull architecture. In such
pulls it on demand. This has consequences concerning the propagation scenario the network state is stored in the control-plane while the
of xTRs reachability/liveness information. On the contrary BGP is a data-plane pulls it on demand. This has consequences concerning the
push architecture, where the required network state is pushed by propagation of xTRs reachability/liveness information since pull
means of BGP UPDATE messages to BGP speakers. In push architectures, architectures require explicit mechanisms to propagate this
reachability information is also pushed to the interested routers. information. As a result LISP defines a set of mechanisms to inform
However pull architectures require explicit mechanisms to propagate
reachability information. LISP defines a set of mechanisms to inform
ITRs and PITRS about the reachability of the cached RLOCs: ITRs and 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 of the ETR site are up/down. This ETRs to specify which RLOCs of the ETR site are up/down. This
information can be used by the ITRs as a hint about the reachability information can be used by the ITRs as a hint about the reachability
to perform additional checks. Also note that LSB does not provide to perform additional checks. Also note that LSB does not provide
path 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
skipping to change at page 18, line 49 skipping to change at page 18, line 4
Stateless: With this mechanism the effective MTU is assumed from the Stateless: With this mechanism the effective MTU is assumed from the
ITR's perspective. If a payload packet is too big for the ITR's perspective. If a payload packet is too big for the
effective MTU, and can be fragmented, the payload packet is effective MTU, and can be fragmented, the payload packet is
fragmented on the ITR, such that reassembly is performed at the fragmented on the ITR, such that reassembly is performed at the
destination host. 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. ITRs will send ICMP Too Big packets sent by intermediate routers. ITRs will send ICMP Too Big
messages to inform the sources about the effective MTU. messages to inform the sources about the effective MTU.
Additionally ITRs can use mechanisms such as PMTUD [RFC1191] or Additionally ITRs can use mechanisms such as PMTUD [RFC1191] or
PLPMTUD [RFC4821] to keep track of the MTU towards the locators. PLPMTUD [RFC4821] to keep track of the MTU towards the locators.
In both cases if the packet cannot be fragmented (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.
5. Mobility 5. Mobility
The separation between locators and identifiers in LISP was initially The separation between locators and identifiers in LISP is suitable
proposed for traffic engineering purpose where LISP sites can change for traffic engineering purpose where LISP sites can change their
their attachment points to the Internet (i.e., RLOCs) without attachment points to the Internet (i.e., RLOCs) without impacting
impacting endpoints or the Internet core. In this context, the endpoints or the Internet core. In this context, the border routers
border routers operate the xTR functionality and endpoints are not operate the xTR functionality and endpoints are not aware of the
aware of the existence of LISP. This functionality is similar to existence of LISP. This functionality is similar to Network Mobility
Network Mobility [RFC3963]. However, this mode of operation does not [RFC3963]. However, this mode of operation does not allow seamless
allow seamless mobility of endpoints between different LISP sites as mobility of endpoints between different LISP sites as the EID address
the EID address might not be routable in a visited site. might not be routable in a visited site. Nevertheless, LISP can be
Nevertheless, LISP can be used to enable seamless IP mobility when used to enable seamless IP mobility when LISP is directly implemented
LISP is directly implemented in the endpoint or when the endpoint in the endpoint or when the endpoint roams to an attached xTR. Each
roams to an attached xTR. Each endpoint is then an xTR and the EID endpoint is then an xTR and the EID address is the one presented to
address is the one presented to the network stack used by the network stack used by applications while the RLOC is the address
applications while the RLOC is the address gathered from the network gathered from the network when it is visited. This functionality is
when it is visited. This functionality is similar to Mobile IP similar to Mobile IP ([RFC5944] and [RFC6275]).
([RFC5944] and [RFC6275]).
Whenever the device changes of RLOC, the xTR updates the RLOC of its Whenever the device changes of RLOC, the xTR updates the RLOC of its
local mapping and registers it to its Map-Server, typically with a local mapping and registers it to its Map-Server, typically with a
low TTL value (1min). To avoid the need of a home gateway, the ITR low TTL value (1min). To avoid the need of a home gateway, the ITR
also indicates the RLOC change to all remote devices that have also indicates the RLOC change to all remote devices that have
ongoing communications with the device that moved. The combination ongoing communications with the device that moved. The combination
of both methods ensures the scalability of the system as signaling is of both methods ensures the scalability of the system as signaling is
strictly limited the Map-Server and to hosts with which strictly limited the Map-Server and to hosts with which
communications are ongoing. In the mobility case the EID-prefix can communications are ongoing. In the mobility case the EID-prefix can
be as small as a full /32 or /128 (IPv4 or IPv6 respectively) be as small as a full /32 or /128 (IPv4 or IPv6 respectively)
skipping to change at page 20, line 42 skipping to change at page 19, line 43
general different, unless in specific cases where the underlay general different, unless in specific cases where the underlay
provider implements a tight control on the overlay. LISP provider implements a tight control on the overlay. LISP
specifications already support all PIM modes [RFC6831]. specifications already support all PIM modes [RFC6831].
Additionally, LISP can support as well non-PIM mechanisms in order to Additionally, LISP can support as well non-PIM mechanisms in order to
maintain multicast state. maintain multicast state.
7. Use Cases 7. Use Cases
7.1. Traffic Engineering 7.1. Traffic Engineering
BGP is the standard protocol to implement inter-domain routing. With A LISP site can strictly impose via which ETRs the traffic must enter
BGP, routing information are propagated along the network and each the the LISP site network even though the path followed to reach the
autonomous system can implement its own routing policy that will ETR is not under the control of the LISP site. This fine control is
influence the way routing information are propagated. The direct implemented with the mappings. When a remote site is willing to send
consequence is that an autonomous system cannot precisely control the traffic to a LISP site, it retrieves the mapping associated to the
way the traffic will enter the network. destination EID via the mapping system. The mapping is sent directly
by an authoritative ETR of the EID and is not altered by any
As opposed to BGP, a LISP site can strictly impose via which ETRs the intermediate network.
traffic must enter the the LISP site network even though the path
followed to reach 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 send traffic to a LISP site, it retrieves the
mapping associated to the destination EID via the mapping system.
The mapping is sent directly by an authoritative ETR of the EID and
is not altered by any intermediate network.
A mapping associates a list of RLOCs to an EID prefix. Each RLOC A mapping associates a list of RLOCs to an EID prefix. Each RLOC
corresponds to an interface of an ETR (or set of ETRs) that is able corresponds to an interface of an ETR (or set of ETRs) that is able
to correctly forward packets to EIDs in the prefix. Each RLOC is to correctly forward packets to EIDs in the prefix. Each RLOC is
tagged with a priority and a weight in the mapping. The priority is tagged with a priority and a weight in the mapping. The priority is
used to indicates which RLOCs should be preferred to send packets used to indicates which RLOCs should be preferred to send packets
(the least preferred ones being provided for backup purpose). The (the least preferred ones being provided for backup purpose). The
weight permits to balance the load between the RLOCs with the same weight permits to balance the load between the RLOCs with the same
priority, proportionally to the weight value. priority, proportionally to the weight value.
As mappings are directly issued by the authoritative ETR of the EID As mappings are directly issued by the authoritative ETR of the EID
and are not altered while transmitted to the remote site, it offers and are not altered while transmitted to the remote site, it offers
highly flexible incoming inter-domain traffic engineering with even highly flexible incoming inter-domain traffic engineering with even
the possibility for a site to issue a different mapping for each the possibility for a site to support a different mapping policy for
remote site, implementing so precise routing policies. each remote site. routing policies.
7.2. LISP for IPv6 Co-existence 7.2. LISP for IPv6 Co-existence
LISP encapsulations allows to transport packets using EIDs from a LISP encapsulations allows to transport packets using EIDs from a
given address family (e.g., IPv6) with packets from other address given address family (e.g., IPv6) with packets from other address
families (e.g., IPv4). The absence of correlation between the families (e.g., IPv4). The absence of correlation between the
address family of RLOCs and EIDs makes LISP a candidate to allow, address family of RLOCs and EIDs makes LISP a candidate to allow,
e.g., IPv6 to be deployed when all of the core network may not have e.g., IPv6 to be deployed when all of the core network may not have
IPv6 enabled. IPv6 enabled.
skipping to change at page 22, line 30 skipping to change at page 21, line 26
To inform the other LISP routers that the machine moved and where, To inform the other LISP routers that the machine moved and where,
and then to avoid detours via the initial subnetwork, mechanisms such and then to avoid detours via the initial subnetwork, mechanisms such
as the Solicit-Map-Request messages are used. as the Solicit-Map-Request messages are used.
8. Security Considerations 8. Security Considerations
This section describes the security considerations associated to the This section describes the security considerations associated to the
LISP protocol. LISP protocol.
LISP uses a pull architecture to learn mappings. While in a push While in a push mapping system, the state necessary to forward
system, the state necessary to forward packets is learned packets is learned independently of the traffic itself, with a pull
independently of the traffic itself, with a pull architecture, the architecture, the system becomes reactive and data-plane events
system becomes reactive and data-plane events (e.g., the arrival of a (e.g., the arrival of a packet for an unknown destination) may
packet for an unknown destination) may trigger control-plane events. trigger control-plane events. This on-demand learning of mappings
This on-demand learning of mappings provides many advantages as provides many advantages as discussed above but may also affect the
discussed above but may also affect the way security is enforced. way security is enforced.
Usually, the data-plane is implemented in the fast path of routers to Usually, the data-plane is implemented in the fast path of routers to
provide high performance forwarding capabilities while the control- provide high performance forwarding capabilities while the control-
plane features are implemented in the slow path to offer high plane features are implemented in the slow path to offer high
flexibility and a performance gap of several order of magnitude can flexibility and a performance gap of several order of magnitude can
be observed between the slow and the fast paths. As a consequence, be observed between the slow and the fast paths. As a consequence,
the way data-plane events are notified to the control-plane must be the way data-plane events are notified to the control-plane must be
thought carefully so to not overload the slow path and rate limiting thought carefully so to not overload the slow path and rate limiting
should be used as specified in [RFC6830]. should be used as specified in [RFC6830].
skipping to change at page 23, line 17 skipping to change at page 22, line 13
reachabilty of locators, directly into data plane packets. In reachabilty of locators, directly into data plane packets. In
environments that are not fully trusted, control information gleaned environments that are not fully trusted, control information gleaned
from data-plane packets should be verified before using them. from data-plane packets should be verified before using them.
Mappings are the centrepiece of LISP and all precautions must be Mappings are the centrepiece of LISP and all precautions must be
taken to avoid them to be manipulated or misused by malicious taken to avoid them to be manipulated or misused by malicious
entities. Using trustable Map-Servers that strictly respect entities. Using trustable Map-Servers that strictly respect
[RFC6833] and the lightweight authentication mechanism proposed by [RFC6833] and the lightweight authentication mechanism proposed by
LISP-Sec [I-D.ietf-lisp-sec] reduces the risk of attacks to the LISP-Sec [I-D.ietf-lisp-sec] reduces the risk of attacks to the
mapping integrity. In more critical environments, secure measures mapping integrity. In more critical environments, secure measures
may be needed. may be needed. The way security is implemented for a given mapping
system strongly depends on the architecture of the mapping system
itself and the threat model assumed for the deployment. Thus, the
mapping system security has to be discussed in the relevant documents
proposing the mapping system architecture.
As with any other tunneling mechanism, middleboxes on the path As with any other tunneling mechanism, middleboxes on the path
between an ITR (or PITR) and an ETR (or PETR) must implement between an ITR (or PITR) and an ETR (or PETR) must implement
mechanisms to strip the LISP encapsulation to correctly inspect the mechanisms to strip the LISP encapsulation to correctly inspect the
content of LISP encapsulated packets. content of LISP encapsulated packets.
Like other map-and-encap mechanisms, LISP enables triangular routing Like other map-and-encap mechanisms, LISP enables triangular routing
(i.e., packets of a flow cross different border routers depending on (i.e., packets of a flow cross different border routers depending on
their direction). This means that intermediate boxes may have their direction). This means that intermediate boxes may have
incomplete view on the traffic they inspect or manipulate. Moreover, incomplete view on the traffic they inspect or manipulate. Moreover,
skipping to change at page 24, line 11 skipping to change at page 23, line 11
The authors would also like to thank Dino Farinacci, Fabio Maino, The authors would also like to thank Dino Farinacci, Fabio Maino,
Luigi Iannone, Sharon Barkai, Isidoros Kouvelas, Christian Cassar, Luigi Iannone, Sharon Barkai, Isidoros Kouvelas, Christian Cassar,
Florin Coras, Marc Binderberger, Alberto Rodriguez-Natal, Ronald Florin Coras, Marc Binderberger, Alberto Rodriguez-Natal, Ronald
Bonica, Chad Hintz, Robert Raszuk, Joel M. Halpern, Darrel Lewis, Bonica, Chad Hintz, Robert Raszuk, Joel M. Halpern, Darrel Lewis,
David Black as well as every people acknowledged in [RFC6830]. David Black as well as every people acknowledged in [RFC6830].
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
Delegated Database Tree", draft-ietf-lisp-ddt-02 (work in
progress), October 2014.
[I-D.ietf-lisp-lcaf]
Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", draft-ietf-lisp-lcaf-07 (work in
progress), December 2014.
[I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-07
(work in progress), October 2014.
[I-D.ietf-lisp-threats]
Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats
Analysis", draft-ietf-lisp-threats-12 (work in progress),
March 2015.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990. November 1990.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", BCP E. Lear, "Address Allocation for Private Internets", BCP
5, RFC 1918, February 1996. 5, RFC 1918, February 1996.
[RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path [RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path
Algorithm", RFC 2992, November 2000. Algorithm", RFC 2992, November 2000.
skipping to change at page 25, line 40 skipping to change at page 25, line 15
[RFC7052] Schudel, G., Jain, A., and V. Moreno, "Locator/ID [RFC7052] Schudel, G., Jain, A., and V. Moreno, "Locator/ID
Separation Protocol (LISP) MIB", RFC 7052, October 2013. Separation Protocol (LISP) MIB", RFC 7052, October 2013.
[RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
Pascual, J., and D. Lewis, "Locator/Identifier Separation Pascual, J., and D. Lewis, "Locator/Identifier Separation
Protocol (LISP) Network Element Deployment Protocol (LISP) Network Element Deployment
Considerations", RFC 7215, April 2014. Considerations", RFC 7215, April 2014.
11.2. Informative References 11.2. Informative References
[Chiappa] Chiappa, J., "Endpoints and Endpoint names: A Propose
Enhancement to the Internet Architecture,
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.
[I-D.cheng-lisp-shdht] [I-D.cheng-lisp-shdht]
Cheng, L. and J. Wang, "LISP Single-Hop DHT Mapping Cheng, L. and J. Wang, "LISP Single-Hop DHT Mapping
Overlay", draft-cheng-lisp-shdht-04 (work in progress), Overlay", draft-cheng-lisp-shdht-04 (work in progress),
July 2013. July 2013.
[I-D.curran-lisp-emacs] [I-D.curran-lisp-emacs]
Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID
Mappings Multicast Across Cooperating Systems for LISP", Mappings Multicast Across Cooperating Systems for LISP",
draft-curran-lisp-emacs-00 (work in progress), November draft-curran-lisp-emacs-00 (work in progress), November
2007. 2007.
[I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
Delegated Database Tree", draft-ietf-lisp-ddt-02 (work in
progress), October 2014.
[I-D.ietf-lisp-lcaf]
Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", draft-ietf-lisp-lcaf-07 (work in
progress), December 2014.
[I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-07
(work in progress), October 2014.
[I-D.ietf-lisp-threats]
Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats
Analysis", draft-ietf-lisp-threats-11 (work in progress),
December 2014.
[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.
[Mathy] Mathy, L., Iannone, L., and O. Bonaventure, "LISP-DHT: [Mathy] Mathy, L., Iannone, L., and O. Bonaventure, "LISP-DHT:
Towards a DHT to map identifiers onto locators. The ACM Towards a DHT to map identifiers onto locators. The ACM
ReArch, Re-Architecting the Internet. Madrid (Spain)", ReArch, Re-Architecting the Internet. Madrid (Spain)",
December 2008. December 2008.
[Quoitin] Quoitin, B., Iannone, L., Launois, C., and O. Bonaventure, [Quoitin] Quoitin, B., Iannone, L., Launois, C., and O. Bonaventure,
""Evaluating the Benefits of the Locator/Identifier ""Evaluating the Benefits of the Locator/Identifier
Separation" in Proceedings of 2Nd ACM/IEEE International Separation" in Proceedings of 2Nd ACM/IEEE International
Workshop on Mobility in the Evolving Internet Workshop on Mobility in the Evolving Internet
Architecture", 2007. Architecture", 2007.
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 architecture for separation of location and identity
the discussions of this topic at the Amsterdam IAB Routing and resulted from the discussions of this topic at the Amsterdam IAB
Addressing Workshop, which took place in October 2006 [RFC4984]. Routing and 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 spontaneously formed
locations within Cisco, spontaneously formed immediately after that immediately after that workshop, to work on an idea that came out of
workshop, to work on an idea that came out of informal discussions at informal discussions at the workshop and on various mailing lists.
the workshop and on various mailing lists. The first Internet-Draft The first Internet-Draft on LISP appeared in January, 2007.
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 initially conceived, had a number of potential operating LISP, as initially conceived, had a number of potential operating
modes, named 'models'. Although they are not used anymore, one modes, named 'models'. Although they are no 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. 37 change blocks. 
201 lines changed or deleted 188 lines changed or added

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