Subject: Re: [MOBILE-IP] Route Optimization draft comments

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 26 Jan 2000 16:17:57 -0800

Hello Karl,

I hope you can find a way to excuse my extreme tardiness in
responding to your note.  It's been on my list for a long time,
but only now am I able to revise the Route Optimization draft,
and thus to pay attention to these issues.

> The first issue is the number of different methods for updating binding caches
> during a registration.  The draft discusses three means:  (1) The MN sending a
> binding warning extension during the registration request, (2) The MN sending a
> Previous FA Notification extension during the registration request, and (3) the
> MN sending binding update messges if it fails to get a binding ack from the FA
> after sending the Previous FA Notification extension.

The Previous FA Notification extension is designed for smooth handoff.
The Binding Warning extension was requested by engineers from Nortel
who pointed out that the home agent was often well placed to deliver
the warnings.  Lastly, since the Previous FA Notification is basically
a one-shot mechanism to handle the _usual_ case of successful
transmission between wired foreign agents, we did not want to make
the new foreign agent responsible for retransmissions.  This leads
directly to making the mobile node responsible for them.  Furthermore,
if the mobile node does NOT send the binding update, it alone will
suffer whatever the consequences might be.

> I believe these methods are overkill and should be reduced to just the binding
> warning extension (if even that).  I also believe the HA should be required to
> send binding updates when it detects a change in the FA assignment for a MN.

The home agent can be pretty far away from the scene of the action, though.
Furthermore, with regional registration, the home agent wouldn't be involved
at all.

> Here's the rational:  Only the HA can send the initial Binding Update message to
> a node.  It may be in response to a Binding Warning Message/Extension, a Binding
> Request, or done on its own, but the HA is the only point where the initial
> Binding Update messages originate.

This is not true if you like the idea of using Previous Foreign Agent
Notification messages.

> Since I believe there is no reason why one would want to leave a node pointing
> to an old FA (please correct me if I'm wrong), the HA is the perfect point
> during a registration to automatically update all binding caches to all nodes
> via the Binding update messsage.  The HA also knows the old FA, so it could send
> the old FA a small lifetime (and the full lifetime to the other nodes).  This
> would ensure that packets in transit to the old FA would get to the new FA and
> would alleviate all the old FA issues related to requiring special tunnels,
> binding ACKs and data coming before the  Registration Reply, required MN/FA
> security associations, etc.

This just isn't true, if the home agent doesn't even get the Registration
Request until 100ms (say) after the mobile node sends it.  Or, 500ms.
Or, even worse on a bad day.

> I would propose making the HA required to keep track of all nodes it sends a
> binding update to and require that the HA send a BInding Update to those nodes
> and the old FA whenever a MN roams to a new FA.

It would be better to make the mobile node do it, especially if
you believe that communications are more often local than remote.
On the other hand, it would be nice to cut down traffic over the
air interface during busy times like handovers.  On the third hand,
there are many issues involved and it is difficult to make blanket
statements that are always true.

> A second issue is how to handle binding updates for non-routable IP address
> assignments.  The HA can not send binding updates for MNs that are assigned non
> routable IPaddresses, regardless of the Privacy bit setting.  All packets must
> be tunneled throught the HA to the FA.  I believe you want to add this statement
> to the draft.

Right now, the Route Optimization draft doesn't have a lot to say about
private addresses.  The Privacy bit has to do with halting the dissemination
of bindings to third parties, and is not related to the nature of the
home address (i.e., whether it is a routable address).  On the other hand,
I would be happy to add some clarifying text if you will craft a statement
that says what you want to be said.

> A third issue relates to correspondant nodes tunneling data to the FA instead of
> the HA.  If the correspondant node uses GRE, that node must not try to use
> sequence numbers.  Since the FA can get data from any number of nodes (as the HA
> or MN may initiate the binding update without telling the FA), the FA would need
> to setup a sequence number history for each node that tunnels it data.  This is
> not reasonable.  Thus, some words are required to discuss what portions of the
> tunneling protocols are not allowed.  [I did not review the other options, but
> remembered that GRE could pose a problem.]

Again, I would appreciate it if you could craft some appropriate text to
be inserted as needed.  I have not myself used GRE tunnels for this, so
I do not have the experience.  GRE was included as a tunneling option by
other people in the working group.  As far as I know, it has not been tested
for interoperability.  I agree that there should be some implementations and
some testing so that the feature can be kept, but I won't be able to help
much with the task of doing so.

> The last item is minor.  In sections 8 and 8.1, you mention  "Previous FA
> Notification messages".  Shouldn't those really be extensions instead of
> messages?

Yes, that is true.  I'll make the changes.

Regards,
Charlie P.