1 / 11

LISP Mobile Node draft-meyer-lisp-mn-00.txt

LISP Mobile Node draft-meyer-lisp-mn-00.txt. Dino Farinacci, Vince Fuller, Darrel Lewis and David Meyer IETF StockholmHiroshima LISP Working Group July/Hov 2009. Agenda. User and Network Goals for LISP MN Overview of the Solution Control and Data Plane operation while Roaming Summary

nadda
Download Presentation

LISP Mobile Node draft-meyer-lisp-mn-00.txt

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 Mobile Nodedraft-meyer-lisp-mn-00.txt Dino Farinacci, Vince Fuller, Darrel Lewis and David Meyer IETF StockholmHiroshima LISP Working Group July/Hov 2009

  2. Agenda • User and Network Goals for LISP MN • Overview of the Solution • Control and Data Plane operation while Roaming • Summary • Draft Disposition • Q&A IETF 75 July 2009

  3. User Goals • Allow a MN to roam while keeping TCP connections alive • Allow a MN to talk to MN while roaming when either can be a client or server • or p2p or … • Allow multi-homing on MN • MN can set ingress policies for reception of traffic • e.g., active-active with simultaneous v4 and v6 ingress flows • Shortest path bidirectional traffic between MN and SN as well as between MN and MN • No triangle routing in data path IETF 75 July 2009

  4. Network Goals • No MN EID state in core • MN-based state only in Map-Server and ITRs (and PTRs) which are talking to MN •  No /32 (/128) state in either the ALT or the DFZ control-planes • Use existing LISP mapping system components as anchor points for LISP mobile nodes • In particular, the Map Server/Resolver infrastructure • Note that these components are not part of the data-plane IETF 75 July 2009

  5. Solution Overview • MN is a lightweight ITR and ETR for itself • MN sends Map-Requests • A MN may send Map-Replies • A MN can ask its Map-Server to “proxy Map-Reply” by setting the proxy-map-reply bit in its Map-Register messages • All packets originated by MN are LISP encapsulated • Packets destined for non-LISP destinations are decapsulated by a Proxy ETR (PETR) IETF 75 July 2009

  6. Solution Overview, cont. • A MN ALWAYS Map-Registers with its provisioned Map-Server • That Map-Server is configured to advertise an aggregate covering the MN’s EID into the ALT • This allows the ALT to scale in the presence of mobile nodes since mobile node specific state is not propagated into the ALT • For existing cachers (ITRs or PTRs) • Cachers respect MN’s (possibly lower) TTL • MN can SMR • MN can send Map-Request (with verifying Map-Request) IETF 75 July 2009

  7. LISP-ALT LISP-ALT LISP-ALT LISP-ALT Map-Server Map-Resolver Map-Resolver Map-Resolver EID: 153.16.1.1 3.3.3.3 -> 65.1.1.1 LISP AH Map-Register 153.16.1.1 -> (3.3.3.3, 4.4.4.4) Roaming - Control Plane MN1 MN2 EID: 153.16.2.1 EID: 153.16.3.1 153.16.1.0./24 65.1.1.1 MN3 Legend: EIDs -> Green, RLOCs -> Red 3G network -> 3.0.0.0/8 4G network -> 4.0.0.0/8 BGP-over-GRE Map-Register BGP update (1) No matter where MN3 roams, MN1 and MN2 can find it’s locator by using the database mapping system. (2) Only the Map-Server will store 153.16.1.1/32 state with the latest set of RLOCs. (3) Data always travels on shortest path to and from MN. IETF 75 July 2009

  8. 1.0.0.1 -> 5.5.5.5 1.0.0.1 -> 4.4.4.4 S MN roams, stays multi-homed and TCP connection does not reset 4.4.4.4 Map-Cache entry: EID-prefix: 153.16.1.1/32 RLOC-set: 4.4.4.4, priority: 1, weight: 50 3.3.3.3, priority: 1, weight: 50 10.0.0.1 -> 153.16.1.1 10.0.0.1 -> 153.16.1.1 10.0.0.1 -> 153.16.1.1 5.5.5.5 Map-Cache entry: EID-prefix: 153.16.1.1/32 RLOC-set: 4.4.4.4, priority: 2, weight: 100 5.5.5.5, priority: 1, weight: 100 S1 S2 EID: 153.16.1.1 Roaming - Data Plane ITR Provider A 1.0.0.0/8 3G Provider 3.0.0.0/8 3.3.3.3 1.0.0.1 ITR LISP EID-prefix 10.0.0.0/8 EID: 153.16.1.1 2.0.0.1 4G Provider 4.0.0.0/8 Provider B 2.0.0.0/8 4.4.4.4 DNS entry: mn.abc.com A153.16.1.1 WiFi Provider 5.0.0.0/8 Legend: EIDs -> Green, Locators -> Red IETF 75 July 2009

  9. Summary • Using the Map-Server/Map-Resolver service interface • We get scalable roaming with same LISP infrastructure used for multi-homing and route scaling • LISP sites talk to each other and MNs talk to each other over same infrastructure • Anchor point architecture allows mobile nodes to be discovered in the control-plane • Data-plane has no stretch and therefore no packet delivery latency • Addressing scales routing because it maps to the physical topology IETF 75 July 2009

  10. Working Group Document? • Routing must scale to support the mobile node Internet • LISP map-server and ALT infrastructure are mechanisms to do this for stationary sites which change addresses • Same infrastructure used when mobile nodes change addresses • Therefore LISP MN is within the charter of LISP WG IETF 75 July 2009

  11. Q&A Thanks! IETF 75 July 2009

More Related