RE: [Seamoby] CAR Discovery Requirements

Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com> Fri, 15 March 2002 23:07 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13188 for <seamoby-archive@odin.ietf.org>; Fri, 15 Mar 2002 18:07:22 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02296; Fri, 15 Mar 2002 17:58:23 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02268 for <seamoby@optimus.ietf.org>; Fri, 15 Mar 2002 17:58:21 -0500 (EST)
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12966 for <seamoby@ietf.org>; Fri, 15 Mar 2002 17:58:18 -0500 (EST)
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id PAA13909 for <seamoby@ietf.org>; Fri, 15 Mar 2002 15:58:21 -0700 (MST)]
Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id PAA22860 for <seamoby@ietf.org>; Fri, 15 Mar 2002 15:46:25 -0700 (MST)]
Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <DHFW19QX>; Fri, 15 Mar 2002 16:58:20 -0600
Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FFA7@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'Dirk.Trossen@nokia.com'" <Dirk.Trossen@nokia.com>, Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>, seamoby@ietf.org
Subject: RE: [Seamoby] CAR Discovery Requirements
Date: Fri, 15 Mar 2002 16:57:22 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.52)
Content-Type: text/plain; charset="iso-8859-1"
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting <seamoby.ietf.org>
X-BeenThere: seamoby@ietf.org

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: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com]
Sent: Thursday, March 14, 2002 10:51 AM
To: Madjid Nakhjiri; seamoby@ietf.org
Subject: RE: [Seamoby] CAR Discovery Requirements


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:Madjid.Nakhjiri@motorola.com]
Sent: Thursday, March 14, 2002 10:59 AM
To: Trossen Dirk (NRC/Boston); seamoby@ietf.org
Subject: RE: [Seamoby] CAR Discovery Requirements


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


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

_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby