LISP-CONS A Mapping Database Service IETF/IRTF - July 2007

LISP-CONSLISP-CONS

A Mapping Database ServiceA Mapping Database Service

IETF/IRTF - July 2007IETF/IRTF - July 2007 Dave Meyer

Dino FarinacciVince FullerDarrel LewisScott Brim

Noel Chiappa

LISP-CONS for RRGLISP-CONS for RRG IETF/IRTFIETF/IRTF Slide Slide 22

AgendaAgenda• Brief Intro• Design Considerations• Brief Definitions• How CONS Works• Hybrid Approaches

– Combining NERD and CONS– Combining APT and CONS– Is LISP 1.5 sufficient?


Problem StatementProblem Statement• Operationally

– Improve site multihoming– Improve ISP Traffic Engineering– Reduce site renumbering costs– Reduce size of core routing tables– PI for all?– Some form of mobility?

• Architecturally– Create two namespaces: IDs and Locators


Splitting an AddressSplitting an Address

2001:0102:0304:0506:1111:2222:3333:4444

Locator ID

IPv6:

209.131.36.158IPv4:

Locator

.10.0.0.1

ID


LISP is a Jack-UpLISP is a Jack-Up

Host StackUses IDs

Map-n-EncapUses Locators


LISP PartsLISP Parts

• Data-plane– Design for encapsulation and tunnel

router placement– Design for locator reachability– Data triggered mapping service

• Control-plane– Design for a scalable mapping service


LISP VariantsLISP Variants• LISP 1

– Routable IDs over existing topology to probe for mapping reply

• LISP 1.5– Routable IDs over another topology to probe for

mapping reply

• LISP 2– EIDs are not routable and mappings are in DNS

• LISP 3– EIDs are not routable, mappings obtained using new

mechanisms (DHTs perhaps, LISP-CONS, NERD, APT)

Data-Plane Mapping

Control-Plane Mapping


Quick LISP TermsQuick LISP Terms• Endpoint Identifiers (EIDs)

– IDs for host-use and routeable in source and dest sites

– Can be out of PA or PI address space

• Routing Locators (RLOCs)– Routeable addresses out of PA address space

• Ingress Tunnel Router (ITR)– Device in source-site that prepends LISP header with

RLOCs

• Egress Tunnel Router (ETR)– Device in destination-site that strips LISP header


LISP Control-PlaneLISP Control-Plane

• Build a large distributed mapping database service• Scalability paramount to solution• How to scale:

(state * rate)• If both factors large, we have a problem

– state will be O(1010) hosts– Aggregate EIDs into EID-prefixes to reduce state– So rate must be small– Make mappings have “subscription time”

frequency


LISP Control-PlaneLISP Control-Plane• Where to put the mappings?• How to find the mappings?• Is it a push model?• Is it a pull model?• Do you use secondary storage?• Do you use a cache?• What about securing the mapping entries?• What about protecting infrastructure from DOS-

attacks?• What about controlling packet loss and latency?


LISP Control-PlaneLISP Control-Plane

“Push doesn’t scale, caching doesn’t scale, pick one”


LISP-CONSLISP-CONS

• We have chosen a hybrid approach• Push at upper levels of hierarchy• Pull from lower levels of hierarchy• Mappings stay at lower-levels

– Requests get to where the mappings are– Replies are returned

• Getting to the lower-levels via pushing of EID-prefixes

• LISP-CONS is a mapping system for LISP 3.0• LISP-CONS is not a DHT


LISP-CONSLISP-CONS• We can get good EID-prefix aggregation

– If hierarchy based on EID-prefix allocation and not topology

– Then build a logical topology based on the EID-prefix allocation

• Map-Requests routed through logical hierarchy– Key is the EID

• Map-Reply returned to originator– With mapping record {EID-prefix, Locator-set}


LISP-CONS Network ElementsLISP-CONS Network Elements• Content Access Routers (CARs)

– Querying-CARs• Generate Map-Requests on behalf of ITRs

– Replying-CARs• Hold authoritative mappings at level-0 of hierarchy• Aggregate only EID-prefix upwards • Respond with Map-Replies

• Content Distribution Routers (CDRs)– Push around EID-prefixes with level-1 to n of hierarchy– Aggregate EID-prefix upwards– Advertise EID-prefixes in a mesh topology within level– Forward Map-Requests and Map-Replies


LISP-CONSLISP-CONS

ITR ITRETRETR

qCAR qCAR rCARqCAR rCAR qCARLevel-0

CDR Mesh

CDR CDR

CDR CDR

CDR CDR CDR CDRLevel-1

qCAR qCAR

Level-n

CDR MeshCDR Mesh

{ 1.1.1.0/24: L1,L2 }

Legend:

{ } : mapping entry

[ ] : EID aggregate

: mapping table

{ 1.1.2.0/24: L11,L22 }

[ 1.1.0.0/16 ]

[ 1.0.0.0/8 ]

Map-Request1.1.1.1

No EID-Prefix within mesh,forward to parent peer

Map-Request1.1.1.1

No mapping cached,forwardto parent peer

Take shortest path to 1.0.0.0/8

Map-Request1.1.1.1

Has more-specific entry downward

CAR has mapping,returns Map-Replyto orig CAR EID address

{ 1.1.1.0/24: L1,L2 }{ 1.1.2.0/24: L11,L22 }


LISP-CONSLISP-CONS

CDR Mesh

CDR CDR

CDR CDR

Level-n

Level-(n-1)Parent Peer

Child Peer

Sibling Peer

CDR

[ EID-prefix agg ]

[ 0.0.0.0/0 ]

All peering on TCP HMACprotected connections

Within a CDR-mesh, EID-prefixesget seq num pushed with PV lists


LISP-CONSLISP-CONS

CDR Mesh

CDR CDR

CDR CDR

Level-1

Level-0Parent Peer

Child Peer

rCAR

[ EID-prefix agg ]

Sibling PeerAll peering on TCP HMACprotected connections

Within a CDR-mesh, EID-prefixesget seq num pushed with PV lists

ETR


Hybrid ModelsHybrid Models

• Combining brute-force push of NERD to CONS CARs

• Lower latency like with CONS caching since entire database stored in CAR

• ITR still caches and encapsulates directly to ETR


ITR

NERD with CONSNERD with CONS

ITR ITR

qCAR qCAR qCARqCAR qCAR qCARLevel-0qCAR qCAR

NERD NERD NERDAuthoritative and SignedMapping Database

ITR


Hybrid ModelsHybrid Models

• Use CARs as Default Mappers (like APT)

• Use data packet as Map-Request• Never a packet drop at expense of

increased stretch• Mappings between CARs are NERD

pushed


CARs are Default MappersCARs are Default Mappers

ITR ITR ETRETR

qCAR qCAR qCARqCAR qCAR qCARLevel-0qCAR qCAR

NERD NERD NERDAuthoritative and SignedMapping Database

{ 1.1.1.0/24: L1,L2 }

LiSP encapedto qCAR

ITR has mapping: 0.0.0.0/0 -> qCAR

Decaped and Reencaped to ETR

Map-Reply


Is LISP 1.5 Sufficient? Is LISP 1.5 Sufficient?

• Use an alternate topology to run BGP on EID namespace

• Use BGP to either pass mappings around– And use APT type forwarding

• Use BGP to pass only EID-prefixes– Send Map-Requests to find CARs– Use data probe ala LISP 1.5 and have ETRs

return data-triggered Map-Replies


LISP 1.5LISP 1.5

Provider A10.0.0.0/8

Provider B11.0.0.0/8

S

ITR

DITR

ETR

ETR

Provider Y13.0.0.0/8

Provider X12.0.0.0/8

S1

S2

D1

PI EID-prefix 1.0.0.0/8

PI EID-prefix 2.0.0.0/8

1.0.0.1 -> 2.0.0.2

1.0.0.1 -> 2.0.0.2

11.0.0.1 -> 2.0.0.2

Legend: EIDs -> Green Locators -> Red

1.0.0.1 -> 2.0.0.2

12.0.0.2

D213.0.0.2

Alternate TopologyRunning BGP on

EID-prefixes

1.0.0.1 -> 2.0.0.2

11.0.0.1 -> 12.0.0.2

1.0.0.1 -> 2.0.0.2

11.0.0.1 -> 12.0.0.2

13.0.0.2 -> 11.0.0.1

Map-Reply

2.0.0.0/8 12.0.0.2, p: 1, w: 50 13.0.0.2, p: 1, w: 50


DocumentationDocumentation

• Draft draft-farinacci-lisp-02.txt– UDP encapsulation– UDP for Map-Request & Map-Reply– Locator reach bits– Fixes from implementation

experience

• Draft draft-meyer-lisp-cons-01.txt– A control-plane mapping service


Oh, so it's just like a Oh, so it's just like a Blackberry!Blackberry!


Documents

LISP-CONS A Mapping Database Service IETF/IRTF - July 2007