draft-ietf-lisp-introduction-07.txt   draft-ietf-lisp-introduction-08.txt 
Network Working Group A. Cabellos Network Working Group A. Cabellos
Internet-Draft UPC-BarcelonaTech Internet-Draft UPC-BarcelonaTech
Intended status: Informational D. Saucez (Ed.) Intended status: Informational D. Saucez (Ed.)
Expires: April 27, 2015 INRIA Expires: May 16, 2015 INRIA
October 24, 2014 November 12, 2014
An Architectural Introduction to the Locator/ID Separation Protocol An Architectural Introduction to the Locator/ID Separation Protocol
(LISP) (LISP)
draft-ietf-lisp-introduction-07.txt draft-ietf-lisp-introduction-08.txt
Abstract Abstract
This document describes the architecture of the Locator/ID Separation This document describes the architecture of the Locator/ID Separation
Protocol (LISP), making it easier to read the rest of the LISP Protocol (LISP), making it easier to read the rest of the LISP
specifications and providing a basis for discussion about the details specifications and providing a basis for discussion about the details
of the LISP protocols. This document is used for introductory of the LISP protocols. This document is used for introductory
purposes, more details can be found in RFC6830, the protocol purposes, more details can be found in RFC6830, the protocol
specification. specification.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 27, 2015. This Internet-Draft will expire on May 16, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 21
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
3. LISP Architecture . . . . . . . . . . . . . . . . . . . . . . 4 3. LISP Architecture . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Design Principles . . . . . . . . . . . . . . . . . . . . 4 3.1. Design Principles . . . . . . . . . . . . . . . . . . . . 4
3.2. Overview of the Architecture . . . . . . . . . . . . . . 4 3.2. Overview of the Architecture . . . . . . . . . . . . . . 5
3.3. Data-Plane . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Data-Plane . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1. LISP Encapsulation . . . . . . . . . . . . . . . . . 7 3.3.1. LISP Encapsulation . . . . . . . . . . . . . . . . . 8
3.3.2. LISP Forwarding State . . . . . . . . . . . . . . . . 8 3.3.2. LISP Forwarding State . . . . . . . . . . . . . . . . 9
3.4. Control-Plane . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Control-Plane . . . . . . . . . . . . . . . . . . . . . . 9
3.4.1. LISP Mappings . . . . . . . . . . . . . . . . . . . . 9 3.4.1. LISP Mappings . . . . . . . . . . . . . . . . . . . . 10
3.4.2. Mapping System Interface . . . . . . . . . . . . . . 9 3.4.2. Mapping System Interface . . . . . . . . . . . . . . 10
3.4.3. Mapping System . . . . . . . . . . . . . . . . . . . 10 3.4.3. Mapping System . . . . . . . . . . . . . . . . . . . 11
3.5. Interworking Mechanisms . . . . . . . . . . . . . . . . . 13 3.5. Interworking Mechanisms . . . . . . . . . . . . . . . . . 14
4. LISP Operational Mechanisms . . . . . . . . . . . . . . . . . 13 4. LISP Operational Mechanisms . . . . . . . . . . . . . . . . . 14
4.1. Cache Management . . . . . . . . . . . . . . . . . . . . 14 4.1. Cache Management . . . . . . . . . . . . . . . . . . . . 15
4.2. RLOC Reachability . . . . . . . . . . . . . . . . . . . . 14 4.2. RLOC Reachability . . . . . . . . . . . . . . . . . . . . 15
4.3. ETR Synchronization . . . . . . . . . . . . . . . . . . . 16 4.3. ETR Synchronization . . . . . . . . . . . . . . . . . . . 17
4.4. MTU Handling . . . . . . . . . . . . . . . . . . . . . . 16 4.4. MTU Handling . . . . . . . . . . . . . . . . . . . . . . 17
5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 19 8.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 20
8.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . 19 8.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . 20
8.3. LISP for Virtual Private Networks . . . . . . . . . . . . 20 8.3. LISP for Virtual Private Networks . . . . . . . . . . . . 21
8.4. LISP for Virtual Machine Mobility in Data Centers . . . . 20 8.4. LISP for Virtual Machine Mobility in Data Centers . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . 22 12.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. A Brief History of Location/Identity Separation . . 24 Appendix A. A Brief History of Location/Identity Separation . . 25
A.1. Old LISP Models . . . . . . . . . . . . . . . . . . . . . 24 A.1. Old LISP Models . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
This document introduces the Locator/ID Separation Protocol (LISP) This document introduces the Locator/ID Separation Protocol (LISP)
[RFC6830] architecture, its main operational mechanisms and its [RFC6830] architecture, its main operational mechanisms and its
design rationale. Fundamentally, LISP is built following a well- design rationale. Fundamentally, LISP is built following a well-
known architectural idea: decoupling the IP address overloaded known architectural idea: decoupling the IP address overloaded
semantics. Indeed and as pointed out by [Chiappa], currently IP semantics. Indeed and as pointed out by [Chiappa], currently IP
addresses both identify the topological location of a network addresses both identify the topological location of a network
attachment point as well as the node's identity. However, nodes and attachment point as well as the node's identity. However, nodes and
skipping to change at page 3, line 33 skipping to change at page 3, line 33
typically routed intra-domain. RLOCs are assigned topologically to typically routed intra-domain. RLOCs are assigned topologically to
network attachment points and are typically routed inter-domain. network attachment points and are typically routed inter-domain.
With LISP, the edge of the Internet (where the nodes are connected) With LISP, the edge of the Internet (where the nodes are connected)
and the core (where inter-domain routing occurs) can be logically and the core (where inter-domain routing occurs) can be logically
separated and interconnected by LISP-capable routers. LISP also separated and interconnected by LISP-capable routers. LISP also
introduces a database, called the Mapping System, to store and introduces a database, called the Mapping System, to store and
retrieve mappings between identity and location. LISP-capable retrieve mappings between identity and location. LISP-capable
routers exchange packets over the Internet core by encapsulating them routers exchange packets over the Internet core by encapsulating them
to the appropriate location. to the appropriate location.
By taking advantage of such separation between location and identity In summary:
LISP offers Traffic Engineering, multihoming, and mobility among
others benefits. Additionally, LISP's approach to solve the routing o RLOCs have meaning only in the underlay network
scalability problem [RFC4984] is that with LISP the Internet core is
populated with RLOCs while Traffic Engineering mechanisms are pushed o EIDs have meaning only in the overlay network (unless they are
to the Mapping System. With this RLOCs are quasi-static (i.e., low leaked into the underlay network)
churn) and hence, the routing system scalable [Quoitin] while EIDs
can roam anywhere with no churn to the underlying routing system. o The LISP edge maps EIDs to RLOCs
o Within the underlay network, RLOCs have both locator and
identifier semantics
o An EID within a LISP site carries both identifier and locator
semantics to other nodes within that site
o An EID within a LISP site carries identifier and limited locator
semantics to nodes at other LISP sites (i.e., enough locator
information to tell that the EID is external to the site)
The relationship described above is not unique to LISP but it is
common to other overlay technologies.
The initial motivation in the LISP effort is to be find in the
routing scalability problem [RFC4984], where, if LISP is completely
deployed, the Internet core is populated with RLOCs while Traffic
Engineering mechanisms are pushed to the Mapping System. Where RLOCs
are quasi-static (i.e., low churn) and hence, the routing system
scalable [Quoitin] while EIDs can roam anywhere with no churn to the
underlying routing system. However, the separation between location
and identity that LISP offers makes it suitable for use in additional
scenarios such as Traffic Engineering (TE), multihoming, and mobility
among others.
This document describes the LISP architecture, its main operational This document describes the LISP architecture, its main operational
mechanisms as its design rationale. It is important to note that mechanisms as its design rationale. It is important to note that
this document does not specify or complement the LISP protocol. The this document does not specify or complement the LISP protocol. The
interested reader should refer to the main LISP specifications interested reader should refer to the main LISP specifications
[RFC6830] and the complementary documents [RFC6831], [RFC6832], [RFC6830] and the complementary documents [RFC6831], [RFC6832],
[RFC6833], [RFC6834], [RFC6835], [RFC6836], [RFC7052] for the [RFC6833], [RFC6834], [RFC6835], [RFC6836], [RFC7052] for the
protocol specifications along with the LISP deployment guidelines protocol specifications along with the LISP deployment guidelines
[RFC7215]. [RFC7215].
skipping to change at page 4, line 39 skipping to change at page 5, line 14
o Overlay architecture: Overlays route packets over the current o Overlay architecture: Overlays route packets over the current
Internet, allowing deployment of new protocols without changing Internet, allowing deployment of new protocols without changing
the current infrastructure hence, resulting into a low deployment the current infrastructure hence, resulting into a low deployment
cost. cost.
o Decoupled data and control-plane: Separating the data-plane from o Decoupled data and control-plane: Separating the data-plane from
the control-plane allows them to scale independently and use the control-plane allows them to scale independently and use
different architectural approaches. This is important given that different architectural approaches. This is important given that
they typically have different requirements and allows for other they typically have different requirements and allows for other
data-planes to be added. data-planes to be added. While decoupled, data and control-plane
are not completely isolated because the LISP data-plane may
trigger control-plane activity.
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
skipping to change at page 8, line 46 skipping to change at page 9, line 31
can be used for Traffic Engineering and re-routing. Re-encapsulating can be used for Traffic Engineering and re-routing. Re-encapsulating
tunnels are consecutive LISP tunnels and occur when a decapsulator tunnels are consecutive LISP tunnels and occur when a decapsulator
(an ETR action) removes a LISP header and then acts as an encapsultor (an ETR action) removes a LISP header and then acts as an encapsultor
(an ITR action) to prepend another one. On the other hand, Recursive (an ITR action) to prepend another one. On the other hand, Recursive
tunnels are nested tunnels and are implemented by using multiple LISP tunnels are nested tunnels and are implemented by using multiple LISP
encapsulations on a packet. Typically such functions are implemented encapsulations on a packet. Typically such functions are implemented
by Reencapsulating Tunnel Routers (RTRs). by Reencapsulating Tunnel Routers (RTRs).
3.3.2. LISP Forwarding State 3.3.2. LISP Forwarding State
ITRs retrieve from the LISP Mapping System mappings between EID In the LISP architecture, ITRs keep just enough information to route
prefixes and RLOCs that are used to encapsulate packets. Such traffic flowing through it. Meaning that, ITRs retrieve from the
mappings are stored in a local cache called the Map-Cache for LISP Mapping System mappings between EID prefixes and RLOCs that are
subsequent packets addressed to the same EID prefix. Mappings used to encapsulate packets. Such mappings are stored in a local
include a (Time-to-Live) TTL (set by the ETR). More details about cache called the Map-Cache for subsequent packets addressed to the
the Map-Cache management can be found in Section 4.1. same EID prefix. Note that, in case of overlapping EID-prefixes,
following a single request, the ITR may receive a set of mappings,
covering the requested EID-prefix and all more-specifics (cf.,
Section 6.1.5 [RFC6830]). Mappings include a (Time-to-Live) TTL (set
by the ETR). More details about the Map-Cache management can be
found in Section 4.1.
3.4. Control-Plane 3.4. Control-Plane
The LISP control-plane, specified in [RFC6833], provides a standard The LISP control-plane, specified in [RFC6833], provides a standard
interface to register and request mappings. The LISP Mapping System interface to register and request mappings. The LISP Mapping System
is a database that stores such mappings. The following first is a database that stores such mappings. The following first
describes the mappings, then the standard interface to the Mapping describes the mappings, then the standard interface to the Mapping
System, and finally its architecture. System, and finally its architecture.
3.4.1. LISP Mappings 3.4.1. LISP Mappings
skipping to change at page 14, line 49 skipping to change at page 15, line 49
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 The LISP architecture is an edge to edge pull architecture, where the
network state is stored in the control-plane while the data-plane network state is stored in the control-plane while the data-plane
pulls it on demand. On the contrary BGP is a push architecture, pulls it on demand. This has consequences concerning the propagation
where the required network state is pushed by means of BGP UPDATE of xTRs reachability/liveness information. On the contrary BGP is a
messages to BGP speakers. In push architectures, reachability push architecture, where the required network state is pushed by
information is also pushed to the interested routers. However pull means of BGP UPDATE messages to BGP speakers. In push architectures,
architectures require explicit mechanisms to propagate reachability reachability information is also pushed to the interested routers.
information. LISP defines a set of mechanisms to inform ITRs and However pull architectures require explicit mechanisms to propagate
PITRS about the reachability of the cached RLOCs: reachability information. LISP defines a set of mechanisms to inform
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
effectively when data flows bi-directionally between two effectively when data flows bi-directionally between two
skipping to change at page 18, line 9 skipping to change at page 19, line 9
multicast packets, the outter header includes its own RLOC as the multicast packets, the outter header includes its own RLOC as the
source (S-RLOC) and the original multicast group address (G) as source (S-RLOC) and the original multicast group address (G) as
the destination. Please note that multicast group address are the destination. Please note that multicast group address are
logical and are not resolved by the mapping system. Then the logical and are not resolved by the mapping system. Then the
multicast packet is transmitted through the core towards the multicast packet is transmitted through the core towards the
receiving ETRs that decapsulates the packets and sends them using receiving ETRs that decapsulates the packets and sends them using
the receiver's site multicast state. the receiver's site multicast state.
LISP can also support non-PIM mechanisms to maintain multicast state. LISP can also support non-PIM mechanisms to maintain multicast state.
7. Security 7. Security Considerations
LISP uses a pull architecture to learn mappings. While in a push LISP uses a pull architecture to learn mappings. While in a push
system, the state necessary to forward packets is learned system, the state necessary to forward packets is learned
independently of the traffic itself, with a pull architecture, the independently of the traffic itself, with a pull architecture, the
system becomes reactive and data-plane events (e.g., the arrival of a system becomes reactive and data-plane events (e.g., the arrival of a
packet for an unknown destination) may trigger control-plane events. packet for an unknown destination) may trigger control-plane events.
This on-demand learning of mappings provides many advantages as This on-demand learning of mappings provides many advantages as
discussed above but may also affect the way security is enforced. discussed above but may also affect the way security is enforced.
Usually, the data-plane is implemented in the fast path of routers to Usually, the data-plane is implemented in the fast path of routers to
skipping to change at page 19, line 50 skipping to change at page 20, line 50
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 issue a different mapping for each
remote site, implementing so precise routing policies. remote site, implementing so precise routing policies.
8.2. LISP for IPv6 Co-existence 8.2. LISP for IPv6 Co-existence
LISP encapsulations permits to transport packets using EIDs from a LISP encapsulations 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.
For example, two IPv6-only data centers could be interconnected via For example, two IPv6-only data centers could be interconnected via
the legacy IPv4 Internet. If their border routers are LISP capable, the legacy IPv4 Internet. If their border routers are LISP capable,
sending packets between the data center is done without any form of sending packets between the data center is done without any form of
translation as the native IPv6 packets (in the EID space) will be translation as the native IPv6 packets (in the EID space) will be
LISP encapsulated and transmitted over the IPv4 legacy Internet by LISP encapsulated and transmitted over the IPv4 legacy Internet by
the mean of IPv4 RLOCs. the mean of IPv4 RLOCs.
8.3. LISP for Virtual Private Networks 8.3. LISP for Virtual Private Networks
It is common to operate several virtual networks over the same It is common to operate several virtual networks over the same
physical infrastructure. In such virtual private networks, it is physical infrastructure. In such virtual private networks, it is
essential to distinguish which virtual network a packet belongs and essential to distinguish which virtual network a packet belongs and
tags or labels are used for that purpose. With LISP, the distinction tags or labels are used for that purpose. When using LISP, the
can be made with the Instance ID field. When an ITR encapsulates a distinction can be made with the Instance ID field. When an ITR
packet from a particular virtual network (e.g., known via the VRF or encapsulates a packet from a particular virtual network (e.g., known
VLAN), it tags the encapsulated packet with the Instance ID via the VRF or VLAN), it tags the encapsulated packet with the
corresponding to the virtual network of the packet. When an ETR Instance ID corresponding to the virtual network of the packet. When
receives a packet tagged with an Instance ID it uses the Instance ID an ETR receives a packet tagged with an Instance ID it uses the
to determine how to treat the packet. Instance ID to determine how to treat the packet.
The main advantage of using LISP for virtual networks, on top of the The main usage of LISP for virtual private networks does not
simplicity of managing the mappings, is that it does not impose any introduce additional requirements on the underlying network, as long
requirement on the underlying network, as long as it is running IP. as it is running IP.
8.4. LISP for Virtual Machine Mobility in Data Centers 8.4. LISP for Virtual Machine Mobility in Data Centers
A way to enable seamless virtual machine mobility in data center is A way to enable seamless virtual machine mobility in data center is
to conceive the datacenter backbone as the RLOC space and the subnet to conceive the datacenter backbone as the RLOC space and the subnet
where servers are hosted as forming the EID space. A LISP router is where servers are hosted as forming the EID space. A LISP router is
placed at the border between the backbone and each subnet. When a placed at the border between the backbone and each subnet. When a
virtual machine is moved to another subnet, it can 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
 End of changes. 13 change blocks. 
68 lines changed or deleted 100 lines changed or added

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