SECCI_LAYOUT.qxp_Layout 1 3/27/14 12:14 PM Page 34 The OpenLISP Control Plane Architecture Dung Chi Phung, UPMC and VNU Stefano Secci, UPMC Damien Saucez, INRIA Sophia Antipolis Luigi Iannone, Telecom ParisTech Abstract Among many options tackling the scalability issues of the current Internet routing architecture, the Locator/Identifier Separation Protocol (LISP) appears as a viable solu- tion. LISP improves a network’s scalability, flexibility, and traffic engineering, enabling mobility with limited overhead. As for any new technology, implementation and deployment are essential to gather and master the real benefits that it provides. In this article, we present the first complete open source implementation of the LISP control plane. Our implementation is deployed in the worldwide LISP Beta Network and the French LISP-Lab testbed, and includes the key standardized control plane fea- tures. Our control plane software is the companion of the existing OpenLISP data- plane implementation, allowing the deployment of a fully functional open source LISP network compatible with any implementation respecting the standards. he Internet is suffering from scalability concerns, packet reaches a border router of the network that acts as an mainly due to the BGP routing infrastructure, and ingress tunnel router (ITR), maps EID to RLOCs, appends a provides limited support to new advanced services. LISP header and an external IP/UDP header with the ITR as As discussed in [1, 2], a way to improve Internet source node, and, as the destination address, an RLOC select- T scalability is separating the IP space into locator ed from the mapping of the destination EID. The egress tun- and identifier spaces. The Locator/Identifier Separation Pro- nel router (ETR) that owns the destination RLOC strips the tocol (LISP) [3] is henceforth being architected in this sense outer header (i.e., decapsulates) and sends the native packet and introduces a two-level routing infrastructure on top of the to the destination EID. current BGP+IP architecture, mapping an endpoint identifier For example, in Fig. 1 the traffic from host 1.1.1.1 to host (EID) to one or several routing locators (RLOCs). RLOCs 2.2.2.2 is encapsulated by the ITR toward one of the RLOCs remain globally routable, while EIDs become provider-inde- (the one with the highest priority, i.e., RLOC3), which acts as pendent and only routable in the local domain. The resulting the ETR and decapsulates the packet before forwarding it to hierarchical routing architecture opens the way to benefits its final destination. On the way back to 1.1.1.1, RLOC4’s ranging from BGP routing table size reduction and efficient xTR queries the mapping system and gets two RLOCs with traffic engineering, up to seamless IP mobility. Moreover, equal priorities, hence performing load-balance as suggested LISP enables a large set of applications and use cases such as by the weight metric. virtual machine mobility management, layer 2 and layer 3 vir- The advantage of creating network control functions dis- tual private networks, intra-autonymous system (AS) traffic joint from the data plane is the possibility of programming the engineering, and stub AS traffic engineering. control plane independent of the forwarding logic, and thus to More technically, LISP uses a map-and-encap approach, implement advanced and personalized functionalities, as done where a mapping (i.e., a correspondence between an EID- in [5] for instance, for virtual machine mobility management. Prefix and its RLOCs) is first retrieved and used to encapsu- This separation respects the software defined networking late the packet in a LISP-specific header that uses only paradigm [6]. RLOCs as addresses. Such a map-and-encap operation in OpenLISP [7] is an open source implementation of the LISP is performed using a distributed mapping database for LISP data plane in a FreeBSD environment. As a standalone, the first packet of a new destination EID; then the mapping is an OpenLISP node is not able to handle all control plane sig- cached locally for all subsequent packets. The LISP control naling within a LISP network. Our control plane implementa- plane is based on signaling protocols necessary to handle tion aims at filling this gap, while keeping the data and EID-to-RLOC registrations and resolutions, dynamically pop- control planes independent of each other for performance ulating mapping caches at LISP network nodes. Since several reasons, as detailed hereafter. Our control plane implementa- RLOCs can be registered for the same EID, priority and tion is used to seamlessly interconnect the UPMC, Telecom weight metrics are associated with each RLOC in order to ParisTech, INRIA, UNIROMA1, VNU, the University of decide which one to use (highest priority) or how to do load- Prague, and UFRJ LISP sites spread worldwide, and is balancing (proportionally to the weights if priorities are deployed in the official LISP Beta Network.1 We are also equal) [4]. In practice, when a host sends a packet to another host at another LISP site, it sends a native IP packet with the EID of the targeted host as the destination IP address; the 1 LISP Beta Network worldwide testbed (website): http://www.lisp4.net 34 0890-8044/14/$25.00 © 2014 IEEE IEEE Network • March/April 2014 SECCI_LAYOUT.qxp_Layout 1 3/27/14 12:14 PM Page 35 2) xTR1 encapsulates the packet 3) xTR3 decapsulates the packet with SA: RLOC1 and DA: RLOC3 and delivers it to: 2.2.2.2 IP transit Multi-homed Multi-homed LISP site 1 RLOC 1 RLOC 3 LISP site 2 (1.1.1.0/24) (2.2.2.0/24) xTR1 xTR3 MS1 MS2 1) 1.1.1.1 sends a Mapping system packet to 2.2.2.2 Map-reply 2.2.2.2 1.1.1.1 Map-request 4) 2.2.2.2 responds RLOC 2 RLOC 4 xTR2 IP transit xTR4 7) xTR2 decapsulates the packet and delivers it to: 1.1.1.1 5) xTR4 sends a Map-Request for 1.1.1.1 to the MS and receives its mapping Data plane Control plane 6) Then, xTR4 encapsulates the packet with SA: RLOC4 and DA: RLOC2 Network Routing locator Priority/weight Network Routing locator Priority/weight 1.1.1.0/24 RLOC 1 1/50 2.2.2.0/24 RLOC 3 1/100 1.1.1.0/24 RLOC 2 1/50 2.2.2.0/24 RLOC 4 2/100 Figure 1. An example of LISP communications between two LISP sites. using it in combination with OpenLISP as the standard imple- site is not directly involved in the mapping database system mentation of nodes in the French LISP-Lab platform involv- but is instead connected to an MS. The ETR sends a Map- ing a dozen partners to date.2 Our purpose is to boost LISP Register message to that MS, which later ensures that the deployments by providing a full-fledged LISP open source mapping is registered in the mapping database system. software implementation, usable in operational networks and Optionally, the MS can acknowledge the registration with a able to be freely tailored, to facilitate implementation of new Map-Notify message. ideas leveraging on LISP. Our integrated OpenLISP system is Several mapping database systems have been proposed fully compatible with the standard as well as other implemen- (e.g., [8–10]), but only the Delegated Database Tree (LISP- tations (e.g., Cisco IOS) as reviewed hereafter. DDT, [10]) that we implement in our control plane is In the following, we detail the OpenLISP control plane deployed. In LISP-DDT, the MR discovers where to send the architecture and implementation aspects before describing Map-Request by iteratively sending Map-Requests and receiv- performance evaluation results. ing Map-Referral messages via the hierarchical LISP-DDT infrastructure, similar to DNS [10]. The LISP Control Plane For scalability reasons, ITRs learn mappings on-demand via The OpenLISP Control Plane Architecture the so-called mapping system. The mapping system is com- In this section, we describe the design of our OpenLISP con- posed of the mapping database system and the map-server inter- trol plane implementation, issued under a BSD licence.3 face [8]. Given that the main role of the LISP control plane is the The mapping system workflow is summarized in Fig. 2. On management of EID-to-RLOC mappings with the mapping one hand, the mapping database system constitutes the infras- system, in the following we first focus on the design of the tructure that stores mappings on the global scale, potentially mapping database, and then we detail the different modules. using complex distributed algorithms ([8–10]). On the other hand, the map-server interface hides this complexity via two Mapping System and Key Network Nodes network elements, the map resolver (MR) and map server The heart of the OpenLISP control plane is the EID-to- (MS), deployed at the edge of the mapping database system, RLOC mapping database, synthetically referred to as map- which LISP sites contact to retrieve and register mappings. table in the following. Each map-entry of the map-table More precisely, when an ITR is willing to obtain a mapping consists of an EID prefix with a list of RLOCs, each RLOC for a given EID, it sends a Map-Request message to an MR. associated with a structure that contains the RLOC address The MR is connected to the mapping database system and and related attributes (i.e., priority and weight). The three implements the lookup logic in order to determine at which network elements involved in the control plane, ETR, MS, LISP site the Map-Request must be delivered (to any of its and MR, serve different purposes; hence, they implement ETRs), and delivers it.