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

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 28 Mar 2002 18:24:22 +0100

James, 

  > The problem is more complex than just using IAPP as a 
  > trigger for fast
  > handover. The current working assumption of 802.11f is that fast
  > handovers for voice can be supported using reactive 
  > handover. That is,
  > the new access point does the IAPP transaction with the old 
  > after the MN
  > has moved rather than the other way around. We've measured 
  > L2 handover
  > times at from 90-200 ms with existing products, the IAPP 
  > transaction +
  > reactive MIP handover would need to be added to that, and they are
  > additionally proposing adding security to IAPP. Since total 
  > (L2 + L3)
  > handover time must be under 40 ms for voice (if you want to 
  > support it),
  > their current model of reactive handover is probably not 
  > going to get
  > anywhere near supporting voice.

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

  > 
  > In fact, I think it unlikely that 802.11 could really benefit in any
  > significant way from the fast handover work in the MIP 
  > group, given the
  > L2 performance of existing products and the current 802.11f 
  > efforts to
  > have the APs use IAPP posthandover, regardless of whether 
  > it is possible
  > to implement a nonstandard mobile-based trigger.

=> I don't understand why PREREG is not considered
a solution here? We always assumed that IAPP is
not relevant. 

  > 
  > So, we are trying to convince the 802.11f WG to change from 
  > a reactive
  > to a proactive model. This would defined a standardized way 
  > for the AP
  > to issue a prehandover trigger to the router or MN to get a 
  > prehandover
  > trigger based on power levels, and for the AP to initiate the IAPP
  > transaction with the new AP prior to the MN moving. There 
  > is some work
  > going on at U. Maryland to measure 802.11 L2 handover times and
  > hopefully this will give the 802.11 group some data to base 
  > modifying
  > the basic L2 handover protocol if needed, and for vendors 
  > to get some
  > baseline to improve their products.

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

  > 
  > As to how likely they are to accept this model, I think it 
  > is probably
  > no more difficult than trying to persuade an IETF WG to accept
  > something, and they are certainly motivated since they want 
  > to support
  > voice. 

=> Well, I suppose the concept of designing a new
cellualr system will be exciting for them :) :) 
Good luck! 

At the worst, we will be able to convince them they 
  > either need
  > to provide some standardized support for fast handover or 
  > give up the
  > goal of supporting voice.

=> There is another alternative, tell them that
there is a draft here that they can at least read
first.

Hesham

---

From: "James Kempf" <[email-masked]>
Date: Thu, 28 Mar 2002 10:45:53 -0800

Hesham,

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

> a solution here? We always assumed that IAPP is

It doesn't matter which fast handover algorithm is used, if the IAPP
transaction takes, say, 200 ms to complete and the L2 handover takes 200
ms to complete before the MN is allowed to get new packets through the
new AP, then any optimization at Layer 3 will  be in the noise. I wasn't
making a point about PREREG v.s. POSTREG, I was making a point about how
the assumptions being made by the 802.11 committee are causing both
algorithms to be not useful.

> by the WG will ever be used!

Please stay calm, Hesham.

"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. Also, I believe
they are thinking of using it for flushing the ARP cache.

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,
and have him brief you on the details. Also, take a look at the 802.11f
IAPP spec, http://grouper.ieee.org/groups/802/11/ and browse from there.
If you see something that he and I have missed, then  please let us
know. We are just trying to convince them that their protocol needs some
work if it will properly support fast IP handover.

                jak