0x LISP Controller Technology
Locator/identifier separation protocol separates the identification and the locator by using two address spaces: the routing locator (RLOC) space and the endpoint identifier space (EID). An RLOC is the globally routable address that indicates the location of end-systems. An EID is the locally routable address that identifies an end-system. By separating two address spaces, packets are routed with RLOCs in the Internet core and delivered to a specific end-system with EIDs in the stub networks.
For forwarding in the data plane, LISP uses a tunneling mechanism. When a host generates IP packets, the packets have source and destination EIDs. The border router in LISP, called ingress tun- nel router (ITR), encapsulates the packets using the RLOCs of the source and destination EIDs. The encapsulated packets are forwarded to the border router, egress tunnel router (ETR), by using the des- tination RLOC. The ETR then decapsulates the packets and forwards the packets to the destination host by using the destination EID. Generally, both ITR and ETR are referred as xTR.
For the encapsulation and the decapsulation operations in the data plane, LISP tunnel routers asso- ciate EIDs with RLOCs. The control plane helps the mapping between EIDs and RLOCs for the encapsulations and decapsulations in the data plane. The EID–RLOC mapping information consists of EIDs and its corresponding RLOCs, priority, and weight values. An EID can be associated with many RLOC spaces. Among RLOC spaces, the RLOC with the highest priority will be associated. When RLOCs have the same priority, then weight value is used for load balancing by distributing packets according to the weight value for each RLOC space.
The LISP Database resides in ETRs, and it stores the EID–RLOC mappings between EID-prefixes and the corresponding RLOCs in the local LISP domain. For the encapsulation on ITRs, the LISP Database allows ITRs to select the source RLOC associated with the source EID-prefix. For the decap- sulation on ETRs, the LISP Database verifies if the RLOC in the inner packet header exists in the LISP Database. The LISP Database is manually configured on each xTR.
The LISP Cache resides in ITRs, and it stores the EID–RLOC mappings for those EIDs outside the local LISP domain. For the encapsulation on ITRs, the LISP Cache allows ITRs to select the destination RLOC associated with the destination EID-prefix. For the decapsulation on ETRs, mappings in the LISP cache are used to check if the destination RLOC in the outer header is the RLOC for the source EID. The mapping in the LISP Cache only lasts for a pre-configured time.
The LISP mapping system consists of a Map-Server and a Map-Resolver. ETRs register its EID– RLOC mappings to the mapping system by sending a Map-Register message. When the registration is successful, the Map-Server sends back a Map-Notify message. When the LISP Cache does not have any mappings for the destination EID (e.g., a new flow), the ITR sends a Map-Request message to the Map-Resolver. This query message is forwarded by the Map-Resolver to the Map-Server to look up the associated RLOC. The Map-Resolver or the destination ETR replies with a Map-Reply message including the queried mapping.