Subject: Re: [MOBILE-IP] IPv6 handover document

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Thu, 17 Aug 2000 04:12:13 +1000

Hi Charlie,

Welcome aboard.  I will send you the rough draft by day's end.

=>Thanks, I'll look forward to it.

> I have a question though, is this new document going to be based on an
> existing proposal for fast handoffs in v6 (I'm only aware of our draft) or
> is it a new approach ?

The document is first and foremost a delineation of the issues
and relationships to Mobile IP.

I believe that recent Internet Drafts for IPv6 smooth handovers from
our group here at Nokia will also be relevant.  We propose a SHIN
(Smooth Handover Initiation) destination option, as well as SHREQ and
SHREP, for IPv6.  However, it may be the case that no protocol at all
will be specified in the document under discussion.  I hope at least
to get some consensus from the working group about what should be
under consideration.  If we get a protocol too, then so much the better!
The rough draft so far does not contain any protocol specification.

=>My understanding is that the task that was decided on by the WG in the
"smaller" handoff meeting was to devise a method for Fast Handoffs
that is independant of the access technology.
As far as I understand, the SHIN and SHREQ messages above are triggers
for context transfer. While we decided that this work is important,
it was also seen as something that is not part of the MIP WG charter
and that yourself, Alan and James? would consult with the IESG to find
out where it should be done. So based on this evidence (or at least my
side of the story) I'm not sure how this proposal would fit with the
task allocated by the WG.
The main problem that I understood we're addressing here is the routing
problem.

I also hope to get a clear picture about how to separate fast,
smooth, seamless handovers from regional registration.  The main
idea could be that handovers are purely edge phenomena, whereas
binding updates (e.g., registrations) are mostly not edge phenomena.

=>Yes I think that is important, but also just as important is to
separate fast, smooth and seamless handoffs from each other. I believe
the basic MIPv6 already provides smooth handoffs (as far as routing goes).

I wonder whether "fast restoration" is a handover thing or not (see
Alan's recent note).

I'm sure it is related but I think we need to precisely define what
it means.

---

From: Linfeng Yang <[email-masked]>
Date: Thu, 17 Aug 2000 13:06:58 +0300

> the basic MIPv6 already provides smooth handoffs (as far as routing goes).

Here is my understanding about the different between fast, smooth and
seamless handoff. Please correct me if I am wrong.

I feel smooth handoff and seamless handoff are the same, they describe the
handoff in the way what we want it achieve, i.e., minimized packet loss.
In basic MIPv6 smooth or seamless handoff is achieved through establishing
forwarding from a previous care-of address.

Fast handoff on the other hand describe how we can achieve it. Fast is
compared with basic MIPv6 in the sense that it will overcome the router
advertisement interval limit. Here I schemed one way of Fast handoff, I
call it Link Layer Assisted Fast Handoff.

When MN is on idle movement, there is no need to perform fast handoff,
since there is no packet loss issue.

So MN will start fast handoff process when it is in active movement.
MN will constantly measure signal strength of message received from
current router, if it is lower than some threshold value (t1), MN will
then send a router solicitation message in hope of receiving a router
advertisement. In this way, MN can overcome the Router Advertisement
interval limit, thus speed up handoff process. MN may then receive
more than one Solicited Router Advertisement from neighboring routers.
After compare the signal strength of current router (sc) with the one
received earliest from new router (sn), MN can then decide to perform a
Handoff or not. If (sn + t2) >= sc, MN will perform handoff, otherwise
MN will send another Router Solicitation.  t2 is used to prevent
unnecessary handoff in the "ping pong" like movement within the overlap
of two router domain. After handoff new router becomes current default
router or MN, MN will then measure its signal strength from this router.

We can see this is only local handoff, if accompanied with establishing
forwarding from a previous care-of address, it can achieve even better
smoothness.

Regards,

Linfeng Yang
                Helsinki University of Technology
                Telecommunications Software and Multimedia Laboratory
                P.O.Box 9700, 02015 HUT, Finland
                Phone: +358 9 451 5250           Fax: +358 9 451 5351

---

From: Francis Dupont <[email-masked]>
Date: Thu, 17 Aug 2000 16:57:43 +0200

=> you have forgotten smart handoff (:-)!

=> this is seamless handoff, smooth is based on bicasting.
The mechanism is not exactly the same.

   Fast handoff on the other hand describe how we can achieve it. Fast is
   compared with basic MIPv6 in the sense that it will overcome the router
   advertisement interval limit.

=> to use router advertisements as a beacon is stupid (from a IPv6 person
point of view).

   Here I schemed one way of Fast handoff, I call it Link Layer
   Assisted Fast Handoff.

=> idle movement is "not moving", isn't it? And active is "moving"?

   advertisement.

=> I disagree, if you want to poll a router you should use a neighbor
solicitation:
 - router solicitations are multicasted then they are more expensive
   than unicasted neighbor solicitations
 - router advertisements are expensive to build, transmit and decode
 - routers should wait a bit before sending a solicited router advertisement
   (in order to avoid synchronization of replies)

   In this way, MN can overcome the Router Advertisement
   interval limit, thus speed up handoff process.

=> the less-reachability detection of routers should not rely on router
advertisements, I agree.

   MN may then receive more than one Solicited Router Advertisement
   from neighboring routers.

=> I prefer to use router advertisement in order to get the set of
available routers first and to have a regular measure of the signal
strength in second and in a *passive* way.

   of two router domain.

=> I prefer to have a second threshold: if (sn + t2) >= sc then the
new candidate router should be polled in order to get a fresh sn,
then if (sn + t3) >= sc MN will perform handoff. This is cheaper
and faster than using router solicitation as a hammer and more
powerful than a decay mechanism on signal strength. It can support
multiple candidates too if movement is both active and fast.
 An interesting case is if there are real beacons associated to
routers then signal strengths are available directly.

   After handoff new router becomes current default
   router or MN, MN will then measure its signal strength from this router.

=> MN should keep a list of candidate default routers (RFC 2461) then
it is not so expensive to keep signal strengths too.

=> "forwarding from a previous care-of address" is I-D 12 10.9, isn't it?
This supposes there are enough available home agents (ie. lost of benefits
of the disappearance of foreign agents).

Thanks

[email-masked]

PS: fast/smooth/seamless/smart handoffs are fine but mobile IPv6 code should
support other more traditional usage of mobility, for instance it should
be able to change an interface for another, for instance a GSM/GPRS/UMTS/...
cellular device for a 100Mbits/s Ethernet. This is what makes mobile IPv*
more powerful than any layer 2 solution and we should not drop this in order
to fight with better weapons against layer 2 solutions.
I am afraid this was forgotten by some of us...

---

From: John Emmert <[email-masked]>
Date: Thu, 17 Aug 2000 09:45:43 -0500

>forwarding from a previous care-of address, it can achieve even better

I've seen two solutions to this. Have a FA cover a large geographic area,
thus minimizing the need for changing FAs, and have the FA assigned by a
lower link layer when boundaries are crossed. I think short term forwarding
from a previous FA would be worth investigating. Perhaps a defined interval
that if not renewed is automatically flushed? Ping-ponging problems are
already handled at the lower layers (or they better be). Due to the
inherent unreliability of RF in delivering data without errors, and well
known problems with the error handling routines of IP, the lower layers
better do some error detection and correction as well.

I'm not sure, and in fact am of the opinion, that the lower layers are not
the topic of this group. Really they should be handled by other groups.
This group should give a mobility solution that the other groups can use to
integrate a complete mobility solution, including RF protocol layers.

---

From: Linfeng Yang <[email-masked]>
Date: Thu, 17 Aug 2000 22:01:59 +0300

Hi,

> => idle movement is "not moving", isn't it? And active is "moving"?

Sorry, they are Cellular IP like concept, I expressed them in a too
simplified form.

Linfeng Yang

---

From: Pete McCann <[email-masked]>
Date: Fri, 18 Aug 2000 14:28:03 -0500

John Emmert <[email-masked]> (JE) writes:

>> forwarding from a previous care-of address, it can achieve even better

JE> I've seen two solutions to this. Have a FA cover a large geographic area,
JE> thus minimizing the need for changing FAs,

This is the approach taken by the 3gwireless-ext draft.

JE> and have the FA assigned by a
JE> lower link layer when boundaries are crossed. I think short term forwarding
JE> from a previous FA would be worth investigating. Perhaps a defined interval
JE> that if not renewed is automatically flushed?

Yes!  This is exactly what is proposed in
draft-mccann-mobileip-limiph-00.txt.  I hope everyone reads it!  We
take a "transparent" approach where we assume that the link-layer can
often help us find the previous FA, and the tunnel is established by
the network on behalf of the user.

JE> Ping-ponging problems are
JE> already handled at the lower layers (or they better be).

Unfortunately, the link-layer may provide quite a bit of ping-ponging.
We propose to deal with this through appropriate use of the 'S' bit.

-Pete