1. LIP6 – University Pierre and Marie Curie ALTERNATIVE MOBILE NODE MANAGEMENT IN LISP Dung Phung, Patrick Raad, Stefano Secci LIP6 - UPMC Bureau 25-26/318 4 place Jussieu, 75005 Paris stefano.secci@lip6.fr http://www-phare.lip6.fr/~secci

2. EID: 153.16.1.1 4.4.4.4 5.5.5.5 Map 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 Provider A 1.0.0.0/8 Provider B 2.0.0.0/8 S xTR 4G Provider 4.0.0.0/8 S1 S2 LISP EID-prefix 10.0.0.0/8 1.0.0.1 2.0.0.1 WiFi Provider 5.0.0.0/8 Mapentry: 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 EID: 153.16.1.1 3.3.3.3 4.4.4.4 1.0.0.1 -> 4.4.4.4 10.0.0.1 -> 153.16.1.1 1.0.0.1 -> 4.4.4.4 10.0.0.1 -> 153.16.1.1 3G Provider 3.0.0.0/8 MS 2.0.0.1 -> 5.5.5.5 10.0.0.1 -> 153.16.1.1 2.0.0.1 -> 5.5.5.5 10.0.0.1 -> 153.16.1.1 Legend: EIDs -> Green, Locators -> Red 10.0.0.1 -> 153.16.1.1 Overview of current LISP mobile-node Inspired by http://tools.ietf.org/agenda/76/slides/lisp-5.ppt

3. Pro and cons – LISP-MN Advantages:  The LISP-MN is itself an xTR independently of the provider network(s);  No change to the LISP control-plane. Disadvantages:  Must install xTR functions into MN’s OS;  LISP-MN has to handle encap/decap for most traffic  Energy and CPU consumption might be critical;  MS/MR may overload in presence of too many MNs 3

4. An alternative way to handle MNs in LISP? What if:  not deploying xTR functions at LISP-MN;  We know that LISP-MN moves across a limited number of RLOCs  E.g., wireless Gateway Points (GPs) or DCs border routers  RLOCs may already appear in the map-cache  with different priorities, even if not used at a given time.  How it might work:  MN attachment points (Access Points, hypervisor) detect a MN move and notify it to a pre-set/discovered authoritative xTR  e.g., GPs or DCs routers  xTR increases the mapping priority of the current RLOC  Many authoritative xTRs/RLOCs?  Why not 4

5. 3.3.3.3 D2 Map entry: EID-prefix: 153.16.1.1/32 RLOC-set: 4.4.4.4, priority: 1, weight: 50 3.3.3.3, priority: 2, weight: 50 Provider A 1.0.0.0/8 Provider B 2.0.0.0/8 S xTR 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 4.4.4.4 WiFi Provider 5.0.0.0/8 Mapentry: EID-prefix: 153.16.1.1/32 RLOC-set: 4.4.4.4, priority: 2, weight: 50 3.3.3.3, priority: 1, weight: 50 1.0.0.1 -> 4.4.4.4 10.0.0.1 -> 153.16.1.1 3G Provider 3.0.0.0/8 2.0.0.1 -> 3.3.3.3 10.0.0.1 -> 153.16.1.1 MS An alternative way to handle MNs in LISP D1 EID: 153.16.1.1 Change priority Message Hardware Hypervisor App OS xTR Hardware Hypervisor App OS App OS App OS xTR

6. Skeptic? Advantages:  Scalability  MN transparency: no control-plane messages reaching/sent by the MN;  xTR functions and signaling concentrated in a few devices ;  APs/hypervisor take out signaling load from the MN.  Suitable for DC, corporate and provider networks where VMs/MNs’ RLOCs are known Disadvantages:  Node IP mobility continuity restricted to pre-known sites;  Additional functionalities to implement:  Identification of incoming mobile node at AP/Hypervisor;  Need for AP/hypervisor  xTR node mobility notification.  Do you see something else (yes, apart security)?? 6

7. A possible node mobility notification message A draft of message that AP/Hyp uses to notify xTR about an incoming MN (possibly followed by a map-notify message xTR  AP/Hyp) 7 To enable map-notify from xTR to AP/hypervisor Useful aggregation? (dozens of EID-non- aggretable IaaS-VMs moved together) Of course – different key (and authentication method): managed locally

8. Opinions? ? 8