RE: [Seamoby] CAR Discovery Requirements

Dirk.Trossen@nokia.com Thu, 14 March 2002 17: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 MAA22794 for <seamoby-archive@odin.ietf.org>; Thu, 14 Mar 2002 12:07:27 -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 LAA13660; Thu, 14 Mar 2002 11:51:29 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13631 for <seamoby@ns.ietf.org>; Thu, 14 Mar 2002 11:51:27 -0500 (EST)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22310 for <seamoby@ietf.org>; Thu, 14 Mar 2002 11:51:23 -0500 (EST)
From: Dirk.Trossen@nokia.com
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2EGpbZ00983 for <seamoby@ietf.org>; Thu, 14 Mar 2002 18:51:37 +0200 (EET)
Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T59a0df60cdac12f255081@davir02nok.americas.nokia.com>; Thu, 14 Mar 2002 10:51:23 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 14 Mar 2002 10:50:57 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [Seamoby] CAR Discovery Requirements
Date: Thu, 14 Mar 2002 11:50:56 -0500
Message-ID: <DC504E9C3384054C8506D3E6BB012460382FFB@bsebe001.NOE.Nokia.com>
Thread-Topic: [Seamoby] CAR Discovery Requirements
Thread-Index: AcHLcTXHz/MHPugWSwi9IZh6yeo+TgABpqxw
To: Madjid.Nakhjiri@motorola.com, seamoby@ietf.org
X-OriginalArrivalTime: 14 Mar 2002 16:50:57.0131 (UTC) FILETIME=[699A2BB0:01C1CB78]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA13632
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
Content-Transfer-Encoding: 8bit

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