1 / 8

Fast Mobile IPv6 Handovers: Update

Fast Mobile IPv6 Handovers: Update. Rajeev Koodli. Proposed Changes. Deprecate Three-party handover (Section 4.6) Finish two-party first Fall back base Mobile IPv6 in case of errors Take up later in a separate draft if there is need from ML L2 optimized handover (Section 4.5)

maren
Download Presentation

Fast Mobile IPv6 Handovers: Update

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. Fast Mobile IPv6 Handovers: Update Rajeev Koodli

  2. Proposed Changes • Deprecate Three-party handover (Section 4.6) • Finish two-party first • Fall back base Mobile IPv6 in case of errors • Take up later in a separate draft if there is need • from ML • L2 optimized handover (Section 4.5) • proposes further optimizations to FMIPv6: setting up tunnel without using IP messages • Potentially useful, perhaps a separate document if there is interest • Deprecate for now; however, better describe how L2 triggers cause handover invocation • from ML

  3. FBU transmission from new link • Scenarios • MN has not sent FBU • MN has not received FBack for an FBU (sent on previous link) • FBU is processed, but MN has moved • FBU is lost • For both, MN does not know whether PAR has processed FBU • For both 1) and 2) FBack_Count = 0 • PrRtSol and PrRtAdv have taken place • Send FBU together with FNA as soon as new link is established • FNA • Requests NAR to create a Reachable forwarding entry: corresponds to scenario 1) and 2.b) • Moves the existing entry to reachable state: corresponds to 2.a)

  4. FBU transmission from new link.. • FBU • Requests PAR to tunnel packets to NCoA • Sent with src addr = NCoA • Why encapsulate FBU within FNA ? • Single packet (channel access considerations) • NAR could verify if NCoA is conflict-free while creating a new forwarding entry, and drop FBU in case of conflict • “stateless” operation: avoids misdirecting traffic based on outer message (FNA) processing • FNA format to be changed to Destination Option to facilitate encapsulation

  5. Why is FNA necessary ? • When a router has no ND cache entry for an address, an unsolicited NA will not create one (scenarios 1, 2.b) • Unsolicited NA is wasteful • When packets arrive, a round-trip of NS-NA • When a router does have entry in Incomplete state, unsolicited NA moves it to Stale which invokes a round-trip of NUD although packet forwarding can take place in parallel • Encapsulating FBU within FNA avoids traffic misdirection if NAR detects address conflict

  6. HI and HAck • Exchanged when FBU is processed by PAR • Allow NAR to • Buffer incoming packets • Not invoke ND until the MN attaches • Proxy NCoA • Why Necessary ? • Without HI, an incoming packet invokes ND • MN present when router sends NS, well done • MN not present: what to do with arriving packets ? Where to buffer them ? • ND queue: cannot distinguish between handover streams and non-handover streams • Separate FMIPv6 buffer: needs signaling

  7. HI and HAck • Using HI, NAR has some “validation” of the forwarding entry for NCoA from a trusted peer (PAR)

  8. Remaining.. • Text specifying security for FBU • Support for PCoA if there is conflict with NCoA • Fall back to basic address configuration ? • ..

More Related