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:benjamin.limck@sg.panasonic.com] 
> Sent: 12. december 2008 04:01
> To: Kaas-Petersen Christian
> Cc: mext@ietf.org
> Subject: Re: [MEXT] Subject: Multiple CoA draft 10 -- two 
> proposals and some comments
> 
> Hi Christian,
> 
> Comment to one of your question.
> 
> Christian.Kaas-Petersen@tieto.com 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
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext