Subject: QDIM issue: cardinality of ConditioningServiceOnEndpoint

From: [email-masked]
Date: Thu, 17 Aug 2000 09:19:28 -0400

There are several changes I'd like to propose for the QoS
Device Information Model (draft-ietf-policy-qos-device-
info-model-01.txt).  I'll post each proposed change in a
separate note, to make it easier to follow the discussion
threads.

The first change involves relaxing the cardinality at the
ConditioningService end of the ConditioningServiceOnEndpoint
association from 0..1 to 0..n (i.e., to *).  If you think of
the conditioning services as they are represented in the
Diffserv Conceptual Model's TCB figures, you can draw the
protocol endpoint as another box on the network side of
the figure.  That is, the protocol endpoint box would be
on the left side of the picture for an ingress interface,
but on the right side of the picture for an egress
interface.  In the ingress direction the protocol endpoint
feeds traffic to the first conditioning service, typically,
but not necessarily, a classifier.  Here the maximum
cardinality of 1 for ConditioningService is correct.

In the egress direction, however, the protocol endpoint is
tied to the last conditioning services on the interface,
and there may be several of these.  The maximum cardinality
of 1 for this association may date from the time when the
Diffserv Conceptual Model said that a TCB always has
exactly one output.  Now, though, the Conceptual Model
correctly says that there can be several last elements, one
for each path that a packet may follow through the ACG of
conditioning services.  Consequently, the cardinality for
this association needs to be relaxed, to allow all of these
last conditioning services to be tied to the protocol
endpoint.

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]