Locator ID Separation Protocol (LISP)

In this blog, I will explain how the Data Plane and Control Plane works in a LISP environment. I assume that the reader is already aware of what LISP is and why it is deployed.

LISP Data Plane:

1.  The source host sends an IP packet destined to another LISP site. The source IP is the EID of the      source host and destination IP is the EID of the destination host. Remember, the hosts are not aware of the LISP environment.

2.  This packet gets forwarded normally towards the edge router (ITR) of the EID domain.

3. The ITR looks to see if it has a mapping for the destination EID in its map-cache. If it has, the ITR encapsulates the original IP packet into a LISP packet. The outer header will have source IP of the ITR's RLOC IP and destination IP will be the one found in the map-cache. The ITR forwards the packet into the RLOC space. If the mapping is not found in the map-cache, the ITR will initiate a map-request. This process is explained in the Control Plane section below.

4. The LISP encapsulated packet will be routed normally in the RLOC space and will arrive at the ETR of the destination EID.

5. The ETR will examine the LISP packet. If the destination IP on the outer header is that of its own, it will decapsulate the LISP packet, take out the original packet and forward inside the EID domain towards the final destination.

LISP Control Plane:

The main job of the LISP control plane is to provide the EID-to-RLOC mappings to the requesting ITRs.

1.  The ETRs responsible for the EID space will send a map-register message to its configured Map Server (MS).

2. The MS will advertise (inject) the EID prefix into the ALT topology, just like any other prefix in BGP.

3. The Map Resolvers (MR) will learn the EID prefix via the ALT topology. Remember, MS and MR are part of ALT topology. The MR now knows how to reach the EID prefix.

4. Now, when the ITR does not have EID-to-RLOC mapping in its map-cache (see point 3 in Data Plane section), it sends a map-request message to its configured MR. If the ITR is not part of the ALT, it will encapsulate the map-request and send it towards the IP address of the MR. Also remember, if the EID-to-RLOC mapping is not available in the map-cache, the ITR will put the original EID destination IP in its outer header's destination IP.

If the ITR is part of the ALT topology, it will just forward the map-request in the ALT topology. Remember, the ALT routers have the EID prefix in its routing table. In this case, we assume ETR is also part of ALT, so that the map-request directly reaches the ETR, without using MR/MS. MR/MS mapping infrastructure is used to scale the LIPS for large deployments, such as Internet.

5. The MR will decapsulate the map-request and forward the map-request in the ALT. The map-request will have the destination EID as the destination IP in the packet. So, the map-request will be forwarded towards the MS over the ALT. Remember, MS is the one that injected the EID into the ALT.

6. After the map-request reaches the MS, it will consult its mapping database to find out the RLOC for the EID in question. MS knows this information because the ETR has registered with MS in step 1.

7. MS will encapsulate the map-request and forward it to the RLOC (ETR's outside IP address).

8. ETR will get the map-request and will directly send a map-reply to the ITR's outside IP address.

9. The ITR will receive the EID-to-RLOC mapping and keeps this mapping in its map-cache for future use.

Thanks for reading. Please leave a comment.