Subject: RE: [mobile-ip] Administratively enabling and disabling of the route optimisation

From: [email-masked]
Date: Fri, 4 Oct 2002 13:37:13 -0500

>Hello All
>I have a question on administratively enabling and disabling of the route
>optimisation
>
>1>after disabling route optimisation what CN will do with existing binding
>in the binding cache and existing upper layer connection? Should CN
>continue sending packet with type 2 routing header? Or send packet to Home
>address of MN in case binding exist for MN.

Disabling RO should clear the binding cache at the CN, but only after
the lifetime has expired (MAX_RR_BINDING_LIFE). No new requests for RO
or for renewing an existing binding should be accepted.

>
>Also consider the scenario
>Route optimisation is disabled at CN and MN is sending packet with Home
>Address option, when CN receives packet with Home address option it will
>send binding error message with status as 1. Then MN starts RR procedure.
>MN will retransmit HOTI, COTI message and CN will drop the message, as
>route optimisation is disabled, this can be avoided by sending binding
>error message to MN indicating route optimisation is disabled ...what I
>mean is defining another status code for binding error message to report
>route optimisation not supported.

But if you take the approach indicated above, the CN will not delete the
binding cache immediately but instead wait till the lifetime expires and
hence packets with HAO are processed. When the MN tries to renew the 
binding, it fails and packets from the MN will be tunnelled via the HA.
So I do not believe there is a need for another status code.

>Regards
>Arvind
-Basavaraj

-Basavaraj

---

From: Jari Arkko <[email-masked]>
Date: Sat, 05 Oct 2002 08:30:09 +0300

We do require a capability to turn RO on and off. The question is,
what does turning it off exactly mean?

Arvind and Basavaraj presented two possible interpretations.
What I'd like to show below is that the situation is recoverable
regardless of how this is implemented.

First, the CN could remove the current entries immediately. As
Arvind notes, this will lead to a BE message back to the mobile
node. According to Section 11.7.5 in the draft 19 prerelease,
if the MN does not have recent upper layer progress information
it MUST remove the entry and route further communications through
the home agent. Some packets may be lost before the MN realizes
the CN is not listening to the direct traffic. However, communications
can still progress, eventually.

The MN may also retry RR. As Section 11.8 states, few extra packets
be sent but there's a back-off process that prevents too large
amount of traffic. And while we are retrying RR, all traffic goes
through the home.

Secondly, the CN could remove the current entries not immediately,
but when they actually expire. In this case the MN would not see
anything different until it tries to rerun RR and send a new
binding update. This would fail, as the CN would not answer.
Eventually the binding would be removed by the MN. (If there
is clock drift, there might be some lost packets and the recovery
process would be the same as described above.)

In conclusion, the worst that could happen is a few packets
that get dropped. Smart implementations should of course use
graceful mechanisms, such as keeping the current BCE entries
or stopping the use of a binding on the MN side slightly
before it actually expires.

Jari