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

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 2 Apr 2002 10:34:51 +0200

James,

  > > => Which is exactly my point. IAPP is not relevant here.
  > > The only way to do it in WLAN (at least so far) is to
  > > make sure that the MN initiates the handover
  > > based on internal triggers.
  > >
  > 
  > If the vendors build IAPP into their APs and 802.11 
  > handover is designed
  > to require a secure IAPP transaction to complete before the 
  > new AP lets
  > the MN send packets onto the new link, then this will 
  > lengthen 802.11
  > handover out considerably beyond the rather poor performance of the
  > current round of AP products. Regardless of what the MN 
  > does prior to
  > handover. So I think it is very relevent indeed.

=> I think there is something missing in our
communication. I didn't think IAPP will run
between subnets, is this correct? If yes, then
this is something for IEEE to work out. 
Like all other L2 designers, they will do their
best to minimise their L2's handover time.

  > 
  > > => James I don't understand why or how you can do that.
  > > Unless you have connection oriented l2s with the MN
  > > reporting measurements to the APs, you can't
  > > do it. Is IEEE going to design a cellular network
  > > now?
  > > Even if this happens, are we going to run IAPP
  > > between subnets?? Even if we do that, wouldn't
  > > there still be some interruption from the time
  > > IAPP does its thing, till the MN actually moves?
  > >
  > > The level of complication is astounding and frankly
  > > I don't understand why you would want to do that.
  > >
  > > If people within the WG keep ignoring the work that this
  > > WG is doing, then I agree, nothing produced
  > > by the WG will ever be used!
  > >
  > 
  > Please stay calm, Hesham.

=> I am calm, asking a lot of questions does not
mean I'm hysterical.

  > 
  > "We" are not going to run IAPP, that is what the 802.11 
  > committee wants
  > to do. The problem IAPP is supposed to solve is to tell the 
  > old access
  > point to unallocate buffers and clean up other data structures
  > associated with providing the MN with IP connectivity. Onto 
  > that, there
  > has been additional stuff loaded, like context transfer. 

=> OK I understand this, but I'm trying to understand the 
relevance to IP handover, which is what we care about here.
If this is only running within the same subnet, then
it shouldn't matter to us.

  > I'd suggest that if you have some interest in seeing the right thing
  > done, you contact Bernard Abboba who has been  monitoring 
  > them closely,

=> Thanks. 

Hesham

---

From: "James Kempf" <[email-masked]>
Date: Tue, 2 Apr 2002 08:48:05 -0800

> best to minimise their L2's handover time.

Yes, IAPP will run between subnets. That is why they use IP rather than
802 for it. That is also why we are concerned about it.

The underlying problem is that the architecture on which the 802.11
committee is basing their design does not include routers. They have a
notion of an ESS (Extended Service System, I think) but it has no notion
of IP subnets.

            jak

---

From: "Santhosh K. Pilakkat" <[email-masked]>
Date: Thu, 4 Apr 2002 00:25:28 +0800

Just noticed this thread of discussion.

Not sure everybody is on the same page about the 802.11 ESS (Extended
Service Set), that is 802.11 systems that have more than one Access Points
but all have the same SSID (network name). 802.11 calls the interconnecting
medium as DS (Distributtion System), which consists of the Access Points,
the interconnecting medium and a Portal. 802.11 specifies only the functions
of these elements and hence IP or any other protocol can be used to
inter-connect the entities and deos not matter whether there are
routers/subnets or not as long as frames can be transported between the end
points (e.g. encapsulated in UDP). In ESS all AP's does not bridge the
ethernet frames from the Stations to the IP network, instead only the Portal
bridges them. That is the entire ESS (all stations attached to all APs of
ESS) appears to be on the IP subnet to which the portal is attached.

In the case where IP is used to inter-connect APs (the normal case), the IP
addresses of APs are used only to forward the ethernet packets (porbably as
UDP packets) from AP to portal, which sends it out. (Or if the destination
is another Wireless STA in the same ESS, to the AP to which it is
associated).

The result is that:

1.    The entire ESS appears to be on the same IP subnet (the subnet to
which the portal is connected), even if the AP's are connected to different
subnets.

2.    802.11 takes care of mobility between AP's of same ESS. As long as the
Old and New AP's belong to the same ESS, the IP address of Wireless Station
remains
the same. That is from Mobile IP point of view, the station has not moved.

3.    Reassociation may not be useful as a trigger as in this case the
Station is attaching to another AP of same ESS. To the IP network it has not
moved.

4.    The only point when the IP point of attachement for a Station changes
is when the managment entity finds that current AP signal is weak and after
scanniing finds that there are no other AP's of same ESS that it can attach
to. In this case the device needs to
either attach to any other ESS or get disconnected.

        If it is going to disconnect the trigger is not useful.

        AFAIK the current drivers does not successfully log on to the new
ESS (at least LINUX, not sure of  MS), as this needs triggerring of  DHCP to
get and configure the new IP address. Even if this can be implemented, the
station is going to get the ESSID and MAC address of the target AP, where as
what we need is the IP address of the Access Router to which the Portal is
connected.

One of the reason for confusion I believe is that most initial deployments
of WLANs used IBSS mode which was intended for adhoc networks, where each AP
does bridging. And moving from AP to AP infact means movement of Mobile
Node. In this case however there is no relation between APs and IAPP etc.
does not apply.

In conclusion:

    Mobility between APs of same ESS is handled by the 802.11 transparent to
the IP layer, even when the APs are physically connected to different IP
subnets. If there is a latency issue, then only 802.11 can address it.

        The mobility and latency to be addressed by Mobile IP is when
stations are moving from one ESS to another.

[Wasn't following the list closely of late. May be some of the above may be
out of context or plane inaccurate and sorry for the long mail. But hope the
above is helpful.]

Regards
Santhosh