[Mipshop] Weighing the Importance of Proactivity

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

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

_______________________________________________
Mipshop mailing list
Mipshop@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop