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

From: James Kempf <[email-masked]>
Date: Thu, 30 Nov 2000 15:03:32 -0800

Hi folks,

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.

Note that the term "L2 trigger" in the pro-active handoff draft
may be somewhat misleading as, even in such systems as IS-2000 CDMA,
the protocol stacks involved in control in the RAN are not really
L2, they are SS7 style stacks with control protocols running
at the application layer. The control protocol in the IS-2000 case
would probably be something like IS-634 (IOS 4.0) or maybe IS-41, which
is pretty far above the L2 layer. From the point of view of the FA, however,
they might as well be at L2, since they are not running on IP networks. At any
rate, the IAPP Handover message for 802.11 would be exactly analogous to, say,
an IS-41 Handover Request message, both of which would generate a proactive
Handover Request message, except the IAPP message is a post trigger
while the IS-41 message is a pre trigger.

Apologies if this duplicated any discussion previously on the list.

                jak

---

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

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

> >
> >         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. 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.
>
> >
> >
> >         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).
>
> 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: Ladipo Adefala <[email-masked]>
Date: Fri, 1 Dec 2000 04:15:51 +0100

Could someone please remind me of the process to remove myself from this
mailing list.
Thanks

>From: "Hesham Soliman (EPA)" <[email-masked]>
>Reply-To: "Hesham Soliman (EPA)" <[email-masked]>
>To: [email-masked]
>Subject: Re: [MOBILE-IP] Pro-active Handoff and FA Location
>Date: Fri, 1 Dec 2000 12:07:52 +1100
>
> > >         => 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.
> >
> > 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).
> >
>         => These link layers are much more sophisticated than others
>         because they know where the MN is going. I think that makes
>         it easier to accomodate MIP since you're getting good hints.
>         FH also supports that case by sending the proxy advertisement
>         to the MN from the current FA.
>
> > In these wireless networks, there is no additional time for
> > Mobile IP registration.
> >
>         => Which wireless links ? CDMA for example ?
>         As we mentioned during the meetings, we looked at these
>         handoff sequences and found that there is time and it is
>         certainly possible to support FH. CDMA is much more
>         flexible in terms of handoff times than other wireless
>         systems.
>
> > 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.
> >
>         => The FH model allows for both MN initiation and FA initiation.
>Therefore
>         I don't see why it would need this colocation.
>         You also didn't answer my comments on IAPP :)
>
>         Hesham

_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com