RE: [Seamoby] CAR Discovery Requirements

Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com> Thu, 14 March 2002 16:12 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 LAA20875 for <seamoby-archive@odin.ietf.org>; Thu, 14 Mar 2002 11:12:41 -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 LAA07962; Thu, 14 Mar 2002 11:00:42 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07896 for <seamoby@ns.ietf.org>; Thu, 14 Mar 2002 11:00:38 -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 LAA20578 for <seamoby@ietf.org>; Thu, 14 Mar 2002 11:00:35 -0500 (EST)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA08862 for <seamoby@ietf.org>; Thu, 14 Mar 2002 09:00:30 -0700 (MST)]
Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id JAA24661 for <seamoby@ietf.org>; Thu, 14 Mar 2002 09:00:28 -0700 (MST)]
Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id <D2MY86QG>; Thu, 14 Mar 2002 09:58:56 -0600
Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FF90@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'Dirk.Trossen@nokia.com'" <Dirk.Trossen@nokia.com>, seamoby@ietf.org
Subject: RE: [Seamoby] CAR Discovery Requirements
Date: Thu, 14 Mar 2002 09:58:56 -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

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