LISP (Locator/ID Separation Protocol) Intro

So I’ve been doing some testing lately on LISP and I thought it would be a good time for me to get my initial notes down on paper.

LISP allows you to separate an objects identity with it’s location while using the existing IP space.  Sort of hard to grasp when you initially read that, but the concept isn’t that complicated once you dwell on it for awhile.  LISP accomplishes this by splitting the hosts identity into two distinct identifiers.  The first is the EID (Endpoint ID) and the second is the RLOC (Routing Locators).  So in the past we identified a host by a single IP address.  With LISP, we are essentially identifying a host using two IP address, the EID and the RLOC.  EIDs are assigned to end hosts and RLOCs are primarily assigned to routers that make up the global routing environment. 

So, at this point we could probably summarize things by saying that RLOCs are what exist today (the normal IP routing space) and EID spaces (or LISP sites) are a new concept that LISP adds.  So if we back up for a moment, you might be able to visualize this by thinking of the difference between public and private space.  RLOC’s would include the traditional internet edge or where non-RFC1918 addressing traditionally ends.  The LISP site made up of EIDs would be the private or RFC1918 addressing.  LISP uses a very similar concept, only the RLOCs are advertised, the space in the actual LISP site (private IP space in my example) isn’t advertised out into the RLOC space.  So the RLOC space is essentially non-LISP enabled, and the EID space is LISP enabled.  A crude example perhaps but it should help solidify the difference.

EIDs and RLOCs make up the first two building blocks of LISP.  The third major building block is the LISP mapping system.  As described above, EID space is not advertised in the RLOC space.  Rather, its advertised directly to LISP mapping databases which keeps these prefixes out of the RLOC space entirely.  The Map DB is really just tracking all of the RLOC to EID mappings.  When a LISP enabled device wishes to talk to a specific EID space, it can query the Map DB and download the mapping it needs to facilitate the communication.  The big picture here is that LISP enabled devices ONLY need to download the mappings they need to facilitate the communication they are requested to make.  This would be the same as saying that an internet router wouldn’t need to have the entire internet routing table in memory.  When something behind it wanted to talk to something new, it would just query the Map DB servers and download the mapping it needed.  I’m oversimplifying this but I hope you get the point.

Now let’s cover some basic about device roles in a LISP environment.  Here are a few quick definitions…

ITR – Ingress Tunnel Router
The ITR is generally a customer edge device that receives packets from the EID space, encapsulates it, and sends it off into RLOC space as a LISP packet.  It should be noted here that the ITR device can also natively forward packets towards non-LISP sites.

ETR – Egress Tunnel Router
The ETR is generally a customer edge device that receives the LISP encapsulated packet coming in from the RLOC space, decapsulates it, and sends it back into the EID space towards its final destination. 

xTR – xTR just means that the router is performing both ITR and ETR tasks.  This is a very common configuration. 

PxTR – A proxy version of the xTR device type.  PxTR routers allow LISP and non-LISP sites to work together.  That is, a PxTR device would allow a non-LISP site to interoperate with a LISP site.  The PxTR can be broke into the PITR and PETR functions just like the xTR, ITR, and ETR. 

MS – Map Server
A component of the mapping database and part of what I would consider the shared LISP infrastructure.  ETRs register specific EID prefixes to the MS for which they are authoritative for.  The MS use the information they gather from the ETRs to build a LISP site policy for a particular LISP site. 

MR – Map Resolver
Another component of the mapping database and part of the shared or common LISP infrastructure.  The MRs receive map requests from ITRs.

So this was a super basic introduction, but I think we should leave it there for now.  More to come soon.