Re: [Mipshop] Weighing the Importance of Proactivity

Hi Jari.

 > 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.

Not that there would be any additional delay.  But the signaling 
overhead slightly increases when we use separate messages.

 > 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.

Exactly, my suggestion was to simply use the (separate) CoTI/CoT 
messages specified by RFC 3775.

- Christian

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/

Jari Arkko wrote:
> 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
Mipshop@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop