PDF(166.8 KB) View with Adobe Reader on a variety of devices
Updated:February 27, 2012
Document ID:1518712164356336
Bias-Free Language
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Last updated: February 2012
Cisco Locator/ID Separation Protocol (LISP) is a new routing architecture that is a simple, incrementally deployable, network-based solution, enabling enterprises and service providers to simplify multi-homing routing, facilitate highly scalable network virtualization, support data center virtual machine mobility, and reduce operational complexities.
Challenge
The current Internet routing and addressing architecture uses a single numbering space, 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 DFZ (Default-Free Zone) as a consequence of multi-homing, non-aggregatable address allocations, and business events such as mergers and acquisitions.
Solution
Locator/ID Separation Protocol (LISP) creates a new paradigm by splitting the device identity, known as an Endpoint Identifier (EID), and its location, known as its Routing Locator (RLOC), into two different numbering spaces. Splitting EID and RLOC functions yields many benefits, including simplified and cost-effective multi-homing, ingress Traffic Engineering (TE) capabilities, IP address and host mobility, including session persistency across mobility event, IPv6 transition simplification, including incremental deployment of IPv6 using existing IPv4 infrastructure, and simplified, highly-scalable network virtualization.
Providing ingress TE capabilities is important for the enterprise to control and manage the utilization of the ingress bandwidth it pays for. LISP provides the ability to control ingress bandwidth in a simple and cost-effective manner. Because of its simple configuration and administration, LISP also helps enable sites to manage their own multihomed connectivity, thus eliminating associated outsourcing costs. Furthermore, LISP enables IPv6 connectivity over the existing IPv4 infrastructure.
Providing seamless VM mobility is important for organizations across geographic boundaries. LISP provides seamless VM Mobility across the data center, while providing optimal routing path.
Cisco is leading the LISP development effort through leadership in the IETF LISP Working Group, the development of LISP draft standards, through the development of LISP software, and the deployment and operation of a public LISP network. LISP is being developed as an open standard, with no Cisco intellectual property rights. A summary of many of these and efforts is can be found at
http://lisp.cisco.com
LISP Overview
From the outset, the Cisco philosophy for the development of LISP has been to minimize end-customer changes and deployment complexities. Figure 1 provides a very general overview illustration of the LISP deployment environment. As illustrated in Figure 1, three essential environments exist in a LISP environment: the LISP sites (EID namespaces), the non-LISP sites (RLOC namespaces), and the LISP Infrastructure.
Figure 1. LISP Deployment Environment
As illustrated in Figure 1, the LISP namespace represents customer end sites in exactly the same way that end sites are defined today. The only difference is that the IP addresses used within these LISP sites are not advertised within the non-LISP RLOC namespace. Here, end-customer LISP functionality is deployed exclusively on Customer Edge (CE) routers, which function in the LISP roles of Ingress Tunnel Router (ITR) and Egress Tunnel Router (ETR) devices. To fully implement LISP on an Internet-scale and in order to provide interoperability between LISP and non-LISP sites, additional LISP infrastructure components are required to be deployed as well. These additional LISP infrastructure components, as illustrated in Figure 1, support the LISP roles of Map-Server (MS), Map-Resolver (MR), Proxy Ingress Tunnel Router (PITR), and Proxy Egress Tunnel Router (PETR) devices. The specific functions implemented by each of the LISP devices illustrated in Figure 1 are discussed in the sections below.
LISP Site Edge Devices
• ITR-Ingress Tunnel Router is deployed as a CE device. It receives packets from site-facing interfaces, and either encapsulates packets to remote LISP sites or natively forwards packets to non-LISP sites.
• ETR-Egress Tunnel Router is deployed as a CE device. It receives packets from core-facing interfaces and either decapsulates LISP packets or natively delivers non-LISP packets to local EIDs at the site. It is common for LISP site edge devices to implement both ITR and ETR functions. When this is the case, the device is referred to as an xTR. The LISP specification does not require that a device perform both ITR and ETR functions, however. For both devices, the EID namespace is used inside the sites for end-site addresses for hosts and routers. EIDs go in Domain Name System (DNS) records, just as they do today. Generally speaking, the EID namespace is not globally routed in the underlying infrastructure. RLOC namespace on the other hand is used in the core. RLOCs are used as infrastructure addresses for LISP routers and ISP routers, and are globally routed in the underlying infrastructure, just like today. Hosts do not know about RLOCs, and RLOCs do not know about hosts.
LISP Infrastructure Devices
• MS-The Map-Server is deployed as a LISP Infrastructure component. It configures the LISP site policy for LISP ETRs that register to it. This includes the EID prefixes for which registering ETRs are authoritative, and an authentication key, which must match the one also configured on the ETR. Map-Servers receive Map-Register control packets from ETRs. When the MS is configured with a service interface to the LISP ALT, it injects aggregates for the EID prefixes for registered ETRs into the ALT. The MS also receives Map-Request control packets from the ALT, which it then encapsulates to the registered ETR that is authoritative for the EID prefix being queried.
• MR-The Map-Resolver is deployed as a LISP Infrastructure device. It receives Map-Requests encapsulated to it from ITRs, and when configured with a service interface to the LISP ALT, forwards Map-Requests to the ALT. Map-Resolvers also send Negative Map-Replies to ITRs in response to queries for non-LISP addresses.
• ALT-An Alternative Topology device is deployed as part of the LISP Infrastructure to provide scalable EID prefix aggregation. Because the ALT is deployed as dual-stack (IPv4 and IPv6) BGP over generic routing encapsulation (GRE) tunnels, ALT-only devices can be implemented using basic router hardware, or other off-the-shelf devices capable of supporting BGP and GRE.
LISP Interworking Devices
• PITR-A Proxy ITR is a LISP Infrastructure device that provides connectivity between non-LISP sites and LISP sites. A PITR does this by advertising coarse-aggregate prefixes for LISP EID namespace into the Internet, thus attracting non-LISP traffic destined to LISP sites. The PITR then encapsulates and forwards this traffic to LISP sites. This not only facilitates LISP/non-LISP interworking, but also allows LISP sites to see LISP ingress traffic engineering benefits from non-LISP traffic.
• PETR-A Proxy ETR is a LISP Infrastructure device that allows IPv6 LISP sites without native IPv6 RLOC connectivity, to reach LISP sites that only have IPv6 RLOC connectivity. In addition, the PETR can also be used to allow LISP sites with uRPF restrictions to reach non-LISP sites.
It is likely that a LISP interworking device will implement both PITR and PETR functions. When this is the case, the device is referred to as a PxTR. The LISP specification does not require that a device perform both PITR and PETR functions, however.
Cisco LISP Software
Cisco LISP capabilities are currently supported on a range of Cisco IOS and NX-OS routing platforms through both Early Deployment (ED) software releases, and through the mainline releases.
Customers who wish to perform a LISP trial can download the required LISP-enabled ED software or mainline release by going to
http://lisp.cisco.com
Platform Support
Cisco Locator/ID Separation Protocol (LISP) is available in Cisco IOS and NX-OS software feature sets as listed in Table 1.
Table 1. LISP Platform Support and License Required
Product Family
Platforms Supported
License
ISR 800 Series
860, 870, 880 and 890 Series
Advanced IP Services or Advanced Enterprise Services
ISR 1800 Series
1801, 1802, 1803, 1805, 1811, 1812, 1841, 1861
Advanced IP Services or Advanced Enterprise Services
ISR 1900 Series
1921, 1941, 1941W
Data license and up
ISR 2800 Series
2801, 2811, 2821, 2851
Advanced IP Services or Advanced Enterprise Services
ISR 2900 Series
2901, 2911, 2921, 2951
Data license and up
ISR 3800 Series
3825, 3845
Advanced IP Services or Advanced Enterprise Services
ISR 3900 Series
3925, 3925E, 3945, 3945E
Data license and up
7200 Series
7200-NPE-G2, 7201, 7204VXR, 7206VXR, 7301, 7304
Advanced IP Services or Advanced Enterprise Services
Feedback