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

[Benjamin Lim <[e-mail]>]

Hi Christian,

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

[e-mail] wrote:
> 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
[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.

> 
> 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.
[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.

> 
> 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.
[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

> 
> 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
>  
> 
>> -----Original Message-----
>> From: Benjamin Lim [mailto:[e-mail]] 
>> Sent: 12. december 2008 04:01
>> To: Kaas-Petersen Christian
>> Cc: [e-mail]
>> Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two 
>> proposals and some comments
>>
>> Hi Christian,
>>
>> Comment to one of your question.
>>
>> [e-mail] wrote:
>>> 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.
>> [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
>>
>>
>>
> 
> 


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