This is part of a series of posts – The Lisp Papers.
As the previous blog post discussed, an IP address contains two different semantics, or meanings. The Locator / ID Separation Protocol (LISP) is an effort to create a divide between the Location semantic and the ID Semantic.
Using LISP, an IP address will either be a Routing Locator (RLOC) or End Identifier (EID). These two terms are defined as follows:
- An RLOC is a location semantic – this is where a device is connected to the wider Internet.
- An EID is an identification semantic – this is the ID of the device. Similar to the MAC address – which was the answer to the question posed at the end of the last post - the EID does not need to change if the location changes.
EIDs are used within the customer network, while RLOCs are used in the Default-Free Zone, a.k.a. the Internet at Large.
A few points on the suitability of LISP. The designers set out to provide a solution that:
- was a network-based solution. No end-user changes were required.
- did not require any address changes to the user-site
- would interoperate with the Internet and could be deployed incrementally.
These points were considered key to the success of the protocol as it would allow for a phased approach. We have seen how long it has taken for an end-user change to take place, especially when all systems have to change in order for the system to operate – consider the uptake of IPv6.
LISP uses a technique known as Map ‘n Encap. This means that an EID is mapped to RLOCs, and then the packet is encapsulated with a UDP header which uses the RLOC addressing. This is also known as a jack-up, as the EID network layer is “jacked up” and the RLOC addressing is inserted. This is illustrated below:
The edge of the LISP domain is defined by a Tunnel Router. This router is responsible for reading the EID address, checking its local RLOC to EID mapping cache and, if there is a cache miss, interrogating the Mapping infrastructure. This is similar to DNS.
The flow from the source towards the Internet is encapsulated by the Ingress Tunnel Router (ITR) , while the flow from the Internet towards the destination is decapsulated by the Egress Tunnel Router (ETR). The operation is illustrated below:
The ETR and ITR very rarely operate independently; the device is usually an ITR for traffic leaving a site and an ETR for traffic destined for the site. A combined system is known as an xTR.
At this point, an end-to-end view would probably be useful. Assuming that the RLOC is obtained from the cache ( a previous mapping operation has occurred at the EID is mapped to a corresponding RLOC), the network will operate as illustrated in the following diagram (click for larger diagram):
In this example, 10.1.1.2 sends traffic to 10.1.2.2. As the traffic is routed, the ITR 1.1.1.1 checks its map cache and locates the RLOC for 10.1.2.0/24 is 2.2.2.2. Traffic is then encapsulated with a UDP header, and a new network layer with a source of 1.1.1.1 and destination of 2.2.2.2 is added. The traffic is then routed transparently over the Internet until it reaches the ETR 2.2.2.2, where the encapsulation is removed and the original packet is forwarded. Of course, the roles will be swapped around for the return traffic (hence the xTR labels on the diagram).
As is implied by the diagram, more that one RLOC can be associated with an EID. In this case, powerful traffic engineering policies can be implemented. In the next post, a practical example of the data plane is considered.
This is part of a series of posts – The Lisp Papers.
