Policy Framework Working Group J. Strassner
INTERNET-DRAFT A. Westerinen
Category: Standards Track Cisco Systems
Bob Moore
IBM Corporation
David Durham
Intel
Walter Weiss
Ellacoya
November 2000
Information Model for Describing Network Device QoS Mechanisms
for Differentiated Services
<draft-ietf-policy-qos-device-info-model-02.txt>
Friday, November 24, 2000, 10:20 AM
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Strassner, et al. Expires: Nov 2000 + 6 months [Page 1] Internet Draft QoS Device Info Model November 2000
Abstract
The purpose of this draft is to define an information model that
describes the QoS mechanisms inherent in different network
devices, including hosts. Broadly speaking, these mechanisms
describe the attributes common to selecting and conditioning
traffic through the forwarding path of network devices running
Differentiated Services (see [R2475]). Another draft will
address Integrated Services (see [R1633]).
This draft is intended to be used with the QoS Policy Information
Model [QOSPIM] to model how policies can be defined to manage and
configure the QoS mechanisms (i.e., the classification, marking,
metering, dropping, queuing, and scheduling functionality) of
devices. Together, these two drafts describe how to write QoS
policy rules to configure and manage the QoS mechanisms of
devices.
This draft, as well as [QOSPIM], are information models. That
is, they represent information independent of a binding to a
specific type of repository. A separate draft will be written to
provide a mapping of the data contained in this document to a
form suitable for implementation in a directory that uses (L)DAP
as its access protocol. This latter draft is analogous to
[QOSSCH], which provides a similar mapping of the data in
[QOSPIM] to a directory. Together, these drafts (information
models and schema mappings) then describe how to write QoS policy
rules that can be used to store information in directories to
configure device QoS mechanisms.
Definition of Key Word Usage
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119 [R2119].
Strassner, et al. Expires: Nov 2000 + 6 months [Page 2] Internet Draft QoS Device Info Model November 2000
Table of Contents
1. Introduction......................................................5
1.1. Policy Management Conceptual Model...........................6
1.2. Purpose and Relation to Other Policy Work....................7
1.3. Typical Examples of Policy Usage.............................7
2. Approach..........................................................8
2.1. Common Needs Of DiffServ and IntServ.........................8
2.2. Specific Needs Of DiffServ...................................9
2.3. Specific Needs Of IntServ....................................9
3. Methodology......................................................10
3.1. Level of Abstraction for Expressing QoS Policies............10
3.2. Specifying Policy Parameters................................11
3.3. Specifying Policy Services..................................12
3.4. Level of Abstraction for Defining QoS Attributes and
Classes..........................................................13
3.5. Characterization of QoS Attributes..........................14
3.6. QoS Information Model Derivation............................15
3.7. Attribute Representation....................................16
3.8. Mental Model................................................16
3.8.1. The QoSService Class......................................17
3.8.2. The ConditioningService Class.............................18
3.8.3. QoS Statistics Classes....................................19
3.9. Classifiers, FilterLists, and FilterEntries.................19
4. The Class Hierarchy..............................................20
4.1. Associations................................................20
4.2. Aggregations................................................21
4.3. The Structure of the Class Hierarchies......................21
4.3.1. The Class Hierarchies for Modeling State Information......21
4.3.2. The Class Hierarchies for Modeling Configuration
Information......................................................26
4.4. Class Definitions for the State Portion of the Model........26
4.4.1. The Abstract Class ManagedElement.........................26
4.4.2. The Abstract Class ManagedSystemElement...................27
4.4.3. The Abstract Class LogicalElement.........................27
4.4.4. The Abstract Class Service................................27
4.4.5. The Abstract Class NetworkService.........................27
4.4.6. The Class ForwardingService...............................28
4.4.7. The Class ConditioningService.............................28
4.4.8. The Class ClassifierService...............................29
4.4.9. The Class ClassifierElement...............................30
4.4.10. The Class MeterService...................................30
4.4.11. The Class AverageRateMeter...............................32
4.4.12. The Class EWMAMeter......................................32
4.4.13. The Class TokenBucketMeter...............................33
4.4.14. The Class MarkerService..................................34
4.4.15. The Class ToSMarkerService...............................35
4.4.16. The Class DSCPMarkerService..............................36
4.4.17. The Class PriorityMarkerService..........................36
4.4.18. The Class DropperService.................................37
4.4.19. The Class HeadTailDropperService.........................38
4.4.20. The Class REDDropperService..............................38
4.4.21. The Class QueuingService.................................40
Strassner, et al. Expires: Nov 2000 + 6 months [Page 3] Internet Draft QoS Device Info Model November 2000
4.4.22. The Class PacketSchedulingService........................40
4.4.23. The Class QoSService.....................................41
4.4.24. The Class DiffServService................................42
4.4.25. The Class AFService......................................43
4.4.26. The Class EFService......................................44
4.4.27. The Class PrecedenceService..............................45
4.4.28. The Class 8021PService...................................45
4.4.29. The Class DropThresholdCalculationService................46
4.4.30. The Abstract Class FilterEntryBase.......................47
4.4.31. The Class FilterEntry....................................47
4.4.32. The Class IP6TupleFilter.................................48
4.4.33. The Class 8021Filter.....................................49
4.4.34. The Class 8021PQFilter...................................49
4.4.35. The Class FilterList.....................................50
4.4.36. The Abstract Class ServiceAccessPoint....................50
4.4.37. The Class ProtocolEndpoint...............................50
4.4.38. The Abstract Class Collection............................50
4.4.39. The Abstract Class CollectionOfMSEs......................51
4.4.40. The Class BufferPool.....................................51
4.5. Association Definitions for the State Portion of the
Model............................................................52
4.5.1. The Abstract Association Dependency.......................52
4.5.2. The Association ServiceSAPDependency......................52
4.5.3. The Association Forwards Among............................53
4.5.4. The Association ConditioningServiceOnEndpoint.............53
4.5.5. The Association IngressConditioningServiceOnEndpoint......54
4.5.6. The Association EgressConditioningServiceOnEndpoint.......54
4.5.7. The Association HeadTailDropQueueBinding..................55
4.5.8. The Association CalculationBasedOnQueue...................55
4.5.9. The Association ProvidesServiceToElement..................56
4.5.10. The Association ServiceServiceDependency.................56
4.5.11. The Association QueueHierarchy...........................56
4.5.12. The Association CalculationServiceForDropper.............57
4.5.13. The Association QueueAllocation..........................58
4.5.14. The Association ClassifierFilterSet......................59
4.5.15. The Association ClassifierElementUsesFilterList..........60
4.5.16. The Association AFRelatedServices........................60
4.5.17. The Association NextService..............................61
4.5.18. The Association NextServiceAfterMeter....................62
4.5.19. The Association NextServiceAfterClassifierElement........63
4.5.20. The Association SchedulerUsed............................64
4.5.21. The Association PrioritySchedulerUsed....................65
4.5.22. The Association BoundedPrioritySchedulerUsed.............66
4.5.23. The Association BandwidthSchedulerUsed...................66
4.5.24. The Association WRRSchedulerUsed.........................67
4.5.25. The Aggregation MemberOfCollection.......................68
4.5.26. The Aggregation CollectedBufferPool......................68
4.5.27. The Abstract Aggregation Component.......................69
4.5.28. The Aggregation ServiceComponent.........................69
4.5.29. The Aggregation QoSSubService............................69
4.5.30. The Aggregation QoSConditioningSubService................70
4.5.31. The Aggregation ClassifierElementInClassifierService.....71
4.5.32. The Aggregation EntriesInFilterList......................72
Strassner, et al. Expires: Nov 2000 + 6 months [Page 4] Internet Draft QoS Device Info Model November 2000
5. Intellectual Property............................................73
6. Acknowledgements.................................................73
7. Security Considerations..........................................73
8. References.......................................................74
9. Authors' Addresses...............................................75
10. Full Copyright Statement........................................76
11. Appendix A: Naming Instances in a Native CIM Implementation....77
11.1. Naming Instances of the Classes Derived from Service.......77
11.2. Naming Instances of FilterEntry............................77
11.3. Naming Instances of FilterList.............................77
11.4. Naming Instances of ProtocolEndpoint.......................77
11.5. Naming Instances of BufferPool.............................78
11.5.1. The Property CollectionID................................78
11.5.2. The Property CreationClassName...........................78
1. Introduction
The purpose of this draft is to define an information model that
describes the QoS mechanisms inherent in different network
devices, including hosts. Broadly speaking, these mechanisms
describe the attributes common to selecting and conditioning
traffic through the forwarding path of network devices running
Differentiated Services (see [R2475]). Another draft will
address Integrated Services (see [R1633]).
This draft is intended to be used with the QoS Policy Information
Model [QOSPIM] to model how policies can be defined to manage and
configure the QoS mechanisms (i.e., the classification, marking,
metering, dropping, queuing, and scheduling functionality) of
devices. Together, these two drafts describe how to write QoS
policy rules to configure and manage the QoS mechanisms of
devices.
This draft, as well as [QOSPIM], are information models. That
is, they represent information independent of a binding to a
specific type of repository. A separate draft will be written to
provide a mapping of the data contained in this document to a
form suitable for implementation in a directory that uses (L)DAP
as its access protocol. This latter draft is analogous to
[QOSSCH], which provides a similar mapping of the data in
[QOSPIM] to a directory. Together, these drafts (information
models and schema mappings) then describe how to write QoS policy
rules that can be used to store information in directories to
configure device QoS mechanisms.
The approach taken in this draft defines a common set of
attributes that can be used to model Differentiated Services QoS.
(Integrated Services will be modeled in a separate draft.)
Vendors can then map these attributes, either directly or using
an intervening format like a COP-PR PIB, to their own device-
specific implementations.
Strassner, et al. Expires: Nov 2000 + 6 months [Page 5] Internet Draft QoS Device Info Model November 2000
This draft explicitly separates the concepts of configuration and
state. Configuration attributes are used to describe the desired
state of a device, whereas state attributes reflect the current
operation of the device. Both state and configuration attributes
are necessary in order to model and manage QoS at the device
level. Although configuration is discussed, this draft only
models state attributes at this time. Configuration attributes
will be added in a future version of the draft.
The design of the class and relationship hierarchies described in
this draft is influenced by the DMTF Network QoS submodel [CIM].
These hierarchies are not derived from the Policy Core
Information Model [PCIM]. This is because the modeling of the
QoS mechanisms of a device is separate and distinct from the
modeling of policies that manage those mechanisms. Hence, there
is a need to separate QoS mechanisms (this draft) from their
control (specified using the generic policy draft [PCIM]
augmented by the QoS Policy draft [QOSPIM]).
1.1. Policy Management Conceptual Model
The [PCIM] describes a general methodology for constructing
policy rules. A policy rule aggregates a set of policy
conditions and a set of policy actions. The semantics of a
policy rule are such that if the set of conditions evaluates to
TRUE, then the set of actions are executed.
Policy conditions and actions have two principal components:
operands and operators. Operands can be constants or variables.
To specify a policy, it is necessary to specify:
o the operands to be examined (also known as state variables);
o the operands to be changed (also known as configuration
variables);
o the relationships between these two sets of operands.
Operands can be specified at a high-level, such as Joe (a user)
or Gold (a service). Operands can also be specified at a much
finer level of detail, one that is much closer to the operation
of the device. Examples of the latter include an IP Address or a
queue's bandwidth allocation. Implicit in the use of operands is
the binding of legal values or ranges of values to an operand.
For example, the value of an IP address cannot be an integer.
The concepts of operands and their ranges are defined in
[QOSPIM].
The second component of policy conditions and actions is a set of
operators. Operators can express both relationships (greater
than, member of a set, Boolean OR, etc.) and assignments.
Together, operators and operands can express a variety of
conditions and actions, such as:
Strassner, et al. Expires: Nov 2000 + 6 months [Page 6] Internet Draft QoS Device Info Model November 2000
If Bob is an Engineer...
If the source IP address is in the Marketing Subnet...
Set Joe's IP address to 2.3.4.5
Limit the bandwidth of application x to 10 Mb
We recognize that the definition of operator semantics is
critical to the definition of policies. However, the definition
of these operators is beyond the scope of this document. Rather,
this draft (with [QOSPIM]) takes the first steps in identifying
and standardizing a set of properties (operands) for use in
defining policies for Differentiated Services.
1.2. Purpose and Relation to Other Policy Work
This model establishes a canonical model of the QoS mechanisms of
a network device (e.g., a router, switch, or host) that is
independent of any specific type of network device. This enables
traffic conditioning to be described using a common set of
abstractions, modeled as a set of services and sub-services.
When the concepts of this draft are used in conjunction with the
concepts of [QOSPIM], then one is able to define policies that
bind the services in a network to the needs of applications using
that network. In other words, the business requirements of an
organization can be reflected in one set of policies, and those
policies can be translated to a lower-level set of policies that
control and manage the configuration and operation of network
devices.
1.3. Typical Examples of Policy Usage
Policies could be implemented as low-level rules using the
information model described in this specification. For example,
in a low-level policy, a condition could be represented as an
evaluation of a specific attribute from this model. Therefore, a
condition such as "If filter = HTTP" would be interpreted as a
test determining whether any HTTP filters have been defined for
the device. A high-level policy, such as "If protocol = HTTP,
then mark with DSCP 24," would be expressed as a series of
actions in a low-level policy using the classes and attributes
described below:
1. Create HTTP filter
2. Create DSCP marker with the value of 24
3. Bind the HTTP filter to the DSCP marker
Note that unlike "mark with DSCP 24," these low-level actions are
not performed on a packet as it passes through the device.
Rather, they are configuration actions performed on the device
itself, to make it ready to perform the correct action(s) on the
correct packet(s). The act of moving from a high-level policy
rule to the correct set of low-level device configuration actions
Strassner, et al. Expires: Nov 2000 + 6 months [Page 7] Internet Draft QoS Device Info Model November 2000
is an example of what [POLTERM] characterizes as "policy
translation" or "policy conversion".
2. Approach
QoS activities in the IETF have mainly focused in two areas,
Integrated Services (IntServ) and Differentiated Services
(DiffServ) (see [POLTERM], [R1633] and [R2475]). This draft
focuses on the specification of QoS attributes and classes for
Differentiated Services. However, the framework defined by the
structure of the classes defined in this document has been
designed with the needs of IntServ as well as DiffServ in mind.
2.1. Common Needs Of DiffServ and IntServ
First, let us consider IntServ. IntServ has two principal
components. One component is embedded in the forwarding engine
of the networking device. Its functions include the
classification and policing of individual flows, and scheduling
admitted packets for the outbound link. The other component of
IntServ is the management of the signaling protocol (e.g., the
PATH and RESV messages of RSVP). This component processes
reservation requests, manages bandwidth, outsources decision
making to policy servers, and interacts with the Routing Table
manager.
We will consider RSVP when defining the structure of this
information model. As this draft initially focuses on the
forwarding engine, elements of RSVP applicable to the forwarding
engine will be considered in the structure of the classes. The
complete IntServ device model will, as we have indicated earlier,
be addressed in a subsequent document.
This draft models a small subset of the QoS policy problem, in
hopes of constructing a methodology that can be adapted for other
aspects of QoS in particular, and of policy construction in
general. The focus in this draft is on QoS for devices that
implement DiffServ.
DiffServ operates exclusively in the forwarding engine. It has
all of the same components of the IntServ forwarding engine with
two major differences. First, DiffServ classifies packets based
solely on their DSCP field, whereas IntServ examines a subset of
a standard flow's addressing 5-tuple. The exception to this rule
occurs in a router or host at the boundary of a DiffServ domain.
A device in this position may examine a packet's DSCP, its
addressing 5-tuple, other fields in the packet, or even
information wholly outside the packet, in determining the DSCP
value with which to mark the packet prior to its transfer into
the DiffServ domain. However, routers in the interior of a
DiffServ domain will only need to classify based on the DSCP
field.
Strassner, et al. Expires: Nov 2000 + 6 months [Page 8] Internet Draft QoS Device Info Model November 2000
The second difference between IntServ and DiffServ is that the
signaling protocol used in IntServ (e.g., RSVP) affects the
forwarding engine in a more dynamic fashion. This is because
each newly admitted RSVP reservation requires a reconfiguration
of the forwarding engine. In contrast, DiffServ requires far
fewer changes to the forwarding engine after the Per-Hop
Behaviors (PHBs) have been configured.
The approach advocated in this draft for the creation of policies
that control the various QoS mechanisms of networking devices is
to first identify the attributes with which policies are to be
constructed. These attributes are the parameters used in
expressions that are necessary to construct policies. There is
also a parallel desire to define the operators, relations, and
precedence constructs necessary to construct the conditions and
actions that constitute these policies. However, these efforts
are beyond the scope of this document.
2.2. Specific Needs Of DiffServ
DiffServ-specific rules focus on two particular areas: the core
and the edges of the network. As explained in the DiffServ
Architecture document [R2475], devices at the edge of the network
classify traffic into different traffic streams. The core of the
network then forwards traffic from different streams by using a
set of Per-Hop Behaviors (PHBs). A DiffServ Code Point (DSCP)
identifies each PHB. The DSCP is part of the IP header of each
packet (as described in [R2474]). This enables multiple traffic
streams to be aggregated into a small number of aggregated
traffic streams, where each aggregate traffic stream is
identified by a particular DSCP, and forwarded using a particular
PHB.
The attributes used to manipulate QoS capabilities in the core of
the network primarily address the behavioral characteristics of
each supported PHB. At the edges of the DiffServ network, the
additional complexities of flow classification, policing, RSVP
mappings, remarkings, and other factors have to be considered.
Additional modeling will be required in this area. However,
first, the standards for edges of the DiffServ network need more
detail - to allow the edges to be incorporated into the policy
model.
2.3. Specific Needs Of IntServ
This document focuses exclusively on the forwarding aspects of
network QoS. Therefore, while the forwarding aspects of IntServ
are considered, the management of IntServ is not considered.
This topic will be addressed in a future draft.
Strassner, et al. Expires: Nov 2000 + 6 months [Page 9] Internet Draft QoS Device Info Model November 2000
3. Methodology
There is a clear need to define attributes and behavior that
together define how traffic should be conditioned. This draft
defines a set of classes and relationships that represent the QoS
mechanisms used to condition traffic; [QOSPIM] is used to define
policies to control the QoS mechanisms defined in this draft.
However, some very basic issues need to be considered when
combining these drafts. Considering these issues should help in
constructing a schema for managing the operation and
configuration of network QoS mechanisms through the use of QoS
policies.
3.1. Level of Abstraction for Expressing QoS Policies
The first issue requiring consideration is the level of
abstraction at which QoS policies should be expressed. If we
consider policies as a set of rules used to react to events and
manipulate attributes or generate new events, we realize that
policy represents a continuum of specifications that relate
business goals and rules to the conditioning of traffic done by a
device or a set of devices. An example of a business level policy
might be: from 1:00 pm PST to 7:00 am EST, sell off 40% of the
network capacity on the open market. In contrast, a device-
specific policy might be: if the queue depth grows at a geometric
rate over a specified duration, trigger a potential link failure
event.
A general model for this continuum is shown in Figure 1 below.
+---------------------+
| High-Level Business | Not directly related to device
| Policies | operation and configuration details
+---------------------+
|
|
+---------V-----------+
| Device-Independent | Translate high-level policies to
| Policies | generic device operational and
+---------------------+ configuration information
|
|
+---------V-----------+
| Device-Dependent | Translate generic device information
| Policies | to specify how particular devices
+---------------------+ should operate and be configured
Figure 1. The Policy Continuum
High-level business policies are used to express the requirements
of the different applications, and prioritize which applications
get "better" treatment when the network is congested. The goal,
Strassner, et al. Expires: Nov 2000 + 6 months [Page 10] Internet Draft QoS Device Info Model November 2000
then, is to use policies to relate the operational and
configuration needs of a device directly to the business rules
that the network administrator is trying to implement in the
network that the device belongs to.
Device-independent policies translate business policies into a
set of generalized operational and configuration policies that
are independent of any specific device, but dependent on a
particular set of QoS mechanisms, such as RED dropping or
weighted round robin scheduling. Not only does this enable
different types of devices (i.e., routers, switches, firewalls,
and hosts) to be controlled by QoS policies, it also enables
devices made by different vendors that use the same types of QoS
mechanisms to be controlled. This enables these different
devices to each supply the correct relative conditioning to the
same type of traffic.
In contrast, device-dependent policies translate device-
independent policies into ones that are specific for a given
device. The reason that a distinction is made between device-
independent and device-dependent policies is that in a given
network, many different devices having many different
capabilities need to be controlled together. Device-independent
policies provide a common layer of abstraction for managing
multiple devices of different capabilities, while device-
dependent policies implement the specific conditioning that is
required. This draft provides a common set of abstractions for
representing QoS mechanisms in a device-independent way.
This draft is focused on the device-independent representation of
QoS mechanisms. QoS mechanisms are modeled in sufficient detail
to provide a common device-independent representation of QoS
policies. They can also be used to provide a basis for
specialization, enabling each vendor to derive a set of vendor-
specific classes that represent how traffic conditioning is done
for that vendor's set of devices.
3.2. Specifying Policy Parameters
Policies are a function of parameters (attributes) and operators
(boolean, arithmetic, relational, etc.). Therefore, both need to
be defined as part of the same policy in order to correctly
condition the traffic. If the parameters of the policy are
specified too narrowly, they will reflect the individual
implementations of QoS in each device. As there is currently
little consensus in the industry on what the correct
implementation model for QoS is, most defined attributes would
only be applicable to the unique characteristics of a few
individual devices. Moreover, standardizing all of these
potential implementation alternatives would be a never-ending
task as new implementations continued to appear on the market.
Strassner, et al. Expires: Nov 2000 + 6 months [Page 11] Internet Draft QoS Device Info Model November 2000
On the other hand, if the parameters of the policy are specified
too broadly, it is impossible to develop meaningful policies.
For example, if we concentrate on the so-called Olympic set of
policies, a business policy like "Bob gets Gold Service," is
clearly meaningless to the large majority of existing devices.
This is because the device has no way of determining who Bob is,
or what QoS mechanisms should be configured in what way to
provide Gold service.
Furthermore, Gold service may represent a single service, or it
may identify a set of services that are related to each other.
In the latter case, these services may have different
conditioning characteristics.
This draft defines a set of parameters that fit into a canonical
model for modeling the elements in the forwarding path of a
device implementing DiffServ. By defining this model in a
device-independent way, the needed parameters can be
appropriately abstracted.
3.3. Specifying Policy Services
Administrators want the flexibility to be able to define traffic
conditioning without having to have a low-level understanding of
the different QoS mechanisms that implement that conditioning.
Furthermore, administrators want the flexibility to group
different services together, so that one group of services as a
whole will receive "better" treatment than another group of
services.
These two goals dictate the need for the following set of
abstractions:
o a flexible way to describe a service
o must be able to group different services that may use
different technologies (e.g., DiffServ and 802.1P)
together
o must be able to define a set of sub-services that
together make up a higher-level service
o must be able to associate a service and the set of QoS
mechanisms that are used to condition traffic for that
service
o must be able to define policies that manage the QoS
mechanisms used to implement a service.
This draft addresses this set of problems by defining a set of
classes and relationships that can represent abstract concepts
like "Gold Service," and bind each of these abstract services to
a specific set of QoS mechanisms that implement the conditioning
Strassner, et al. Expires: Nov 2000 + 6 months [Page 12] Internet Draft QoS Device Info Model November 2000
that they require. Furthermore, this draft defines the concept
of "sub-services," to enable Gold Service to be defined either as
a single service or as a set of services that together should be
treated as an atomic entity.
Given these abstractions, policies (as defined in [QOSPIM]) can
be written to control the QoS mechanisms and services defined in
this draft.
3.4. Level of Abstraction for Defining QoS Attributes and Classes
This draft defines a set of classes and attributes to support
policies that configure device QoS mechanisms. This draft
concentrates on the representation of DiffServ services. A
future draft will define classes and attributes for IntServ
services.
The classes and attributes in this draft are designed to be used
in conjunction with the QoS policy classes and attributes defined
in [QOSPIM]. For example, to preserve the delay characteristics
committed to an end-user, a network administrator may wish to
create policies that monitor the queue depths in a device, and
adjust resource allocations when delay budgets are at risk
(perhaps as a result of a network topology change). The classes
and attributes in this document define the specific services and
mechanisms required to implement those services. The classes and
attributes defined in [QOSPIM] provide the overall structure of
the policy that manages and configures this service.
This combination of low-level specification (using this draft)
and high-level structuring (using [QOSPIM]) of network services
enables network administrators to define new services required of
the network, that are directly related to business goals, while
ensuring that such services can be managed. However, this goal
(of creating and managing service-oriented policies) can only be
realized if policies can be constructed that are capable of
supporting diverse implementations of QoS. The solution is to
model the QoS capabilities of devices at the behavioral level.
This means that for DiffServ, the model must support the
following characteristics:
o modeling of a generic network service that has QoS
capabilities
o modeling of how DiffServ traffic conditioning is defined
o modeling of how statistics are gathered to monitor
DiffServ (and other types of QoS) services
This draft models a network service, and associates it with one
or more QoS mechanisms that are used to implement that service.
It also models in a canonical form the various components that
Strassner, et al. Expires: Nov 2000 + 6 months [Page 13] Internet Draft QoS Device Info Model November 2000
are used to condition DiffServ traffic, such that standard as
well as custom DiffServ services may be described.
Statistics will be added in the next release of this draft.
3.5. Characterization of QoS Attributes
The QoS attributes and classes will be described in more detail
in section 4. However, we should consider the basic
characteristics of these attributes, to understand the
methodology for representing them.
There are essentially two types of attributes, state and
configuration. Configuration attributes describe the desired
state of a device, and include attributes and classes for
representing desired or proposed thresholds, bandwidth
allocations, and how to classify traffic. State attributes
describe the actual state of the device. These include attributes
to represent the current ACTUAL values of the quantities in
devices configured via the configuration attributes, as well as
attributes that represent dynamic state (queue depths, excess
capacity consumption, loss rates, and so forth).
In order for them to be used together, these two types of
attributes must be modeled using a common information model.
This draft makes explicit the common information model for
modeling state as well as configuration attributes for DiffServ
QoS mechanisms. In addition, it emphasizes the need to separate
these two types of attributes.
One should note that the state attributes defined in this draft
are purposely device-independent. In contrast, configuration
attributes that will be defined in a future release of this draft
can be represented and applied to either the same set of devices
or to a specific device. Examples of the former are setting one
or more attributes in all devices in the same domain that share
the same AS (autonomous system) number, or in all core devices
that share the same delay bound for a specific service. Examples
of the latter are setting a specific set of attributes that
configures how a device-specific implementation of a conditioning
mechanism will operate.
This difference between state and configuration attributes
suggests that the schema for configuration attributes will not be
exactly the same as the schema that supports state attributes.
However, many of the attributes defined in this draft represent
exactly the quantities that will be configured by the
configuration attributes. Thus, the definition of these state
and configuration attributes provides the link between modeling
the operational state of a device and setting configuration
parameters of that device. The intersection of these two
schemata will be through the set of attributes, associations, and
aggregations that relate one schema to the other.
Strassner, et al. Expires: Nov 2000 + 6 months [Page 14] Internet Draft QoS Device Info Model November 2000
3.6. QoS Information Model Derivation
The question of context also leads to another question: how does
the information specified in the core and QoS policy models
([PCIM] and [QOSPIM], respectively) integrate with the
information defined in this draft? Put another way, where should
device-independent concepts that lead to device-specific QoS
attributes be derived from?
Past thinking was that QoS was part of the policy model. This
view is not completely accurate, and it leads to confusion. QoS
is a set of services that can be controlled using policy. These
services are represented as device mechanisms. An important
point here is that QoS services, as well as other types of
services (e.g., security), are provided by the mechanisms
inherent in a given device. This means that not all devices are
indeed created equal. For example, although two devices may have
the same type of mechanism (e.g., a queue), one may be a simple
implementation (i.e., a FIFO queue) whereas one may be much more
complex and robust (i.e., CBWFQ). However, both of these devices
can be used to deliver QoS services, and both need to be
controlled by policy. Thus, a device-independent policy can
instruct the devices to queue certain traffic, and a device-
specific policy can be used to control the queuing in each
device.
Furthermore, policy is used to control these mechanisms, not to
represent them. For example, QoS services are implemented with
classifiers, meters, markers, droppers, queues, and schedulers.
Similarly, security is also a characteristic of devices, as
authentication and encryption capabilities represent services
that networked devices perform (irrespective of interactions with
policy servers). These security services may use some of the
same mechanisms that are used by QoS services, such as the
concepts of filters. However, they will mostly require different
mechanisms than the ones used by QoS, even though both sets of
services are implemented in the same devices.
Thus, the similarity between the QoS model and models for other
services is not so much that they contain a few common
mechanisms. Rather, they model how a device implements their
respective services. As such, the modeling of QoS should be part
of a networking device schema rather than a policy schema. This
allows the networking device schema to concentrate on modeling
device mechanisms, and the policy schema to focus on the
semantics of representing the policy itself (conditions, actions,
operators, etc.). While this iteration of this draft
concentrates on defining an information model to represent
DiffServ QoS services, the ultimate goal is to be able to apply
policies that control these services in network devices.
Furthermore, these two schemata (device and policy) must be
tightly integrated in order to enable policy to control QoS
services.
Strassner, et al. Expires: Nov 2000 + 6 months [Page 15] Internet Draft QoS Device Info Model November 2000
3.7. Attribute Representation
The last issue to be considered is the question of how attributes
are represented. If QoS attributes are represented as absolute
numbers (e.g., Class AF2 gets 2 Mbs of bandwidth), it is more
difficult to make them uniform across multiple ports in a device
or across multiple devices, because of the broad variation in
link capacities. However, expressing attributes in relative or
proportional terms (e.g., Class AF2 gets 5% of the total link
bandwidth) makes it more difficult to express certain types of
conditions and actions, such as:
(If ConsumedBandwidth = AssignedBandwidth Then ...)
There are really three approaches to addressing this problem:
o Multiple attributes can be defined to express the same value
in various forms. This idea has been rejected because of the
difficulty in keeping these different attributes synchronized
(e.g., when one attribute changes, the others all have to be
updated).
o Multi-modal attributes can be defined to express the same
value, in different terms, based on the access or assignment
mode. This option was rejected because it significantly
complicates the model and is impossible to express in current
directory access protocols (e.g., (L)DAP).
o Attributes can be expressed as "absolutes", but the operators
in the policy schema would need to be more sophisticated.
Thus, to represent a percentage, division and multiplication
operators are required (e.g., Class AF2 gets .05 * the total
link bandwidth). This is the approach that has been taken in
this draft.
3.8. Mental Model
The mental model for constructing this schema is based on the
work done in the Differentiated Services working group. This
schema is based on information provided in the current versions
of the DiffServ Conceptual Model [DSMODEL], the DiffServ MIB
[DSMIB], the PIB [PIB], as well as on information in the set of
RFCs that constitute the basic definition of DiffServ itself
([R2475], [R2474], [R2597], and [R2598]). In addition, a common
set of terminology is available in [POLTERM].
Note that this work is not yet completely aligned, as there are
differences among the DiffServ Conceptual Model, the DiffServ
MIB, the DiffServ PIB, and this draft. Work to finish aligning
these drafts is in progress, and will be reflected in the next
revision of this draft.
Strassner, et al. Expires: Nov 2000 + 6 months [Page 16] Internet Draft QoS Device Info Model November 2000
This model is built around two fundamental class hierarchies that
are bound together using a set of relationships. The two class
hierarchies derive from the QoSService and ConditioningService
base classes. A set of associations relate lower-level QoSService
subclasses to higher-level QoSServices, relate different types of
ConditioningServices together in processing a traffic class, and
relate a set of ConditioningServices to a specific QoSService.
This combination of relationships enables us to view the device
as providing a set of services that can be configured, in a
modular building block fashion, to construct application-specific
services. Thus, this document can be used to model existing and
future standard as well as application-specific network QoS
services.
3.8.1. The QoSService Class
The first of the classes defined here, QoSService, is used to
represent higher-level network services that require special
conditioning of their traffic. QoSService has a set of subclasses
that represent technology-specific implementations of QoS (e.g.,
DiffServ and 802.1P), as well as a relationship to the second
fundamental class, ConditioningService. The subclasses of
QoSService typically model a set of coordinated, cooperating sub-
services.
The QoS services can be related to each other as peers, or they
can be implemented as subservient services to each other. This
enables us to define Gold Service as (for example) a combination
of the EF PHB to implement a voice service and a set of AF PHBs
to condition data traffic. Furthermore, it lets us think of AF as
a service that requires different sub-services (e.g., a
classification service, a dropping service, etc.) to implement
it. These sub-services derive from the ConditioningService class,
and are related to the QoSService class via the aggregation
QoSConditioningSubService (see section 4 for class and
relationship definitions).
This document, in its current form, identifies three subclasses
of QoSService: DiffServ, 802.1P, and Precedence. The purpose of
these subclasses is to enable administrators to manage the
application of QoS according to the specific technologies that
they are using. Thus, a network consisting of a set of DiffServ-
and non-DiffServ-compliant devices that each provided QoS traffic
conditioning would be modeled using different subclasses of
QoSService. However, the mechanisms can be inter-related, since
they all derive from a common base class, QoSService.
These concepts are depicted in Figure 2. Note that both of the
associations are aggregations: a QoSService aggregates both the
set of QoSServices subservient to it, and the set of
ConditioningServices that realize it.
Strassner, et al. Expires: Nov 2000 + 6 months [Page 17] Internet Draft QoS Device Info Model November 2000
/\______
0..1 \/ |
+--------------+ | QoSSubService +---------------+
| |0..n | | |
| QoSService |----- | Conditioning |
| | | Service |
| | | |
| |0..1 0..n| |
| | /\______________________| |
| | \/ QoSConditioning | |
+--------------+ SubService +---------------+
Figure 2. QoSService and its Aggregations
3.8.2. The ConditioningService Class
The goal of the ConditioningService classes is to describe the
sequence of traffic conditioning that is applied to a given
traffic stream on the ingress interface through which it enters a
device, and then on the egress interface through which it leaves
the device. This is done using a set of classes and
relationships. The routing decision in the device core, which
selects which egress interface a particular packet will use, is
not represented in this model.
A single base class, ConditioningService, is the superclass for a
set of subclasses representing the mechanisms that condition
traffic. These subclasses define device-independent conditioning
primitives (including classifiers, meters, markers, droppers,
queues, and schedulers) that together implement the conditioning
of traffic on an interface. This model abstracts these services
into a common set of modular building blocks that can be used,
regardless of device implementation, to model the traffic
conditioning internal to a device.
The different conditioning mechanisms need to be related to each
other to describe how traffic is conditioned. Several important
variations of how these services are related together exist:
o A particular ingress or egress interface may not require
all the types of ConditioningServices.
o Multiple instances of the same mechanism may be required
on an ingress or egress interface.
o There is no set order of application for the
ConditioningServices on an ingress or egress interface.
Therefore, this model does not dictate a fixed ordering among the
subclasses of ConditioningService, or identify a subclass of
ConditioningService that must appear first or last among the
ConditioningServices on an ingress or egress interface. Instead,
Strassner, et al. Expires: Nov 2000 + 6 months [Page 18] Internet Draft QoS Device Info Model November 2000
this model ties together the various ConditioningService
instances on an ingress or egress interface using the
NextService, NextServiceAfterMeter, and
NextServiceAfterConditioningElement associations (see Section 4).
There is also a separate association, called
ConditioningServiceOnEndpoint (see section 4), with subclasses
that tie an ingress interface to its first ConditioningService,
and tie an egress interface to its last ConditioningService.
3.8.3. QoS Statistics Classes
Various statistics classes were proposed in an earlier iteration
of this draft. Such statistics are necessary to properly
instrument QoS services. However, since the core of the draft
has been reworked, the previous statistics classes are no longer
aligned with the rest of the document. Consequently, they have
been removed. The next iteration of this draft will add these
classes back into the draft.
3.9. Classifiers, FilterLists, and FilterEntries
This draft uses a number of classes to model the classifiers
defined in [DSMODEL]: ClassifierService, ClassifierElement,
FilterList, FilterEntry, and various subclasses of FilterEntry.
There are also two associations involved:
ClassifierElementUsesFilterList and EntriesInFilterList. (The
association ClassifierFilterSet, which is available in the CIM
model for representing other types of classifiers, is not used in
the representation of DiffServ classifiers.) The FilterList and
FilterEntry classes, and the EntriesInFilterList association that
relates them, are used in other models such as BGP and IPsec, as
well as in the QoS device model specified in this draft. Because
they are used in other models, the FilterList and FilterEntry
classes contain elements that are not needed in the QoS device
model. This section identifies the unused elements from these
two classes, while also providing a summary of how all of the
classes are used to model a DiffServ classifier.
In [DSMODEL], a single traffic stream coming into a classifier is
split into multiple traffic streams leaving it, based on which of
an ordered set of filters each packet in the incoming stream
matches. A filter matches either a field in the packet itself,
or possibly "other attributes associated with the packet." In
the case of a multi-field (MF) classifier, packets are assigned
to output streams based on the contents of multiple fields in the
packet header. For example, an MF classifier might assign
packets to an output stream based on their complete IP-addressing
5-tuple.
The FilterEntry class models the process of matching a single
field in a packet (or a single attribute associated with a
packet) against a specified value. Consequently, it takes
multiple FilterEntries to model a selector in an MF classifier.
Strassner, et al. Expires: Nov 2000 + 6 months [Page 19] Internet Draft QoS Device Info Model November 2000
These FilterEntries are combined into a FilterList, using the
EntriesInFilterList aggregation. EntriesInFilterList has a
property EntrySequence, which ordinarily imposes an evaluation
order on the FilterEntries in a FilterList. In the case of a
selector for an MF classifier, however, the EntrySequence
property takes its default value: '0'. This value indicates that
the FilterEntries are ANDed together to determine whether a
packet matches the MF selector that the FilterList represents.
To optimize the representation of MF classifiers, subclasses of
FilterEntry are introduced, which allow multiple related packet
header fields to be represented in a single object. These
subclasses are IP6TupleFilter, 8021Filter, and 8021PQFilter.
With IP6TupleFilter, for example, a test that selects packets
based on all 6 of the IP 6-tuple header fields can be represented
by a FilterList containing one IP6TupleFilter object, as opposed
to a FilterList containing six FilterEntry objects.
The FilterList object is always needed, even if it contains only
one FilterEntry (or one FilterEntry subclass) object. This is
because it is the ClassifierElementUsesFilterList association
that ties a filter back to the classifier in which it is used.
4. The Class Hierarchy
The following sections present the class and association
hierarchies that together comprise the information model for
modeling QoS capabilities at the device level.
4.1. Associations
An association is a means of representing a dependency
relationship between two (or theoretically more) objects. In CIM
and DEN, this type of relationship is modeled as a class
containing two (or more) object references. Since the
association is itself a class, it can benefit from all of the
object-oriented features that other non-association classes have.
For example, it can contain properties and methods, and
inheritance can be used to refine its semantics such that it
represents a more specialized type of dependency.
It is important to note that associations form an inheritance
hierarchy that is separate from the class inheritance hierarchy.
Although associations are typically bi-directional, there is
nothing that prevents higher order associations from being
defined. However, such associations are inherently more complex
to define, understand, and use. In practice, associations of
orders higher than binary are rarely used, because of their
greatly increased complexity and lack of generality. All of the
associations defined in this model are binary.
Strassner, et al. Expires: Nov 2000 + 6 months [Page 20] Internet Draft QoS Device Info Model November 2000
Finally, note that associations that are defined between two
classes do not affect the classes themselves. That is, the
addition or deletion of an association does not affect the
interfaces of the classes that it is connecting.
4.2. Aggregations
An aggregation is a strong form of an association, which usually
represents a "whole-part" or a "collection" relationship. For
example, CIM uses an aggregation to represent the containment
relationship between a system and the components that make it up.
In this draft, all aggregations represent "whole-part"
relationships.
Note that an aggregate object is treated as an atomic unit, even
though it is comprised of, or collects, multiple objects. This is
a defining feature of an aggregation - although the individual
components that make up an aggregate object have their own
identities, the aggregate object that is constructed from these
objects has its own identity and name as well.
"Whole-part" aggregations have some very interesting properties:
o cascaded deletion (if you delete the aggregate, you
delete all of its constituent components)
o transitivity (e.g., if Object A is-a-part-of Object B,
and if Object B is-a-part-of Object C, then Object A is-
a-part-of Object C)
o anti-symmetry (e.g., if Object A is-a-part-of Object B,
then Object B cannot also be a-part-of Object A)
Aggregation is used to represent the physical and/or logical
grouping of related objects.
4.3. The Structure of the Class Hierarchies
The following sections discuss the class hierarchies used to
model the state of QoS devices and services. A later release
will include configuration hierarchies. This model has been
influenced by [CIM], and is compatible with the Directory Enabled
Networks (DEN) effort.
4.3.1. The Class Hierarchies for Modeling State Information
The structure of the class, association, and aggregation class
inheritance hierarchies for managing the state of Differentiated
Services devices is shown, respectively, in Figure 3, Figure 4,
and Figure 5. The following notation is used in these figures:
o (CIMCORE) identifies a class defined in the CIM Core
Model.
Strassner, et al. Expires: Nov 2000 + 6 months [Page 21] Internet Draft QoS Device Info Model November 2000
o (CIMNET) identifies a class defined in the CIM Network
Model. Note that the CIM Network model currently has a
number of Change Requests (CRs) open, which seek to
better align it with the model in this draft. The
(CIMNET) notation indicates an element that is either in
the CIM Network Model now, or is an addition to the model
proposed in one of these CRs.
Please refer to [CIM] for the definitions of the classes in
(CIMCORE) and (CIMNET).
Strassner, et al. Expires: Nov 2000 + 6 months [Page 22] Internet Draft QoS Device Info Model November 2000
+--ManagedElement (CIMCORE)
|
+--ManagedSystemElement (CIMCORE)
| |
| +--LogicalElement (CIMCORE)
| | |
| | +--Service (CIMCORE)
| | | |
| | | +--NetworkService (CIMNET)
| | | | |
| | | | +--ForwardingService (CIMNET)
| | | | | |
| | | | | +--ConditioningService (CIMNET)
| | | | | |
| | | | | +--ClassifierService (CIMNET)
| | | | | | |
| | | | | | +--ClassifierElement
| | | | | |
| | | | | +--MeterService (CIMNET)
| | | | | | |
| | | | | | +--AverageRateMeterService (CIMNET)
| | | | | | |
| | | | | | +--EWMAMeterService (CIMNET)
| | | | | | |
| | | | | | +--TokenBucketMeterService (CIMNET)
| | | | | |
| | | | | +--MarkerService (CIMNET)
| | | | | | |
| | | | | | +--TOSMarkerService (CIMNET)
| | | | | | |
| | | | | | +--DSCPMarkerService (CIMNET)
| | | | | | |
| | | | | | +--8021PMarkerService (CIMNET)
| | | | | |
| | | | | +--DropperService (CIMNET)
| | | | | | |
| | | | | | +--HeadTailDropperService (CIMNET)
| | | | | | |
| | | | | | +--RedDropperService (CIMNET)
| | | | | |
| | | | | +--QueuingService (CIMNET)
| | | | | |
| | | | | +--PacketSchedulingService (CIMNET)
(continued on following page)
Strassner, et al. Expires: Nov 2000 + 6 months [Page 23] Internet Draft QoS Device Info Model November 2000
(continued from previous page;
the first five elements are repeated for convenience)
+--ManagedElement (CIMCORE)
|
+--ManagedSystemElement (CIMCORE)
| |
| +--LogicalElement (CIMCORE)
| |
| +--Service (CIMCORE)
| | |
| | +--NetworkService (CIMNET)
| | | |
| | | +--QoSService (CIMNET)
| | | |
| | | +--DiffServService (CIMNET)
| | | | |
| | | | +--AFService (CIMNET)
| | | | |
| | | | +--EFService (CIMNET)
| | | |
| | | +--PrecedenceService (CIMNET)
| | | |
| | | +--8021PService (CIMNET)
| | |
| | +--DropThresholdCalculationService (CIMNET)
| |
| +--FilterEntryBase (CIMNET)
| | |
| | +--FilterEntry (CIMNET)
| | |
| | +--IP6TupleFilter
| | |
| | +--8021Filter
| | |
| | +--8021PQFilter
| |
| +--FilterList (CIMNET)
| |
| +--ServiceAccessPoint (CIMCORE)
| |
| +--ProtocolEndpoint (CIMNET)
|
+--Collection (CIMCORE)
|
+--CollectionOfMSEs (CIMCORE)
|
+--BufferPool (CIMNET)
Figure 3. Class Inheritance Hierarchy
Strassner, et al. Expires: Nov 2000 + 6 months [Page 24] Internet Draft QoS Device Info Model November 2000
The inheritance hierarchy for the associations defined in this
draft is shown in Figure 4.
+--Dependency (CIMCORE)
| |
| +--ServiceSAPDependency (CIMCORE)
| | |
| | +--ForwardsAmong (CIMNET)
| | |
| | +--ConditioningServiceOnEndpoint (CIMNET)
| | |
| | +--IngressConditioningServiceOnEndpoint
| | |
| | +--EgressConditioningServiceOnEndpoint
| |
| +--HeadTailDropQueueBinding (CIMNET)
| |
| +--CalculationBasedOnQueue (CIMNET)
| |
| +--ProvidesServiceToElement (CIMCORE)
| | |
| | +--ServiceServiceDependency (CIMCORE)
| | |
| | +--QueueHierarchy (CIMNET)
| | |
| | +--CalculationServiceForDropper (CIMNET)
| |
| +--QueueAllocation (CIMNET)
| |
| +--ClassifierFilterSet (CIMNET)
| |
| +--ClassifierElementUsesFilterList
|
+--AFRelatedServices (CIMNET)
|
+--NextService (CIMNET)
|
+--NextServiceAfterMeter (CIMNET)
|
+--NextServiceAfterClassifierElement
|
+--SchedulerUsed (CIMNET)
|
+--PrioritySchedulerUsed (CIMNET)
| |
| +--BoundedPrioritySchedulerUsed (CIMNET)
|
+--BandwidthSchedulerUsed (CIMNET)
|
+--WRRSchedulerUsed (CIMNET)
Figure 4. Association Class Inheritance Hierarchy
Strassner, et al. Expires: Nov 2000 + 6 months [Page 25] Internet Draft QoS Device Info Model November 2000
The inheritance hierarchy for the aggregations defined in this
draft is shown in Figure 5.
+--MemberOfCollection (CIMCORE)
| |
| +--CollectedBufferPool (CIMNET)
|
+--Component (CIMCORE)
|
+--ServiceComponent (CIMCORE)
| |
| +--QoSSubService (CIMNET)
| |
| +--QoSConditioningSubService (CIMNET)
| |
| +--ClassifierElementInClassifierService
|
+--EntriesInFilterList (CIMNET)
Figure 5. Aggregation Class Inheritance Hierarchy
4.3.2. The Class Hierarchies for Modeling Configuration Information
The structure of the class and association class hierarchies for
managing the configuration of Differentiated Services will be
presented in the next iteration of this draft. These hierarchies
are being held back now because the hierarchies for representing
state information that are included here have undergone
significant changes to reflect participant feedback. Once the
state hierarchies have stabilized, the configuration hierarchies
can be added back in.
4.4. Class Definitions for the State Portion of the Model
This section presents the classes and attributes 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 and Network Models [CIM]. Only
the QoS-related classes will be defined in this draft. However,
other classes drawn from the CIM Core and Network Models will be
described briefly. The reader is encouraged to look at [CIM] for
further information. Associations and aggregations will be
defined in Section 4.5.
4.4.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
Strassner, et al. Expires: Nov 2000 + 6 months [Page 26] Internet Draft QoS Device Info Model November 2000
instantiated object. Please refer to [CIM] for the full
definition of this class.
4.4.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 QueueHierarchy and
CalculationServiceForDropper associations.
Please refer to [CIM] for the full definition of this class.
4.4.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.4.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.4.2, this class participates in the
ProvidesServiceToElement association. Please refer to [CIM] for
the full definition of this class.
4.4.5. The Abstract Class NetworkService
This is an abstract class defined in the Network Model of CIM.
It is a subclass of the Service class, and serves as the base
class rooting the network service hierarchy. Network services
Strassner, et al. Expires: Nov 2000 + 6 months [Page 27] Internet Draft QoS Device Info Model November 2000
represent generic functions that are available from the network,
and that condition and/or modify one or more parameters of the
traffic being sent, such as fields in a packet's header. Note
that the network services discussed here are provided by a
network's hosts, as well as by its network devices; for example,
a host might provide classification and conditioning of packets
on its egress interfaces.
None of the associations in which this class participates is used
in the QoS device state model. Please refer to [CIM] for the
full definition of this class.
4.4.6. The Class ForwardingService
This is a concrete class defined in the Network Model of CIM. It
is a subclass of the NetworkService class, and represents the
forwarding of network traffic by receiving data from one or more
communication sources, and either discarding it or sending it via
other communication sources. The properties of ForwardingService
are ProtocolType and OtherProtocolType, describing the type of
protocol being forwarded. None of the associations in which this
class participates is used directly in the QoS device state
model. The ForwardsAmong association is, however, the superclass
for the model's ConditioningServiceOnEndpoint association.
Please refer to [CIM] for the full definition of this class.
4.4.7. The Class ConditioningService
This is a concrete class defined in the Network Model of CIM. It
is a subclass of ForwardingService, and 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 draft. 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 iterations.
ConditioningService is a concrete class because of considerations
related to CIM naming. 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.
Strassner, et al. Expires: Nov 2000 + 6 months [Page 28] Internet Draft QoS Device Info Model November 2000
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 ForwardingService
TYPE Concrete
PROPERTIES Enabled
4.4.7.1 The Property Enabled
This property is a boolean that, if TRUE, signifies that the
instance's conditioning function can be performed on traffic that
it encounters.
4.4.8. The Class ClassifierService
This is a concrete class defined in the Network Model of CIM.
The concept of a Classifier comes from [DSMODEL]. It 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. (Currently the only
filters defined in the model make their selections based only on
a packet's contents.) Each output stream is the result of
matching a particular filter.
In the CIM QoS model, the association ClassifierFilterSet links a
classifier to the set of FilterLists that it uses to sort
traffic. In this document, however, the representation of
classifiers is closer to that presented in [DSMIB] and [DSMODEL].
Rather than being linked directly to its FilterLists by the
ClassifierFilterSet association, a classifier is modeled here as
an aggregation of ClassifierFilterElements. Each of these
ClassifierFilterElements is then linked to a single FilterList by
the association ClassifierElementUsesFilterList, which is derived
from the more general association ClassifierFilterSet.
A Classifier is modeled as a ConditioningService so that it can
be aggregated into a QoSService (using the
QoSConditioningSubService aggregation), and can use the
NextService association to identify the subsequent
ConditioningServices for different traffic streams.
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.
Strassner, et al. Expires: Nov 2000 + 6 months [Page 29] Internet Draft QoS Device Info Model November 2000
DERIVED FROM ConditioningService
TYPE Concrete
PROPERTIES HaveClassifiedPackets
4.4.8.1 The Property HaveClassifiedPackets
This is a boolean property that, if TRUE, indicates that this
Classifier has already processed at least one packet.
4.4.9. The Class ClassifierElement
This concrete class is not currently defined in the Network Model
of CIM, although it may be added to the model at some point in
the future. The concept of a ClassifierElement comes from
[DSMIB]. It represents the linkage, within a single
ClassifierService, between a FilterList that selects 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, although it inherits HaveClassifiedPackets
from its superclass, ClassifierService. It is present to serve
as the anchor for an aggregation with its classifier, and for
associations with its FilterList and its next
ConditioningService.
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
4.4.10. The Class MeterService
This is a concrete class defined in the Network Model of CIM.
This class 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
Strassner, et al. Expires: Nov 2000 + 6 months [Page 30] Internet Draft QoS Device Info Model November 2000
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 a subclass of the NextService association, to
identify the subsequent ConditioningServices 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.4.10.1 The Property MeterType
This attribute 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 - TokenBucketMeter
4.4.10.2 The Property OtherMeterType
This is a string attribute that defines a vendor-specific
description of a type of meter. It is used when the value of the
MeterType attribute in the instance is equal to 1.
4.4.10.3 The Property ConformanceLevels
This attribute 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.
Strassner, et al. Expires: Nov 2000 + 6 months [Page 31] Internet Draft QoS Device Info Model November 2000
4.4.11. The Class AverageRateMeter
This is a concrete class, defined in the Network Model of CIM.
It is a subclass of MeterService, and 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 AverageRateMeter
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.4.11.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.4.11.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.4.12. The Class EWMAMeter
This is a concrete class, defined in the Network Model of CIM.
It is a subclass of the MeterService class, and 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 EWMAMeter
DESCRIPTION A concrete class classifying admitted
traffic as either conforming or non-
conforming, depending on whether the
arrival of a packet causes the average
Strassner, et al. Expires: Nov 2000 + 6 months [Page 32] Internet Draft QoS Device Info Model November 2000
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.4.12.1 The Property AverageRate
This attribute 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.4.12.2 The Property DeltaInterval
This attribute is an unsigned 64-bit integer that defines the
sampling interval used to measure the arrival rate in bytes. The
calculated rate is averaged over this interval and checked
against the AverageRate attribute. All packets whose computed
average arrival rate is less than the AverageRate are deemed
conforming.
The value is specified in microseconds.
4.4.12.3 The Property Gain
This attribute 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 attribute represents a time constant value of
1/64.
4.4.13. The Class TokenBucketMeter
This is a concrete class defined in the Network Model of CIM. It
describes 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].
Strassner, et al. Expires: Nov 2000 + 6 months [Page 33] Internet Draft QoS Device Info Model November 2000
The class definition is as follows:
NAME TokenBucketMeter
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.4.13.1 The Property AverageRate
This attribute is an unsigned 32-bit integer that specifies the
committed rate of the meter. The value is expressed in kilobits
per second.
4.4.13.2 The Property PeakRate
This attribute is an unsigned 32-bit integer that specifies the
peak rate of the meter. The value is expressed in kilobits per
second.
4.4.13.3 The Property BurstSize
This attribute 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.4.13.4 The Property ExcessBurstSize
This attribute is am 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.4.14. The Class MarkerService
This is a concrete class, defined in the Network Model of CIM.
It 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 of considerations
related to CIM naming. 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.
Strassner, et al. Expires: Nov 2000 + 6 months [Page 34] Internet Draft QoS Device Info Model November 2000
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 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
4.4.15. The Class ToSMarkerService
This is a concrete class, defined in the Network Model of CIM.
It 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
process of marking the type of service
(ToS) field in the IPv4 packet header
with a specified value. Packets are
marked in order to control the
conditioning that they will subsequently
receive.
DERIVED FROM MarkerService
TYPE Concrete
PROPERTIES ToSValue
4.4.15.1 The Property ToSValue
This property is an unsigned 8-bit integer, representing a value
to be used for marking the type of service (ToS) field in the
IPv4 packet header. The ToS field is defined to be a complete
octet, so the range for this property is 0..255. Some
implementations, however, require that the lowest-order bit in
the ToS field always be '0'. Such an implementation is
consequently unable to support an odd TosValue.
Strassner, et al. Expires: Nov 2000 + 6 months [Page 35] Internet Draft QoS Device Info Model November 2000
4.4.16. The Class DSCPMarkerService
This is a concrete class, defined in the Network Model of CIM.
It represents the marking of the differentiated services
codepoint (DSCP) within the DS field in the IPv4 and IPv6 packet
headers, as defined in [R2474]. 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 DSCPMarkerService
DESCRIPTION A concrete class representing the
process of marking the DSCP field
in a packet with a specified
value. Packets are marked in order
to control the conditioning that
they will subsequently receive.
DERIVED FROM MarkerService
TYPE Concrete
PROPERTIES DSCPValue
4.4.16.1 The Property DSCPValue
This property is an unsigned 8-bit integer, representing a value
to be used for marking the DSCP within the DS field in an IPv4 or
IPv6 packet header. Since the DSCP consists of 6 bits, the
values for this property are limited to the range 0..63. When
the DSCP is marked, the remaining two bit in the DS field are
left unchanged.
4.4.17. The Class PriorityMarkerService
This is a concrete class, defined in the Network Model of CIM.
It represents the marking of the the user priority field defined
in the IEEE P802.1Q specification [IEEE802Q]. 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 PriorityMarkerService
DESCRIPTION A concrete class representing the
process of marking the the Priority
field in an 802.1Q-compliant frame
with a specified value. Frames are
marked in order to control the
conditioning that they will
subsequently receive.
DERIVED FROM MarkerService
TYPE Concrete
PROPERTIES PriorityValue
Strassner, et al. Expires: Nov 2000 + 6 months [Page 36] Internet Draft QoS Device Info Model November 2000
4.4.17.1 The Property PriorityValue
This property is an unsigned 8-bit integer, representing a value
to be used for marking the Priority field in the 802.1Q header.
Since the Priority field consists of 3 bits, the values for this
property are limited to the range 0..7. When the Priority field
is marked, the remaining bits in its octet are left unchanged.
4.4.18. The Class DropperService
This is a concrete class, defined in the Network Model of CIM.
It represents the ability to selectively drop network traffic, or
to invoke another ConditioningService for further processing of
traffic that is not dropped. This is the base class for
different types of droppers. Droppers are distinguished by the
algorithm that they use to drop traffic. Please see [DSMODEL]
for more information about the various types of droppers. Note
that this class encompasses both Absolute Droppers and
Algorithmic Droppers from [DSMODEL].
DropperService 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 that acts on any remaining traffic that is
not dropped.
The class definition is as follows:
NAME DropperService
DESCRIPTION A concrete base class describing the
common characteristics of droppers.
DERIVED FROM ConditioningService
TYPE Concrete
PROPERTIES DropperType, OtherDropperType
Note: The DropperType property and the DropperService subclasses
provide similar information. The DropperType property is defined
for query purposes, as well as for those cases where a subclass
of DropperService is not needed to model a particular type of
dropper. For example, the Absolute Dropper defined in [DSMODEL]
is modeled as an instance of the DropperService class with its
DropperType set to '6' ("Absolute Dropper").
4.4.18.1 The Property DropperType
This is an enumerated 16-bit unsigned integer that defines the
type of dropper. Values include:
1 - Other
Strassner, et al. Expires: Nov 2000 + 6 months [Page 37] Internet Draft QoS Device Info Model November 2000
2 - Head
3 - Tail
4 - RED
5 - Weighted RED
6 - Absolute Dropper
4.4.18.2 The Property OtherDropperType
This string attribute is used in conjunction with the DropperType
attribute. When the value of DropperType is '1' (i.e., Other),
then the name of the type of dropper (for this instance) appears
in this attribute.
4.4.19. The Class HeadTailDropperService
This is a concrete class, defined in the Network Model of CIM.
It describes the threshold information of a head or tail dropper.
The class definition is as follows:
NAME HeadTailDropperService
DESCRIPTION A concrete class used to describe
a head or tail dropper.
DERIVED FROM DropperService
TYPE Concrete
PROPERTIES QueueThreshold
4.4.19.1 The Property QueueThreshold
This is an unsigned 32-bit integer that indicates the queue depth
at which traffic will be dropped. For a tail dropper, all newly
arriving traffic is dropped. For a head dropper, packets at the
front of the queue are dropped to make room for new packets,
which are added at the end. The value is expressed in bytes.
4.4.20. The Class REDDropperService
This is a concrete class, defined in the Network Model of CIM.
It describes the ability to drop network traffic using a Random
Early Detection (RED) algorithm. This algorithm is described in
[RED]. The purpose of a RED algorithm is to avoid congestion (as
opposed to managing congestion). Instead of waiting for the
queues to fill up, and then dropping large numbers of packets,
RED works by monitoring the average queue depth. When the queue
depth exceeds a minimum threshold, packets are randomly
discarded. These discards cause TCP to slow down its
transmission rate for those connections that experienced the
packet discards. Other TCP connections are not affected by these
discards. Please see [DSMODEL] for more information about a
dropper.
The class definition is as follows:
Strassner, et al. Expires: Nov 2000 + 6 months [Page 38] Internet Draft QoS Device Info Model November 2000
NAME REDDropperService
DESCRIPTION A concrete class used to describe
dropping using the RED algorithm (or
one of its variants).
DERIVED FROM DropperService
TYPE Concrete
PROPERTIES MinQueueThreshold, MaxQueueThreshold,
StartProbability, StopProbability
NOTE: In [DSMIB], there is a single diffServRandomDropTable,
which represents the general category of random dropping. (RED
is one type of random dropping, but there are also types of
random dropping distinct from RED.) The REDDropperService class
corresponds to the columns in the table that apply to the RED
algorithm in particular. Work is ongoing to decide how/whether
this model should represent the other columns in the table.
4.4.20.1 The Property MinQueueThreshold
This is an unsigned 32-bit integer that defines the minimum
average queue depth (in bytes) at which packets are subject to
being dropped. The slope of the drop probability function is
described by the Start/StopProbability properties.
4.4.20.2 The Property MaxQueueThreshold
This is an unsigned 32-bit integer that defines the maximum
average queue length (in bytes) at which packets are subject to
always being dropped, regardless of the dropping algorithm and
probabilities being used
4.4.20.3 The Property StartProbability
This is an unsigned 32-bit integer; in conjunction with the
StopProbability attribute, it defines the slope of the drop
probability function. This function governs the rate at which
packets are subject to being dropped, as a function of the queue
length.
Min and max values are 0 to 100.
4.4.20.4 The Property StopProbability
This is an unsigned 32-bit integer; in conjunction with the
StartProbability attribute, it defines the slope of the drop
probability function. This function governs the rate at which
packets are subject to being dropped, as a function of the queue
length.
Min and max values are 0 to 100.
Strassner, et al. Expires: Nov 2000 + 6 months [Page 39] Internet Draft QoS Device Info Model November 2000
4.4.21. The Class QueuingService
This is a concrete class defined in the Network Model of CIM. It
represents the ability to queue network traffic, and to specify
the characteristics for determining long-term congestion. Please
see [DSMODEL] for more information about queuing functionality.
QueuingService 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.
The class definition is as follows:
NAME QueuingService
DESCRIPTION A concrete class describing the ability
to queue network traffic and to specify
the characteristics for determining
long-term congestion.
DERIVED FROM ConditioningService
TYPE Concrete
PROPERTIES
NOTE: While they are not (yet) part of the Network Model of CIM,
the authors are investigating adding two properties to the
QueuingService class:
o An unsigned 32-bit integer CurrentQueueDepth, to function
as a gauge that represents the current depth of this one
queue. This value may be important in diagnosing
unexpected behavior by a DropThresholdCalculationService.
o A boolean property VirtualQueue, to identify "queues" in
a hierarchy of bandwidth-scheduled queues that have
bandwidth to share with other queues in the hierarchy,
but do not themselves enqueue any packets.
4.4.22. The Class PacketSchedulingService
This is a concrete class defined in the Network Model of CIM. It
represents a scheduling service, which is a process that
determines when a queued packet should be removed from a queue
and sent to an output interface. Note that output interfaces can
be physical network interfaces or interfaces to components
internal to systems, such as crossbars or back planes. In either
case, if multiple queues are involved, schedulers are used to
provide access to the interface.
Each instance of a PacketSchedulingService describes a scheduler
from the perspective of the queues that it is servicing. Please
see [DSMODEL] for more information about a scheduler.
Strassner, et al. Expires: Nov 2000 + 6 months [Page 40] Internet Draft QoS Device Info Model November 2000
PacketSchedulingService 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, if any, that acts on traffic after it has
been processed by the scheduler.
The class definition is as follows:
NAME PacketSchedulingService
DESCRIPTION A concrete class used to determine when
a packet should be removed from a
queue and sent to an output interface.
DERIVED FROM ConditioningService
TYPE Concrete
PROPERTIES SchedulerType, OtherSchedulerType,
WorkConserving
4.4.22.1 The Property SchedulerType
This attribute is an enumerated 16-bit unsigned integer, and
defines the type of scheduler. Values are:
1 - Other
2 - FIFO
3 - Priority
4 - Bandwidth
5 - Bounded Strict Priority
6 - Round Robin Packet
7 - Weighted Round Robin Packet
8 - Class-Based Queuing
9.- Custom Queuing
10 - Weighted Fair Queuing
11 - Weighted Interleaved Round Robin
4.4.22.2 The Property OtherSchedulerType
This attribute is used in conjunction with the SchedulerType
attribute. When the value of SchedulerType is 1 (i.e., Other),
then the type of scheduler is specified in this attribute.
4.4.22.3 The Property WorkConserving
If the value of this boolean attribute is TRUE, then the
scheduling algorithm services a packet, if one is available, at
every transmission opportunity.
4.4.23. The Class QoSService
This is a concrete class defined in the Network Model of CIM. It
represents the ability to conceptualize a QoS service as a set of
coordinated sub-services. This enables the network administrator
Strassner, et al. Expires: Nov 2000 + 6 months [Page 41] Internet Draft QoS Device Info Model November 2000
to map business rules to the network, and the network designer to
engineer the network such that it can provide different functions
for different traffic streams.
This class has two main purposes. First, it serves as a common
base class for defining the various sub-services needed to build
higher-level QoS services. Second, it serves as a way to
consolidate the relationships between different types of QoS
services and different types of ConditioningServices.
For example, Gold Service may be defined as a set of sub-
services, where each of these sub-services performs one or more
different functions required by the higher-level service.
Continuing the example, Gold Service may be used to specify EF
for one traffic stream, along with different AF services for
other different traffic streams. Each of these services is an
instance of the class QoSService, and each requires a set of sub-
services to be defined as part of its implementation. For
example, one would expect to see different marking, dropping, and
queuing sub-services to be defined for each of these services.
This is modeled as a type of NetworkService, which is used as the
anchor point for defining a set of sub-services that implement
the desired conditioning characteristics for different types of
flows. It will direct the specific type of ConditioningServices
to be used in order to implement this service.
The class definition is as follows:
NAME QoSService
DESCRIPTION A concrete class used to represent a QoS
service or set of services, as defined
by a network administrator.
DERIVED FROM NetworkService
TYPE Concrete
PROPERTIES
4.4.24. The Class DiffServService
This is a concrete class defined in the Network Model of CIM.
This class represents using standard or custom DiffServ services
to implement a (higher-level) QoS service. Note that the
DiffServService may be just one of a set of coordinated
QoSSubServices that together implement a higher-level QoS
service.
DiffServService is modeled as a subclass of QoSService. This
enables it to be related to a higher-level QoS service via
QoSSubService, as well as to specific ConditioningServices (e.g.,
classification, metering, dropping, queuing, and others) via
QoSConditioningSubService.
The class definition is as follows:
Strassner, et al. Expires: Nov 2000 + 6 months [Page 42] Internet Draft QoS Device Info Model November 2000
NAME DiffServService
DESCRIPTION A concrete class used to represent a
DiffServ service, or a set of DiffServ
services.
DERIVED FROM QoSService
TYPE Concrete
PROPERTIES DSCP
4.4.24.1 The Property DSCP
This attribute is an unsigned 8-bit integer. It identifies a
Differentiated Services Code Point used to represent various
types of differentiated services, through device-specific
configuration commands.
4.4.25. The Class AFService
This is a concrete class defined in the Network Model of CIM. It
represents a specialization of the general concept of forwarding
network traffic by adding specific semantics that characterize
the operation of the Assured Forwarding (AF) Service ([R2597]).
[R2597] defines four different AF classes, to represent four
different treatments of traffic. A different amount of
forwarding resources, such as buffer space and bandwidth, are
allocated to each AF class. Within each AF class, IP packets are
marked with one of three possible drop precedence values. The
drop precedence of a packet determines the relative importance of
that packet compared to other packets within the same AF class,
if congestion occurs. A congested interface will try to avoid
dropping packets marked with a lower drop precedence value, by
instead discarding packets marked with a higher drop precedence
value.
Note that [R2597] defines 12 DSCPs that together represent the AF
Per-Hop Behavior (PHB) group. Implementations are free to extend
this (e.g., add more classes and/or drop precedences).
The AFService class is modeled as a specialization of
DiffServService, which is in turn a specialization of QoSService.
This enables it to be related to higher-level QoS services, as
well as to lower-level conditioning sub-services (e.g.,
classification, metering, dropping, queuing, and others).
The class definition is as follows:
NAME AFService
DESCRIPTION A concrete class for describing the
common characteristics of differentiated
services that are used to affect
traffic forwarding, using the AF
PHB Group.
DERIVED FROM DiffServService
Strassner, et al. Expires: Nov 2000 + 6 months [Page 43] Internet Draft QoS Device Info Model November 2000
TYPE Concrete
PROPERTIES ClassNumber, DropperNumber
4.4.25.1 The Property ClassNumber
This attribute is an 8-bit unsigned integer that indicates the
number of AF classes that this AF implementation uses.
Implementations should define at least four classes.
4.4.25.2 The Property DropperNumber
This attribute is an 8-bit unsigned integer that indicates the
number of drop precedence values that this AF implementation
uses. The number of drop precedence values is the number PER AF
CLASS. Implementations should define at least three drop
precedence values per class.
4.4.26. The Class EFService
This is a concrete class defined in the Network Model of CIM. It
represents a specialization of the general concept of forwarding
network traffic by adding specific semantics that characterize
the operation of the Expedited Forwarding (EF) Service ([R2598]).
The EFService class is modeled as a specialization of
DiffServService, which is in turn a specialization of QoSService.
This enables it to be related to a higher-level QoS service, as
well as to lower-level conditioning sub-services (e.g.,
classification, metering, dropping, queuing, and others).
The EF PHB can be used to build a low loss, low latency, low
jitter, assured bandwidth, end-to-end service through DiffServ
domains. Such a service appears to the endpoints like a point-
to-point connection or a virtual leased line. This service has
also been described as Premium service.
[R2598] defines one DSCP for the EF service. The inherited DSCP
property will contain this value for all instances of EFService.
The class definition is as follows:
NAME EFService
DESCRIPTION A concrete class for describing the
common characteristics of differentiated
services that are used to affect
traffic forwarding using the EF
PHB Group.
DERIVED FROM DiffServService
TYPE Concrete
PROPERTIES
Strassner, et al. Expires: Nov 2000 + 6 months [Page 44] Internet Draft QoS Device Info Model November 2000
4.4.27. The Class PrecedenceService
This is a concrete class defined in the NetworkModel of CIM. It
represents a specialization of the general concept of forwarding
network traffic by adding specific semantics that define how
traffic is forwarded based on the value of the ToS byte of a
packet.
This class is used to enable DiffServ devices and non-DiffServ
devices to exchange traffic. The sibling class DiffServService
is used to represent devices that forward traffic based on the
DiffServ code point, while this class represents devices that use
the ToS byte. Using these two classes, the administrator can
define mappings between devices that do not support DiffServ, and
instead use IP Precedence, and devices that do support DiffServ,
which use DSCPs.
Since the PrecedenceService class is a specialization of
QoSService, instances can be related to higher-level QoS services
using the QoSSubService association. Instances can also be
related to lower-level sub-services (e.g., classification,
metering, dropping, queuing, and others), using the
QoSConditioingSubService association.
The class definition is as follows:
NAME PrecedenceService
DESCRIPTION A concrete class for describing the
common characteristics of forwarding
traffic based on the value of the
ToS byte.
DERIVED FROM DiffServService
TYPE Concrete
PROPERTIES PrecedenceValue
4.4.27.1 The Property PrecedenceValue
This attribute is an 8-bit unsigned integer that defines the
notion of precedence for different types of traffic. See [R2474]
for more information on the definition and use of this attribute,
as well as on its backward compatibility with the ToS byte of
IPv4.
4.4.28. The Class 8021PService
This is a concrete class defined in the Network Model of CIM. It
represents a specialization of the general concept of forwarding
network traffic by adding specific semantics that define how
traffic is forwarded based on the value of the user priority
field defined in the IEEE P802.1Q specification [IEEE802Q].
Strassner, et al. Expires: Nov 2000 + 6 months [Page 45] Internet Draft QoS Device Info Model November 2000
This class is used to enable DiffServ devices and domains that
support 802.1P, to exchange traffic. It allows implementations
that only support 802.1P priority marking to be mapped to
implementations that support DiffServ, which uses DSCPs.
Since the 8021PService class is a specialization of QoSService,
instances can be related to higher-level QoS services using the
QoSSubService association. Instances can also be related to
lower-level sub-services (e.g., classification, metering,
dropping, queuing, and others), using the
QoSConditioingSubService association.
The class definition is as follows:
NAME 8021PService
DESCRIPTION A concrete class for describing the
common characteristics of forwarding
traffic based on the value of the
Priority field in the 802.1P header.
DERIVED FROM QoSService
TYPE Concrete
PROPERTIES PriorityValue
4.4.28.1 The Property PriorityValue
This attribute is an 8-bit unsigned integer that represents a
priority value, as specified in the 802.1Q standards.
4.4.29. The Class DropThresholdCalculationService
This class represents a logical entity that calculates an average
queue depth, possibly across several queues, based on a smoothing
weight and a sampling time interval. It does this calculation on
behalf of a RED dropper, to allow the dropper to make its
decisions whether to drop packets based on an average queue depth
calculated across a set of queues.
The class definition is as follows:
NAME DropThresholdCalculationService
DESCRIPTION A concrete class representing a logical
entity that calculates an average queue
depth, possibly across several queues,
based on a smoothing weight and a
sampling time interval. The latter are
properties of this Service, describing
how it operates and its necessary
parameters.
DERIVED FROM Service
TYPE Concrete
PROPERTIES SmoothingWeight, TimeInterval
Strassner, et al. Expires: Nov 2000 + 6 months [Page 46] Internet Draft QoS Device Info Model November 2000
4.4.29.1 The Property SmoothingWeight
This property is a 32-bit unsigned integer, ranging between 0 and
100,000 - specified in thousandths. It defines the weighting of
past history in affecting the calculation of the current queue
average. When performing this calculation over a single queue,
the current queue depth uses the inverse of this value as its
factor, and one minus that inverse as the factor for the
historical average. The calculation takes the form:
average = (old_average*(1-inverse of SmoothingWeight))
+ (current_queue_depth*inverse of SmoothingWeight)
When performing this calculation over multiple queues, the value
for current_queue_depth is based on the current depths of all the
queues being monitored.
Implementations may choose to limit the acceptable set of values
to a specified set, such as powers of 2.
Min and max values are 0 and 100000.
4.4.29.2 The Property TimeInterval
This property is a 32-bit unsigned integer, defining the number
of nano-seconds between each calculation of average/smoothed
queue depth. If this property is not specified, the
CalculationService may determine an appropriate interval.
4.4.30. The Abstract Class FilterEntryBase
A simplistic but accurate view of the CIM filter classes is:
- FilterEntries aggregated into FilterLists,
- Which are then used by the ClassifierService
- To separate incoming traffic into different traffic classes
(and service levels).
FilterEntryBase is an abstract class defined in the Network Model
of CIM. It is the base class for all filter entries, and is the
endpoint of the association aggregating filter entries into
filter lists. Its properties include CIM naming attributes and
an IsNegated boolean property (to easily "NOT" the match
information specified in FilterEntryBase's subclasses). Please
refer to [CIM] for the full definition of this class.
4.4.31. The Class FilterEntry
FilterEntry is a concrete class defined in the Network Model of
CIM. It is specific to packet filtering, identifying traffic for
Strassner, et al. Expires: Nov 2000 + 6 months [Page 47] Internet Draft QoS Device Info Model November 2000
forwarding/further processing or for dropping. Please refer to
[CIM] for the full definition of this class.
FilterEntry's properties include:
- TrafficType (an enumeration) - Indicates the type of traffic
that is filtered. This property affects what can be
specified in MatchCondition. Currently, only IP-related
values ("IPv4", "IPX", and "IPv6") and the special value
"Any" are defined. "Any" is used when the DefaultFilter
property indicates that this is the default FilterEntry for
its FilterList.
- MatchConditionType (an enumeration) - Specifies the type of
condition that will be matched - source/destination address
and mask, port or port range, protocol type, DiffServ
codepoint, ToS Value, 802.1 Priority, etc. The special
value "Any" is also defined here, for use, once again, in
the default FilterEntry in a FilterList.
- OtherMatchConditionType (a string) - When the
MatchConditionType is "Other" (value = 1), this string
explicitly describes the type of MatchCondition.
- MatchConditionValue (a string) - Indicates the specific
value(s) to match (or NOT match if the inherited IsNegated
property is TRUE). When the value of MatchConditionType is
"Any", this property's value is the empty string.
- ActionType (an enumeration) - This property is not used in
modeling DiffServ classifiers. It always takes its default
value 3 ("Filter Only").
- DefaultFilter (a boolean) - This property is not used in
modeling DiffServ classifiers. It always takes its default
value FALSE.
- TrafficClass (a string) - Specifies the label for the
traffic class of a packet, when this FilterEntry selects the
packet. (A FilterEntry selects a packet if the packet
matches it and its IsNegated property is FALSE, or if the
packet fails to match it and its IsNegated property is
TRUE.) This property is not used in modeling DiffServ
classifiers. It always takes its default value "N/A", not
applicable.
4.4.32. The Class IP6TupleFilter
This concrete class is not currently defined in the Network Model
of CIM, although it may be added to the model at some point in
the future. It is an optimization of the FilterEntry class, that
allows an entire IP 6-tuple filter to be expressed in a single
object.
Strassner, et al. Expires: Nov 2000 + 6 months [Page 48] Internet Draft QoS Device Info Model November 2000
The class definition is as follows:
NAME IP6TupleFilter
DESCRIPTION An optimization of FilterEntry, which
allows an IP 6-tuple filter (or any
subset of one) to be expressed in a
single object.
DERIVED FROM FilterEntry
TYPE Concrete
PROPERTIES SrcAddress, SrcMask, DestAddress,
DestMask, DSCP, ProtocolID,
SrcPortStart, SrcPortEnd,
DestPortStart, DestPortEnd
Since IP6TupleFilter is a subclass of FilterEntry, it has the
TrafficType property to categorize its source and destination
addresses as either IPv4 or IPv6. Note that this mechanism
requires that the two addresses be of the same type.
<<DETAILS OF THE PROPERTIES TO BE ADDED IN THE NEXT VERSION.>>
4.4.33. The Class 8021Filter
This concrete class is not currently defined in the Network Model
of CIM, although it may be added to the model at some point in
the future. It is an optimization of the FilterEntry class, that
allows 802.1.source and destination MAC addresses, as well as the
802.1 protocol ID, to be expressed in a single object
The class definition is as follows:
NAME 8021Filter
DESCRIPTION An optimization of FilterEntry, which
allows the 802.1 source and destination
MAC addresses and the protocol ID to be
expressed in a single object.
DERIVED FROM FilterEntry
TYPE Concrete
PROPERTIES SrcMAC, DestMAC, ProtocolID
<<DETAILS OF THE PROPERTIES TO BE ADDED IN THE NEXT VERSION.>>
4.4.34. The Class 8021PQFilter
This concrete class is not currently defined in the Network Model
of CIM, although it may be added to the model at some point in
the future. It continues the optimization of the FilterEntry
class begun in the 8021Filter class, by adding 802.1Q priority
and VLAN identifier fields to the 802.1 fields already combined
in the 8021Filter class.
The class definition is as follows:
Strassner, et al. Expires: Nov 2000 + 6 months [Page 49] Internet Draft QoS Device Info Model November 2000
NAME 8021PQFilter
DESCRIPTION An optimization of 8021Filter, which
adds 802.1 priority and VLAN identifier
fields.
DERIVED FROM 8021Filter
TYPE Concrete
PROPERTIES PriorityValue, VLANID
<<DETAILS OF THE PROPERTIES TO BE ADDED IN THE NEXT VERSION.>>
4.4.35. The Class FilterList
This is a concrete class defined in the Network Model of CIM. It
aggregates instances (of subclasses) of FilterEntryBase via the
aggregation EntriesInFilterList. It is possible to aggregate
different types of filters into a single FilterList - for
example, aggregating packet filters (which are instances of
FilterEntry or its subclasses) and security filters (which are
subclasses of FilterEntryBase defined in the IPsec portion of the
CIM Network Model).
The aggregation property EntriesInFilterList.EntrySequence serves
to order the filter entries in the FilterList. This is necessary
when algorithms such as "Match First" are used to identify
traffic based on an aggregated set of FilterEntries. In modeling
DiffServ classifiers, however, this property is always set to 0,
to indicate that the aggregated FilterEntries are ANDed together
to form a selector for a class of traffic.
Please refer to [CIM] for the full definition of the FilterList
and EntriesInFilterList classes.
4.4.36. The Abstract Class ServiceAccessPoint
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 manage access to CIM_Services. It
represents the management of utilizing or invoking a Service.
Please refer to [CIM] for the full definition of this class.
4.4.37. The Class ProtocolEndpoint
This is a concrete class defined in the Network Model of CIM. It
is derived from ServiceAccessPoint, and describes a communication
point from which the services of the network or the system's
protocol stack may be accessed. Please refer to [CIM] for the
full definition of this class.
4.4.38. The Abstract Class Collection
This is an abstract class defined in the Core Model of CIM. It
is the superclass for all classes that represent groupings or
bags, and that carry no status or "state". (The latter would be
Strassner, et al. Expires: Nov 2000 + 6 months [Page 50] Internet Draft QoS Device Info Model November 2000
more correctly modeled as ManagedSystemElements.) Please refer
to [CIM] for the full definition of this class.
4.4.39. The Abstract Class CollectionOfMSEs
This is an abstract class defined in the Core Model of CIM. It
is a subclass of the Collection superclass, restricting the
contents of the Collection to ManagedSystemElements. Please
refer to [CIM] for the full definition of this class.
4.4.40. The Class BufferPool
This is a concrete class, defined in the NetworkModel of CIM. It
represents the collection of buffers used by a QueuingService.
(The association QueueAllocation describes this usage semantic.)
The existence and management of individual buffers will be
modeled in a future release. At the current level of
abstraction, modeling the existence of the BufferPool is
necessary. Long term, it is not sufficient.
In implementations where there are multiple buffer sizes, an
instance of BufferPool should be defined for each set of buffers
with identical or similar sizes. These instances of buffer pools
can then be grouped together using the CollectedBuffersPool
aggregation.
Note that this class is derived from CollectionOfMSEs, and not
from Forwarding or ConditioningService. A BufferPool is only a
collection of storage, and is NOT a Service.
The class definition is as follows:
NAME BufferPool
DESCRIPTION A concrete class representing
a collection of buffers.
DERIVED FROM CollectionOfMSEs
TYPE Concrete
PROPERTIES Name, BufferSize, TotalBuffers,
AvailableBuffers, SharedBuffers
4.4.40.1 The Property Name
This attribute is a string with a maximum length of 256
characters. It is the common name or label by which the object
is known.
4.4.40.2 The Property BufferSize
This attribute is a 16-bit unsigned integer, identifying the
approximate number of bytes in each buffer in the buffer pool.
An implementation will typically group buffers of roughly the
same size together, to reduce the number of buffer pools it needs
Strassner, et al. Expires: Nov 2000 + 6 months [Page 51] Internet Draft QoS Device Info Model November 2000
to manage. This model does not specify the degree to which
buffers in the same buffer pool may differ in size.
4.4.40.3 The Property TotalBuffers
This attribute is a 32-bit unsigned integer, reporting the total
number of individual buffers in the pool.
4.4.40.4 The Property AvailableBuffers
This attribute is a 32-bit unsigned integer, reporting the number
of buffers in the Pool that are currently not allocated to any
instance of a QueuingService. Buffers allocated to a
QueuingService could either be in use (that is, currently contain
packet data), or be allocated to a queue pending the arrival of
new packet data.
4.4.40.5 The Property SharedBuffers
This attribute is a 32-bit unsigned integer, reporting the number
of buffers in the Pool that have been simultaneously allocated to
multiple instances of QueuingService.
4.5. Association Definitions for the State Portion of the Model
This section details the QoS device class associations, which
were shown earlier in Figure 5. These associations are defined
as classes (that can have properties) in the Information Model.
4.5.1. The Abstract Association Dependency
This abstract association defines two object references (named
Antecedent and Dependent) that establish general dependency
relationships between different managed objects in the
information model. The Antecedent reference identifies the
independent object in the association, while the Dependent
reference identifies the entity that IS dependent.
The association's cardinality is many to many.
The association is defined in the CIM Core Model of CIM. Please
refer to [CIM] for the full definition of this class.
4.5.2. The Association ServiceSAPDependency
This association defines two object references that establish a
general dependency relationship between a Service object and a
ServiceAccessPoint object. This relationship indicates that the
referenced Service uses the ServiceAccessPoint of ANOTHER
Service. The Service is the Dependent reference, relying on the
ServiceAccessPoint to gain access to another Service.
The association's cardinality is many to many.
Strassner, et al. Expires: Nov 2000 + 6 months [Page 52] Internet Draft QoS Device Info Model November 2000
The association is defined in the Core Model of CIM. Please
refer to [CIM] for the full definition of this class.
4.5.3. The Association Forwards Among
This association defines two object references that establish a
general dependency relationship between the ProtocolEndpoints
that are used to forward data and the ForwardingService that is
performing the forwarding. The ProtocolEndpoints that are used
to forward the data are the Antecedent reference. The service
that is forwarding the data is the Dependent reference.
The association's cardinality is many to many.
The association is defined in the Network Model of CIM. Please
refer to [CIM] for the full definition of this class.
4.5.4. The Association ConditioningServiceOnEndpoint
This association is defined in the Network Model of CIM. It
establishes a dependency relationship between a ProtocolEndpoint
object and a ConditioningService object. This relationship
indicates that the referenced ProtocolEndpoint is used by the
ConditioningService for traffic to enter or leave the device.
The direction of the traffic is represented by the property
ServiceType, which indicates whether the ConditioningService
object handles incoming or outgoing traffic. The
ProtocolEndpoint represents whether the traffic arrives at or
leaves from a network device, and the ConditioningService that
begins or ends the traffic conditioning process within a network
device.
This class is derived from the ForwardsAmong association. It
restricts the Dependent to instances of the ConditioningService
class (instead of the more generic ForwardingService class).
The class definition for this association is as follows:
NAME ConditioningServiceOnEndpoint
DESCRIPTION A generic association used to establish
dependency relationships between a
ConditioningService object and a
ProtocolEndpoint object.
DERIVED FROM ServiceSAPDependency
ABSTRACT False
PROPERTIES Dependent[ref ConditioningService[0..n]],
ServiceType
4.5.4.1 The Reference Dependent
This property is inherited from the ForwardsAmong association,
and overridden to serve as an object reference to a
ConditioningService object (instead of to the more general
Strassner, et al. Expires: Nov 2000 + 6 months [Page 53] Internet Draft QoS Device Info Model November 2000
Service object). This reference indicates the
ConditioningService that begins or ends the traffic conditioning
processing within a network device. When the ServiceType
property indicates the ingress direction, then this reference
identifies the first ConditioningService encountered by traffic
entering the device via this ProtcolEndpoint. When the
ServiceType property indicates the egress direction, then this
reference identifies the last ConditioningService to process
traffic leaving the device via this ProtocolEndpoint.
4.5.4.2 The Property ServiceType
This property is a 16-bit unsigned integer that indicates whether
a packet is incoming (value = 1, "Ingress") or outgoing (value =
2, "Egress") at the ProtocolEndpoint, relative to the
ConditioningService.
4.5.5. The Association IngressConditioningServiceOnEndpoint
This association is not currently defined in the Network Model of
CIM, although it may be added to the model at some point in the
future. It is derived from ConditioningServiceOnEndpoint, and
represents the binding, in the ingress direction, between a
protocol endpoint and the first ConditioningService that
processes packets received via that protocol endpoint. Since
there can only be one "first" ConditioningService for a protocol
endpoint, the cardinality for the Dependent object reference is
narrowed from 0..n to 0..1. Since, on the other hand, a single
ConditioningService can be the first to process packets received
via multiple protocol endpoints, the cardinality of the
Antecedent object reference remains 0..n. Finally, the value of
the ServiceType property, which is inherited from
ConditioningServiceOnEndpoint, is fixed at '1' ("Ingress").
4.5.6. The Association EgressConditioningServiceOnEndpoint
This association is not currently defined in the Network Model of
CIM, although it may be added to the model at some point in the
future. It is derived from ConditioningServiceOnEndpoint, and
represents the binding, in the egress direction, between a
protocol endpoint and the last ConditioningService that processes
packets before they leave a network device via that protocol
endpoint. (This "last" ConditioningService is ordinarily a
scheduler, but it doesn't have to be.) Since there can only be
one "last" ConditioningService for a protocol endpoint, the
cardinality for the Dependent object reference is narrowed from
0..n to 0..1. Similarly, since a single ConditioningService
cannot be the last one to process packets for multiple protocol
endpoints, the cardinality of the Antecedent object reference is
also narrowed from 0..n to 0..1. Finally, the value of the
ServiceType property, which is inherited from
ConditioningServiceOnEndpoint, is fixed at '2' ("Egress").
Strassner, et al. Expires: Nov 2000 + 6 months [Page 54] Internet Draft QoS Device Info Model November 2000
4.5.7. The Association HeadTailDropQueueBinding
This association is defined in the Network Model of CIM. It is a
subclass of Dependency, describing the association between a head
or tail dropper and the queue that it monitors to determine when
to drop traffic. The referenced queue is the one whose queue
depth is compared against the Dropper's threshold. The
cardinality is 1 on the queue side, since a head/tail dropper
must monitor a queue.
The class definition is as follows:
NAME HeadTailDropQueueBinding
DESCRIPTION A generic association used to establish a
dependency relationship between a
head or tail dropper and the queue that it
monitors.
DERIVED FROM Dependency
ABSTRACT False
PROPERTIES Antecedent[ref QueuingService[1..1]],
Dependent[ref
HeadTailDropperService [0..n]]
4.5.8. The Association CalculationBasedOnQueue
This association is defined in the Network Model of CIM. It is a
subclass of Dependency, and defines two object references that
establish a dependency relationship between a QueuingService and
an instance of the DropThresholdCalculationService class. The
queue's current depth is used by the calculation service in
calculating an average queue depth.
The class definition is as follows:
NAME CalculationBasedOnQueue
DESCRIPTION A generic association used to establish a
dependency relationship between a
QueuingService object and a
DropThresholdCalculationService object.
DERIVED FROM ServiceServiceDependency
ABSTRACT False
PROPERTIES Antecedent[ref QueuingService[0..n]],
Dependent[ref
DropThresholdCalculationService [0..n]]
4.5.8.1 The Reference Antecedent
This property is inherited from the Dependency association, and
overridden to serve as an object reference to a QueuingService
object (instead of to the more general ManagedElement). This
reference identifies a queue that the
Strassner, et al. Expires: Nov 2000 + 6 months [Page 55] Internet Draft QoS Device Info Model November 2000
DropThresholdCalculationService will use in its calculation of
average queue depth.
4.5.8.2 The Reference Dependent
This property is inherited from the Dependency association, and
overridden to serve as an object reference to a
DropThresholdCalculationService object (instead of to the more
general ManagedElement). This reference identifies a
DropThresholdCalculationService that uses the referenced queue's
current depth as one of the inputs to its calculation of average
queue depth.
4.5.9. The Association ProvidesServiceToElement
This association defines two object references that establish a
dependency relationship in which a ManagedSystemElement depends
on the functionality of one or more Services. 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.5.10. The Association ServiceServiceDependency
This association defines two object references that establish a
dependency relationship between two Service objects. The
particular type of dependency is represented by the
TypeOfDependency property; typical examples include that one
Service is required to be present or required to have completed
for the other Service to operate.
This association is very similar to the ServiceSAPDependency
relationship. For the latter, the Service is dependent on an
AccessPoint to get at another Service. In this relationship, it
directly identifies its Service dependency. Both relationships
should not be instantiated, since their information is
repetitive.
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.5.11. The Association QueueHierarchy
This association is defined in the Network Model of CIM. It is a
subclass of ServiceServiceDependency, and defines two object
references that establish a dependency relationship between two
QueuingService objects.
The class definition is as follows:
Strassner, et al. Expires: Nov 2000 + 6 months [Page 56] Internet Draft QoS Device Info Model November 2000
NAME QueueHierarchy
DESCRIPTION A generic association used to establish a
dependency relationship between two
QueuingService objects.
DERIVED FROM ServiceServiceDependency
ABSTRACT False
PROPERTIES Antecedent[ref QueuingService[0..n]],
Dependent[ref QueuingService[0..1]]
4.5.11.1 The Reference Antecedent
This property is inherited from the ServiceServiceDependency
association, and overridden to serve as an object reference to a
QueuingService object (instead of to the more general Service
object). This reference defines the supporting queue through its
QueuingService. This QueuingService can only support at most one
higher-level QueuingService.
4.5.11.2 The Reference Dependent
This property is inherited from the ServiceServiceDependency
association, and overridden to serve as an object reference to a
QueuingService object (instead of to the more general Service
object). It also restricts the cardinality of this end of the
relationship to 0-or-1 (instead of the more generic 0-or-more).
This reference indicates the QueuingService that depends on one
or more other, lower-level QueuingServices.
4.5.12. The Association CalculationServiceForDropper
This association is defined in the Network Model of CIM. It is a
subclass of ServiceServiceDependency, and defines two object
references that represent the reliance of a REDDropperService on
a DropThresholdCalculationService - calculating an average queue
depth based on the observed depths of one or more queues.
The class definition is as follows:
NAME CalculationServiceForDropper
DESCRIPTION A generic association used to establish a
dependency relationship between a
calculation service and a
REDDropperSrevice for which it performs
average queue depth calculations
DERIVED FROM ServiceServiceDependency
ABSTRACT False
PROPERTIES Antecedent[ref
DropThresholdCalculationService[1..1]],
Dependent[ref REDDropperService[0..n]]
Strassner, et al. Expires: Nov 2000 + 6 months [Page 57] Internet Draft QoS Device Info Model November 2000
4.5.12.1 The Reference Antecedent
This property is inherited from the ServiceServiceDependency
association, and overridden to serve as an object reference to a
DropThresholdCalculationService object (instead of to the more
general Service object). The cardinality of the object reference
is also restricted to 1, indicating that a RED dropper is always
served by exactly one calculation service.
4.5.12.2 The Reference Dependent
This property is inherited from the ServiceServiceDependency
association, and overridden to serve as an object reference to a
REDDropperService object (instead of to the more general Service
object). This reference identifies a RED dropper served by a
DropThresholdCalculationService.
4.5.13. The Association QueueAllocation
This association is defined in the Network Model of CIM. It is a
subclass of Dependency, and defines two object references that
establish a dependency relationship between a QueuingService and
a BufferPool that provides storage space for the packets in the
queue.
The class definition is as follows:
NAME QueueAllocation
DESCRIPTION A generic association used to establish a
dependency relationship between a
QueuingService object and a BufferPool
object.
DERIVED FROM Dependency
ABSTRACT False
PROPERTIES Antecedent[ref BufferPool[0..n]],
Dependent[ref QueuingService[0..n]]
4.5.13.1 The Reference Antecedent
This property is inherited from the Dependency association, and
overridden to serve as an object reference to a BufferPool
object. This reference identifies the BufferPool in which
packets on the QueuingService's queue are stored.
4.5.13.2 The Reference Dependent
This property is inherited from the Dependency association, and
overridden to serve as an object reference to a QueuingService
object. This reference identifies the QueuingService whose
packets are being stored in the BufferPool's buffers.
Strassner, et al. Expires: Nov 2000 + 6 months [Page 58] Internet Draft QoS Device Info Model November 2000
4.5.14. The Association ClassifierFilterSet
This association is defined in the Network Model of CIM. In
order for a ClassifierService to correctly identify and process
network traffic, that traffic must be described by FilterEntries,
which are aggregated into FilterLists. This association defines
the Dependency of a ClassifierService on FilterLists (and,
therefore, on their FilterEntries).
In the DiffServ model, a classifier is always modeled as a
ClassifierService that aggregates a set of ClassifierElements. A
consequence of this modeling choice is that there is never a
ClassifierFilterSet association between a DiffServ
ClassifierService and a FilterList. Instead, there is an
instance of the association ClassifierElementUsesFilterList,
which is itself a subclass of ClassifierFilterSet, between each
of the ClassifierElements and a FilterList.
The class definition is as follows:
NAME ClassifierFilterSet
DESCRIPTION A generic association used to establish a
dependency relationship between a
ClassifierService object and a FilterList
object.
DERIVED FROM Dependency
ABSTRACT False
PROPERTIES Antecedent[ref FilterList [0..n]],
Dependent[ref ClassifierService [0..n]],
FilterListPosition
4.5.14.1 The Reference Antecedent
This property is inherited from the Dependency association, and
overridden to serve as an object reference to a FilterList
object, instead of to the more general ManagedElement object.
4.5.14.2 The Reference Dependent
This property is inherited from the Dependency association, and
overridden to serve as an object reference to a ClassifierService
object, instead of to the more general ManagedElement object.
This reference identifies a ClassifierService that depends on the
associated FilterList objects to provide its classification
logic.
4.5.14.3 The Property FilterListPosition
This property is a 32-bit unsigned integer, that provides an
ordering of the FilterLists used in the classification and
forwarding functions of the ClassifierService. The semantics of
this ordering are left unspecified in this model.
Strassner, et al. Expires: Nov 2000 + 6 months [Page 59] Internet Draft QoS Device Info Model November 2000
4.5.15. The Association ClassifierElementUsesFilterList
This association is not currently defined in the Network Model of
CIM, although it may be added to the model at some point in the
future. It is a subclass of the ClassifierFilterSet association.
It relates one or more ClassifierElements with a FilterList that
selects packets for each ClassifierElement to process. Since a
given ClassifierElement is always associated with exactly one
FilterList, the FilterListPosition property inherited from
ClassifierFilterSet has no significance, and thus always returns
its default value '0'.
In the DiffServ model, a classifier is always modeled as a
ClassifierService that aggregates a set of ClassifierElements.
The class definition is as follows:
NAME ClassifierElementUsesFilterList
DESCRIPTION An association relating a
ClassifierElement to the FilterList
that selects packets for that
ClassifierElement to process.
DERIVED FROM ClassifierFilterSet
ABSTRACT False
PROPERTIES Antecedent[ref FilterList [1..1]],
Dependent[ref ClassifierElement [0..n]]
4.5.15.1 The Reference Antecedent
This property is inherited from the ClassifierFilterSet
association. Its cardinality is restricted to 1, indicating that
a ClassifierElement always has exactly one FilterList to select
packets for it.
4.5.15.2 The Reference Dependent
This property is inherited from the ClassifierFilterSet
association, and overridden to serve as an object reference to a
ClassifierElement object, instead of to the more general
ClassifierService object. This reference identifies a
ClassifierElement that depends on the associated FilterList
object to select packets for it.
4.5.16. The Association AFRelatedServices
This association is defined in the Network Model of CIM. It
defines two object references that establish a dependency
relationship between two AFService objects. This dependency is
the precedence of the individual AF drop-related Services within
an AF IP packet-forwarding class.
The class definition is as follows:
Strassner, et al. Expires: Nov 2000 + 6 months [Page 60] Internet Draft QoS Device Info Model November 2000
NAME AFRelatedServices
DESCRIPTION An association used to establish
a dependency relationship between two
AFService objects.
DERIVED FROM Nothing
ABSTRACT False
PROPERTIES AFLowerDropPrecedence[ref
AFService[0..1]],
AFHigherDropPrecedence[ref
AFService[0..n]]
4.5.16.1 The Reference AFLowerDropPrecedence
This property serves as an object reference to an AFService
object that has the lower probability of dropping packets.
4.5.16.2 The Reference AFHigherDropPrecedence
This property serves as an object reference to an AFService
object that has the higher probability of dropping packets.
4.5.17. The Association NextService
This association is defined in the Network Model of CIM. It
defines two object references that establish a dependency
relationship between two ConditioningService objects. This
association is used to indicate the sequence of
ConditioningServices required to process a particular type of
traffic.
Instances of this dependency describe the various relationships
between different ConditioningServices (such as classifiers,
meters, droppers, etc.) that are used collectively to condition
traffic. Both one-to-one and more complicated fan-in and/or fan-
out relationships can be described. The ConditioningServices may
feed one another directly, or they may be mapped to multiple
"next" Services based on the characteristics of the packet.
The class definition is as follows:
NAME NextService
DESCRIPTION An association used to establish
a dependency relationship between two
ConditioningService objects.
DERIVED FROM Nothing
ABSTRACT False
PROPERTIES PrecedingService[ref
ConditioningService[0..n]],
FollowingService[ref
ConditioningService[0..n]],
TrafficClass
Strassner, et al. Expires: Nov 2000 + 6 months [Page 61] Internet Draft QoS Device Info Model November 2000
4.5.17.1 The Reference PrecedingService
This property serves as an object reference to a
ConditioningService object that occurs earlier in the processing
sequence for a given type of traffic.
4.5.17.2 The Reference FollowingService
This property serves as an object reference to a
ConditioningService object that occurs later in the processing
sequence for a given type of traffic, immediately after the
ConditioningService identified by the PrecedingService object
reference.
4.5.17.3 The Property TrafficClass
This property is a string used to identify different traffic
flows that have been separated by a Classifier. In environments
such as Differentiated Services, in which microflows are not
tracked, the value of this property is defaulted to "N/A",
indicating that microflow-level tracking is not applicable.
4.5.18. The Association NextServiceAfterMeter
This association is defined in the Network Model of CIM. It
defines two object references that establish a dependency
relationship between a MeterService and one or more
ConditioningService objects that process traffic from the
MeterService. It subclasses the NextService association to
restrict the independent (or PrecedingService) to be a
MeterService.
Meters are 1:n fan-out elements, which means that we need a way
to distinguish between the different outputs of a meter.
Therefore, this association also defines a new property,
MeterResult, which can be used to identify the output through
which this traffic left the meter.
The class definition is as follows:
NAME NextServiceAfterMeter
DESCRIPTION An association used to establish
a dependency relationship between a
particular output of a MeterService
and the next ConditioningService
object that is responsible for further
processing of the traffic.
DERIVED FROM NextService
ABSTRACT False
PROPERTIES PrecedingService[ref MeterService[0..n]],
MeterResult
Strassner, et al. Expires: Nov 2000 + 6 months [Page 62] Internet Draft QoS Device Info Model November 2000
4.5.18.1 The Reference PrecedingService
This property is inherited from the NextService association. It
is overridden in this subclass to restrict the object reference
to a MeterService, as opposed to the more general
ConditioningService defined in the NextService superclass.
This property serves as an object reference to a MeterService
object that occurs earlier in the processing sequence for a given
type of traffic. 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.5.18.2 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.5.19. The Association NextServiceAfterClassifierElement
This association is not currently defined in the Network Model of
CIM, although it may be added to the model at some point in the
future. It refines the definition of its superclass, the
NextService association, in two ways:
o It restricts the PrecedingService object reference to the
class ClassifierElement.
o It restricts the cardinality of the FollowingService object
reference to exactly 1.
The class definition is as follows:
NAME NextServiceAfterClassifierElement
DESCRIPTION An association used to establish
a dependency relationship between a
single ClassifierElement within a
Classifier and the next
ConditioningService object that is
responsible for further processing of
the traffic selected by that
ClassifierElement.
DERIVED FROM NextService
ABSTRACT False
PROPERTIES PrecedingService
[ref ClassifierElement[0..n]],
Strassner, et al. Expires: Nov 2000 + 6 months [Page 63] Internet Draft QoS Device Info Model November 2000
FollowingService
[ref ConditioningService[1..1]
4.5.19.1 The Reference PrecedingService
This property is inherited from the NextService association. It
is overridden in this subclass to restrict the object reference
to a ClassifierElement, as opposed to the more general
ConditioningService defined in the NextService superclass.
This property serves as an object reference to a
ClassifierElement, which is a component of a single
ClassifierService. Packets selected by this ClassifierElement
are always passed to the ConditioningService identified by the
FollowingService object reference.
4.5.19.2 The Reference FollowingService
This property is inherited from the NextService association. It
is overridden in this subclass to restrict the cardinality of the
reference to exactly 1. This reflects the requirement that the
behavior of a DiffServ classifier must be deterministic: the
packets selected by a given ClassifierElement in a given
ClassifierService must always go to one and only one next
ConditioningService.
4.5.20. The Association SchedulerUsed
This association is defined in the Network Model of CIM. It is a
subclass of NextService, and defines two object references that
establish a dependency relationship between one or more
QueuingService objects and a PacketSchedulingService that removes
packets from the queues. A scheduler is thus represented as the
NextService after each of the queues that it empties.
There are some usage restrictions related to this association
that cannot be expressed via its cardinality. Ideally, the
association should convey that a QueuingService has one
associated PacketSchedulingService - i.e., that the cardinality
is '1' on the PacketSchedulingService side. However, at the
instance level, it is not required that the SchedulerUsed class
be instantiated. In addition, AT MOST one of the association's
subclasses will be appropriate/instantiated. Therefore,
cardinality is set to '0..1', with the usage stipulation that one
instance of SchedulerUsed or one of its subclasses MUST relate a
QueuingService to a PacketSchedulingService.
The class definition is as follows:
NAME SchedulerUsed
DESCRIPTION A generic association used to establish
dependency relationships between a
PacketSchedulingService object and
Strassner, et al. Expires: Nov 2000 + 6 months [Page 64] Internet Draft QoS Device Info Model November 2000
one or more QueuingService objects.
DERIVED FROM NextService
ABSTRACT False
PROPERTIES PrecedingService[ref
QueuingService[0..n]],
FollowingService[ref
PacketSchedulingService[0..1]]
4.5.20.1 The Reference PrecedingService
This property is inherited from the NextService association, and
overridden to serve as an object reference to a QueuingService
object (instead of to the more general ConditioningService
object). This reference indicates the queue(s) and the
associated QueuingService(s) that depend on the
PacketSchedulingService.
4.5.20.2 The Reference FollowingService
This property is inherited from the NextService association, and
overridden to serve as an object reference to a
PacketSchedulingService object (instead of to the more general
ConditioningService object). This reference identifies the
PacketSchedulingService that is used to empty the queue(s)
represented by the QueuingService(s).
4.5.21. The Association PrioritySchedulerUsed
This association is defined in the Network Model of CIM; it is a
subclass of the SchedulerUsed association. PrioritySchedulerUsed
indicates that a scheduler is taking packets from a set of queues
using the priority scheduling discipline. The property Priority
on the association represents the priority for a queue, relative
to the priorities of all the other queues to which the scheduler
is related via the PrioritySchedulerUsed association. Queues to
which a scheduler is related via other subclasses of
SchedulerUsed do not figure in this prioritization.
The class definition is as follows:
NAME PrioritySchedulerUsed
DESCRIPTION This association specializes the
SchedulerUsed association to add
a Priority property. This property is
used by a SchedulingService that is doing
priority scheduling for a set of queues.
DERIVED FROM SchedulerUsed
ABSTRACT False
PROPERTIES Priority
Strassner, et al. Expires: Nov 2000 + 6 months [Page 65] Internet Draft QoS Device Info Model November 2000
4.5.21.1 The Property Priority
This property is a 16-bit unsigned integer that indicates the
priority level of a queue relative to the other queues serviced
by this PacketSchedulingService. A larger value represents a
higher priority.
4.5.22. The Association BoundedPrioritySchedulerUsed
This association is defined in the Network Model of CIM; it is a
subclass of the PrioritySchedulerUsed association.
BoundedPrioritySchedulerUsed adds an upper bound (in kilobits per
second) on how much traffic can be transmitted from a queue. This
data is specific to the queue, handled by the referenced
scheduler. It is needed when bounded strict priority scheduling
is performed.
The class definition is as follows:
NAME BoundedPrioritySchedulerUsed
DESCRIPTION This association specializes the
PrioritySchedulerUsed association to add
a BandwidthBound property. This property
bounds the rate at which traffic from the
referenced queue can be transmitted.
DERIVED FROM PrioritySchedulerUsed
ABSTRACT False
PROPERTIES BandwidthBound
4.5.22.1 The Property BandwidthBound
This property is a 32-bit unsigned integer that defines the upper
limit on the amount of traffic that can be transmitted from the
queue. This is not a shaped upper bound, since bursts can occur.
It is a strict bound, limiting the impact of the queue. The
units are kilobits per second.
4.5.23. The Association BandwidthSchedulerUsed
This association is defined in the Network Model of CIM; it is a
subclass of the SchedulerUsed association.
BandwidthSchedulerUsed introduces three new properties related to
bandwidth scheduling.
The class definition is as follows:
NAME BandwidthSchedulerUsed
DESCRIPTION This association specializes the
SchedulerUsed relationship to add
bandwidth allocation. This is used
by a BandwidthSchedulingService when
handling its associated queues.
Strassner, et al. Expires: Nov 2000 + 6 months [Page 66] Internet Draft QoS Device Info Model November 2000
DERIVED FROM SchedulerUsed
ABSTRACT False
PROPERTIES BandwidthAllocation, BurstAlloccation,
CanShare
4.5.23.1 The Property BandwidthAllocation
This property is a 32-bit unsigned integer that defines the
number of kilobits/second that should be allocated to the
associated queue.
4.5.23.2 The Property BurstAllocation
This property is a 32-bit unsigned integer that specifies the
amount of temporary or short-term bandwidth (in kilobits per
second) that can be allocated to a queue, beyond the amount of
bandwidth allocated through the BandwidthAllocation attribute.
If the maximum actual bandwidth allocation for the queue were to
be measured, it would be the sum of the BurstAllocation and the
BandwidthAllocation properties
4.5.23.3 The Property CanShare
This is a boolean property that, if TRUE, enables unused
bandwidth from the associated queue to be allocated to other
queues serviced by the Scheduler.
4.5.24. The Association WRRSchedulerUsed
This association is defined in the Network Model of CIM; it is a
subclass of the SchedulerUsed association. WRRSchedulerUsed
introduces a new property WeightingFactor, to give some queues a
higher probability of being serviced than other queues. It also
introduces a property Priority, to serve as a tiebreaker to be
used when queues have equal weighting factors.
The class definition is as follows:
NAME WRRSchedulerUsed
DESCRIPTION This association specializes the
SchedulerUsed association to add
a per-queue weight. This is used
by a weighted round robin packet
scheduler when it handles its
associated queues.
DERIVED FROM SchedulerUsed
ABSTRACT False
PROPERTIES WeightingFactor,
Priority
Strassner, et al. Expires: Nov 2000 + 6 months [Page 67] Internet Draft QoS Device Info Model November 2000
4.5.24.1 The Property WeightingFactor
This property is a 32-bit unsigned integer, which defines the
weighting factor that offers some queues a higher probability of
being serviced than other queues. This property represents this
probability. Its minimum value is 0, its maximum value is
100000, and its units are thousandths.
4.5.24.2 The Property Priority
This property is a 16-bit unsigned integer, which serves as a
tiebreaker, in the event that two or more queues have equal
weights. A larger value represents a higher priority.
While this condition may not occur in some implementations of a
weighted round robin scheduler, many implementations require a
priority to resolve an equal-weight condition. In instances
where this behavior is not necessary or is undesirable, this
property may be left unspecified.
4.5.25. 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.5.26. The Aggregation CollectedBufferPool
This aggregation is defined in the Network Model of CIM. It
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]]
Strassner, et al. Expires: Nov 2000 + 6 months [Page 68] Internet Draft QoS Device Info Model November 2000
4.5.26.1 The Reference Collection
This property represents the parent, or aggregate, object in the
relationship. It is a BufferPool object.
4.5.26.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.5.27. 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.5.28. 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 is defined in the Core Model of CIM. Please
refer to [CIM] for the full definition of this class.
4.5.29. The Aggregation QoSSubService
This aggregation is defined in the Network Model of CIM. It
represents a set of subordinate QoSServices 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
Strassner, et al. Expires: Nov 2000 + 6 months [Page 69] Internet Draft QoS Device Info Model November 2000
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.5.29.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.5.29.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.5.30. The Aggregation QoSConditioningSubService
This aggregation is defined in the Network Model of CIM. It is
used to define the set of ConditioningServices that together
condition traffic for a particular QoSService.
This aggregation is subclassed from the more generic
ServiceComponent superclass to restrict the types of objects that
can participate in this relationship 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 that they
provide traffic conditioning for.
DERIVED FROM ServiceComponent
ABSTRACT False
PROPERTIES GroupComponent[ref QoSService[0..1]],
PartComponent[ref
ConditioningService[0..n]]
4.5.30.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). It also
restricts the cardinality of the aggregate to 0-or-1 (instead of
the more generic 0-or-more).
Strassner, et al. Expires: Nov 2000 + 6 months [Page 70] Internet Draft QoS Device Info Model November 2000
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.5.30.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.5.31. The Aggregation ClassifierElementInClassifierService
This aggregation is not currently defined in the Network Model of
CIM, although it may be added to the model at some point in the
future. It 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:
Strassner, et al. Expires: Nov 2000 + 6 months [Page 71] Internet Draft QoS Device Info Model November 2000
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.5.31.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.5.31.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 has associations to a FilterList that selects
packets from the traffic stream coming into the classifier, and
to a ConditioningService to which packets selected by this
FilterList are next forwarded.
4.5.31.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.
4.5.32. 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 FilterEntry can
Strassner, et al. Expires: Nov 2000 + 6 months [Page 72] Internet Draft QoS Device Info Model November 2000
figure in the QoS Device model is by being aggregated into a
FilterList by this aggregation.
The aggregation is defined in the Network Model of CIM. Please
refer to [CIM] for the full class definition.
5. Intellectual Property
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 group for their
many helpful comments and suggestions.
7. Security Considerations
Security and denial of service considerations are not explicitly
considered in this memo, as they are appropriate for the
underlying policy architecture implementing the distribution and
communication of the information described in this draft.
Specifically, any mechanisms used to distribute and communicate
the information described in this draft must minimize theft and
denial of service threats. Second, it must be ensured that the
entities involved in policy control can verify each other's
identity and establish necessary trust before communicating.
The communication tunnel between policy clients and policy
servers SHOULD be secured by the use of an IPSEC [R1825] channel.
Strassner, et al. Expires: Nov 2000 + 6 months [Page 73] Internet Draft QoS Device Info Model November 2000
It is advisable that this tunnel makes use of both the AH
(Authentication Header) and ESP (Encapsulating Security Payload)
protocols, in order to provide confidentiality, data origin
authentication, integrity and replay prevention.
8. References
[CIM] Common Information Model (CIM) Schema, version 2.4.
Distributed Management Task Force, Inc. The components of the
CIM v2.4 schema are available via links on the following DMTF
web page: http://www.dmtf.org/spec/cims.html.
[DSMIB] Management Information Base for the Differentiated
Services Architecture. Internet Draft, draft-ietf-diffserv-
mib-06.txt, F. Baker, K. Chan, and A. Smith. November 2000.
[DSMODEL] An Informal Management Model for DiffServ Routers.
Internet Draft, draft-ietf-diffserv-model-05.txt, Y. Bernet,
A. Smith, S. Blake, and D. Grossman. November 2000.
[IEEE802Q] Virtual Bridged Local Area Networks, ANSI/IEEE std
802.1Q, 1998 edition. Approved December 8, 1998
[PCIM] Policy Core Information Model - Version 1 Specification.
Internet Draft, draft-ietf-policy-core-info-model-08.txt, B.
Moore, E. Ellison, J. Strassner, and A. Westerinen. October
2000.
[PIB] Differentiated Services Quality of Service Policy
Information Base. Internet Draft, draft-ietf-diffserv-pib-
01.txt, M. Fine, K. McCloughrie, J. Seligson, K. Chan, S.
Hahn, A. Smith, and F. Reichmeyer. July 2000.
[POLTERM] Policy Terminology. Internet Draft, draft-ietf-policy-
terminology-01.txt, A. Westerinen, J. Schnizlein, J.
Strassner, M. Scherling, B. Quinn, J. Perry, S. Herzog, A.
Huynh, and M. Carlson. November 2000.
[QOSPIM] Policy Framework QoS Information Model. Internet
Draft, draft-ietf-policy-qos-info-model-01.txt, Y. Snir, Y.
Ramberg, J. Strassner, and R. Cohen. April 2000.
[QOSSCH] QoS Policy Schema. Internet Draft, draft-itef-policy-
qos-schema-01.txt, Y. Snir, Y. Ramberg, J. Strassner, and R.
Cohen. February 2000.
[R791] Postel, J., Editor, "Internet Protocol", STD RFC 791,
September 1981.
Strassner, et al. Expires: Nov 2000 + 6 months [Page 74] Internet Draft QoS Device Info Model November 2000
[R1633] Integrated Services in the Internet Architecture: An
Overview. R. Braden, D. Clark, and S. Shenker. June 1994.
[R1825] Security Architecture for the Internet Protocol. R.
Atkinson. August 1995.
[R2119] Key words for use in RFCs to Indicate Requirement
Levels. S. Bradner. March 1997.
[R2474] Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers. K. Nichols, S. Blake,
F. Baker, and D. Black. December 1998.
[R2475] An Architecture for Differentiated Service. S. Blake,
D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss.
December 1998.
[R2597] Assured Forwarding PHB Group. J. Heinanen, F. Baker, W.
Weiss, and J. Wroclawski. June 1999.
[R2598] An Expedited Forwarding PHB. V. Jacobson, K. Nichols,
and K. Poduri. June 1999.
[RED] See http://www-nrg.ee.lbl.gov/floyd/red.html.
9. Authors' Addresses
John Strassner
Cisco Systems, Bldg 15
170 West Tasman Drive
San Jose, CA 95134
E-mail: johns@cisco.com
Andrea Westerinen
Cisco Systems, Bldg 15
170 West Tasman Drive
San Jose, CA 95134
E-mail: andreaw@cisco.com
Bob Moore
IBM Corporation, BRQA/502
4205 S. Miami Blvd.
Research Triangle Park, NC 27709
E-mail: remoore@us.ibm.com
David Durham
Intel
2111 NE 25th Avenue
Hillsboro, OR 97124
Phone: (503) 264-6232
Email: david.durham@intel.com
Strassner, et al. Expires: Nov 2000 + 6 months [Page 75] Internet Draft QoS Device Info Model November 2000
Walter Weiss
Ellacoya Networks
7 Henry Clay Dr.
Merrimack, NH. 03054
Phone: +1-603-879-7364
E-mail: wweiss@ellacoya.com
10. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to
the Internet Society or other Internet organizations, except as
needed for the purpose of developing Internet standards in which
case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate
it into languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
Strassner, et al. Expires: Nov 2000 + 6 months [Page 76] Internet Draft QoS Device Info Model November 2000
11. Appendix A: Naming Instances in a Native CIM Implementation
Following the precedent established in [PCIM], this document has
placed the details of how to name instances of its classes in a
native CIM implementation here in an appendix. Since Appendix A
in [PCIM] has a lengthy discussion of the general principles of
CIM naming, this appendix does not repeat that information here.
Readers interested in a more global discussion of how instances
are named in a native CIM implementation should refer to [PCIM].
11.1. Naming Instances of the Classes Derived from Service
Most of the classes defined in this model are derived from the
CIM class Service. Even though Service is an abstract class, it
nevertheless has key properties included as part of its
definition. The purpose of including key properties in an
abstract class is to have instances of all of its instantiable
subclasses named in the same way. Thus the majority of this
model's classes name their instances in exactly the same way:
with the two key properties CreationClassName and Name that they
inherit from Service.
11.2. Naming Instances of FilterEntry
Like Service, FilterEntryBase is an abstract class that includes
key properties in its definition. FilterEntryBase has four key
properties. Two of them, SystemCreationClassName and SystemName,
are propagated to it via the weak association
FilterEntryInSystem. The other two, CreationClassName and Name,
are native to FilterEntryBase.
Since FilterEntry is a subclass of FilterEntryBase, its instances
are named with the four key properties it inherits from
FilterEntryBase. Instances of the other subclasses of
FilterEntryBase are named in exactly the same way.
11.3. Naming Instances of FilterList
Instances of the class FilterList are named in exactly the same
way that instances of the subclasses of FilterEntryBase are
named. Because it is defined as being weak to System, FilterList
has propagated to it the two key properties
SystemCreationClassName and SystemName. It also has two key
properties of its own: CreationClassName and Name. Taken
together, these four key properties uniquely identify an instance
of FilterList.
11.4. Naming Instances of ProtocolEndpoint
The class ProtocolEndpoint inherits its key properties from its
superclass, ServiceAccessPoint. These key properties provide the
same naming structure that we've seen before: two propagated key
Strassner, et al. Expires: Nov 2000 + 6 months [Page 77] Internet Draft QoS Device Info Model November 2000
properties SystemCreationClassName and SystemName, plus two
native key properties CreationClassName and Name.
11.5. Naming Instances of BufferPool
Unlike the other classes in this model, BufferPool is not derived
from Service. Consequently, it does not inherit its key
properties from Service. Instead, it inherits one of its key
properties, CollectionID, from its superclass Collection, and
adds its other key property, CreationClassName, in its own
definition.
11.5.1. The Property CollectionID
CollectionID is a string property with a maximum length of 256
characters. It identifies the buffer pool. Note that this
property is defined in the BufferPool class's superclass,
CollectionOfMSEs, but not as a key property. It is overridden in
BufferPool, to make it part of this class's composite key.
11.5.2. The Property CreationClassName
This attribute is a string property of with a maximum length of
256 characters. It is set to "CIM_BufferPool" if this class is
directly instantiated, or to the class name of the BufferPool
subclass that is created.
Strassner, et al. Expires: Nov 2000 + 6 months [Page 78]
Datatracker
Report a datatracker bug
draft-ietf-policy-qos-device-info-model-02
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 3670.
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |