Subject: [Seamoby] CAR discovery

From: [email-masked]
Date: Tue, 26 Mar 2002 11:56:52 -0500

Hi all,

the recent discussion on CAR discovery gave me the impression that
there is some disconnection regarding the scope of CAR discovery.

You should keep in mind that CAR discovery is not dealing with final handover
decisions, it merely determines a set of geographically adjacent access routers that satifies MN's requirements at the time of requesting this 
information. Whether to use this set of ARs or not for the final decision, 
is up to the algorithm that does that decision. Said algorithm is called 
TAR selection and is out of scope of the CAR discovery work. 

However, for the openness of implementing any kind of TAR selection
schemes, the current requirements take care of this by demanding
the usability of CAR information by others (see exact wording in
the document). With that requirement, CAR discovery solutions must
enable to implement ANY kind of TAR selection, whether AR- or
MN-based. Hence, it does really not matter whether the final
authority of selection is the MN or any other network-related
entity, since this question is simply out of scope.

Regarding the requirements for CAR discovery, we therefore should
allow any kind of CAR discovery solutions as well, as long as they 
fulfill the basic job requirements, namely providing said set of CARs 
(under several constraints, such as preserving existing security models). Hence, any solution, either MN-based, AR-based, network-assisted, or 
whatever, should be feasible with the requirements, even though some 
people might not believe that certain solutions are possible or sufficient. Keep in mind that the best proof is the assessment of a provided solution. 

Hence, I still hope that the final requirements won't preclude
certain solutions by demanding certain functionality to be located
in certain entities.

Thanks,

Dirk

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

---

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

> decisions, it merely determines a set of geographically 
  > adjacent access routers that satifies MN's requirements at 
  > the time of requesting this 

=> Which entity runs the TAR ?? This MUST NOT 
be out of scope. This *is* the issue here, you 
can't leave the definition so loose.

  > MN-based. 

=> There are different requirements for each case. 
I don't think we should go through this _again_. 
Steve presentation was very clear I think and most
people agreed.

Hence, it does really not matter whether the final
  > entity, since this question is simply out of scope.

=> Of course it does, the algorithm might be out
of scope but NOT the entity running it. 
Are you seriously saying that the solutions is exactly 
the same regardless of who is running TAR?? 
Are you saying that my Cellular AR can locate my 
Starbucks AR just as easily as my MN can do it????
I hope not.

Hesham

---

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

Hesham

---

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

Hello Hesham,
Just a couple of quick clarifications to understand your
point better.

Regards,
Govind.

>can't leave the definition so loose.

[Govind] Hmm, Could you clarify this a little more on this for me.
Are you saying that the CAR discovery process which ends before
TAR selection starts, is affected by where the TAR selection
process resides. I agree that the CAR discovery output must be
fed as an input to TAR selection. Wouldn't doing that be enough?
Just for clarification. See the explanation of my concern later in this
email.

>Steve presentation was very clear I think and most
[Govind]I agree that based on whether CAR discovery is performed at
the AR or MN, some of the current requirements have to be re-worded
to remove any pro-AR bias. Therefore I agree that for example the
first requirement can become in some sense:

MUST find IP addresses of GAARs (in pseudo code)

if [L2 becaons received as input]
then map to appropriate GAAR IP address; /* how the mapping is done is
                                           particular to the solution */
else
Find IP address; /* How the IP address is found is particular to the 
solution */

wouldn't that cover the case you have in mind. However, this does
not talk about TAR selection at all. First the MN (in your case)
must get capabilities. If there are any other L2 beacons in the area
maybe it has to repeat the same process there too. Once its done with
the L2 becons (how many the MN chooses to look at is the MN's business)
CAR discovery ends. The MN passes on the information to the TAR selection 
process (which probably in your case resides in the MN) to make the final
decision right?  But what has the original requirement have to do
with the process of delivering the output of CAR discovery to the TAR 
selection process? As an example, the MN could push the output to the AR
to make the final decision and still the original requirement holds good
is it not?

I agree that a requirement is needed that the CAR discovery process
MUST have provisions to feed its output to the TAR selection process.
Will this additional requirement satisfy your concerns?

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

---

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

Hello Hesham,

Regards,
Govind.

---

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

> process resides. 

=> Of course. Process A is needed for process B, therefore
the node running B will need to run A or trigger someone
to run it and pass the results.

I agree that the CAR discovery output must be
  > Just for clarification. See the explanation of my concern 

=> There are different requirements depending on who
runs the CAR. I hope we can at least agree on this. 
What is the requirement for changes in physical
topology if the MN is running the CAR ???
If the physical location of a BS changes so that 
it doesn't have the coverage area where the MN is, 
then guess what, the MN's interface will not come up!
Nothing to do with CAR or any protocols. 

Hesham

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

---

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

Hesham

---

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

Hello Hesham,

>Nothing to do with CAR or any protocols.

[Govind] I agree with this and I thought that was the whole purpose
of pseudo code I had written in my previous mail with Requirement 1
as an example.
So maybe we can rephrase each requirement (if needed) with
suggestions from you and others. I can start it off by re-wording the
controversial requirements and post it on the list.

What I was trying to state in my earlier mail was that I did not understand 
how CAR discovery requrements
were affected by where the TAR selection resides. I thought using
the pseudo code I explained that we will be able to do this without
getting into the messy ground of TAR selection at this moment. This with
the additional statement that CAR discovery output MUST be made available to 
TAR selection whereever it resides. I am attaching the
pseudo-code just incase you missed it.

// Start paragraph from previous mail

[Govind]I agree that based on whether CAR discovery is performed at
the AR or MN, some of the current requirements have to be re-worded
to remove any pro-AR bias. Therefore I agree that for example the  first 
requirement can become in some sense:
MUST find IP addresses of GAARs (in pseudo code)
if [L2 becaons received as input]
then map to appropriate GAAR IP address; /* how the mapping
                                             is done

wouldn't that cover the case you have in mind. However, this does
not talk about TAR selection at all. First the MN (in your case)
must get capabilities. If there are any other L2 beacons in the area
maybe it has to repeat the same process there too. Once its done with
the L2 becons (how many the MN chooses to look at is the MN's business) CAR 
discovery ends. The MN passes on the information to the TAR selection 
process (which probably in your case resides in the MN) to make the final 
decision right?  But what has the original requirement have to do  with the 
process of delivering the output of CAR discovery to the TAR selection 
process? As an example, the MN could push the  output to the AR to make the 
final decision and still the original requirement holds good  is it not?

I agree that a requirement is needed that the CAR discovery process
MUST have provisions to feed its output to the TAR
selection process.
Will this additional requirement satisfy your concerns?

// End paragraph from previous mail

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

---

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

Hello Hesham,

---

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

Hello James,
Please see whether the following at least is reasonable enough
not to preclude AR based CAR discovery at this moment.

1. For a MN with a single 802.11 interface which is connected to an AR,
it can scan for other APs in the neighborhood. Can you tell me how
this MN will do capability discovery of the ARs connected to the other
APs in the neighborhood without loosing connectivity to the current
AR and AP?

2. Also, there are engineering considerations such as bandwidth and power 
constraints for the MN in adopting an AR-assisted (with help from the MN) 
CAR discovery process and an AR-unassisted CAR discovery process.

Is this fair enough?

Regards,
Govind.

>
>Sorry, Dirk, but I thought we settled this in Minneapolis.
>
>The point of requirements is to constrain the solution set sufficiently
>that the selected solution solves the problem in a way that makes
>engineering sense. I have not yet heard an argument as to why AR-based
>CAR discovery makes engineering sense.
>
>If you think the requirements should allow that possibility, then please
>give me an argument why.

>         jak

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

---

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

Hello James,

Is this fair enough?

Regards,
Govind.