Subject: [Monami6] Problem with MCoA draft?!

From: Heikki Mahkonen <[email-masked]>
Date: Thu, 23 Mar 2006 16:09:44 +0200

Hi Ryuji,

     I don't know if you think that my mail about adding the binding 
lifetime into the BID option was fubar but I think some kind of 
"smarter" mechanism is needed, than the one specified in the current 
MCoA draft, to remove and add bindings between HoA and multiple CoAs.

     Imagine the following scenario. HA (or CN) has the following 
information in it's Binding Cache:

BID1, HoA, CoA1
BID2, HoA, CoA2
BID3, HoA, CoA3

If the MN which has registered these bindings makes a handover and it 
wants to replace the CoA1 and CoA2 with a CoA4 and the CoA3 remains 
valid. Does the MN send two BU messages to de-register the CoA1 and CoA2 
and one BU message to register the CoA4? How about if the MN had three 
or more CoAs which needs to be removed and three or more CoAs which 
needs to be added? This problem escalates, right (6 or more BU 
messages)? To me this seems little bit unwise. What do you think?

One option could be for the MN to always add all the valid CoAs into the 
BU message with lifetime 0 and when CN or HA receives this BU message it 
would replace the bindings for that HoA. But if the CNs and HAs function 
this way how would it then be possible to register multiple CoAs in 
separate BU messages because the CoA sent in the first BU message would 
always be replaced with the CoA in the second BU message (lifetime not 
0). So if you only use the mechanism specified in the draft you have to 
choose to send each CoA in one BU message or you have to send all CoAs 
in each BU message, right?

Now, if you add the binding lifetime into the BID option you can 
de-register old CoAs and register new ones with only one BU message!!! 
Well MTU would be the limit. That is, you always have to take care to 
de-register invalid CoAs by sending a BID option with lifetime zero for 
the de-registration and this is the only way you can remove invalid 
CoAs. IMHO, this sounds better. However, this could be misunderstanding 
on my part and/or you could have better solution to this problem?

Do you or anybody have any thoughts about this?

Best regards,

Heikki Mahkonen

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

---

From: Martti Kuparinen <[email-masked]>
Date: Fri, 24 Mar 2006 13:11:47 +0200

> de-register old CoAs and register new ones with only one BU message!!!

In other words, something like this:

Home Binding Unique Identifier sub-option (HBID)
------------------------------------------------

                             1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                        |   Type = TBD  |     Length    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Binding Unique ID (BID)   |  Priority     |C|L| Reserved  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        +                                                               +
        |                                                               |
        +                        Care-of Address                        +
        |                                                               |
        +                                                               +
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          Lifetime             |          Reserved             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where Length is either 4, 20 or 24.

C==0 and L==0, Length=4

C==0 and L==1: maybe this should be an illegal combination?

C==1 and L==0, Length=20: lifetime is taken from BU's lifetime field

C==1 and L==1, Length=24: Lifetime field overrides BU's lifetime field

Correspondent Binding Unique Identifier sub-option (CBID)
---------------------------------------------------------

                             1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                        |   Type = TBD  |     Length    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Binding Unique ID (BID)   |  Priority     |C|L| Reserved  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
        |                                                               |
        +                                                               +
        |                                                               |
        +                        Care-of Address                        +
        |                                                               |
        +                                                               +
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |         Home Nonce Index      |     Care-of Nonce Index       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        +                                                               +
        |                         Authenticator                         |
        +                                                               +
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          Lifetime             |          Reserved             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where Length is either 4, 36 or 40.

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 29 Mar 2006 00:49:49 +0900

Hi Heikki

Thanks for comments.
see my comments inline

On 2006/03/23, at 23:09, Heikki Mahkonen wrote:

> "smarter" mechanism is needed, than the one specified in the  
> current MCoA draft, to remove and add bindings between HoA and  
> multiple CoAs.
>
> If the MN which has registered these bindings makes a handover and  
> it wants to replace the CoA1 and CoA2 with a CoA4 and the CoA3  
> remains valid. Does the MN send two BU messages to de-register the  
> CoA1 and CoA2 and one BU message to register the CoA4? How about if  
> the MN had three or more CoAs which needs to be removed and three  
> or more CoAs which needs to be added? This problem escalates, right  
> (6 or more BU messages)? To me this seems little bit unwise. What  
> do you think?

You don't need to de-register CoA1 and CoA2, but only update CoA1 and  
CoA2 to CoA4 by two BUs.
HA can update the correspondent binding with the new CoA (i.e. CoA4)  
because of BID.

Anyway, your scenario may happen, but imagine when a MN has three  
different interfaces,
the address change will not be often occurred at the same time.

For example, WLAN and EVDO are different coverage and handover timing  
is also different.
That's why we only support separate BUs.

The important aspect of bulk BU is that the address changes must be  
happened at the same time. Otherwise, the MN shouldn't send BUs for  
multiple CoAs.

> One option could be for the MN to always add all the valid CoAs  
> into the BU message with lifetime 0 and when CN or HA receives this  
> BU message it would

why lifetime zero?

> replace the bindings for that HoA. But if the CNs and HAs function  
> separate BU messages because the CoA sent in the first BU message  
> would always be replaced with the CoA in the second BU message  
> (lifetime not 0). So if you only use the mechanism specified in the  
> draft you have to choose to send each CoA in one BU message or you  
> have to send all CoAs in each BU message, right?

No.
If MN has three CoAs, MN can send two BUs (a BU for CoA1 and a BU for  
CoA2 and CoA3).

> Now, if you add the binding lifetime into the BID option you can de- 
> register old CoAs and register new ones with only one BU message!!!  
> Well MTU would be the limit. That is, you always have to take care  
> to de-register invalid CoAs by sending a BID option with lifetime  
> zero for the de-registration and this is the only way you can  
> remove invalid CoAs. IMHO, this sounds better. However, this could  
> be misunderstanding on my part and/or you could have better  
> solution to this problem?

deregistration and registration are occurred at once as same as MIP6.  
i.e. Updating binding.

> Do you or anybody have any thoughts about this?

I don't know if I understand your point

ryuji

---

From: "Starry.Lin" <[email-masked]>
Date: Wed, 29 Mar 2006 13:16:39 +0800

In the "Multiple Care-of Addresses Registration
draft-wakikawa-mobileip-multiplecoa-05" Page 10, there is a paragraph
described as below:

   The second situation is when a mobile node does not want to return
   home, though one of its interfaces is attached to its home link.  The
   mobile node disables the interface attached to the home link and
   keeps using the rest of interfaces attached to foreign links.  In
   this case, the mobile node sends a de-registration Binding Update for
   the interface attached to the home link with the Binding Unique
   Identifier sub-option.  The receiver of the de-registration Binding
   Update deletes only the correspondent binding entry from the binding
   cache database.  The home agent does not stop proxying neighbor
   advertisement unless there are still bindings for the other
   interfaces.

   The last sentence of this paragraph make me puzzled. Why the HA doesn't
stop proxying while there are no more bindings for other interfaces.  In my
opinion, the right expression may like this: " The home agent does not stop
proxying neighbor advertisement if there are still bindings for the other
interfaces." or "The home agent stop proxying neighbor advertisement unless
there are still bindings for the other interfaces."

  Anybody can clarify the puzzled for me? whether it's just a typing mistake
or for the poor of my english? 

Thanks!

---

From: Heikki Mahkonen <[email-masked]>
Date: Wed, 29 Mar 2006 11:13:05 +0300

Hi Ryuji,

Thank you for your reply. I have included my (hopefully) clarifying 
comments inline.

> HA can update the correspondent binding with the new CoA (i.e. CoA4)  

==> OK! When I wrote the original mail I didn't take into acount that it 
is possible to reuse BIDs. This I think is what you are talking about in 
your reply, aren't you? I originally had the misunderstanding that you 
create new BID for every CoA. So what you do is you rather make one BID 
for the first CoA you register and when this CoA changes you use the 
same BID for updating the binding, right? This is a good mechanism but I 
still see a problem with it and I try to clarify what I think the 
problem is.

> the address change will not be often occurred at the same time.

==> Yes it actually can, because ( I have a good imagination, no =) ), 
you might have multiple CoAs per interface in this scenario as well. So 
when you make a handover from one access network to another and you had 
or now have multiple CoAs you end up sending either one bulk BU or many 
BUs. So you could say that in this scenario as well multiple CoAs are 
changing at the same time.

> That's why we only support separate BUs.

==> By saying this do you also say that you only want to support one CoA 
per interface? I have been focusing on this subject in more general 
level and thinking how this would work for the different scenarios 
described in the Analysis of Multihoming in Mobile IPv6 draft 
(draft-ietf-monami6-mipv6-analysis-00.txt). There you also have 
scenarios where you have more than one CoA in one interface (for 
instance more than one prefix in the access network).

> happened at the same time. Otherwise, the MN shouldn't send BUs for  

==> OK! I originally meant that the CoA1 and CoA2 are CoAs from the same 
interface. So let me clarify my example. You have one HoA, three CoAs 
and two interfaces. Two of the CoAs are from the same interface. So even 
  when the CN or HA does not know based on the CoAs or BIDs which 
address is from which MNs interface the BC would look like this.

BID1, HoA, CoA1 (WLAN)
BID2, HoA, CoA2 (WLAN)
BID3, HoA, CoA3 (EVDO)

So now when your WLAN interface makes a handover from a link with two 
prefixes to a link with only one prefix the CoA1 and CoA2 needs to be 
"updated" to CoA4 which is now the new CoA of the WLAN interface. In 
this case you can only reuse one of the BIDs (either BID1 or BID2) for 
the CoA4 and you have to do something else to remove the binding with 
the leftover BID. So this is why I make such a fuss about this what if 
you have this many CoAs and they are changed to this many CoAs. =) But 
OK, if you only want to support one CoA per interface then this is no 
problem at all.

My opinion is that you can't make the assumption that MNs are only using 
one CoA per interface. At least, this assumption should be clearly 
stated in the draft.

>> One option could be for the MN to always add all the valid CoAs  into 
>> the BU message with lifetime 0 and when CN or HA receives this  BU 
>> message it would
> 
> 
> why lifetime zero?

==> =) I don't know, beats me (who wrote this?)! =) OK, I was clearly 
thinking something else and writing something completely different.
My point which I tried to make (and clearly did not make) is that when 
in a situation where you are replacing N bindings with N-M (M>0) 
bindings you can't reuse all the BIDs and therefore you cannot update 
all the BC entries. This is why you would need some other means of 
removeing the bindings you don't need anymore and updating them with the 
new ones and also leave the bindings still valid (from different 
interfaces) in to the BC.

> If MN has three CoAs, MN can send two BUs (a BU for CoA1 and a BU for  

==> Hmmm... I don't understand this. Do you mean one BU for CoA1 and one 
for CoA2? Because the CoA3 should be left into the BC as it is still 
valid because the EVDO interface did not move. Therefore, no BUs should 
be sent with BID3 or how do you see this? So after the update the 
binding cache should look like this, right.

BID4, HoA, CoA4 (WLAN)
BID3, HoA, CoA3 (EVDO)

Now the BID4 could be BID1 or BID2 but one of these BC entries needs to 
be removed by some other means.

> deregistration and registration are occurred at once as same as MIP6.  

==> Actually I have to disagree here also. This is not always the case!

I think that there are three cases which need to be thought of:

case 1:
You have the same amount of CoA(s) in the new access network as you had 
in the previous access network. In this case yes you can simply update 
the binding and reuse the BID(s) for this. This is the same as in MIP6 
(RFC 3775). So no problem here! Other than the fact that you need bulk 
registration to minimize the signaling overhead if you have more than 
one CoA.

case 2:
You have more CoAs in the new access network than you had in the 
previous access network. In this case you can update the existing 
bindings by reusing the BIDs and allocate new BID(s) for the additional 
CoAs. So no problem here other that the possible signaling overhead.

case 3:
You have less CoAs in the new access network than you had in the 
previous access network. In this case you can only reuse some of the 
BIDs to update the binding but have to have some mechanism to remove the 
  not valid CoAs as well. So this case is the problem I'm talking about.

> I don't know if I understand your point

==> I hope you now see what I tried to explain in the original mail? If 
you choose to only support one CoA per interface and this is also WG's 
decision then I think this should also be stated in the drafts which are 
writen for this WG.

Best regards,

Heikki Mahkonen