Subject: Re: [mobile-ip] FMIPv6 protocol changes

From: "James Kempf" <[email-masked]>
Date: Wed, 9 Jul 2003 11:55:01 +0200

> > In that vein, I would suggest an additional change: dropping tighly
> > coupling unsolicited PrxyRtAdv with handover in support of network
> > controlled handover. The problem is that if the handover is truely
> > network controlled (i.e. the mobile has no say in when it moves at
> > Layer 2) having predictive information doesn't help accelerate the
> > FBU
> > because the mobile can't control keeping the old link stable long
> > enough to make sure that the FBU/FBack sequence is sent and received
> > without error. We've done lots of experimental work on this, both for
> > FMIPv4 and FMIPv6, on a variety of wireless protocols (cellular,
> > WLAN,
> > emulation).
>
> Do not agree : The same problem is encountered if the handoff is
mobile-controlled because the mobile could send the RtSolPr without the
FBU/FBack being sent and received due to further link deterioration

Agree, but that is a reason to drop coupling RtSolPr closely to handover,
not a reason to keep network controlled handover in the spec. The problem is
that with network controlled handover, PrxyRtAdv *must *be sent close to
handover. That means there are three messages to fail if the network hands
over too soon: PrxyRtAdv, FBU, and FBack. So by decoupling
RtSolPr/PrxyRtAdv completely from handover, and only doing mobile controlled
handover, the number of over the air messages required at handover (when
link deterioration is a problem) is reduced to two. That reduces the
possibility that the over the air transaction will fail.

In addition, with network controlled handover, the mobile has no control
over the L2 change, so it can't force the old link to stay up until the
FBU/FBack is complete. FMIP is a poor match for network controlled handover,
because it is subject to disruption by factors that are out of the control
of the mobile.

> Furthermore, network-controlled handover could prevent from additionnal
traffic from MN to the PAR. For example, when the PAR would already have
knowledge that a Candidate NAR does not support Fast handoffs, it could
detect a MN but without sending any unsollicited PrRtAdv. If the handover is
mobile-controlled, the MN will always engage in the procedure with RtSolPr
and therefore, force the pAR to initiate traffic that could eventually lead
to failure of the process.
>
>
> > The other aspect of network controlled handover is that the wireless
> > Layer 2 protocols that support network controlled handover are
> > cellular protocols, and these protocols have little or no interest in
> > FMIP. 3GPP has GTP/GPRS and 3GPP2 has stretchy PPP for fast handover.
> > While one could argue that "future protocols may need support", right
> > now, it is hard to know exactly what sort of support they will need
> > because they don't exist. The FMIP design has benefited enormously
> > from focussing on 802.11 and what can be done with an existing
> > protocol. When the time comes, better to revise the spec when it goes
> > to PS or write another one with support for network controlled
> > handover than to introduce something speculative that may or may not
> > work.
>
> Do not agree: 3GPP may be soon considering using Mobile IP for seamless
mobility between WLAN and GPRS/3G. FMIP could be very interesting to address
the handoff issue when a MN moves from a GPRS-3G PAR to WLAN AR  or
vice-versq

Is there a formal set of requirements from 3GPP specifying that this is
needed? If so, please point me to the document.

BTW, I am not advocating that network controlled handover not be supported
in some way. Our experimental results indicate that having the mobile deeply
involved at L3 is a recipe for a nonepsilon percentage of handover failures,
due to the lack of the guaranteed ability of the mobile to keep the old link
up long enough to complete L3 signaling. FMIP is premised on having the
mobile deeply involved at L3, a protocol that did not have this premise
would not suffer from this defect. So, in summary, I support having a
different protocol to properly support network controlled handover, and
having FMIP be simple and concentrate on what it does well.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 09 Jul 2003 09:46:32 -0700

Eric,

NJEDJOU Eric FTRD/DMR/REN wrote:

> >Rajeev,
>
>
> The feature in section 4.5 of the spec (L2 optimized handover) is very essential i think! I can't see what could better trigger the need for handover than information available at L2.
>

There will be reference to L2 triggers causing handover to
take place. The protocol specification itself will cover IP messages however.

Regards,

-Rajeev

> Eric Njedjou