Subject: Requirements Document - Capabilities Model

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 23 May 2002 16:00:59 -0400

In reviewing the Requirements document and the proposed Architecture (or
framework) document, I realized that from my perspective there is an
additional piece of the puzzle that should be discussed along with the FE
model in the requirements document.

The requirements document describes an FE model, and indicates that it is a
capabilities model.  A capabilities model is a representation of what kinds
of operations something can perform, and frequently includes resource
availability (since resources have a direct effect on capability).
However, to control an FE, a CE needs to know more than just what it is
capable of.  It needs to know what the current configuration (state) of the
device is.  For example, if the CE is adding another filter, and wants to
cause traffic that matches that filter to be directed to an existing meter
or marker, then the CE must know how to refer to that meter or marker, and
the FE must understand that reference properly.  Therefore, there is a
shared model of the actual current state of the FE, which the CE
manipulates and the FE uses to manipulate its actual behavior.
The DiffServ conceptual model (and MIB / PIB) which have been mentioned as
starting points for the capabilities model are actually state models, not
capabilities models.  There is no way to tell from these models how many
filters a device can handle, or whether it is capable of
metering.  However, you can tell at any given time exactly what filters it
has, how they connect to markers, meters, queues, etc.  When you want to
configure additional processing elements into the processing path, you
reference the elements of this model.

Thus, the requirements document should call out the need for both a
capabilities model and a state model.

Yours,
Joel M. Halpern

PS: I am sorry that I am bringing this issue up in last call.  Fortunately,
not much text is required to resolve this.

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 23 May 2002 13:33:36 -0700

Hi Joel

Thanks for the comments. If I understand you correctly, you
are saying that we need a Capabilities Model which expresses
all the possible caps and then an Instance Model which
specifies the instances of those caps on the FE. I think
the DiffServ model has both these, the MIB/PIB defines all
the possible caps and has place holder for instance Ids which
are used in the protocol at run-time. Do correct me if I am
wrong.

Anyways I think we already imply that we need both these in
the Requirements. Is there any particular text that you think
implies otherwise ??

regards
Hormuzd
-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Thursday, May 23, 2002 1:01 PM
To: [email-masked]
Subject: [FORCES] Requirements Document - Capabilities Model

Yours,
Joel M. Halpern

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 23 May 2002 16:44:02 -0400

The DiffServ model is definitely not a capabilities model.  There is no way
to express the fact that a given implementation is or is not capable of
having more than one queue, more than 0 markers, more than 0 meters, etc,
much less the number and kinds of meters, markers, queues, etc that it can
have.

There are places where the Requirements document implies that the model is
both a capability and a state model.  However, section 6 FE Model
explicitly states that the model is a capabilities model.

Yours,
Joel M. Halpern

PS: In other modeling work in and around the IETF it is referred to as a
state model(or sometimes a configuration model), not an instance model.  I
don't much care exactly what words we use to seaparte the two kinds of
models, but they are different, and need to be distinguished.

---

From: "Yang, Lily L" <[email-masked]>
Date: Thu, 23 May 2002 15:12:22 -0700

Since the motivation of an FE model is to allow CEs later to control and
configure FEs' behavior via ForCES protocol, it becomes essential to examine
and understand what kind of control and configuration CEs might do to FEs.
Maybe we can categorize them into 3 kinds.

The first kind of control and configuration is the simplest of all. It
assumes that each FE's capability is already given and remains static in its
lifetime, and CEs can only control its behavior by manipulating its state.
For example, an FE may provide a certain QoS function consisting of one
classifier with 3 filters, connected to fixed number of meters, markers,
queues etc. But the way these blocks connected is fixed and given. If such a
configuration remains static during FE's lifetime, then all CE can control
is the parameters associated with each block. But CE can not reconfigure the
topology (among classifiers, meters, markers, queues, etc.)  dynamically,
such as adding another meter or queue onto the FE on the fly. For this kind
of control and configuration purpose, the useful FE model is consisted of
the state information that FEs allow CEs to manipulate and the statistics
and events that FEs can collect and report back to CEs. Such a state model
doesn't need to describe a lot of other information, like the packet formats
supported between a particular meter and a particular counter, for example.
Because that is fixed and given.

The second kind of control and configuration builds on top of the first
category by allowing "dynamic FE" control and configuration. Therefore, an
FE state model is not sufficient now. A more powerful and flexible
capability model is required to convey information such as "This FE can
support one classifier with N filters, M meters, X queues, etc." It also
becomes necessary to model the capability of the building blocks like
classifiers, filters, meters etc. so that CE can configure them correctly.
For example, it becomes necessary to describe the packet formats supported
at each input and output of each block, because CEs need to have that
information to allow correct reconfiguration of the graph. Therefore, both
the FE state model and capability model become necessary for such dynamic
control and configuration.

The third kind of control and configuration is even more powerful and future
looking. In addition to dynamic configuration, CEs might be even allowed to
download a given functionality onto FEs. I am not sure how we model that
yet. But we probably can get by without too concerned with this.

My personal take on this is that we definetely MUST support the first kind
of "static FE" control and configuraiton, and we MAY also allow the second
kind of "dynamic FE". Therefore, a state model is a must and some flavor of
a capability model would also be good.

I guess when the requirement draft was written, this distinction was
probably not made explicitly. I believe the requirements regarding the model
in the document are still valid, except a few wording might need to be made
more explicit, esp. when we say "FE capabilities".

Lily

> Sent: Thursday, May 23, 2002 1:44 PM
> Subject: Re: Requirements Document - Capabilities Model
>
>