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

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 15 Sep 2000 13:21:41 -0700

Hello again Francis,

Still catching up...

Francis Dupont wrote:

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

What is that?

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

Can you say more about why?

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

Agreed.

>  - router advertisements are expensive to build, transmit and decode

Can you provide a little more insight about why this should be so?

>  - 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 Mobile IPv6 document allows routers to send out advertisements more
often.

>           Recommended values for these limits are:
>
>    -  MinRtrAdvInterval       0.5 seconds
>
>    -  MaxRtrAdvInterval       1.5 seconds
>
>   Use of these modified limits MUST be configurable, and specific
>   knowledge of the type of network interface in use SHOULD be taken
>   into account in configuring these limits for each network interface.

The actual interval can be set to whatever is needed.  Isn't this
good enough for many handover scenarios?

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

I agree this is a good plan.

> => "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).

Isn't this just a matter of providing needed functionality?
If so, then I'm not clear on why it matters about whether you
call the access router a home agent or a foreign agent.

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

I believe it is an essential part of Mobile IPv6, and always has
been.  Can you mention where it might have been forgotten and
thus needs repair in the specification?

I look forward to your further comments.  I append your original
note in its entirety in case this is so old that you wouldn't
remember the context.

Regards,
Charlie P.

================================================================================

Francis Dupont wrote:
>
>  In your previous mail you wrote:
>
>    > =>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).
>
>    Here is my understanding about the different between fast, smooth and
>    seamless handoff. Please correct me if I am wrong.
>
> => you have forgotten smart handoff (:-)!
>
>    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.
>
> => 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.
>
>    When MN is on idle movement, there is no need to perform fast handoff,
>    since there is no packet loss issue.
>
> => idle movement is "not moving", isn't it? And active is "moving"?
>
>    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.
>
> => 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.
>
>    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.
>
> => 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.
>
>    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.
>
> => "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: Francis Dupont <[email-masked]>
Date: Sat, 16 Sep 2000 16:02:32 +0200

What is that?

=> just a joke (with a smile). In the list there were fast, smooth and
seamless: smart was missing.

=> RAs are too expensive to build, too expensive to send, too expensive
to process. In fact they are not designed for this role and a dedicated
mechanism should be far better when a fast beacon is needed.
I am *really* tired to see people twisting RA timers in order to get
fast handoffs: if there is a good reason to use very special timings
then there should be a good reason to build a dedicated/simpler/cheaper
mechanism. Reuse is not perversion!

=> a RA should have at least one prefix information which is the more
complex extention of ND, very expensive to process because of prefix
timers. And if you'd like to have two kinds of RAs, one regular and
one stripped (I-D 12 6.5 last paragraph is a step in this direction)
then it will be better to have another kind of packets.

=> even if it is fixed in order to have MIN_DELAY_BETWEEN_RAS aligned
with MinRtrAdvInterval (:-) then RAs should not be sent in response of
a RS without a small delay (because there can be more than one router,
in fact the issue is deeper, RS/RA is designed to be multicasted,
this is not good for a poll).

=> prediction: this will never be as fast as some people would like.

   > ... it should be able to change an interface for another ...

   I believe it is an essential part of Mobile IPv6, and always has been.

=> we agree but my fear is not a prediction, just based on facts.

   Can you mention where it might have been forgotten and
   thus needs repair in the specification?

=> no, we need to repair brains (a bit harder :-).

=> the discussion begins by the remark that layer 2 should help
then some examples about layer 3 weaknesses (with in front RAs/beacon)
and what should be done in order to use the layer 2 (you know the
conclusion: it will be a nice thing but it is hard to do it in
a generic enough way, ...)

Thanks

PS: the important point today is to get a working and published spec
for mobile IPv6. Improvements should be done after: we need
foundations, nice stained-glass windows will come afterwards...