Locator/ID Separation Protocol (LISP1) [Routeable ID Version]

1. Locator/ID Separation Protocol(LISP1)[Routeable ID Version] Dino, Dave, Jason, Vince October 2006 Last Updated: Mon Nov 13 16:46:59 PST 2006

2. Background • Stimulated from problem statement effort at the Amsterdam IAB Routing Workshop on October 18/19 2006 • The solution started at dinner between Dino Farinacci, Dave Oran, and Jason Schiller on day-1 of workshop • Discussions continued with various people on day-2 of workshop, primarily with Lixia Zhang and Vince Fuller Dino, Dave, Jason, Vince

3. Agenda • Scaling the Internet • PA Addressing • Site and Provider Requirements • PI Addressing • Locator/ID Separation • Decoupling is critical • LISP • A packet forwarding mechanism to support decoupling • Encourages route aggregation for scalability • Implementation Plan Dino, Dave, Jason, Vince

4. Scaling Internet Routing • Fundamentally, scale the Internet by reducing routing table size • Route aggregation is really the only proven method to reduce routing table size • Without sacrificing route optimiality • Site addresses must be allocated out of blocks provided by their upstream providers • Provider Assigned (PA) Dino, Dave, Jason, Vince

5. Site-Based Requirements • Sites need to be multihomed • Connected to more than one provider • Sites need flexibility to change providers • While maintaining session survivability • Site-supported devices need to be mobile • While maintaining session survivability • Sites need to easily renumber their devices • While maintaining session survivability Dino, Dave, Jason, Vince

6. Provider-Based Requirements • Providers need their routers to scale or they can’t deliver any service • Providers need to maximize their resources to deliver cost effective connectivity • Providers want the ability to do Traffic Engineering • Provider-supported devices need to be mobile • While maintaining session survivability • While achieving scalability Dino, Dave, Jason, Vince

7. A Recent Address Allocation Plan • Provider Independent Assigned (PI) • Sites get route prefixes that are not more specific than their upstream providers • Advantage to Sites • They never have to renumber, they keep their PI addresses forever • They can share their entry/exit points • Disadvantages to Providers • They have to carry more route prefixes • The Internet is doing flat site-based routing • This cannot scale Dino, Dave, Jason, Vince

8. Locator/ID Separation • Today, an IP address is used both as a “endpoint ID” (aka ID) and a “location ID” (aka Locator) • If one changes, the other has to change • If the ID was not changeable but the Locator was dynamically changeable: • You could have session survivability when a device is renumbered • You could have session survivability when a device moves Dino, Dave, Jason, Vince

9. Locator/ID Separation • Being able to change the Locator allows devices at sites to stay in PA space • This will allow the routing table to be as small as possible • This allows the site to easily change providers • You could also use PI space • Transport IDs use PI space (which wouldn’t be routable) • While Locators would use PA space (routable and aggregatable) Dino, Dave, Jason, Vince

10. Locator/ID Separation • We need a mechanism to: • Associate an ID with a set of Locator addresses • Forward packets using Locator addresses • Maintain the reachability status of Locator addresses • The mechanism needs to be: • Simple so it can be easily and incrementally deployed • Does not depend on a lot of Internet infrastructure • Does not require transit non-TE routers to carry state • No specialized ID/Locator binding service • Flexible so both Sites and Providers can benefit • Pragmatic so it can be deployed in <= 12 months Dino, Dave, Jason, Vince

11. LISP Overview • Uses well-known IP-in-IP tunneling technology • IDs are stored in the inner IP header (the header the source host builds) • Locators are stored in the outer IP header (the header the tunnel ingress router builds) • The tunnel endpoint routers: • Keep the ID-to-Locator(s) cache • The Locator Addresses are the IP addresses of the egress tunnel router(s) • The tunnel endpoint routers can be: • First-hop and last-hop routers (directly connected to endpoints) • Site-resident border routers • And for TE cases, provider-resident routers Dino, Dave, Jason, Vince

12. LISP Terminology • The LISP “Cache” is: • The ID->Locator(s) mappings learned from ICMP messages • The cache is built on demand • Caches have the information to get you somewhere • The LISP “Database” is: • The configured IP addresses of routers which are used as Locator addresses for hosts that have IDs assigned from subnets attach to the routers (or learned via the IGP in the tunnel border router case) • Advertised in ICMP messages only when decapsulating a control packet • Databases have the information for others to get to you Dino, Dave, Jason, Vince

13. S R B C D A How LISP Works Provider A 10.0.0.0/8 S’s ID is 1.1.1.1 11.1.1.12 11.1.1.13 1.1.1.1 1.0.0.0/8 Internet 1.1.1.11 1.1.1.10 10.0.1.13 10.0.1.12 10.0.1.1 10.0.1.0/24 Provider B 11.0.0.0/8 R’s ID is 10.0.1.1 1) S wants to talk to R, S gets R’s ID from DNS 2) S sends packet to R with SA=1.1.1.1, DA=10.0.1.1 3) S’s default router is router A, A does route lookup for 10.0.1.1, matches on default route,indicator to tunnel encapsulate 4) A builds outer IP header with SA=1.1.1.10, DA=10.0.1.1, IP-prot=“LISP-control” 5) When packets flow to C, IP-prot is “LISP-control” means to send an ICMP ID-mapping packet to SA (1.1.1.10), the ICMP packet contains Locators 10.0.1.12 & 11.1.1.12 6) A caches ID-mapping of 10.0.1.1->{10.0.1.12, 11.1.1.12} 7) Subseqent packets from S, A will set outer DA to 10.0.1.12 (the Locator for R), IP-prot=“LISP-data” 8) Packets are addressed to C, which decapsulates tunnel packet and delivers to R. 9) If connectivity to 10.0.1.12 changes, due to Provider A path is down or R moves, A gets back a ICMP-host-unreachble (from any router on the path) for address 10.0.1.12. Subsequent packets from S get enapsulated by A to address 11.1.1.12. 10) Periodically A can send IP-prot=“LISP-control” packets to the unreachable locator address and when the SA is that Locator address in the returning ICMP ID-mapping message, A can conclude the Locator is reachable again 11) C could glean ID->Locator mapping when decapsulating and avoid the signalling step back. 12) A could encapsulate packets for S with alternating SA Locator address so when C gleans, it can get all Locator addresses for S’s ID. On host subnet 10.0.1.0/24: C is 10.0.1.12 (PA from Provider A) D is 10.0.1.13 (PA from Provider A) On Loopback interfaces: C is 11.1.1.12 (PA from Provider B) D is 11.1.1.13 (PA from Provider B) Dino, Dave, Jason, Vince

14. Some LISP Details • Why two IP protocol numbers? • “LISP-Control” is used by the hardware forwarding engine to decapsulate and forward packets in hardware and signal the control-plane to send an ICMP ID-mapping message • These packets are not addressed to the router • Because the DA is the ID/Locator of the host • “LISP-Data” is used by the hardware forwarding engine to decapsulate and forward packets in hardware in most cases • These packets are addressed to the router • But if gleaning is done, then rate-limit to the control-plane so to cache ID-Locator mapping from data packet Dino, Dave, Jason, Vince

15. Some LISP Details • ICMP ID-Mapping Messages • Need to be rate-limited to the ingress tunnel router by the egress tunnel router • An implementation which gleans can keep a rate-limiter per ID in the LISP Cache • Locator/ID mappings need to be authenticated or signed so third-party intrusion can be avoided • Use digital signatures • Use nonces • When multiple egress tunnel routers are in use, there is no Locator/ID mapping synchronization among them Dino, Dave, Jason, Vince

16. Some LISP Details • ICMP Host-Unreachable Messages • The cache needs to figure out when a Locator becomes reachable again • Periodic control packet probe only tells you the egress tunnel router Locator is valid but there is no positive feedback as to the path being reachable • Possible Solutions • The ICMP Host-Unreachable sender could avoid sending the message and try to use another Locator • But multiple Locators would need to be in the data packet and a DA rewrite required • Don’t want to do this • The SA from the ICMP ID-Mapping message is one of the Locator addresses • If this message contained invoking data message header, we have reachability confirmation for the DA Locator in the invoking packet • Do want to do this Dino, Dave, Jason, Vince

17. LISP Observations • There are absolutely no host changes • Changes to routers are in very few places • High-end site or provider core routers don’t have to change • The tunnel endpoint routers can be low/mid-end routers • Read: cheap and rapid deployment Dino, Dave, Jason, Vince

18. LISP Observations • There is no centralized ID->Locator database • Distributed where the locators exist and are managed • ID->Locators mappings stay more up to date • Caches can be centralized (if border router is tunnel endpoint) or distributed (if tunnel endpoint is closer to the hosts) • We can use “ID Prefixes” to reduce the size of caches with Locator set is the same • There are no new protocols • Just a new ICMP packet type • Minimal (if any) hardware changes required • Allows fast product delivery and deployment Dino, Dave, Jason, Vince

19. LISP Drawbacks • If PI addresses are used for IDs • LISP requires them to be routable • How to reduce routeable PI usage: • Create an economic incentive to not use them • For large sites renumbering is costly, so they pay and can afford routeable PIs • Small sites use PA because renumbering is easier and they can’t afford routeable PIs • We just created a provider revenue generator but they need to share that revenue with peer providers since others bear the cost of carrying PI routes as well • Create a automatic method for renumbering • So it’s easy to renumber when there is a PA site change • Then PA addresses are used for IDs everywhere Dino, Dave, Jason, Vince

20. Other LISP Usage Scenarios • Border router tunneling • The ID->Locator database and cache for entire site is centralized in border router(s) • 1000s of site hosts could share a few Locator addresses • Provider router tunneling • When provider wants TE, it can prepend and strip its own outer IP header • Can have recursive tunneling if both site and provider do LISP • Ingress tunnel router decides path to destination since it selects the Locator • ICMP ID-mapping packet could rank Locators so destination can have a say which entry point is used Dino, Dave, Jason, Vince

21. Rough Implementation Plan • Prototype a software forwarding version • Dino to write IP forwarding code in DC-OS • Dino to make ICMP changes in DC-OS • Provide eval platforms for lab testing • Vince/Dave M tests internally at cisco • Jason, Vijay, Dorian/Peter, Ted/Peter test externally • That would be UUnet/VB, AOL, NTT/Verio, and Sprint • Lixia and Geoff could test in research labs • Recruit multiple vendors for prototype interoperability testing • Report on deployment at Spring IETF • Or at an earlier workshop • In parallel, determine hardware requirements Dino, Dave, Jason, Vince

22. Summary • Must do PA assignment to scale routing • Locator/ID separation is a sound concept and is necessary • LISP defines the encapsulation format for packet delivery and a simple ID->Locator management mechanism • Do a cisco router prototype • Start pilot deployment Dino, Dave, Jason, Vince