Locator/Identifier Separation Protocol

Locator/ID Separation Protocol (LISP) (RFC 6830) is a "map-and-encapsulate" protocol which is developed by the Internet Engineering Task Force LISP Working Group.[1] The basic idea behind the separation is that the Internet architecture combines two functions, routing locators (where a client is attached to the network) and identifiers (who the client is) in one number space: the IP address. LISP supports the separation of the IPv4 and IPv6 address space following a network-based map-and-encapsulate scheme (RFC 1955). In LISP, both identifiers and locators can be IP addresses or arbitrary elements like a set of GPS coordinates or a MAC address.[2]

This article is about an Internet communication protocol. For a programming language, see Lisp (programming language).
The LISP Logo

Historical origin

The Internet Architecture Board's October 2006 Routing and Addressing Workshop [3] renewed interest in the design of a scalable routing and addressing architecture for the Internet. Key issues driving this renewed interest include concerns about the scalability of the routing system and the impending exhaustion of IPv4 address space. Since the IAB workshop, several proposals have emerged that attempted to address the concerns expressed at the workshop. All of these proposals are based on a common concept: the separation of Locator and Identifier in the numbering of Internet devices, often termed the "Loc/ID split".[4]

Current Internet Protocol Architecture

The current namespace architecture used by the Internet Protocol uses IP addresses for two separate functions:

  • as an end-point identifier to uniquely identify a network interface within its local network addressing context
  • as a locator for routing purposes, to identify where a network interface is located within a larger routing context

LISP

There are several advantages to decoupling Location and Identifier, and to LISP specifically.[5]

  • Improved routing scalability
  • BGP-free multihoming in active-active configuration
  • Address family traversal: IPv4 over IPv4, IPv4 over IPv6, IPv6 over IPv6, IPv6 over IPv4
  • Inbound traffic engineering
  • Mobility
  • Simple deployability
  • No host changes are needed
  • Customer driven VPN provisioning replacing MPLS-VPN
  • Network virtualization
  • Customer operated encrypted VPN based on LISP/GETVPN replacing IPsec scalability problems
  • High availability for seamless communication sessions through (constraint-based) multihoming

A recent discussion of several LISP use cases may be found in [6]

IETF has an active workgroup establishing standards for LISP. As of 2016, the LISP specifications are on the experimental track. The LISP workgroup plans moving the core specifications onto the standards track in 2017.

Terminology
  • Routing Locator (RLOC): A RLOC is an IPv4 or IPv6 address of an egress tunnel router (ETR). A RLOC is the output of an EID-to-RLOC mapping lookup.
  • Endpoint ID (EID): An EID is an IPv4 or IPv6 address used in the source and destination address fields of the first (most inner) LISP header of a packet.
  • Egress Tunnel Router (ETR): An ETR is a device that is the tunnel endpoint; it accepts an IP packet where the destination address in the "outer" IP header is one of its own RLOCs. ETR functionality does not have to be limited to a router device; server host can be the endpoint of a LISP tunnel as well.
  • Ingress Tunnel Router (ITR): An ITR is a device that is the tunnel start point; it receives IP packets from site end-systems on one side and sends LISP-encapsulated IP packets, across the Internet to an ETR, on the other side.
  • Proxy ETR (PETR): A LISP PETR implements ETR functions on behalf of non-LISP sites. A PETR is typically used when a LISP site needs to send traffic to non-LISP sites but the LISP site is connected through a service provider that does not accept nonroutable EIDs as packet sources.
  • Proxy ITR (PITR): A PITR is used for inter-networking between Non-LISP and LISP sites, a PITR acts like an ITR but does so on behalf of non-LISP sites which send packets to destinations at LISP sites.[7]
  • xTR: A xTR refers to a device which functions both as an ITR and an ETR (which is typical), when the direction of data flow is not part of the context description.[8]
  • Re-encapsulating Tunnel Router (RTR): An RTR is used for connecting LISP-to-LISP communications within environments where direct connectivity is not supported. Examples include: 1) joining LISP sites connected to "disjointed locator spaces"—for example a LISP site with IPv4-only RLOC connectivity and a LISP site with IPv6-only RLOC connectivity; and 2) creating a data plane 'anchor point' by a LISP-speaking device behind a NAT box to send and receive traffic through the NAT device.[9]

The LISP mapping system

In the Locator/Identifier Separation Protocol the network elements (routers) are responsible for looking up the mapping between end-point-identifiers (EID) and route locators (RLOC) and this process is invisible to the Internet end-hosts.[10][11] The mappings are stored in a distributed database called the mapping system, which responds to the lookup queries. The LISP beta network initially used a BGP-based mapping system called LISP ALternative Topology (LISP+ALT),[12] but this has now been replaced by a DNS-like indexing system called DDT inspired from LISP-TREE.[13] The protocol design made it easy to plug in a new mapping system, when a different design proved to have benefits. Some proposals have already emerged and have been compared.

Implementations
  • Cisco has released public IOS, IOS XR, IOS XE and NX-OS images which support LISP.
  • A team of researchers from the Université catholique de Louvain and T-Labs/TU Berlin have written a FreeBSD implementation called OpenLISP.[14]
  • The LIP6 lab of UPMC, France, has implemented a fully featured control-plane (MS/MR, DDT, xTR) for OpenLISP [15][16]
  • Historically, LISPmob was an open source implementation of LISP for Linux, OpenWRT and Android maintained at Polytechnic University of Catalonia. It could act as xTR or LISP Mobile Node.[17] Recently, this implementation has been further developed into a full open source LISP router called the "Open Overlay Router" or OOR (see OpenOverLayRouter)
  • AVM GmbH added LISP-support in firmware for their FRITZ!Box-devices in FRITZ!OS 6.00 and supports LISP in the recent versions, too
  • LANCOM Systems supports LISP in the router operating system LCOS
  • HPE supports LISP in their Comware 7 platform based routers (under the marketing name FlexNetwork MSR and VSR). This platform is developed by H3C Technologies and sold in China under their own logo.
  • OpenDaylight supports LISP flow mappings.
  • ONOS develops a distributed LISP control plane as an SDN application.[18] [19]
  • Lispers.net provides an open source, feature complete implementation of LISP.[20]
  • fd.io also supports LISP by the Overlay Network Engine (ONE).[21]
  • A simple LISP Mapping System implementation is also available in Java. [22]

LISP beta network

A testbed has been developed to gain real-life experience with LISP. Participants include Google, Facebook, NTT, Level3, InTouch N.V. and the Internet Systems Consortium.[23] As of January 2014, around 600 companies, universities, and individual contributors from 34 countries are involved. The geographical distribution of participating routers, and the prefixes they are responsible for, can be observed on the LISPmon project website (updated daily). The multi-company, LISP-community initiative LISP4.net/LISP6.net publishes relevant information about this beta network on http://www.lisp4.net/ and http://www.lisp6.net/. Since March 2020 the LISP Beta Network is not maintained anymore.

LISP-Lab consortium research network

The LISP-Lab project,[24] coordinated by UPMC/LIP6, aims at building a LISP network experimentation platform exclusively built using open source LISP nodes (OpenLISP) acting as ITR/ETR tunnelling routers, MS/MR mapping servers/resolvers, DDT root and Proxy ITR/ETR. Partners include two academic institutions (UPMC, TPT), two Cloud Networking SME (Alphalink, NSS), two network operators (Renater, Orange), two SMEs on Access/Edge Networking (Border 6, Ucopia) and one Internet eXchange Point (Rezopole). More information on https://web.archive.org/web/20190508220217/http://www.lisp-lab.org/ . The platform should be opened to external partners on 2014/2015 and is already interconnected to the LISP Beta Network with an OpenLISP DDT root.[25]

Future use of LISP

ICAO is considering Ground-Based LISP as a candidate technology for the next-generation Aeronautical Telecommunications Network (ATN).[26] The solution is under further development in part of the SESAR (Single European Sky ATM Research) FCI activities.

Other approaches

Several proposals for separating the two functions and allowing the Internet to scale better have been proposed, for instance GSE/8+8 as network based solution and SHIM6, HIP and ILNP as host based solutions.

See also

References
  1. "Locator/ID Separation Protocol (lisp) Working Group".
  2. "LISP Canonical Address Format (LCAF)".
  3. "RFC4984 - Report from the IAB Workshop on Routing and Addressing". Retrieved 2010-10-28.
  4. "IETF I-D Architectural Implications of Locator/ID Separation".
  5. "IETF I-D draft-brim-lisp-analysis". Retrieved 2010-10-28.
  6. Saucez, Damien ; Iannone, Luigi ; Bonaventure, Olivier ; Farinacci, Dino, Designing a Deployable Future Internet: the Locator/Identifier Separation Protocol (LISP) case IEEE Internet Computing, December 2012.
  7. "Interworking LISP with IPv4 and IPv6".
  8. "Interworking LISP with IPv4 and IPv6".
  9. "NAT traversal for LISP".
  10. IPJ article about LISP
  11. Scaling the Internet with LISP Archived 2010-03-15 at the Wayback Machine tutorial
  12. "LISP Alternative Topology (LISP+ALT)".
  13. Jakab, Lorand; Cabellos-Aparicio, Albert; Coras, Florin; Saucez, Damien; Bonaventure, Olivier (2010). "LISP-TREE: A DNS Hierarchy to Support the LISP Mapping System". IEEE Journal on Selected Areas in Communications. 28 (8): 1332–1343. CiteSeerX 10.1.1.716.8421. doi:10.1109/JSAC.2010.101011.
  14. Iannone, Luigi; Saucez, Damien; Bonaventure, Olivier (March 2011). "Implementing the Locator/ID Separation Protocol: Design and Experience". Computer Networks. 55 (4): 948–958. CiteSeerX 10.1.1.648.3739. doi:10.1016/j.comnet.2010.12.017.
  15. Open LISP control-plane project: https://github.com/lip6-lisp/control-plane
  16. Research activities on LISP at LIP6: http://www.lisp.ipv6.lip6.fr (webserver hosted behind the LISP Beta Network)
  17. "IETF I-D draft-meyer-lisp-mn". Retrieved 2011-09-13.
  18. https://github.com/K-OpenNet/ONOS-LISP-Management-Plane
  19. https://github.com/opennetworkinglab/onos/tree/master/protocols/lisp
  20. https://github.com/farinacci/lispers.net
  21. https://wiki.fd.io/view/Project_Proposals/Overlay_Network_Engine
  22. https://github.com/jLisp/jlisp
  23. "LISP Site Status". Retrieved 2010-10-28.
  24. LISP-Lab project website: http://www.lisp-lab.org Archived 2019-05-08 at the Wayback Machine
  25. DDT root website: http://ddt-root.org
  26. "Ground-Based LISP for the Aeronautical Telecommunications Network". Retrieved 2018-03-06.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.