RE: [Seamoby] CAR Discovery Requirements

Dirk.Trossen@nokia.com Wed, 13 March 2002 16:08 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 LAA09562 for <seamoby-archive@odin.ietf.org>; Wed, 13 Mar 2002 11:08:08 -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 KAA22768; Wed, 13 Mar 2002 10:55:46 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22745 for <seamoby@optimus.ietf.org>; Wed, 13 Mar 2002 10:55:44 -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 KAA08865 for <seamoby@ietf.org>; Wed, 13 Mar 2002 10:55:35 -0500 (EST)
From: Dirk.Trossen@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2DFtjZ20245 for <seamoby@ietf.org>; Wed, 13 Mar 2002 17:55:45 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T599d3d5c85ac158f23076@esvir03nok.nokia.com>; Wed, 13 Mar 2002 17:55:33 +0200
Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 13 Mar 2002 17:55:33 +0200
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 13 Mar 2002 09:54:04 -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: Wed, 13 Mar 2002 10:54:03 -0500
Message-ID: <DC504E9C3384054C8506D3E6BB012460382FEB@bsebe001.NOE.Nokia.com>
Thread-Topic: [Seamoby] CAR Discovery Requirements
Thread-Index: AcHKF4MSiaG8bRpbSYenJsysPAQFGAAjdyuA
To: kempf@docomolabs-usa.com, seamoby@ietf.org
X-OriginalArrivalTime: 13 Mar 2002 15:54:04.0782 (UTC) FILETIME=[4D4548E0:01C1CAA7]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA22746
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 James,

comments inline...

-----Original Message-----
From: ext James Kempf [mailto:kempf@docomolabs-usa.com]
Sent: Tuesday, March 12, 2002 5:43 PM
To: Trossen Dirk (NRC/Boston); seamoby@ietf.org
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.

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

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

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