Re: [Mipshop] Weighing the Importance of Proactivity

[Jari Arkko <[e-mail]>]

I believe the main difference between the current design
and the one that you outlined is whether the care-of test
runs within the same message or in a separate message.
A separate message, however, does not necessarily mean
additional delay, given that the early BU and the test can
run in parallel.

So one possible design is that the messages are simply
separate; if you are in proactive mode then you delay
the test init until you have actually moved but otherwise
you send it immediately. This adds some some header
overhead, but not a significant amount of delay.

--Jari

Christian Vogt wrote:

> Hi everybody,
>
> Gabriel asked me to provide some details about the implications of 
> proactive CoA registrations (i.e., registrations initiated before L2 
> handoff) on RO enhancements such as draft-arkko-mipshop-cga-cba-02.txt 
> [1].
>
> The bottom-line is that the Care-of Test Init and Care-of Keygen Token 
> options used in [1] are incompatible with proactive registrations when 
> MNs are single-interfaced.  (Things are easier with multiple interfaces.)
>
> This email seeks to solicit comments about the importance of proactive 
> registrations when the MN has a single interface only.
>
> Specifically...
>
> [1] replaces the CoTI and CoT messages, which are used in RFC 3775 
> during a care-of-address test, with Care-of Test Init and Care-of 
> Keygen Token options for the BU and BAck messages.
>
> Our objective for introducing these options was to reduce the number 
> of messages required for a correspondent registration.
>
> This is fine when MNs register their CoAs in a reactive way (i.e., 
> after L2 handoff), or when MNs have multiple interfaces.
>
> OTOH, separate messages are required when *single*-interfaced MNs want 
> to register their CoAs in a *proactive* way (i.e., before L2 handoff). 
> In such a case, the handoff procedure might look as follows:
>
> - MN finds a better access point.
> - MN obtains prefix information for the link to which that access 
> point  belongs (by some external means).
> - MN sends an (early) BU + AltCoA option from the old link.
> - MN continues to receive and send packets at the old link.
> - Arrival of the (early) BAck will cause the mobile node to initiate 
> the L2 handoff procedure.
> - MN performs a concurrent care-of-address test from the new link.
> - MN sends a (full) BU from the new link.
>
> The CN directs packets to the new CoA as of receiving the (early) BU. 
> The (early) BAck is the last packet it sends to the old link.
>
> The CN uses Credit-Based Authorization to make use of the AltCoA 
> option and the concurrent CoA test secure.
>
> Note:  MNs with multiple interfaces can send the (early) BU and 
> receive the (early) BAck on the new link.
>
> The above procedure was already proposed in [2].  But in principle it 
> applies to [1] just as well.  I'm currently updating [2] with some 
> more details.
>
> We think this issue is worth discussion, so Jari will attend to it 
> during his presentation in the Mipshop session.
>
> BTW, the simple solution to this issue would be to go back to the 
> original CoTI and CoT messages.
>
> Regards,
> - Christian
>
>
> [1]  
> http://www.ietf.org/internet-drafts/draft-arkko-mipshop-cga-cba-02.txt
> [2] 
> http://doc.tm.uka.de/2005/draft-vogt-mobopts-early-binding-updates-00.txt
>


_______________________________________________
Mipshop mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mipshop