LISPmob: a Flexible LISP Implementation

Introduction

The approach Locator/ID Separation Protocol (LISP) takes to solving the routing scalability problem is to decouple IP address semantics of identity and location by considering two different types of addresses: End Point Identifiers (EIDs) to identify hosts and Routing Locators (RLOCs) to route packets over the Internet.

Since its inception, LISP has gained significant traction because of its inherent architectural advantages: fully featured traffic engineering capabilities, minimal configuration needs, very low deployment cost and benefits to early adopters. Institutions (both commercial and academic) across the globe have demonstrated their interest in LISP. At the time of writing LISP has been deployed in a beta-network that includes more than 20 countries and hundreds of institutions.

The LISPmob project aims to bring a full-featured LISP open-source implementation to Linux-flavoured systems. Currently it is available for standard Linux, Android and OpenWRT . LISPmob is fully compatible with both LISP and LISP-MN specifications. LISP-MN is a lightweight version of LISP for mobile devices. Some features that LISPmob implements are the following:

• Full IPv6 and IPv4 support
• Router mode and mobile node mode (as well as other LISP devices)
• Handling multihoming scenarios (with traffic balancing among links)
• Interface management (including handover events)
• NAT traversal capabilities

The LISPmob audience is composed of both individuals and companies. The estimated user-base, based on the mailing list subscriptions, is approaching 200. However, many of these users represent companies using LISPmob. Individuals are interested in LISPmob to obtain IPv6 connectivity over IPv4-only providers (and sometimes the other way around) and to set up simple multihoming deployments. Companies use LISPmob in different ways, mostly as a tool for proof-of-concept LISP deployments and to provide LISP connectivity on client-side devices. We are seeing also an increasing interest for LISPmob in academic projects and other open-source communities. Since sometimes LISPmob is being used by multiple users in the same company, the real number of users is hard to estimate.

This article presents LISPmob software architecture and components. It also presents its most common use cases.

LISP Overview

Locator/ID separation protocol (LISP) decouples the identity of a host from its location. It creates two different namespaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). Each host is identified by an EID and its point of attachment to the network is specified by an RLOC. To keep LISP incrementally deployable, EIDs and RLOCs are syntactically identical to current IPv4 or IPv6 addresses. However, the protocol allows more address families to be used as well.

Host applications bind to EIDs for transport layer connections. Packets are routed based on EIDs at LISP sites and on RLOCs on transit networks. At LISP sites' edge points, Ingress/Egress Tunnel Routers (xTR) are deployed to allow transit between EID and RLOC space. To do so, LISP follows a map-and-encap approach. xTRs serve as gateways on their LISP sites. If a packet wants to leave the LISP site, the xTR performs a lookup at its map-cache. The map-cache contains the mappings from EID to RLOC that the xTR has learned. If there is already an entry, the xTR knows the RLOC of the destination EID. It encapsulates the original packet in a new IP header, using this RLOC as destination and its own RLOC as source, and forwards the packet to the transit network. If there is no entry for that EID, it first needs to find the desired EID-RLOC mapping.

LISP introduces a publicly accessible Mapping System. The LISP Mapping System is a distributed database containing EID-to-RLOC mappings. A single EID can be mapped to several RLOCs with different priority and weight values to allow backup policies and traffic balancing. The Mapping System is composed by Map-Resolvers and Map-Servers. Map Servers store mapping information and Map Resolvers find the Map Server storing a specific mapping. An xTR with a map-cache miss will ask the Mapping System (through a Map Resolver) to get the mapping information. The mapping is stored in its map-cache for future use. If there is no mapping information stored on the Mapping System, the xTR will know the destination is not in the LISP space. It can, however, use a Proxy xTR (PxTR) to communicate to the site. LISP also defines intermediate tunnel routers that can be used as landmarks in the path in the RLOC space, the Re-Encapsulating Tunnel Routers (RTR).

The figure above shows the basic operation of LISP. Host A wants to communicate (1) with its peer B, from which it only knows its EID. xTR X sends (2) a Map-Request to obtain the RLOC of the peer. This Map-Request is routed (3) through the Mapping System to finally reach the Map Server containing this information. The Map Server replies (4) to xTR X with a Map-Reply message. Finally, xTR X sends (5) the data to the xTR Y, which forwards it to the peer (6).

Architecture

This section gives a general vision of LISPmob software architecture. The LISPmob architecture relies on a few core ideas depicted in the figure below. There are two main modules, control and data , that govern the behaviour of LISPmob. To operate as different LISP devices, there are specific modules that modify the behaviour of data and control . The current LISPmob implementation is oriented towards operating as a LISP Mobile Node (MN) or a LISP Tunnel Router (xTR), however it can also operate as a Map Server/Map Resolver (MS/MR), a Re-Encapsulating Tunnel Router (RTR) or a Proxy Tunnel Router (PxTR). Some functions of the control module have been externalised to improve the modularity and manageability of the system. Such external modules include the databases system, the multihoming support and the interface management. LISPmob also uses the liblisp library, developed within the project, to parse and process LISP messages.

We divide the analysis of the internals of the software architecture into data-plane and control-plane, implemented by the data and control modules respectively. In the section discussing the data plane we describe how LISPmob encapsulates traffic into LISP data packets and how it decapsulates traffic from LISP data packets. In the section describing the control plane, we show how LISP control is managed, both in terms of processing control packets, as well as handling control state. Both data plane and control plane are implemented in a single user-space daemon.

Data plane

The LISPmob data plane operates on outgoing and incoming packets. It encapsulates common packets in LISP data packets prior to sending them over the network. It receives LISP data packets from the network and extracts the inner regular packet to forward it to the system. Both for incoming and outgoing traffic, LISPmob needs to capture, decapsulate and encapsulate and forward the packets.

LISPmob implements the data plane on the user space using TUN/TAP drivers. TUN virtual devices allow user space applications to receive and transmit network layer packets. LISPmob creates a TUN device to capture all the outgoing traffic coming from the EID space, and to forward the incoming traffic to the EID space. With this approach, LISPmob does not need to use any kernel code. Both data and control plane are managed by a single user space daemon. The TUN/TAP approach allows a straightforward communication between control and data plane, and serves to develop advanced features requiring intricate control-data operations (such as load balancing).

For outgoing traffic, LISPmob establishes routes and rules that redirect all, non-local EID space traffic to the TUN interface. LISPmob daemon receives the traffic reaching the TUN interface. If the traffic does not come from the EID space, it is natively forwarded into the system. Otherwise, LISPmob encapsulates the traffic into LISP prior to forwarding it into the system. LISP builds the external RLOC header and sends the encapsulated packet over raw sockets. LISPmob creates specific source routing rules to ensure that the encapsulated traffic is correctly forwarded through the appropiate interface.

To manage incoming traffic, LISPmob opens sockets listening for LISP data traffic. The LISPmob daemon processes all traffic received through those sockets. It removes the external encapsulation header and writes the inner packet on the TUN interface. The TUN interface forwards the EID packet to the EID space.

Control plane

The control plane on LISPmob is in charge of several tasks: it stores and accesses mappings, sends control messages and reacts to received ones, and keeps track of periodic events.

LISPmob stores mappings in two different data structures, depending on whether these mappings are local or not. The mappings related to EID prefixes belonging to the LISPmob node itself are stored in the local database . Mappings related to EIDs belonging to remote nodes are stored in the map-cache database . The local database is loaded from a configuration file during boot-up and remains static during LISPmob execution. The map-cache database instead is dynamically populated during LISPmob operation. Despite serving different purposes and being populated in different ways, the two databases share a similar internal structure. Both are implemented over a Patricia Tree structure (sometimes called Radix Tree) taking advantage of the hierarchical structure of IP addresses. This allows a query on either of the databases to return the most specific mapping for that prefix.

LISP control messages are (generally) not LISP encapsulated. LISPmob sends these packets through the desired output interface by means of the mechanisms described in the data-plane section. In order to receive LISP control packets from other LISP entities, LISPmob opens sockets on the LISP control port (UDP 4342). When a packet reaches one of these sockets, LISPmob triggers the control message processing mechanism. LISPmob will perform different actions, depending on the type of the packet received. In the case of a Map-Reply, for instance, it will store the newly arrived mapping on the map-cache database .

The LISP protocol requires performing some actions periodically, for instance sending control messages to the Mapping System from time to time. LISPmob keeps track of periodic events using a timer wheel algorithm. Event timers are placed in a wheel structure that rotates over time. Its position on the wheel indicates when the timer is going to expire. Timers are created with an assigned callback function and related data. Whenever the timer expires, the callback function is called with the associated data as a parameter.

Use cases

Over the years, individuals and companies have applied LISPmob for different scenarios. This section presents a selection of the most interesting use cases we are aware of.

Individuals

In the community around LISPmob, there are users that have reported successful usage of LISPmob for different scenarios. For instance, some of them are using it to get native IPv6 connectivity over IPv4-only providers (or the other way around). Others are using it as a way to easily keep a static, provider-independent IP address regardless from where they are connecting from. However, one of the most interesting usages is home-level multihoming.

Some users are deploying a simple multihoming solution based on LISP and two DSL connections (or one DSL and one mobile connection). Users request an EID prefix from the beta-network and get connectivity from two different ISPs to get several RLOCs. They then deploy a LISPmob box operating as router connected to both connection points. This allows them to get home-level multihoming, in an active-active scenario, with traffic balancing among the lines, and bandwidth aggregation.

Companies

There are companies that are interested in LISP but have no experience yet with the technology. They see LISPmob as a way to check if LISP covers their needs, prior to getting hardware-based commercial LISP solutions. Those companies use LISPmob as a proof-of-concept tool to deploy LISP test scenarios to experiment and get familiar with the technology.

Other companies use LISPmob as a way to provide LISP access to their users. An example of this scenario would be a company that offers services in the cloud and uses LISPmob to route user's traffic to their premises. They could deploy commercial LISP equipment on their data centre and provision users with LISPmob devices. They could put little plug'n'play boxes powered with OpenWRT and a preconfigured version of LISPmob at the home of the user. The LISPmob box would then encapsulate original user traffic towards the cloud system. Once the traffic has gone though the cloud service, the reply packets would be routed to the LISPmob box again to be decapsulated and forwarded to the user's equipment.

Projects

We are also seeing an increasing usage of LISPmob in community-driven projects such open-source platforms or academic research. LISPmob is used as a tool to prototype LISP scenarios and to evaluate new lines of networking research (LISP-specific or not). Furthermore, and following the growing interest of LISP as a Software Defined Networking (SDN) solution, LISPmob is being used in SDN scenarios. Particularly, it is a recommended LISP data plane to be used with the LISP control plane implemented in the OpenDaylight project, a referenced open-source SDN controller implementation.

Alberto is one of the successful candidates of the RIPE Academic Cooperation Initiative (RACI) and will be presenting his research at RIPE 69 .