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

["Giaretta, Gerardo" <[e-mail]>]

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> [e-mail]
> Sent: Friday, December 12, 2008 1:48 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two proposals and some
> comments
> 
> 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
> 
> 
> > -----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
_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext