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

From: Pete McCann <[email-masked]>
Date: Wed, 25 Sep 2002 13:39:45 -0500

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: Behcet Sarikaya <[email-masked]>
Date: Thu, 26 Sep 2002 11:27:24 -0500

I read this draft, I found it very good. It clearly points out the 
impossible scenarios in FMIPv6 even for the only wireless link for which 
we thought it was applicable.
Great work Pete!

Regards,

-- 
Behcet

---

From: "s. goswami" <[email-masked]>
Date: Thu, 26 Sep 2002 13:22:04 -0400 (EDT)

Hi Mr. McCann, have browsed the draft. It is well written,
altough still very general. I my view there can be only one
handoff, all the layers that interact with the infrastructure
would need to complete their respective handoff together.
At the same time the protocols would have to designed such that
the layers are cleanly seperated. The handoff protocol should
be defined at L3 and then would be adapted to each type of
link (ala IP and Ehernet via ARP).

Subrata

---

From: Pete McCann <[email-masked]>
Date: Thu, 26 Sep 2002 13:07:32 -0500

Hi, Behcet,

Thanks.

I would be careful using the word "impossible"; it's just a question
of how much firmware you want to re-write.  Also, it may be the case
that some cards do support the required functionality for Anticipated;
I have not done a survey to find out.

For Tunnel-based, I think there is just a bit more L2 security
standardization work that needs to take place in the IEEE.

-Pete

---

From: Pete McCann <[email-masked]>
Date: Thu, 26 Sep 2002 13:09:55 -0500

Hi, Subrata,

Thanks for your comments.  I agree with you mainly, but I question how
much of the "adaptation" can be done in the IETF, especially if it
involves new message elements inside 802.11 frames.  I think that can
only be done in the IEEE.  It may be the case that no new work is
needed in the IETF, and that existing Mobile IP messages suffice.

-Pete

---

From: "s. goswami" <[email-masked]>
Date: Thu, 26 Sep 2002 14:18:49 -0400 (EDT)

Yes, I am very  much aware of that.  There are some minor
changes that  can be made with IETF RFC's, but the major
part of the work has to be done in IEEE. Although, I would
say blessing from IETF would certainly go a long way.

Subrata

---

From: "James Kempf" <[email-masked]>
Date: Thu, 26 Sep 2002 13:02:40 -0700

Pete,

Excellent job, good work. Your draft does a good job pointing out the gaps
between theory and reality in the fast handover work.

A few comments.

            jak

------------------------------------------

Overall comment: One approach that was not considered, because it is not in
draft 04,  is to have the mobile node initiate the tunnel after handoff. This
does not have as good performance characteristics as the two techniques
described in draft 04, but I believe there should be no barriers in principle to
this, unlike the techniques described in draft 04. We've done some experimental
work in this area, and, modulo the packet drops due to the L2 handover time, the
performance is as almost as good as AP tunnel initiation.

Specfic comments:

Section 1 paragraph 1: "disconnects from one point of attachment" ->
"disconnects from one point of attachment in one subnet"
"new point of attachment" -> "new point of attachment in a new subnet"

Section 2. ESS definition suggests an IP subnet. Would there be any leverage
gained by recommending (via a Best Current Practices RFC) that network operators
configure their networks with such an overlap? Would this gain any signaling
advantage at the link layer that would allow use of anticpated or tunneled
handover in a better way?

IAPP is mentioned later on in the document without being mentioned in the
definitions.

Section 3: Probably ought to mention that this section discusses 802.11
infrastructure mode deployment only. There has been some work done on Mobile IP
handover with 802.11 in infrastructureless mode.

Section 4. pg. 5 last paragraph: It is unclear here whether the trust
relationship is between the MN and an AP or between APs.

Section 4. pg. 6 3rd paragraph: "local implementation decisions" -> "
properietary algorithms in the NIC card firmware"

Section 4 pg. 6 last paragraph: The MN can do the AP link layer id to AR IP
address mapping if it is running CARD.

Also, parallel sending of PrxyRtAdv with HI/HaCK is probably not such a good
idea (althrough recommended in the draft) in case DAD fails on the new subnet.

Section 4. pg. 7 1st paragraph: The FBack is sent on the old and new links,
because the MN may have moved.

Section 4 pg. 7 2nd paragraph: "permission from the host" -> "allowing control
to pass back to the IP layer"

Section 4 pg. 7 3rd paragraph: "such an exchange" -> " the
SolPrxyRtAdv/PrxyRtAdv exchange"
"connection to oAR" -> "connection to the old access point"
following "nAR" -> "new access point"

Section 7: There is a general issue with the 802.11 MAC layer that affects both
protocols. The MAC address is fully spoofable, thus it is impossible to achieve
true MAC layer security.

Section 7. pg 8. 2nd paragraph: Would it be possible for the 802.11 committe to
define a new Authentication method type that would allow some kind of fast
reauthentication, instead of requiring 802.1x reauthentication? This would
actually benefit both protocols.

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 26 Sep 2002 15:42:28 -0700

Hi Pete,

Thank you for this very good analysis...

Few comments/questions...

When is "association" used vs "re-association"? What does
the spec say about this? Note that Tunnel-based handover
relies on a piece of information that is only available on
"re-association", but not "association". 

In the text, you are referring to L2-TT and L2-ST, which
are acronyms used in this draft: 
draft-manyfolks-l2-mobilereq-02.txt.
You might want to provide a reference to it.

Also you can find a proposed AP-AR protocol here for
transporting L2 triggers:
draft-yegin-l2-triggers-00.txt

And later there was a mention of CAR protocols. 
Section 4.2.2. of draft-gwon-mobileip-efw-fmipv6-00.txt
is an example of such protocol... I'm providing these
as pointers that you might want to consider including
in the reference section...

  "Even for Anticipated handovers, these flaws must be 
   fixed to allow secure handovers within the same subnet.  "

Does the intra-subnet handover really relate to FMIP here?

"If the proper L2 security can be obtained, we recommend a Tunnel-
   based handover be initiated due to its superior performance. "

I couldn't see where this conclusion was drawn from in this text.

Thanks.

alper

---

From: Pete McCann <[email-masked]>
Date: Fri, 27 Sep 2002 10:56:01 -0500

Hi, James,

Thanks for your comments.  Replies below.

 > performance is as almost as good as AP tunnel initiation.

I think what you are saying is to just use F-BU after reassociation.
This makes a lot of sense to me; it might be the case that the right
scope of the Mobile IP WG is to just define this message and work out
the details of securing it.  Other techniques might be more properly
pursued in the IEEE.

 > "new point of attachment" -> "new point of attachment in a new subnet"

Ok.

 > handover in a better way?

ESS definition says "may consist of one or more IP subnets" which is
true.

Maybe what you are saying is that we need a coordinated assignment of
ESS ID's across all the APs that plan to implement fast handoff to
each other.  Perhaps there should just be one global well-known ESS ID
for all 802.11 public Internet access (or perhaps the broadcast SSID
is good enough).

Anyway, the point is that if we are going to leverage the information
in a Reassociation Request, I think we need to have both APs belong to
the same ESS, and there will likely be more coordation needed between
them and between the associated ARs.  It would be nice if this
coordination were just "hook them up to the same Internet", but a both
of the handoff methods discussed so far require more.

 > IAPP is mentioned later on in the document without being mentioned in the

Ok, I will add it.

 > handover with 802.11 in infrastructureless mode.

Could you outline what you think the differences are?  I assume we
would still be talking about Internet access and not ad-hoc routing.

I think we couldn't use IAPP in this case.  I think the scan/beacon
process is somewhat different.

 > relationship is between the MN and an AP or between APs.

Are you talking about the IAPP IPSec tunnel?  This is definitely
between APs, and the only trust is between APs.  I will try to clarify
this.  It is important to note that this trust/security is independent
of whatever means was used to authenticate the MN.

 > properietary algorithms in the NIC card firmware"

True, I think it is most often done in firmware but I believe other
implementations are possible.

 > address mapping if it is running CARD.

I think you mean Section 5, right?  Here the mapping is done at the
oAR, not the MN.  I don't think CARD applies directly and we need some
other source of data.

 > idea (althrough recommended in the draft) in case DAD fails on the new subnet.

That discussion should be held separately on the list, methinks.

 > because the MN may have moved.

Right, I will clarify (assume you mean Section 5).

 > to pass back to the IP layer"

I think "permission from the host" is more general, your suggested
text is certainly implied by that.  I was trying to say that nothing
on the host (IP stack, device driver, kernel, etc) is involved in the
handoff decision, given certain firmware implementations.

 > SolPrxyRtAdv/PrxyRtAdv exchange"
ok
 > "connection to oAR" -> "connection to the old access point"
ok
 > following "nAR" -> "new access point"
ok

 > protocols. The MAC address is fully spoofable, thus it is impossible to achieve

I think there has been some misunderstanding in some of the recent
list discussions on this topic.  From what I understand, once you have
properly authenticated to an AP and developed keying material
(following the in-progress 802.11i spec), subsequent messages are
protected by strong authentication and the link-layer address is used
as an index to selec the proper security association, much as an IP
address/SPI is used in IPSec.  So the MAC address is in fact protected
and there is no way for a bogus STA to insert frames without breaking
the cryptography.

 > actually benefit both protocols.

I think both the Mobile IP WG and IEEE need to have a discussion about
this.  I see two main goals, when compared to the current 802.1x
exchange that is being worked on now:

1) Allow for pre-authentication (or fast re-authentication) across
   subnets.  The current 802.1x messages must stay within a subnet or
   VLAN. 
2) Minimize the number of messages sent over-the-air.  Current 802.1x
   would do a from-scratch EAP exchange on every handover, which might
   involve too many messages.

Possible approaches are to use PANA in a pre-authentication style or
leverage IAPP to do context transfer of security credentials.  Bernard
Aboba recently pointed me at his draft on the IAPP approach:
draft-aboba-802-context-02.txt.  While I'm not sure that this
particular approach is being worked in IEEE currently, we should
certainly try to discuss the solution space a bit more.

-Pete

---

From: Pete McCann <[email-masked]>
Date: Fri, 27 Sep 2002 11:07:20 -0500

Hi, Alper,

Thanks for your comments --- replies below.

Alper E. YEGIN writes:
 > the spec say about this?

Association should be used when first connecting to an ESS, and
Re-association should be used when connecting to a new AP in the same
ESS.  However, the spec doesn't mandate that you do a Re-association
under these circumstances, and you will get service even if all you do
is Assocation.  In that case you wouldn't be able to execute IAPP
because you wouldn't have the link layer address of the old AP (it is
only included in the Re-association message).

 > Note that Tunnel-based handover

Correct.  Perhaps I will add some text to clarify this.

 > You might want to provide a reference to it.

These terms are actually used and defined in Section 3.2.1 of
draft-ietf-mobileip-fast-mipv6-04.txt.  Perhaps they should be moved
into the terminology section.

 > draft-yegin-l2-triggers-00.txt

Yes, thanks, I had heard about this draft but haven't studied it
closely.  This is definitely the kind of thing that IETF and IEEE
should be working together on.

 > in the reference section...

Thanks, I will look at it.  I currently just reference a WG document
on CAR requirements, I wasn't sure of the status of any of the
individual drafts.

 > Does the intra-subnet handover really relate to FMIP here?

Only indirectly, in that if there is a fix for intra-subnet it might
also fix the inter-subnet problem.  In this case, that happens to be
true, but at the expense of some additional authentication traffic
after reassociation when compared to the intra-subnet case.

 > I couldn't see where this conclusion was drawn from in this text.

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.

-Pete

---

From: "s. goswami" <[email-masked]>
Date: Fri, 27 Sep 2002 13:10:46 -0400 (EDT)

See my comments below.

>  > Does the intra-subnet handover really relate to FMIP here?

Good point, probably not.

> experimental data but I think it is compelling.

Aagree,  the number of messages need to be exchanged
with or within the infrastructure needs to be reduced -
by avoiding duplication and other means.

Take a look at the  draft draft-goswami-aaa-mipv4-wlan-auth-00.txt.
Where Diameter Mobile IPv4 Application is proposed as an alternative
to 802.1x Auth/Key-Exchange. By doing that all the  4 security
associations needed (MN-HA, MN-FA, FA-HA, MN-AP) can be generated
dynamically together.  It is still a work in progress.

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 27 Sep 2002 18:48:18 -0700

Hello Pete,

I have gone through your analysis and have some
comments.

1. the ultimate control on L2 handover resides in
   firmware. However, the driver can have information
   about the SNR and RSSI. See for instance "Wireless
   Extensions" work in Linux  (Jean Tourrilhes'
   website). So, one could write a wrapper that
   a) selects an AP based on metric(s) of interest
   b) sends RtSolPr
   c) receives PrRtAdv
   d) sends FBU, and
   e) executes steps 2+ in your draft

Note that c) is necessary for the MN to send packets to
the new AR immediately upon connecting. I brought this
up at the last IETF meeting. (See Slide 5 in
http://www.ietf.org/proceedings/02jul/slides/mobileip-3/index.html).
So, the way I see anticipation is that it is an extension in PrRtAdv.
But the bottomline is the MN needs NAR's MAC address.

2. Ofcourse, if the card makes "autonomous decisions", the
above steps might not be useful always. In order to address this
and the "default" scenario, where a host attaches to a new AP
without being able to exchange messages on the previous link,
"Tunnel Establishment Subsequent to Handover" was also
brought up in the last IETF (See Slide 3). Here, an FBU sent
from the new link causes HI/Hack exchange resulting in tunnel set up and
packet forwarding. The MN sends a RS immediately upon
connecting (associating here) to obtain both the MAC address
and the router's IP address, which it uses to bind its previous
CoA.

3. I think one way to look at tunnel-based handover is to
consider the case when RtSolPr and PrRtAdv are not needed.
[As you point out, how the MN gets the NAR's MAC address
is still an issue in WLAN]. Note that recent discussion on
the list has converged on the need for FBU to authorize forwarding
on the tunnel which could be set without exchanging messages
with the MN. Of course, tunnel-based handover also defines
other functionalities such as tunnel renewal, HTT etc.

4. Both "anticipation" and "tunnel-based" approaches need
a bidirectional tunnel between the routers to allow the MN
to send and receive packets using previous CoA. This is the
case even if the MN is able to pre-configure NCoA, since it
is not useful until the BU is completed with the CN(s). So,
anticipation helps in expediting the RR and BU process, and
not so much with the packet forwarding part. In fact, it helps
a MN to receive packets using "direct" routing faster.

All these considerations have been entered into v05 version
and it should be available on the list pretty soon.

Some more comments..

- Since scanning is time consuming, the draft may want to
   make a recommendation to not do it ahead of the actual handover.
   This should also include a note that data is blind-sighted
    during this process.

- There needs to be some discussion of the implications of
    "autonomous decision making" by the card. This is perhaps
    a bigger issue than what the draft can address..

- How widely is the configuration in Figure 2 used compared
    to Figure 1 is useful to know. A hierarchical deployment
    clearly favors configuration 1 which is deployed, and it would
    be useful to know when configuration 2 would be desirable and
    used, if any.

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

- "Even for Anticipated handovers, these flaws must be fixed to
     allow secure handovers within the same subnet"
     Within the same subnet, why is there a need for IP handover?

- "The relationship between PrRtAdv and CAR discovery protocols
    needs further ...."
    I agree. The important parameter that the MN needs is the NAR's
    MAC address. I would even suggest that the capabilities be provided
    as options in PrRtAdv.

- "If the support for security can be obtained, we recommend a Tunnel-
    -based be initiated .."
     I cannot quite figure out how this conclusion can be made based on
     what the document describes. Apart from the security, you need a
     particular deployment configuration that favors the tunnel mode,
     new messages between the APs and ARs, a message that carries the
     MAC address of the NAR, etc..So, this is premature.

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.

Thanks for the analysis.

-Rajeev

---

From: Pete McCann <[email-masked]>
Date: Sat, 28 Sep 2002 22:31:09 -0500

Hi, Rajeev,

Thanks for your comments - some responses below.

 >    e) executes steps 2+ in your draft

My understanding of the "Wireless Extensions" is that they give signal
strength information on the currently connected AP only; the "wrapper"
you describe would have to do some kind of exhaustive search,
re-tuning the radio to each channel, associating with the AP there,
figuring out the best AP from the bunch, and then tuning back to that.
I would think this would take much longer than the existing beacon
scanning process.

I think a better approach would be to just move *all* of the
management traffic into the host; something like this does in fact
seem to be allowed by the firmware on most cards with the Prism2
chipset.  See http://hostap.epitest.fi/.  In this way, the host would
actually be sending probes and processing the beacons.  However, the
point made in the draft is that not all cards support this mode of
operation.

 > But the bottomline is the MN needs NAR's MAC address.

I agree that the MN needs to learn the MAC address of nAR, but
c) PrRtAdv is just one possible mechanism.  There may be others.

 > and the router's IP address, which it uses to bind its previous

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

If we want to keep features that are only implementable given very
specialized device drivers and/or firmware, we should probably move
some of the discussion into IEEE or at least poll relevant
manufacturers to make sure these things are going to exist.

 > is still an issue in WLAN].

Maybe RtSolPr and PrRtAdv should be merged with CAR, or perhaps the
same information could be derived on a more end-to-end basis if we
could do something like put AR IP/link addresses into beacons.  This latter
approach would require a bit of work in the IEEE, but would alleviate
some of the AR-to-AR-to-AP configuration issues.

 > Note that recent discussion on
 > with the MN.

I realize the importance of IP-layer MN-to-AR security (see the
Security Considerations section of the draft), but I worry that this
requirement might rule out some highly optimized configurations that
leverage link-layer security.  However, perhaps the sort of approach
originally outlined in Tunnel-Based is best pursued in the IEEE,
between APs that know they have good security.

 > Of course, tunnel-based handover also defines

Yup.

 > is not useful until the BU is completed with the CN(s).

Agreed.  This is the whole point of fast handoff.

 > So,

I think you are saying that a head-start on CoA address allocation
gets the RR and BU done faster.  I think this is true, assuming that
you can correctly anticipate the handover; I just don't think current
802.11 cards give the IP stack much time to do anything before
handover.

 >    This should also include a note that data is blind-sighted

I think some of the recommendations given at the end of the UMD study
should be looked into.  In particular, maybe we should encourage
beacon scanning well in advance of handover.  It would be nice to be
able to probe one channel at a time, so that a single probe could be
scheduled between real-time packets, and the list of candidates could
be built in advance.

 >     a bigger issue than what the draft can address..

We might just need to wait for a new generation of 802.11 hardware
before any of this work becomes practical.

 >     be useful to know when configuration 2 would be desirable and

I can't say for sure, but I think Figure 1 deployments are much more
widespread than Figure 2 deployments.  I think IETF meetings use a
Figure 1 deployment.

 >      AP (and NAR). We did have more than two APs.

Ok, that's a useful data point.

 >      Within the same subnet, why is there a need for IP handover?

There isn't, I am just saying that if there is a fix for intra-subnet
movement (as there must be no matter what fast handover protocol is
chosen) it might also be a fix for inter-subnet tunnel-based.  The
ongoing 802.11i work seems to be just the fix, although it does
require extra overhead on the critical handoff path for the
inter-subnet case.

 >     MAC address. I would even suggest that the capabilities be provided

Or maybe the information could be pushed down to the 802.11 layer
managements frames.

I don't see the need to pursue separate efforts on CAR and PrRtAdv in
separate drafts.

 >      MAC address of the NAR, etc..So, this is premature.

See my response to Alper on the same topic.

 > decide if it wishes to pre-configure a NCoA.

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.

 > Thanks for the analysis.

You're welcome.  I hope we can all converge on a useful draft through
the resulting discussion.

-Pete

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 30 Sep 2002 10:39:53 -0700

Hello Pete,

> I would think this would take much longer than the existing beacon

I suppose scanning is needed anyway. It should be done
at a less time-critical time. (We seem to agree below).

> actually be sending probes and processing the beacons.  However, the

This would be a useful feature.

> point made in the draft is that not all cards support this mode of

Right. We should cover different possibilities. "Tunnel Establishment
Subsequent to Handover" is meant to cover the cases when no
firmware/driver support is available for any preparation prior to
handover.

> c) PrRtAdv is just one possible mechanism.  There may be others.

We should specify PrRtAdv, while leaving room for others.

> If we remove those features that aren't universally implementable on

"universally implementable" is a function of time!

> improve things much over basic Mobile IPv6, assuming we get the

Well, FBU (in this case) triggers a tunnel set up which is necessary to
allow the MN
to use previous CoA. With MIPv6, you could have had a tunnel from
the PAR to NCoA, but, NCoA is not useful as a src IP address until
RR is done. FMIPv6 allows a MN to use PCoA until RR is done. So,
I would say there is a crucial improvement.

> manufacturers to make sure these things are going to exist.

We should be in sync with IEEE. And, we should leave room for
improvements. The example you cite above and the Wireless
Extensions work are perhaps indicators that one could already
use the protocol messages provided.

> Maybe RtSolPr and PrRtAdv should be merged with CAR, or perhaps the

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.

> some of the AR-to-AR-to-AP configuration issues.

I hope something like this could be done. We should leave
room for it in the draft.

> between APs that know they have good security.

Ok, IEEE may be a good place.

> Agreed.  This is the whole point of fast handoff.

Good. Just as a matter of clarification, v04 predates RR which
makes use of PCoA in a source IP address necessary. RR was
not a consideration in v04.

> gets the RR and BU done faster.  I think this is true, assuming that

Right.

> 802.11 cards give the IP stack much time to do anything before

The hooks should exist for anticipation. And, we can cover the
current default scenario by sending FBU subsequent to handover.
This is specified in the v05 which will be available soon.

> scheduled between real-time packets, and the list of candidates could

Agreed. Indeed, in our experiments, we have done the same.

> widespread than Figure 2 deployments.  I think IETF meetings use a

That's what I thought as well. Deployment in Figure 1 clearly provides
better coverage area per subnet.

> require extra overhead on the critical handoff path for the

ok. You might rephrase it then that the issue is intra-subnet
movement.

> Or maybe the information could be pushed down to the 802.11 layer

That is possible, although unlikely for IETF to work on.

> I don't see the need to pursue separate efforts on CAR and PrRtAdv in

While I agree with the need to avoid duplicity, the practical issues
are noteworthy. I hope [seamoby] can define CAR capabilities in
a format that would allow them to be used as options in PrRtAdv,
being standardized in [mobile-ip].

> together (which is of course what it was...).  I think a bit of

I hope v05 would be seen as a step in this direction.

> the resulting discussion.

It is my hope and intent as well.

-Rajeev

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Mon, 30 Sep 2002 18:43:17 -0700

Hi Pete,

> only included in the Re-association message).

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?

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

alper

---

From: "James Kempf" <[email-masked]>
Date: Mon, 30 Sep 2002 18:50:12 -0700

Pete,

> point made in the draft is that not all cards support this mode of

There's a question about whether the kernel could handle the beacon processing.
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.

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.

> "fast handoff" draft, but it would have a much smaller scope than its

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.

> manufacturers to make sure these things are going to exist.

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.

> scheduled between real-time packets, and the list of candidates could

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.

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

> I don't see the need to pursue separate efforts on CAR and PrRtAdv in

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.

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

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

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 30 Sep 2002 19:10:01 -0700

Rajeev,

> "universally implementable" is a function of time!

It is also a function of how tightly the specification is written, so
manufacturers don't have room for variations that cause interoperability
problems. The 802.11 specification is, unfortunatly, very loosely written in the
area of handover.

If we want MIP and 802.11 to work better together, we will have to convince the
802.11 committee to change the spec in a way that will facilitate
interoperability by tightening up the definition of what the firmware is allowed
to do.

> MAC address for communication. Any available "capabilities" can be

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.

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.

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

> being standardized in [mobile-ip].

The Seamoby design team is aware of the issue, and have been tasked with taking
it into account in their deliberations.

            jak

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Mon, 30 Sep 2002 19:21:27 -0700

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

like in:

http://www.ietf.org/internet-drafts/draft-gwon-mobileip-efwd-fmipv6-00.txt

alper