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, Paris

EID: Map entry: EID-prefix: /32 RLOC-set: , priority: 1, weight: , priority: 1, weight: 50 Provider A /8 Provider B /8 S xTR 4G Provider /8 S1 S2 LISP EID-prefix / WiFi Provider /8 Mapentry: EID-prefix: /32 RLOC-set: , priority: 2, weight: , priority: 1, weight: 100 EID: > > > > G Provider /8 MS > > > > Legend: EIDs -> Green, Locators -> Red > Overview of current LISP mobile-node Inspired by

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

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

D2 Map entry: EID-prefix: /32 RLOC-set: , priority: 1, weight: , priority: 2, weight: 50 Provider A /8 Provider B /8 S xTR 4G Provider /8 S1 S2 LISP EID-prefix /8 Legend: EIDs -> Green, Locators -> Red WiFi Provider /8 Mapentry: EID-prefix: /32 RLOC-set: , priority: 2, weight: , priority: 1, weight: > > G Provider / > > MS An alternative way to handle MNs in LISP D1 EID: Change priority Message Hardware Hypervisor App OS xTR Hardware Hypervisor App OS App OS App OS xTR

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

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

Opinions? ? 8