Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Fri, 1 Dec 2000 10:29:34 +1100

Hi James,

Good point , but I have a question and a comment below.

> I've been told that, while I was offline, there was a discussion of
> whether
> pro-active FA handoff would require co-location of the FA and an 802.11
> access point because of the need for link layer triggers.
>
> In fact, there is a protocol for interaccess point communication in 802.11
> (InterAccess Point Protocol, IAPP) that was presented to the IETF in 1998
> but
> was turned down because it was too 802.11 specific, that, I believe,
> has been picked up by IEEE. This protocol allows access points to
> announce themselves when they come on line, and to send out handover
> information on the wired backbone when a mobile moves from one access
> point to
> another (which the mobile can do in 802.11 on its own). I have an old copy
> of
> the spec if anybody cares to look at it.
>
> An FA that was located away from an access point could tap into this
> information and use the IAPP Handover message as an "L2" trigger to
> determine when an L2 handoff was occuring. This would fit in directly
> to the "post trigger" scenario described in the pro-active draft.
>
        => My understanding of this protocol (correct me if I'm wrong)
        is that it works between APs connected on the same subnet.
        Hence the FA on the current subnet will not be aware of the
        movement of the MN to the new subnet. I realise that you
        mentioned the "post trigger". I assume you mean that after
        the movement, the new FA would tap into the IAPP protocol
        to know the MAC address of the MN that just turned up and
        "somehow" notify the old FA ?
        If that is correct then I have a couple of points to make :

        1. How does the new FA know where the MN came from ?
        Knowing the MAC address doesn't help

        2. Even if somehow the FA can determine this, the handover
        in this cases is not very fast as no anticipation was done
        (as opposed to the case where the current FA knows
        that the MN is about to move).
        So what would happen is:
        a) The MN moves
        b) The FA somehow knows this and knows where it came
            from
        c) The new FA requests forwarding of packets from the old
             FA. In the mean time all packets are not delivered
            or are lost over the old air interface.

        Finally, the use of WLAN was an example of the architectural
        limitation. My point was that there are cases where the FA
        may not have that knowledge (the MNs future movement)
        so in these scenarios a complete network control does not
        help. That is IMO one of the fundamental differences between
        the two proposals. FH follows RFC 2002 and simply reorders
        the actions (new adv from the old FA)  and the MN requests
bicasting.
        So the control of handoff is still shared between the MN and
        the terminal. Hence more flexibility and less architectural
        dependance.

        Regards,
        Hesham

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 30 Nov 2000 15:49:20 -0800

>         Knowing the MAC address doesn't help

I believe that Jim meant to state that the APs would forward IAPP messages to
the FAs as well. This way the FAs would be aware of handoffs. This, of course,
is not typically done today.

>             or are lost over the old air interface.
IAPP provides all you need. Again, this is ONLY needed for implementations
that DO NOT colocate FA and APs. Keep in mind that although this is not a
popular combination today, the demand for fast handoffs will force vendors to
combine these features.

>         the terminal. Hence more flexibility and less architectural

Hesham, it seems as if I've missed something here. You keep stating that
pro-active FA would not work because the AP is not part of the FA (which again
I state is really an implementation issue).

However, the "fast handoff" proposal supports two methods of providing faster
handoffs: 1. Inter-FA Solicitation
        Now in order for this scheme to work, the FA will HAVE to receive a layer
        two trigger of some form, so it is subject to the same problem as
        the pro-active FA proposal (where colocation is required).
2. Piggy-backing Advertisements on L2 messaging
        Now this proposal requires link layer changes, so we are back to square
        one. If link layer changes are required, then I see no reason why #1
        cannot be done (using either proposal).

So I am quite confused when you state that pro-active has some inherent
problems with 802.11. I really don't see either of our proposals are being ANY
different from each other in this regard.

Furthermore, for APs that do not colocate FA, or do something else to get fast
handoff, then mobiles get RFC2002. Let the market demand for fast handoff
drive colocation of APs and FA. Let's not dwell on this one...

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 30 Nov 2000 16:00:37 -0800

>         cannot be done (using either proposal).

Let me rephrase this one. If link layer changes are required, then we are back
to the e-mail you and Ajoy exchanged to requiring link layer changes for
non-colocated APs/FAs.

So in either proposal, the amount of effort is the same.

Keep in mind, however, the fast handoff will NOT work in environments that do
not provide sufficient time for mobiles to participate in the handoff.

PatC