Subject: [MOBILE-IP] Route Optimization draft comments

From: Karl Freter <[email-masked]>
Date: Mon, 15 Nov 1999 15:35:16 -0600

Charles, Dave - Upon learning that the Route optimization draft
(draft-ietf-mobileip-optim-08.txt) was being put to last call, I've reviewed it
and have a few comments/concerns.  I've not been involved in the history of this
draft, so please forgive me if these issues have already been raised and/or
resolved.  I also would like information on how to get my email address onto
this mailing list ([email-masked]).  Please let me know if you know the
procedure.

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.

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.
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.  Thus, it knows the full set of all nodes
that may be using a binding cache entry for routing packets.  The HA can also
determine from the Registration Request message that a MN is changing FAs.
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.  It would also simplify the MN processing, as (a) it
would not need to maintain a list of nodes it requested binding updates for, (b)
it would not need to worry about Previous FA Notification extension processing
nor binding update messges for the ack failure legs discussed above, and (c) it
would not require a MN/FA security association (which will be painful to
maintain until a standard dynamic key assignment process is adopted).

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.

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.

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

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?

Thanks,

Karl Freter
Manager, Wireless System Architecture Group
3Com
847 222 2268
[email-masked]

---

From: Matthew Cheng <[email-masked]>
Date: Mon, 15 Nov 1999 17:16:04 -0500

I have one more question about the route optimization draft:

It seems to me that the smooth handoff for a MH moving back to the home
network is not described. Should the previous FA be notified (via Binding
Update) by the HA to tunnel in-flight packets to the HA, which then detunnels
the packets and forwards them to the MH? If so, the in-flight packets will not
be lost. Besides, the binding cache at the CH can be updated in time as the
previous FA can warn the HA when receiving the in-flight packets, in case the
MH has not included the Binding Warning extension in the registration.

Any comments? Thanks.

Matthew
----------------------------------------------------------------------
Matthew Cheng, Research Scientitst
Wireless Next Generation Network Research
Telcordia Technologies (formerly Bellcore)
NVC-3X315, 331 Newman Springs Road, Red Bank, NJ 07701-5699, U.S.A.
Tel: +1-732-758-2897, Fax: +1-732-758-4372, Email: [email-masked]