Subject: Re: [Seamoby] Examples of CAR discovery

From: "Govind Krishnamurthi" <[email-masked]>
Date: Mon, 25 Mar 2002 11:32:25 -0500

James,
[snip]
>
>This statement sounds like some other entity beside the MN is doing the
>choosing (TAR selection).  I can't see the relevance of CAR discovery
>other than in the following cases:
>
>1) There are multiple wireless media options (e.g. cellular and WLAN)
>and one medium has wider coverage than the other (e.g. cellular is
>typically a WAN while WLAN is typically only for hotspots).
>2) The MN has two interfaces.
>3) The MN wants to keep one interface off while using the other.
>4) The MN wants to be informed when it enters or leaves the coverage
>area of the less dense coverage option.

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

>
>Only the MN is in a position to make a choice, that's what Steve's talk
>was all about. So I would rephrase this:
>
>     CAR discovery provides the MN with information on CARs for the MN to
>choose which TAR it wants to
>     hand over to.

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

[snip]

>Can you give me an example of when the network would want to select? In
>every case where I can think of needing CAR discovery, intertechnology
>handover is required and the MN must be involved in order to bring up
>and connect the new interface. For single technology handover, you don't
>need CAR discovery. In that case, either the network or the MN can do
>it, but the choice of next AR is predetermined by the Layer 2 power
>characteristics.

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

>
> > - CAR discovery does not force any handoffs and it does not advocate
>any
> > network-based handoff decision making.
> >
>
>OK, but like I said, I don't see the relevence to network handover to
>CAR discovery.

[Govind]
Well CAR discovery helps in the handover decision, it does not matter
whether the handover is network controlled or mobile controlled.
[snip]
>
>If MN can hear the beacon, why doesn't it simply solicit a router
>advert? There's no need for the current AR to get involved.

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

[snip]
>This is too complicated. After solcitiing the new RA, the MN can decide
>whether to connect or not.
>What's the point of all this communication with the old AR when the MN
>can already hear the
>new one?

[Govind] Of course it can blindly connect to the first AP it hears.
But are we proposing that? We are giving the MN an option to make the best
choice it can under the circumstances. Yes what you propose is true
but there are bandwidth, time and power issues to take into consideration.
[snip]
> >
>
>Why is this any different than Example 1? If the MN can get a beacon,
>why can't it solicit an RA? And if it can't solicit an RA, then what is
>the point of the MN even bringing up the interface to get a beacon? It
>should just leave the interface down and use CAR discovery with the
>current AR to find out if there are any routers on the other medium
>around.

[Govind] Example 2 can refer to the case when there are two interfaces
in the MN and in Example 1 there is just one. Example 1 could mean
that the MN has to disconnect from the previous L2 device before attaching
to the new one. Another difference is that Example 2 implies higher 
bandwidth,
time and power requirements. Example 1 can use FMIPv6.

[snip]
> > Example 3:
> > ----------
> >
> > Here MN is connected to cellular network over one interface and its
>other
> > interface (WLAN) is sleeping for power saving purposes.
> >
>
>This is the only example I think makes sense.

[Govind] I disagree, as explained before.
[snip]
>
>The current AR doesn't have to be involved if the MN periodically polls.
>That's an implementation assumption.

[Govind] Yes I agree, it is an optimization when using the network
to help the MN to turn on the interface only when there is a possibility
of finding a particular technology, as well as it can fine tuned
to wake up only when the particular AR can support its requirements
and it is authorized to roam. In other words periodic waking up is more
power consuming than selective waking up.

Regards,
Govind.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

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

---

From: "James Kempf" <[email-masked]>
Date: Mon, 25 Mar 2002 12:17:49 -0800

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

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.

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

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

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.

>Again, I don't agree with

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.

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

> but there are bandwidth, time and power issues to take into
consideration.

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?

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 25 Mar 2002 12:17:49 -0800

jak