1 / 26

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

LISP-CONS A Mapping Database Service IETF/IRTF - July 2007. Dave Meyer Dino Farinacci Vince Fuller Darrel Lewis Scott Brim Noel Chiappa. Agenda. Brief Intro Design Considerations Brief Definitions How CONS Works Hybrid Approaches Combining NERD and CONS Combining APT and CONS

baird
Download Presentation

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

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. LISP-CONSA Mapping Database ServiceIETF/IRTF - July 2007 Dave Meyer Dino Farinacci Vince Fuller Darrel Lewis Scott Brim Noel Chiappa

  2. Agenda • Brief Intro • Design Considerations • Brief Definitions • How CONS Works • Hybrid Approaches • Combining NERD and CONS • Combining APT and CONS • Is LISP 1.5 sufficient? IETF/IRTF

  3. Problem 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 IETF/IRTF

  4. Locator ID IPv4: 209.131.36.158 .10.0.0.1 Locator ID Splitting an Address IPv6: 2001:0102:0304:0506:1111:2222:3333:4444 IETF/IRTF

  5. Host Stack Uses IDs Uses Locators Map-n-Encap LISP is a Jack-Up IETF/IRTF

  6. LISP 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 IETF/IRTF

  7. Data-Plane Mapping Control-Plane Mapping LISP 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) IETF/IRTF

  8. Quick 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 IETF/IRTF

  9. LISP 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 IETF/IRTF

  10. LISP 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? IETF/IRTF

  11. LISP Control-Plane “Push doesn’t scale, caching doesn’t scale, pick one” IETF/IRTF

  12. LISP-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 IETF/IRTF

  13. LISP-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} IETF/IRTF

  14. LISP-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 IETF/IRTF

  15. Take shortest path to 1.0.0.0/8 Map-Request 1.1.1.1 No EID-Prefix within mesh, forward to parent peer Has more- specific entry downward Map-Request 1.1.1.1 No mapping cached,forward to parent peer [ 1.0.0.0/8] [ 1.1.0.0/16] qCAR ETR ETR CDR ITR CDR rCAR ITR qCAR qCAR qCAR CDR CDR rCAR CDR CDR CDR CDR qCAR qCAR {1.1.1.0/24: L1,L2} {1.1.2.0/24: L11,L22} Map-Request 1.1.1.1 CAR has mapping, returns Map-Reply to orig CAR EID address {1.1.1.0/24: L1,L2} {1.1.2.0/24: L11,L22} LISP-CONS Legend: { } : mapping entry [ ] : EID aggregate : mapping table Level-n CDR Mesh CDR Mesh CDR Mesh Level-1 Level-0 IETF/IRTF

  16. All peering on TCP HMAC protected connections Sibling Peer [ EID-prefix agg] Within a CDR-mesh, EID-prefixes get seq num pushed with PV lists Parent Peer [ 0.0.0.0/0] CDR CDR CDR CDR CDR Child Peer LISP-CONS CDR Mesh Level-n Level-(n-1) IETF/IRTF

  17. All peering on TCP HMAC protected connections Sibling Peer [ EID-prefix agg] Within a CDR-mesh, EID-prefixes get seq num pushed with PV lists Parent Peer rCAR CDR CDR CDR ETR CDR Child Peer LISP-CONS CDR Mesh Level-1 Level-0 IETF/IRTF

  18. Hybrid 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 IETF/IRTF

  19. qCAR qCAR ITR ITR ITR qCAR ITR qCAR qCAR qCAR qCAR NERD NERD NERD qCAR NERD with CONS Authoritative and Signed Mapping Database Level-0 IETF/IRTF

  20. Hybrid 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 IETF/IRTF

  21. Decaped and Reencaped to ETR Map-Reply qCAR ITR ITR ETR ETR qCAR qCAR qCAR qCAR qCAR qCAR NERD NERD NERD qCAR LiSP encaped to qCAR CARs are Default Mappers Authoritative and Signed Mapping Database Level-0 {1.1.1.0/24: L1,L2} ITR has mapping: 0.0.0.0/0 -> qCAR IETF/IRTF

  22. 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 IETF/IRTF

  23. S D 11.0.0.1 -> 12.0.0.2 Map-Reply 11.0.0.1 -> 2.0.0.2 1.0.0.1 -> 2.0.0.2 1.0.0.1 -> 2.0.0.2 1.0.0.1 -> 2.0.0.2 1.0.0.1 -> 2.0.0.2 1.0.0.1 -> 2.0.0.2 13.0.0.2 -> 11.0.0.1 Alternate Topology Running BGP on EID-prefixes 2.0.0.0/8 12.0.0.2, p: 1, w: 50 13.0.0.2, p: 1, w: 50 D1 D2 S1 S2 11.0.0.1 -> 12.0.0.2 LISP 1.5 PI EID-prefix 2.0.0.0/8 PI EID-prefix 1.0.0.0/8 Provider A 10.0.0.0/8 Provider X 12.0.0.0/8 ETR ITR 12.0.0.2 ITR ETR Provider B 11.0.0.0/8 Provider Y 13.0.0.0/8 13.0.0.2 Legend: EIDs -> Green Locators -> Red IETF/IRTF

  24. Documentation • 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 IETF/IRTF

  25. Oh, so it's just like a Blackberry! IETF/IRTF

  26. IETF/IRTF

More Related