Re: [Mip4] Differences between Low Latency Handovers and FMIPv4
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mip4] Differences between Low Latency Handovers and FMIPv4



Henrik,

I'm in support of doing this work. Since MOBOPTS seems to have a lot on its
plate at the moment and MIP4 doesn't, perhaps MIP4 would be the right place.

As Kent mentioned in his email, 802.11 wireless switches now do inter-subnet
handover optimization for "lightweight AP" 802.11 without any need for host
involvment (essentially using a nonstandardized version of Post-reg), so it
is not clear to me how relevant this work is to 802.11. I think it might
make sense to look into bringing the switch vendors into the discussion,
since wireless LAN switches are a large and growing part of the 802.11
market. From a service provider/enterprise customer standpoint, having a PS
RFC protocol for inter-subnet handover on wireless switches would be ideal,
because the switches are shipping product, are being deployed, but are not
interoperable at this level today. Unfortunately, FMIPv4 won't address this,
but it might be useful for other link technologies and for intertechnology
handover.

With regard to Charlie's email about the technical drawbacks of LLH, what
our research found for three different link technology types (simulated
using 802.3, CDMA2K, and 802.11) and with some analysis is that Pre-reg is
nondeterministic for certain deployment and link technology situations, and
we therefore believe it would be very hard to deploy. Post-reg performs very
well when the required link triggers are available (such as on CDMA2K), but
it cannot be implemented on "standalone AP" 802.11 because the link triggers
aren't there (it can be implemented on "lightweight AP" 802.11 because the
wireless switch provides the link trigger and anchor point for the tunnel).
In our research, we implemented an FMIP-like protocol on 802.11 and the
results were good within statistical range for both network-triggered
handover (using the Post-reg and Reassoc.Request() arrival on the AP and a
single AP per subnet) and host-triggered handover (using the FMIPv4 like
protocol).

Note, however, that if one assumes completely decoupled handover at L2 and
L3, as now is apparently the case with "standalone AP" 802.11 due to the
potential for 802.11i/r reauthentication on every AP move, the host must
perform DNAv4 on every L2 handover, which will involve an ARP to the router.
This means that, effectively, there are at least four IP round trips prior
to the MN receiving traffic from the previous FA. Exactly what the impact of
that is on performance-sensitive traffic, such as VoIP, needs to be
clarified.

With respect to the security issue, there is still not a resolution of how
to secure the host to network interaction in FMIPv6, and it is even more
unclear for FMIPv4, particularly in a roaming situation. There are a couple
approaches being worked on for FMIPv6. One approach, on which I am
co-author, uses SEND and therefore is not applicable directly to FMIPv4,
though it could be modified to be so. Another is under development to use
the EAP key hierarchy to derive a handover key, but as yet there is no
written draft in this area.

So, I think this would be a good item for the WG to take up, but I believe
the primary hurdle is security.

        jak



----- Original Message ----- 
From: "Henrik Levkowetz" <henrik at levkowetz.com>
To: "Karim El-Malki (AL/EAB)" <karim.el-malki at ericsson.com>
Cc: "Mobile IPv4 Mailing List" <mip4 at ietf.org>; "Charles E.Perkins"
<charliep at iprg.nokia.com>; "Rajeev Koodli" <rajeev.koodli at nokia.com>
Sent: Friday, March 18, 2005 5:17 AM
Subject: Re: [Mip4] Differences between Low Latency Handovers and FMIPv4


> Hi Karim,
>
> <hat type="chair">
>
>     I think it would be good if we could look at this proposed workgroup
>     item according to its merits, rather than go into its history, where
>     there is a bit of controversy which we don't need to repeat here.
>
>     That the low-latency draft is due for publication as experimental does
>     not preclude other experimental drafts in the same area if there is
>     good motivation for them.  Quite to the contrary, actually - this is a
>     way to improve our understanding and move forward as a community.
>
>     When this work has been discussed in the meetings, there has seemed to
>     be a good amount of interest in it, which makes it a valid candidate
>     for adoption.  So again, let's consider it on its objective merits.
>
>     I'd also like to hear other people's comments on the merits of
adopting
>     this as a workgroup item, and the level of interest there currently is
in
>     this.
>
> </hat>
>
> Henrik
>
>
> On 03/18/2005 12:47 PM Karim El-Malki (AL/EAB) said the following:
> > Hi Charlie
> > I am a bit surprised by the many differences you see
> > between FMIPv6 and Low Latency. In actual fact low
> > latency was written first and most of the stuff was
> > reused when FMIPv6 was first drafted in Madrid (when
> > George was editing FMIPv6). The same pre-reg (updating
> > routing before actual handoff) and post-reg (updating
> > routing after handoff) are still there. I am not
> > against changes in the spec but it took a while to
> > get to a stable document to go out as exp rfc with the
> > purpose of seeing what interest there is. I would hang
> > on to making changes until we know what are the real
> > needs from people (apart from ourselves since we
> > authored these specs) that have reviewed the exp rfc and
> > want to take it a step further.
> > Rgds
> > /Karim
>
> -- 
> Mip4 mailing list: Mip4 at ietf.org
>     Web interface: https://www1.ietf.org/mailman/listinfo/mip4
>      Charter page: http://www.ietf.org/html.charters/mip4-charter.html
> Supplemental site: http://www.mip4.org/
>



-- 
Mip4 mailing list: Mip4 at ietf.org
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.