Subject: [Seamoby] CAR Discovery Requirements

From: [email-masked]
Date: Tue, 12 Mar 2002 13:48:47 -0500

Hi all,

I'd like to propose the following requirement to be added to the CAR discovery 
requirements list:

"3.xx Providing MN's requirement for Determination of CARs

The fundamental task of CAR discovery is to determine candidate
access routers (from the set of GAARs) that meet MN's requirements,
if known at the time of handoff. A CAR discovery protocol MUST 
determine a set of CARs that meet MN's requirements. For this, 
a CAR discovery protocol MUST provide means for the MN to express 
these requirements."

Thanks,

Dirk

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

---

From: [email-masked]
Date: Tue, 12 Mar 2002 16:06:36 -0500

Hi James,

I don't see that the requirement is addressing the distribution 
of the information. There is another requirement for this, namely
3.4. The present one is merely addressing that a solution has to 
match the set of GAAR+capabilities with MN's requirements to determine 
the set of CARs. This is essentially what CAR discovery is about, isn't 
it?

Whether you use existing protocols for certain parts is not
prohibited by the chosen wording. You might use AAA to express
the requirements. Still, a CAR discovery protocol has to match
these requirements onto the available GAAR+cap info. How this
is done depends on the solution.

Regards,

Dirk

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Tuesday, March 12, 2002 3:27 PM
To: Trossen Dirk (NRC/Boston); [email-masked]
Subject: Re: [Seamoby] CAR Discovery Requirements

Dirk,

</wg-chair-hat-off>

> a CAR discovery protocol MUST provide means for the MN to express 

I think this is confusing two issues:

    - Distribution of routing reachability and capability information.

    - Expression of MN requirements or rights.

The second issue may require, for example, AAA, or it 
may be implemented using an AAA protocol.

I think it would make more sense to keep these issues separate.

</wg-chair-hat-on>

            jak

---

From: [email-masked]
Date: Tue, 12 Mar 2002 16:49:58 -0500

Hi James,

some comments inline

What 3.4 states is:

    3.4. CAPABILITY DISCOVERY

    The other fundamental function of CAR discovery protocols is that of
    identifying the capabilities of GAARs. The protocol MUST provide
    functionality to allow ARs to discover their GAAR's capabilities.
These
    capabilities MUST be communicated in a secure fashion.

This says nothing about the MN's capability requirements.

[DOT] of course not since it aims at securely exchanging
capability information. That's why I wanted to address MN's
requirements in a separate protocol requirement.

In fact, if you look at the last item in Section 3 of
draft-ietf-seamoby-cardiscovery-issues-02.txt, TAR Selection Algorithm,
the selection of a target router, which would involve matching the MN's
requests with the AR capabilities, is explicitly excluded from the
problem
statement.

[DOT] The TAR Selection eventually picks one particular AR out of
the set of CARs. This 'picking' is out of scope of the CAR discovery.
If I look at the definition of CAR, namely 
"This is an AR that is a candidate for MN's handoff. CAR is necessarily 
a GAAR of the AR currently serving the MN, and also has the capability 
set required to serve the MN." 

and look at the fundamental task of CAR discovery, namely to determine a set of
CARs, it means logically for me that I also require means to express
these requirements and feed them into CAR discovery. This does not
mean that I need a new protocol for expressing these requirements.
If I look at CAR discovery as a black box, and I want to define the
requirements of this black box, to fulfill the implicit fundamental 
task that we put in the issues draft, namely 
"What is required is a protocol that would allow an AR or an MN to discover
the neighboring ARs whose capabilities meet the requirements of
a MN, thus becoming potential target ARs for handoff." (copied from
introduction of issues draft),
I came up with this requirement. It merely says, that CAR discovery has
to provide this set of CARs that would meet MN's requirement. For that,
I need means to express MN's requirements. It does not imply that we
have to invent the wheel again for this part, it merely has to be part
of this black box to fulfill its task.

Regards,

Dirk

---

From: [email-masked]
Date: Wed, 13 Mar 2002 10:54:03 -0500

Hi James,

comments inline...

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Tuesday, March 12, 2002 5:43 PM
To: Trossen Dirk (NRC/Boston); [email-masked]
Subject: Re: [Seamoby] CAR Discovery Requirements

Dirk,

Well, here we have a basic disagreement about what is involved in
TAR selection.

IMHO, TAR selection includes everything including communication
of MN requirements. The reason I believe this is because communication
of the requirements may require functions such as:

    - verifying that the MN is, in fact, authorized to get what it is
asking.

    - arranging for accounting information so that the owner of the MN
    can be billed appropriately for what it is asking.

    - authenticating the exchange with the MN so that the AR (or
whatever
    other network entity is involved in doing TAR selection) knows that
    they come from an authorized MN and not from a freeloader.

    - securing the exchange between the MN and the AR or other
    entity implementing the MN's selection.

These functions are separate from communicating routing reachability
and router capability information, even if the MN is involved in
propagating the reachability and capability information (as, I believe,
it may be in CAR discovery). The AAA functions are
completely orthogonal, as are the security functions.

[DOT] By all due respect, I'm kind of surprised to see these interpretations
at this stage of discussion. What I quoted in my previous email is the 
definition of CARs and the fundamental sentence in the problem statement.
In addition, here the definition of TAR selection:
"TAR Selection Algorithm

  The algorithm that determines a unique TAR for MN's handoff from
  the set of CARs. The exact nature and definition of this algorithm
  is outside the scope of this document.
" 
With all this information, available in the issues draft for quite a while,
I draw the following line
- discover GAARs and their capabilities
- determine set of CARs (i.e., subset of GAARs that fulfil MN's requirements)
- select a unique TAR from this set (i.e., TAR selection)
I don't see that much room for interpretation of the terms, at least this
interpretation should have been done at appropriate time of the discussion.

[DOT] Further, the requirement to provide means to express MN's requirements
to be used for the determination of the set of CARs (as I stated in my requirement)
does not imply that we have to invent a new protocol for this part of CAR discovery. 
If I want to solve the CAR discovery problem (which according to the issues draft
include the determination of CARs), I have to have means to express MN's
requirements. These 'means' might certainly be existing protocols. 

[DOT] More philosophically, the requirements are meant to define a protocol
that solves the CAR discovery problem. The design of such protocol should always
be done under the constraint to re-use as much existing functionality as possible.
However, the first and strongest requirement is to solve the problem. To do, I do
think that this requirement is needed.

> of this black box to fulfill its task.

Perhaps what we need is "requirements for TAR selection." One
requirement
is that the MN communicate its requirements. 

[DOT] Since TAR selection is out of scope, I don't see the necessity
and sense of such requirements. As I pointed out above, the need to
communicate MN's requirements is already required for the CAR
determination. 

There is no need to for the AR to know the MN's requirements just to select GAARs.

[DOT] On what basis do you want to select GAARs? If you plainly determine
a subset of GAARs that are reachable by the MN at time of handoff (is it 
that what you mean?), then you are not determining CARs according to the
definition of CARs. You are plainly selecting reachable GAARs.

Regards,

Dirk

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 14 Mar 2002 09:58:56 -0600

Sorry for the late response,

isn't MN's requirement spelled out in MN's user profile or
SLA or something else recorded in the policy server of the
MN's network? why does the MN has to express them again.
if the new network needs it (I don't know why it would in 
a CAR selection), then it can get it from old network, if the
old network needs, it gets it from policy server.
I think what this should concentrate on is:

CAR discovery protocol MUST provide means for signaling 
parameters needed for a TAR selection mechanims (regardless
of whether it is done at MN or at AR). 

I know that the selection process is out of scope, but providing
input for it should be in scope. signaling MN's requirements for
service is a different issue.

Regards,

Madjid

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 14 Mar 2002 09:58:56 -0600

Regards,

Madjid

---

From: [email-masked]
Date: Thu, 14 Mar 2002 11:50:56 -0500

Hi Madjid,

I'm not saying that MN's requirements have to be spelled out again.
'Means to express the requirements' includes some mechanisms to
define these requirements somehow and the means that they can be used
as an input to the CAR discovery protocol. It is certainly possible that
the first part is done by currently existing protocols, but the
requirement merely states that the means are mandatory for the
CAR discovery solution, otherwise it cannot fulfil its task.

Maybe, here's some confusion in general sometimes that the requirements
always mandate NEW functionality. This is not the case. The requirements
merely describe the functionality that is needed to do the job. Whether
or not this will be done in the final proposal by existing protocols,
modifications to existing ones, or new mechanisms is out of the scope
of the requirements. 

Regards,

Dirk

-----Original Message-----
From: ext Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Thursday, March 14, 2002 10:59 AM
To: Trossen Dirk (NRC/Boston); [email-masked]
Subject: RE: [Seamoby] CAR Discovery Requirements

Regards,

Madjid

---

From: [email-masked]
Date: Thu, 14 Mar 2002 11:50:56 -0500

Hi Madjid,

Regards,

Dirk

-----Original Message-----
From: ext Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Thursday, March 14, 2002 10:59 AM
To: Trossen Dirk (NRC/Boston); [email-masked]
Subject: RE: [Seamoby] CAR Discovery Requirements

Regards,

Madjid

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 15 Mar 2002 16:57:22 -0600

Hi Dirk,

I think it is sufficient to point out that the CAR disc protocol
needs to provide means of signaling the necessary input
for the selection process, including network capabilities
and MN's preferences (profile). 
My point was that:
Since the selection process is either done by MN or oldAR
in the old network, no external signaling is necessary, because
they are both aware of MN's preferences, unless CAR
is happening at a different network entity at the old network.
And I don't think CAR is performed at the target network either,
do you? 

Regards,
Madjid
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 14, 2002 10:51 AM
To: Madjid Nakhjiri; [email-masked]
Subject: RE: [Seamoby] CAR Discovery Requirements

Hi Madjid,

Regards,

Dirk

-----Original Message-----
From: ext Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Thursday, March 14, 2002 10:59 AM
To: Trossen Dirk (NRC/Boston); [email-masked]
Subject: RE: [Seamoby] CAR Discovery Requirements

Regards,

Madjid