Subject: RE: [Seamoby] CAR Discovery Requirements

From: [email-masked]
Date: Tue, 12 Mar 2002 16:49:58 -0500

Hi James,

some comments inline

What 3.4 states is:

    3.4. CAPABILITY DISCOVERY

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

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.

Regards,

Dirk

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "James Kempf" <[email-masked]>
Date: Tue, 12 Mar 2002 14:43:04 -0800

Dirk,

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

> 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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 12 Mar 2002 14:43:04 -0800

Dirk,

                jak