Subject: RE: [mobile-ip] I-D ACTION:draft-mccann-mobileip-80211fh-01.txt

From: "Karim El-Malki (EAB)" <[email-masked]>
Date: Wed, 6 Nov 2002 20:08:53 +0100

Hi Pete

Some comments below.

 > Even if you don't buy this argument, I think we would gain from
 > separating out the AR discovery problem from the tunnel establishment
 > problem.  I am not sure why we need to couple HI/HACK to the receipt
 > of a RtSolPr.  What if an MN wants to learn the IP addresses of
 > several neighboring ARs, but doesn't want to initiate the 
 > tunnel until
 > after it has moved?  It seems like we should let F-BU take care of
 > tunnel establishment and packet forwarding initiation.  Discovery
 > could be handled with CAR (eventually) or maybe with link-layer
 > modifications to beacons or with just plain MIPv6 movement detection
 > if you don't have those other pieces done yet.

As we both know, RtSolPr is needed because the MN in many cases can't
directly receive RAs from the new AR. The spec correctly has a default way
to do movement detection and uses PrRtAdv to do that (in addition to L2
triggers). The MN doesn't have to send the F-BU immediately, it could send
it after moving. I wonder why it would need to do this rather than updating
the HA or local HA (i.e. MAP which is likely to be as close as the old AR)
but let's put this aside for the moment. The point is that the RtSolPr doesn't
have the effect you imply above.

 > 
 >  > - What good does removing this message do?? At least if people
 >  > have the right cards (like the one on my laptop), they can use 
 >  > this today. Why should we ban people from using this?
 > 
 > The good is to make the document simpler, so that it solves a problem
 > that we actually know how to solve, and which can work no matter what
 > firmware/driver architecture is in place.
 > 
 > I am not saying we should ban people from sending RtSolPr, just that
 > we don't have such a short-term need for it and we can standardize it
 > in a different document after a more careful consideration of how to
 > implement it on 802.11 networks.

Simplicity is good, but you can't cut down beyond a certain point otherwise
the document becomes incomplete. In fact, IMO adding the tunnel-based handover
made it much more complex than what Rajeev had earlier. Anyway, the point
is that since there are cards that allow mobile-based L2 triggers, RtSolPr
is needed. Also, 802.11 is a good starting point but I thought we agreed
that the basic FMIPv6 spec would not be based only on 802.11 requirements,
otherwise we'll have to do a new FMIPv6 spec per link-layer. I don't want to
get into the discussion of which other link-layers there may be, since there
won't be any link-layer which provides triggers if there's no IP protocol
like FMIPv6 requiring them. It would just get us nowhere. So I'm in favour of
not hacking the basic FMIPv6 spec to pieces and let the implementers finish
the job they have started. There are people who are implementing it.

Rgds
/Karim

---

From: Pete McCann <[email-masked]>
Date: Wed, 6 Nov 2002 16:34:40 -0600

Hi, Karim,

 > have the effect you imply above.

From the draft-05:

   3.2. Tunnel Establishment

      When the PAR receives a RtSolPr message, it transmits a Handover
      Initiate (HI) message to NAR, after looking up the IP address
      corresponding to the link-layer identifier supplied by the MN.

Why should the discovery process trigger a tunnel to be established,
even if it is a tunnel that isn't used for packet forwarding?  The
reason might have something to do with CoA establishment - but why
can't we take care of that after the handoff has completed, now that
we have a mechanism to continue using PCOA from the new AR?

 > made it much more complex than what Rajeev had earlier.

I agree; I now think something like tunnel-based could be done at the
link layer, within IEEE.

 > Anyway, the point
 > like FMIPv6 requiring them. It would just get us nowhere.

It seems like this might be putting the cart before the horse.
Shouldn't we coordinate with the link layer standards bodies to make
sure what we need is in place?

 > So I'm in favour of

Of course it is up to the working group to decide what to do with the
draft; I have simply expressed my own personal opinion.  I am not
currently implementing FMIPv6 so I don't have much of a stake one way
or the other.

-Pete

---

From: "James Kempf" <[email-masked]>
Date: Wed, 6 Nov 2002 16:17:38 -0800

> directly receive RAs from the new AR.

Please see draft-ietf-seamoby-card-protocol-00.txt, a work in progress. The
design uses an ICMP extension, but not the same one as RtSolPr.

> The spec correctly has a default way
> but let's put this aside for the moment.

Because if the HA is on the other side of the ocean and the operator chooses not
to deploy a MAP, then it will take upwards of 160 ms to complete. If it is on
the other side of the continent, it might take 50-60 ms to complete.

Deploying a MAP is the operator's choice, and some operators won't want to do
it.

> made it much more complex than what Rajeev had earlier.

The tunnel has been there since the first draft. The difference is that it
initially ran to the mobile node, the new draft allows it to run just to the
access router, and provides for 3 way handover in case the mobile must move
quickly before RR completes.

> is needed.

But all cards do not. Thus, the spec would have to say "you can use this on X,Y,
and Z cards, but not on A, B, and C."

In addition, I believe the cards you are talking about only allow you to turn
off automatic firmware scanning. This means that the handover can be triggered
after the RtSolPr completes without having the firmware scanning happen, but it
does not get rid of the need to scan. The mobile node must scan in order to know
what access point channels are available. Since the scan typically takes up the
bulk of the L2 time during handover (see Bill Arbaugh's SigComm paper for more
detailed information), the the mobile node ends up losing packets (anywhere from
80-300 ms of them) during the scan prior to the anticipated signaling. The net
effect is no better performance than reactive handover, i.e. doing the signaling
after the handover completes.

>Also, 802.11 is a good starting point but I thought we agreed

The point is to complete a *standard* that is implementable using existing link
layers.

If the intent is to do something experimental, then the draft should become an
experimental RFC.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 6 Nov 2002 16:28:46 -0800

> I agree; I now think something like tunnel-based could be done at the

As mentioned in a previous response, the tunnel has been there since the first
FMIPv6 draft. The changes Rajeev made were to allow it to run to the router
instead of the MN, and three-way handover. The first allows the MN to get
packets under the old CoA while RR is completing, the second allows the MN to
continue receiving packets if it moves before RR completes.

As for a Layer 2 tunnel, please see "Link Layer Assisted Mobile IP Fast Handoff
Method Over Wireless LAN Networks," Hidetoshi Yokata, Akira Idoue, Toru
Hesagawa, Proceedings of MobiCom 2002.

Note that any such scheme will only work for a limited geographical area, due to
the coverage span of the bridge. And, bridged networks are typically fairly
difficult to manage, I'm told, so most network admins tend to avoid them. 802.11
is not like cdma2000, a couple of small changes to PPP won't fix this. :-)

> currently implementing FMIPv6 so I don't have much of a stake one way

I would certainly be in favor of a simplified draft, and taking the current
anticipated signaling + tunnel based to Experimental, as was done for FMIPv4,
until we've got more experience on different link layers.

            jak