draftmeyerlispmn00txt Dino Farinacci Vince Fuller Darrel Lewis and David Meyer IETF StockholmHiroshima LISP Working Group JulyHov 2009 LISP Mobile Node IETF 75 July 2009 Slide 2 Agenda ID: 391942
Download Presentation The PPT/PDF document "LISP Mobile Node" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
LISP Mobile Nodedraft-meyer-lisp-mn-00.txt
Dino Farinacci, Vince Fuller, Darrel Lewis and David Meyer
IETF StockholmHiroshima
LISP Working Group
July/Hov 2009Slide2
LISP Mobile NodeIETF 75 July 2009Slide 2
Agenda
User and Network Goals for LISP MN
Overview of the Solution
Control and Data Plane operation while Roaming
Summary
Draft Disposition
Q&ASlide3
LISP Mobile NodeIETF 75 July 2009Slide 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 pathSlide4
LISP Mobile NodeIETF 75 July 2009Slide 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
N
o /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-planeSlide5
LISP Mobile NodeIETF 75 July 2009Slide 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)Slide6
LISP Mobile NodeIETF 75 July 2009Slide 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)Slide7
LISP Mobile NodeIETF 75 July 2009Slide 7
Roaming - Control Plane
Map-Resolver
LISP-ALT
LISP-ALT
LISP-ALT
LISP-ALT
Map-Server
Map-Resolver
Map-Resolver
EID: 153.16.2.1
EID: 153.16.3.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
)
153.16.1.0./24
EID: 153.16.1.1
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
65.1.1.1
(1) No matter where MN3 roams,
MN1 and MN2 can find it’s locator by
using the database mapping system.
MN1
MN2
(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.
MN3Slide8
LISP Mobile NodeIETF 75 July 2009Slide 8
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
DNS entry:
mn.abc.com A
153.16.1.1
Roaming - Data Plane
Provider A
1.0.0.0/8
Provider B
2.0.0.0/8
S
ITR
ITR
4G Provider
4.0.0.0/8
S1
S2
LISP
EID-prefix
10.0.0.0/8
Legend:
EIDs -> Green
,
Locators -> Red
1.0.0.1
2.0.0.1
EID: 153.16.1.1
3.3.3.3
4.4.4.4
WiFi Provider
5.0.0.0/8
EID: 153.16.1.1
4.4.4.4
5.5.5.5MN roams, stays multi-homed and TCPconnection does not resetMap-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
10.0.0.1 -> 153.16.1.1
1.0.0.1 -> 4.4.4.4
10.0.0.1 -> 153.16.1.13G Provider3.0.0.0/810.0.0.1 -> 153.16.1.1
1.0.0.1 -> 5.5.5.5Slide9
LISP Mobile NodeIETF 75 July 2009Slide 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 topologySlide10
Working Group Document?Routing must scale to support the mobile node InternetLISP map-server and ALT infrastructure are mechanisms to do this for stationary sites which change addressesSame infrastructure used when mobile nodes change addresses
Therefore LISP MN is within the charter of LISP WG
LISP Mobile Node
IETF 75 July 2009
Slide
10Slide11
LISP Mobile NodeIETF 75 July 2009Slide 11
Q&A
Thanks!