Subject: Re: [Seamoby] Examples of CAR discovery

From: "Govind Krishnamurthi" <[email-masked]>
Date: Mon, 25 Mar 2002 16:57:24 -0500

James,
> > [Govind] What about WLAN -> WLAN?
> > the MN has one WLAN interface and it is connected to an AP.
> > Suppose it needs to be handed over to another AP. It can only
> > perceive the other L2 beacon, but cannot establish connectivity with
> > the other one without leaving the current interface(ok theoretically
> > this can be done without letting go of the previous L2 but I don't
>think
> > the specs allow this but I'm not sure. Anyways it is quite expensive
>in
> > terms of bandwidth, power and time).
> > I think CAR discovery
> > is very relevant in this scenario too. I don't think
> > that only inter-technology handovers alone are in CAR discovery's
>scope.
> > Clearly FMIPv6 and context transfer protocols are dependent on this.
> > Or am I missing something? I thought this was one of the main
> > intentions to start CAR discovery. I therefore
> > think it is totally incorrect to presume that CAR discovery is only
>for
> > inter-technology handovers.
> >
>
>The WLAN interface hands over the MN at Layer 2 if only WLAN is
>involved, even if the MN is doing the controlling. Why should CAR
>discovery be involved?
[Govind] I don't think my point came across clearly. In your mail
you had not mentioned the WLAN -> WLAN case at all which is considered
in FMIPv6 like L2 -> IP address translation. CAR discovery needs to be
involved if the MN has multiple options... esentially if the MN has to
choose the AR to handover to. I thought that was pretty clear.

>
>The only place where I can see CAR discovery involved for a single
>technology handover is for reverse address translation, as in Eunsoo's
>note.
>

[Govind] That CAR discovery is needed for reverse translation is quite
obvious from requirement 1 of the current requirement draft. I thought
that was the main idea behind the requirement. Anyways, my previous
mail was saying this too.

> > [Govind]  I am not sure
> > why network controlled handovers must be completely be rejected
>without
> > proper review. I think the point to note is that network controlled
> > handovers does not imply that the MN requirements are neglected.
> > However, I agree that CAR discovery is not involved here.
> >
>
>Because the MN *must* be involved if the handover is intertechnology. I
>don't see how it could be otherwise. Only the MN is in a position to
>know what interfaces it has if they are not powered on. Please let me
>know why we are having so much difficulty getting this point across.

[Govind] I agree that the MN *must* be involved too. The main disconnect
between us is that you assume that the MN has no role whatsoever
if the handover is network controlled. Clearly, the handover can be
controlled by the network, i.e., tell the MN when to disconnect etc but 
still take into account all of the MN's preferences. I don't understand
why we are having to get this point across too!  Regarding the MN
only knowing which interfaces are powered on. What big difference does
this make? If the network knows what interfaces the MN has then it can
advise it to power on at the appropriate time. If it is already powered
on the MN just discards this. If not it acts on it. If the card is not
inserted then it just discards the message too. What is the difficulty
that you see here. Maybe you can explain it.

>
> > [Govind] The network is made aware of the MN's requirements as part of
>its
> > Home AAA infrastructure (some kind of static profile for the MN)
> > and this is transferred to the AR. In this case the MN's requirements
> > are completely known to the MN. So the AR sends the ID of the AR
> > as best as it can judge to the MN and then the MN makes the final
>decision
> > anyways. Essentially give the MN a "veto" power for
> > the networks decision. Why wouldn't this work?
>
>Why not just give the MN a list of what's available and let it decide?
>What's the point of going through a convoluted AAA exchange?

[Govind] Of course, this is an option, thats what Example 2 gives. There
are performance tradeoffs for each case that thats my main point. Your 
contention is that any other approach is is infeasible which is not 
agreeable to me.

>The AAA exchange also might not be accurate. Suppose the MN is a laptop
>and the user forgot that day to put in their WLAN card. The AAA record
>might say that the MN's got WLAN, but, in fact, it doesn't. So the AR
>could hand the MN over to a medium which the MN can't access.

[Govind] I thought reachability information *from the MN *is part of TAR 
selection process. If the MN's WLAN card is not inserted, how do you
suppose reachability for WLAN APs are got from the MN. So why do you think 
the network will blindly just handover the MN to a WLAN network?

>
> >Again, I don't agree with
> > your notion that CAR discovery is suitable only for inter-technology
> > handovers , as I have described earlier (WLAN -> WLAN case)
> > in this mail. Also, clearly when we consider heterogeneous (in
>capability
> > and not in technology) ARs, the SIR information alone may not be
>enough.
> >
>
>Right, so I am willing to concede that there is a place for reverse
>address translation to support fast handovers, but I don't see this
>fairly limited use in the requirements. I don't think this involves any
>capabilities, mobile node preferences, or any other complications of
>that sort. It is fairly simple. The Layer 2 trigger on the AR says that
>the MN is about to move to a new AP or AR and all that the Layer 2
>trigger gives is a Layer 2 ID. The AR needs to map that into a Layer 3
>ID, namely an IP address. Simple. It works just like IPv6 ND or RARP.

[Govind] I don't understand your point. As I explained earlier, Requirement 
1 essentially deals with L2 to L3 mapping. Why doesn't MN's
preferences come into picture, if there are 10 APs connected to different 
ARs with different capabilities, ofcourse the MN's preferences
come into picture.

>
> > [Govind] Listening to the beacon, and connected to the L2 device is
> > two different things. You can't solicit unless you are connected.
> > Of course, if you have 20 such APs you have to connect to every one
>first
> > (and be authenticated and made sure it is authorized to roam
> > in the AR's net) before soliciting an RAdv.
> >
>
>We are considering the case where this activity is going on with a
>second interface, not with the same interface on which the MN already
>has IP service. Thus, what's the problem with it getting connected? If
>it is looking at a beacon, then presumably there's no power constraint.
>It doesn't have to give up IP service on the interface where IP service
>is already available to look at the new interface.

[Govind] First, I don't think there is any restriction on the applicability 
of CAR discovery based on whether there is one interface or two interfaces.
Are you saying listening passively to beacons vs attempting to connect
to the AP device and futher get a router solicitation have the same
power requirements? The main point I'm making is that if there are multiple 
APs available and the MN has to choose among them, then clearly
this has more power implications than just listening to the beacon and
passively forward it to a AR.

[snip]
>Like I said, if it can hear a beacon, then presumably there is no
>problem with power. Otherwise, it would not bother bringing up the
>interface to the point where it could hear the beacon. If the MN's got
>the interface card in, then presumably the user knows what kind of
>bandwidth to expect. Perhaps the link is congested, but I don't see CAR
>discovery as providing that kind of real time data to the MN. As for
>time, I don't see what that has to do with it. Maybe you could explain?

[Govind] Please see previous paragraph. My main point is listening to
the APs beacons imposes less power constraints than attaching to each one of 
the APs and get RtAdvs, capabilities, processing them and selecting. I am 
not going into a MN vs AR CAR discovery here.. but I am
pointing out that to say that there is no power constraints for the MN
involved in the process above vs. just listening to the beacon is incorrect 
IMHO.

Regards,
Govind.

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "James Kempf" <[email-masked]>
Date: Tue, 26 Mar 2002 09:26:51 -0800

> choose the AR to handover to. I thought that was pretty clear.

We seem not to be connecting.

The way handover works in WLAN is that the WLAN NIC selects one of the
currently visible BSSIDs and sends a Reassociation message (or an
Association message, the standard is not very clear). All this is
happening at Layer 2.
This is essentially no different than cellular.

Now, depending on the software driver for the NIC, it is possible with
some NICs to force handover to a particular BSSID. However, this is not
part of the standard and so it is not supported on all cards. So I don't
see much point in IETF developing a protocol for it.

The upshot of this is that the IP stack has essentially no say in the
matter about what AR the MN gets next, just like cellular. Once the link
is established, however, the IP stack can perform an IPv6 Router
Discovery to find out what routers are available. Alternatively, if the
NIC card provides the IP stack with a L2 trigger containing the L2
address of the next access point prior to handover, the MN can perform
FMIPv6 SolPrxyRtAdv to the current AR, providing it with the address.
The current AR can use the L2 ->IP address mapping support provided by
CAR discovery, do the HI/HAck, and return the result to the MN as
PrxyRtAdv.

Now, one could imagine a link layer in which there was a standardized
way for the IP layer to force handover to a particular access point.
This would still not require the AR to do the choosing. The CAR
information provided from the AR to the MN can be used by the MN to make
the choice. Why the MN would prefer one access point rather than another
in an intratechnology handover situation has always been a mystery to
me, but I do believe it could be supported.

Thus, I don't see the intraWLAN case as supporting the need for the AR
to make the decision either, though I am willing to concede that there
is a possible use for CAR discovery in intratechnology handover if the
L2 allows the IP layer to force handover.

> mail was saying this too.

OK.

> why we are having to get this point across too!

So here is the basic disagreement:

I don't see the point in a complicated protocol for the MN to "express
its preferences" to the AR, when the
AR can just hand over the CAR information to the MN and let the MN
choose.

>Regarding the MN
> this make?

It makes a big difference! If the interface isn't powered on and the AR
says to the MN "handover to that interface," the MN has just lost
network connectivity. Don't you agree?

>If the network knows what interfaces the MN has then it can

Please explain to me why you want to do all this complex signaling
between the network and the MN, when all
that is required is to simply send the MN the list of CARs and have it
do the selecting? What does all this
complexity buy us?

If we accept your proposal, then we are not just doing a CAR discovery
protocol but also a protocol for having the MN tell the network what
interfaces it has and what their current state is. This is just too
complicated. The MN knows this stuff, given the right information, it
can act on it accordingly without having to get the network involved. I
simply don't see what adding this level of complexity buys us.

> contention is that any other approach is is infeasible which is not

I'm not saying it is infeasible, I'm saying that a rational engineering
tradeoff between a complex protocol involving signaling MN interface
state and one letting the MN simply make the choice itself seems, to me
at least, to go in the direction of the latter.

Can you explain to me what, exactly, sending the MN's interface state
around buys us that we don't get by simply sending the CAR information
to the MN and letting it make the choice?

> the network will blindly just handover the MN to a WLAN network?

I don't understand your comment. If the WLAN card isn't in, the MN isn't
going to initiate a MIP handover to an interface that is not there.
Thus, if the MN is in control of an intertechnology handover, it won't
disconnect.
However, if the AR is in control of an intertechnology handover, how is
it supposed to know that the card isn't there?

From your comments above, I surmise you would like to see CAR discovery
include a protocol for communicating the MN's current interface state:
whether the card is there, whether it is powered on, etc., to the AR. My
contention is that this is unnecessarily complex and having the MN
control the handover would provide exactly the same functionality at
much less protocol complexity cost.

Perhaps I am missing something and there is some large benefit to adding
this complexity that I do not see. If so, what is it?

> ARs with different capabilities, ofcourse the MN's preferences

I think we agree on this, Govind. Let's move on to where we don't.

>The main point I'm making is that if there are multiple

Like I said, the MN, at the IP layer, does not today get to choose in a
single technology situation. A future L2 might have this capability, but
I do not see why that means the AR must get involved.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 26 Mar 2002 09:26:51 -0800

OK.

            jak