Locator/ID Separation Protocol provides a method of routing packets that enables virtual machines (VMs) to move...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
from server to server or mobile devices to move seamlessly between Wi-Fi and cellular networks without changing software on endpoints.
This fall, LISP IETF draft RFCs are scheduled for release, coming on the heels of draft RFCs issued earlier in 2012. These follow the previous release of several public domain LISP implementations and a beta network set up in 2010.
Why the need for Locator/ID Separation Protocol?
Traditional IP forwarding mechanisms cease to work when nodes move from network to network. The difficulty arises because IP addresses, both IPv4 and IPv6, include both a network number and a network interface address. The network number is used to route packets to the proper network; the interface address is used to select a node on that network.
Once a node moves to another network, the network part of the address is no longer valid. Updating the end point IP address as the node moves requires modifying node software, which is not practical for either a VM or mobile device.
How Locator/ID Separation Protocol works
In the traditional case, where end nodes don't move, a node with a packet to send, finds the End Point Identifier (EID) of the destination node either through a DNS lookup or by having previously received a packet from that destination. The EID is simply the IP address of the destination node, and the Routing Locator (RLOC) portion accurately identifies the destination's local network. The packet is sent through the local network to the router that provides the pathway to the Internet. That router determines how to reach the destination network using standard routing protocols.
Locator/ID Separation Protocol definitions
Several definitions are used throughout the LISP specifications.
EID – End point identifier is the IP address assigned to an end point when it is initialized, typically by Dynamic Host Configuration Protocol. A device or virtual machine's EID does not change as it moves from network to network.
ETR – Egress Tunnel Router is the router that transfers packets from the Internet to the local network on which the destination end node is currently located.
ITR – Ingress Tunnel Router is the router that transfers packets to the Internet from the local network on which the source node is located. Since packets move in both directions, a router serves as an ITR for packets exiting its network and as an ETR for packets arriving from the Internet and destined for nodes on its network.
RLOC – Routing Locator is the network identifier portion of an IP address. It's used to route packets from ITR to ETR.
When nodes move, the traditional method of routing packets doesn't work. A node with a packet to send learns the EID of the destination via DNS or a previously received packet just as in the traditional case. In the mobile case, however, the RLOC contained in the EID is not valid. The mobile node's EID was assigned when the node was initialized. Once the node moves, the RLOC portion can no longer be used to route packets to the mobile destination.
LISP solves this problem by adding an additional IP header to packets sent to mobile nodes. Ingress Tunnel Routers (ITRs) learn about the current location of a mobile node via the mapping function defined by the Location/ID Separation Protocol (LISP).
When an ITR receives a packet sent from a node on its connected local network, it queries the LISP mapping function. The mapping function responds with the RLOC needed to reach the destination node at its current location.
The ITR then prefixes the outgoing packet with an additional header and places the RLOC learned from the mapping service in the header. The packet can then be routed through the Internet using standard routing protocols. LISP does not require any modification to routing protocols or Internet core routers.
On arrival at the destination network, the receiving Egress Tunnel Router (ETR) strips off the added header. It then forwards the packet over its local network to the destination node. The received packet appears to the destination node just as it would if there had been no movement. As a result, LISP doesn't require any change to node software.
ITRs cache the results of mapping service queries so there is no need to query for each subsequent packet. The mapping service will supply an updated RLOC if the destination node moves while the connection continues.
Locator/ID Separation Protocol benefits beyond mobility
- Permits sites to switch Internet service providers without renumbering end nodes
- Enables multi-homed nodes to spread load over multiple links
- Supports both IPv4 and IPv6 and can simplify the IPv4 to IPv6 transition
Locator/ID Separation Protocol mapping
The LISP mapping function responds to requests from ITRs for the proper RLOC needed to reach a remote node. Several designs have been proposed, but current work includes network components that operate as "map servers" and "map resolvers." ETRs periodically send "map register" messages to a map server. Map register messages list the EIDs that are currently accessible via that ETR.
Map servers are connected by Generic Router Encapsulation (GRE) tunnels. Each map server distributes information about EIDs received from connected ETRs to other map servers via Border Gateway Patrol (BGP). Actual EID-to-RLOC information is stored on ETRs. There is no central database of EID-to-RLOC mappings.
When an ITR needs to forward a packet but does not have information about which RLOC to use it on, it sends a "map request" to a "map resolver." The map resolver uses information learned via BGP to determine the appropriate ETR. The map resolver then forwards the map request to the ETR, which responds by sending a map reply to the originating ITR. The ITR appends the additional header on the packet and places the received RLOC in the destination address field.
About the author
David B. Jacobs of The Jacobs Group has more than twenty years of networking industry experience. He has managed leading-edge software development projects and consulted to Fortune 500 companies as well as software startups.