Subject: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some comments

From: <[email-masked]>
Date: Thu, 11 Dec 2008 15:08:16 +0100

Assume a mobile node with home address HoA has two interfaces,
both attached to foreign links.  After exchange of binding update
and binding acknowledgement, the home agent's binding cache (at
least the snip of it related to HoA) will look like this

    HoA, BID= 7, CoA1, other parameters like period of validity...
    HoA, BID=10, CoA2, other parameters ...

The draft uses HoA=2001:db8::EUI.

Draft 10, section 5.1 states, that a BID value must be unique for a
home address and care-of address pair.  This is satisfied above, but
it means, that the mobile station is not allowed to change the
second entry such that it also uses CoA1 as care-of address.

Proposal:  I think it has merit to be able to allow more than
one BID value per pair of home address and care-of address.  Consider
flow bindings (defined in draft-ietf-mext-flow-binding) where
a flow may refer to a BID, and thus there is a simple way to move
flows between interfaces: only updating the binding cache.

Draft 10, section 4.2 (and other places) defines the H flag, which when
set means the mobile node wants to use both its home link and one or
more of its foreign links.  The H flag is really an instruction to the
home agent, that in addition to all the bidings currently defined
is shall have an extra binding where packets shall not be tunneled.  

Proposal:  The mobile node should be able to define a binding saying

    HoA BID=0 HoA

This is a kind of default binding to be used when any of the other HoA-
bindings cannot be used.  I think the H flag is an indirect way of
saying there is an extra binding, whereas the binding above is direct.
It also avoids continuously setting the H flag when both home link
and foreign links are active.

Other comments

 o Figure 1: In general I think it simpler for human readers to have
   the elements of the primary key to a database given first,
   therefore I suggest

       binding [2001:db8::EUI  BID1  care-of address1]

   to be used allover.

 o Figure 4: looks as if position 6 is followed by position 17.

 o Section 4.2, O flag.  The O flag is carried in an Binding
   Identification mobility option, but really it a kind of global
   value to be understood by the receiver as "clean all HoA entries".
   If it really is too much to introduce a new mobility option,
   isn't it enough to set the O flag in the first Binding
   Identification mobility option?

 o Section 4.2, Care-of address and section 6.2 bullet 6, sub-bullet 2.
   If the care-of address is omitted, the care-of address is to be
   taken from the source address of the IPv6 header.
   When the binding update arrives at the home agent, the
   IPv6 header's source address is exactly the care-of
   address used by the mobile node, but when the home agent is 
   actually able to understand the contents of the binding update,
   then the IPv6 headers source address has been swapped with the
   address found in the Destination Option extension header,
   and thus the care-of address is now found in the Destination
   Option extension header.

 o Section 5.6.2, bullet 2.  The term link-local address is used, but I
   think this should be changed to be like in all the other places,
   using link-layer address.

 o Section 6.2, bullet 7, sub-bullet 1: I think the condition should
read
   "If one of the 'O' flags is set, then all of the 'O' flags must be
   set, else [MCOA MALFORMED] is returned."  But as suggested above, 
   I don't think there is reason to enforce an all-or-none 'O' flags.

 o Section 8.2, para 2.  The text says, that the IPv4 Address
   Acknowledgement mobility option is included only if the mobile node
   requested a home address.  When I read
draft-ietf-mext-nemo-v4traversal,
   section 4.2.1, the IPv4 Address Acknowledgement mobility option
   is included always, indicating the home agent created a binding cache
   entry for the IPv4 home address.

Christian 

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 11 Dec 2008 09:05:21 -0800

Hi Christian,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Thursday, December 11, 2008 6:08 AM
> To: [email-masked]
> Subject: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some
> comments
> 

I guess you mean only updating the CoA of the BCE/BID. I think this is a very valid point and it should be allowed. I did not realize this was not possible while reading the draft. I agree this is a necessary feature when coupling MCoA with flow bindings.

Thanks
Gerardo

---

From: Benjamin Lim <[email-masked]>
Date: Fri, 12 Dec 2008 11:00:33 +0800

Hi Christian,

Comment to one of your question.

> and foreign links are active.
[Ben] I cannot understand the reasoning for this.  Does not the use of
the H flag can achieve the same purpose as the 'default' binding as you
mention?  Is there some issue for the H flag to require this change you
are proposing?  Also, note that this draft underwent one IESG review and
changing a working mechanism now does not seem to garden any logic.

Regards,
Benjamin Lim

---

From: Conny Larsson <[email-masked]>
Date: Fri, 12 Dec 2008 06:59:42 +0100

Hi Christian,

> flows between interfaces: only updating the binding cache.
I agree with Gerardo. When reading the draft I did not catch this one 
but I agree that the behaviour should be as you have described it above.

Regards
Conny

---

From: <[email-masked]>
Date: Fri, 12 Dec 2008 10:47:47 +0100

Thanks for the comment.

I understand the draft has been reviewed carefully.
I'll give some more details on my proposal, as follows.
I might of course have misunderstood the text of the draft, so
please correct me.

Assume the situation, see draft 10, Figure 3, Topology B, slightly
edited to illustrate the situation when the mobile node is away.

                    +----+
                    | CN |
                    +--+-+
                       |
                   +---+------+    Router    +----+
            +------+ Internet |-------R      | HA |
            |      +----+-----+       |      +--+-+
        CoA2|           |             |         |   Home Link
         +--+--+        |           --+---------+------
         |  MN +========+
         +-----+ CoA1

In this situation, the mobile node could have populated (using binding
updates) the home agent's binding cache as follows

    v6HoA   BID= 7   CoA1
    v6HoA   BID= 8   CoA1
    v6HoA   BID=11   CoA2
    v6HoA   BID=13   CoA2

Should the home agent receive a packet destined for v6HoA, which
it cannot map to one of the BID values 7, 8, 11, or 13, the
home agent will drop such a packet.

Now the mobile node attaches to the home link (the figure below is
now the unedited Figure 3, Topology B)

                    +----+
                    | CN |
                    +--+-+
                       |
                   +---+------+    Router    +----+
            +------+ Internet |-------R      | HA |
            |      +----+-----+       |      +--+-+
        CoA2|           |             |         |   Home Link
         +--+--+        |           --+-+-------+------
         |  MN +========+               |
         +--+--+ CoA1                   |
            |                           |
            +---------------------------+

The mobile node wants to move two bindings to the home link.  Thus
naively the mobile node wants the home agent to have the following
binding cache.

    v6HoA   BID= 7   CoA1
    v6HoA   BID= 8   v6HoA
    v6HoA   BID=11   CoA2
    v6HoA   BID=13   v6HoA

This naive approach should not be used, because the home agent should
not keep bindings when packets are not be tunneled.
On the other hand, this situation is different to previous
mobility solutions by allowing being at home and away at the same time.

The proposal given in draft 10 is, that as long as the mobile
node wants to use its attachment to the home link, it must set the
H-bit in all binding identification options using foreign links.
In the end, the home agent will have the following binding cache

    v6HoA   BID= 7   CoA1
    v6HoA   BID=11   CoA2

plus the H-bit information.  Thus when the home agent receives a packet
destined for v6HoA which cannot be mapped to BID values 7 or 11, such
a packet will be sent on the home link.  The presence of the H-bit
is like having a final default entry in the binding cache.  The H-bit
must be sent in all updates to the bindings as long as access
to the home link is maintained.  The proposal was therefore to
add this final entry explicitly, allowing the mobile node to send
a binding update with contents "v6HoA BID=0 v6HoA".
The binding identifier "v6HoA BID=0 v6HoA" could be sent only once
when attachment to the home link was established, and removed when
the attachment was removed.

First time the H-bit is set it means "I now want to use also my
home link" whereas all following packets set the H-bit meaning
"I still want to use my home link".  It is this sort of keepalive
mechanism for the home link I find a little surprising.

Christian

> From: Benjamin Lim [mailto:[email-masked]] 
> Sent: 12. december 2008 04:01
> To: Kaas-Petersen Christian
> Cc: [email-masked]
> Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two 
> proposals and some comments
> 
> Hi Christian,
>

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 13 Dec 2008 00:05:25 +1100

> second entry such that it also uses CoA1 as care-of address.

=> But why would the MN want to do that? The scenario you're suggesting
means that there is effectively one binding, so why do we need to allocated
two BIDs to the same CoA? If there is a reason then I think your proposal is
fine, although it will be tricky to implement. But I'd like to see a
plausible scenario first.

> and foreign links are active.

=> This is basically asking for a permanent binding. Again, I'd like to
understand why this is needed, compared to what the draft says now.

Hesham

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Fri, 12 Dec 2008 11:25:45 -0800

Hi Hesham and Christain,

See below some comments

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hesham
> Soliman
> Sent: Friday, December 12, 2008 5:05 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some
> comments
> 
> 
> 
> 

Suppose the MN is connected to access 1 and access2 and has two flow bindings with two different CoA

HoA, BID=1, CoA1, FID1, FID4, FID6
HoA, BID=2, CoA2 FID2, FID3, FID5

When the MN loses access 2 coverage it can do two things to keep the flows active:
- send a BU with HoA, BID=1, FID2, FID3, FID5 to add those flows to the first binding
- send a BU with HoA, BID=2, CoA1 to update the CoA of the second binding

The second has advantages in terms of signaling overhead. This is true in particular if then the MN moves back to access2 and wants to re-establish the flow bindings as previously. In that case just a new CoA update is needed instead of re-registering the flows again.

If the second approach is used you will have up giving two different BIDs for which the CoA is the same. But this should not be an issue as the bindings are treated independently, they just happen to point to the same CoA

Gerardo

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Fri, 12 Dec 2008 11:29:19 -0800

I think Christian has a valid point here. In particular this is useful/needed when flow bindings is used and one interface is in the home link. In the way Christina is proposing, the MN could explicitly associate some flows to the interface which is on the home link. In the way the draft it is written now, the home link becomes always the default route.

Basically the current draft does not support the scenario where the MN wants to have FID1 in the interface in the home link and a match all entry for the interface in the foreign link. To allow this, a BID needs to be allocated to the interface in the HoA. 

Gerardo

> Sent: Friday, December 12, 2008 1:48 AM
> To: [email-masked]
> Cc: [email-masked]

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 13 Dec 2008 13:06:03 +1100

> The second has advantages in terms of signaling overhead. This is true in
> particular if then the MN moves back to access2 and wants to re-establish the
> flow bindings as previously. In that case just a new CoA update is needed
> instead of re-registering the flows again.

=> That's right, I guessed this is why you and Christian were asking for it.
But I think it's strange to have a binding id if it's not unique because
it's basically replicating the binding in case we need to change the CoA. It
makes things more complex and error prone in the implementation for a small
difference of bytes that will be sent. After all, you're not eliminating the
need to send another BU, you're just sending a smaller BU. So if you're
lucky, you'll save tens of bytes. It's not worth it IMHO.

Hesham

> 
> If the second approach is used you will have up giving two different BIDs for
> which the CoA is the same. But this should not be an issue as the bindings are
> treated independently, they just happen to point to the same CoA
> 
> Gerardo
>

---

From: Benjamin Lim <[email-masked]>
Date: Mon, 15 Dec 2008 11:52:18 +0800

Hi Christian,

Thanks for providing details.  Pls see inline for my comments.

>             +------+ Internet |-------R      | HA |
[Ben] Is there a reason why you would want to create duplicate entires
for CoAs in the BCE?  I agree you can implement it this way, but I
cannot see the reasoning for it.  Unless this is the 'navie' approach
you are talking about that MN creates these duplicate entires in
anticipation that it might want to use simultaneous home and foreign link.

> home agent will drop such a packet.
[Ben] I am not sure where you pull this assumption of HA dropping
packets so long there is no match.  I do not think that such assumption
is valid as even the flow filtering draft mentions a default binding to
be maintain and thus if a flow does not match any FID at HA, it is
possible for that flow to be routed using the default entry in the BCE.

>             +------+ Internet |-------R      | HA |
[Ben] By sending the above BID once when attaching and removing it when
attachment is gone seems to imply infinite lifetime for the home link
attachment.  The purpose of lifetime is a way to let HA know that MN is
still on that link (by forcing MN to refresh the lifetime).  I am not
sure if there are deployments that allow MN to obtain infinite lifetime.
 Even for 3GPP when PMIP is used for home link by MN, the MAG still have
to refresh the PBU based on the lifetime.

Regards,
Benjamin Lim

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 17 Dec 2008 15:27:01 +0900

Hi Christian,

thanks for comments.

> flows between interfaces: only updating the binding cache.

Do you want these bindings? 
     HoA, BID= 7, CoA1, other parameters like period of validity...
     HoA, BID=10, CoA1, other parameters ...

>From the protocol operational view, we don't have any issue to relax
the BID assignment for this purpose.

> and foreign links are active.

This was originally proposed by Keigo from Panasonic and has been discussed it.
You can check the discussion on ML archives.

>        binding [2001:db8::EUI  BID1  care-of address1]

OK, will fix this.

>  o Figure 4: looks as if position 6 is followed by position 17.

this is typo. i'll fix this.

>    Identification mobility option?

I'm updating the document after last call. the O flag is now defined
in the BU itself, since this is global value for all bindings as you pointedout.

>    and thus the care-of address is now found in the Destination

In section 6.1.7 of RFc3775, it said
  "The care-of address is specified either by the Source Address field
   in the IPv6 header or by the Alternate Care-of Address option, if
   present. "

So, I will fix this to 

the care-of address is to be taken from the source address of the IPv6 header "of the Binding Update".

>    using link-layer address.

yes, thanks.

>    I don't think there is reason to enforce an all-or-none 'O' flags.

right, see above.

>    entry for the IPv4 home address.

correct. I will check dsmip and update it.

thanks
ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 17 Dec 2008 15:31:43 +0900

Hi Gerardo,

At Thu, 11 Dec 2008 09:05:21 -0800,
> I guess you mean only updating the CoA of the BCE/BID. I think this is a very valid point and it should be allowed. I did not realize this was not possible while reading the draft. I agree this is…

it is allowed, though this is not clear from the current spec. 
Christian's point is whether we allow multiple bindings (BID) which HoA and CoA are same. 

regards,
ryuji

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Tue, 16 Dec 2008 22:42:23 -0800

Hi Ryuji,

one point related to Christian's comments is that we need a BID also for the interface which is on the home link. This is needed in order to associate FIDs to that interface. The rules to create/update/delete that BID should be the same as for any other binding

Gerardo

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Ryuji Wakikawa [[email-masked]]
Sent: Tuesday, December 16, 2008 10:27 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some    comments

Hi Christian,

thanks for comments.

OK, will fix this.

So, I will fix this to

yes, thanks.

right, see above.

thanks
ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 17 Dec 2008 16:17:32 +0900

Hi Hesham

At Sat, 13 Dec 2008 13:06:03 +1100,

>From protocol point of view, except for error handling, there are no
big issues and extentions to the current spec..

However, this feature is basically proposed for the flow binding optimization.

Shall we relax this restriction (change MUST to SHOULD) to keep the
flow binding optimization?

regards,
ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 17 Dec 2008 16:32:08 +0900

Hi Gerardo,

Yes, I was reading the mail threads. sorry to catch up this thread  
late. I was in Europe;-)

I understand the reasons of BID for the home attached interface.

MN keeps sending the BU (w/ non zero lifetime) from the home link?
It sounds like we'll remove de-registration operation from RFC-3775?

As a result, HA will have a home binding for the interface attached to  
home link,
but will not operate proxy ND and encapsulation for that binding.
I don't know this is reasonable modification to RFC-3775.

My understanding was that, when MN is at home, most of traffic should  
be sent directly from the home link.
I didn't see any strong reasons to use the interface attached to  
foreign links.
Why not setting special flows which need to be sent from the foreign  
link by flow binding and
rest of traffic are just sent from the home link. We don't need BID  
for the home attached interface.
This is what I expected.

Do you think there is a case where MN attaches to home link by  
multiple interfaces?

regards,
ryuji

On 2008/12/17, at 15:42, Giaretta, Gerardo wrote:

> Hi Ryuji,
>
> one point related to Christian's comments is that we need a BID also  
> for the interface which is on the home link. This is needed in order  
> to associate FIDs to that interface. The rules to create/update/ 
> delete that BID should be the same as for any other binding
>
> Gerardo
>
> From: [email-masked] [[email-masked]] On Behalf Of  
> Ryuji Wakikawa [[email-masked]]

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 17 Dec 2008 07:59:21 -0800

Hi Ryuji,

> From: Ryuji Wakikawa [mailto:[email-masked]]
> Sent: Tuesday, December 16, 2008 11:18 PM
> To: Hesham Soliman
> Cc: Giaretta, Gerardo; [email-masked]; [email-masked]
> > > Suppose the MN is connected to access 1 and access2 and has two flow
> bindings
> > > with two different CoA
> > >
> > > - send a BU with HoA, BID=1, FID2, FID3, FID5 to add those flows to the
> first
> > > binding

What is exactly the text you propose to change in the draft?

Thanks
Gerardo

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 17 Dec 2008 08:47:12 -0800

Hi Ryuji,

> Sent: Tuesday, December 16, 2008 11:32 PM
> To: Giaretta, Gerardo
> Cc: [email-masked]; [email-masked]

The point is that the MN does no de-register as in RFC-3775 if there are other active interfaces. The MN will de-register only when only the interface on the home link is active.

> but will not operate proxy ND and encapsulation for that binding.

If the HA is the default router, the HA will still intercept all packets as defined in the draft. It is true that there will be no encapsulation, but again this is already mentioned in the draft.

> Do you think there is a case where MN attaches to home link by

Think about this scenario: the MN has a cellular interface and a WLAN interface. Cellular is the home link. MN wants to do VoIP over cellular and all other traffic over WLAN. In this case the MN will register a match-all filter for WLAN BID and more specific FIDs for the "home binding". This is the main scenario studied in 3GPP for example. 

In my opinion, allocating a BID for the HoA in the home link sounds like the cleanest way of solving this scenario. However I am open to other suggestions as soon as the scenario is supported :-)

Gerardo

---

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 19 Dec 2008 18:40:28 +0900

Hi Gerardo,

On 2008/12/18, at 1:47, Giaretta, Gerardo wrote:

> The point is that the MN does no de-register as in RFC-3775 if there  
> are other active interfaces. The MN will de-register only when only  
> the interface on the home link is active.

OK

> If the HA is the default router, the HA will still intercept all  
> packets as defined in the draft. It is true that there will be no  
> encapsulation, but again this is already mentioned in the draft.
>
> Think about this scenario: the MN has a cellular interface and a  
> WLAN interface. Cellular is the home link.
> MN wants to do VoIP over cellular and all other traffic over WLAN.  
> In this case the MN will register a match-all
> filter for WLAN BID and more specific FIDs for the "home binding".  
> This is the main scenario studied in 3GPP for example.
>
> In my opinion, allocating a BID for the HoA in the home link sounds  
> like the cleanest way of solving this scenario.
> However I am open to other suggestions as soon as the scenario is  
> supported :-)

If we need a BID for the interface attached to the home link, we need  
a "binding".
I think we don't have any other alternative for this purpose.

I will update the document for this and will post the new version  
(including modifications of all other comments during last call).

ryuji