Subject: [Seamoby] CARD feeding TAR selection issue

From: [email-masked]
Date: Sun, 5 Jan 2003 17:45:52 -0500

Hi all:

In order to proceed with next version of CARD draft, the design team would like to seek WG consensus on the following way of CARD operation, so that it can be used for TAR selection.

TAR selection is defined as selecting a unique AR for handoff from a set of CARs. For this, TAR selection module needs access to CAR identities and their capabilities. TAR selection module resides in the MN.

Base protocol:
--------------

Step 1: MN collects the identities of CARs (after listening to AP beacons from them) and their capabilities using CARD protocol. For this, MN queries either current AR or new AR (depending upon whether is it doing CARD in MN orchestrated or network assisted mode) and receives this information. For a given CAR, its entire capability set is provided to MN.

Step 2: MN runs TAR selection algorithm to choose TAR at the time of handoff.

Optional optimizations to the base protocol:
--------------------------------------------

Capability pre-filtering:

Step 1A: To avoid sending whole capability set of any CAR to MN, especially if MN is not interested in all those capabilities, in the CARD query MN can specify the capabilities that it is interested in receiving (by specifying capability attributes).

Step 1B: Even when capabilities of interest are specified by MN in query, to avoid sending information on CARs that MN is not obviously going to like, MN can also specify in the query to send CAR information if the capability of interest is above a threshold (attribute being greater than some value).

Network policies:

Network policies (in network assisted CARD) can be implemented indirectly by current AR. In other words, current AR may not send information about certain CARs to MN, if network policy in unfavorable to those CARs. In an extreme case, if network sends to MN information about only one CAR, it is tantamount to performing TAR selection on current AR.

Please provide your feedback on this. 

Thanks,

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

---

From: "Xiaoming Wang" <[email-masked]>
Date: Mon, 6 Jan 2003 09:13:53 +0900

> Network policies:
>
> Network policies (in network assisted CARD) can be implemented indirectly
by current AR. In other words, current AR may not send information about
certain CARs to MN, if network policy in unfavorable to those CARs. In an
extreme case, if network sends to MN information about only one CAR, it is
tantamount to performing TAR selection on current AR.

This optimization doesn't work when MN queries new ARs directly. Therefore
these policies should not be depended on by current AR in order to filter
unfavorable CARs.

---

From: "Xiaoming Wang" <[email-masked]>
Date: Mon, 6 Jan 2003 09:13:53 +0900

---

From: Pat Calhoun <[email-masked]>
Date: 05 Jan 2003 05:36:01 -0800

> Step 1: MN collects the identities of CARs (after listening to AP beacons from them) and their capabilities using CARD protocol. For this, MN queries either current AR or new AR (depending upon whe…

There are link layers that do not allow more than one link layer
connection at any given time, and although the beacons could be
received, as they are on a special channel. In these conditions, how
would the mobile receive CARD packets?

PatC

---

From: Pat Calhoun <[email-masked]>
Date: 05 Jan 2003 05:36:01 -0800

PatC

---

From: "James Kempf" <[email-masked]>
Date: Mon, 6 Jan 2003 11:48:18 -0800

> Step 1A: To avoid sending whole capability set of any CAR to MN, especially if
MN is not interested in all those capabilities, in the CARD query MN can specify
the capabilities that it is interested in receiving (by specifying capability
attributes).

Agree.

> Step 1B: Even when capabilities of interest are specified by MN in query, to
avoid sending information on CARs that MN is not obviously going to like, MN can
also specify in the query to send CAR information if the capability of interest
is above a threshold (attribute being greater than some value).

My experience suggests that this is a slippery slope towards a generalized
predicate grammer. I can't see this saving the MN much, and the complexity in
code more than overwhelms any advantage.

> Network policies (in network assisted CARD) can be implemented indirectly by
current AR. In other words, current AR may not send information about certain
CARs to MN, if network policy in unfavorable to those CARs. In an extreme case,
if network sends to MN information about only one CAR, it is tantamount to
performing TAR selection on current AR.

Hmm, I'm not sure I understand the motivation for this requirement. Could you
clarify?

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 6 Jan 2003 11:48:18 -0800

Agree.

            jak