Locator id separation protocol lisp1 routeable id version
Download
1 / 22

Locator/ID Separation Protocol (LISP1) [Routeable ID Version] - PowerPoint PPT Presentation


  • 302 Views
  • Updated On :

Locator/ID Separation Protocol (LISP1) [Routeable ID Version] Dino, Dave, Jason, Vince October 2006 Background Stimulated from problem statement effort at the Amsterdam IAB Routing Workshop on October 18/19 2006

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Locator/ID Separation Protocol (LISP1) [Routeable ID Version]' - elina


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Locator id separation protocol lisp1 routeable id version l.jpg

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

Dino, Dave, Jason, Vince

October 2006

Last Updated: Mon Nov 13 16:46:59 PST 2006


Background l.jpg
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


Agenda l.jpg
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


Scaling internet routing l.jpg
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


Site based requirements l.jpg
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


Provider based requirements l.jpg
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


A recent address allocation plan l.jpg
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


Locator id separation l.jpg
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


Locator id separation9 l.jpg
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


Locator id separation10 l.jpg
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


Lisp overview l.jpg
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


Lisp terminology l.jpg
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


How lisp works l.jpg

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


Some lisp details l.jpg
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


Some lisp details15 l.jpg
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


Some lisp details16 l.jpg
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


Lisp observations l.jpg
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


Lisp observations18 l.jpg
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


Lisp drawbacks l.jpg
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


Other lisp usage scenarios l.jpg
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


Rough implementation plan l.jpg
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


Summary l.jpg
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