Subject: [nemo] Closing Issue 16

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 02 Dec 2003 15:56:51 -0800

hi all,

this issue was about support MIPv6 Home Agents that do not support
mobile routers. we initially modified DHAAD to return only the list
of home agents that support mobile routers. but Pascal and Jari
argued that the protocol is more robust if the Home Agent echos a
bit in the binding acknowledgement to indicate to the mobile router
that it has setup forwarding for the mobile network.

so I changed the format of the binding ack to include a new flag.
this flag is set when the Home Agent which processed the binding
update supports mobile routers and the mobile router flag in the
corresponding binding update was set to 1.

change the binding ack format

4.2. Binding Acknowledgement

    A new flag (R) is included in the Binding Acknowledgement to indicate
    that the Home Agent which processed the corresponding Binding Update
    supports Mobile Routers.  The flag is set only if the corresponding
    Binding Update had the Mobile Router flag (R) set to 1.  The rest of
    the Binding Acknowledgement format remains the same as defined in
    [1].

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                        |   Status      |K|R|  Reserved |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |         Sequence #            |           Lifetime            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        .                                                               .
        .                        Mobility options                       .
        .                                                               .
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Mobile Router Flag (R)

          The Mobile Router Flag is set to indicate that the Home Agent
          which processed the Binding Update supports Mobile Routers.  It
          is set to 1 only if the corresponding Binding Update had the
          Mobile Router flag set to 1.

       For a description of the other fields in the message, see [1].

    This document also introduces the following new Binding
    Acknowledgement status values.

       140     Mobile Router Operation not permitted

       141     Invalid Prefix

       142     Not Authorized for Prefix

       143     Forwarding Setup failed

    Status values less than 128 indicate that the Binding Update was
    processed successfully by the receiving nodes.  Values greater than
    128 indicate that the Binding Update was rejected by the Home Agent.

change section 5.3

5.3. Receiving Binding Acknowledgements

    The Mobile Router receives Binding Acknowledgements from the Home
    Agent, corresponding to the Binding Updates it sent.  If the Binding
    Acknowledgement status is set to '0' (Binding Update accepted) and
    the Mobile Router flag (R) is set to 1, the Mobile Router assumes
    that the Home Agent has successfully processed the Binding Update
    and has set up forwarding for the Mobile Network.  The Mobile Router
    can then start using the bi-directional tunnel for reverse tunneling
    traffic from the mobile network.  If the Mobile Router flag (R) is
    not set, then the Mobile Router concludes that its current Home Agent
    does not support Mobile Routers and performs Dynamic Home Agent
    Discovery again to discover Home Agents which support Mobile Routers.

modify section 6.6 to say

    The Home Agent sets the status code in the Binding Acknowledgement
    to '0' (Binding Update accepted) in order to indicate to the Mobile
    Router that it successfully processed the Binding Update.  It also
    sets the Mobile Router flag (R) to indicate to the Mobile Router that
    it has setup forwarding for the Mobile Network.

a MIPv6 Home Agent will not set this flag.

let me know if this looks good.

Vijay

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 3 Dec 2003 10:59:27 -0000

Vijay:

Fine with me too :) It's a pain that the bit in the ack is not the same as the bit in the req but it's already true for the K bit, so...

I've also reviewed your text in pre_02 for the change in DHAAD, in the light of Jari's comment that the capabilities should be a response thing and not a req thing, which I do agree on.

Say we add more and more features like basic nemo and now HAs support a number of those features. The request may end up like an SQL query depending on what the requester wants or is willing to accept if the most wanted is not available. Wouldn't it be better to list everything and let the requester sort it out based on its own preference?

On the other hand, there are formatting issues and the list of HAs as presented here is very practical. But if you look at prefix options in RAs, they already have additional info associated with them.

Pascal
> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: mercredi 3 décembre 2003 08:50
> To: Vijay Devarapalli
> Cc: [email-masked]; Pascal Thubert (pthubert)
> Subject: Re: [nemo] Closing Issue 16
> 
> 
> It does. Thanks! I agree with Ryuji that you should
> require a de-register if the home agent turned out to
> be plain MIPv6 only.
> 
> --Jari

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 4 Dec 2003 07:30:48 -0000

MIPv6 did not set a direction for this. Because it does not need it for itself. It appears it would if it is seen as a precursor. If it's not in MIPv6, then the first RFC coming next sets the direction. But taking the wrong direction will make the future painful. I'd sure appreciate Jari's advice.

Pascal

> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: mercredi 3 décembre 2003 19:10
> To: Pascal Thubert (pthubert)
> Cc: Jari Arkko; [email-masked]
> Pascal Thubert (pthubert) wrote:
> 
> >
> > Say we add more and more features like basic nemo and now HAs support a number of those
> features. The request may end up like an SQL query depending on what the requester wants or
> is willing to accept if the most wanted is not available. Wouldn't it be better to list
> everything and let the requester sort it out based on its own preference?
> 
> you maybe right. but NEMO basic support spec the place to do it?
> 
> Vijay