Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11

From: [email-masked]
Date: Tue, 4 Dec 2001 14:57:33 +0200

Hi,

It's not plain API issue because it relates to the handoff decisions and
mechanisms. Is there any WG that is working with this?

- Dan

> -----Original Message-----
> From: ext James Kempf [mailto:[email-masked]]
> Sent: 04. December 2001 13:38
> To: [email-masked]
> Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11
> 
> 
> Dan,
> 
> There is an issue with comparibility. How would one compare, 
> say, signal
> strength measurements for 802.11 with
> those for GPRS (presuming one could get that information from GPRS)?
> 
> Also, I don't think this is a protocol issue, it is more of an API
> issue.
> 
>         jak
> 
> ----- Original Message -----
> From: <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, December 04, 2001 3:25 AM
> Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11
> 
> 
> > Hi,
> >
> > One comment below.
> >
> > > -----Original Message-----
> > > From: ext James Kempf [mailto:[email-masked]]
> > > Sent: 04. December 2001 12:58
> > > To: [email-masked]
> > > Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11
> > >
> > >
> > > Karim,
> > >
> > > The MN in 802.11 does a reassociation without any trigger to
> > > Layer 3, at
> > > least, that is how it currently works.
> > > One could make the modification you suggest below, however,
> > > it would be
> > > a change in the way the 802.11
> > > protocol works. If you simply modify the driver to look at signal
> > > strength, then deliver a pre-Layer 2 trigger
> > > based on that, the MN may very well decide to move to 
> another Access
> > > Point if the signal strength of that
> > > AP meets the criteria. As far as I understand, there is no
> > > way given the
> > > current 802.11 protocol to fix the new AP in advance of 
> the Layer 2
> > > handover.
> >
> > This could be great help for vertical handovers also. The l3 would
> know the
> > different l2 technologies and be able to compare them, 
> choose the best
> > according to the settings (policies). This is the approach that
> Dynamics -
> > HUT Mobile IPv4 has taken.
> >
> > Just think for example GPRS, ethernet, wlan, bluetooth and infrared
> > together: many possibilities, different characteristics and 
> different
> costs.
> > It would be nice to have a standard way to compare these possible
> > connections... and use them according to the settings of the user.
> >
> > - Dan
> >
> >
> > > At best, given current 802.11, one could imagine delivering a
> > > pre-Layer
> > > 2 trigger as soon
> > > as the MN sent the 802.11 reassociation message (the Link
> > > Down trigger),
> > > but this would not give Prereg
> > > enough time to complete any messaging through the old AP.
> > >
> > >                 jak
> > >
> > > ----- Original Message -----
> > > From: "Karim El-Malki (ERA)" <[email-masked]>
> > > To: <[email-masked]>
> > > Sent: Monday, December 03, 2001 2:06 AM
> > > Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11
> > >
> > >
> > > > James,
> > > >
> > > > Why does draft-ietf-mobileip-lowlatency-handoffs not support
> 802.11?
> > > > PRE-REG can be applied to 802.11 using the mobile-initiated
> > > part with
> > > > a mobile trigger. The mobile trigger in this case would 
> likely be
> > > based
> > > > on signal strength measurements in the MN and the FA
> > > address could be
> > > > embedded in the beacon. So I disagree that low latency 
> needs to be
> > > fixed
> > > > for 802.11. What you may have intended is that POST-REG as it is
> in
> > > the
> > > > draft cannot be used with 802.11, but low latency has a
> > > solution which
> > > > can be used for 802.11 already.
> > > >
> > > > /Karim
> > > >
> > > >
> > > >  > -----Original Message-----
> > > >  > From: James Kempf [mailto:[email-masked]]
> > > >  > Sent: den 3 december 2001 00:57
> > > >  > To: [email-masked]
> > > >  > Subject: [mobile-ip] IPv4 Fast Handover Support for 802.11
> > > >  >
> > > >  >
> > > >  > Folks,
> > > >  >
> > > >  > As some of you may have noticed,
> > > >  > draft-ietf-mobileip-lowlatency-handoffs-ipv4.txt does not
> > > >  > support fast
> > > >  > handoff for the current 802.11 MAC. While the 802.11
> > > spec is always
> > > >  > subject to change, it may take awhile and the IPv4 fast
> > > >  > handoff work is
> > > >  > supposted to be immediately deployable. We've done a short
> > > >  > proposal for
> > > >  > how to support fast handoff for 802.11 as it currently
> > > >  > exists, it's at
> > > >  > http://geocities.com/kempf42/draft-kempf-mobileip-postmit-han
> > > > dover-00.tx
> > > > t, it fits into the existing
> > > > low latency framework fairly smoothly. Sorry we 
> couldn't get this
> in
> > > on
> > > > time, but we just figured it out in the last couple days. This
> > > proposal
> > > > also has some other uses, re the low latency draft, and it
> > > is just to
> > > > get the conversation started about how to fix low latency for
> 802.11
> > > > (that is, we don't necessary expect the WG to accept it as
> > > is, but we
> > > do
> > > > want to get the problem solved).
> > > >
> > > >             jak
> > > >
> > >
> >
>

---

From: "James Kempf" <[email-masked]>
Date: Tue, 4 Dec 2001 13:11:18 -0800

I guess I don't see why it being related to handoff decisions and
mechanisms as being not an API issue. There is only
a protocol issue if there is some need to communicate between the
network elements. Deciding which of n interfaces
to handoff to on the MN based on signal strength data doesn't involve
communicating between network elements.
Actually causing the handoff to occur might.

The MIP group is workong on the handoff mechanisms. Seamoby is
discussing candidate access router discovery. But
the actual decision is a policy issue that is not being discussed, since
it is up to the network operator to decide how they
will choose the target access router.

                jak