1 / 5

Network-based, Localized Mobility Management – the Problem

Network-based, Localized Mobility Management – the Problem. James Kempf DoCoMo Labs USA kempf@docomolabs-usa.com. Why Not Use Global Mobility Management on Every Subnet Move?.

lenaa
Download Presentation

Network-based, Localized Mobility Management – the Problem

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. Network-based, Localized Mobility Management – the Problem James Kempf DoCoMo Labs USA kempf@docomolabs-usa.com

  2. Why Not Use Global Mobility Management on Every Subnet Move? • If correspondent and/or global routing anchor is topologically far away, high update latency results in dropped packets • Amount of signaling to come up on a new subnet, including subnet configuration and global mobility management, is prohibitive • Changes in the care-of address on host can reveal a mobile node’s topological and geographical location to an undesirable granularity

  3. What’s Changed? • IETF has been working on this problem for about 5 years • MIP related protocols – HMIP, FMIP, LLMIPv4 • Experimental, FMIP about to go PS track • Micromobility routing protocols – no real progress • Last year has seen three important new trends • In IETF, new, non-MIP related global mobility management protocols have arisen • HIP, Mobike* • Proprietary, L2 specific “IP mobility” (marketing speak for localized mobility management) in WLAN switches • Host’s IP address doesn’t change as it moves between switches • New cellular type protocols under development • 802.16/WiMax • Super/3.9G *Note: Mobike is not really a global mobility management protocol even though it behaves like one

  4. Problems with Experimental IETF Protocols • Changes required in host stack for localized mobility management required • Localized mobility management can’t be used by any host • Designed to support Mobile IPv6 • Other global mobility management protocols are not supported • Security issues • Because localized mobility management is a service provided to a host, auth/authz required between host and localized mobility server • Security association required between every roaming partner’s network and every roamed MN • Virus/mal-ware on host can expose host’s local care-of address or address of localized mobility server in network • Opens MN’s location privacy and server’s security to Internet-wide attack

  5. New Solution Sought • Localized mobility management is provided by the network as a routing-style service • Auth/Authz for network access is sufficient to authorize MN for localized mobility management • I.e. localized mobility management is provided as part of the basic IP routing service with no additional host authorization required • Also no additional host to network security required beyond what is needed for Layer 2 & IP level movement detection • Minimize special IP level software for localized mobility management required on the host • Drivers or IP movement detection OK • Host’s IP addresses do not change as it moves across the localized mobility management domain • Works across wide area on any combination of link/wireless technologies • Including WiMax

More Related