subclass from NextService. However, meters are 1:n fan-out elements,
and require a mechanism to distinguish between the different
results/outputs of the meter. Therefore, this association defines a
new key property, MeterResult, which is used to record the result and
identify the output through which this traffic left the meter.
Because of this additional key, NextServiceAfterMeter cannot be a
subclass of NextService.
The class definition is as follows:
NAME NextServiceAfterMeter
DESCRIPTION An association used to establish
a predecessor-successor relationship
between a particular output of a
MeterService and the next
ConditioningService object that is
responsible for further processing of
the traffic.
DERIVED FROM Nothing
ABSTRACT False
PROPERTIES PrecedingService[ref MeterService[0..n]],
FollowingService[ref
ConditioningService[0..n]],
MeterResult
4.4.17.1. The Reference PrecedingService
The preceding MeterService, ’earlier’ in the processing sequence for
a packet. Since Meters are 1:n fan-out devices, this relationship
associates a particular output of a MeterService (identified by the
MeterResult property) to the next ConditioningService that is used to
further process the traffic.
4.4.17.2. The Reference FollowingService
The ’next’ or following ConditioningService.
4.4.17.3. The Property MeterResult
This property is an enumerated 16-bit unsigned integer, and
represents information describing the result of the metering. Traffic
is distinguished as being conforming, non-conforming, or partially
conforming. More complicated metering can be built either by
extending the enumeration or by cascading meters.
The enumerated values are: "Unknown" (0), "Conforming" (1),
"PartiallyConforming" (2), "NonConforming" (3).
4.4.18. The Association QueueToSchedule
This is a top-level association, representing the relationship
between a queue (QueuingService) and a SchedulingElement. The
SchedulingElement, in turn, represents the information in a packet
scheduling service that is specific to this queue, such as relative
priority or allocated bandwidth.
It cannot be expressed formally with the association cardinalities,
but there is an additional constraint on participation in this
association. A particular instance of (a subclass of)
SchedulingElement always participates either in exactly one instance
of this association, or in exactly one instance of the association
SchedulingServiceToSchedule.
The class definition is as follows:
NAME QueueToSchedule
DESCRIPTION This association relates a queue to
the SchedulingElement containing
information specific to the queue.
DERIVED FROM Nothing
ABSTRACT False
PROPERTIES Queue[ref QueuingService[0..1]],
SchedElement[ref
SchedulingElement[0..n]]
4.4.18.1. The Reference Queue
This property serves as an object reference to a QueuingService
object. A QueuingService object may be associated 0 or more
SchedulingElement objects.
4.4.18.2. The Reference SchedElement
This property serves as an object reference to a SchedulingElement
object. A SchedulingElement is always associated either with exactly
one QueuingService or with exactly one upstream scheduler
(PacketSchedulingService).
4.4.19. The Association SchedulingServiceToSchedule
This is a top-level association, representing the relationship
between a scheduler (PacketSchedulingService) and a
SchedulingElement, in a configuration involving cascaded schedulers.
The SchedulingElement, in turn, represents the information in a
subsequent packet scheduling service that is specific to this
scheduler, such as relative priority or allocated bandwidth.
It cannot be expressed formally with the association cardinalities,
but there is an additional constraint on participation in this
association. A particular instance of (a subclass of)
SchedulingElement always participates either in exactly one instance
of this association, or in exactly one instance of the association
QueueToSchedule.
The class definition is as follows:
NAME SchedulingServiceToSchedule
DESCRIPTION This association relates a scheduler to
the SchedulingElement in a subsequent
scheduler containing information specific
to this scheduler.
DERIVED FROM Nothing
ABSTRACT False
PROPERTIES SchedService[ref
PacketSchedulingService[0..1]],
SchedElement[ref
SchedulingElement[0..n]]
4.4.19.1. The Reference SchedService
This property serves as an object reference to a
PacketSchedulingService object. A PacketSchedulingService object may
be associated 0 or more SchedulingElement objects.
4.4.19.2. The Reference SchedElement
This property serves as an object reference to a SchedulingElement
object. A SchedulingElement is always associated either with exactly
one QueuingService or with exactly one upstream scheduler
(PacketSchedulingService).
4.4.20. The Aggregation MemberOfCollection
This aggregation is a generic relationship used to model the
aggregation of a set of ManagedElements in a generalized Collection
object. The aggregation’s cardinality is many to many.
MemberOfCollection is defined in the Core Model of CIM. Please refer
to [CIM] for the full definition of this class.
4.4.21. The Aggregation CollectedBufferPool
This aggregation models the ability to treat a set of buffers as a
pool, or collection, that can in turn be contained in a "higher-
level" buffer pool. This class overrides the more generic
MemberOfCollection aggregation to restrict both the aggregate and the
part component objects to be instances only of the BufferPool class.
The class definition for the aggregation is as follows:
NAME CollectedBufferPool
DESCRIPTION A generic association used to aggregate
a set of related buffers into a
higher-level buffer pool.
DERIVED FROM MemberOfCollection
ABSTRACT False
PROPERTIES Collection[ref BufferPool[0..1]],
Member[ref BufferPool[0..n]]
4.4.21.1. The Reference Collection
This property represents the parent, or aggregate, object in the
relationship. It is a BufferPool object.
4.4.21.2. The Reference Member
This property represents the child, or lower level pool, in the
relationship. It is one of the set of BufferPools that together make
up the higher-level pool.
4.4.22. The Abstract Aggregation Component
This abstract aggregation is a generic relationship used to establish
"part-of" relationships between managed objects (named GroupComponent
and PartComponent). The association’s cardinality is many to many.
The association is defined in the Core Model of CIM. Please refer to
[CIM] for the full definition of this class.
4.4.23. The Aggregation ServiceComponent
This aggregation is used to model a set of subordinate Services that
are aggregated together to form a higher-level Service. This
aggregation is derived from the more generic Component superclass to
restrict the types of objects that can participate in this
relationship. The association’s cardinality is many to many.
The association is defined in the Core Model of CIM. Please refer to
[CIM] for the full definition of this class.
4.4.24. The Aggregation QoSSubService
This aggregation represents a set of subordinate QoSService objects
(that is, a set of instances of subclasses of the QoSService class)
that are aggregated together to form a higher-level QoSService. A
QoSService is a specific type of Service that conceptualizes QoS
functionality as a set of coordinated sub-services.
This aggregation is derived from the more generic ServiceComponent
superclass to restrict the types of objects that can participate in
this relationship to QoSService objects, instead of a more generic
Service object. It also restricts the cardinality of the aggregate
to 0-or-1 (instead of the more generic 0-or-more).
The class definition for the aggregation is as follows:
NAME QoSSubService
DESCRIPTION A generic association used to establish
"part-of" relationships between a
higher-level QoSService object and the
set of lower-level QoSServices that
are aggregated to create/form it.
DERIVED FROM ServiceComponent
ABSTRACT False
PROPERTIES GroupComponent[ref QoSService[0..1]],
PartComponent[ref QoSService[0..n]]
4.4.24.1. The Reference GroupComponent
This property is overridden in this aggregation to represent an
object reference to a QoSService object (instead of to the more
generic Service object defined in its superclass). This object
represents the parent, or aggregate, object in the relationship.
4.4.24.2. The Reference PartComponent
This property is overridden in this aggregation to represent an
object reference to a QoSService object (instead of to the more
generic Service object defined in its superclass). This object
represents the child, or "component", object in the relationship.
4.4.25. The Aggregation QoSConditioningSubService
This aggregation identifies the set of conditioning services that
together condition traffic for a particular QoS service.
This aggregation is derived from the more generic ServiceComponent
superclass; it restricts the types of objects that can participate in
it to ConditioningService and QoSService objects, instead of the more
generic Service objects.
The class definition for the aggregation is as follows:
NAME QoSConditioningSubService
DESCRIPTION A generic aggregation used to establish
"part-of" relationships between a set
of ConditioningService objects and the
particular QoSService object(s) that they
provide traffic conditioning for.
DERIVED FROM ServiceComponent
ABSTRACT False
PROPERTIES GroupComponent[ref QoSService[0..n]],
PartComponent[ref
ConditioningService[0..n]]
4.4.25.1. The Reference GroupComponent
This property is overridden in this aggregation to represent an
object reference to a QoSService object (instead of to the more
generic Service object defined in its superclass). The cardinality
of the reference remains 0..n, to indicate that a given
ConditioningService may provide traffic conditioning for 0, 1, or
more than 1 QoSService objects.
This object represents the parent, or aggregate, object in the
association. In this case, this object represents the QoSService
that aggregates one or more ConditioningService objects to implement
the appropriate traffic conditioning for its traffic.
4.4.25.2. The Reference PartComponent
This property is overridden in this aggregation to represent an
object reference to a ConditioningService object (instead of to the
more generic Service object defined in its superclass). This object
represents the child, or "component", object in the relationship. In
this case, this object represents one or more ConditioningService
objects that together indicate how traffic for a specific QoSService
is conditioned.
4.4.26. The Aggregation ClassifierElementInClassifierService
This aggregation represents the relationship between a classifier and
the classifier elements that provide the fan-out function for the
classifier. A classifier typically aggregates multiple classifier
elements. A classifier element, however, is aggregated only by a
single classifier. See [DSMODEL] and [DSMIB] for more about
classifiers and classifier elements.
The class definition for the aggregation is as follows:
NAME ClassifierElementInClassifierService
DESCRIPTION An aggregation representing the
relationship between a classifier
and its classifier elements.
DERIVED FROM ServiceComponent
ABSTRACT False
PROPERTIES GroupComponent[ref
ClassifierService[1..1]],
PartComponent[ref
ClassifierElement[0..n],
ClassifierOrder
4.4.26.1. The Reference GroupComponent
This property is overridden in this aggregation to represent an
object reference to a ClassifierService object (instead of to the
more generic Service object defined in its superclass). It also
restricts the cardinality of the aggregate to 1..1 (instead of the
more generic 0-or-more), representing the fact that a
ClassifierElement always exists within the context of exactly one
ClassifierService.
4.4.26.2. The Reference PartComponent
This property is overridden in this aggregation to represent an
object reference to a ClassifierElement object (instead of to the
more generic Service object defined in its superclass). This object
represents a single traffic selector for the classifier. A
ClassifierElement usually has an association to a FilterList that
provides selection criteria for packets from the traffic stream
coming into the classifier, and to a ConditioningService to which
packets selected by these criteria are next forwarded.
4.4.26.3. The Property ClassifierOrder
Because the filters for a classifier can overlap, it is necessary to
specify the order in which the ClassifierElements aggregated by a
ClassifierService are presented with packets coming into the
classifier. This property is an unsigned 32-bit integer representing
this order. Values are represented in ascending order: first ’1’,
then ’2’, and so on. Different values MUST be assigned for each of
the ClassifierElements aggregated by a given ClassifierService.
4.4.27. The Aggregation EntriesInFilterList
This aggregation is a specialization of the Component aggregation; it
is used to define a set of filter entries (subclasses of
FilterEntryBase) that are aggregated by a FilterList.
The cardinalities of the aggregation itself are 0..1 on the
FilterList end, and 0..n on the FilterEntryBase end. Thus in the
general case, a filter entry can exist without being aggregated into
any FilterList. However, the only way a filter entry can figure in
the QoS Device model is by being aggregated into a FilterList by this
aggregation.
See [PCIME] for the definition of this aggregation.
4.4.28. The Aggregation ElementInSchedulingService
This concrete aggregation represents the relationship between a
PacketSchedulingService and the set of SchedulingElements that tie it
to its inputs.
The class definition for the aggregation is as follows:
NAME ElementInSchedulingService
DESCRIPTION An aggregation used to tie a
PacketSchedlingService to the
configuration information for one of
the elements (either a QueuingService or
another PacketSchedulingService) that it
schedules.
DERIVED FROM Component
ABSTRACT False
PROPERTIES GroupComponent[ref
PacketSchedulingService[0..1]],
PartComponent[ref
SchedulingElement[1..n]
4.4.28.1. The Reference GroupComponent
This property is overridden in this aggregation to represent an
object reference to a PacketSchedulingService object (instead of to
the more generic Service object defined in its superclass). It also
restricts the cardinality of the aggregate to 0..1 (instead of the
more generic 0-or-more), representing the fact that a
SchedulingElement exists within the context of at most one
PacketSchedulingService.
4.4.28.2. The Reference PartComponent
This property is overridden in this aggregation to represent an
object reference to a SchedulingElement object (instead of to the
more generic Service object defined in its superclass). This object
represents a single scheduling element for the scheduler. It also
restricts the cardinality of the SchedulingElement to 1..n (instead
of the more generic 0-or-more), representing the fact that a
PacketSchedulingService always includes at least one
SchedulingElement.
5. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF’s procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11.
Copies of claims of rights made available for publication and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
6. Acknowledgements
The authors wish to thank the participants of the Policy Framework
and Differentiated Services working groups for their many helpful
comments and suggestions. Special thanks to Joel Halpern, who
provided some key technical direction during the latter stages of the
document’s development.
7. Security Considerations
Like [PCIM] and [PCIME], this document defines an information model
that cannot be implemented directly. Consequently, security issues
do not arise until it is mapped to an actual, implementable data
model such as a MIB, PIB, or LDAP schema. See [PCIM] for a general
discussion of security considerations for information models. See
also [DSMIB] (which in fact is a data model that corresponds to a
large extent with the QDDIM information model), for a discussion of
the security implications of specific objects in the model.
8. References
8.1. Normative References
[CIM] Common Information Model (CIM) Schema, version 2.5.
Distributed Management Task Force, Inc., available at
http://www.dmtf.org/standards/cim_schema_v25.php.
[IEEE802Q] Virtual Bridged Local Area Networks, ANSI/IEEE std 802.1Q,
1998 edition. Approved December 8, 1998
[PCIM] Moore, B., Ellesson, E., Strassner, J. and A. Westerinen,
"Policy Core Information Model - Version 1 Specification",
RFC 3060, February 2001.
[PCIME] Moore, B., Ed., "Policy Core Information Model (PCIM)
Extensions", RFC 3460, January 2003.
[R791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[R2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[R2474] Nichols, K., Blake, S., Baker, F. and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.
[R2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[R3140] Black, D., Brim, S., Carpenter, B. and F. Le Faucheur,
"Per Hop Behavior Identification Codes", RFC 3140, June
2001.
8.2. Informative References
[DSMIB] Baker, F., Chan, K. and A. Smith, "Management Information
Base for the Differentiated Services Architecture", RFC
3289, May 2002.
[DSMODEL] Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An
Informal Management Model for DiffServ Routers", RFC 3290,
May 2002.
[PIB] Chan, K., Sahita, R., Hahn, S. and K. McCloghrie,
"Differentiated Services Quality of Service Policy
Information Base", RFC 3317, March 2003.
[POLTERM] Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,
J. and S. Waldbusser, "Terminology for Policy-Based
Management", RFC 3198, November 2001.
[QPIM] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R. and B.
Moore, "Policy Quality of Service (QoS) Information
Model", RFC 3644, November 2003.
[R1633] Braden, R., Clark, D. and S. Shenker, "Integrated Services
in the Internet Architecture: An Overview", RFC 1633,
June 1994.
[R2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated
Service", RFC 2475, December 1998.
[R3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le
Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V. and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002.
[RED] See http://www.aciri.org/floyd/red.html
9. Appendix A: Naming Instances in a Native CIM Implementation