Subject: [mobile-ip] MIPv6 v20/21 inconsistencies wrt CN binding (life) and home binding (life) [11.7.2]

From: "Greg O'Shea" <[email-masked]>
Date: Mon, 17 Feb 2003 14:57:43 -0000

1 = "After the mobile node has sent a Binding Update to its home agent
... the mobile node SHOULD initiate a correspondent binding procedure
for each node that already appears in the mobile node's Binding Update
List." [11.7.2]
2 = "Upon successfully completing the return routability procedure, and
after receiving a successful Binding Acknowledgement from the Home
Agent, a Binding Update can be sent to the correspondent node." [11.7.2]

Sending a home binding update (1) is not the same thing, and does not
occur at the same time as, receiving a home binding ack (2). I suspect
the BA provision of (2) should be removed.

I think the MN can send CoTi (and HoTi if it does not think it possesses
a valid Home Cookie) concurrently with sending the BU to its HA per (1).
This is optimistic, but not excessively so. If HA is temporarily
unreachable during handoff and MN has a Home Cookie for CN then the CN
binding may sometimes be renewed without reference to HA and in the
interim CN will not keep sending traffic to the old CoA. 

The difference between (1) and (2) will be one or a few seconds when the
HA is running DAD for the HoA, but this is a rare case.

I notice also that 11.7.2 and 11.7.4 say different things about max CN
binding life: 11.7.2 says max = life of HoA and 11.7.4 says max = life
of home binding. Is that deliberate?

There might be a slim case for (2) when the MN is changing between two
different HA on the home net, so initial (HoTi, HoT) may be dropped then
prolonged by the exponential backoff on HoTi rexmit. Was that the
concern?

(Should the "can" in (2) be ["MAY" | "SHOULD" | "MUST"] ?)

---

From: Jari Arkko <[email-masked]>
Date: Mon, 17 Feb 2003 17:19:10 +0200

Thanks again Greg for your detailed comments... some responses
inline:

> ? the mobile node SHOULD initiate a correspondent binding procedure for 
> each node that already appears in the mobile node's Binding Update 
> List."

So, you can start RR at this time.

> Agent, a Binding Update can be sent to the correspondent node."

Sending a BU to a CN requires the completion of both the RR procedure
and the home registration (including getting an answer).

> the BA provision of (2) should be removed.

Perhaps, but they are not in conflict as such. (1) talks about the
condition for starting RR, and (2) talks about the condition to
send the BU to the CN. It is true that the RR might be a no-op if
the necessary tokens are already avaiable.

> This is optimistic, but not excessively so. If HA is temporarily 

I agree with this.

> HA is running DAD for the HoA, but this is a rare case.

So, you want to make it slightly more optimistic, i.e. allow even
sending the BU to the CN before the home registration is assured
to be complete?

> of home binding. Is that deliberate?

This looks like a bug. I think we want it to be the lifetime of the
home binding.

> prolonged by the exponential backoff on HoTi rexmit. Was that the concern?

I don't think so. I think the protocol first required home registration to
be fully completed before you started any corresponding binding procedures.
But then we added some parallelism -- and now you want some more...

> Should the "can" in (2) be "MAY" | "SHOULD" | "MUST" ?

MAY sounds appropriate.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 18 Feb 2003 12:15:52 +0200

I have thought some more about this. Here's a few observations:

*  In the usual case -- not first registration, packets not reordered
    or dropped -- the behaviour is the same whether the current
    or Greg's even more optimistic scheme is used. The order of
    packets in the MN is likely to be the following:

       ---> Home BU
       ---> Hoti (optional)
       <--- Home BA
       <--- Hot (optional)
       ---> Correspondent BU

   Why is the order like this? Its Home Test and -Init messages
   have to take a longer route, whereas the BU is answered from
   the home agent directly. Secondly, if the order was different,
   the tunneled hoti would not satisfy checks required from the
   home agent, and the hot would be tunneled to the wrong place.

* In the first registration where DAD has to be invoked it is
   likely that we have to wait for the BA. However, in this case
   the tunnel is not set up yet, and the hoti and/or hot messages
   may be lost, and have to be retransmitted after the BA arrives.

   On the other hand, as Greg notes, this is a rare case and probably
   not worth optimizing.

* If the home cookie has been cached the correspondent, the
   BU could be sent sooner. If we allowed it. This has an
   impact for fast movements.

* If the home address has somehow gotten deprecated, removed
   etc. the current rule about waiting for the BA ensures that
   bad home addresses are not entered to the CNs. On the other
   hand, this can only happen for a short period of time, assuming
   the MN had an existing binding at the previous location.

So what should we do about this issue? I think it is clear
that we will fix the nits that Greg complained about. Change
"home address" to "home registration" in Section 11.7.2 at
"... Lifetime field sent in the Binding Update SHOULD be less
than or equal to the remaining lifetime of the home address
and ..." Also, in 11.7.2 change "can" to a "MAY" in "...
a Binding Update can be sent to the correspondent node".

I'm undecided about what to do about the wait-for-the-BA rule.
Its pretty late in the process to add optimizations... on the
other hand a clarification of this rule would make fast handovers
significantly better. Here's one potential text suggestion if
we want to do the change. This text tries to ensure that we
don't inject bad information to the correspondent nodes.

    Upon successfully completing the return routability procedure, and
    after receiving a successful Binding Acknowledgement from the Home
    Agent, a Binding Update MAY be sent to the correspondent node.
    Alternatively, the Binding Update MAY be sent immediately, if the
    following conditions are fulfilled:

      o  The mobile node already has a registration for the
         given home address at a previous care-of address.

      o  The mobile node can reuse recently received keygen
         tokens as described in Section 11.6.1.

      o  The lifetime in the Binding Update sent to the correspondent
         node does not exceed the lifetime of the previous
         home registration the mobile node had.

Jari

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 19 Feb 2003 02:33:12 +0100

Jari Arkko wrote:
> that we will fix the nits that Greg complained about...

Agree that the nits should be fixed, yes.

> Its pretty late in the process to add optimizations... 

Agree. I'd vote for putting this optimization off for later. I see Greg
is ok with this.

-gabriel