Locator/ID Separation Protocol (LISP) -- Cisco Systems, Inc.

LISP Overview Page

What's the Problem?

The current Internet routing and addressing architecture uses a single namespace -- the IP address, to simultaneously
express two functions about a device: its identity and how it is attached to the network. One very visible and detrimental
result of this single numbering space is manifested in the rapid growth of the Internet's default-free zone (DFZ) as a
consequence of multihoming, traffic engineering (TE), nonaggregatable address allocations, and business events such as
mergers and acquisitions.

This problem has been further exacerbated by two further conditions. The first is IPv4 address space depletion which has
led to a finer breakup of IPv4 addresses with less aggregation potential, especially in the case of Provider Independent (PI)
addressing. The second is the increasing occurance of dual-stack routers supporting both IPv4 and IPv6 protocols. IPv6 did
not change anything about the use of IP addresses (no inherent locator separation) and so it suffers from the same
problems as IPv4 - only with larger addresses.

From a Customer perspective, they face significant challenges in many aspects of operating their networks. Some of the
more important areas of concern include:

• the complexity of todays networks, especially when multi-homing is required for increased bandwidth and availability
  and for resiliency. Often times a network staff with a "PhD in BGP" is required to support routine operations.
• the complexities and expenses associated with site re-numbering when changing services providers inhibits
  competition, and is detrimental to the development of new services.

What is LISP?

LISP is a network architecture and set of protocols that implements a new semantic for IP addressing. LISP creates two namespaces
and uses two IP addresses: Endpoint Identifiers (EIDs), which are assigned to end-hosts, and Routing Locators (RLOCs), which are
assigned to devices (primarily routers) that make up the global routing system. Performing this separation offers several advantages,
including:

• Improved routing system scalability by using topologically-aggregated RLOCs
• Provider-independence for devices numbered out of the EID space (IP portability)
• Low-OPEX multi-homing of end-sites with improved traffic engineering
• IPv6 transition functionality
• IP mobility (EIDs can move without changing - only the RLOC changes!)

LISP is a simple, incremental, network-based implementation that is deployed primarily in network edge devices.
It requires no changes to host stacks, DNS, or local network infrastructure, and little to no major changes to
existing network infrastructures.

Learn More About LISP in this presentation! Updated!

How Does LISP Solve the Problem?

The concept of a "location/ID separation" has been under study by the IETF and various universities and researchers for
greater than 15 years. Finally, a Routing and Addressing Workshop that was held by the Internet Architecture Board (IAB)
took up the problem, as documented inRFC4984. The concept of Locator/ID Separation has long been considered
important to resolving the DFZ routing table scaling issues. By splitting the device identity, its Endpoint Identifier (EID),
and the device location, its Routing Locator (RLOC), into two different namespaces, improvements in scalability of the
routing system can be achieved through greater aggregation of RLOCs.

Cisco researchers decided that the only way to see whether Locator/ID separation could indeed be effective was to develop
draft standards and implement them in code to test the theory. With that, Cisco began the LISP initiative. LISP
standards are currently being developed within the IETF LISP Working Group. In addition to leading this standards effort,
Cisco is also developing LISP software for both Cisco IOS and NX-OS platforms, as well as gaining working experience with
LISP through the deployment and operation of a public LISP network.

Cisco's contributions to LISP are being developed as open standards, with no Cisco intellectual property rights (IPR).
We feel it is in the best interest of the overall Internet community to resolve the issues facing the Internet today.
A healthy and growing Internet benefits everyone, including Cisco. Cisco has constantly sought to stimulate outside
interest and development efforts from the outset. Other LISP development is being pursued by the open source community,
several competitive companies, and many researchers and universities.

Now That We Have LISP, What Else Can We Do?

Once LISP began to take shape, other benefits of locator/ID separation soon became apparent. There are "five" LISP
Core Use-Cases, including:

• Case #1 -- Low OpEx multihoming with ingress traffic engineering (TE) capabilities provides control and
  management of the utilization of the ingress bandwidth that is being paid for. This is accomplished while
  eliminating the need for Border Gateway Protocol (BGP) peering with upstream service providers. This case
  also supports eliminating the need for site renumbering and the associated complexities and costs when
  changing service providers by decoupling site addressing from core addressing.
• Case #2 -- IPv6 Transition support provides inherent, day-one Address-Family agnostic flexibilities.
  Incorporating LISP into an IPv6 transition or coexistence strategy can both speed and simplify the initial
  rollout of IPv6 by taking advantage of the LISP mechanisms to encapsulate IPv6 host packets within IPv4
  headers (or IPv4 host packets within IPv6 headers). Incorporating LISP into an IPv6 transition strategy
  has demonstrated quick deployment times, low deployment and operational costs, little or no need for
  additional equipment or modifications, and high user-satisfaction.
• Case #3 -- Virtualization/Multi-tenancy support provides the capability to segment traffic with minimal
  infrastructure impact, but with high scale and global scope. Control plane and data plane traffic are
  segmented by mapping VRFs to LISP "instance-id's," making this overlay solution highly flexible, highly
  scalable, and inherently low OpEx.
• Case #4 -- Data Center VM-Mobility support provides location flexibility for IP endpoints within the data
  center network and across the Internet due to the servers’ identifiers (EIDs) being separated from their
  location (RLOC). By using Cisco LISP VM-Mobility, you can deploy IP endpoints such as virtual machines
  anywhere regardless of their IP addresses and can freely move them across data center racks and rows, to
  separate locations, and globally across organizations.
• Case #5 -- LISP Mobile-Node support provides a "lightweight" version of LISP's ITR/ETR functionality can
  be used to provide seamless mobility to a mobile node. This allows TCP connections to stay alive while
  roaming, for example, and allows mobile nodes to communicate with other mobile nodes, while either or
  both are roaming -- across the "shortest path" (no home agent).

LISP Beta Network

LISP has been operational for more than 5 years now, first in on experimental and code-development basis, progressing
to todays' LISP Beta Network that includes close to 600 LISP Sites in 34 countries, operating in both IPv4 and IPv6 EID
and RLOC space. LISP Beta Network also runs multiple LISP implementations, including Cisco, AVM (Fritz!Box), OpenWrt, Linux,
Android, and others. You can learn more about the LISP Beta Network here:www.lisp4.net and www.lisp6.net

If you would like to join the LISP Beta Network, please send an email to: lisp-support@cisco.com [lisp-support@cisco.com]

Mail to: lisp-support@cisco.com [lisp-support@cisco.com]

LISP -- We've Got Bigger Fish To Fry...