RE: [Seamoby] CAR Discovery Requirements Tue, 12 March 2002 22:01 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id RAA09744 for <>; Tue, 12 Mar 2002 17:01:46 -0500 (EST)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id QAA15270; Tue, 12 Mar 2002 16:50:04 -0500 (EST)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id QAA15245 for <>; Tue, 12 Mar 2002 16:50:02 -0500 (EST)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id QAA09330 for <>; Tue, 12 Mar 2002 16:49:58 -0500 (EST)
Received: from ( []) by (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2CLoDZ26423 for <>; Tue, 12 Mar 2002 23:50:13 +0200 (EET)
Received: from (unverified) by (Content Technologies SMTPRS 4.2.5) with ESMTP id <>; Tue, 12 Mar 2002 23:50:01 +0200
Received: from ([]) by with Microsoft SMTPSVC(5.0.2195.3779); Tue, 12 Mar 2002 23:50:01 +0200
Received: from ([]) by with Microsoft SMTPSVC(5.0.2195.3779); Tue, 12 Mar 2002 15:49:59 -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: Tue, 12 Mar 2002 16:49:58 -0500
Message-ID: <>
Thread-Topic: [Seamoby] CAR Discovery Requirements
Thread-Index: AcHKDNpukhCxQNWySDKfoUDD3djG2AAAW8+w
X-OriginalArrivalTime: 12 Mar 2002 21:49:59.0646 (UTC) FILETIME=[DB592FE0:01C1CA0F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by id QAA15246
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting <>
Content-Transfer-Encoding: 8bit

Hi James,

some comments inline

What 3.4 states is:


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

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



Seamoby mailing list