LISP Data Plane | LISP Control plane
Locator Identity Separation Protocol – LISP Control and LISP Data Plane
The purpose of this post is to look at Data and Control plane functions for North-to-South Locator Identity Separation Protocol ( LISP ) traffic flows. Later posts will review these functions with the LISP Host mobility solution. A method to separate the identity from its location offers many benefits. A single address field for both identifying a device and for determining where it is topologically located is not an optimum approach and offers many challenges with host mobility. A new technology called LISP offers an architecture that provides seamless ingress traffic engineering and move detection without any DNS changes or agents on the host. A key concept of LISP is that end hosts operate the same way. The IP addresses that hosts use for tracking sockets and connections, and for sending and receiving packets, do not change.
LISP Data Plane
-Client C1 is located in a remote LISP enabled site and wants to open a TCP connection with D1 which is a server deployed in a LISP enabled Data Center. C1 queries through DNS the IP address of D1 and a A/AAAA record is returned. The address returned is the destination Endpoint Identifier ( EID ) and it’s non routable. EIDs are IP addresses assigned to hosts.
-Client C1 realizes that this is not an address on its local subnet and steers the traffic to its default gateway, which is a LISP enabled device. This triggers the LISP control plane activity.
-LISP control plane is triggered only if the lookup produces no results or if the only available match is a default route. This means that a Map-Request ( from ITR to Mapping system ) is sent only when the destination is not found.
-The ITR receives its EID-to-RLOC mapping from the mapping system and updates its local map-cache that previously did not contain the mapping. The local map-cache can be used for any future communications between these end points.
-The destination EID will be mapped to a number of RLOC ( Routing Locator ) which will identify the ( Egress Tunnel Router ) ETRs at the remote Data Center site. Each entry has associated priority and weights that is used to load balance and influence inbound traffic towards the RLOC address space. The selection of the specific RLOC is done on a per-flow basis based on 5-tuple hashing of the original clients IP packet.
-Once the controls are in place, the ITR performs LISP encapsulation on the original packets and forward the LISP encapsulated packet to one ( two or more if load balancing is used ) of the RLOCs of the Data Centers ETRs. RLOC prefixes are routable addresses.
-The destination ETR receives the packet, decapsulates and sends it towards the destination EID
LISP Control plane
-The destination ETRs register their non routable EIDs to the Map Server using a Map-Register message. This is done every 60 seconds.
-If the ITR does not have a local mapping for the remote EID-RLOC mapping, it will send a Map-Request messages to the Map Resolver. Map-Requests should be rate-limited to avoid denial of service attacks.
-The Map Resolver then forwards the request to the authoritative Map Server. The Map Resolver and Map Server could be the same device. The Map resolver could also be an anycast address.
-The Map-Server then forwards the request to the last registered ETR. The ETR looks at the destination of the Map-Request and compares it to its configured EID-to-RLOC database. If there is a match it triggers the ETR to directly reply back to the ITR with a Map-Reply containing the requested mapping information. Map-Replies are sent on the underlying routing system topology. On the other hand, if there is no match, the Map-Request are simply dropped.
-When the ITR receives the Map-Reply containing the mapping information it will update its local EID-to-RLOC map-cache. All subsequent flows will forward without the mapping systems integration.