Subject: [Monami6] handover and draft-wakikawa-mobileip-multiplecoa

From: jean-mickael guerin <[email-masked]>
Date: Thu, 12 May 2005 17:43:45 +0200

Hi,

I'm looking how far the use of multiple CoAs can help the handover of 
mobile node, compared to regular Mobile IPv6. In my understanding, for a 
mobile attached to two distinct physical interfaces, registering two 
CoAs should reduce the latency introduced by autoconfiguration and 
Mobile IPv6 - more or less Previous/New CoA of draft Fast handover 
(mipshop). Am I right ?
The issue is on binding cache selection on correspondant node, which is 
left out of scope in the draft. I think with no policy on CN, CN may 
choose a CoA that is bound to a poor link for a long time. So it could 
be worth mentioning a default policy like selecting the last used 
binding entry.

In term of implementation one idea could be to extend the socket API for 
Mobile IPv6, allowing an application to retrieve BID information from 
incoming packet, and to pass it as preference when sending data.

Regards,

Jean-Mickael

_______________________________________________
Monami6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/monami6

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 16 May 2005 02:55:07 +0900

Hello Jean-Mickael

At Thu, 12 May 2005 17:43:45 +0200,
> Mobile IPv6 - more or less Previous/New CoA of draft Fast handover 

Yes. If MN has some movement prediction, multipleCoA registration can
help fast handover. If no prediction, the latency is up to time of
Binding De-registration for inactive CoA. MN can delete
inactive binding by sending de-registration BU from still active CoA.

> be worth mentioning a default policy like selecting the last used 

right.
I thought similar mechanism, but I have reason not to mention in the draft, yet.
1. CN need state of the last used BC. (maybe just one flag in BC though)
2. It will need more state if MN and CN select different binding per application.
3. This can only work when MN and CN communicate in each
   direction. Like one-way UDP streaming, we can not use this
   mechanism.

It might be good to mention CN alwsays using the last-used BC as a
default behavior. what do you think?

> incoming packet, and to pass it as preference when sending data.

Good idea. If application can handle the preference of binding entry,
MIP6 does not bother managing such states. 

regards,
ryuji

---

From: jean-mickael guerin <[email-masked]>
Date: Fri, 20 May 2005 13:20:28 +0200

> inactive binding by sending de-registration BU from still active CoA.

Right.

> 1. CN need state of the last used BC. (maybe just one flag in BC though)

Agree.

> 2. It will need more state if MN and CN select different binding per application.

This could be see as optional.

>    direction. Like one-way UDP streaming, we can not use this
I miss the point here - if CN does not reply, it does not need a default 
policy.

> default behavior. what do you think?

I think that MCoA requires policies to work properly - it is likely that 
if no policy is defined then MCoA could be worst than regular MIPv6.
Using last-used BC seems to not put high requirement on hosts, since the 
binding cache is look-up on reception (checking if Home Address is 
valid), and on transmission. Flag or timestamp seems to be enough.

A field in BU may be useful too for correspondent. For instance, this 
way MN could advertise HA or CN to duplicate (bi-cast) the traffic over 
all the bindings. Or use the latest BC.

> MIP6 does not bother managing such states. 

Yes, the aim of this mechanism is to allow an application to overwrite 
the default policy, assuming the application has a knownledge of quality 
/availability of the links.

Regards,

Jean-Mickael