Subject: Re: [mobile-ip] New Draft on FMIPv6 over 802.11

From: Pete McCann <[email-masked]>
Date: Tue, 1 Oct 2002 09:26:01 -0500

Hi, Alper,

Alper E. YEGIN writes:
 > Can mobile node still send a re-association message even though
 > it's now trying to associate with an AP in another ESS? 
 > If we can use re-association "only" when the mobile is moving
 > within the same ESS, than what is the use? The mobility would
 > be already handled by L2 mechanisms, right?

An ESS can cover multiple IP subnets.

 > > You're right, it's not really supported well by the text.  It's my own
 > > opinion that by minimizing the over-the-air messages we can get better
 > > performance, and support faster velocity movement with fewer packet
 > > drops.  I think this has been borne out by experments conducted by
 > > others.  I didn't want to get involved in a deep discussion of that
 > > experimental data but I think it is compelling.
 > 
 > I think this claim shouldn't go in the text without sufficient support.
 > In the form of either a dedicated section in the draft, or a 
 > reference to another publication. 

I will work to find a reference, or remove the claim from the next
version of the draft.

-Pete

---

From: Pete McCann <[email-masked]>
Date: Tue, 1 Oct 2002 12:03:51 -0500

Hi, James,

James Kempf writes:
 > There's a question about whether the kernel could handle the beacon
 > processing.

Yes, it would need special real-time handling.  But this is the sort
of re-architecting that is going to be needed for a good VoIP
terminal anyway.

 > Also, if the hosts are in infrastructureless mode (which is essentially what you
 > are describing) they can only look at one channel if there is only one .11
 > transciever, right? Otherwise, the host is in the same situation as before,
 > namely the driver (rather than the firmware)  would have to retune the
 > transciever to another channel, in which case the host would lose data service.

Yes, which is why the probes need to be very carefully scheduled with
respect to the real-time traffic.

 > But I've not looked at the Prism2 specs, so I don't know whether having the
 > driver handle the AP management and the APs essentially do an all-IP AP protocol
 > would work better or not. I think the Moby Dick guys in Europe have looked into
 > this, but I am not sure how far they got with it.

It would be good to have them comment on the list if they have
practical experience to report...

 > I've argued on this list (and I hope to have a draft ready by the deadline) that
 > the current FBU semantics confuse MIP binding update with fixing up a temporary
 > failure of routing due to the handover. I think it should be possible to define
 > a way to do mobile initiated tunnel establishment that doesn't have this
 > confusion, for example, by including an extension on the SolRtAdv which the MN
 > sends to the new AR, allowing the new AR to establish the tunnel. There are some
 > security implications here, there needs to be some security between the router
 > and the MN, but the very same security implications are there for any routing
 > function (including setting up the initial security association with the old AR
 > so that the FBU can be secured), not just setting up the tunnel.

Are you just saying that it should be possible to send an F-BU-like
message from the old link?  I would certainly agree that the security
is similar.  I guess you also want to be able to do this prior to nCoA
establishment.

 > Agree. We've looked at a number of existing products, and they all have the
 > characteristic that the handover decision making by the firmware is a black box.
 > Once the scan starts for handover, it is not possible to interrupt it. Some
 > cards allow the driver to obtain signal strength or "link quality" information,
 > others don't, but if the handover can't be broken between steps 1 and 2 for IP
 > signaling, then the information is not useful for doing anticpated handover.
 > There is nothing that IETF can really do about this problem, as IETF does not
 > control the link specification.

Yup.  I think it's important to realize that not all standards can be
done in the IETF.

 > The problem is that the scanning is scheduled on the channel with the same
 > priority as data packets. To the extent that extra scanning results in
 > additional traffic, it could increase the collision rate and reduce the number
 > of mobile nodes that can be scheduled per AP.

Yes, but I don't think there's any reason why you have to go scan all
the other channels in one huge block.  I think that's the reason for
the big interruption in service.

 > > I don't see the need to pursue separate efforts on CAR and PrRtAdv in
 > > separate drafts.
 > 
 > There is a Seamoby design team currently working on CARD. CARD has a wider scope
 > than just this particular problem, for example, it is expected to be useful in
 > intertechnology handover.

Will CARD be an instantiation of PrRtAdv?  I would like to know in
advance what is the relationship between the two.

 > >  > My input is that there is essentially a single mode which can be optimized
 > >  > further where RtSolPr and PrRtAdv are not needed and address
 > >  > pre-configuration is not used. It appears that we need PrRtAdv to provide
 > >  > the MAC addres of the NAR, so might as well provide the prefix
 > >  > information about NAR whenever possible. It should be up to the MN to
 > >  > decide if it wishes to pre-configure a NCoA.
 > 
 > I don't think PrRtAdv is necessarily needed for this purpose. The CARD protocol
 > could run well in advance of handover, perhaps even when the MN shows up at the
 > new AR. Thus, the MN would have a complete map from surrounding AP L2 addresss
 > to new AR L2/IP addresses which would be periodically updated _outside_ of the
 > time-critical handover period. When a reassociation happens, the MN can perform
 > the mapping between the new AP L2 address and the AR L2/IP address, to initiate
 > the tunnel and to route packets to the new AR while it is undergoing the
 > time-consuming process of configuring its new care of address. The old AR need
 > not be involved at all, except to confirm the tunnel initiation and to tunnel
 > packets as needed.

I agree with this, modulo the fact that CARD and PrRtAdv may turn out
to be different facets of the same protocol.

 > > I would also like to see the methods better integrated, it would be
 > > nice if the draft didn't look like 2 competing proposals glued
 > > together (which is of course what it was...).  I think a bit of
 > > discussion with IEEE folks is in order, to figure out the relationship
 > > between PrRtAdv/CAR/beacons.
 > 
 > I'm not sure a general draft is possible. Your work on 802.11 has shown that the
 > 04 draft, and even the 05 draft which Rajeev just released, doesn't really
 > contain anything that would work on existing 802.11 products. I would actually
 > prefer a draft that had a collection of techniques, and then apply them to
 > particular link layers in drafts for those specific link layers ("Fast Handover
 > over 802.11", etc.). That is more likely to provide implementors with
 > interoperable specifications for specific link layers. For MIPv4, the draft is
 > such a collection of techniques, and I think that approach is more likely to
 > accommodate the diversity in wireless link layers.

It seems to me that the IETF should focus on a short term effort
involving F-BU and the associated security concerns.  The problem of
CARD/PrRtAdv seems like a richer problem space that needs more study,
and I think some of these problems might best be solved with
link-layer mechanisms.

-Pete

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 01 Oct 2002 10:15:53 -0700

Jim,

James Kempf wrote:

>
> > I would say the opposite: the least denominator in PrRtAdv is NAR's
> > MAC address for communication. Any available "capabilities" can be
> > provided as options.
> >
>
> I disagree. The current draft requires PrRtAdv to be scheduled immediately prior
> to handover. Merging it with CAR would remove it from the time-critical handover
> period. If the MN always has a map of available APs, then it doesn't have to
> contact the old AR when it moves, accomodating the default 802.11 as it exists
> in products today.
>

The current draft also has made PrRtAdv optional on links
where the information it provides is supplied by other means.
I am not in favor of merging PrRtAdv with CARD. We ought to
be able to run fast handovers without running CARD. And, I know
we can.

>
> There is, of course, an issue here with other link layers (such a cellular)
> where the old AR can provide help, but then we are into a network initiated
> case, and that is another situation.
>
> This is one reason why I think trying to get a single protocol that covers all
> link layers is not likely to be very productive. Every link layer has particular
> features and misfeatures that will allow/inhibit additional optimization. If the
> intent is to come up with a protocol that provides maximum optimization, then we
> must allow developers to utilize those features/accommodate misfeatures. While
> it might be possible to capture some of these features in an abstraction, such
> as link layer triggers, this approach has not generated much appeal in the IETF.
>

Clearly, we cannot cover features of all link layers. That's our advantage
as well! What we can do is to define a base protocol while _allowing_
all sorts of customizations possible on different link layers. We don't
have to define all those optimizations; I even wonder if we can!
The base protocol must work on all link types. Text may be added
(in the base draft, elsewhere) regarding specific link customizations
necessary.

>
> On the other hand, if the goal is to simply provide an improved version of
> movement detection (which is what I think draft 05 is trying to do), then
>

Well, I don't know what you have in mind here, but v05 defines support for
1) handover initiation
2) tunnel establishment and
3) packet forwarding on the tunnel

It is basically evolving from v04, with the additions reflecting the
discussion on the ML.

> perhaps accommodating various link layers isn't necessary. But we should not
> expect it to work particularly well on specific link layers, including 802.11,
> though it will probably work better than movement detection on all link layers.
>

I get the feeling that we are prematurely concluding many things here.
We have not proven that the base protocol does not meet the performance
nor have we clearly understood the performance gain (vs cost) of having
link layer-assisted features. We should allow implementors to try the
base protocol, and gather some data, most likely from the 802.11 space.

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 01 Oct 2002 10:45:48 -0700

James Kempf wrote:

>
> >> If we remove those features that aren't universally implementable on
> > any 802.11 firmware, what is left is just F-BU.  This doesn't seem to
> > improve things much over basic Mobile IPv6, assuming we get the
> > security and semantics of the F-BU defined (I know this was recently
> > moved out of the base draft, and I think it makes a good topic for the
> > "fast handoff" draft, but it would have a much smaller scope than its
> > current incarnation).
> >
>

On the original point about whether there is improvement
over Mobile IPv6: there should be, because the MN gets to use
PCoA until it completes BU with CN.

>
>
> >  > - "Also there is no guarantee that MN will actually attach to
> >  >     the given AR after it has sent FBU.."
> >  >     While this could be true in general, in our experiments spanning
> >  >      few hundred handovers, the MN always attached to the target
> >  >      AP (and NAR). We did have more than two APs.
> >
> > Ok, that's a useful data point.
> >
>
> I'm curious how many mobile nodes were involved. The behavior under load might
> be much different than with one or a few mobile nodes. For example, in our
> measurements, Layer 2 handover time increased as the number of mobile nodes
> doing real time traffic increased, because of the aformentioned lack of QoS on
> the handover signaling.

We have not done a stress test or anything like that, but we did have more than
one MN attached to the APs. I can imagine at high loads there might be some
additional delay, but would be very surprised if it causes noticeable difference in

a 11 Mbps WLAN. Anyway, we do plan to study this.

> not be involved at all, except to confirm the tunnel initiation and to tunnel

As I have mentioned before, if on a link the necessary information is
provided by other means, on such links PrRtAdv is optional. This is
stated in v05. However, I don't want to make it optional because CARD
is working on a super set. Folks ought be able to run fast handovers without
having to run CARD. And, it is not difficult. I have another idea: the Handover
Capability Extension in v05 is now included in RA. Sounds like a good place
to embed the "map" and the node attributes.

> contain anything that would work on existing 802.11 products. I would actually

I disagree.

1) Setting up the tunnel after re-association should work on existing
     products
2) Setting up the tunnel prior to disconnecting from the previous
     link is an option that folks working on things like Wireless Extensions
     and firmware designers could use. BTW, Jean Tourrilhes' note to the
     PILC WG mentioned using the extensions for Mobile IP and AODV.
      There is a link to Mobile IP on his webpage.
3) Having the user have control to induce handover should also work.
     For instance, a user may be notified of a hot spot through PrRtAdv
    and tunnel may be set up prior to re-association. The current
    implementation that Vijay has worked on shows this is feasible.

-Rajeev

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Tue, 1 Oct 2002 12:08:53 -0700

Hi Pete,

> An ESS can cover multiple IP subnets.

But this still doesn't answer my question though.
As long as the mobile moves within the same ESS,
wouldn't/shouldn't distribution system (DS)
handle the mobility?

alper

---

From: "James Kempf" <[email-masked]>
Date: Tue, 1 Oct 2002 13:00:54 -0700

Rajeev,

> be able to run fast handovers without running CARD. And, I know

I wasn't proposing getting rid of PrRtAdv. Making it optional should satisfy the
requirement.

> It is basically evolving from v04, with the additions reflecting the

OK, I need to take a look.

> base protocol, and gather some data, most likely from the 802.11 space.

Clearly, the base protocol won't be able to eliminate the 100-400 ms Layer 2
handover gap, without firmware enhancement.

Besides, 802.11 isn't the only radio protocol out there.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 1 Oct 2002 12:57:43 -0700

Rajeev,

> 1) Setting up the tunnel after re-association should work on existing

This loses packets during the Layer 2 blackout period, which is substantial
(100-400 ms) in 802.11.

>       There is a link to Mobile IP on his webpage.

Do you think firmware designers are going to do this, absent an 802.11 spec that
clearly defines how it should work? Even if they do, what do you think the
probability is that the different products would be interoperable?

>     implementation that Vijay has worked on shows this is feasible.

Sure, for intertechnology handover, the current approach will work just fine.
But if traffic is proceeding fine on another link, there's no urgency to get up
the hotspot link, so no real need for FMIPv6 anyway.

You've also missed my general point. Here's an example of the point.

Though I have not taken a look at draft 05 yet, I believe it now requires that
the FBU be the signal for the
tunnel to be established.  Since the FBU is sent at Layer 3, there are three
possible cases: 1) it is sent before the link down, 2) it is partially sent when
the link down occurs, so that it is dropped (though from the MN's IP stack, it
looks as if it was sent), 3) it is sent after the link down.

Now, some link layers may have a secured link down trigger that could be used.
By disallowing this to be used to signal tunnel establishement, the draft
effectively cuts off a means whereby additional optimization can be obtained.

The current approach is attempting to define an all-Layer 3 replacement for
movement detection, without being specific about what link layer information
could provide maximal performance. This is a fine approach, but I don't think
one can expect it to perform optimally on all link layers. Pete's draft has
pointed out where this approach has problems.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 01 Oct 2002 16:52:32 -0700

> This loses packets during the Layer 2 blackout period, which is substantial

Is this due to re-association or scanning ? As Pete mentioned,
scanning should happen ahead of handover. If re-association
takes this long, that's link switching delay and the base draft can't
do anything about it, although one possibility is to request the PAR
to buffer after scanning.

> probability is that the different products would be interoperable?

Firmware: I don't know, but I won't rule it out.
Driver extensions: I think it is more likely than firmware.
Interoperability: those firmware/driver implementation that
have it can test interop.

> the hotspot link, so no real need for FMIPv6 anyway.

Well, I may want to switch because I get better video on WLAN. And
I don't want to see a disruption. There might be other reasons.

So, my point above is that we are trying to cover the possible
cases, and not that one case is necessarily more important than
the others.

> tunnel to be established.  Since the FBU is sent at Layer 3, there are three

Actually, tunnel is established using FBU in the case when
the MN associates first without being able to engage in any
signaling.

> effectively cuts off a means whereby additional optimization can be obtained.

Again, tunnel _could_ be established using link-layer
features. It is the forwarding on the tunnel that happens
after FBU is received.

> pointed out where this approach has problems.

We should let the implementors provide some data. That would
let us know how well an implementation without any assistance
from the link layer will do compared to the one with assistance
from the link layer.

So, I would like to encourage folks to try out the implementations.

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 01 Oct 2002 16:56:36 -0700

> I wasn't proposing getting rid of PrRtAdv. Making it optional should satisfy the

Ok.

> handover gap, without firmware enhancement.

Right. How can it eliminate the link switching delay ?

> Besides, 802.11 isn't the only radio protocol out there.

Agreed. I was saying that 802.11 is a very likely early
adoptor, and we ought to encourage other links to
consider the implementation too.

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Wed, 2 Oct 2002 08:55:50 -0700

> features. It is the forwarding on the tunnel that happens

This is the problem. If the MN sends the FBU before it moves, traffic is sent to
the new AR and the MN either loses the packets or the new AR must buffer (which
is not good for real time traffic), exactly like FMIPv4 Prereg. If the FBU is
interrupted by the link switch, the MN ends up waiting some period of time on
the new link without packets before resending. These cases are possible on
particular link types.

Furthermore, how does the MN know that it is on a new link (which could be used
to optimize sending an FBU so as to avoid the two conditions above) _without_
using L2 information? If L2 information is unacceptable for starting packet
forwarding on the old AR, then why is it acceptable for signaling the MN to send
the FBU?

If we are to strictly run this protocol using L3 information, then the MN must
wait for the RA beacon from the AR, and then the performance will be no better
or worse than movement detection.

> from the link layer will do compared to the one with assistance

See above.

> So, I would like to encourage folks to try out the implementations.

We've implemented draft 04, which is not so different. We have seen exactly the
problems outlined above.

            jak

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 11 Oct 2002 15:18:30 -0700

hi Pete,

I just read your draft. I am not clear about one thing.

in section 4, step 4, is it an association request or a
re-association request? looks like only the re-association 
request contains the MAC address of the old AP. in case the 
MN sends an association request, the new AP does not get the 
MAC address of the old AP (and it has no way of figuring out 
the MAC address of the old AP). so steps 5 and 6 cannot be 
performed unless the MN sends a re-association request, 
right?

from the mailing list discussion between Alper and you, it
seems re-association request is sent only if both the old AP
and new AP belong to the same ESS.

how can you assume the old AP and the new AP are part of the
same ESS??

Vijay

ps: did I miss something from the discussion Alper and you had?

Pete McCann wrote:
> 
> Hello,
> 
> Yesterday I submitted a new draft that describes how the FMIPv6 work
> might apply in an 802.11 network.  It has appeared in the
> internet-drafts directory and you can find it at:
> 
> http://www.ietf.org/internet-drafts/draft-mccann-mobileip-80211fh-00.txt
> 
> Please read and comment (preferably in that order).
> 
> I think I have found significant issues with both of the main
> approaches that were proposed in fmipv6-04.  I hope this draft can
> contribute a dose of reality to the discussion going forward.  I
> think there are several opportunities for closer collaboration with
> link-layer standards bodies like the IEEE, once some of these issues
> are understood.
> 
> -Pete

---

From: Pete McCann <[email-masked]>
Date: Fri, 11 Oct 2002 17:35:35 -0500

Hi, Vijay,

 > performed unless the MN sends a re-association request, 

Correct.

 > and new AP belong to the same ESS.

I think it's not quite clear from the standards; the IAPP protocol
assumes both APs are in the same ESS, but I think a STA is technically
allowed to send a re-association even when moving to a new ESS.  I
have no idea whether any given implementation actually does this,
however.

 > how can you assume the old AP and the new AP are part of the

It's easy to assume - there, I just did it. :)

Seriously, though, it is a good question whether this assumption is
realistic for a given deployment environment.  Neighboring operators
should configure their APs to broadcast the same ESSID if they want
to use IAPP for handover.  I will likely add some explanatory text to
this effect, based on the discussions we've had so far.

-Pete

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 11 Oct 2002 15:59:30 -0700

> have no idea whether any given implementation actually does this,

maybe I can make this statement. IAPP was designed to work 
only between APs in the same ESS (read.. 'same administrative 
domain'). maybe RADIUS authentication does not work if the APs
belong to different ESSs. maybe I need to take a look at IAPP
specs :-)

> this effect, based on the discussions we've had so far.

so, going further, the triggers used in section 6 (Tunnel-based 
Handover) cannot happen, unless the MN sends a re-association 
request (and not an association request) to the new AP.

regards
Vijay

---

From: Pete McCann <[email-masked]>
Date: Mon, 14 Oct 2002 09:53:57 -0500

Hi, Vijay,

Vijay Devarapalli writes:
 > belong to different ESSs.

The RADIUS server is used to distribute security associations, so it
must have access to secret key material for both APs.  The simplest
assumption is that one ESS = one administrative domain, but other
approaches are possible.

 > maybe I need to take a look at IAPP specs :-)

Wouldn't be a bad idea.

Correct.

-Pete