Subject: Re: [mobile-ip] Mobile IPv6 I-D 18:BA status value

From: Erik Nordmark <[email-masked]>
Date: Thu, 1 Aug 2002 19:18:22 +0200 (CEST)

> 6.1.2. Binding Refresh Request (BRR) Message
> 
>     [...] When a mobile node receives a
>     packet containing a Binding Refresh Request message and there
>     already exists a Binding Update List entry for the source of the
>     Binding Refresh Request, it MAY start a return routability procedure
>     (see Section 5.2) if it believes the amount of traffic with the
>                             
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     correspondent justifies the use of route optimization.
> 
> This means MN judges whether the MN uses RO or not depends
> on the amount of traffic with CN when it receives BRR.

Yes. Just like the MN initially decides when to first initiate a BU procedure,
it isn't required to refresh the binding when it receives the BRR.
The MN can presumably use whatever information it has (amount of traffic,
the type of traffic, the phase of the moon) to determine which CNs it
wants to use RO with at any given time. 
The high level point is that the BRR is a hint that the CN would like to
see the binding refreshed.

> And if the amount is low enough, it sends BA with 136 to the CN?

Sending a BA in response to a BRR seems odd.
I've been assuming the MN would just silently ignore the BRR if the MN
doesn't see a need to refresh the binding. Perhaps this should be made
explicit in the spec?

  Erik

---

From: Jari Arkko <[email-masked]>
Date: Tue, 06 Aug 2002 12:56:59 +0300

> doesn't see a need to refresh the binding. Perhaps this should be made

Yes. Suggested text follows.

Here's a new version of the first paragraph in 9.4.4:

   When a mobile node receives a packet containing a Binding Refresh Request
   message and there already exists a Binding Update List entry for the
   source of the Binding Refresh Request, it MAY start a return routability
   procedure (see Section~\ref{overview:security}) if it believes the
   amount of traffic with the correspondent justifies the use of route
   optimization. If it does not believe this, the mobile node MAY choose
   to either ignore the Binding Refresh Request or to delete its binding
   from the sender of the Binding Refresh Request. Note that the mobile
   node SHOULD NOT respond Binding Refresh Requests from previously
   unknown correspondent nodes due to Denial-of-Service concerns.

We also need to clarify how to use 130/136. My proposal is to
merge the error codes and add the following text to the end of 9.4.2:

    The correspondent node MAY refuse to accept a new Binding Cache
    entry, if it does not have sufficient resources. A new entry MAY
    also be refused if the correspondent node believes its resources
    are utilized more efficiently in some other purpose, such as
    serving another mobile node with higher amount of traffic. In both
    cases the correspondent node SHOULD return a Binding
    Acknowledgement with status value 130.

Jari

---

From: Hiroyuki OHNISHI <[email-masked]>
Date: Wed, 07 Aug 2002 12:06:53 +0900

Hi,

At 12:56 02/08/06 +0300, Jari Arkko wrote:
>>wants to use RO with at any given time. The high level point is that the 
>>BRR is a hint that the CN would like to

I agree to merge the 130/136 error codes because it is difficult for the MN
to use these different code effectively as you mentioned in your e-mail.
But I want to confirm the meaning of second operation [A new entry MAY 
also be refused if .....].
It says that the route optimization is effective to reduce the traffic,
but handling binding cache consumes CN's resources and
the CN does not want to create new binding cache for a MN
with which CN has a little amount of traffic.
So there is a trade-off between the reduction of amount of traffic and
the consumption of CN's resource.  CN MAY decide how to use R.O from
these 2 viewpoints.
Is my understanding correct?

--
Hiroyuki

---

From: Jari Arkko <[email-masked]>
Date: Wed, 07 Aug 2002 10:30:45 +0300

> to use these different code effectively as you mentioned in your e-mail.

Good.

> Is my understanding correct?

Yes. But I don't really want to emphasize the resource consumption
point: RR+RO consumes an extremely small amount of resources from
the CN. Still, in some cases one wants to carefully evaluate the
tradeoff, e.g. on busy servers. The idea is to allow CNs to make
these decisions.

Jari