Subject: [mobile-ip] Summary of issues: Support for Three Party handover

From: Rajeev Koodli <[email-masked]>
Date: Tue, 24 Sep 2002 13:59:11 -0700

The main issue is if the MN
leaves AR2 for AR3 before it updates the
correspondents while on AR2's link, packets don't
arrive to NCoA-2 and hence, once the tunnel
between AR1 and AR2 expires, the MN might
loose its packets (sent to NCoA-1) until it
updates its correspondents with NCoA-3!

This could be addressed by specifying that the
MN SHOULD treat AR1 as its previous router
if it is unable to update its binding while on AR2.
This means, even if a single binding could not
be updated, the MN MAY need to set up a tunnel
between AR1 and AR3. This tunnel set up is upto
the MN, since it may have intentionally not updated
its binding with one or more correspondents.

While the resolution on this issue is less clear,
I would like to start with a simpler protocol and
"naturally extend"it for the three party case, and
identify its deficiencies. Once we get more clarity
on the on-going discussion about how long a
tunnel for the previous CoA should be kept open
and the need for maintaining the performance
across a series of routers at the cost of additional
protocol (as opposed to falling back to base MIPv6)
becomes clearer, we could have an optional section
on three part handover (as was suggested).

-Rajeev

Subject: [mobile-ip] fastv6: Issue 3: Support for Three Party handover
From: Rajeev Koodli <[email-masked]>
To: [email-masked]
Date: Mon, 16 Sep 2002 19:08:45 -0700

Issue: Should "Three Party Handover" (Section 3.1.7 and
Section 3.4 in version 04) be specified as a natural
continuation of the base (i.e., Two Party) handover ?

Background: Both Section 3.1.7 and 3.4 describe
Three Party handover. Section 3.4 is especially
exhaustive. This is done with the objective of
avoiding potential routing loops (especially a
concern when the same IP address is used across
a series of routers) and chaining of tunnels.

Proposal: To allow the base protocol to operate
without specifically describing additional protocol
structure. In particular, if the MN returns back to
its previous AR without completing Mobile IPv6
Binding Update procedure, it must send a FBU
with lifetime of zero (Section 6.1.2 in v04), which
allows the PAR to disable any outgoing tunnels.
This, coupled with a short lifetime for the tunnels
and by making the MN configure a new CoA each
time it visits a new AR, should alleviate the need
for a special Three Party Handover protocol.

Please specify

- YES if you agree to describe Three Party
    Handover as a natural continuation of
    the base protocol with necessary requirements
- NO otherwise. Indicate a brief reason.

Thanks,

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Tue, 24 Sep 2002 21:16:38 -0700

Rajeev,

I agree with putting 3 party handover into a section of the draft. I agree with
making support of 3 party handover optional.

            jak