Subject: [MOBILE-IP] handover

From: Roberts Phil-QA3445 <[email-masked]>
Date: Mon, 24 Apr 2000 15:56:03 -0500

Hello folks,

         I'd like to raise the issue of working on support of fast handover
for cellular systems that use Mobile IP for mobility at the handover level.
We had some discussion about whether to add this to the charter before
IETF47 and then we had 4 drafts on the topic which we discussed during the
meeting.   I'd like to propose that we add support of fast handover for
cellular systems to the charter.

        We need to set some parameters for the discussion.  We do not want
the working group to get tangled up in link layer issues.  There are several
radio access protocols supporting differing kinds of cellular systems and
it's just beyond the scope to start standardizing carrying around specific
information for those protocols in mobile IP messages or developing
interfaces to all of those systems.  It seems that the approach we would
want to take is to design a mechanism to support fast handovers in IP and
mobile IP such that those systems could use the IP and mobile IP messages
knowing that the support is there but that IP and mobile IP don't depend on
using features that are specific to one of those systems.  I would call this
a kind of bottom-up approach to solving fast handover.  We also do not want
the working group to be doing overall design of IP based cellular systems.

         During the discussion there was also concern that we not develop
anything that won't work with other kinds of technologies.  One would like,
for example, to be able to use the same methods to go between access points
in a cellular system and go from a cellular system onto a wireless LAN.

       So I'd like to propose this as a new item in the charter:  'Develop
an access technology independent method for supporting low latency handover
between access points within a system or across systems.'

---

From: Vincent Magret <[email-masked]>
Date: Tue, 25 Apr 2000 10:43:54 -0500

Hello,

I like the idea although I believe that link layer interaction can play an
important role and might even boost the overall performance of the solution. So
I just wanted to clarify what is behind the technology independent method.
Having the IP layer capable of knowing whether a mobile node as left or entered
an area might be somehow useful, but how this IP layer got the information is
more a problem of implementation rather than standardization. My point is that a
fast hand-off solution can be investigated taking advantage of link layer
without getting in the standardization of a mapping for every technology.
I think that the group should work on the definition of events (if we can called
them like that) sent by the underlying layer informing the IP layer of change in
the current configuration (e.g. entrance of a new mobile node in a cell). Those
events could trigger specific actions in mobile IP protocols (macro and micro).

Regards,

Vincent.

---

From: Gerald Maguire <[email-masked]>
Date: Tue, 25 Apr 2000 18:53:51 +0200

Unfortuantely many of the factors upon which a mobile might make a
decision concerning handoff are not associated with a discrete
event. For example, consider the case of being between two WLAN access
points and the decision of when you should make a handoff, you might
want to consider the SNR of each access point, the currently available
capacity of each access point, the peak available capacity of each
access point, ... -- none of these is associated with a simple
discrete event. One of the problems which has plagued me since the
early 1980s has been that most of the handoff code is only invoked
when you loose contact with the access point that you are using (since
this is such a nice easy event to trigger on) -- however, you now have
to do a whole lot of operations all of which contribute to the
handover delay -- but if you could start some of these operations
_before_ you were forced to, then you can greatly reduce the handover
delay.

For details of some of these optimizations you should look toward to
licentiate theses which will be defended this spring, one by J-O Vatn
and the other Jiang Wu, both of the department of Teleinformatics at
KTH. {I'm not their principal advisor, but am their secondary
advisor.} The first of these students has shown want can be done for
unicasts and the second has examined the multicast case. The bottom
line is that many of the operations which took many seconds of time
can be reduced to 10s or 100s of ms. In fact, J-O Vatn's results show
that detecting the availability of a new link or the failure of a link
is becoming the dominate part of the handover delay for unicasts.

Chip

---

From: "C. Perkins/D. Reese" <[email-masked]>
Date: Tue, 25 Apr 2000 10:19:12 -0700

Hello Chip,

>       ......           One of the problems which has plagued me since
> the

Some time ago at IBM we implemented "Eager Cell Switch" (ECS)
and found that it had a LOT better performance.  That was the reason
I tried to make sure that RFC 2002 "allowed" this behavior, if only
by violating a "SHOULD".  It does not violate any MUSTs.  Tracy
Camp did a paper on this which I have somewhere around here, but
 don't know if it ever got published.  I still think it's a lot better
than
"LCS" (Lazy Cell Switching).

Regards,
Charlie P.

---

From: Gerald Maguire <[email-masked]>
Date: Tue, 25 Apr 2000 19:42:29 +0200

Charlie,

I remember the paper (or at least discussion about it), unfortunately
most of the people building hardware devices (and drivers) still have
not made it easy to support such behavior.

I think you will like these two theses as both students have done a
nice job. {Of course I'm perhaps biased since I'm a co-author with J-O
on his first paper which looks at speeding up DHCP (for example,
checking IP addresses in the background and thus being able to hand
out a new address quickly -- as you have already checked for
conflicts).} They should both be published in about 2 weeks -- as they
have gone for approval to defend today or early tomorrow.

In addition, my student, Joe Mitola III will have his dissertation
defense on 8 June with a superb thesis on Cognitive Radios (this
builds upon his earlier work on software defined radios).

I hope you are still enjoying Nokia.

Cheers,
Chip

---

From: Jim Bound <[email-masked]>
Date: Tue, 25 Apr 2000 23:34:54 -0400

I think this work is very important to add to the charter.  The reason
is that I think (and hearing from WAN Wireless Suppliers) that for GPRS
and 3GPP the handoff and authentication will not be done via Mobile IP
and our other mechanisms initially, but use the existing mechanisms.
We need to understand this for us implementors and those implementing
whats needed per pilc work for IP, and I think there will be specific
implementation valves shut off for MIP for the above business
opportunities.  Also pilc has ignored UDP and it has its own set of
issues as more apps will bang on UDP much harder for wireless and VoIP.
One could view UDP as stupid I guess, but not this implementor, and it also
needs to run faster for wireless too.

So what MIP (v4andv6) valves are shut off (or suspended) if hand-off is
not used?  Could be a Mobile Implementor WG too as we don't want to alter
the standard set IMO.

Also I strongly believe MIP celluar must be done here in the IETF.  This
is where IP over anything should be done and also where the IP
implementors and IP wizards live.  Not in other standards forums.

My .02cents,
/jim

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 26 Apr 2000 13:17:24 +0900

Here are my 2 cents:

  It seems that there are what I call bulls who believe that

fast handover IS in the Mobile IP WG's mandate so the group should continue

its standardization activity and consider the new proposals such as Regionalized Registrations,

HMIPv4/v6, UMIP, EMA, possibly others (including the L3 paging?).

If I understood correctly Phil Roberts is on this side.

  There are also what I call bears who believe that the present standards RFC 2002bis, MIPv6 Draft

together with Route Optimization Draft are all we need. The rest is probably an implementation issue

and there already are so many (see Motorola email, I think that Ericsson too has deployed) implementations of

Mipv4 clients.

If I understood well Charlie is on this side. But then I do not understand why he coauthored the Regionalized Registration draft.

  If my opinion counts I vote on the bulls side.
--
Behcet Sarikaya
Computer Communications Lab.
The University of Aizu

---

From: Jim Bound <[email-masked]>
Date: Wed, 26 Apr 2000 00:39:27 -0400

I am a bear............
But can be convinced to be a bull if I see the right technical arguments
which I have not thus far.  It is an implementation issue.  And I doubt
smart implementors will wait for the IETF process to standardize the
bull stuff.

/jim

---

From: campbell <[email-masked]>
Date: Wed, 26 Apr 2000 01:33:16 -0400

Hi Jim:

I liked your comments but ..

I think its all about the definition of an
"open wireless signaling API" to
expose the state and controls of the wireless
link layer to the higher layers?

Forgive me, I'm off on a tangent for a moment:

There is a problem with the discussion so far.
Handoff is like QOS. Some link layers
can do neat stuff (assure delay) others are flat best effort.
Making MIP dependent on any strong QOS (bear with my analogy for
a moment or read: link layer, handoff scheme,
SNR, etc.) is not the way to go.

MIP is not morphing into GSM, W-CMDA, cmda2000 and it would be
dead wrong to bind or strongly couple these layers. One
would like very loose coupling; if one MIP "cellular" service
provider wants to use the API for a stronger coupling
that is fine. But lets not dictate it to be X type.

Back to my QOS analogy again:

For the that want to integrate link specific details
or control into MIP it will be OK if its ATM-everywhere again,
but in the real world we will have multiple wireless link layers
with multiple signaling schemes for a variety of
handoff approaches. No winners. In fact best effort is
the winner today?

Coupling MIP to any one approach scheme is deadly call it
cellular, 3GPP2, ad hoc, PAN, etc. Rather, we should define an
open wireless signaling API between the wireless link and MIP layers.

That API should capture all the bells and whistles in
a generic sense that MIP "could" not "should"
utilize to better exploit the underlying link,
e.g., drive fast handoff using GSM style or Cellular IP schemes.

I think the format of this open API is the real debate here.
If all the vendors from WLAN to GSM to cdma2000 to Bluetooth
agreed on the definition of such API then the "OS" can
export it to MIP to use and program.

Lets leave MIP be! What is this API and how do various wireless
link layers export their capability
to it. And hoe does MIP and other mobility protocols (e.g., HAWAII)
use that API to meet specific requirements.

Apologies for the plug; one example of such an
API is bundled in the Mobiware code.

In Mobiware we use the concept of this API to access the
SNR of packets and beacons and to program beacons to
carry IP addresses and the available resources (i.e., bandwidth)
of the forward base stations. A Corba API was built on one given to
us by those extremely nice Lucent fellows in Europe.

As I said the API is bundled in the source code release
and is one example of letting MIP (in this case Mobiware)
access the capability of the wireless link - but maintaining
independence from the link. The code is here:

  http://comet.columbia.edu/mobiware/

This work let to the idea of programmable handoff.
But I'll stop there.

Andrew

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 25 Apr 2000 22:05:48 -0700

Hello Behcet,

You can count me as a "bull".

> If I understood well Charlie is on this side. But then I do not understand
> why he coauthored the Regionalized Registration draft.

I am interested in Regionalized Registration because I think
it offers a very good method for reducing registration traffic
back to the home network.  And, I think that such registration
traffic can, in many circumstances, be an impediment to the
ability for large numbers of mobile nodes to move quickly in
distant domains.  Having said that, however, I note that the
regionalized registration draft is very much like RFC 2002(bis)
except that the target for the registration traffic has been
moved closer to the mobile node.  Thus that draft has a ready
made security model and mostly intuitive other features.

Regards,
Charlie P.

---

From: Jim Bound <[email-masked]>
Date: Wed, 26 Apr 2000 22:00:51 -0400

hi andrew,

thanks for the pointer to the mobicom which I had seen previously. I
think an informational API is good idea.  I am not a big fan of
anything other than sockets or sysctl or ioctls though.

if an api does result out of all this it should be very basic and based
on extensions to the bsd socket apis and informational in the ietf context.
see mail I sent pat.

where are you with the link-layer spec idea?

thx
/jim

---

From: Amanda Walker <[email-masked]>
Date: Thu, 27 Apr 2000 16:56:38 -0400

> open wireless signaling API between the wireless link and MIP layers.

I would not even constrain it to wireless link layers.  Wireless does
involve a set of the hardest problems in MIP, but applying link-level
information into MIP policy is a general problem.

Here's a quick example quite removed from the cellular case: A laptop with
Ethernet and IEEE 802.11, sitting on my desk at work.  Someone working in
the phone closet accidentally unplugs my Ethernet jack.  It would be
*really* nice if the link layer provided a "down" notification of some sort
to MIP, which then could handoff to IEEE 802.11, and then back when the
Ethernet interface said, "hey, I'm up again."

> I think the format of this open API is the real debate here.

I agree. And it's one where being too specific or too abstract are both
pitfalls.

Amanda Walker <[email-masked]>
Lucent Technologies InterNetworking Systems

---

From: John Emmert <[email-masked]>
Date: Fri, 28 Apr 2000 09:40:48 -0500

>smart implementors will wait for the IETF process to standardize the

I have to agree with you about the not waiting part. I've already got MIP
on my Nextel phone. At least to us, for the time being, the bull discussion
is a moot point. It's already deployed and working. Not that we would
ignore any standards released in the future, but we aren't waiting for them.

John Emmert
Motorola iDEN
Packet Data Optimization Engineer