Subject: [Monami6] Changes needed to MCoA draft?

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

Hi Ryuji,

     What I think is that the MCoA draft is a good draft and it 
definitely should be monami6 WG draft as the monami6 charter also 
specifies. As I write this, I'm not awere of any decisions people have 
made in the monemi6 WG meeting held on tuesday about making this draft a 
WG draft. However, I also think that the MCoA draft needs some 
additional work to bring a optimal solution for the MCoA problem space.

     I think that the draft should solve two separate problem scenarios. 
First, it should enable MIPv6 MNs to bind more than one CoA to a single 
HoA. Second, it should specify a optimal way of delivering these 
bindings to HAs and CNs. Optimal way in this context meaning that the 
signaling overhead should be minimized (BU packet size and the number of 
BUs sent should be optimal).

1. Problems which the current draft solves:

     The current version of the MCoA draft solves the problem of binding 
multiple CoAs to a single HoA for HAs and CNs by introducing a BID for 
the bindings. This is a good and optimal solution for the first problem 
scenario and I don't think this needs to be changed.

     In addition the current draft specifies a BID option to deliver 
these BID's for the bindings in a BU message. This is also good solution 
when each CoA is sent in a single BU (either as source address or in a 
ACoA option). This BID option is in this case valid for HAs as well as 
any CNs.

2. Problems with the current draft:

     The problems I can see with the current MCoA draft are with the 
second problem scenario which deals with a way of delivering the BIDs to 
other nodes from the MN. This should be done in a optimal way and I 
think that sending one BU for each CoA to HAs and CNs is not an optimal 
way. My opinion is that the MCoA draft should offer a way of piggy 
baging more than one CoA into a BU message destined to HAs and CNs. As I 
see it, the current mechanism defined in the MCoA draft does not enable 
MNs to send multiple CoAs in a single BU at least not to CNs. My opinion 
is that a new mechanism should be defined which is used to deliver 
multiple CoAs in single BU message. This new mechanism is defined in 
addition to the mechanism defined in the current MCoA draft which now 
enables delivering of CoAs one by one to HAs and CNs. So if the MN 
chooses to use one or the other solution it is up to the implementation 
to decide which is the better mechanism in any situation.

     In addition, I think that both of the mechanisms (the current and 
the new mechanism) should also work with legacy MIPv6 nodes which do not 
support the MCoA funtionality. This means that there might be 
constraints when sending a BU with multiple ACoA options which is the 
way specified in the draft now.

     Also, when sending a BU message which includes more than one CoA 
which the MN whishes to register (with a HA or CN), the binding lifetime 
  for each CoA must be delivered for each CoA in the BU message. This is 
not currently done in the MCoA draft.

3. Solutions to the problem of delivering multiple BIDs and CoAs in a 
ingle BU message:

     There are two solutions for the second problem scenario. First 
solution is to define a variable length BID option. Second solution is 
to define three (two new) BID option types.

     It should be defined that MN must always adds one CoA to the BU 
message as a source address or in the ACoA option and it is used in the 
normal RFC 3775 way. For this CoA the MN includes a BID option which is 
formatted as specified in the current MCoA draft. This is a valid way of 
delivering one of the CoAs to HAs and when the BU is sent to the CN a 
normal BAD option is used to authorize this CoA. In addition the binding 
lifetime for this CoA comes from the lifetime field in the BU option 
header. This enables a binding with a legacy MIPv6 nodes (which simply 
ignore the unknown options in the BU) as well.

     When a MN is sending multiple CoAs to a HA in a single BU message, 
it will add the other CoAs (other than the one in the source address 
field or in the ACoA option) into a new variable length BID option. Each 
CoA is added into one BID option. Now this option would have the same 
fields currently defined in the MCoA option and in addition a field for 
the valid binding lifetime and a field for the CoA itself. The second 
solution is to add the binding lifetime and other CoAs into a new BID 
otion which looks like the BID option in the first case but would have 
different type code.

     When a MN is sending multiple CoAs to a CN in a single BU message, 
it will add the other CoAs (other than the one in the source address 
field or in the ACoA option) into a new variable length BID option. Each 
CoA is added into one BID option. Now this option would have the same 
fields currently defined in the MCoA option and in addition a field for 
the valid binding lifetime, a field for the CoA itself, and fields for 
the nonces and binding authorization data. The second solution also in 
this case is to add the lifetime, the other CoAs, and the nonce and 
authorization data into a new BID otion which looks like the BID option 
in the first case but would have different type code.

Any thoughts?

5. Conclusion:

     I think that the current version of the MCoA draft needs a little 
bit of rewriting for the reasons specified in this mail and the mail I 
just sent ("Problem with MCoA draft"). THe aim of the rewriting would be 
to define a good and optimal way of delivering the BIDs to the peer 
nodes of the MN.

     We (Martti Kuparinen, Tero Kauppinen and Heikki Mahkonen) would be 
more than happy to provide/contribute you with the needed changes to the 
draft if you think that it is a good way to approach this (you don't 
have time or you don't want to do it). Let us know if you want us to 
help you to write these parts of the draft.

Best regards,

Heikki Mahkonen

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

---

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

Hi Heikki again

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

> specifies. As I write this, I'm not awere of any decisions people  
> have made in the monemi6 WG meeting held on tuesday about making  
> this draft a WG draft. However, I also think that the MCoA draft  
> needs some additional work to bring a optimal solution for the MCoA  
> problem space.

We are waiting for the WG decision. I believe WG chairs should do  
something now.

>     I think that the draft should solve two separate problem  
> scenarios. First, it should enable MIPv6 MNs to bind more than one  
> CoA to a single HoA. Second, it should specify a optimal way of  
> delivering these bindings to HAs and CNs. Optimal way in this  
> context meaning that the signaling overhead should be minimized (BU  
> packet size and the number of BUs sent should be optimal).
>
>     The current version of the MCoA draft solves the problem of  
> binding multiple CoAs to a single HoA for HAs and CNs by  
> introducing a BID for the bindings. This is a good and optimal  
> solution for the first problem scenario and I don't think this  
> needs to be changed.
>
> these BID's for the bindings in a BU message. This is also good  
> solution when each CoA is sent in a single BU (either as source  
> address or in a ACoA option). This BID option is in this case valid  
> for HAs as well as any CNs.

OK so far.

> second problem scenario which deals with a way of delivering the  
> BIDs to other nodes from the MN. This should be done in a optimal  
> way and I think that sending one BU for each CoA to HAs and CNs is  
> not an optimal way. My opinion is that the MCoA draft should offer  
> a way of piggy baging more than one CoA into a BU message destined  
> to HAs and CNs. As I see it, the current mechanism defined in the  
> MCoA draft does not enable MNs to send multiple CoAs in a single BU  
> at least not to CNs. My opinion is that a new mechanism should be  
> defined which is used to deliver multiple CoAs in single BU  
> message. This new mechanism is defined in addition to the mechanism  
> defined in the current MCoA draft which now enables delivering of  
> CoAs one by one to HAs and CNs. So if the MN chooses to use one or  
> the other solution it is up to the implementation to decide which  
> is the better mechanism in any situation.

Again, as i said in previous mail, bulk registration is realistic  
only for the initial BUs. When a MN first register its binding to CNs.
Simultaneous CoAs changes are not so often occurred.

Anyway, I agree that the current draft is not complete solution for  
bulk registartion to CN.

>
>     In addition, I think that both of the mechanisms (the current  
> and the new mechanism) should also work with legacy MIPv6 nodes  
> which do not support the MCoA funtionality. This means that there  
> might be constraints when sending a BU with multiple ACoA options  
> which is the way specified in the draft now.

well, i can agree and disagree. For CN registration, CN will not  
reply BA. Therefore, MN cannot know whether CN register multiple CoAs  
or just single CoA.
You may set Ack bit for MCoA registration all the time to check this.

>     Also, when sending a BU message which includes more than one  
> CoA which the MN whishes to register (with a HA or CN), the binding  
> lifetime  for each CoA must be delivered for each CoA in the BU  
> message. This is not currently done in the MCoA draft.

no specification for bulk registartion.

> 3. Solutions to the problem of delivering multiple BIDs and CoAs in  
> a ingle BU message:
>
> solution is to define a variable length BID option. Second solution  
> is to define three (two new) BID option types.
>
> message as a source address or in the ACoA option and it is used in  
> the normal RFC 3775 way. For this CoA the MN includes a BID option  
> which is formatted as specified in the current MCoA draft. This is  
> a valid way of delivering one of the CoAs to HAs and when the BU is  
> sent to the CN a normal BAD option is used to authorize this CoA.  
> In addition the binding lifetime for this CoA comes from the  
> lifetime field in the BU option header. This enables a binding with  
> a legacy MIPv6 nodes (which simply ignore the unknown options in  
> the BU) as well.
>
>     When a MN is sending multiple CoAs to a HA in a single BU  
> message, it will add the other CoAs (other than the one in the  
> source address field or in the ACoA option) into a new variable  
> length BID option. Each CoA is added into one BID option. Now this  
> option would have the same fields currently defined in the MCoA  
> option and in addition a field for the valid binding lifetime and a  
> field for the CoA itself. The second solution is to add the binding  
> lifetime and other CoAs into a new BID otion which looks like the  
> BID option in the first case but would have different type code.
>
>     When a MN is sending multiple CoAs to a CN in a single BU  
> message, it will add the other CoAs (other than the one in the  
> source address field or in the ACoA option) into a new variable  
> length BID option. Each CoA is added into one BID option. Now this  
> option would have the same fields currently defined in the MCoA  
> option and in addition a field for the valid binding lifetime, a  
> field for the CoA itself, and fields for the nonces and binding  
> authorization data. The second solution also in this case is to add  
> the lifetime, the other CoAs, and the nonce and authorization data  
> into a new BID otion which looks like the BID option in the first  
> case but would have different type code.
>
> Any thoughts?

You solution can be possible. However, in Monami6 WG at dallas, the  
base specification should be simple.
The optimization is always good, but complication is not.

I think Hesham gave comments that we can initially support bulk  
registartion for HA and not for CN.
you can check the minutes of Monami6 WG meeting.

> 5. Conclusion:
>
>     I think that the current version of the MCoA draft needs a  
> little bit of rewriting for the reasons specified in this mail and  
> the mail I just sent ("Problem with MCoA draft"). THe aim of the  
> rewriting would be to define a good and optimal way of delivering  
> the BIDs to the peer nodes of the MN.
>
>     We (Martti Kuparinen, Tero Kauppinen and Heikki Mahkonen) would  
> be more than happy to provide/contribute you with the needed  
> changes to the draft if you think that it is a good way to approach  
> this (you don't have time or you don't want to do it). Let us know  
> if you want us to help you to write these parts of the draft.

Thanks.

One idea is that we can separate bulk registration into separate  
document.
I can remove the texts and move to the new document which will  
contain your inputs, too.

However, before doing that, the draft must be WG document.
This draft is still individual draft and not WG one.

I want to solicit the comments from WG chairs  first !!!

ryuji

---

From: Martti Kuparinen <[email-masked]>
Date: Wed, 29 Mar 2006 09:08:24 +0300

Ryuji Wakikawa wrote:

>> the new mechanism) should also work with legacy MIPv6 nodes which do
>> not support the MCoA funtionality. This means that there might be
> well, i can agree and disagree. For CN registration, CN will not reply
> BA. Therefore, MN cannot know whether CN register multiple CoAs or just
> single CoA. You may set Ack bit for MCoA registration all the time to check this.

What do you mean by "For CN registration, CN will not reply BA."?

Martti

---

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

> What do you mean by "For CN registration, CN will not reply BA."?

BA is necessary only for home registration.
Most of implementation, MN does not set A-bit for CNs

regards,
ryuji

---

From: Martti Kuparinen <[email-masked]>
Date: Wed, 29 Mar 2006 09:33:04 +0300

> Most of implementation, MN does not set A-bit for CNs

But this is not necessarily so as RFC 3775 also allows BUs to CNs with A=1. As
an example, our implementation always sets A=1 because we want to be sure the
binding registration was successful.

Martti

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 29 Mar 2006 15:53:27 +0900

At Wed, 29 Mar 2006 09:33:04 +0300,
> binding registration was successful.

correct, but you now introduce additional message (BA) for bulk registration.
If there are two CoAs, two BU vs 1xBU+1BA. It looks similar.

ryuji