Locator/ID Separation Protocol (LISP) architecture is a feature-rich architecture that not only does the separation of device identity and location but also brings down operational expenses (opex), provides a Border Gateway Protocol (BGP)–free multihoming network, enables multi address-family (AF) support, provides a highly scalable virtual private network (VPN) solution, enables host mobility in data centers, and much more. To understand how all these functionalities and benefits are achieved, it is important to know the underlying architectural components of LISP and also understand how LISP works. This chapter explores the details of the architecture of LISP.
This chapter covers the following topics:
LISP architecture
LISP Canonical Address Format (LCAF)
LISP packet headers
LISP control plane messages
LISP Database Architecture: LISP-DDT
LISP architecture on Cisco platforms
LISP Architecture
LISP, defined in RFC 6830, is a routing and addressing architecture of the Internet Protocol. The LISP routing architecture was designed to solve issues related to scaling, multihoming, inter-site traffic engineering, and mobility. An address on the Internet today combines location (how the device is attached to the network) and identity semantics in a single 32-bit (IPv4 address) or 128-bit (IPv6 address) number. The purpose of LISP is to separate the location from the identity. In simple words, with LISP, where you are (the network layer locator) in a network that can change, but who you are (the network layer identifier) in the network remains the same. LISP separates the end user device identifiers from the routing locators used by others to reach them. The LISP routing architecture design creates a new paradigm, splitting the device identity—that is, the endpoint identifier (EID)—from its location—that is, the routing locator (RLOC).
In order to further understand how LISP does the locator/ID separation, it is important to first learn about the architectural components of LISP. The following are some of the functions or components that form the LISP architecture:
Ingress tunnel router (ITR): The ITR receives the packets from the site-facing interfaces and encapsulates them to the remote LISP site or natively forwards the packets to a non-LISP site.
Egress tunnel router (ETR): The ETR receives the packets from core-facing interfaces and de-encapsulates them to deliver them to local EIDs at the site.
Proxy ingress tunnel router (PITR): A PITR is an infrastructure LISP network entity that receives packets from non-LISP sites and encapsulates the packets to LISP sites or natively forwards them to non-LISP sites.
Proxy egress tunnel router (PETR): A PETR is an infrastructure LISP network entity that de-encapsulates packets from LISP sites to deliver them to non-LISP sites.
Map server (MS): An MS configures LISP site policy to authenticate when LISP sites try to register to the MS. It also performs the following functions:
Provides a service interface to the ALT router and injects routes in the ALT BGP when the site registers.
Receives MAP requests over the ALT router and encapsulates them to registered ETRs.
Map resolver (MR): The MR performs the following functions:
Receives MAP requests, which are encapsulated by ITRs.
Provides a service interface to the ALT router, de-encapsulates MAP requests, and forwards on the ALT topology.
Sends negative MAP replies in response to MAP requests for non-LISP sites.
ALT router (ALT): An ALT router is a router that runs External Border Gateway Protocol (eBGP) over an alternate Generic Routing Encapsulation (GRE) tunnel topology. It is an off-the-shelf router that does not run LISP. The ALT router simply forwards MAP requests according to the BGP Routing Information Base (RIB). ALT routers are used to aggregate BGP connections and to summarize EID prefix routes.
LISP Delegated Database Tree (LISP-DDT): LISP-DDT is a hierarchical distributed database authority that provides EID-to-RLOC mappings. It is statically populated with the EID namespace and other nodes, called DDT nodes. Each DDT node is authoritative for one or more EID prefixes, or “child” DDT nodes, for more specific EID prefixes addressed by an authoritative DDT node.
The following sections discuss these components and features in detail.
Routing Locators and Endpoint Identifiers
The IPv4 or IPv6 address of a device represents its identity and location. In the present-day Internet, when a host moves from one location to another location, it is assigned a different IPv4 or IPv6 address, which overloads the location/identity semantic. LISP separates the location and identity of a device through the RLOC and EID. The RLOC represents the IP address of the egress tunnel router (ETR) the host is attached to, and the EID represents the IP address assigned to the host. With LISP, the change in location of a device does not result in a change in its identity. In other words, when the device moves from one location to another, it still retains its IPv4 or IPv6 address; however, the site tunnel router (xTR) is dynamically updated. Ensuring that the identity does not change for the host even with the change in location requires a mapping system. LISP provides the distributed architecture EID-to-RLOC mapping that maps EIDs to RLOCs. Figure 2-1 displays the location and identity separation in a network with EIDs and RLOCs.
)
FIGURE 2-1 Using EIDs and RLOCs for Location/ID Separation
Ingress/Egress Tunnel Routers (xTRs)
Both the ITRs and ETRs are also referred to as xTRs. The ITRs and ETRs play a vital role in packet forwarding in the LISP architecture.
An ITR is a router that performs the following tasks:
Accepts an IP packet from a host and treats the IP destination as an EID
Performs an EID-to-RLOC mapping lookup in its local map caches or remote map resolver in the event of a missed hit
Prepends the packet with a LISP header, with the RLOC as the destination IP address
Forwards the packet to the ETR that is hosting the RLOC
An ETR is a router that performs the following tasks:
Accepts an IP packet with a LISP header, where the destination IP address is hosted by the router
Strips the LISP header and forwards the packet based on the next IP header found on the packet
To further understand the functioning of the ITR and ETR routers, examine the topology shown in Figure 2-2. In this topology, there are two LISP sites, Site1 and Site2, with hosts in subnets 100.1.1.0/24 and 200.1.1.0/24. The Internet cloud has four ISP networks, with the subnets 10.0.0.0/8, 20.0.0.0/8, 30.0.0.0/8, and 40.0.0.0/8.
)
FIGURE 2-2 LISP-Enabled Topology
If the host 100.1.1.1 wants to reach host 200.1.1.2, the following control plane lookups happen in a LISP-enabled network:
Step 1. Host S1 with IP address 100.1.1.1 performs a DNS lookup for destination host D1 with IP address 200.1.1.2.
Step 2. After the DNS lookup is performed, the host forwards the packet to one of the ITRs, based on the routing and forwarding preference. In this case, the packet is sent to ITR1.
Step 3. ITR1 receives the packet and checks the IP headers and does not find a relevant next-hop entry for forwarding the received packet with source IP address 100.1.1.1 and destination IP address 200.1.1.2. The ITR then thinks that it might be a potential packet for LISP encapsulation. It performs a lookup in the map cache entry and finds two locator sets for the destination 200.1.1.0/24 subnet.
Step 4. The ITR creates an overlay from ITR to ETR with LISP encapsulation. The encapsulation of the IP packet happens on the ITR, and the de-encapsulation happens on the ETR.
Step 5. The ETR forwards the IP packet to the destination host.
Map Servers (MSs) and Map Resolvers (MRs)
The fundamental behavior of LISP is to separate the EID from the RLOC, which allows the host to retain its identity even with a change in location. But the seamless mobility is achieved using the EID-to-RLOC mapping, which is maintained in the distributed database. The map server (MS) learns EID-to-RLOC mapping entries from the ETRs and publishes these mappings to the distributed mapping database. To publish its EID prefixes, an ETR periodically sends its mapping entries to the MS. The MS also receives the map requests via the mapping system and forwards them to the registered ETRs.
The map resolver (MR), on the other hand, accepts LISP encapsulated map requests from an ITR. Based on a map request, two things may happen.
If the destination IP address is part of the EID namespace, the MR finds the appropriate EID-to-RLOC mapping by consulting the distributed mapping database system.
If the destination is not found in the EID namespace, then a negative map reply is sent to the ITR. This means that if the MR receives a map request for a non-LISP site, the MR sends a negative map reply in response.
To understand the functioning of MR/MS routers, examine the topology shown in Figure 2-3.
)
FIGURE 2-3 LISP Map Request and Map Reply
In this topology, when host S1 with IP address 100.1.1.1 tries to reach host D2 with IP address 200.1.1.2, it sends the packet to one of the local ITRs at the site. Then, if the ITR does not have an entry in its map cache table, the ITR creates a map request looking for the host 200.1.1.2 and sends it to the map resolver (MR). The map request is also LISP encapsulated where the outer header has the source IP address of 20.0.0.2 and destination IP address of 50.0.0.2. Based on the request, the MR forwards the map request to the map server (MS). The MS redirects the packet to the ETR, which has the information about the host prefix/subnet. One important thing to notice in this map request/map reply is that the map request comes toward the mapping system, but the mapping system does not send the reply. The ETR sends the map reply directly to the ITR that raised the map request. This significantly reduces the load on the MR/MS and at the same time helps validate the path between the ETR and the ITR. The map reply contain the mapping entries of the ETRs that hold the destination EIDs.
Figure 2-4 illustrates an example of an ITR sending a map request for a prefix in a non-LISP site.
)
FIGURE 2-4 LISP Map Request and Negative Map Reply
In this scenario, if a host connected to the ITR tries to reach a destination that is on a non-LISP site, the ITR (as in the previous scenario) creates a map request and sends it to the MR. The MS performs a lookup to see whether the EID is present in its mapping database. If the MS cannot find a matching entry, it sends a negative map reply back to the originating ITR. On receiving the negative reply, the ITR updates its map cache entry with the tag forward-native, which means that the destination is part of a non-LISP site.
Proxy Ingress/Egress Tunnel Router (PxTR)
Sites cannot all be LISP enabled immediately, and not all segments of the network are not capable of running LISP from day 1. With the gradual migration from non-LISP-enabled sites to LISP-enabled sites, network operators still require that the non-LISP-capable sites be able to send traffic destined to LISP-enabled sites. This is where proxy ingress/egress tunnel routers (PxTRs) come into play.
Proxy ingress tunnel routers (PITRs) allow for non-LISP sites to send packets to LISP sites. A PITR is a new network element that shares many characteristics with a LISP ITR. A PITR allows non-LISP sites to send packets to LISP sites without requiring changes in the protocol or devices at the non-LISP sites. PITRs perform two primary functions:
Originating EID advertisements: PITRs advertise highly aggregated EID-prefix space on behalf of LISP sites to the non-LISP sites so that the non-LISP sites can reach them.
Encapsulating legacy Internet traffic: PITRs encapsulate non-LISP Internet traffic into LISP packets and route them toward their destination RLOCs.
Proxy egress tunnel routers (PETRs) are used to allow traffic from LISP sites to non-LISP sites. A PETR acts as an ETR for traffic sourced from LISP sites and destined to non-LISP sites. PETRs are useful in the following cases:
Avoiding strict uRPF failures: Some providers’ access networks require the source of a packet to be within the address scope of the access networks. PETRs allow for LISP sites to send packets to non-LISP sites in cases where the access network does not allow for the LISP site to send packets with the source address of the site’s EIDs.
Traversing a different IP protocol: The transit path network between LISP sites and non-LISP sites may not be IPv4 or IPv6 enabled. LISP support for mixed protocol encapsulation allows PETRs to hop over such networks in order to route the traffic between the LISP and non-LISP sites.
The LISP ALT System
The LISP Alternative Logical Topology (ALT) system is defined in RFC 6836. The LISP ALT system is a simple distributed index system that assists the ITR or MR in finding the ETR that holds the RLOC mapping information for a particular EID. ALT is a topology formed using GRE tunnels via which EIDs are routable. It is used to propagate mapping entries to the ITR. The purpose of the ALT system is to advertise EID prefixes in BGP on an alternative topology. The ALT system thus allows for incremental deployment of LISP. Figure 2-5 shows a LISP-enabled topology with ALT routers in the network.
)
FIGURE 2-5 LISP ALT
An ALT-only device can be off-the-shelf gear that can be configured on router hardware or even on a Linux host. The device just needs to be BGP and GRE capable. Often users confuse the functionality of LISP ALT system. The ALT system does not distribute the actual EID-to-RLOC mappings but provides a forwarding path from an ITR or MR to an ETR that holds the mapping for a particular EID prefix.