Subject: [Seamoby] Examples of CAR discovery

From: "Hemant Chaskar" <[email-masked]>
Date: Sun, 24 Mar 2002 21:33:50

Hi all:

After the CAR discovery discussion in IETF53, it seems that we need to 
emphasize certain points about CAR discovery. They are as follows:

- CAR discovery always considers MN requirements while choosing CARs from 
GAARs.

- CAR discovery _does not_ make any handoff decisions. It merely chooses 
CARs (by matching MN's requirements with GAARs' capabilities) and makes this 
information available to TAR selection algorithms. TAR selection algorithms 
(whether they reside in MN or network or both) make decision about TAR for 
handoff.

- CAR discovery does not force any handoffs and it does not advocate any 
network-based handoff decision making.

- The problem statement does not advocate any specific way (network-based or 
MN-based or hybrid) of performing CAR discovery.

Below are some examples of CAR discovery (two of them are paraphrased from 
the issues draft) that emphasize above points. They are for illustrative 
purposes only and not to advocate any solution. Such examples may be useful 
for discussing CAR discovery topic further.

Example 1:
----------

Here, an MN connected to AR_current hears a beacon from a nearby access
point (AP_new). Note that this beacon may not contain the IP address of
AR_new that governs this AP_new. MN passes on this beacon information to
AR_current, and AR_current has to map it to the IP address of AR_new.
AR_current then compares the capabilities of AR_new with the
requirements expressed by MN. These requirements are expressed by MN
prior to handoff and are made available to AR_current for CAR discovery.
If good match is found, AR_current deems AR_new as a CAR. A similar
process could occur for every AP beacon heard by MN and other CARs could
be discovered as well. CAR discovery ends here.

CAR discovery output, i.e., this set of CARs, is one parameter used by
the target AR (TAR) selection algorithm. The output of TAR selection
decides where the MN actually hands off to. It could even be to an AR
different than CARs discovered as above. This TAR selection algorithm
may reside in the MN and/or the AR. Depending upon implementation of TAR
selection process, the CAR IDs (possibly along with their capabilities)
may have to be sent to the MN for selection.

Example 2:
----------

In this example, an MN can actually connect to the AP_new and then by
using, say, router solicitation, get the IP address of AR_new. It can
then solicit the capabilities of AR_new over the new IP layer connection
it has established and compare them with its requirements to identify
whether AR_new is a CAR. This process can be repeated for every beacon
heard by MN. Again CAR discovery ends here.

The output of CAR discovery is fed as one input to the TAR selection
algorithm, wherever it resides, and the TAR selection algorithm then
decides the AR that the MN will be handing off to.

There are performance differences between examples 1 and 2 with respect
to wireless bandwidth efficiency, speed of CAR discovery, utility
towards fast/smooth handoff protocols, MN power saving etc.

Example 3:
----------

Here MN is connected to cellular network over one interface and its other 
interface (WLAN) is sleeping for power saving purposes.

MN is attached to AR_current of cellular and "MN has expressed the 
requirement with AR_current" to let it know whenever hot-spot access 
opportunity exists. Note that, MN may not  be able to detect hot-spot access 
by itself as WLAN interface is sleeping for power saving. Since AR_current 
knows the capabilities of GAARs  (thanks to AR <-> GAAR capability exchange 
part of CAR discovery), it knows that WLAN access exists in neighborhood and 
it can intimate so to MN. It is then "upto the MN to decide" if it wants to 
fire up the WLAN interface and start scanning.

During scanning, MN can do further capability discovery either as in example 
1 (AR_current assisted) or example 2 (AR_current non-assisted) mentioned 
above. Note that, MN may detect more than one WLAN beacons during scanning 
as well. Also, it is worth noting that it is not the only option that CAR 
discovery information be available through WLAN interface. It could be 
obtained over cellular interface from AR_current (example 1) or over WLAN 
interface from GAAR (example 2). Performance/implementation tradeoffs will 
determine the best option. In fact, if AR_current's assistance is sought for 
CAR discovery (example 1), there may not be need to unnecessarily fire up 
WLAN interface if the capabilities of WLAN access do not match MN 
requirements. Even more power saving!

Please provide your feedback on these.

BR,
Hemant

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

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

---

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.

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

---

From: "Hemant Chaskar" <[email-masked]>
Date: Mon, 25 Mar 2002 16:45:05

Hi James:

Some comments in line:

>From: "James Kempf" <[email-masked]>
>To: "Hemant Chaskar" <[email-masked]>, <[email-masked]>
>Subject: Re: [Seamoby] Examples of CAR discovery
>Date: Sun, 24 Mar 2002 16:40:51 -0800
>
>choosing (TAR selection).

[HC] The statement is about "CAR discovery" (as seen from the first two 
words of the sentence), which is different from TAR selection, as stated in 
problem statement. Then, why would a statement made for CAR discovery imply 
anything for TAR selection?

I can't see the relevance of CAR discovery
>was all about.

[HC] Nobody is denying that MN should be given choice. But that does not 
mean that processor instructions for comparing MN requirements with AR 
capabilities need to be executed in MN. They could as well be executed in 
AR. Not executing processor instructions in MN does not mean that MN does 
not have choice. What matters is input to execution of instructions.

>choose which TAR it wants to

[HC] That is good. But it is not a "rephrase", it is a "different" 
statement. What I was talking about is "providing MN requirements to CAR 
discovery module", what you are saying in above statement is "providing CAR 
output to MN". Both are different, but I think both need to be there.

>whether to connect or not.

[HC] I disagree that this is complicated. It is fairly simple: Listen to 
beacon - grab AP id - send to AR_current - wait for CAR ID. This is very 
time and power efficient, and also, can feed into fast/seamless handoff 
protocols.

>What's the point of all this communication with the old AR when the MN

[HC] It hears the new AP (e.g. an RF broadcast channel), not the new AR yet. 
Various things need to happen including many message exchanges over wireless 
before MN can be deemed to be listening to new AR.

>why can't it solicit an RA?

[HC] As I said earlier, AP beacon and AR beacon are different things. In 
example 1, MN hears AP beacon, in example 2, it hears AR beacon.

>And if it can't solicit an RA, then what is

[HC] Periodic polling is power inefficient compared to selecting awakeing. 
Also, waking up for WLAN beacons that are not willing to provide you service 
is not efficient.

BR,
Hemant

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

---

From: "Hemant Chaskar" <[email-masked]>
Date: Mon, 25 Mar 2002 16:45:05

Hi James:

BR,
Hemant

---

From: "Hemant Chaskar" <[email-masked]>
Date: Mon, 25 Mar 2002 21:32:33

Hi:

Some comments below:

>To: "Eunsoo Shim" <[email-masked]>, <[email-masked]>
>Date: Mon, 25 Mar 2002 11:03:08 -0800
>
> > Please just let me remind you that the CAR discovery protocol also
>provides
> > mapping of L2 ID to IP address of the new AR which is necessary for
>the
> > low-latency handoff mechanism proposed in the MobileIP WG. So there is
>a
> > case CAR discovery is helpful for single technology handovers.
> >
>
>OK, so what you are saying is that there are two cases:
>
>1) Provding the MN with CAR information on what choices are available
>or, possibly, when the MN moves into an area where a new choice is
>possible, like moving into a hot spot area, for MNs that have multiple
>interfaces.
>
>2) Providing the AR with reverse address translation for CARs for MNs
>that have single interfaces and want fast handover support.
>

>I agree.
>
>I don't get the feeling that these two cases are clearly delineated in
>the requirements. In fact, they seem to me like they are really two
>separate protocols.

[HC] From the requirements perspective, what all the recent discussion is 
about is probably the following requirement text (with supporting line that 
CAR discovery is about comparing MN's requirements with GAAR capabilities 
and slecting CARs from GAARs):

"CAR discovery output MUST be retrievable, possibly selectively, by MN".
Also, I assume that there will the the following requirement as well (I 
think that this was posted before IETF53 and I also saw some WG members 
endorse it in IETF53 meeting): "MN requirements MUST be made available for 
CAR discovery".

This would mandate a CAR discovery functionality as follows:

MN Requirements --(parameters)--> CAR Discovery Module --(output)--> MN
                                       ^
                                       |
                                       |
                         Capability information about GAARs

Again, "CAR discovery module" can reside completely in MN, completely in AR 
or combination depending upon environment, availability of multiplicity of 
interfaces with MN etc. Further, the nature of MN requirements input and 
corresponding output depends upon the environement in which CAR discovery is 
being used. Also, whether the solution is organized into seperate protocols 
or single protocol is a solution-specific aspect.

(Note: The first requirement in requiremnet spec already says the address 
translation part. We can keep it so given its importance for fast/seamless 
handoffs, though it can be subsumed into above generic model (with "one 
parameter = L2 id", "one capability information about GAARs = L2 to IP addr. 
maps" and "output=IP address of CAR").)

>
> > I understand the IETF is pro-end-point-control. Anyway, regarding your
> > question, couldn't we imagine a case when a network provider wants do
>a kind
> > of load-balancing between different access networks in the wireless
>overlay
> > network?
> >
>
>Sure, but I think that's a very special case. The more general case (and
>in fact, the case that is showing up *today*) is that one network
>provider owns one medium and the other another. Example: at the airport,
>the cellular provider owns the CDMA network and some WLAN provider owns
>the WLAN network.

[HC]There is a concept of operator owned WLAN that is actually catching up. 
Some systems are already rolled out in Europe if I am not mistaken. So, both 
cases are very important - two media owned by two operators and two media 
owned by single operator.

BR,
Hemant

---

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

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

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

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

>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

---

From: "Hemant Chaskar" <[email-masked]>
Date: Mon, 25 Mar 2002 22:11:13

Hi James:

Some agreements and some disagreements below, marked as <HC>.

>To: "Hemant Chaskar" <[email-masked]>
>CC: "Kempf" <[email-masked]>
>Date: Mon, 25 Mar 2002 13:23:33 -0800
>
>
> > > > - CAR discovery always considers MN requirements while choosing
>CARs
> > >from
> > > > GAARs.
> > > >
> > >
>The relevance is that I would like the requirement to read as follows:
>
>     The CAR discovery protocol MUST provide the MN with enough
>information about GAARs, including information concerning capabilities,
>so that the MN can make a choice of which CAR to select.

<HC> As I already said, this requirements has to be there. I completely 
agree with you. But then, it is also important to unambiguously state that 
"MN requirements MUST be made available for CAR discovery if needed".

>
>No ambiguity about what is doing the selecting.
>
>So explain to me how the AR is supposed to know what kinds of interfaces
>the MN has? I don't know why this is so hard to understand, maybe I'm
>not explaining it well.

<HC> Is it too difficult for MN to tell so to AR? I do not think so. There 
is another possibility of having it in MN's service profile as well.

I can't see how the AR can know what interfaces
>the MN has on any particular day, so I can't possibly see a role for the
>AR in selecting an interface for the MN.
>
> >
>"CAR discovery module" is too ambiguous. I'd like the requirements to
>clearly state that the MN is the one in charge for intertechnology
>handover.

<HC> But then, "being in charge" is very ambiguous too. What does it 
precisely mean form an algorithmic perspective? If it precludes 
network-assisted CAR discovery, then I am not sure. I think network-assisted 
CAR discovery can be useful for certain intertechnology cases too. It does 
not immediately make sense to me to fix such a solution for inter-technology 
case.

>Otherwise, people start proposing complicated AAA transactions
>that are completely unnecessary and likely to fail anyway. See my above
>rewording. The AR *should not* and *cannot* have any role in selecting
>an interface for the MN in an intertechnology handover situation,
>because it *cannot* know a priori what interfaces the MN has.

[HC] That is like fixing a solution. In the requirements phase, we should 
give freedom to designers to design what is the best from performance 
perspective and specific environments. As long as requirements do not 
constrain above solution that you have in mind, what is the concern?

Also, MN can easily tell AR what interfaces it has (send on ICMP message for 
example) or this information can be statically configured in MN's service 
profile.

>
>What I am saying is your proposal for requirement language is likely to
>lead to unrealistic and complicated proposals for implementation, that
>have a high likelihood of failing in many cases.
>
>Why go through the AR on the other interface when you can simply solicit
>an RA on the new one? This is a standard IPv6 procedure. What's the
>point of introducing an entirely new procedure?
>
>Furthermore, how does the MN know to power up the second interface in
>the first place? The whole point of CAR discovery, IMHO, is to tell the
>MN exactly that. Once it knows, it can simply use standard IPv6/MIPv6
>mechanisms (or IPv4 if the network is a IPv4 network).

[HC] What your are saying here is one solution. I do not think that any of 
the requirements preclude it. But that does not mean that the requirements 
should be formulated around this solution.

>One of those things is that it solicits an RA on the new interface. This
>is not "many message exchanges" it is exactly 1, at the IP level. Or wer
>e you thinking of GPRS?

[HC] Sure, just like MN can go from GPRS to WLAN, it can go from WLAN to 
GPRS as well.

>Hemant, we are talking about sending traffic on which the MN already has
>active IP service, not a dormant mode MN.

[HC]MN already has IP traffic service on one interface. The second one is 
sleeping. Waking it up and sending IP level messages through it (when 
possibly not required) does consume power and takes processor MIPs.

>If you don't like polling, and I agree that it is inefficient, there are
>other ways to do it. We could have an update pushed to the MN when a new
>network medium becomes available, like when it enters a hotspot.

[HC] Yes, I think that is one example of the usefulness of network-assisted 
CAR discovery for inter-technology case. Polling is clearly very 
inefficient.

>             jak

---

From: "Hemant Chaskar" <[email-masked]>
Date: Tue, 26 Mar 2002 15:17:11

Hi Satish:

Some comments inline, marked as [HC].

>From: "Satish Jamadagni" <[email-masked]>
>To: "James Kempf" <[email-masked]>, <[email-masked]>
>Date: Tue, 26 Mar 2002 19:48:48 +0530
>
>Hi James,
> >
> > The requirments already have a statement about capabilities. Is this
> > what you
> > mean?
> >
>The only thing I wanted to convey was that in the CAR discovery process
>varied set of capabilities (also reflects the context supporting 
>capability)
>are exchanges at various times - Should not CT and CAR discovery be 
>combined
>( I dont know if some such discussion has happened earlier - if so please
>forgive me for bringing this again). One can exchange a macro level context
>support information as in the CT drafts during the GAARs and CARs stage -
>finally let the MN solicit a near complete set of Context support
>capabilities of the CARs to decide on a TAR - for all practical purposes 
>the
>CT would have been achieved by the time a TAR is decided..
>
>So in the requirements spec we should have a mandate to classify the so
>called context support capabilities into a hierarchy if possible (Such a
>thing has been initiated in the CT drafts) so that a varied level of
>information exchange can be initiated during the GAARs and CAR
>identification. For TAR the MN can then solicit the remaining set.

[HC] The requirement on the nature and formats of capabilities is still to 
be filled. Could you condense your thoughts above into text that may be 
useful for formulating such a requirement.

>
> > Are you talking about GPS co-ordinates or something? I don't see how the
> > MN could make use
> > of this information.
>
>MNs may not use that but the ARs can identify overlap radio coverage 
>regions
>(for both vertical and horizontal seamless handover support)

[HC] GPS may not be the best way to go about for identifying overlapping 
coverages. GPS can give co-ordinates of entities, not their coverages. The 
coverage patterns may vary based on environment, total power output at base 
station and so on. Also, that will be like going into solution space. 
Nonetheless, there is a consensus pending on the related requirement posted 
earlier which says:

"It MUST/SHOULD be possible for an AR or an MN (depending upon solution 
scenario) to verify that some other AR is indeed a GAAR."

Do you have a vote for or against this requrirement when you raise the above 
issue?

BR,
Hemant

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

---

From: "Hemant Chaskar" <[email-masked]>
Date: Tue, 26 Mar 2002 15:17:11

Hi Satish:

BR,
Hemant

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 26 Mar 2002 18:07:24 +0100

> scenario) to verify that some other AR is indeed a GAAR."

=> I think this statement will only make sense 
if you narrow the scope for the AR-AR protocol
to only work within a small group of routers
within the same access tech and belonging to
the same operator. 

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 26 Mar 2002 18:07:24 +0100

Hesham

---

From: [email-masked]
Date: Tue, 26 Mar 2002 12:22:31 -0500

Hi James,

I prefer wording that specifically requires the MN to be involved in
getting the CAR information. Thus:

    The CAR discovery protocol MUST provide the MN with GAAR
information, along with capabilities.

[DOT] We currently have a requirement stating the usability of 
information. The question though is whether your requirement for 
instance in a network-assisted approach would mean that the current 
AR has to send the entire list of GAARs with capabilities to the MN 
or that the MN should be able to request this information. The former one
looks terribly inefficient to me when it comes to larger capability sets.
The latter one is providing-on-request. As I said this is already in the 
requirements in terms of usability of information.

This is clear and unambiguous about what network entity is in control
during an intertechnology handover.

[DOT] Again as a reminder, TAR selection is not within the scope of
CAR discovery, so it should be possible to implement ANY kind of
TAR selection. Whether in your model, the MN is 'in control' or
'in charge' doesn't really matter as long as we don't define
TAR selection as being in scope, and therefore as to be addressed.

Regards,

Dirk

---

From: "Hemant Chaskar" <[email-masked]>
Date: Tue, 26 Mar 2002 17:19:07

Hi James:

This looks good to me, but with a small attention to detail:

What if MN does not want to receive such information or does not want to 
receive a part of it. Then, CAR discovery should not blast it on MN. To 
avoid this, we can slightly rephrase it as:

"The CAR discovery protocol MUST provide the MN with GAAR information, along 
with capabilities, *whenever and as required by MN*."

BR,
Hemant

>Date: Tue, 26 Mar 2002 08:33:18 -0800
>
>Hemant,
>
>----- Original Message -----
>From: "Hemant Chaskar" <[email-masked]>
>To: <[email-masked]>
>Sent: Monday, March 25, 2002 9:32 PM

---

From: "Hemant Chaskar" <[email-masked]>
Date: Tue, 26 Mar 2002 17:25:38

Hi Hesham:

I do not think so. There are ways to use Geospace information to do this for 
inter-tech and inter-admin handovers as well. But I do not want to talk 
about solutions now. The issue is, whether this requirement is 
MAY/SHOULD/MUST or REMOVE, from the protocol functionality perspective.

Hemant

>From: "Hesham Soliman (ERA)" <[email-masked]>
>To: "'Hemant Chaskar'" <[email-masked]>, [email-masked]
>Subject: RE: [Seamoby] Examples of CAR discovery
>Date: Tue, 26 Mar 2002 18:07:24 +0100
>

---

From: "Hemant Chaskar" <[email-masked]>
Date: Tue, 26 Mar 2002 17:25:38

Hi Hesham:

Hemant

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 26 Mar 2002 19:25:22 +0100

> inter-tech and inter-admin handovers as well. 

=> Come on... Geospace to get information about 
the WLAN in starbucks ?? 

Hesham

But I do not 
  > want to talk

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 26 Mar 2002 19:25:22 +0100

Hesham

But I do not

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Tue, 26 Mar 2002 13:16:03 -0500

James,

>We seem not to be connecting.

[Govind] I agree and thats what makes any technical discussion interesting 
:)
>OK.

[Govind] We agree. Good!
> > 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.

[Govind] First, I don't think that it is a "complicated" protocol
as you suggest. As I pointed out it could just be part of the MN's profile. 
Second, pushing capabilities down to the MN for its decision
has power,bandwidth and time considerations which one may want to consider. 
Again, I am not saying that what you say is not an option. But
saying that the MN MUST be the only one deciding the TAR restricts
the field totally which I think is rather pre-mature.

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

[Govind] I don't understand, how a "working" TAR selection algorithm which 
has MN reachability information as one input will allow this to happen.

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

[Govind] First, I disagree that this is complex. All it requires is
match what APs are available in the neighborhood to what the MN has.
What does this buy us as against pushing everything to the MN: saving power 
for the MN. Saving wireless bandwidth is another. But again, the main 
disconnect between you and me is not
disagreeing with what you propose as the solution but your seeming 
disagreement with any other option.
BTW, aren't we transgressing a bit
too much into solution and TAR selection phase. So I propose that we
have this discussion at a later stage, because we are going to have it
then again :)

>
>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.
[Govind] But unless the CAR discovery protocol knows what the requirements 
for the MN are how does it decide what the CARs for the MN
are? If you read the definition of CAR it says GAARs whose capabilities
can satisfy the MN's requirements As I said, telling the MN's interface 
states is not necessary at all.

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.

[Govind] See above.

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

[Govind] Again without accepting that complexity of the protocol is very
high :), we should also make sure what effect this decision has on the MN 
w.r.t to power and bandwidth.
>
>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?

[Govind] See above.

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

[Govind] No one is arguing that the reachbility information from the MN to 
APs is NOT an integral part of the TAR selection process.  Once this 
reachability information there it does not matter whether the TAR selection 
process resides in the network or the MN as far as your issue
is concerned.

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

[Govind] Nope I'm not saying this is necessary. For TAR selection the 
generic statement that the MN's requirements MUST be made known to CAR
discovery is more than enough.

Waking up an already awake device or trying to wake up an non-existent
device too such a requirement will just provide an optimization to
avoid some messages.

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

[Govind] Please see above.
>I think we agree on this, Govind. Let's move on to where we don't.

[Govind] Sure.
>
> >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.

[Govind] Well for this future L2 that you mention, I have explained this 
several times, if the MN has to
connect and disconnect to every AP then get IP connectivity, get capability 
info etc and then decide not to use it is a  waste of time and bandwidth. 
Therefore, to say that a solution that involves the current AR is feasible 
is not ok IMHO.
But again, I suggest lets leave this issue for now and get back to
it later when things are more clearer.

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 26 Mar 2002 19:24:19 +0100

> receive a part of it. Then, CAR discovery should not blast 
  > it on MN.

=> The MN will ignore it if it doesn't 
need it. 

 To 
  > with capabilities, *whenever and as required by MN*."
=> I disagree this is a very strange 
argument for removing the MN from the loop.
How does the AR know ?? Do we have to invent
another protocol that the MN should implement
to say no ?!

Can we please make this simple?

Hesham

---

From: "Hemant Chaskar" <[email-masked]>
Date: Tue, 26 Mar 2002 19:53:48

Hi Hesham:

Why do you think that anybody is trying to remove MN from loop? On the 
contrary, we are giving even more control to MN of deciding whether it wants 
to receive all the information, a part of it or none.

This fits well in line with giving end host absolute control over CAR 
discovery. If we do not have that extension to requirement, it seems that 
network is assuming on behalf of MN that MN does need all this information, 
when MN actually chooses not to. Of course, nothing prevents us from having 
a default case of blasting MN with all GAARs and their requirements.

Blindly blasting MN with requirements looks very inefficient to me. Further, 
this will in the future considerably restrict the detailedness of capability 
information that we can to consider.

Finally, you said below that MN can ignore it. But then, why spend wireless 
bandwidth and MN processing power (it takes processing power to ignore too) 
to receive unwanted information.

BR,
Hemant

>Date: Tue, 26 Mar 2002 19:24:19 +0100
>

---

From: "Hemant Chaskar" <[email-masked]>
Date: Tue, 26 Mar 2002 20:26:29

Sorry, some errors in the previous email. I meant "capabilites" and "not 
requirements" in some of the following sentences. Here is the corrected 
version:

-------
Hi Hesham:

This fits well in line with giving end host absolute control over CAR
discovery. If we do not have that extension to requirement, it seems that 
network is assuming on behalf of MN that MN does need all this
information, when MN actually chooses not to. Of course, nothing prevents us 
from having a default case of blasting MN with all GAARs and their 
capabilities.

Blindly blasting MN with GAAR capabilities looks very inefficient to me. 
Further, this will in the future considerably restrict the detailedness of 
capability information that we can to consider.

BR,
Hemant
--------------------------------------------

>To: [email-masked], [email-masked]
>Date: Tue, 26 Mar 2002 19:53:48
>
>Hi Hesham:
>

---

From: "Hemant Chaskar" <[email-masked]>
Date: Tue, 26 Mar 2002 20:26:29

-------
Hi Hesham:

BR,
Hemant

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Tue, 26 Mar 2002 16:15:05 -0500

James,
>
>But..but..
>
>How can you push into the MN's profile that on Tues. March 26 Mr. Fu
>forget his network card because he had to take his kid to the doctor?
>
>             jak
>

[Govind]
I have said this several times in my earlier mails but somehow the point was 
missed. So let me repeat again.

Assuming that the forgotten interface card is a WLAN card.

For TAR selection this does not matter that Mr Fu's
MN forgot his network card. This is because, the TAR selection
algorithm (trying to decide the new AR on this Tue March 26)
realizes this fact from the absence of reachability
(received from the MN) to WLAN APs. This is clearly an implementation
issue of the TAR selection algorithm.

Regards,
Govind.

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Tue, 26 Mar 2002 16:25:39 -0500

Sorry about  a typo in my previous mail. In my reply to James I meant, that 
it is  not necessary to inform the TAR selection algorithm that the card was 
removed.. I left out the "to inform the TAR selection" by mistake. Ofcourse 
it is important for the TAR selection algorithm but
I meant it can figure out the non availability of the interface card
on the fly.

Regards,
Govind.

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Tue, 26 Mar 2002 16:25:39 -0500

Regards,
Govind.

---

From: "Hemant Chaskar" <[email-masked]>
Date: Tue, 26 Mar 2002 21:42:37

Hi James:

I need to clarify the use of terms. Are you saying

(1) "GAARs and their capabilities MUST be sent to MN" or

(2) "CARs and their capabilities MUST be sent to MN".

I am in total disagreement with (1) for the reasons already stated below, I 
need to think more about (2).

Again, disagreement on (1) is not for the sake of optimization, but a 
fundamentally desirable feature from all angles - MN being in charge, 
wireless bandwidth and power.

BR,
Hemant

>To: "Hemant Chaskar" <[email-masked]>, 
><[email-masked]>,   <[email-masked]>
>Date: Tue, 26 Mar 2002 13:34:51 -0800
>
>Hemant,
>
>Premature optimization is never such a good idea. Let's leave it until
>later. Main issue is that the MN gets the CAR info and makes the TAR
>decision for ITHO.
>
>             jak
>
>To: <[email-masked]>; <[email-masked]>
>Sent: Tuesday, March 26, 2002 7:53 PM
>information,

---

From: "Hemant Chaskar" <[email-masked]>
Date: Tue, 26 Mar 2002 21:42:37

Hi James:

BR,
Hemant

---

From: "Hemant Chaskar" <[email-masked]>
Date: Tue, 26 Mar 2002 21:31:21

Hi James:

I am bit confused. First the extension to requirement sounded fine to you, 
now it is not. What is you final opinion?

I am not proposing any optimization. There is core flaw in the original 
requirement that you have proposed. The requirement you proposed means 
following: As soon as AR sees MN attached to it, it blasts MN with set of 
GAARs and their capabilities. This is clearly inefficient. This is like 
empowering the network to spam MN with possibly unwanted information.

Sometimes you say MN must be in charge and sometimes you give leeway to 
network to ignore MN. Why is that?

BR,
Hemant

>To: "Hesham Soliman \(ERA\)" <[email-masked]>,        
>"'Hemant Chaskar'" <[email-masked]>, <[email-masked]>
>Date: Tue, 26 Mar 2002 13:14:52 -0800
>
>
>Good point.
>I don't think we need to include optimizations in the requirements.
>Let's keep it simple.
>
>             jak
>
>

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Tue, 26 Mar 2002 17:33:33 -0500

James,
Because one of the inputs to TAR selection is the reachability information 
from the MN.  Irrespective of what the MN's profile
says if the MN does not inform that it can hear to a particular
AP (which is of a particular technology) then why will the TAR
selection algorithm hand over to the AR which controls that AP?
I thought reachability information from the MNs includes what
APs it can hear and if a interface is not present why will the MN
give information that it can hear an AP of a matching technology?

Clearly if the AR clearly intreprets this lack of information
from the MN as a signal to hand it over to that very AR then there
something wrong in the implementation.
There is no need for any complicated protocol. When you look at
the issues draft you will see that TAR selection has the reachability
information from the MN as one of its input.

>
>How can the TAR selection algorithm realize the absence of
>reachability? If the subscriber profile says that the MN has
>a WLAN card in and, in fact, it doesn't, then there either a) there
>needs
>to be some complicated protocol to tell the AR or b) the AR
>will make a mistake and move the MN to a medium that
>it currently doesn't have.
>
>I maintain that a) is too complicated and b) is an error.
>
>And, no, I don't think this is TBD by the TAR implementation. It
>lies at the heart of whether a network-only controlled algorithm
>would work for ITHO.

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Tue, 26 Mar 2002 17:33:33 -0500

James,

---

From: "Hemant Chaskar" <[email-masked]>
Date: Tue, 26 Mar 2002 22:36:22

Hi James:

Simplicity should not compromise fundamentally desirable features. The 
requirement is fundamentally flawed.

Hemant

>Date: Tue, 26 Mar 2002 14:17:26 -0800
>
>On second thought, let's keep it simple. Premature optimization often
>has unintended consequences.
>
>Sorry for the confusion. I'm having trouble keeping up with 200+ emails
>a day.
>
>             jak
>
>To: <[email-masked]>; <[email-masked]>
>Sent: Tuesday, March 26, 2002 9:31 PM

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Tue, 26 Mar 2002 18:03:13 -0500

James,
So now you agree that the AR can hand over the list of GAARs and
their capabilities to the MN (maybe only pass on those which satisfy
the MN requirements, which is what CAR discovery was originally about).

Which first implies that the network is taking care of CAR discovery.
This seems contradictory to your earlier mails saying that there is
no basis for network based CAR discovery. So are you now agreeing
that network based CAR discovery has its place?

Now to the current issue.
Why cant the AR send over the GAARs and their associated capabilities
to the MN for TAR selection.  This comes into the domain of
TAR selection. What you suggest can be done and has no basis on
where CAR discovery is being done. Similarly I can suggest a scheme,
in which for example,
wherein this final decision can be taken in the network after considering 
the MN's requirements  and the MN can have a veto power
on the decision. There are bandwidth and power considerations in both ( I 
have described this in an earlier mail in detail and hence don't want to go 
into it again).
But again this is out of scope of CAR discovery. All CAR discovery MUST
ensure is that its output is available for TAR selection irrespective
of where the TAR selection process resides.

Regards,
Govind.

>Right, so the AR hands over the list of GAAR and the MN figures out
>where it wants to go. What could be simpler?
>
>             jak
>
>From: "Govind Krishnamurthi" <[email-masked]>
>Sent: Tuesday, March 26, 2002 2:32 PM

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Tue, 26 Mar 2002 17:32:51 -0500

James,

---

From: "Hemant Chaskar" <[email-masked]>
Date: Tue, 26 Mar 2002 22:32:58

Hi Henrik:

There is no doubt that MN-centric is fundamental point. But, here is what I 
mean by this statement:

CAR discovery in its simplest terms is about comparing "MN requirements" 
with "GAAR capabilities". The "place" where this comparison is done 
(processor MIPs for comparison instructions are executed) is 
solution-specific and neither relevant in problem statement phase nor 
requirements phase.

An example where such comparison may occur in network is when there is only 
one interface on MN and it can listen only to radio beacons of surrounding 
access points. This is similar to break-before-make handoff case. Here, MN 
cannot receive capabilities of GAARs without letting go the previous 
connection. Do you think that such cases are not relevant and we should 
exclude such cases right at the problem statement/requirements stage?

BR,
Hemant

>From: "Henrik Levkowetz" <[email-masked]>
>Date: Tue, 26 Mar 2002 23:10:47 +0100
>
>Catching up on this thread. Sorry if this point has already
>been made:
>
>Hemant wrote:
>...<snip>>
>I believe this is pointing us in the wrong direction. I believe it is
>an essential part of CAR discovery that it is MN-centric. In other
>words, CAR discovery is the process of the Networks, Current Active
>Access Points and the MN itself (through stored information, scanning,
>this, that, and whatever other magic is available) providing *the MN*
>with information that *the MN* can use to assemble the most appropriate
>list of GAARs for *that MN* at that moment, from which *the MN* can
>destill its CARs.
>
>	Regards,
>		Henrik
>
>

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Tue, 26 Mar 2002 19:41:31 -0500

Henrik,
I am assuming nothing. I'm merely pointing out that the GAARs can
be discovered by the AR along with their capabilities. This is part
of CAR discovery. The other part being matching these capabilities
with the requirements of the MN. All I'm saying that it is possible
to do that in the AR too.

>Govind wrote:
>Here you seem to assume that one single AR has the full list of GAARs.
>I would argue that a flexible and scalable solution would have the final
>list of GAARs be composed from sublists provided by multiple ARs and the
>MN.

[Govind] This may be possible.

>It may be technically possible for all Currently Active Access Routers to
>transit their GAAR sublist to the MN, who transmit the lot together with
>its own GAAR sublist to one particular AR, who runs some algorithm and
>returns the result to the MN.
>
>But it certainly doesnt't seem either sensible or optimal to me.

[Govind] WHat do you mean currently active Access routers? The MN is
currently attached just to one AR and we are talking about the GAARs of
this currently attached AR to which the MN may potentially handoff too.

Second, I agree what you propose is neither sensible not optimal.
But I don't think anyone is suggesting that. To do this we have to
go into solution space. But transmitting the GAARs and their capabilties
to the MN has its bandwidth and power constraints too.
I am not arguing against one another. All I'm saying is we shouldn't
totally reject AR based CAR discovery now.

---

From: "Hemant Chaskar" <[email-masked]>
Date: Wed, 27 Mar 2002 00:48:15

Hi Henrik:

If we honestly think that the requirement does not oblige AR to blast all 
GAAR IDs and all of their capabilities to MN, why not say so clearly. Why do 
we need to hide this fact? We can come up with something else, if you do not 
like on-demand extension. I think without such extension the solution 
satisfying this requirement may have serious shortcomings that I described 
in my other email to James.

BR,
Hemant

>Date: Wed, 27 Mar 2002 00:06:37 +0100
>
>Hemant,
>
>	No, the requirement is just fine. It does not require *all* GAAR
>information, it does not require *on-demand operation*, it expresses 
>exactly
>what we are in a position to say about the matter now:
>
> > > > I am bit confused. First the extension to requirement sounded fine 
>to
> > >you,
> > > > following: As soon as AR sees MN attached to it, it blasts MN with 
>set
> > >of

---

From: "Hemant Chaskar" <[email-masked]>
Date: Wed, 27 Mar 2002 00:48:15

Hi Henrik:

BR,
Hemant

---

From: "Hemant Chaskar" <[email-masked]>
Date: Wed, 27 Mar 2002 01:04:46

Hi Henrik:

-------------------------------------snip------------------------------
>I think that designing for the one access technology case will cripple
>the solution.

[HC] I do not understand your comment. Are you essentially saying that "This 
case is irrelevant for CAR discovery" or "Completely AR unassisted CAR 
discovery is optimal for this case too".

IMHO neither requirements nor problem statement should ignore any use cases. 
If they do, it should be explicitly stated so in the spec, so that designers 
are not misguided to apply solutions to cases for which they are not 
designed.

BR,
Hemant

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 14:46:11 +0100

> > > mail was saying this too.

=> Again this is assuming a certain scenario (AR discovering
GAARs) which will only work in very limited cases. I.e.
few GAARs in one operator's domain.

  > as you suggest. As I pointed out it could just be part of 

=> What exactly would this profile say? And what impacts
does it have on privacy? 

  > has power,bandwidth and time considerations which one may 

=> only as much as an RA would have. Are you saying 
RAs should not be allowed?

  > Again, I am not saying that what you say is not an option. 

=> Good.

But
  > the field totally which I think is rather pre-mature.

=> How does it restrict it?

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 14:46:11 +0100

=> Good.

But

Hesham

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 10:06:04 -0500

Henrik,
Thanks for your comments. My comments inline.

>Ok.

[Govind] Thanks to you too. Essentially the key word is may.

>No, no, no, you cannot assume that only one of the N possible interfaces
>the MN may have is in use. At any given time, zero, N or any number in
>between of the interfaces may be in use, and may provide different lists
>of GAARs. Additionally, the MN's interfaces scanning for APs may result
>in GAARs which are not on any of the other lists.

[Govind] Again, I am not making any such assumption. You assume that
you will be able to get the GAAR ID directly in each of the interfaces..
For one they may be able to access only the L2 beacon of the respective
APs. For example in the 802.11b case, if you need to get the IP address
of the GAAR you first need to connect to the AP (authenticate, authorize 
etc) before soliciting for the router adv. Then you have to get the 
capabilities. If you have several such AP options then you have to do
the same with each before being able to decide. Whether this is ok or
not is debatable. Saying that the CAR discovery output MUST be pushed
to the MN is just one possible way. There are others possible. I am
just asking to not reject other solutions possible, at least not now.

>Ok.
>I'm arguing that we should reject CAR discovery which is not MN centric.
>The ARs will (must!) have their role in this, but an AR centric scheme
>does not seem to make sense, and I believe that it would be good to get
>that established.

[Govind] All CAR discovery does is identify "POSSIBLE" ARs for handovers. 
All CAR discovery has to do is feed into the TAR selection
algorithm. Where can you tell me in the above definitions of CAR discovery 
is it decided that the MN goes some place without its concern?

Next what do you mean by MN-centric? Does it mean that the MN's requirements 
(what ever they may be) are completely adhered to? If so
I completely agree. That is what is CAR discovery for. Whether you do
it in the network or the MN, by definition CARs are discovered based on
a capability - MN requirement match. If you mean that it MUST be done
at the MN then it is  not true, IMHO

If what you are alluding to is MN-centric TAR selection? I agree too.
But this this is clearly out of scope. All CAR discovery does is
feed into TAR selection. There might be a 100 inputs to take in
apart from the CAR discovery output. Why does it have to do with CAR 
discovery? Cant the requirement be
CAR discovery output MUST be made available to TAR selection?
This takes care of
the TAR selection being available in the MN or network. It depends on
the solution and should be discussed at that appropriate time is it not?

Thanks for reading my mail patiently.

Regards,
Govind.

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 10:06:04 -0500

Henrik,

Regards,
Govind.

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 10:26:20 -0500

Hesham,

>few GAARs in one operator's domain.

[Govind] Hesham, either you are not getting all my mails or you are
selectively answering them. I responded this to James, who specially
was talking about an L2 - L3 mapping when the MN passes it on to the
network is not expressed in the requirements. I was pointing out that
it was taken care of already. If you read the rest of this thread you
will see that he agrees too.
I don't think it is impossible to use a network based scheme to do
inter-domain CAR discovery. But again this goes into solution space
and I don't want to go into it now.
Having said that if you have a chance
please read the other mails to you which has explicitly talked about
your concerns about this not reflecting the case you illustrated
to me. I look forward to hearing from on that.
>=> What exactly would this profile say? And what impacts

[Govind]
The MN makes available to the network whatever it needs to for handover
decision thats all (this is the part required by CAR discovery. This
profile might make available other things, ofcourse.)
Privacy is an important issue and has to be tackled of course. But that
doesn't mean  we can't do it. Second, profile was just an example
to illustrate to James. There might be other ways of doing it.
Therefore right, we will look at this when the complete protocol is
presented each one of us. We should address this issue then and not
now. Otherwise this discussiong goes too much into solution space.
Precluding me from doing so right now implies that there is no way
of doing CAR discovery in the network which is I think a little premature 
now.

>RAs should not be allowed?

[Govind] Ofcourse not, if you intend to do CAR discovery that way
by all means you should be allowed to... (which again gets me to the
mail to you which talks about this matter.. please take a look at it
and let me know your comments). But there are performance tradeoffs when
you do this, because you the RA does not contain the capabilities that might 
be required by the MN. The capabilities have to be sent over
to the MN. This has to be done for each AP the MN wants to check.
This does conserve power, bandwidth and in a low bandwidth
environment, it does take time too depending on how many capabilities
are to be sent. Again, I am not preventing you to do it. If the
requirement does not allow you to do this I agree we should re-word it.
But it should allow me to do my way of implementing things too if I choose 
to. All I am asking is that, then we decide based on the protocol. There are 
performance tradeoffs to each scheme.

>   > Again, I am not saying that what you say is not an option.

[Govind] Thanks.
>=> How does it restrict it?

[Govind] The requirement as James proposed it says that CAR discovery
implies that the GAARs and the capabilities MUST be sent to the MN.
I don't think this is true and necessary. All CAR discovery must
do (where ever it resides) MUST make available its output to TAR selection 
(whereever that resides). That way we are satisfying everyone.

Hope you understand my concern.
Regards,
Govind.

---

From: [email-masked]
Date: Wed, 27 Mar 2002 11:03:23 -0500

Hi James,

[DOT] A simple solution is desirable but not if it floods my MN. A
requirement is not necessarily only about simplicity, it should take 
certain constraints into account. Distributing information that is
not necessary is a major constraint for me, in particular in wireless
environments. This is even more important since we haven't fully understood 
yet what capabilities actually might be. What is the amount of data we're 
talking about here? It heavily depends on the format we'll choose. Closing 
the door for solutions that allow the MN to say what information it actually 
wants looks very premature to me in this stage. If we later decide that the 
final solution will send the entire information, we can still do this (it simply 
means that the MN requests ALL information, i.e., the list of ALL GAARs plus
full capabilities), if it doesn't matter in terms of bandwidth and power
constraints.

Dirk

---

From: [email-masked]
Date: Wed, 27 Mar 2002 11:03:23 -0500

Hi James,

Dirk

---

From: [email-masked]
Date: Wed, 27 Mar 2002 11:05:28 -0500

Hi James,

[DOT] Premature non-optimization can be even worse, in particular in this
sense in which the actual data (and the amount) we're talking about is not
yet understood. So demanding the transmission of ALL data might have very ugly
consequences.

Regards,

Dirk

---

From: "Hemant Chaskar" <[email-masked]>
Date: Wed, 27 Mar 2002 16:11:12

Henrik:

I agree that you cannot focus on one case only, but then you cannot ignore 
any too. The current requirement of blasting MN blindly with volume of 
capability data does ingore implication on certain cases. Further this 
requirement is a MUST one and does not say whether it is applicable to only 
some cases or all cases.

Hemant

>Date: Wed, 27 Mar 2002 02:28:25 +0100
>
>Hemant wrote:
> >
> > Hi Henrik:
> >
> >
> > > > An example where such comparison may occur in network is when there 
>is
> > >only
> > > > access points. This is similar to break-before-make handoff case. 
>Here,
> > >MN
>No, i'm not saying this case is irrelevant, or that AR unassisted CAR 
>discovery
>is optimal ... for any case. I'm saying:
>
>Nobody's ignoring any use cases. But if you focus on one sample to the
>detriment of the rest, it will cripple your solution.
>
>	Regards,
>		Henrik
>
>
>

---

From: "Hemant Chaskar" <[email-masked]>
Date: Wed, 27 Mar 2002 16:11:12

Henrik:

Hemant

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 10:26:20 -0500

Hesham,

[Govind]

[Govind] Thanks.

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 17:28:22 +0100

> doesn't mean  we can't do it. 

=> I haven't seen an answert to my question yet. 
What would the profile say???

Second, profile was just an example
  > of doing CAR discovery in the network which is I think a 

=> No. You're avoiding a question that several people
have raised by saying let's do it later. The problem
here is that people are trying to say to you
that you're making it too complicated. 
So I think you need to show an example of this
profile. I'm sorry. but your answer above is
only confirming my concerns.

  > environment, it does take time too depending on how many 

=> We've discussed this in MPLS also. You only need an 
option in the RA. How frequently do you think 
the capabilities change? 
Depending on the link layer, the AR can also send
the RA only at the time of handover, so I don't
think the power conservation argument applies
here. 

  > requirement does not allow you to do this I agree we should 

=> That's all I've been asking for during the last
2 months. Can we just do it?!

  > to. 

=> It's not about your way or my way, it's about
placing reasonable requirements. If enough people
are concerned, then you need to justify why 
the requirements should implicitly exclude
certain scenarios. To quote Steve Deering in the meeting:
' I don't think I'm crazy if I say that there is 
a bias towards network controlled handovers'.

All I am asking is that, then we decide based on the 
  > protocol. There are 

=> I don't agree with the performance argument. 
As I continue to say, the RA can be sent
'on demand' if your L2 allows it. 
For ones that don't, BW is not a major issue.

  > (whereever that resides). 

=> Govind, sorry, but this is 'lawyer talk'. What 
do you mean 'wherever it resides' ????
It's either in the MN or the AR, there are no
mysteries here. Be specific, each case requires 
different requirements. Or put differently, 
the MN case requires less requirements.

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 17:28:22 +0100

Hesham

---

From: "Hemant Chaskar" <[email-masked]>
Date: Wed, 27 Mar 2002 16:25:24

Hi Henrik:

------------------snip---------------------------

>Neither.
>
>The "one access technology case" is the case where your mobile node only
>has one access technology, i.e. only one interface, and will not have more.
>
>Designing for this case in particular, instead of designing for the general
>case with multiple interfaces and technologies, will cripple our solution.
>
>Designing for the general case will permit handling this special case,
>and many many others.

[HC] I totally agree with your statement that we should list requirements 
for general case. But that is not what is happening here. Here requirements 
seem to be being formulated around a specific case of "two interface, both 
awake, no power constraint" case, without considering their impact on other 
cases.

BR,
Hemant

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 11:46:08 -0500

>What would the profile say???

[Govind] Profile could have information regarding cost preferences,
Personal preferences with types of network. Types of encryption algorithms 
that the MN would prefer etc.

>only confirming my concerns.

[Govind] Hesham, my only intention was to not divert the attention
of this thread into a matter which is clearly solution space.
If you want we can take it offline and I can attempt to convince you.

>think the power conservation argument applies

[Govind] Depends on the type of capability and how much granularity
you want to support in the changes. DO you have any idea of the capabilities 
when making such a statement? Of course if the MN gets blasted with 
capabilities and information about ALL GAARS and the MN has
to process it does cost machine cycles. I am suprised you dont view it
as an expense which can be avoided (if you choose to.. I am not saying that 
you should :))
>2 months. Can we just do it?!

[Govind] I am trying my best to do that. Please excuse me as
this email exchanges is taking up a lot of my time. But I apologize and
I will send out a reworded requirement soon.
>a bias towards network controlled handovers'.

[Govind] Exactly, and MN being blasted with GAARs and capabilities
without giving it an option not to want it is clearly "Crazy" too in
my opinion.
>For ones that don't, BW is not a major issue.
[Govind] I don't agree with you.

>the MN case requires less requirements.

[Govind] Hesham it is clearly not lawyer talk. TAR selection can
be in the network or MN or both. CAR discovery should be able to
feed its output to TAR selection. Whats difficult in that?

For example in the methodology you illustrated,
The MN gets the capabilities and identities of the GAARs and makes its
decision. Here CAR discovery and the TAR selection process lies in the
MN. Regarding the requirements I will reword what is available and send
it out in the next couple of days.

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 11:46:08 -0500

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 17:52:37 +0100

Govind, 

I won't answer all the mails below, since you ended 

  > it out in the next couple of days.

=> I'll let you come up with the new text, but
my curent concerns on the requirement is:

- The scope of AR-based CAR should be limited
to one operator's domain and one access technology. 

- The MN-based one is naturally limited by the number
of ARs it can hear. 

FWIW, I don't think that passing preferences to
the AR is a good idea or will ever scale. 

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 17:52:37 +0100

Govind, 

Hesham

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 27 Mar 2002 12:01:55 -0500

For what is worth I am in full agreement with what Hesham is saying below
about the scope of this.

George

-----Original Message-----
From: Hesham Soliman (ERA) [mailto:[email-masked]]
Sent: Wednesday, March 27, 2002 4:53 PM
To: 'Govind Krishnamurthi'; Hesham Soliman (ERA); [email-masked]
Subject: RE: [Seamoby] Examples of CAR discovery

....

Hesham

---

From: [email-masked]
Date: Wed, 27 Mar 2002 11:05:28 -0500

Hi James,

Regards,

Dirk

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 12:19:04 -0500

George,
Scope has already been addressed in the requirements right now
using the Inter (SHOULD) vs. Intra (MUST) domain scope of CAR discovery.

Second, to say that CAR discovery for Inter-technology (MUST) not being 
feasible (using scope as a reason) is again is incorrect IMHO. A simple 
counter example would be the same provider owning both technologies.

Having said that what is too much or acceptible bandwidth usage is very 
subjective. Thats why the option should rest with the MN whether to
accept it or not.

AR based or MN based, TAR selection is clearly limited by the number
of ARs the MN can be associated with.

MN-based CAR discovery is not only constrained by the number of ARs the
it can associate with, but how much tolerance the MN has with respect
to bandwidth and power requirements.

AR-assisted CAR discovery discovers probably all the GAARs in the AR's
domain and during TAR selection the MN can choose clearly based and what it 
can hear.
My two cents,
Govind.

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 12:19:04 -0500

George,

---

From: "Hemant Chaskar" <[email-masked]>
Date: Wed, 27 Mar 2002 17:49:24

Henrik:

If you are so sure of this interpretation, why don't we add it to 
requirement for clarity. Why should leave the requirement text to open 
interpretation.

Hemant

>From: "Henrik Levkowetz" <[email-masked]>
>Date: Wed, 27 Mar 2002 17:44:53 +0100
>
>Hemant,
>
>	Nobody is proposing to blast anybody blindly. This is a misapprehension.
>
>	Henrik
> >
> > Henrik:
> >
> > > > [HC] I do not understand your comment. Are you essentially saying 
>that
> > >"This
> > > > IMHO neither requirements nor problem statement should ignore any 
>use
> > >cases.

---

From: "Hemant Chaskar" <[email-masked]>
Date: Wed, 27 Mar 2002 17:51:30

Then you cannot make requirements for specific special cases. If you want to 
solve general case, you must consider impact of requirements for that 
general case on all special cases, at least the harmful part of it.

>Date: Wed, 27 Mar 2002 17:47:30 +0100
>
>Oh, this is interesting. I advocate solving the general case, and
>you interpret that as another particular case.
>
>Well, anyway, I advocate solving the general case, in case that did
>not come across clearly.
>
>	Best regards,
>		Henrik
>
> >
> > Hi Henrik:
> >

---

From: [email-masked]
Date: Wed, 27 Mar 2002 13:25:56 -0500

Henrik,

> requirement for clarity. Why should leave the requirement text to open

Because the requirement is perfectly clear as is.

	Henrik

[DOT] By all due respect, but this is your opinion. There is certain concern
on this mailing list that the text is not clear and allows for interpretation,
which makes it a controversial requirement. We shouldn't have those in a requirement
document, since we're going to have the same discussion when assessing solutions.

Dirk

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 19:45:12 +0100

> I agree with your comment about passing preferences to the 
  > AR. It won't
  > scale.
  > 
  > Actually, I would prefer to avoid any mention of AR based 
  > discovery in
  > the requirements. To me, this is an implementation issue. I 
  > would like
  > the requirements to clearly state that the MN is in charge. 
  > If it turns
  > out that a network based implemention makes some sense, 
  > then it can be
  > considered during the protocol design.
  > 
  > This was the message I took away from Steve's talk.

=> Yep! And I thought there was an overwhelming 
concensus for that in the meeting.

Hesham

  > From: "George Tsirtsis" <[email-masked]>
  > To: "'Hesham Soliman (ERA)'" <[email-masked]>;
  > <[email-masked]>
  > Sent: Wednesday, March 27, 2002 9:01 AM
  > > For what is worth I am in full agreement with what Hesham 
  > is saying
  > below
  > > about the scope of this.
  > >
  > > George
  > >

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 19:45:12 +0100

Hesham

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Wed, 27 Mar 2002 12:58:12 -0600

Hello James,
I have not been actively involved in CAR discussion, but
I am not sure how MN controlled CAR will really work when L2 handover 
is controlled by network. I do agree that in case of 
inter-technology or Mobile controlled handover, MN is the right
candidate to select AR. But mostly in cellular where network controlled
handover is used, I don't see how MN can select CAR. Won't 
there be inconsistency in L2 and L3 decision? Probably I might 
have missed some important discussion.    
regards,
ajoy

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Wednesday, March 27, 2002 12:42 PM
To: George Tsirtsis; 'Hesham Soliman \(ERA\)'; [email-masked]
Subject: Re: [Seamoby] Examples of CAR discovery

Hesham,

I agree with your comment about passing preferences to the AR. It won't
scale.

Actually, I would prefer to avoid any mention of AR based discovery in
the requirements. To me, this is an implementation issue. I would like
the requirements to clearly state that the MN is in charge. If it turns
out that a network based implemention makes some sense, then it can be
considered during the protocol design.

            jak

----- Original Message -----
From: "George Tsirtsis" <[email-masked]>
To: "'Hesham Soliman (ERA)'" <[email-masked]>;
<[email-masked]>

---

From: [email-masked]
Date: Wed, 27 Mar 2002 14:09:53 -0500

Henrik,

> document, since we're going to have the same discussion when assessing solutions.

Certainly this is my opinion! And going back, I seem to see that there is ONE
person who started out misapprehending this. That does not make it controversial, 
that makes it a misapprehension.

[DOT] Now don't let us drift into this, ok. First, I saw Govind, George, and myself
agreeing with Hemant's interpretation of this requirement. Second, the term "misapprehension"
sounds to me like an assumption that you're right with your interpretation, which I don't
want to comment further. The controversial point is exactly that there are different 
interpretations of a single requirement due to the chosen wording.

Dirk

---

From: [email-masked]
Date: Wed, 27 Mar 2002 14:09:53 -0500

Henrik,

Dirk

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 20:14:40 +0100

> interpretations of a single requirement due to the chosen wording.

=> No, it\s not the wording, it is a clear
bias towards a certain model. Govind agreed that
there is a bias, but you insist on keeping
the discussion within the wording domain. 
This is not going to help. We need clear requirements
and we need to distinguish between the entities 
invloved in the CAR discovery. We do not want requirements
that can be interpreted in several ways. 

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 27 Mar 2002 20:14:40 +0100

Hesham

---

From: [email-masked]
Date: Wed, 27 Mar 2002 14:19:00 -0500

Hesham,

[DOT] Before you start offending people like this on the mailing list,
start reading mails thoroughly before you answer. I did agree on the same 
bias and its removal from the requirements. And stating clear requirements that do not
allow different interpretations is exactly what the text above was about. Since you
agreed on this, too, we can start re-wording the requirement in a way that we can find
consensus. 

Dirk

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 14:23:15 -0500

>   > interpretations of a single requirement due to the chosen wording.

[Govind] Hesham, I think what I said earlier and what Dirk
is referring to are different requirements I think. This one deals
with what James posted about MNs being informed of all the detail.
What I told you was 3.4 which appears that AR might be doing things
and we should add something to reflect the CAR discovery done totally
by the MN too.

However, I do agree that James' requirement swings totally to the MN
side precluding any other option and I don't want that either.

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Wed, 27 Mar 2002 14:23:15 -0500

---

From: [email-masked]
Date: Wed, 27 Mar 2002 14:51:46 -0500

James,

[DOT] If we could word the requirements in a way that it still allows
network assistance, keeping in mind that the MN's requirements are
the overall constraint of the design, this would be fine. But the way it
has been proposed so far does not suffice to me. But at least I sense
a common understanding that it should still be possible to involve the
network in parts where it "makes sense", which could be related to avoiding
unnecessary information transfer for instance. The point in the current discussion
is, at least from my part, that we shouldn't replace AR-biased wordings
by MN-biased ones. It is the theme that counts, namely that it is the MN that makes
the final decision. Everything that does not allow this is not a good solution. 
But every requirement that does not allow solutions that would be compliant to 
this "theme" is not a good one either.

Dirk

---

From: [email-masked]
Date: Wed, 27 Mar 2002 14:51:46 -0500

James,

Dirk

---

From: "Hemant Chaskar" <[email-masked]>
Date: Wed, 27 Mar 2002 20:56:28

Hi:

The problem statement says "load balancing" as one example. How is router 
load information obtained from layer 2?

Hemant

>To: "Singh Ajoy-ASINGH1" <[email-masked]>,        "George Tsirtsis" 
><[email-masked]>,        "'Hesham Soliman \\\(ERA\\\)'" 
>Date: Wed, 27 Mar 2002 12:19:40 -0800
>
>Ajoy,
>
>You are right, CAR discovery won't be needed if the handover is network
>controlled. It will only be needed if the handover is mobile controlled,
>and it is really most needed for intertechnology handover. If the
>handover is network controlled, the Layer 2 protocol basically knows
>where the MN is going, since it is determined by power levels, and the
>MN gets moved.
>
>That's one reason why I am having a hard time understanding why people
>want anything at all in the requirements about network controlled
>handover.
>
>             jak
>
>From: "Singh Ajoy-ASINGH1" <[email-masked]>
>To: "'James Kempf'" <[email-masked]>; "George Tsirtsis"
><[email-masked]>; "'Hesham Soliman \(ERA\)'"
><[email-masked]>; <[email-masked]>
>Sent: Wednesday, March 27, 2002 10:58 AM

---

From: "Hemant Chaskar" <[email-masked]>
Date: Wed, 27 Mar 2002 20:56:28

Hi:

Hemant

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Thu, 28 Mar 2002 14:01:18 -0600

Hello Charlie,
Please find my in line clarification/question.  
regards,
ajoy

-----Original Message-----
From: Charlie Perkins [mailto:[email-masked]]
Sent: Wednesday, March 27, 2002 5:17 PM
To: [email-masked]
Subject: Re: [Seamoby] Examples of CAR discovery

Hello,

I am a lurker only, but occasionally I read the messages in this thread.
If somehow things have progressed past my original understanding,
I'd like to find that out.   So, a question:

James Kempf wrote:

> and it is really most needed for intertechnology handover.

Does this mean that the access points themselves cannot use CAR to
prepare for a network-controlled handover?  Darn ...!

>  If the handover is network controlled, the Layer 2 protocol basically
> knows

Handover can be controlled by things other than power levels!
As someone noted, it would be better to frame handover considerations
more general "resource consumption" requirements...

ajoy: Sure, you are correct. Handover can be initiated due to other 
reasons such as to optimize the radio and network resource 
consumption. But I think my question was regarding the applicability 
of mobile controlled access router discovery in a 
network that can only support network controlled L2 handover. 
I am still not sure how mobile controlled access router discovery 
will really work in these networks ? BTW, I am not talking 
about selecting one AR from a pool of ARs in a particular subnet. 
Please correct me if I am missing something here.  

Regards,
Charlie P.

---

From: Phillip Neumiller <[email-masked]>
Date: Fri, 29 Mar 2002 11:12:23 -0500

Hi,

Don't want to be a butinsky, but oh well.
> Hello again,
> > They can, but in a typical cellular system, they won't. The 
> access points
> >
> > don't move around much, so this can be preprogrammed into tables.
> 
> I'd like it if, eventually, availability of QoS would be considered
> a "Capability", and discoverable by way of this CAR protocol that
> is under discussion. Such information is not static.
> 
> Indeed, I'd like it if the actual qualifications for candidacy of an
> access router were _data_, separated from the actual discovery
> protocol, as far as possible.

I like what Charlie is saying here and that was my original thoughts with
contract NET protocols (CNP) being used to decide on the best handoff 
candidate based on vectors of metrics exchanged between the mobile and the
AR/AP (watcha callits).

Cheers,

phil
****************************************************************************
This e-mail is intended only for the addressee named above and may contain
confidential, proprietary or privileged information. If you are not the
named addressee or the person responsible for delivering the message to the
named addressee, please inform us promptly by reply e-mail, then delete the
e-mail and destroy any printed copy. The contents should not be disclosed to
anyone and no copies should be made. We take reasonable precautions to
ensure that our emails are virus free. However we accept no responsibility
for any virus transmitted by us and recommend that you subject any incoming
e-mail to your own virus checking procedures.

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 29 Mar 2002 17:11:20 -0600

Well,

don't know what a butinsky is (that phil is refering to :) )
, but that QoS capabilities
were what I had in mind as the most important capability
information to be shared or included in discovery process.

And yes, as Charlie mentioned, different access technologies
with different bandwidth is an important scenario here.

Madjid

-----Original Message-----
From: Phillip Neumiller [mailto:[email-masked]]
Sent: Friday, March 29, 2002 10:12 AM
To: 'Charlie Perkins'; James Kempf
Cc: [email-masked]
Subject: RE: [Seamoby] Examples of CAR discovery

Hi,

Cheers,

phil

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 29 Mar 2002 17:11:20 -0600

Well,

Madjid

-----Original Message-----
From: Phillip Neumiller [mailto:[email-masked]]
Sent: Friday, March 29, 2002 10:12 AM
To: 'Charlie Perkins'; James Kempf
Cc: [email-masked]
Subject: RE: [Seamoby] Examples of CAR discovery

Hi,

Cheers,

phil

---

From: "Hemant Chaskar" <[email-masked]>
Date: Sun, 31 Mar 2002 03:12:20

Hi:

As far as delegating QoS aspects of smooth handoff to NSIS is considered, 
the following statement that was discussed in the WG catches my attention 
when reading NSIS (rough) meeting minutes from IETF53.

[Quote:] "Regarding to the mobile IP, the hand of decision and trigger 
sources should be out of the scope of the NSIS. Thus the WG should rather 
focus only on "establishing" QoS after hand off."

The following statement from Mobile IP QoS requirements draft (WG document 
that has passed the last call) is interesting too:

[Quote:] "In this document, we assume that the target access router for
   MN's handover is already pinned down by other protocols. For
   example, Seamoby working group has started work on the candidate
   access router discovery protocols [3]. Thus, any QoS-capability
   specific negotiations that may affect the handover decision are
   outside the scope of QoS solution as such, rather need to be
   performed by candidate and target access router selection
   protocols."

BR,
Hemant

>To: "Charlie Perkins" <[email-masked]>
>CC: <[email-masked]>
>Date: Fri, 29 Mar 2002 19:10:03 -0800
>
> > If one access router has 5 Mb/s available, and another only has
> > 10 Kb/s available, I would like to get my streaming video from
> > the first access router.  I might be able to have the choice.
> >
>
>Wouldn't it be better to let the IP QoS signaling protocol handle this?
>I believe this is exactly what NSIS is working on,
>but John Loughny could say more.
>
> > IP is exactly the right place for this to be disseminated, assuming
> > that we even have IP QoS in the first place.
>
>I was speaking of last hop link capacity. I agree that IP is the right
>place to handle next to last hop QoS (i.e. DiffServ). I believe the NSIS
>charter also speaks about last hop QoS signaling as well. There is some
>interest in NSIS to tie Layer 2 QoS and  IP QoS together on the last
>hop, but there has not yet been much work done on it.
>
> > I do not think
> > that this information would typically change much over the
> > 10-150 milliseconds that it "should" take to accomplish a
> > handover.  If this is a problem, though, one could define a
> > "special" kind of CAR discovery protocol that makes the
> > candidate access router reserve the bandwidth for 200 milliseconds,
> > or else not claim that it has the bandwidth available.
> >
>
>I did not mean just during the handover. If the information provided by
>the CAR discovery protocol has a lifetime of 200 msec, then if the total
>L2 + L3 handover time is 40 ms, 5 mobile nodes could move into the cell
>during the time between when a mobile node gets its last CAR discovery
>update and when it decides to move to the cell. At that point, the QoS
>due to the new load may be below the decision point where the mobile
>node would want to move into the cell.
>
>                 jak
>
>
>

---

From: "Hemant Chaskar" <[email-masked]>
Date: Sun, 31 Mar 2002 16:29:04

Hi:

You are right, there is not one point in time that can probably be 
identified as handoff event in seamless handoffs. But, I think, in spirit, 
this means that NSIS protocol may no go looking for which access router is 
the best one for MN's handoff. Rather it will take the target access router 
as input and *establish* QoS from there.

Hemant

>From: "Phil Neumiller" <[email-masked]>
>Date: Sun, 31 Mar 2002 06:10:33 -0500
>
>Interesting...
>Sent: Sunday, March 31, 2002 3:12 AM
>Don't know who this quote is from, but clearly this show a
>mis-understanding.
>There should be no "after" handoff.  A seamless handoff will not have a
>before
>and after.  A big part of QoS to mobiles is making the handoff seamless.
>
>-pdn
>
>
>

---

From: "Hemant Chaskar" <[email-masked]>
Date: Sun, 31 Mar 2002 16:29:04

Hi:

Hemant