1 / 8

LIP6 – University Pierre and Marie Curie ALTERNATIVE MOBILE NODE MANAGEMENT IN LISP

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. Overview of current LISP mobile-node. S.

dotty
Télécharger la présentation

LIP6 – University Pierre and Marie Curie ALTERNATIVE MOBILE NODE MANAGEMENT IN LISP

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. LIP6 – University Pierre and Marie CurieALTERNATIVE MOBILE NODE MANAGEMENT IN LISP Dung Phung, Patrick Raad, Stefano Secci LIP6 - UPMC Bureau 25-26/3184 place Jussieu, 75005 Parisstefano.secci@lip6.fr http://www-phare.lip6.fr/~secci

  2. Overview of current LISP mobile-node S 10.0.0.1 -> 153.16.1.1 S1 S2 1.0.0.1 -> 4.4.4.4 10.0.0.1 -> 153.16.1.1 3.3.3.3 EID: 153.16.1.1 xTR Provider A 1.0.0.0/8 3G Provider 3.0.0.0/8 MS 1.0.0.1 4.4.4.4 LISP EID-prefix 10.0.0.0/8 xTR 2.0.0.1 4G Provider 4.0.0.0/8 Provider B 2.0.0.0/8 4.4.4.4 WiFi Provider 5.0.0.0/8 EID: 153.16.1.1 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 5.5.5.5 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 2.0.0.1 -> 5.5.5.5 10.0.0.1 -> 153.16.1.1 Legend: EIDs -> Green, Locators -> Red 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

  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

  5. An alternative way to handle MNs in LISP S 2.0.0.1 -> 3.3.3.3 10.0.0.1 -> 153.16.1.1 1.0.0.1 -> 4.4.4.4 10.0.0.1 -> 153.16.1.1 D2 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 D1 S1 S2 10.0.0.1 -> 153.16.1.1 Legend: EIDs -> Green, Locators -> Red 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 App App App OS OS OS EID: 153.16.1.1 xTR App Hypervisor Hypervisor OS xTR Hardware Provider A 1.0.0.0/8 3G Provider 3.0.0.0/8 Hardware 4.4.4.4 MS 1.0.0.1 xTR LISP EID-prefix 10.0.0.0/8 2.0.0.1 4G Provider 4.0.0.0/8 Provider B 2.0.0.0/8 WiFi Provider 5.0.0.0/8 xTR 3.3.3.3 Change priority Message

  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)??

  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) 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? ?

More Related