draft-ietf-lisp-introduction-13.txt   draft-ietf-lisp-introduction-14.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: October 4, 2015 INRIA Expires: 4 March 2022 Inria
April 02, 2015 31 August 2021
An Architectural Introduction to the Locator/ID Separation Protocol An Architectural Introduction to the Locator/ID Separation Protocol
(LISP) (LISP)
draft-ietf-lisp-introduction-13.txt draft-ietf-lisp-introduction-14
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.
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 4, 2015. This Internet-Draft will expire on 4 March 2022.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(http://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . 5 3.2. Overview of the Architecture . . . . . . . . . . . . . . 6
3.3. Data-Plane . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Data-Plane . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1. LISP Encapsulation . . . . . . . . . . . . . . . . . 8 3.3.1. LISP Encapsulation . . . . . . . . . . . . . . . . . 9
3.3.2. LISP Forwarding State . . . . . . . . . . . . . . . . 10 3.3.2. LISP Forwarding State . . . . . . . . . . . . . . . . 10
3.4. Control-Plane . . . . . . . . . . . . . . . . . . . . . . 10 3.4. Control-Plane . . . . . . . . . . . . . . . . . . . . . . 11
3.4.1. LISP Mappings . . . . . . . . . . . . . . . . . . . . 10 3.4.1. LISP Mappings . . . . . . . . . . . . . . . . . . . . 11
3.4.2. Mapping System Interface . . . . . . . . . . . . . . 11 3.4.2. Mapping System Interface . . . . . . . . . . . . . . 11
3.4.3. Mapping System . . . . . . . . . . . . . . . . . . . 11 3.4.3. Mapping System . . . . . . . . . . . . . . . . . . . 12
3.5. Internetworking Mechanisms . . . . . . . . . . . . . . . 14 3.5. Internetworking Mechanisms . . . . . . . . . . . . . . . 15
4. LISP Operational Mechanisms . . . . . . . . . . . . . . . . . 15 4. LISP Operational Mechanisms . . . . . . . . . . . . . . . . . 16
4.1. Cache Management . . . . . . . . . . . . . . . . . . . . 15 4.1. Cache Management . . . . . . . . . . . . . . . . . . . . 16
4.2. RLOC Reachability . . . . . . . . . . . . . . . . . . . . 16 4.2. RLOC Reachability . . . . . . . . . . . . . . . . . . . . 17
4.3. ETR Synchronization . . . . . . . . . . . . . . . . . . . 17 4.3. ETR Synchronization . . . . . . . . . . . . . . . . . . . 18
4.4. MTU Handling . . . . . . . . . . . . . . . . . . . . . . 17 4.4. MTU Handling . . . . . . . . . . . . . . . . . . . . . . 18
5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 19 7.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 20
7.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . 20 7.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . 21
7.3. LISP for Virtual Private Networks . . . . . . . . . . . . 20 7.3. LISP for Virtual Private Networks . . . . . . . . . . . . 21
7.4. LISP for Virtual Machine Mobility in Data Centers . . . . 21 7.4. LISP for Virtual Machine Mobility in Data Centers . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. A Brief History of Location/Identity Separation . . 25 Appendix A. A Brief History of Location/Identity Separation . . 27
A.1. Old LISP Models . . . . . . . . . . . . . . . . . . . . . 26 A.1. Old LISP Models . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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 Noel Chiappa [RFC4984], semantics. Indeed and as pointed out by Noel Chiappa [RFC4984],
currently IP addresses both identify the topological location of a currently IP addresses both identify the topological location of a
network attachment point as well as the node's identity. However, network attachment point as well as the node's identity. However,
nodes and routing have fundamentally different requirements, routing nodes and routing have fundamentally different requirements. On the
systems require that addresses are aggregatable and have topological one hand, routing systems require that addresses are aggregatable and
meaning, while nodes require to be identified independently of their have topological meaning, on the other hand nodes require to be
current location [RFC4984]. identified independently of their 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 syntactically identical to the RLOCs (Routing LOCators), both are syntactically identical to the
current IPv4 and IPv6 addresses. EIDs are used to uniquely identify current IPv4 and IPv6 addresses. However, EIDs are used to uniquely
nodes irrespective of their topological location and are typically identify nodes irrespective of their topological location and are
routed intra-domain. RLOCs are assigned topologically to network typically routed intra-domain. RLOCs are assigned topologically to
attachment points and are typically routed inter-domain. With LISP, network attachment points and are typically routed inter-domain.
the edge of the Internet (where the nodes are connected) and the core With LISP, the edge of the Internet (where the nodes are connected)
(where inter-domain routing occurs) can be logically separated and and the core (where inter-domain routing occurs) can be logically
interconnected by LISP-capable routers. LISP also introduces a separated. LISP-capable routers interconnect the two logical spaces.
database, called the Mapping System, to store and retrieve mappings LISP also introduces a database, called the Mapping System, to store
between identity and location. LISP-capable routers exchange packets and retrieve mappings between identity and location. LISP-capable
over the Internet core by encapsulating them to the appropriate routers exchange packets over the Internet core by encapsulating them
location. to the appropriate location.
In summary: In summary:
o RLOCs have meaning only in the underlay network, that is the * 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, which is the * EIDs have meaning only in the overlay network, which is the
encapsulation relationship between LISP-capable routers. encapsulation relationship between LISP-capable routers.
o The LISP edge maps EIDs to RLOCs * The LISP edge maps EIDs to RLOCs
o Within the underlay network, RLOCs have both locator and * 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 * 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 * 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 and 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 were to be routing scalability problem [RFC4984], where, if LISP were to be
completely deployed, the Internet core is populated with RLOCs while completely deployed, the Internet core would be populated with RLOCs
Traffic Engineering mechanisms are pushed to the Mapping System. In while Traffic Engineering mechanisms would be pushed to the Mapping
such scenario RLOCs are quasi-static (i.e., low churn), hence making System. In such scenario RLOCs are quasi-static (i.e., low churn),
the routing system scalable [Quoitin], while EIDs can roam anywhere hence making the routing system scalable [Quoitin], while EIDs can
with no churn to the underlying routing system. [RFC7215] discusses roam anywhere with no churn to the underlying global routing system.
the impact of LISP on the global routing system during the transition [RFC7215] discusses the impact of LISP on the global routing system
period. However, the separation between location and identity that during the transition period. However, the separation between
LISP offers makes it suitable for use in additional scenarios such as location and identity that LISP offers makes it suitable for use in
Traffic Engineering (TE), multihoming, and mobility among others. additional scenarios such as Traffic Engineering (TE), multihoming,
and mobility among others.
This document describes the LISP architecture and its main This document describes the LISP architecture and its main
operational mechanisms as well as its design rationale. It is operational mechanisms as well as its design rationale. It is
important to note that this document does not specify or complement important to note that this document does not specify or complement
the LISP protocol. The interested reader should refer to the main the LISP protocol. The interested reader should refer to the main
LISP specifications [RFC6830] and the complementary documents LISP specifications [RFC6830] and the complementary documents
[RFC6831], [RFC6832], [RFC6833], [RFC6834], [RFC6835], [RFC6836], [RFC6831], [RFC6832], [RFC6833], [RFC6834], [RFC6835], [RFC6836],
[RFC7052] for the protocol specifications along with the LISP [RFC7052] for the protocol specifications along with the LISP
deployment guidelines [RFC7215]. deployment guidelines [RFC7215].
skipping to change at page 5, line 21 skipping to change at page 5, line 28
This section presents the LISP architecture, it first details the This section presents the LISP architecture, it first details the
design principles of LISP and then it proceeds to describe its main design principles of LISP and then it proceeds to describe its main
aspects: data-plane, control-plane, and 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 * 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 topologically 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 * 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 * Decoupled data-plane and control-plane: Separating the data-plane
the control-plane allows them to scale independently and use from 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 and allows for other they typically have different requirements and allows for other
data-planes to be added. While decoupled, data and control-plane data-planes to be added. Even though the data-plane and the
are not completely isolated because the LISP data-plane may control-plane are decoupled, they are not completely isolated
trigger control-plane activity. because the LISP data-plane may trigger control-plane activity.
o Incremental deployability: This principle ensures that the * 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 IPv4 or IPv6 Autonomous System) that use EID addresses. EIDs are IPv4 or IPv6
addresses that uniquely identify communication end-hosts and are addresses that uniquely identify communication end-hosts and are
assigned and configured by the same mechanisms that exist at the time assigned and configured by the same mechanisms that exist at the time
of this writing. EIDs do not contain inter-domain topological of this writing. EIDs do not contain inter-domain topological
information and because of this, EIDs are usually routable at the information and because of this, EIDs are usually routable at the
edge (within LISP sites) or in the non-LISP Internet; see Section 3.5 edge (within LISP sites) but not in the core; see Section 3.5 for
for discussion of LISP site internetworking with non-LISP sites and discussion of LISP site internetworking with non-LISP sites and
domains in the Internet. domains in the Internet.
LISP sites (at the edge of the Internet) are connected to the core of LISP sites (at the edge of the Internet) are connected to the core of
the Internet by means of LISP-capable routers (e.g., border routers). the Internet by means of LISP-capable routers (e.g., border routers).
LISP sites are connected across the core of the Internet using LISP sites are connected across the core of the Internet using
tunnels between the LISP-capable routers. When packets originated tunnels between the LISP-capable routers. When packets originated
from a LISP site are flowing towards the core network, they ingress from a LISP site are flowing towards the core network, they ingress
into an encapsulated tunnel via an Ingress Tunnel Router (ITR). When into an encapsulated tunnel via an Ingress Tunnel Router (ITR). When
packets flow from the core network to a LISP site, they egress from packets flow from the core network to a LISP site, they egress from
an encapsulated tunnel to an Egress Tunnel Router (ETR). An xTR is a an encapsulated tunnel to an Egress Tunnel Router (ETR). An xTR is a
skipping to change at page 7, line 19 skipping to change at page 7, line 25
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 space with the RLOC
Additionally, LISP requires the deployment of an independent Mapping space. Additionally, LISP requires the deployment of an independent
System, such distributed database is a new network entity. 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 21 skipping to change at page 8, line 44
standard intra-domain mechanisms. standard intra-domain mechanisms.
3. ITR_A upon receiving the packet queries the Mapping System to 3. ITR_A upon receiving the packet queries the Mapping System to
retrieve the locator of ETR_B that is servicing HostB's EID_B. retrieve the locator of ETR_B that is servicing HostB's EID_B.
In order to do so it uses a LISP control message called Map- In order to do so it uses a LISP control message called Map-
Request, the message contains EID_B as the lookup key. In turn Request, the message contains EID_B as the lookup key. In turn
it receives another LISP control message called Map-Reply, the it receives another LISP control message called Map-Reply, the
message contains two locators: RLOC_B1 and RLOC_B2 along with message contains two locators: RLOC_B1 and RLOC_B2 along with
traffic engineering policies: priority and weight per locator. traffic engineering policies: priority and weight per locator.
Note that a Map-Reply can contain more locators if needed. ITR_A Note that a Map-Reply can contain more locators if needed. ITR_A
also stores the mapping in a local cache to speed-up forwarding can cache the mapping in a local storage to speed-up forwarding
of subsequent packets. 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_B1 as destination, the inner original header has EID_A and RLOC_B1 as destination, the inner original header has EID_A
as source and EID_B as destination. Furthermore ITR_A adds a as source and EID_B as destination. Furthermore ITR_A adds a
LISP header, more details about LISP encapsulation can be found LISP header, more details about LISP encapsulation can be found
in Section 3.3.1. in Section 3.3.1.
skipping to change at page 11, line 16 skipping to change at page 11, line 44
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 limited to Map-Servers. This setup is useful when the ETR has limited
resources (i.e., CPU or power). resources (e.g., 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 cases ITRs with the Mapping System by proxying queries and in some cases
responses. responses.
The interface defines four LISP control messages which are sent as The interface defines four LISP control messages which are sent as
UDP datagrams (port 4342): UDP datagrams (port 4342):
Map-Register: This message is used by ETRs to register mappings in Map-Register: This message is used by ETRs to register mappings in
the Mapping System and it is authenticated using a shared key the Mapping System and it is authenticated using a shared key
skipping to change at page 11, line 50 skipping to change at page 12, line 30
to a Map-Request and contains the resolved mapping. Please note to a Map-Request and contains the resolved mapping. Please note
that a Map-Reply may contain a negative reply if, for example, the that a Map-Reply may contain a negative reply if, for example, the
queried EID is not part of the LISP EID space. In such cases the queried EID is not part of the LISP EID space. In such cases the
ITR typically forwards the traffic natively (non encapsulated) to ITR typically forwards the traffic natively (non encapsulated) to
the public Internet, this behavior is defined to support the public Internet, this behavior is defined to support
incremental deployment of LISP. incremental deployment of LISP.
3.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 for forwarding data-packets, with the LISP Mapping responsible for forwarding data-packets - with the LISP Mapping
System, a database responsible for 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 to 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
skipping to change at page 13, line 4 skipping to change at page 13, line 33
Map-Server responsible for the mapping. Upon reception the Map- Map-Server responsible for the mapping. Upon reception the Map-
Server forwards the request to the ETR that in turn, replies directly Server forwards the request to the ETR that in turn, replies directly
to the ITR using the native Internet core. to the ITR using the native Internet core.
3.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 which is a particular instance of a DDT node and that matches the
matches the entire address space. As in the case of DNS, DDT entire address space. As in the case of DNS, DDT supports multiple
supports multiple redundant DDT nodes and/or DDT roots. Finally, redundant DDT nodes and/or DDT roots. Finally, Map-Resolvers are the
Map-Resolvers are the clients of the DDT hierarchy and can query clients of the DDT hierarchy and can query either the DDT root and/or
either the DDT root and/or other DDT nodes. other DDT nodes.
/---------\ /---------\
| | | |
| DDT Root| | DDT Root|
| /0 | | /0 |
,.\---------/-, ,.\---------/-,
,-'` | `'., ,-'` | `'.,
-'` | `- -'` | `-
/-------\ /-------\ /-------\ /-------\ /-------\ /-------\
| DDT | | DDT | | DDT | | DDT | | DDT | | DDT |
skipping to change at page 14, line 12 skipping to change at page 15, line 6
node that has more specific information about the queried XEID- node that has more specific information about the queried XEID-
prefix. This process is repeated until the DDT client walks the tree prefix. This process is repeated until the DDT client walks the tree
structure (downwards) and discovers the Map-Server servicing the structure (downwards) and discovers the Map-Server servicing the
queried XEID. At this point the client sends a Map-Request and queried XEID. At this point the client sends a Map-Request and
receives a Map-Reply containing the mappings. It is important to receives a Map-Reply containing the mappings. It is important to
note that DDT clients can also cache the information contained in note that DDT clients can also cache the information contained in
Map-Referrals, that is, they cache the DDT structure. This is used Map-Referrals, that is, they cache the DDT structure. This is used
to reduce the mapping 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 configured with the set of available DDT root nodes
nodes while DDT nodes are manually configured with the appropriate while DDT nodes are configured with the appropriate XEID delegations.
XEID delegations. Configuration changes in the DDT nodes are only Configuration changes in the DDT nodes are only required when the
required when the tree structure changes itself, but it doesn't tree structure changes itself, but it doesn't depend on EID dynamics
depend on EID dynamics (RLOC allocation or traffic engineering policy (RLOC allocation or traffic engineering policy changes).
changes).
3.5. Internetworking Mechanisms 3.5. Internetworking 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 stored in the LISP Mapping System, however they are usually they are stored in the LISP Mapping System, however they are usually
not announced in the Internet global routing system. As a result not announced in the Internet global routing system. As a result
LISP requires an internetworking mechanism to allow LISP sites to LISP requires an internetworking mechanism to allow LISP sites to
speak with non-LISP sites and vice versa. LISP internetworking speak with non-LISP sites and vice versa. LISP internetworking
mechanisms are specified in [RFC6832]. mechanisms are specified in [RFC6832].
skipping to change at page 16, line 6 skipping to change at page 16, line 49
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
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 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. Further details are available in [RFC6834].
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
In most cases LISP operates with a pull-based Mapping System (e.g., In most cases LISP operates with a pull-based Mapping System (e.g.,
DDT), this results in an edge to edge pull architecture. In such DDT), this results in an edge to edge pull architecture. In such
scenario the network state is stored in the control-plane while the scenario the network state is stored in the control-plane while the
skipping to change at page 20, line 51 skipping to change at page 21, line 51
tags or labels are used for that purpose. When using LISP, the tags or labels are used for that purpose. When using LISP, the
distinction can be made with the Instance ID field. When an ITR distinction can be made with the Instance ID field. When an ITR
encapsulates a packet from a particular virtual network (e.g., known encapsulates a packet from a particular virtual network (e.g., known
via the VRF or VLAN), it tags the encapsulated packet with the via the VRF or VLAN), it tags the encapsulated packet with the
Instance ID corresponding to the virtual network of the packet. When Instance ID corresponding to the virtual network of the packet. When
an ETR receives a packet tagged with an Instance ID it uses the an ETR receives a packet tagged with an Instance ID it uses the
Instance ID to determine how to treat the packet. Instance ID to determine how to treat the packet.
The main usage of LISP for virtual private networks does not The main usage of LISP for virtual private networks does not
introduce additional requirements on the underlying network, as long introduce additional requirements on the underlying network, as long
as it is running IP. as it runs IP.
7.4. LISP for Virtual Machine Mobility in Data Centers 7.4. LISP for Virtual Machine Mobility in Data Centers
A way to enable seamless virtual machine mobility in data center is A way to enable seamless virtual machine mobility in data center is
to conceive the datacenter backbone as the RLOC space and the subnet to conceive the datacenter backbone as the RLOC space and the subnet
where servers are hosted as forming the EID space. A LISP router is where servers are hosted as forming the EID space. A LISP router is
placed at the border between the backbone and each subnet. When a placed at the border between the backbone and each subnet. When a
virtual machine is moved to another subnet, it can keep (temporarily) virtual machine is moved to another subnet, it can keep (temporarily)
the address it had before the move so to continue without a transport the address it had before the move so to continue without a transport
layer connection reset. When an xTR detects a source address layer connection reset. When an xTR detects a source address
skipping to change at page 23, line 12 skipping to change at page 24, line 16
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] [I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
Delegated Database Tree", draft-ietf-lisp-ddt-02 (work in Smirnov, "Locator/ID Separation Protocol Delegated
progress), October 2014. Database Tree (LISP-DDT)", Work in Progress, Internet-
Draft, draft-ietf-lisp-ddt-09, 18 January 2017,
<https://www.ietf.org/archive/id/draft-ietf-lisp-ddt-
09.txt>.
[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-07 (work in Address Format (LCAF)", Work in Progress, Internet-Draft,
progress), December 2014. draft-ietf-lisp-lcaf-22, 28 November 2016,
<https://www.ietf.org/archive/id/draft-ietf-lisp-lcaf-
22.txt>.
[I-D.ietf-lisp-sec] [I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Maino, F., Ermagan, V., Cabellos, A., and D. Saucez,
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-07 "LISP-Security (LISP-SEC)", Work in Progress, Internet-
(work in progress), October 2014. Draft, draft-ietf-lisp-sec-22, 12 January 2021,
<https://www.ietf.org/archive/id/draft-ietf-lisp-sec-
22.txt>.
[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, "Locator/ID
Analysis", draft-ietf-lisp-threats-12 (work in progress), Separation Protocol (LISP) Threat Analysis", Work in
March 2015. Progress, Internet-Draft, draft-ietf-lisp-threats-15, 29
January 2016, <https://www.ietf.org/archive/id/draft-ietf-
lisp-threats-15.txt>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990. DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
E. Lear, "Address Allocation for Private Internets", BCP J., and E. Lear, "Address Allocation for Private
5, RFC 1918, February 1996. Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[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, DOI 10.17487/RFC2992, November 2000,
<https://www.rfc-editor.org/info/rfc2992>.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced
an On-line Database", RFC 3232, January 2002. by an On-line Database", RFC 3232, DOI 10.17487/RFC3232,
January 2002, <https://www.rfc-editor.org/info/rfc3232>.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol", Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005. RFC 3963, DOI 10.17487/RFC3963, January 2005,
<https://www.rfc-editor.org/info/rfc3963>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007. Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>.
[RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report
Workshop on Routing and Addressing", RFC 4984, September from the IAB Workshop on Routing and Addressing",
2007. RFC 4984, DOI 10.17487/RFC4984, September 2007,
<https://www.rfc-editor.org/info/rfc4984>.
[RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", RFC [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised",
5944, November 2010. RFC 5944, DOI 10.17487/RFC5944, November 2010,
<https://www.rfc-editor.org/info/rfc5944>.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
in IPv6", RFC 6275, July 2011. Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/info/rfc6275>.
[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,
2013. DOI 10.17487/RFC6830, January 2013,
<https://www.rfc-editor.org/info/rfc6830>.
[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
Locator/ID Separation Protocol (LISP) for Multicast Locator/ID Separation Protocol (LISP) for Multicast
Environments", RFC 6831, January 2013. Environments", RFC 6831, DOI 10.17487/RFC6831, January
2013, <https://www.rfc-editor.org/info/rfc6831>.
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking between Locator/ID Separation Protocol "Interworking between Locator/ID Separation Protocol
(LISP) and Non-LISP Sites", RFC 6832, January 2013. (LISP) and Non-LISP Sites", RFC 6832,
DOI 10.17487/RFC6832, January 2013,
<https://www.rfc-editor.org/info/rfc6832>.
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
Protocol (LISP) Map-Server Interface", RFC 6833, January Protocol (LISP) Map-Server Interface", RFC 6833,
2013. DOI 10.17487/RFC6833, January 2013,
<https://www.rfc-editor.org/info/rfc6833>.
[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", RFC 6834, Separation Protocol (LISP) Map-Versioning", RFC 6834,
January 2013. DOI 10.17487/RFC6834, January 2013,
<https://www.rfc-editor.org/info/rfc6834>.
[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,
DOI 10.17487/RFC6835, January 2013,
<https://www.rfc-editor.org/info/rfc6835>.
[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, DOI 10.17487/RFC6836,
January 2013, <https://www.rfc-editor.org/info/rfc6836>.
[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
Routing Locator (RLOC) Database", RFC 6837, January 2013. Routing Locator (RLOC) Database", RFC 6837,
DOI 10.17487/RFC6837, January 2013,
<https://www.rfc-editor.org/info/rfc6837>.
[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,
DOI 10.17487/RFC6935, April 2013,
<https://www.rfc-editor.org/info/rfc6935>.
[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, DOI 10.17487/RFC6936, April 2013,
<https://www.rfc-editor.org/info/rfc6936>.
[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,
DOI 10.17487/RFC7052, October 2013,
<https://www.rfc-editor.org/info/rfc7052>.
[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, DOI 10.17487/RFC7215, April
2014, <https://www.rfc-editor.org/info/rfc7215>.
11.2. Informative References 11.2. Informative References
[DDT-ROOT]
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", Work in Progress, Internet-Draft, draft-cheng-
July 2013. lisp-shdht-04, 15 July 2013, <http://www.ietf.org/
internet-drafts/draft-cheng-lisp-shdht-04.txt>.
[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 Work in Progress, Internet-Draft, draft-curran-lisp-emacs-
2007. 00, 9 November 2007,
<http://tools.ietf.org/html/draft-curran-lisp-emacs-00>.
[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.
skipping to change at page 27, line 10 skipping to change at page 28, line 43
Distributed Hash Tables). Two variants were possible: a 'push' Distributed Hash Tables). Two variants were possible: a 'push'
system, in which all mappings were distributed to all ITRs, and a system, in which all mappings were distributed to all ITRs, and a
'pull' system in which ITRs load the mappings they need, as 'pull' system in which ITRs load the mappings they need, as
needed. needed.
Authors' Addresses Authors' Addresses
Albert Cabellos Albert Cabellos
UPC-BarcelonaTech UPC-BarcelonaTech
c/ Jordi Girona 1-3 c/ Jordi Girona 1-3
Barcelona, Catalonia 08034 08034 Barcelona Catalonia
Spain Spain
Email: acabello@ac.upc.edu Email: acabello@ac.upc.edu
Damien Saucez (Ed.) Damien Saucez (Ed.)
INRIA Inria
2004 route des Lucioles BP 93 2004 route des Lucioles BP 93
Sophia Antipolis Cedex 06902 06902 Sophia Antipolis Cedex
France France
Email: damien.saucez@inria.fr Email: damien.saucez@inria.fr
 End of changes. 66 change blocks. 
158 lines changed or deleted 190 lines changed or added

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