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

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 16 Oct 2002 11:49:49 -0700 (PDT)

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

It may be implementation dependent. But the draft could specify basic
rules. For example, whether turning off and on of RO feature should
be done at run-time or only at boot-time, depends on the specific
implementation. But, at least the draft should be able to say something
about the behavior of CN when RO is turned off and it receives a BU.

> 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.)
> 

I'd like the second choice when CN does not remove the BCE entries 
immediately, but it can deny accepting new BUs and HOTI/COTI packets
from then on. CN can remove the BCE entries after they expire.
Removing BCE entries for existing MN-CN connections will be very
disruptive to the MNs.

> 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.

However, I think it would be good idea to have a BE status field
which specifically tells the MN that RO service is not available
anymore. Otherwise, MN may send BUs/RRs and not receive response
from CN for other reasons (system down, network problem etc.), in 
this case, receiving an error status would make the MN to take
decision sooner. Particularly the case, when MN was corresponding
with CN with RO, and it then sends another BU for refresh (after
sysadmin at CN had turned off RO), it does not receive any ACK or BE
back--would not MN be confused ?

How about adding a status code in the BE

3   Route Optimization is not operational

This will also distinguish from MIPv6 aware CN and non-MIPv6 CN nodes, when
one sends BE and the other sends ICMP PARAM.

Thanks,
-Samita

---

From: Brian Haley <[email-masked]>
Date: Wed, 16 Oct 2002 15:13:19 -0400

> about the behavior of CN when RO is turned off and it receives a BU.

...

> Removing BCE entries for existing MN-CN connections will be very

It is not fatal however, and the MN will figure out it must reverse tunnel
future packets.  This choice is what I'd recommend as well.

> one sends BE and the other sends ICMP PARAM.

You can just as easily send a Binding Acknowledgement with Status code 129
(Administratively prohibited), which is what we do.  Implementations that don't
understand Mobility Headers will return an ICMP parameter problem already.
Either way, it doesn't matter to the MN, when it receives an error it should
reverse tunnel and not send future BUs.  Sections 11.7.3 and 11.9 cover both
these cases.

-Brian