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

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Fri, 1 Dec 2000 11:26:06 +1100

Sorry for the last mail. I do actually have something to say :)

> > > 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
>
> 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.
>
        => Yes I understand. But the APs will forward this information to
        the FA they are connected to _only_. My understanding is that
        the MN does not tell the old AP "I'm leaving now to go to AP X".
        The AP's update each other after the MN has moved to their
        respective coverage areas to avoid packets being sent over
        multiple radio interfaces.  So based on my understanding
        I can't see how the "current" FA would know that the MN
        is moving. In addition the new FA has no way of knowing
        where the MN came from even if it listens to IAPP.

> >
> >         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.
> IAPP provides all you need.
>
        => Perhaps an answer to my question above would make it
        clearer.

> 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.
>
        => I'm not disagreeing, but I want to emphasise that this is
        an example to express my point, being architectural dependancy.

> >
> >
> >         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.
>
> 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).
>
        => I respectfully disagree. I would say it's an architectural 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.
>
        => I agree that the two proposals are very similar. They both
support
        simultaneous bindings and other similar concepts.
        Apart from the list of differences we discussed, I see a difference
        in the dependancy on certain architectures. You might think that
        this is an implementation issue, but it's important to highlight it.

        In some cases the changes required to support the assumed
        architecture may not be trivial.

        Regards,
        Hesham

---

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

>         architecture may not be trivial.

Correct, but the design choices made also allow the proposal to be used with
even the strictest of link layers (ones that INFORM the mobile that a handoff
is in process). In these wireless networks, there is no additional time for
Mobile IP registration.

However, you failed to address my comment where I stated that this co-location
issue is NOT a pro-active problem, since the fast handoff proposal uses
similar triggers. Both proposals require colocated AP/FAs.

PatC