1 / 7

Problem Statement for Common Interface Support in Localized Mobility Management

Problem Statement for Common Interface Support in Localized Mobility Management. draft-corujo-ps-common-interfaces-lmm-00. Problem Space.

javen
Download Presentation

Problem Statement for Common Interface Support in Localized Mobility Management

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. Problem Statement for Common Interface Support in Localized Mobility Management draft-corujo-ps-common-interfaces-lmm-00

  2. Problem Space ..the document aims at identifying a common problem space for the design of a MN-AR multi-purpose interface covering fast link change detection, proactive and reactive handovers in LMD environments (such as Proxy MIPv6 solutions). …starting from existing solutions for fast link detection the document aims at discussing possibilities for a layer 2.5 interface between MN and AR

  3. Several solutions make use of link events: • DNA/FRD and its 802.21 Integration • Proxy Mobile IPv6 and reactive HO • Fast Handovers for Proxy Mobile IPv6 • However so far not much is available for MN/AR interface • MN-AR interface based on ND

  4. Where the common interface applies: • Bootstrapping (e.g. power on of a MN) • Proactive handover • Reactive handover

  5. Providing interfaces with 802.21 An example ACCESS ROUTER .................. | ........ | | | LMP | | | |ENGINE| | | `'''''' | | / \ | | MIH / \ | |EVENT | | | LINK EVENT | | | | ____________ +----------+ | FROM MN \| MIH | | OR PoA ____________/| FUNCTION | | | +----------+ | .................. LMP Engine as an MIH user? PoAs co-located with AR? 

  6. Requirements • This framework should accommodate with future instances of the NetLMM protocol, and be flexible enough to allow and support possible optimizations of the NetLMM procedures. • This framework does not aim at replacing L3 procedures rather to improve them by facilitating the information exchange between the host and the AR even prior to full network configuration. • While several deployment scenarios of the MIHF and its relation to the upper layers are possible (IP stack, LMP engine), a more clear communication model needs to be agreed and specified. • Need to align different identifiers. • Link layer events have to be carefully registered by whoever can use them to trigger procedures. A single event can be forwarded to more than one high level entity, inducing parallel behavior that might not be desirable. • The host must be able to store the previous network configuration information, both for detecting subnet changes upon attachment, and also to report it to the nAR upon a reactive handover. • Sufficient authentication of devices supplying link-layer events has to be considered. For example, reachability and attachment notifications may be falsely asserted by an attacker

  7. Views…ideas…comments?

More Related