Re: [Seamoby] CAR Discovery Requirements

"James Kempf" <kempf@docomolabs-usa.com> Tue, 12 March 2002 22:56 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 RAA11110 for <seamoby-archive@odin.ietf.org>; Tue, 12 Mar 2002 17:56:30 -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 RAA20399; Tue, 12 Mar 2002 17:45:17 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20372 for <seamoby@ns.ietf.org>; Tue, 12 Mar 2002 17:45:15 -0500 (EST)
Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10860 for <seamoby@ietf.org>; Tue, 12 Mar 2002 17:45:11 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2CMigI04784; Tue, 12 Mar 2002 14:44:42 -0800 (PST)
Message-ID: <032401c1ca17$45f2e790$7e6015ac@T23KEMPF>
From: James Kempf <kempf@docomolabs-usa.com>
To: Dirk.Trossen@nokia.com, seamoby@ietf.org
References: <DC504E9C3384054C8506D3E6BB01246008D5B3@bsebe001.NOE.Nokia.com>
Subject: Re: [Seamoby] CAR Discovery Requirements
Date: Tue, 12 Mar 2002 14:43:04 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
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: 7bit

Dirk,

> 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
> problem
> statement.
>
> [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."
>

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.

> 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. There is no need to for the
AR to know the MN's requirements just to select GAARs.

I remember us very clearly discussing this when we were writing
draft-ietf-seamoby-cardiscovery-issues-02.txt, but perhaps
we took away two different interpretations of the discussion.

Anybody else in the WG care to comment?

                jak


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