--> /* MENU */

0x LISP Network

As the current Internet architecture is suffering from scalability issues, the network research community has proposed alternative designs for the Internet architecture. Among those solutions that adopt the idea of locator/identifier split paradigm, the locator/identifier separation protocol (LISP) has been considered as the most promising solution because of its incrementally deployable feature.

0x LISP Controller Technology

System Architecture

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.

What Are Problems in LISP Protocol?



• Lack of centralized management: The main role of the LISP mapping system is quite limited, and it cannot be used for the management of LISP networks. In the standard LISP, EID–RLOC mappings are periodically collected from xTRs by using Map-Request and Map-Reply mes- sages. In other words, the EID–RLOC mappings in the mapping system are fully originated from xTRs, and it cannot be directly modified by a network operator. When the network operator manipulates an EID–RLOC mapping in the LISP mapping system for a management purpose, the new EID–RLOC mapping temporarily lasts until the next polling cycle. The LISP mapping system, the only centralized system in the LISP control plane, does not provide any controlla- bility to the network operator. Network operator expects to modify the EID–RLOC mapping, weight, and priority for management purposes. From an ISP’s perspective, a centralized LISP management system is necessary to provide LISP-enabled services.

• Lack of management on xTRs: LISP is basically based on the concept where each xTR is owned by an autonomous system (AS). An xTR belongs to an AS, and the network operator of the AS has full control over the xTR to change its map database, map cache, weight, and priority. The architecture of LISP is basically autonomous and decentralized. An xTR is only controlled by the AS it belongs to. In these existing LISP scenarios, an ISP cannot access and manage xTRs, which means that an ISP will have difficulties to start a new business or provide a new service using LISP. Therefore, in an ISP’s LISP-enabled service scenarios, xTRs belong to the ISP, not to the customers because the management and the control of xTRs are essential for the ISP who provides LISP-enabled services. From an ISP’s perspective on LISP scenarios, the basic concept is that an ISP owns every xTR in its network.

• Latency of map entry update: When an EID–RLOC mapping in the map database is changed, the new mapping information is notified to the network. However, the map entry update mech- anism in the standard LISP shows long latency for the propagation of the updated mapping information. To provide LISP-enabled commercial services, an ISP requires fast update of EID–RLOC mappings.

• Modifications on the LISP: When providing LISP-enabled services, ISPs do not want to modify the standard LISP because ISPs have to provide compatibility to existing LISP-enabled network devices (e.g., Cisco’s LISP-enabled devices).

0x LISP Controller Technology

LISP Control System

The control system was proposed to give controllability to the LISP control plane. The control plane in the existing LISP does not provide any controllability except the case where an AS modifies its own xTRs’ map database. Using the proposed control system, an ISP can build a LISP network where the network operator of the ISP accesses every xTR in the network and updates its map database and cache. By providing the control and management functionalities in a centralized manner, the LISP controller gives controllability on the LISP network to the network operator.



LISP Mapping System

The mapping system plays the similar role as the standard LISP mapping system. The mapping system maintains EID–RLOC mappings of every xTR in an ISP’s network. The mapping system periodically sends Map-Request and receives Map-Reply messages to collect map database information from xTRs. Also, when an xTR requests an EID–RLOC mapping with a Map-Request message, the mapping system looks up its EID–RLOC entries and responses to the request with a Map-Reply message. In addition to the standard LISP mapping system, the proposed mapping system interoperate with the control system. Control system can access the mapping system directly. The control system can query map entries, or it can modify the map entries in the LISP mapping system for management purposes.

Use Cases

Traffic Engineering

0x traffic engineering system helps the network operator to control the ingress traffic of LISP sites. In the proposed system, the modified weight/priority is applied to the mapping system and to the other xTRs in a shorter time compared with the standard LISP. When the network operator modi- fies weight/priority of a target xTR, it first replaces the xTR’s weight/priority in the mapping system with the new weight/priority. At the same time, an Update (database) message is sent to the xTR, and Update (cache) messages are sent to the other xTRs in the network.



Virtual machine live migration

0x LISP-based VM live migra- tion is faster than the standard LISP-enabled approach because the proposed VM live migration does not need to communicate with the mapping system. Also, the proposed approach does not require any modifications on the standard LISP.



Vertical handover

Because LTE network uses NAT, the mobile node needs to be supported by NAT traversal function in the RTR to communicate with the nodes in the test bed. Currently, OpenLISP does not include NAT/RTR functions, so 0x LISP implemented the RTR and located it to the test bed. The RTR was installed in LISP site C. Also, the RTR in the test bed has both private IP and public IP. The private IP is used for the communication with the nodes inside test bed, and the public IP is used for the communication with the mobile node. The RTR acts as an anchor point between the nodes using private IP addresses and the nodes using public IP addresses. Packets are re-encapsulated by the RTR when packets pass through the RTR.