| +--ClassifierElementUsesFilterList
|
+--AFRelatedServices
|
+--NextService
| |
| +--NextServiceAfterClassifierElement
| |
| +--NextScheduler
| |
| +--FailNextScheduler
|
+--NextServiceAfterMeter
|
+--QueueToSchedule
|
+--SchedulingServiceToSchedule
Figure 10. Association Class Inheritance Hierarchy
The inheritance hierarchy for the aggregations defined in this
document is shown in Figure 11.
+--MemberOfCollection (CIMCORE)
| |
| +--CollectedBufferPool
|
+--Component (CIMCORE)
| |
| +--ServiceComponent (CIMCORE)
| | |
| | +--QoSSubService
| | |
| | +--QoSConditioningSubService
| | |
| | +--ClassifierElementInClassifierService
| |
| +--EntriesInFilterList [PCIME]
|
+--ElementInSchedulingService
Figure 11. Aggregation Class Inheritance Hierarchy
4.3. Class Definitions
This section presents the classes and properties that make up the
Information Model for describing QoS-related functionality in network
devices, including hosts. These definitions are derived from
definitions in the CIM Core model [CIM]. Only the QoS-related
classes are defined in this document. However, other classes drawn
from the CIM Core model, as well as from [PCIME], are described
briefly. The reader is encouraged to look at [CIM] and at [PCIME]
for further information. Associations and aggregations are defined
in Section 4.4.
4.3.1. The Abstract Class ManagedElement
This is an abstract class defined in the Core Model of CIM. It is
the root of the entire class inheritance hierarchy in CIM. Among the
associations that refer to it are two that are subclassed in this
document: Dependency and MemberOfCollection, which is an aggregation.
ManagedElement’s properties are Caption and Description. Both are
free-form strings to describe an instantiated object. Please refer
to [CIM] for the full definition of this class.
4.3.2. The Abstract Class ManagedSystemElement
This is an abstract class defined in the Core Model of CIM; it is a
subclass of ManagedElement. ManagedSystemElement serves as the base
class for the PhysicalElement and LogicalElement class hierarchies.
LogicalElement, in turn, is the base class for a number of important
CIM hierarchies, including System. Any distinguishable component of
a System is a candidate for inclusion in this class hierarchy,
including physical components (e.g., chips and cards) and logical
components (e.g., software components, services, and other objects).
None of the associations in which this class participates is used
directly in the QoS device state model. However, the aggregation
Component, which relates one ManagedSystemElement to another, is the
base class for the two aggregations that form the core of the QoS
device state model: QoSSubService and QoSConditioningSubService.
Similarly, the association ProvidesServiceToElement, which relates a
ManagedSystemElement to a Service, is the base class for the model’s
CalculationServiceForDropper association.
Please refer to [CIM] for the full definition of this class.
4.3.3. The Abstract Class LogicalElement
This is an abstract class defined in the Core Model of CIM. It is a
subclass of the ManagedSystemElement class, and is the base class for
all logical components of a managed System, such as Files, Processes,
or system capabilities in the form of Logical Devices and Services.
None of the associations in which this class participates is relevant
to the QoS device state model. Please refer to [CIM] for the full
definition of this class.
4.3.4. The Abstract Class Service
This is an abstract class defined in the Core Model of CIM. It is a
subclass of the LogicalElement class, and is the base class for all
objects that represent a "service" or functionality in a System. A
Service is a general-purpose object that is used to configure and
manage the implementation of functionality. As noted above in
section 4.3.2, this class participates in the
ProvidesServiceToElement association. Please refer to [CIM] for the
full definition of this class.
4.3.5. The Class ConditioningService
This is a concrete subclass of the CIM Core class Service; it
represents the ability to define how traffic is conditioned in the
data-forwarding path of a device. The subclasses of
ConditioningService define the particular types of conditioning that
are done. Six fundamental types of conditioning are defined in this
document. These are the services performed by a classifier, a meter,
a marker, a dropper, a queue, and a scheduler. Other, more
sophisticated types of conditioning may be defined in future
documents.
ConditioningService is a concrete class because at the time it was
defined in CIM, its superclass was concrete. While this class can be
instantiated, an instance of it would not accomplish anything,
because the nature of the conditioning, and the parameters that
control it, are specified only in the subclasses of
ConditioningService.
Two associations in which ConditioningService participates are
critical to its usage in QoS - QoSConditioningSubService and
NextService. QoSConditioningSubService aggregates
ConditioningServices into a particular QoS service (such as AF), to
describe the specific conditioning functionality that underlies that
QoS service in a particular device. NextService indicates the
subsequent conditioning service(s) for different traffic streams.
The class definition is as follows:
NAME ConditioningService
DESCRIPTION A concrete class to define how traffic
is conditioned in the data forwarding
path of a host or network device.
DERIVED FROM Service
TYPE Concrete
PROPERTIES (none)
4.3.6. The Class ClassifierService
The concept of a Classifier comes from [DSMODEL]. ClassifierService
is a concrete class that represents a logical entity in an ingress or
egress interface of a device, that takes a single input stream, and
sorts it into one or more output streams. The sorting is done by a
set of filters that select packets based on the packet contents, or
possibly based on other attributes associated with the packet. Each
output stream is the result of matching a particular filter.
The representation of classifiers in QDDIM is closely related to that
presented in [DSMIB] and [DSMODEL]. Rather than being linked
directly to its FilterLists, a classifier is modeled here as an
aggregation of ClassifierElements. Each of these ClassifierElements
is then linked to a single FilterList, by the association
ClassifierElementUsesFilterList.
A Classifier is modeled as a subclass of ConditioningService so that
it can be aggregated into a QoSService (using the
QoSConditioningSubService aggregation), and can use the NextService
association to identify the subsequent ConditioningService objects
for the different traffic streams.
ClassifierService is designed to allow hierarchical classification.
When hierarchical classification is used, a ClassifierElement may
point to another ClassifierService. When used for this purpose, the
ClassifierElement must not use the ClassifierElementUsesFilterList
association.
The class definition is as follows:
NAME ClassifierService
DESCRIPTION A concrete class describing how an input
traffic stream is sorted into multiple
output streams using one or more
filters.
DERIVED FROM ConditioningService
TYPE Concrete
PROPERTIES (none)
4.3.7. The Class ClassifierElement
The concept of a ClassifierElement comes from [DSMIB]. This concrete
class represents the linkage, within a single ClassifierService,
between a FilterList that specifies a set of criteria for selecting
packets from the stream of packets coming into the ClassifierService,
and the next ConditioningService to which the selected packets go
after they leave the ClassifierService. ClassifierElement has no
properties of its own. It is present to serve as the anchor for an
aggregation with its classifier, and for associations with its
FilterList and its next ConditioningService.
When a ClassifierElement is associated with a ClassifierService
through the NextServiceAfterClassifierElement association, the
ClassifierElement may not use the ClassifierElementUsesFilterList
association. Further, when a ClassifierElement is associated with a
ClassifierService as described above, the order of processing of the
associated ClassifierService is a function of the ClassifierOrder
property of the ClassifierElementInClassifierService aggregation.
For example, lets assume the following:
1. ClassifierService (C1) aggregates ClassifierElements (E1), (E2)
and (E3), with relative ClassifierOrder values of 1, 2, and 3.
2. ClassifierElements (E1) and (E3) associations to FilterLists (F1)
and (F3) respectively using the ClassifierElementUsesFilterList
association.
3. (E1) & (E3) are associated with Meters (M1) and (M3) through their
respective NextServiceAfterClassifierElement associations.
4. (E2) is associated with ClassifierService (C2) through its
NextServiceAfterClassifierElement association.
5. ClassifierService (C2) aggregates ClassifierElements (E4) and (E5)
with relative ClassifierOrder values of 1 and 2.
6. ClassifierElements (E4) and (E5) have associations to FilterLists
(F4) and (F5) respectively using the
ClassifierElementUsesFilterList association.
In this example, packet processing would match FilterLists in the
order of (F1), (F4), (F5), and (F3).
The class definition is as follows:
NAME ClassifierElement
DESCRIPTION A concrete class representing
the process by which a classifier
uses a filter to select packets
to forward to a specific next
conditioning service.
DERIVED FROM ClassifierService
TYPE Concrete
PROPERTIES (none)
4.3.8. The Class MeterService
This is a concrete class that represents the metering of network
traffic. Metering is the function of monitoring the arrival times of
packets of a traffic stream, and determining the level of conformance
of each packet with respect to a pre-established traffic profile. A
meter has the ability to invoke different ConditioningServices for
conforming and non-conforming traffic. Traffic leaving a meter may be
further conditioned (e.g., dropped or queued) by routing the packet
to another conditioning element. Please see [DSMODEL] for more
information on metering.
This class is the base class for defining different types of meters.
As such, it contains common properties that all meter subclasses
share. It is modeled as a ConditioningService so that it can be
aggregated into a QoSService (using the QoSConditioningSubService
association), to indicate that its functionality underlies that QoS
service. MeterService also participates in the NextServiceAfterMeter
association, to identify the subsequent ConditioningService objects
for conforming and non-conforming traffic.
The class definition is as follows:
NAME MeterService
DESCRIPTION A concrete class describing the
monitoring of traffic with respect to a
pre-established traffic profile.
DERIVED FROM ConditioningService
TYPE Concrete
PROPERTIES MeterType, OtherMeterType,
ConformanceLevels
Note: The MeterType property and the MeterService subclasses provide
similar information. The MeterType property is defined for query
purposes and for future expansion. It is possible that not all
MeterServices will require a subclass to define them. In these
cases, MeterService will be instantiated directly, and the MeterType
property will provide the only way of identifying the type of the
meter.
4.3.8.1. The Property MeterType
This property is an enumerated 16-bit unsigned integer that is used
to specify the particular type of meter represented by an instance of
MeterService. The following enumeration values are defined:
1 - Other
2 - Average Rate Meter
3 - Exponentially Weighted Moving Average Meter
4 - Token Bucket Meter
Note: if the value of MeterType is not one of these four values, it
SHOULD be interpreted as if it had the value ’1’ (Other).
4.3.8.2. The Property OtherMeterType
This is a string property that defines a vendor-specific description
of a type of meter. It is used when the value of the MeterType
property in the instance is equal to 1.
4.3.8.3. The Property ConformanceLevels
This property is a 16-bit unsigned integer. It indicates the number
of conformance levels supported by the meter. For example, when only
"in profile" versus "out of profile" metering is supported,
ConformanceLevels is equal to 2.
4.3.9. The Class AverageRateMeterService
This is a concrete subclass of MeterService that represents a simple
meter, called an Average Rate Meter. This type of meter measures the
average rate at which packets are submitted to it over a specified
time. Packets are defined as conformant if their average arrival
rate does not exceed the specified measuring rate of the meter. Any
packet that causes the specified measuring rate to be exceeded is
defined to be non-conforming. For more information, please see
[DSMODEL].
The class definition is as follows:
NAME AverageRateMeterService
DESCRIPTION A concrete class classifying traffic as
either conforming or non-conforming,
depending on whether the arrival of a
packet causes the average arrival rate
to exceed a pre-determined value.
DERIVED FROM MeterService
TYPE Concrete
PROPERTIES AverageRate, DeltaInterval
4.3.9.1. The Property AverageRate
This is an unsigned 32-bit integer that defines the rate used to
determine whether admitted packets are in conformance or not. The
value is specified in kilobits per second.
4.3.9.2. The Property DeltaInterval
This is an unsigned 64-bit integer that defines the time period over
which the average measurement should be taken. The value is
specified in microseconds.
4.3.10. The Class EWMAMeterService
This is a concrete subclass of the MeterService class that represents
an exponentially weighted moving average meter. This meter is a
simple low-pass filter that measures the rate of incoming packets
over a small, fixed sampling interval. Any admitted packet that
pushes the average rate over a pre-defined limit is defined to be
non-conforming. Please see [DSMODEL] for more information.
The class definition is as follows:
NAME EWMAMeterService
DESCRIPTION A concrete class classifying admitted
traffic as either conforming or non-
conforming, depending on whether the
arrival of a packet causes the average
arrival rate in a small fixed
sampling interval to exceed a
pre-determined value or not.
DERIVED FROM MeterService
TYPE Concrete
PROPERTIES AverageRate, DeltaInterval, Gain
4.3.10.1. The Property AverageRate
This property is an unsigned 32-bit integer that defines the average
rate against which the sampled arrival rate of packets should be
measured. Any packet that causes the sampled rate to exceed this
rate is deemed non-conforming. The value is specified in kilobits
per second.
4.3.10.2. The Property DeltaInterval
This property is an unsigned 64-bit integer that defines the sampling
interval used to measure the arrival rate. The calculated rate is
averaged over this interval and checked against the AverageRate
property. All packets whose computed average arrival rate is less
than the AverageRate are deemed conforming.
The value is specified in microseconds.
4.3.10.3. The Property Gain
This property is an unsigned 32-bit integer representing the
reciprocal of the time constant (e.g., frequency response) of what is
essentially a simple low-pass filter. For example, the value 64 for
this property represents a time constant value of 1/64.
4.3.11. The Class TokenBucketMeterService
This is a concrete subclass of the MeterService class that represents
the metering of network traffic using a token bucket meter. Two
types of token bucket meters are defined using this class - a simple,
two-parameter bucket meter, and a multi-stage meter.
A simple token bucket usually has two parameters, an average token
rate and a burst size, and has two conformance levels: "conforming"
and "non-conforming". This class also defines an excess burst size,
which enables the meter to have three conformance levels
("conforming", "partially conforming", and "non-conforming"). In
this case, packets that exceed the excess burst size are deemed non-
conforming, while packets that exceed the smaller burst size but are
less than the excess burst size are deemed partially conforming.
Operation of these meters is described in [DSMODEL].
The class definition is as follows:
NAME TokenBucketMeterService
DESCRIPTION A concrete class classifying admitted
traffic with respect to a token bucket.
Either two or three levels of
conformance can be defined.
DERIVED FROM MeterService
TYPE Concrete
PROPERTIES AverageRate, PeakRate,
BurstSize, ExcessBurstSize
4.3.11.1. The Property AverageRate
This property is an unsigned 32-bit integer that specifies the
committed rate of the meter. The value is expressed in kilobits per
second.
4.3.11.2. The Property PeakRate
This property is an unsigned 32-bit integer that specifies the peak
rate of the meter. The value is expressed in kilobits per second.
4.3.11.3. The Property BurstSize
This property is an unsigned 32-bit integer that specifies the
maximum number of tokens available for the committed rate (specified
by the AverageRate property). The value is expressed in kilobytes.
4.3.11.4. The Property ExcessBurstSize
This property is an unsigned 32-bit integer that specifies the
maximum number of tokens available for the peak rate (specified by
the PeakRate property). The value is expressed in kilobytes.
4.3.12. The Class MarkerService
This is a concrete class that represents the general process of
marking some field in a network packet with some value. Subclasses of
MarkerService identify particular fields to be marked, and introduce
properties to represent the values to be used in marking these
fields. Markers are usually invoked as a result of a preceding
classifier match. Operation of markers of various types is described
in [DSMODEL].
MarkerService is a concrete class because at the time it was defined
in CIM, its superclass was concrete. While this class can be
instantiated, an instance of it would not accomplish anything,
because both the field to be marked and the value to be used to mark
it are specified only in subclasses of MarkerService.
MarkerService is modeled as a ConditioningService so that it can be
aggregated into a QoSService (using the QoSConditioningSubService
association) to indicate that its functionality underlies that QoS
service. It participates in the NextService association to identify
the subsequent ConditioningService object that acts on traffic after
it has been marked by the marker.
The class definition is as follows:
NAME MarkerService
DESCRIPTION A concrete class representing the
general process of marking a selected
field in a packet with a specified
value. Packets are marked in order
to control the conditioning that
they will subsequently receive.
DERIVED FROM ConditioningService
TYPE Concrete
PROPERTIES (none)
4.3.13. The Class PreambleMarkerService
This is a concrete class that models the storing of traffic-
conditioning results in a packet preamble. See Section 3.8.3 for a
discussion of how, and why, QDDIM models the capability to store
these results in a packet preamble. An instance of
PreambleMarkerService appends to a packet preamble a two-part string
of the form "<type>,<value>". Section 3.8.3 provides a list of the
<type> strings defined by QDDIM. Implementations may support other
<type>’s in addition to these.
The class definition is as follows:
NAME PreambleMarkerService
DESCRIPTION A concrete class representing the saving
of traffic-conditioning results in a
packet preamble.
DERIVED FROM MarkerService
TYPE Concrete
PROPERTIES FilterItemList[ ]
4.3.13.1. The Multi-valued Property FilterItemList
This property is an ordered list of strings, where each string has
the format "<type>,<value>". See Section 3.8.3 for a list of
<type>’s defined in QDDIM, and the nature of the associated <value>
for each of these types.
4.3.14. The Class ToSMarkerService
This is a concrete class that represents the marking of the ToS field
in the IPv4 packet header [R791]. Following common practice, the
value to be written into the field is represented as an unsigned 8-
bit integer.
The class definition is as follows:
NAME ToSMarkerService
DESCRIPTION A concrete class representing the