One document matched: draft-ietf-policy-qos-device-info-model-03.txt
Differences from draft-ietf-policy-qos-device-info-model-02.txt
Policy Framework Working Group B Moore
INTERNET-DRAFT IBM Corporation
Category: Standards Track D. Durham
Intel
J. Halpern
Longitude Systems
J. Strassner
INTELLIDEN, Inc.
A. Westerinen
Cisco Systems
W. Weiss
Ellacoya
May 2001
Information Model for Describing Network Device QoS Datapath
Mechanisms
<draft-ietf-policy-qos-device-info-model-03.txt>
Monday, May 07, 2001, 3:43 PM
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 (2001). All Rights Reserved.
Moore, et al. Expires: May 2001 + 6 months [Page 1]
Internet Draft QoS Device Datapath Info Model May 2001
Abstract
The purpose of this draft is to define an information model to
describe the quality of service (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 (datapath) of a
network device. This selection and conditioning of traffic in
the datapath spans both major QoS architectures: Differentiated
Services (see [R2475]) and Integrated Services (see [R1633]).
This draft is intended to be used with the QoS Policy Information
Model [QPIM] 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 present
in the datapaths of devices.
This draft, as well as [QPIM], are information models. That is,
they represent information independent of a binding to a specific
type of repository. A separate draft could 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. Similarly, a draft could be written to
provide a mapping of the data in [QPIM] to a directory.
Together, these four drafts (information models and directory
schema mappings) would 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].
Moore, et al. Expires: May 2001 + 6 months [Page 2]
Internet Draft QoS Device Datapath Info Model May 2001
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.9. Classifiers, FilterLists, and Filter Entries................19
3.10. Modeling of Queues and Schedulers..........................20
4. The Class Hierarchy..............................................20
4.1. Associations and Aggregations...............................20
4.2. The Structure of the Class Hierarchies......................21
4.3. Class Definitions...........................................26
4.3.1. The Abstract Class ManagedElement.........................26
4.3.2. The Abstract Class ManagedSystemElement...................26
4.3.3. The Abstract Class LogicalElement.........................27
4.3.4. The Abstract Class Service................................27
4.3.5. The Class ConditioningService.............................27
4.3.6. The Class ClassifierService...............................28
4.3.7. The Class ClassifierElement...............................29
4.3.8. The Class MeterService....................................29
4.3.9. The Class AverageRateMeter................................30
4.3.10. The Class EWMAMeter......................................31
4.3.11. The Class TokenBucketMeter...............................32
4.3.12. The Class MarkerService..................................33
4.3.13. The Class PreambleMarkerService..........................34
4.3.14. The Class ToSMarkerService...............................35
4.3.15. The Class DSCPMarkerService..............................35
4.3.16. The Class 8021QMarkerService.............................36
4.3.17. The Class DropperService.................................36
4.3.18. The Class HeadTailDropperService.........................38
4.3.19. The Class REDDropperService..............................38
4.3.20. The Class QueuingService.................................40
4.3.21. The Class PacketSchedulingService........................40
4.3.22. The Class NonWorkConservingSchedulingService.............41
4.3.23. The Abstract Class NetworkService........................42
4.3.24. The Class QoSService.....................................42
Moore, et al. Expires: May 2001 + 6 months [Page 3]
Internet Draft QoS Device Datapath Info Model May 2001
4.3.25. The Class DiffServService................................43
4.3.26. The Class AFService......................................43
4.3.27. The Class EFService......................................44
4.3.28. The Class PrecedenceService..............................45
4.3.29. The Class 8021QService...................................46
4.3.30. The Class FlowService....................................47
4.3.31. The Class DropThresholdCalculationService................47
4.3.32. The Abstract Class FilterEntryBase.......................48
4.3.33. The Class IP5TupleFilter.................................48
4.3.34. The Class IPDSCPFilter...................................51
4.3.35. The Class 8021Filter.....................................52
4.3.36. The Class 8021QFilter....................................53
4.3.37. The Class FilterList.....................................54
4.3.38. The Abstract Class ServiceAccessPoint....................55
4.3.39. The Class ProtocolEndpoint...............................55
4.3.40. The Abstract Class Collection............................55
4.3.41. The Abstract Class CollectionOfMSEs......................55
4.3.42. The Class BufferPool.....................................56
4.3.43. The Abstract Class SchedulingElement.....................57
4.3.44. The Class AllocationSchedulingElement....................58
4.3.45. The Class WRRSchedulingElement...........................59
4.3.46. The Class PrioritySchedulingElement......................60
4.3.47. The Class BoundedPrioritySchedulingElement...............61
4.4. Association Definitions.....................................61
4.4.1. The Abstract Association Dependency.......................61
4.4.2. The Association ServiceSAPDependency......................62
4.4.3. The Association IngressConditioningServiceOnEndpoint......62
4.4.4. The Association EgressConditioningServiceOnEndpoint.......63
4.4.5. The Association HeadTailDropQueueBinding..................63
4.4.6. The Association CalculationBasedOnQueue...................64
4.4.7. The Association ProvidesServiceToElement..................64
4.4.8. The Association ServiceServiceDependency..................65
4.4.9. The Association CalculationServiceForDropper..............65
4.4.10. The Association QueueAllocation..........................66
4.4.11. The Association ClassifierElementUsesFilterList..........66
4.4.12. The Association AFRelatedServices........................67
4.4.13. The Association NextService..............................68
4.4.14. The Association NextServiceAfterMeter....................69
4.4.15. The Association NextServiceAfterClassifierElement........70
4.4.16. The Association NextScheduler............................71
4.4.17. The Association FailNextScheduler........................71
4.4.18. The Association QueueToSchedule..........................72
4.4.19. The Association SchedulingServiceToSchedule..............72
4.4.20. The Aggregation MemberOfCollection.......................73
4.4.21. The Aggregation CollectedBufferPool......................73
4.4.22. The Abstract Aggregation Component.......................74
4.4.23. The Aggregation ServiceComponent.........................74
4.4.24. The Aggregation QoSSubService............................74
4.4.25. The Aggregation QoSConditioningSubService................75
4.4.26. The Aggregation ClassifierElementInClassifierService.....76
4.4.27. The Aggregation EntriesInFilterList......................77
4.4.28. The Aggregation ElementInSchedulingService...............78
Moore, et al. Expires: May 2001 + 6 months [Page 4]
Internet Draft QoS Device Datapath Info Model May 2001
5. Intellectual Property............................................78
6. Acknowledgements.................................................79
7. Security Considerations..........................................79
8. References.......................................................79
9. Authors' Addresses...............................................81
10. Full Copyright Statement........................................82
11. Appendix A: Naming Instances in a Native CIM Implementation....83
11.1. Naming Instances of the Classes Derived from Service.......83
11.2. Naming Instances of Subclasses of FilterEntryBase..........83
11.3. Naming Instances of FilterList.............................83
11.4. Naming Instances of ProtocolEndpoint.......................83
11.5. Naming Instances of BufferPool.............................84
11.5.1. The Property CollectionID................................84
11.5.2. The Property CreationClassName...........................84
11.6. Naming Instances of SchedulingElement......................84
1. Introduction
The purpose of this draft is to define an information model to
describe the quality of service (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 (datapath) of a
network device. This selection and conditioning of traffic in
the datapath spans both major QoS architectures: Differentiated
Services (see [R2475]) and Integrated Services (see [R1633]).
This draft is intended to be used with the QoS Policy Information
Model [QPIM] 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 present
in the datapaths of devices.
This draft, as well as [QPIM], are information models. That is,
they represent information independent of a binding to a specific
type of repository. A separate draft could 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. Similarly, a draft could be written to
provide a mapping of the data in [QPIM] to a directory.
Together, these four drafts (information models and directory
schema mappings) would 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 classes
that can be used to model QoS in a device datapath. Vendors can
then map these classes, either directly or using an intervening
format like a COP-PR PIB, to their own device-specific
Moore, et al. Expires: May 2001 + 6 months [Page 5]
Internet Draft QoS Device Datapath Info Model May 2001
implementations. Note that the admission control element of
Integrated Services is not included in the scope of this model.
The design of the class, association, and aggregation 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 [QPIM]).
1.1. Policy Management Conceptual Model
The Policy Core Information Model [PCIM] describes a general
methodology for constructing policy rules. PCIM Extensions
[PCIME] updates and extends the original PCIM. A policy rule
aggregates a set of policy conditions and an ordered 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 [PCIME].
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:
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
Moore, et al. Expires: May 2001 + 6 months [Page 6]
Internet Draft QoS Device Datapath Info Model May 2001
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 [QPIM]) takes the first steps in identifying and
standardizing a set of properties (operands) for use in defining
policies for Differentiated and Integrated 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 [QPIM], 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
is an example of what [POLTERM] characterizes as "policy
translation" or "policy conversion".
Moore, et al. Expires: May 2001 + 6 months [Page 7]
Internet Draft QoS Device Datapath Info Model May 2001
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
modeling the datapath where packet traffic is conditioned.
However, the framework defined by the classes in this document
has been designed with the needs of the admission control portion
of IntServ in mind as well.
2.1. Common Needs Of DiffServ and IntServ
First, let us consider IntServ. IntServ has two principal
components. One component is embedded in the datapath 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 admission
control, which focuses on 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 focuses on the datapath,
elements of RSVP applicable to the datapath 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 traffic conditioning in the datapath.
DiffServ operates exclusively in the datapath. It has all of the
same components of the IntServ datapath, 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.
The second difference between IntServ and DiffServ is that the
signaling protocol used in IntServ (e.g., RSVP) affects the
Moore, et al. Expires: May 2001 + 6 months [Page 8]
Internet Draft QoS Device Datapath Info Model May 2001
configuration of the datapath in a more dynamic fashion. This is
because each newly admitted RSVP reservation requires a
reconfiguration of the datapath. In contrast, DiffServ requires
far fewer changes to the datapath 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.
Moore, et al. Expires: May 2001 + 6 months [Page 9]
Internet Draft QoS Device Datapath Info Model May 2001
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; [QPIM] 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
Moore, et al. Expires: May 2001 + 6 months [Page 10]
Internet Draft QoS Device Datapath Info Model May 2001
get "better" treatment when the network is congested. The goal,
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 (routers, switches, hosts, etc.) 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.
Moore, et al. Expires: May 2001 + 6 months [Page 11]
Internet Draft QoS Device Datapath Info Model May 2001
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 QoS traffic conditioning. 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, describing a higher-level concept
such as "Gold Service". This higher-level service could be
viewed as providing the processing to deliver "Gold" quality of
service.
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.1Q)
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 associations that can represent abstract concepts
Moore, et al. Expires: May 2001 + 6 months [Page 12]
Internet Draft QoS Device Datapath Info Model May 2001
like "Gold Service," and bind each of these abstract services to
a specific set of QoS mechanisms that implement the conditioning
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 [QPIM]) 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 services in the datapath
that support both DiffServ (for aggregate traffic conditioning)
and IntServ (for flow-based traffic conditioning). Classes and
attributes for modeling IntServ admission control services may be
defined in a future draft.
The classes and attributes in this draft are designed to be used
in conjunction with the QoS policy classes and attributes defined
in [QPIM]. 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 [QPIM] 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 [QPIM]) 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 traffic conditioning services realized in the
datapath, the model must support the following characteristics:
o modeling of a generic network service that has QoS
capabilities
o modeling of how the traffic conditioning itself is
defined
Moore, et al. Expires: May 2001 + 6 months [Page 13]
Internet Draft QoS Device Datapath Info Model May 2001
o modeling of how statistics are gathered to monitor QoS
traffic conditioning services - this facet of the model
will be added in a future draft.
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
are used to condition traffic, such that standard as well as
custom traffic conditioning services may be described.
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 operational values of the
attributes in devices configured via the configuration
attributes, as well as attributes that represent state (queue
depths, excess capacity consumption, loss rates, and so forth).
In order to be correlated and used together, these two types of
attributes must be modeled using a common information model. The
possibility of modeling state attributes and their corresponding
configuration settings is accomplished using the same classes in
this model - although individual instances of the classes would
have to be appropriately named or placed in different containers
to distinguish current state values from desired configuration
settings.
State information is addressed in a very limited fashion by
QDDIM. Currently, only CurrentQueueDepth is proposed as an
attribute on QueuingService. The majority of the model is
related to configuration. Given this fact, it is assumed that
this model is a direct memory map into a device. All
manipulation of model classes and attributes directly affects the
state of the device. If it is desired to also use these classes
to represent desired configuration, that is left to the
discretion of the implementor.
It is acknowledged that additional attributes are needed to
completely model current state. However, many of the attributes
defined in this draft represent exactly the state variables that
will be configured by the configuration attributes. Thus, the
definition of the configuration attributes has an exact
Moore, et al. Expires: May 2001 + 6 months [Page 14]
Internet Draft QoS Device Datapath Info Model May 2001
correspondence with the state attributes, and can be used in
modeling both actual (state) and desired/proposed configuration.
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], [PCIME], and [QPIM], 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 draft concentrates on defining an
information model to represent QoS services in a device datapath,
the ultimate goal is to be able to apply policies that control
Moore, et al. Expires: May 2001 + 6 months [Page 15]
Internet Draft QoS Device Datapath Info Model May 2001
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.
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 Informal Management 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 Informal Management Model, the
Moore, et al. Expires: May 2001 + 6 months [Page 16]
Internet Draft QoS Device Datapath Info Model May 2001
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.
This model is built around two fundamental class hierarchies that
are bound together using a set of associations. 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 associations 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.1Q), as well as an association 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 association definitions).
This document, in its current form, identifies four subclasses of
QoSService: DiffServ, 802.1Q, Precedence, and Flow (for
representing microflows). 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.
Moore, et al. Expires: May 2001 + 6 months [Page 17]
Internet Draft QoS Device Datapath Info Model May 2001
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.
/\______
0..1 \/ |
+--------------+ | QoSSubService +---------------+
| |0..n | | |
| QoSService |----- | Conditioning |
| | | Service |
| | | |
| |0..n 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.
Moore, et al. Expires: May 2001 + 6 months [Page 18]
Internet Draft QoS Device Datapath Info Model May 2001
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,
this model ties together the various ConditioningService
instances on an ingress or egress interface using the
NextService, NextServiceAfterMeter, and
NextServiceAfterConditioningElement associations. There are also
separate associations, called
IngressConditioningServiceOnEndpoint and
EgressConditioningServiceOnEndpoint, which, respectively, tie an
ingress interface to its first ConditioningService, and tie an
egress interface to its last ConditioningService(s).
3.9. Classifiers, FilterLists, and Filter Entries
This draft uses a number of classes to model the classifiers
defined in [DSMODEL]: ClassifierService, ClassifierElement,
FilterList, FilterEntryBase, and various subclasses of
FilterEntryBase. There are also two associations involved:
ClassifierElementUsesFilterList and EntriesInFilterList. The
QDDIM model makes no use of CIM's FilterEntry class.
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.
To optimize the representation of MF classifiers, subclasses of
FilterEntryBase are introduced, which allow multiple related
packet header fields to be represented in a single object. These
subclasses are IP5TupleFilter, IPDSCPFilter, 8021Filter, and
8021QFilter. With IP5TupleFilter, for example, a test that
selects packets based on all five of the IP 5-tuple header fields
can be represented by a FilterList containing one IP5TupleFilter
object.
The FilterList object is always needed, even if it contains only
one filter entry (that is, one FilterEntryBase subclass) object.
This is because it is referred to by the
ClassifierElementUsesFilterList association that ties a filter
back to the classifier in which it is used.
Moore, et al. Expires: May 2001 + 6 months [Page 19]
Internet Draft QoS Device Datapath Info Model May 2001
The EntriesInFilterList aggregation has a property EntrySequence,
which in other contexts imposes an evaluation order on the filter
entries 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.
3.10. Modeling of Queues and Schedulers
<<This is a significant new section, with discussion and examples
of the various queue and scheduler classes, associations, and
aggregations, and how they can be combined to model a number of
different queuing configurations.>>
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 and Aggregations
Associations and aggregations are a means of representing
relationships between two (or theoretically more) objects.
Dependency, aggregation, and other relationships are modeled as
classes containing two (or more) object references. It should be
noted that aggregations represent either "whole-part" or
"collection" relationships. For example, aggregation can be used
to represent the containment relationship between a system and
the components that constitute the system.
Since associations and aggregations are classes, they can benefit
from all of the object-oriented features that other non-
relationship classes have. For example, they can contain
properties and methods, and inheritance can be used to refine
their semantics such that they represent more specialized types
of their superclasses.
Note that an association (or an aggregation) object is treated as
an atomic unit (individual instance), even though it
relates/collects/is comprised of multiple objects. This is a
defining feature of an association (or an aggregation) - although
the individual elements that are related to other objects have
their own identities, the association (or aggregation) object
that is constructed using these objects has its own identity and
name as well.
It is important to note that associations and aggregations form
an inheritance hierarchy that is separate from the class
inheritance hierarchy. Although associations and aggregations
Moore, et al. Expires: May 2001 + 6 months [Page 20]
Internet Draft QoS Device Datapath Info Model May 2001
are typically bi-directional, there is nothing that prevents
higher order associations or aggregations from being defined.
However, such associations and aggregations are inherently more
complex to define, understand, and use. In practice,
associations and aggregations of orders higher than binary are
rarely used, because of their greatly increased complexity and
lack of generality. All of the associations and aggregations
defined in this model are binary.
Note also that by definition, associations and aggregations
cannot be unary.
Finally, note that associations and aggregations that are defined
between two classes do not affect the classes themselves. That
is, the addition or deletion of an association or an aggregation
does not affect the interfaces of the classes that it is
connecting.
4.2. The Structure of the Class Hierarchies
The structure of the class, association, and aggregation class
inheritance hierarchies for managing the datapaths of QoS devices
is shown, respectively, in Figure 3, Figure 4, and Figure 5. The
notation (CIMCORE) identifies a class defined in the CIM Core
model. Please refer to [CIM] for the definitions of these
classes. This model has been influenced by [CIM], and is
compatible with the Directory Enabled Networks (DEN) effort.
Moore, et al. Expires: May 2001 + 6 months [Page 21]
Internet Draft QoS Device Datapath Info Model May 2001
+--ManagedElement (CIMCORE)
|
+--ManagedSystemElement (CIMCORE)
| |
| +--LogicalElement (CIMCORE)
| |
| +--Service (CIMCORE)
| | |
| | +--ConditioningService
| | | |
| | | +--ClassifierService
| | | | |
| | | | +--ClassifierElement
| | | |
| | | +--MeterService
| | | | |
| | | | +--AverageRateMeterService
| | | | |
| | | | +--EWMAMeterService
| | | | |
| | | | +--TokenBucketMeterService
| | | |
| | | +--MarkerService
| | | | |
| | | | +--PreambleMarkerService
| | | | |
| | | | +--TOSMarkerService
| | | | |
| | | | +--DSCPMarkerService
| | | | |
| | | | +--8021QMarkerService
| | | |
| | | +--DropperService
| | | | |
| | | | +--HeadTailDropperService
| | | | |
| | | | +--RedDropperService
| | | |
| | | +--QueuingService
| | | |
| | | +--PacketSchedulingService
| | | |
| | | +--NonWorkConservingSchedulingService
| | |
(continued on following page)
Moore, et al. Expires: May 2001 + 6 months [Page 22]
Internet Draft QoS Device Datapath Info Model May 2001
(continued from previous page;
the first four elements are repeated for convenience)
+--ManagedElement (CIMCORE)
|
+--ManagedSystemElement (CIMCORE)
| |
| +--LogicalElement (CIMCORE)
| |
| +--Service (CIMCORE)
| | |
| | +--NetworkService
| | | |
| | | +--QoSService
| | | |
| | | +--DiffServService
| | | | |
| | | | +--AFService
| | | | |
| | | | +--EFService
| | | |
| | | +--PrecedenceService
| | | |
| | | +--8021QService
| | | |
| | | +--FlowService
| | |
| | +--DropThresholdCalculationService
| |
| +--FilterEntryBase
| | |
| | +--IP5TupleFilter
| | | |
| | | +--IPDSCPFilter
| | |
| | +--8021Filter
| | |
| | +--8021QFilter
| |
| +--FilterList
| |
| +--ServiceAccessPoint (CIMCORE)
| |
| +--ProtocolEndpoint
|
(continued on following page)
Moore, et al. Expires: May 2001 + 6 months [Page 23]
Internet Draft QoS Device Datapath Info Model May 2001
(continued from previous page; ManagedElement repeated
for convenience)
+--ManagedElement (CIMCORE)
|
+--Collection (CIMCORE)
| |
| +--CollectionOfMSEs (CIMCORE)
| |
| +--BufferPool
|
+--SchedulingElement
|
+--AllocationSchedulingElement
|
+--WRRSchedulingElement
|
+--PrioritySchedulingElement
|
+--BoundedPrioritySchedulingElement
Figure 3. Class Inheritance Hierarchy
Moore, et al. Expires: May 2001 + 6 months [Page 24]
Internet Draft QoS Device Datapath Info Model May 2001
The inheritance hierarchy for the associations defined in this
draft is shown in Figure 4.
+--Dependency (CIMCORE)
| |
| +--ServiceSAPDependency (CIMCORE)
| | |
| | +--IngressConditioningServiceOnEndpoint
| | |
| | +--EgressConditioningServiceOnEndpoint
| |
| +--HeadTailDropQueueBinding
| |
| +--CalculationBasedOnQueue
| |
| +--ProvidesServiceToElement (CIMCORE)
| | |
| | +--ServiceServiceDependency (CIMCORE)
| | |
| | +--CalculationServiceForDropper
| |
| +--QueueAllocation
| |
| +--ClassifierElementUsesFilterList
|
+--AFRelatedServices
|
+--NextService
| |
| +--NextServiceAfterMeter
| |
| +--NextServiceAfterClassifierElement
| |
| +--NextScheduler
| |
| +--FailNextScheduler
|
+--QueueToSchedule
|
+--SchedulingServiceToSchedule
Figure 4. Association Class Inheritance Hierarchy
Moore, et al. Expires: May 2001 + 6 months [Page 25]
Internet Draft QoS Device Datapath Info Model May 2001
The inheritance hierarchy for the aggregations defined in this
draft is shown in Figure 5.
+--MemberOfCollection (CIMCORE)
| |
| +--CollectedBufferPool
|
+--Component (CIMCORE)
| |
| +--ServiceComponent (CIMCORE)
| | |
| | +--QoSSubService
| | |
| | +--QoSConditioningSubService
| | |
| | +--ClassifierElementInClassifierService
| |
| +--EntriesInFilterList
|
+--ElementInSchedulingService
Figure 5. Aggregation Class Inheritance Hierarchy
4.3. Class Definitions
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 model [CIM]. Only the QoS-
related classes are defined in this draft. However, other
classes drawn from the CIM Core model are described briefly. The
reader is encouraged to look at [CIM] for further information.
Associations and aggregations are defined in Section 4.4.
4.3.1. The Abstract Class ManagedElement
This is an abstract class defined in the Core Model of CIM. It
is the root of the entire class inheritance hierarchy in CIM.
Among the associations that refer to it are two that are
subclassed in this document: Dependency and MemberOfCollection,
which is an aggregation. ManagedElement's properties are Caption
and Description. Both are free-form strings to describe an
instantiated object. Please refer to [CIM] for the full
definition of this class.
4.3.2. The Abstract Class ManagedSystemElement
This is an abstract class defined in the Core Model of CIM; it is
a subclass of ManagedElement. ManagedSystemElement serves as the
base class for the PhysicalElement and LogicalElement class
hierarchies. LogicalElement, in turn, is the base class for a
number of important CIM hierarchies, including System. Any
Moore, et al. Expires: May 2001 + 6 months [Page 26]
Internet Draft QoS Device Datapath Info Model May 2001
distinguishable component of a System is a candidate for
inclusion in this class hierarchy, including physical components
(e.g., chips and cards) and logical components (e.g., software
components, services, and other objects).
None of the associations in which this class participates is used
directly in the QoS device state model. However, the aggregation
Component, which relates one ManagedSystemElement to another, is
the base class for the two aggregations that form the core of the
QoS device state model: QoSSubService and
QoSConditioningSubService. Similarly, the association
ProvidesServiceToElement, which relates a ManagedSystemElement to
a Service, is the base class for the model's
CalculationServiceForDropper association.
Please refer to [CIM] for the full definition of this class.
4.3.3. The Abstract Class LogicalElement
This is an abstract class defined in the Core Model of CIM. It
is a subclass of the ManagedSystemElement class, and is the base
class for all logical components of a managed System, such as
Files, Processes, or system capabilities in the form of Logical
Devices and Services. None of the associations in which this
class participates is relevant to the QoS device state model.
Please refer to [CIM] for the full definition of this class.
4.3.4. The Abstract Class Service
This is an abstract class defined in the Core Model of CIM. It
is a subclass of the LogicalElement class, and is the base class
for all objects that represent a "service" or functionality in a
System. A Service is a general-purpose object that is used to
configure and manage the implementation of functionality. As
noted above in section 4.3.2, this class participates in the
ProvidesServiceToElement association. Please refer to [CIM] for
the full definition of this class.
4.3.5. The Class ConditioningService
This is a concrete subclass of the CIM Core class Service; it
represents the ability to define how traffic is conditioned in
the data-forwarding path of a device. The subclasses of
ConditioningService define the particular types of conditioning
that are done. Six fundamental types of conditioning are defined
in this 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
documents.
ConditioningService is a concrete class because of considerations
related to CIM naming. While this class can be instantiated, an
Moore, et al. Expires: May 2001 + 6 months [Page 27]
Internet Draft QoS Device Datapath Info Model May 2001
instance of it would not accomplish anything, because the nature
of the conditioning, and the parameters that control it, are
specified only in the subclasses of ConditioningService.
Two associations in which ConditioningService participates are
critical to its usage in QoS - QoSConditioningSubService and
NextService. QoSConditioningSubService aggregates
ConditioningServices into a particular QoS service (such as AF),
to describe the specific conditioning functionality that
underlies that QoS service in a particular device. NextService
indicates the subsequent conditioning service(s) for different
traffic streams.
The class definition is as follows:
NAME ConditioningService
DESCRIPTION A concrete class to define how traffic
is conditioned in the data forwarding
path of a host or network device.
DERIVED FROM Service
TYPE Concrete
PROPERTIES (none)
4.3.6. The Class ClassifierService
The concept of a Classifier comes from [DSMODEL].
ClassifierService is a concrete class that represents a logical
entity in an ingress or egress interface of a device, that takes
a single input stream, and sorts it into one or more output
streams. The sorting is done by a set of filters that select
packets based on the packet contents, or possibly based on other
attributes associated with the packet. Each output stream is the
result of matching a particular filter.
The representation of classifiers in QDDIM is closely related to
that presented in [DSMIB] and [DSMODEL]. Rather than being
linked directly to its FilterLists, a classifier is modeled here
as an aggregation of ClassifierElements. Each of these
ClassifierElements is then linked to a single FilterList, by the
association ClassifierElementUsesFilterList.
A Classifier is modeled as a 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
Moore, et al. Expires: May 2001 + 6 months [Page 28]
Internet Draft QoS Device Datapath Info Model May 2001
output streams using one or more
filters.
DERIVED FROM ConditioningService
TYPE Concrete
PROPERTIES (none)
4.3.7. The Class ClassifierElement
The concept of a ClassifierElement comes from [DSMIB]. This
concrete class represents the linkage, within a single
ClassifierService, between a FilterList that 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. 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 (none)
4.3.8. The Class MeterService
This is a concrete class that represents the metering of network
traffic. Metering is the function of monitoring the arrival
times of packets of a traffic stream, and determining the level
of conformance of each packet with respect to a pre-established
traffic profile. A meter has the ability to invoke different
ConditioningServices for conforming and non-conforming traffic.
Traffic leaving a meter may be further conditioned (e.g., dropped
or queued) by routing the packet to another conditioning element.
Please see [DSMODEL] for more information on metering.
This class is the base class for defining different types of
meters. As such, it contains common properties that all meter
subclasses share. It is modeled as a ConditioningService so that
it can be aggregated into a QoSService (using the
QoSConditioningSubService association), to indicate that its
functionality underlies that QoS service. MeterService also
participates in a subclass of the NextService association, to
identify the subsequent ConditioningServices for conforming and
non-conforming traffic.
Moore, et al. Expires: May 2001 + 6 months [Page 29]
Internet Draft QoS Device Datapath Info Model May 2001
The class definition is as follows:
NAME MeterService
DESCRIPTION A concrete class describing the
monitoring of traffic with respect to a
pre-established traffic profile.
DERIVED FROM ConditioningService
TYPE Concrete
PROPERTIES MeterType, OtherMeterType,
ConformanceLevels
Note: The MeterType property and the MeterService subclasses
provide similar information. The MeterType property is defined
for query purposes and for future expansion. It is possible that
not all MeterServices will require a subclass to define them. In
these cases, MeterService will be instantiated directly, and the
MeterType property will provide the only way of identifying the
type of the meter.
4.3.8.1 The Property MeterType
This 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.3.8.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.3.8.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.
4.3.9. The Class AverageRateMeter
This is a concrete subclass of MeterService that represents a
simple meter, called an Average Rate Meter. This type of meter
measures the average rate at which packets are submitted to it
over a specified time. Packets are defined as conformant if
their average arrival rate does not exceed the specified
measuring rate of the meter. Any packet that causes the
Moore, et al. Expires: May 2001 + 6 months [Page 30]
Internet Draft QoS Device Datapath Info Model May 2001
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.3.9.1 The Property AverageRate
This is an unsigned 32-bit integer that defines the rate used to
determine whether admitted packets are in conformance or not.
The value is specified in kilobits per second.
4.3.9.2 The Property DeltaInterval
This is an unsigned 64-bit integer that defines the time period
over which the average measurement should be taken. The value is
specified in microseconds.
4.3.10. The Class EWMAMeter
This is a concrete subclass of the MeterService class that
represents an exponentially weighted moving average meter. This
meter is a simple low-pass filter that measures the rate of
incoming packets over a small, fixed sampling interval. Any
admitted packet that pushes the average rate over a pre-defined
limit is defined to be non-conforming. Please see [DSMODEL] for
more information.
The class definition is as follows:
NAME 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
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
Moore, et al. Expires: May 2001 + 6 months [Page 31]
Internet Draft QoS Device Datapath Info Model May 2001
4.3.10.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.3.10.2 The Property DeltaInterval
This attribute is an unsigned 64-bit integer that defines the
sampling interval used to measure the arrival rate. The
calculated rate is averaged over this interval and checked
against the AverageRate attribute. All packets whose computed
average arrival rate is less than the AverageRate are deemed
conforming.
The value is specified in microseconds.
4.3.10.3 The Property Gain
This 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.3.11. The Class TokenBucketMeter
This is a concrete subclass of the MeterService class that
represents the metering of network traffic using a token bucket
meter. Two types of token bucket meters are defined using this
class - a simple, two-parameter bucket meter, and a multi-stage
meter.
A simple token bucket usually has two parameters, an average
token rate and a burst size, and has two conformance levels:
"conforming" and "non-conforming". This class also defines an
excess burst size, which enables the meter to have three
conformance levels ("conforming", "partially conforming", and
"non-conforming"). In this case, packets that exceed the excess
burst size are deemed non-conforming, while packets that exceed
the smaller burst size but are less than the excess burst size
are deemed partially conforming. Operation of these meters is
described in [DSMODEL].
The class definition is as follows:
NAME TokenBucketMeter
DESCRIPTION A concrete class classifying admitted
traffic with respect to a token bucket.
Either two or three levels of
Moore, et al. Expires: May 2001 + 6 months [Page 32]
Internet Draft QoS Device Datapath Info Model May 2001
conformance can be defined.
DERIVED FROM MeterService
TYPE Concrete
PROPERTIES AverageRate, PeakRate,
BurstSize, ExcessBurstSize
4.3.11.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.3.11.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.3.11.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.3.11.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.3.12. The Class MarkerService
This is a concrete class that represents the general process of
marking some field in a network packet with some value.
Subclasses of MarkerService identify particular fields to be
marked, and introduce properties to represent the values to be
used in marking these fields. Markers are usually invoked as a
result of a preceding classifier match. Operation of markers of
various types is described in [DSMODEL].
MarkerService is a concrete class because 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.
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
Moore, et al. Expires: May 2001 + 6 months [Page 33]
Internet Draft QoS Device Datapath Info Model May 2001
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 (none)
4.3.13. The Class PreambleMarkerService
This is a concrete class that models the storing of information
into a virtual header, or preamble, as a packet makes its way
through a device. <<This class is still very much under
discussion among the authors. The goal, or at least one of the
goals, of the class is to model the "leakage" of information as a
packet moves from an ingress datapath, across the routing core,
and onto an egress datapath. So, for example, we might want to
have a Classifier on an egress datapath that splits a stream of
packets based on which packets were in profile and which ones
were out of profile when they were metered on their respective
ingress datapaths. For this Classifier to work, there has to be
something for it to filter on, indicating whether a given packet
was found to be in or out of profile. The role of this class
would be to write that indication into the packet preamble, where
a subsequent Classifier could find it.
Among the concerns that some of the authors have expressed with
this class are the fact that it does not correspond to anything
in [DSMODEL] / [DSMIB], and the fact that it has the potential to
greatly increase the number of class and association instances
needed to model a datapath.>>.
The class definition is as follows:
NAME PreambleMarkerService
DESCRIPTION A concrete class representing the saving
of information in a packet preamble.
DERIVED FROM MarkerService
TYPE Concrete
PROPERTIES LabelValue
Moore, et al. Expires: May 2001 + 6 months [Page 34]
Internet Draft QoS Device Datapath Info Model May 2001
4.3.13.1 The Property LabelValue
This property is a string representing the information to be
added to the preamble of a packet. <<Still TBD how much to
describe here -- format of the label, how new information is
appended to a preamble, etc.>>
4.3.14. The Class ToSMarkerService
This is a concrete class that represents the marking of the ToS
field in the IPv4 packet header [R791]. Following common
practice, the value to be written into the field is represented
as an unsigned 8-bit integer.
The class definition is as follows:
NAME ToSMarkerService
DESCRIPTION A concrete class representing the
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.3.14.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.
4.3.15. The Class DSCPMarkerService
This is a concrete class that 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
Moore, et al. Expires: May 2001 + 6 months [Page 35]
Internet Draft QoS Device Datapath Info Model May 2001
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.3.15.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.3.16. The Class 8021QMarkerService
This is a concrete class that represents the marking of the user
priority field defined in the IEEE 802.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 8021QMarkerService
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
4.3.16.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.3.17. The Class DropperService
This is a concrete class that represents the ability to
selectively drop network traffic, or to invoke another
Moore, et al. Expires: May 2001 + 6 months [Page 36]
Internet Draft QoS Device Datapath Info Model May 2001
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.3.17.1 The Property DropperType
This is an enumerated 16-bit unsigned integer that defines the
type of dropper. Values include:
1 - Other
2 - Head
3 - Tail
4 - RED
5 - Weighted RED
6 - Absolute Dropper
4.3.17.2 The Property OtherDropperType
This string property is used in conjunction with the DropperType
property. When the value of DropperType is '1' (i.e., Other),
then the name of the type of dropper appears in this property.
Moore, et al. Expires: May 2001 + 6 months [Page 37]
Internet Draft QoS Device Datapath Info Model May 2001
4.3.18. The Class HeadTailDropperService
This is a concrete class that represents the threshold
information of a head or tail dropper. The inherited property
DropperType indicates whether a particular instance of this class
represents a head dropper or a 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.3.18.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.3.19. The Class REDDropperService
This is a concrete class that represents 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:
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,
ThresholdUnits, StartProbability,
StopProbability, DropFrom
Moore, et al. Expires: May 2001 + 6 months [Page 38]
Internet Draft QoS Device Datapath Info Model May 2001
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.3.19.1 The Property MinQueueThreshold
This is an unsigned 32-bit integer that defines the minimum
average queue depth at which packets are subject to being
dropped. The units are identified by the ThresholdUnits
property. The slope of the drop probability function is
described by the Start/StopProbability properties.
4.3.19.2 The Property MaxQueueThreshold
This is an unsigned 32-bit integer that defines the maximum
average queue length at which packets are subject to always being
dropped, regardless of the dropping algorithm and probabilities
being used. The units are identified by the ThresholdUnits
property.
4.3.19.3 The Property ThresholdUnits
This is an unsigned 16-bit integer enumeration that identifies
the units for the MinQueueThreshold and MaxQueueThreshold
properties. Defined enumeration values are
o bytes(1)
o packets(2)
4.3.19.4 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.3.19.5 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.
Moore, et al. Expires: May 2001 + 6 months [Page 39]
Internet Draft QoS Device Datapath Info Model May 2001
Min and max values are 0 to 100.
4.3.19.6 The Property DropFrom
This is an unsigned 16-bit integer enumeration that indicates the
point in the associated queue from which packets should be
dropped. Defined enumeration values are
o head(1)
o tail(2)
o middle(3)
o random(4)
4.3.20. The Class QueuingService
This is a concrete class that 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 CurrentQueueDepth
4.3.20.1 The Property CurrentQueueDepth
This is an unsigned 32-bit integer, which functions as a gauge
representing the current depth of this one queue. This value may
be important in diagnosing unexpected behavior by a
DropThresholdCalculationService.
4.3.21. The Class PacketSchedulingService
This is a concrete class that 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
Moore, et al. Expires: May 2001 + 6 months [Page 40]
Internet Draft QoS Device Datapath Info Model May 2001
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.
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
4.3.21.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 - Allocation
5 - Bounded Priority
6 - Weighted Round Robin Packet
4.3.21.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.3.22. The Class NonWorkConservingSchedulingService
This class does not add any properties beyond those it inherits
from its superclass, PacketSchedulingService. It does, however,
participate in one additional association, FailNextScheduler.
The class definition is as follows:
NAME NonWorkConservingSchedulingService
Moore, et al. Expires: May 2001 + 6 months [Page 41]
Internet Draft QoS Device Datapath Info Model May 2001
DESCRIPTION A concrete class representing a
scheduler that is capable of operating
in a non-work conserving manner.
DERIVED FROM PacketSchedulingService
TYPE Concrete
PROPERTIES (none)
4.3.23. The Abstract Class NetworkService
This is an abstract subclass of the Service class, and serves as
the base class rooting the network service hierarchy. Network
services 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 QDDIM. Please refer to [CIM] for the full definition of this
class.
4.3.24. The Class QoSService
This is a concrete class that represents the ability to
conceptualize a QoS service as a set of coordinated sub-services.
This enables the network administrator 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 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
Moore, et al. Expires: May 2001 + 6 months [Page 42]
Internet Draft QoS Device Datapath Info Model May 2001
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 (none)
4.3.25. The Class DiffServService
This is a concrete class representing the use of 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.,
metering, dropping, queuing, and others) via
QoSConditioningSubService.
The class definition is as follows:
NAME DiffServService
DESCRIPTION A concrete class used to represent a
DiffServ service associated with a
particular Per Hop Behavior.
DERIVED FROM QoSService
TYPE Concrete
PROPERTIES PHBID
4.3.25.1 The Property PHBID
This property is a 16-bit unsigned integer, which identifies a
particular Differentiated Services Per Hop Behavior (PHB).
4.3.26. The Class AFService
This is a concrete class that 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
Moore, et al. Expires: May 2001 + 6 months [Page 43]
Internet Draft QoS Device Datapath Info Model May 2001
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
TYPE Concrete
PROPERTIES ClassNumber, DropperNumber
4.3.26.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.3.26.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.3.27. The Class EFService
This is a concrete class that 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]).
Moore, et al. Expires: May 2001 + 6 months [Page 44]
Internet Draft QoS Device Datapath Info Model May 2001
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., 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.
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 (none)
4.3.28. The Class PrecedenceService
This is a concrete class that 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., metering, dropping,
queuing, and others), using the QoSConditioningSubService
association.
The class definition is as follows:
NAME PrecedenceService
DESCRIPTION A concrete class for describing the
common characteristics of forwarding
Moore, et al. Expires: May 2001 + 6 months [Page 45]
Internet Draft QoS Device Datapath Info Model May 2001
traffic based on the value of the
ToS byte.
DERIVED FROM DiffServService
TYPE Concrete
PROPERTIES PrecedenceValue
4.3.28.1 The Property PrecedenceValue
This property 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 property,
as well as on its backward compatibility with the ToS byte of
IPv4.
4.3.29. The Class 8021QService
This is a concrete class that 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 802.1Q
specification [IEEE802Q].
This class is used to enable DiffServ devices and domains that
support 802.1Q, to exchange traffic. It allows implementations
that only support 802.1Q priority marking to be mapped to
implementations that support DiffServ, which uses DSCPs.
Since the 8021QService 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., metering, dropping, queuing, and
others), using the QoSConditioingSubService association.
The class definition is as follows:
NAME 8021QService
DESCRIPTION A concrete class for describing the
common characteristics of forwarding
traffic based on the value of the
Priority field in the 802.1Q header.
DERIVED FROM QoSService
TYPE Concrete
PROPERTIES PriorityValue
4.3.29.1 The Property PriorityValue
This attribute is an 8-bit unsigned integer that represents a
priority value, as specified in the 802.1Q standards. Since the
802.1Q Priority field consists of 3 bits, the values for this
property are limited to the range 0..7.
Moore, et al. Expires: May 2001 + 6 months [Page 46]
Internet Draft QoS Device Datapath Info Model May 2001
4.3.30. The Class FlowService
This class represents a service that supports a particular
microflow. The microflow is identified by the string-valued
property FlowID. In some implementations, an instance of this
class corresponds to an entry in the implementation's flow table.
The class definition is as follows:
NAME FlowService
DESCRIPTION A concrete class for <<more text>>.
DERIVED FROM QoSService
TYPE Concrete
PROPERTIES FlowID
4.3.30.1 The Property FlowID
This property is a string <<we should specify a maximum length>>
containing an identifier for a microflow.
4.3.31. 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
4.3.31.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
Moore, et al. Expires: May 2001 + 6 months [Page 47]
Internet Draft QoS Device Datapath Info Model May 2001
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.3.31.2 The Property TimeInterval
This property is a 32-bit unsigned integer, defining the number
of nanoseconds between each calculation of average/smoothed queue
depth. If this property is not specified, the CalculationService
may determine an appropriate interval.
4.3.32. The Abstract Class FilterEntryBase
FilterEntryBase is the abstract base class from which all filter
entry classes are derived. It serves as the endpoint for the
EntriesInFilterList aggregation, which groups filter entries into
filter lists. Its properties include CIM naming attributes and
an IsNegated boolean property (to easily "NOT" the match
information specified in an instance of one of its subclasses).
The class definition is as follows:
NAME FilterEntryBase
DESCRIPTION An abstract class representing a single
filter that is aggregated into a
FilterList via the aggregation
EntriesInFilterList.
DERIVED FROM LogicalElement
TYPE Abstract
PROPERTIES IsNegated
4.3.33. The Class IP5TupleFilter
NOTE: Since the goal of this class is to provide a single
representation for device-level filtering on IP packet header
fields, across all Policy disciplines, this class will be moved
from QDDIM to PCIMe before either of the documents is submitted
for advancement.
This concrete class makes it possible to represent an entire IP
5-tuple filter in a single object. A property IpVersion
Moore, et al. Expires: May 2001 + 6 months [Page 48]
Internet Draft QoS Device Datapath Info Model May 2001
identifies whether the IP addresses in an instance are IPv4 or
IPv6 addresses. (Since the source and destination IP addresses
come from the same packet header, they will always be of the same
type.) A subclass introduces a sixth field, DSCP, on which to
filter.
The class definition is as follows:
NAME IP5TupleFilter
DESCRIPTION A class representing an entire IP
5-tuple filter, or any subset of one.
DERIVED FROM FilterEntryBase
TYPE Concrete
PROPERTIES IpVersion, SrcAddress, SrcMask,
DestAddress, DestMask, ProtocolID,
SrcPortStart, SrcPortEnd,
DestPortStart, DestPortEnd
4.3.33.1 The Property IpVersion
This property is an 8-bit unsigned integer enumeration,
identifying the version of the IP addresses to be filtered on.
Defined enumeration values are
o unknown(0)
o ipv4(1)
o ipv6(2)
The value of this property determines the sizes of the
OctetStrings in the four properties SrcAddress, SrcMask,
DestAddress, and DestMask, as follows:
o ipv4(1): OctetString(SIZE (4))
o ipv6(2): OctetString(SIZE (16|20)), depending on whether a
scope identifier is present
4.3.33.2 The Property SrcAddress
This property is an OctetString, of a size determined by the
value of the IpVersion property, representing a source IP
address. This value is compared to the source address in the IP
header, subject to the mask represented in the SrcMask property.
4.3.33.3 The Property SrcMask
This property is an OctetString, of a size determined by the
value of the IpVersion property, representing a mask to be used
in comparing the source address in the IP header with the value
represented in the SrcAddress property.
Moore, et al. Expires: May 2001 + 6 months [Page 49]
Internet Draft QoS Device Datapath Info Model May 2001
4.3.33.4 The Property DestAddress
This property is an OctetString, of a size determined by the
value of the IpVersion property, representing a destination IP
address. This value is compared to the destination address in
the IP header, subject to the mask represented in the DestMask
property.
4.3.33.5 The Property DestMask
This property is an OctetString, of a size determined by the
value of the IpVersion property, representing a mask to be used
in comparing the destination address in the IP header with the
value represented in the DestAddress property.
4.3.33.6 The Property ProtocolID
This property is an 8-bit unsigned integer, representing an IP
protocol type. This value is compared to the Protocol field in
the IP header.
4.3.33.7 The Property SrcPortStart
This property is a 16-bit unsigned integer, representing the
lower end of a range of UDP or TCP source ports. The upper end
of the range is represented by the SrcPortEnd property. The
value of SrcPortStart MUST be no greater than the value of
SrcPortEnd. A single port is indicated by equal values for
SrcPortStart and SrcPortEnd.
A source port filter is evaluated by testing whether the source
port identified in the IP header falls within the range of values
between SrcPortStart and SrcPortEnd, including these two end
points.
4.3.33.8 The Property SrcPortEnd
This property is a 16-bit unsigned integer, representing the
upper end of a range of UDP or TCP source ports. The lower end
of the range is represented by the SrcPortStart property. The
value of SrcPortEnd MUST be no less than the value of
SrcPortStart. A single port is indicated by equal values for
SrcPortStart and SrcPortEnd.
A source port filter is evaluated by testing whether the source
port identified in the IP header falls within the range of values
between SrcPortStart and SrcPortEnd, including these two end
points.
Moore, et al. Expires: May 2001 + 6 months [Page 50]
Internet Draft QoS Device Datapath Info Model May 2001
4.3.33.9 The Property DestPortStart
This property is a 16-bit unsigned integer, representing the
lower end of a range of UDP or TCP destination ports. The upper
end of the range is represented by the DestPortEnd property. The
value of DestPortStart MUST be no greater than the value of
DestPortEnd. A single port is indicated by equal values for
DestPortStart and DestPortEnd.
A destination port filter is evaluated by testing whether the
destination port identified in the IP header falls within the
range of values between DestPortStart and DestPortEnd, including
these two end points.
4.3.33.10 The Property DestPortEnd
This property is a 16-bit unsigned integer, representing the
upper end of a range of UDP or TCP destination ports. The lower
end of the range is represented by the DestPortStart property.
The value of DestPortEnd MUST be no less than the value of
DestPortStart. A single port is indicated by equal values for
DestPortStart and DestPortEnd.
A destination port filter is evaluated by testing whether the
destination port identified in the IP header falls within the
range of values between DestPortStart and DestPortEnd, including
these two end points.
4.3.34. The Class IPDSCPFilter
NOTE: Since the goal of this class is to provide a single
representation for device-level filtering on this IP packet
header field, across all Policy disciplines, this class will be
moved from QDDIM to PCIMe before either of the documents is
submitted for advancement.
This concrete class extends the IP5TupleFilter class, to add the
Differentiated Services Code Point (DSCP) as an additional field
on which to filter. Instances of this class can thus represent
filters that filter on any or all of six fields in an IPv4 or
IPv6 header. Filters that involve other IPv4 or IPv6 header
fields, but not the DSCP, SHOULD be expressed using the
IP5TupleFilter class, rather than this class.
The class definition is as follows:
NAME IPDSCPFilter
DESCRIPTION A subclass of IP5TupleFilter that
adds the DSCP as a sixth field on
which to filter.
DERIVED FROM IPDSCPFilter
TYPE Concrete
Moore, et al. Expires: May 2001 + 6 months [Page 51]
Internet Draft QoS Device Datapath Info Model May 2001
PROPERTIES DSCP
4.3.34.1 The Property DSCP
The property DSCP is defined as a uint8, restricted to the range
0..63. Since DSCPs are defined as discrete code points, with no
inherent structure, there is no semantically significant
relationship between different DSCPs. Consequently, there is no
provision for specifying a range of DSCPs in this property.
4.3.35. The Class 8021Filter
NOTE: Since the goal of this class is to provide a single
representation for device-level filtering on these layer 2 header
fields, across all Policy disciplines, this class will be moved
from QDDIM to PCIMe before either of the documents is submitted
for advancement.
This concrete class 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 A class that allows 802.1 source
and destination MAC address and
protocol ID filters to be
expressed in a single object.
DERIVED FROM FilterEntryBase
TYPE Concrete
PROPERTIES SrcMACAddr, SrcMACMask, DestMACAddr,
DestMACMask, ProtocolID
4.3.35.1 The Property SrcMACAddr
This property is an OctetString of size 6, representing a 48-bit
source MAC address in canonical format. This value is compared
to the SourceAddress field in the MAC header, subject to the mask
represented in the SrcMACMask property.
4.3.35.2 The Property SrcMACMask
This property is an OctetString of size 6, representing a 48-bit
mask to be used in comparing the SourceAddress field in the MAC
header with the value represented in the SrcMACAddr property.
4.3.35.3 The Property DestMACAddr
This property is an OctetString of size 6, representing a 48-bit
destination MAC address in canonical format. This value is
Moore, et al. Expires: May 2001 + 6 months [Page 52]
Internet Draft QoS Device Datapath Info Model May 2001
compared to the DestinationAddress field in the MAC header,
subject to the mask represented in the DestMACMask property.
4.3.35.4 The Property DestMACMask
This property is an OctetString of size 6, representing a 48-bit
mask to be used in comparing the DestinationAddress field in the
MAC header with the value represented in the DestMACAddr
property.
4.3.35.5 The Property ProtocolID
This property is a 16-bit unsigned integer, representing an
Ethernet protocol type. This value is compared to the Ethernet
Type field in the 802.3 MAC header.
4.3.36. The Class 8021QFilter
NOTE: Since the goal of this class is to provide a single
representation for device-level filtering on these layer 2 header
fields, across all Policy disciplines, this class will be moved
from QDDIM to PCIMe before either of the documents is submitted
for advancement.
This concrete class extends 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:
NAME 8021QFilter
DESCRIPTION An extension to 8021Filter, which
adds 802.1 priority and VLAN identifier
fields.
DERIVED FROM 8021Filter
TYPE Concrete
PROPERTIES PriorityValue, VLANID
4.3.36.1 The Property PriorityValue
This property is an 8-bit unsigned integer, representing an
802.1Q priority. This value is compared to the Priority field in
the 802.1Q header. Since the 802.1Q Priority field consists of 3
bits, the values for this property are limited to the range 0..7.
4.3.36.2 The Property VLANID
This property is a 32-bit unsigned integer, representing an
802.1Q VLAN Identifier. This value is compared to the VLAN ID
field in the 802.1Q header. Since the 802.1Q VLAN ID field
consists of 12 bits, the values for this property are limited to
the range 0..4095.
Moore, et al. Expires: May 2001 + 6 months [Page 53]
Internet Draft QoS Device Datapath Info Model May 2001
4.3.37. The Class FilterList
This is a concrete class that 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, packet header filters (represented by
the IP5TupleFilter class) and security filters (represented by
subclasses of FilterEntryBase defined by IPsec).
The aggregation property EntriesInFilterList.EntrySequence serves
to order the filter entries in a FilterList. This is necessary
when algorithms such as "Match First" are used to identify
traffic based on an aggregated set of FilterEntries. In modeling
QoS classifiers, however, this property is always set to 0, to
indicate that the aggregated filter entries are ANDed together to
form a selector for a class of traffic.
The class definition is as follows:
NAME FilterList
DESCRIPTION A concrete class representing
the aggregation of multiple filters.
In the IETF QoS model, this aggregation
always involves ANDing together of the
aggregated filters.
DERIVED FROM LogicalElement
TYPE Concrete
PROPERTIES Direction
4.3.37.1 The Property Direction
This property is an 8-bit unsigned integer enumeration,
representing the direction of the traffic flow to which the
FilterList is to be applied. Defined enumeration values are
o NotApplicable(0)
o Input(1)
o Output(2)
o Both(3) - This value is used to indicate that the direction
is immaterial, e.g., to filter on a source subnet regardless
of whether the flow is inbound or outbound
o Mirrored(4) - This value is also applicable to both inbound
and outbound flow processing, but it indicates that the
filter criteria are applied asymmetrically to traffic in
both directions and, thus, specifies the reversal of source
and destination criteria (as opposed to the equality of
these criteria as indicated by "Both"). The match
conditions in the aggregated FilterEntryBase subclass
instances are defined from the perspective of outbound flows
and applied to inbound flows as well by reversing the source
and destination criteria. So, for example, consider a
FilterList with 3 filter entries indicating destination port
Moore, et al. Expires: May 2001 + 6 months [Page 54]
Internet Draft QoS Device Datapath Info Model May 2001
= 80, and source and destination addresses of a and b,
respectively. Then, for the outbound direction, the filter
entries match as specified and the 'mirror' (for the inbound
direction) matches on source port = 80 and source and
destination addresses of b and a, respectively.
4.3.38. 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.3.39. The Class ProtocolEndpoint
This is a concrete class derived from ServiceAccessPoint, which
describes a communication point from which the services of the
network or the system's protocol stack may be accessed.
The class definition is as follows:
NAME ProtocolEndpoint
DESCRIPTION A communication point from which
data may be sent or received.
DERIVED FROM ServiceAccessPoint
TYPE Concrete
PROPERTIES Name, NameFormat, ProtocolType,
OtherTypeDescription
<<For QDDIM, how do we want ProtocolType to be used? For
example, what's the ProtocolType for an ingress interface where
we want to filter both on 802 header fields and IP header fields?
This needs more work.>>
4.3.40. 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
more correctly modeled as ManagedSystemElements.) Please refer
to [CIM] for the full definition of this class.
4.3.41. 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.
Moore, et al. Expires: May 2001 + 6 months [Page 55]
Internet Draft QoS Device Datapath Info Model May 2001
4.3.42. The Class BufferPool
This is a concrete class that represents the collection of
buffers used by a QueuingService. (The association
QueueAllocation represents this usage.) The existence and
management of individual buffers may be modeled in a future
document. 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.3.42.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.3.42.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
to manage. This model does not specify the degree to which
buffers in the same buffer pool may differ in size.
4.3.42.3 The Property TotalBuffers
This attribute is a 32-bit unsigned integer, reporting the total
number of individual buffers in the pool.
Moore, et al. Expires: May 2001 + 6 months [Page 56]
Internet Draft QoS Device Datapath Info Model May 2001
4.3.42.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.3.42.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.3.43. The Abstract Class SchedulingElement
This is an abstract class that represents the configuration
information that a PacketSchedulingService has for one of the
elements that it is scheduling. The scheduled element is either
a QueuingService or another PacketSchedulingService.
Among the subclasses of this class, some are defined in such a
way that all of their instances are work conserving. Other
subclasses, however, may have instances that either are or are
not work conserving. In this class, the boolean property
WorkConserving indicates whether an instance is or is not work
conserving. The range of values for WorkConserving is restricted
to TRUE in the subclasses that are inherently work conserving,
since instances of these classes cannot be anything other than
work conserving.
The class definition is as follows:
NAME SchedulingElement
DESCRIPTION An abstract class representing the
configuration information that a
PacketSchedulingService has for one of
the elements that it is scheduling.
DERIVED FROM ManagedElement
TYPE Abstract
PROPERTIES WorkConserving
4.3.43.1 The Property WorkConserving
This boolean attribute indicates whether the
PacketSchedulingService tied to this instance by the
ElementInSchedulingService aggregation is treating the input tied
to this instance by the QueueToSchedule or
SchedulingServiceToSchedule association in a work-conserving
manner.
Moore, et al. Expires: May 2001 + 6 months [Page 57]
Internet Draft QoS Device Datapath Info Model May 2001
4.3.44. The Class AllocationSchedulingElement
This class is a subclass of the abstract class SchedulingElement.
It introduces five new properties, that <<fill in text here>>.
As is the case with all subclasses of SchedulingElement, the
input associated with an instance of AllocationSchedulingElement
is of one of two types: either a queue, or another scheduler.
The class definition is as follows:
NAME AllocationSchedulingElement
DESCRIPTION A concrete class representing <<fill
in>>.
DERIVED FROM SchedulingElement
TYPE Concrete
PROPERTIES AllocationUnits, BandwidthAllocation,
BurstAllocation, CanShare,
WorkFlexible
4.3.44.1 The Property AllocationUnits
This property is a 16-bit unsigned integer enumeration that
identifies the units in which the BandwidthAllocation and
BurstAllocation properties are expressed. The following values
are defined:
o bytes(1)
o packets(2)
o cells(3) -- fixed-size, for example, ATM
4.3.44.2 The Property BandwidthAllocation
This property is a 32-bit unsigned integer that defines the
number of units/second that should be allocated to the associated
input. The units are identified by the AllocationUnits property.
4.3.44.3 The Property BurstAllocation
This property is a 32-bit unsigned integer that specifies the
amount of temporary or short-term bandwidth (in units per second)
that can be allocated to an input, beyond the amount of bandwidth
allocated through the BandwidthAllocation property. If the
maximum actual bandwidth allocation for the input were to be
measured, it would be the sum of the BurstAllocation and the
BandwidthAllocation properties. The units are identified by the
AllocationUnits property.
Moore, et al. Expires: May 2001 + 6 months [Page 58]
Internet Draft QoS Device Datapath Info Model May 2001
4.3.44.4 The Property CanShare
This is a boolean property that, if TRUE, enables unused
bandwidth from the associated input to be allocated to other
inputs serviced by the Scheduler.
4.3.44.5 The Property WorkFlexible
This is a boolean property that, if TRUE, indicates that the
behavior of the scheduler relative to this input can be altered
by changing the value of the inherited property WorkConserving.
4.3.45. The Class WRRSchedulingElement
This class is a subclass of the abstract class SchedulingElement.
It introduces a new property WeightingFactor, to give some inputs
a higher probability of being serviced than other inputs. It
also introduces a property Priority, to serve as a tiebreaker to
be used when inputs have equal weighting factors. As is the case
with all subclasses of SchedulingElement, the input associated
with an instance of WRRSchedulingElement is of one of two types:
either a queue, or another scheduler.
Because scheduling of this type is always work conserving, the
inherited boolean property WorkConserving is restricted to the
value TRUE in this class.
The class definition is as follows:
NAME WRRSchedulingElement
DESCRIPTION This class specializes the
SchedulingElement class to add
a per-input weight. This is used
by a weighted round robin packet
scheduler when it handles its
associated inputs. It also adds a
second property to serve as a tie-breaker
in the case where multiple inputs have
been assigned the same weight.
DERIVED FROM SchedulingElement
TYPE Concrete
PROPERTIES WeightingFactor, Priority
4.4.44.1 The Property WeightingFactor
This property is a 32-bit unsigned integer, which defines the
weighting factor that offers some inputs a higher probability of
being serviced than other inputs. This property represents this
probability. Its minimum value is 0, its maximum value is
100000, and its units are thousandths.
Moore, et al. Expires: May 2001 + 6 months [Page 59]
Internet Draft QoS Device Datapath Info Model May 2001
4.4.44.2 The Property Priority
This property is a 16-bit unsigned integer, which serves as a
tiebreaker, in the event that two or more inputs 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.3.46. The Class PrioritySchedulingElement
This class is a subclass of the abstract class SchedulingElement.
It indicates that a scheduler is taking packets from a set of
inputs using the priority scheduling discipline. As is the case
with all subclasses of SchedulingElement, the input associated
with an instance of PrioritySchedulingElement is of one of two
types: either a queue, or another scheduler. The property
Priority in PrioritySchedulingElement represents the priority for
an input, relative to the priorities of all the other inputs to
which the scheduler that aggregates this PrioritySchedulerElement
is associated. Inputs to which the scheduler is related via
other scheduling disciplines do not figure in this
prioritization.
Because scheduling of this type is always work conserving, the
inherited boolean property WorkConserving is restricted to the
value TRUE in this class.
The class definition is as follows:
NAME PrioritySchedulingElement
DESCRIPTION A concrete class that specializes the
SchedulingElement class to add a
Priority property. This property is
used by a SchedulingService that is doing
priority scheduling for a set of inputs.
DERIVED FROM SchedulingElement
TYPE Concrete
PROPERTIES Priority
4.3.46.1 The Property Priority
This property is a 16-bit unsigned integer that indicates the
priority level of a scheduler input relative to the other inputs
serviced by this PacketSchedulingService. A larger value
represents a higher priority.
Moore, et al. Expires: May 2001 + 6 months [Page 60]
Internet Draft QoS Device Datapath Info Model May 2001
4.3.47. The Class BoundedPrioritySchedulingElement
This class is a subclass of the class PrioritySchedulingElement,
which is itself derived from the abstract class
SchedulingElement. As is the case with all subclasses of
SchedulingElement, the input associated with an instance of
BoundedPrioritySchedulingElement is of one of two types: either a
queue, or another scheduler. BoundedPrioritySchedulingElement
adds an upper bound (in kilobits per second) on how much traffic
can be handled from an input. This data is specific to that one
input. It is needed when bounded strict priority scheduling is
performed.
This class inherits from its superclass PrioritySchedulingElement
the restriction of the inherited boolean property WorkConserving
to the value TRUE.
The class definition is as follows:
NAME BoundedPrioritySchedulingElement
DESCRIPTION This concrete class specializes the
PrioritySchedulingElement class to add
a BandwidthBound property. This property
bounds the rate at which traffic from the
associated input can be handled.
DERIVED FROM PrioritySchedulingElement
TYPE Concrete
PROPERTIES BandwidthBound
4.3.47.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 handled from the
input. This is not a shaped upper bound, since bursts can occur.
It is a strict bound, limiting the impact of the input. The
units are kilobits per second.
4.4. Association Definitions
This section details the QoS device datapath associations,
including the aggregations, which were shown earlier in Figures 4
and 5. These associations are defined as classes in the
Information Model. Each of these classes has two properties
referring to instances of the two classes that the association
links. Some of the association classes have additional
properties as well.
4.4.1. The Abstract Association Dependency
This abstract association defines two object references (named
Antecedent and Dependent) that establish general dependency
Moore, et al. Expires: May 2001 + 6 months [Page 61]
Internet Draft QoS Device Datapath Info Model May 2001
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 Core Model of CIM. Please
refer to [CIM] for the full definition of this class.
4.4.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.
The association is defined in the Core Model of CIM. Please
refer to [CIM] for the full definition of this class.
4.4.3. The Association IngressConditioningServiceOnEndpoint
This association is derived from the association
ServiceSAPDependency, 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.
The class definition is as follows:
NAME IngressConditioningServiceOnEndpoint
DESCRIPTION An association that establishes a
dependency relationship between a protocol
endpoint and the first conditioning
service that processes traffic arriving
via that protocol endpoint.
DERIVED FROM ServiceSAPDependency
ABSTRACT False
PROPERTIES Antecedent[ref ProtocolEndpoint[0..n]],
Dependent[ref ConditioningService[0..1]]
Moore, et al. Expires: May 2001 + 6 months [Page 62]
Internet Draft QoS Device Datapath Info Model May 2001
4.4.4. The Association EgressConditioningServiceOnEndpoint
This association is derived from the association
ServiceSAPDependency, 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 be multiple "last"
ConditioningServices for a protocol endpoint in the case of a
fallback scheduler, the cardinality for the Dependent object
reference remains 0..n. Since, however, a single
ConditioningService cannot be the last one to process packets for
multiple protocol endpoints, the cardinality of the Antecedent
object reference is narrowed from 0..n to 0..1.
The class definition is as follows:
NAME EgressConditioningServiceOnEndpoint
DESCRIPTION An association that establishes a
dependency relationship between a protocol
endpoint and the last conditioning
service(s) that process traffic to be
transmitted via that protocol endpoint.
DERIVED FROM ServiceSAPDependency
ABSTRACT False
PROPERTIES Antecedent[ref ProtocolEndpoint[0..1]],
Dependent[ref ConditioningService[0..n]]
4.4.5. The Association HeadTailDropQueueBinding
This association 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]]
Moore, et al. Expires: May 2001 + 6 months [Page 63]
Internet Draft QoS Device Datapath Info Model May 2001
4.4.6. The Association CalculationBasedOnQueue
This association is a subclass of Dependency, which 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.4.6.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
DropThresholdCalculationService will use in its calculation of
average queue depth.
4.4.6.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.4.7. 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.
Moore, et al. Expires: May 2001 + 6 months [Page 64]
Internet Draft QoS Device Datapath Info Model May 2001
4.4.8. 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.4.9. The Association CalculationServiceForDropper
This association is a subclass of ServiceServiceDependency, which
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]]
4.4.9.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.
Moore, et al. Expires: May 2001 + 6 months [Page 65]
Internet Draft QoS Device Datapath Info Model May 2001
4.4.9.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.4.10. The Association QueueAllocation
This association is a subclass of Dependency, which 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.4.10.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.4.10.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.
4.4.11. The Association ClassifierElementUsesFilterList
This association is a subclass of the Dependency association. It
relates one or more ClassifierElements with a FilterList that
selects packets for each ClassifierElement to process.
In the QDDIM model, a classifier is always modeled as a
ClassifierService that aggregates a set of ClassifierElements.
The class definition is as follows:
Moore, et al. Expires: May 2001 + 6 months [Page 66]
Internet Draft QoS Device Datapath Info Model May 2001
NAME ClassifierElementUsesFilterList
DESCRIPTION An association relating a
ClassifierElement to the FilterList
that selects packets for that
ClassifierElement to process.
DERIVED FROM Dependency
ABSTRACT False
PROPERTIES Antecedent[ref FilterList [1..1]],
Dependent[ref ClassifierElement [0..n]]
4.4.11.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.
Also, its cardinality is restricted to 1, indicating that a
ClassifierElement always has exactly one FilterList to select
packets for it.
4.4.11.2 The Reference Dependent
This property is inherited from the Dependency association, and
overridden to serve as an object reference to a ClassifierElement
object, instead of to the more general ManagedElement object.
This reference identifies a ClassifierElement that depends on the
associated FilterList object to select packets for it.
4.4.12. The Association AFRelatedServices
This association 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:
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.4.12.1 The Reference AFLowerDropPrecedence
This property serves as an object reference to an AFService
object that has the lower probability of dropping packets.
Moore, et al. Expires: May 2001 + 6 months [Page 67]
Internet Draft QoS Device Datapath Info Model May 2001
4.4.12.2 The Reference AFHigherDropPrecedence
This property serves as an object reference to an AFService
object that has the higher probability of dropping packets.
4.4.13. The Association NextService
This association 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
4.4.13.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.4.13.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.
Moore, et al. Expires: May 2001 + 6 months [Page 68]
Internet Draft QoS Device Datapath Info Model May 2001
4.4.13.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.4.14. The Association NextServiceAfterMeter
This association 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
4.4.14.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.
Moore, et al. Expires: May 2001 + 6 months [Page 69]
Internet Draft QoS Device Datapath Info Model May 2001
4.4.14.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.4.15. The Association NextServiceAfterClassifierElement
This association 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]],
FollowingService
[ref ConditioningService[1..1]
4.4.15.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.
Moore, et al. Expires: May 2001 + 6 months [Page 70]
Internet Draft QoS Device Datapath Info Model May 2001
4.4.15.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.4.16. The Association NextScheduler
This association is a subclass of NextService, and defines two
object references that establish a dependency relationship
between PacketSchedulingServices. <<More text>>
The class definition is as follows:
NAME NextScheduler
DESCRIPTION An association used to establish
dependency relationships between
PacketSchedulingService objects.
<<more text>>
DERIVED FROM NextService
ABSTRACT False
PROPERTIES PrecedingService[ref
PacketSchedulingService[0..n]],
FollowingService[ref
PacketSchedulingService[0..1]]
4.4.16.1 The Reference PrecedingService
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 indicates <<more
text>>.
4.4.16.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
<<more text>>.
4.4.17. The Association FailNextScheduler
This association is a subclass of the NextScheduler association.
FailNextScheduler represents the relationship between a scheduler
and <<more text>>.
Moore, et al. Expires: May 2001 + 6 months [Page 71]
Internet Draft QoS Device Datapath Info Model May 2001
The class definition is as follows:
NAME FailNextScheduler
DESCRIPTION This association specializes the
NextScheduler relationship. <<More text>>
DERIVED FROM NextScheduler
ABSTRACT False
PROPERTIES (none)
4.4.18. The Association QueueToSchedule
This is a top-level association, representing the relationship
between a queue (QueuingService) and a SchedulingElement. The
SchedulingElement, in turn, represents the information in a
packet scheduling service that is specific to this queue, such as
relative priority or allocated bandwidth.
It cannot be expressed formally with the association
cardinalities, but there is an additional constraint on
participation in this association. A particular instance of (a
subclass of) SchedulingElement always participates either in
exactly one instance of this association, or in exactly one
instance of the association SchedulingServiceToSchedule.
The class definition is as follows:
NAME QueueToSchedule
DESCRIPTION This association relates a queue to
the SchedulingElement containing
information specific to the queue.
DERIVED FROM Nothing
ABSTRACT False
PROPERTIES Queue[ref QueuingService[0..1]],
SchedElement[ref
SchedulingElement[0..n]]
4.4.19. The Association SchedulingServiceToSchedule
This is a top-level association, representing the relationship
between a scheduler (PacketSchedulingService) and a
SchedulingElement, in a configuration where <<text explaining
about cascaded schedulers>>. The SchedulingElement, in turn,
represents the information in a subsequent packet scheduling
service that is specific to this scheduler, such as relative
priority or allocated bandwidth.
It cannot be expressed formally with the association
cardinalities, but there is an additional constraint on
participation in this association. A particular instance of (a
subclass of) SchedulingElement always participates either in
exactly one instance of this association, or in exactly one
instance of the association QueueToSchedule.
Moore, et al. Expires: May 2001 + 6 months [Page 72]
Internet Draft QoS Device Datapath Info Model May 2001
The class definition is as follows:
NAME SchedulingServiceToSchedule
DESCRIPTION This association relates a scheduler to
the SchedulingElement in a subsequent
scheduler containing information specific
to this scheduler.
DERIVED FROM Nothing
ABSTRACT False
PROPERTIES Queue[ref PacketSchedulingService[0..1]],
SchedElement[ref
SchedulingElement[0..n]]
4.4.20. The Aggregation MemberOfCollection
This aggregation is a generic relationship used to model the
aggregation of a set of ManagedElements in a generalized
Collection object. The aggregation's cardinality is many to
many.
MemberOfCollection is defined in the Core Model of CIM. Please
refer to [CIM] for the full definition of this class.
4.4.21. The Aggregation CollectedBufferPool
This aggregation models the ability to treat a set of buffers as
a pool, or collection, that can in turn be contained in a
"higher-level" buffer pool. This class overrides the more
generic MemberOfCollection aggregation to restrict both the
aggregate and the part component objects to be instances only of
the BufferPool class.
The class definition for the aggregation is as follows:
NAME CollectedBufferPool
DESCRIPTION A generic association used to aggregate
a set of related buffers into a
higher-level buffer pool.
DERIVED FROM MemberOfCollection
ABSTRACT False
PROPERTIES Collection[ref BufferPool[0..1]],
Member[ref BufferPool[0..n]]
4.4.21.1 The Reference Collection
This property represents the parent, or aggregate, object in the
relationship. It is a BufferPool object.
Moore, et al. Expires: May 2001 + 6 months [Page 73]
Internet Draft QoS Device Datapath Info Model May 2001
4.4.21.2 The Reference Member
This property represents the child, or lower level pool, in the
relationship. It is one of the set of BufferPools that together
make up the higher-level pool.
4.4.22. The Abstract Aggregation Component
This abstract aggregation is a generic relationship used to
establish "part-of" relationships between managed objects (named
GroupComponent and PartComponent). The association's cardinality
is many to many.
The association is defined in the Core Model of CIM. Please
refer to [CIM] for the full definition of this class.
4.4.23. The Aggregation ServiceComponent
This aggregation is used to model a set of subordinate Services
that are aggregated together to form a higher-level Service.
This aggregation is derived from the more generic Component
superclass to restrict the types of objects that can participate
in this relationship.
The association is defined in the Core Model of CIM. Please
refer to [CIM] for the full definition of this class.
4.4.24. The Aggregation QoSSubService
This aggregation represents a set of subordinate 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
set of lower-level QoSServices that
are aggregated to create/form it.
DERIVED FROM ServiceComponent
ABSTRACT False
PROPERTIES GroupComponent[ref QoSService[0..1]],
Moore, et al. Expires: May 2001 + 6 months [Page 74]
Internet Draft QoS Device Datapath Info Model May 2001
PartComponent[ref QoSService[0..n]]
4.4.24.1 The Reference GroupComponent
This property is overridden in this aggregation to represent an
object reference to a QoSService object (instead of to the more
generic Service object defined in its superclass). This object
represents the parent, or aggregate, object in the relationship.
4.4.24.2 The Reference PartComponent
This property is overridden in this aggregation to represent an
object reference to a QoSService object (instead of to the more
generic Service object defined in its superclass). This object
represents the child, or "component", object in the relationship.
4.4.25. The Aggregation QoSConditioningSubService
This aggregation identifies the set of ConditioningServices that
together condition traffic for a particular QoSService.
This aggregation is derived from the more generic
ServiceComponent superclass; it restricts the types of objects
that can participate in it to ConditioningService and QoSService
objects, instead of the more generic Service objects.
The class definition for the aggregation is as follows:
NAME QoSConditioningSubService
DESCRIPTION A generic aggregation used to establish
"part-of" relationships between a set
of ConditioningService objects and the
particular QoSService object(s) that they
provide traffic conditioning for.
DERIVED FROM ServiceComponent
ABSTRACT False
PROPERTIES GroupComponent[ref QoSService[0..n]],
PartComponent[ref
ConditioningService[0..n]]
4.4.25.1 The Reference GroupComponent
This property is overridden in this aggregation to represent an
object reference to a QoSService object (instead of to the more
generic Service object defined in its superclass). The
cardinality of the reference remains 0..n, to indicate that a
given ConditioningService may provide traffic conditioning for 0,
1, or more than 1 QoSService objects.
This object represents the parent, or aggregate, object in the
association. In this case, this object represents the QoSService
Moore, et al. Expires: May 2001 + 6 months [Page 75]
Internet Draft QoS Device Datapath Info Model May 2001
that aggregates one or more ConditioningService objects to
implement the appropriate traffic conditioning for its traffic.
4.4.25.2 The Reference PartComponent
This property is overridden in this aggregation to represent an
object reference to a ConditioningService object (instead of to
the more generic Service object defined in its superclass). This
object represents the child, or "component", object in the
relationship. In this case, this object represents one or more
ConditioningService objects that together indicate how traffic
for a specific QoSService is conditioned.
4.4.26. The Aggregation ClassifierElementInClassifierService
This aggregation represents the relationship between a classifier
and the classifier elements that provide the fan-out function for
the classifier. A classifier typically aggregates multiple
classifier elements. A classifier element, however, is
aggregated only by a single classifier. See [DSMODEL] and
[DSMIB] for more about classifiers and classifier elements.
The class definition for the aggregation is as follows:
NAME ClassifierElementInClassifierService
DESCRIPTION An aggregation representing the
relationship between a classifier
and its classifier elements.
DERIVED FROM ServiceComponent
ABSTRACT False
PROPERTIES GroupComponent[ref
ClassifierService[1..1]],
PartComponent[ref
ClassifierElement[0..n],
ClassifierOrder
4.4.26.1 The Reference GroupComponent
This property is overridden in this aggregation to represent an
object reference to a ClassifierService object (instead of to the
more generic Service object defined in its superclass). It also
restricts the cardinality of the aggregate to 1..1 (instead of
the more generic 0-or-more), representing the fact that a
ClassifierElement always exists within the context of exactly one
ClassifierService.
4.4.26.2 The Reference PartComponent
This property is overridden in this aggregation to represent an
object reference to a ClassifierElement object (instead of to the
more generic Service object defined in its superclass). This
object represents a single traffic selector for the classifier.
Moore, et al. Expires: May 2001 + 6 months [Page 76]
Internet Draft QoS Device Datapath Info Model May 2001
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.4.26.3 The Property ClassifierOrder
Because the filters for a classifier can overlap, it is necessary
to specify the order in which the ClassifierElements aggregated
by a ClassifierService are presented with packets coming into the
classifier. This property is an unsigned 32-bit integer
representing this order. Values are represented in ascending
order: first '1', then '2', and so on. Different values MUST be
assigned for each of the ClassifierElements aggregated by a given
ClassifierService.
4.4.27. The Aggregation EntriesInFilterList
This aggregation is a specialization of the Component
aggregation; it is used to define a set of filter entries
(subclasses of FilterEntryBase) that are aggregated by a
FilterList.
The cardinalities of the aggregation itself are 0..1 on the
FilterList end, and 0..n on the FilterEntryBase end. Thus in the
general case, a filter entry can exist without being aggregated
into any FilterList. However, the only way a filter entry can
figure in the QoS Device model is by being aggregated into a
FilterList by this aggregation.
The class definition for the aggregation is as follows:
NAME EntriesInFilterList
DESCRIPTION An aggregation used to define a set of
filter entries (subclasses of
FilterEntryBase) that are aggregated by
a particular FilterList.
DERIVED FROM Component
ABSTRACT False
PROPERTIES GroupComponent[ref
FilterList[0..1]],
PartComponent[ref
FilterEntryBase[0..n],
EntrySequence
4.4.27.1 The Reference GroupComponent
This property is overridden in this aggregation to represent an
object reference to a FilterList object (instead of to the more
generic ManagedSystemElement object defined in its superclass).
It also restricts the cardinality of the aggregate to 0..1
(instead of the more generic 0-or-more), representing the fact
Moore, et al. Expires: May 2001 + 6 months [Page 77]
Internet Draft QoS Device Datapath Info Model May 2001
that a filter entry always exists within the context of at most
one FilterList.
4.4.27.2 The Reference PartComponent
This property is overridden in this aggregation to represent an
object reference to a FilterEntryBase object (instead of to the
more generic ManagedSystemElement object defined in its
superclass). This object represents a single filter entry, which
may be aggregated with other filter entries to form the
FilterList.
4.4.27.3 The Property EntrySequence
An unsigned 16-bit integer indicating the order of the filter
entry relative to all others in the FilterList. Since order of
filter entry evaluation is represented differently in QDDIM, via
the ClassifierOrder property in the
ClassifierElementInClassifierService aggregation, this property
always returns its default value, '0', indicating that the
entries in this FilterList are ANDed together.
4.4.28. The Aggregation ElementInSchedulingService
This concrete aggregation represents the relationship between a
PacketSchedulingService and the set of SchedulingElements that
tie it to its inputs.
The class definition for the aggregation is as follows:
NAME ElementInSchedulingService
DESCRIPTION An aggregation used to define a set of
filter entries (subclasses of
FilterEntryBase) that are aggregated by
a particular FilterList.
DERIVED FROM Component
ABSTRACT False
PROPERTIES GroupComponent[ref
PacketSchedulingService[0..1]],
PartComponent[ref
SchedulingElement[0..n]
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
Moore, et al. Expires: May 2001 + 6 months [Page 78]
Internet Draft QoS Device Datapath Info Model May 2001
standards-track and standards-related documentation can be found
in BCP-11.
Copies of claims of rights made available for publication and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the
use of such proprietary rights by implementers or users of this
specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights which may cover technology that may be
required to practice this standard. Please address the
information to the IETF Executive Director.
6. Acknowledgements
The authors wish to thank the participants of the Policy
Framework and Differentiated Services working groups for their
many helpful comments and suggestions.
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.
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.5.
Distributed Management Task Force, Inc. The components of
the CIM v2.5 schema are available via links on the following
DMTF web page: http://www.dmtf.org/spec/cims.html.
Moore, et al. Expires: May 2001 + 6 months [Page 79]
Internet Draft QoS Device Datapath Info Model May 2001
[DSMIB] Management Information Base for the Differentiated
Services Architecture. Internet Draft, draft-ietf-diffserv-
mib-09.txt, F. Baker, K. Chan, and A. Smith. March 2001.
[DSMODEL] An Informal Management Model for DiffServ Routers.
Internet Draft, draft-ietf-diffserv-model-06.txt, Y. Bernet,
A. Smith, S. Blake, and D. Grossman. February 2001.
[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.
RFC 3060, B. Moore, E. Ellesson, J. Strassner, and A.
Westerinen. February 2001.
[PCIME] Policy Core Information Model Extensions. Internet-
Draft, draft-ietf-policy-pcim-ext-01.txt, B. Moore, L.
Rafalow, Y. Ramberg, Y. Snir, J. Strassner, A. Westerinen, R.
Chadha, M. Brunner, R. Cohen. April 2001.
[PIB] Differentiated Services Quality of Service Policy
Information Base. Internet Draft, draft-ietf-diffserv-pib-
03.txt, M. Fine, K. McCloughrie, J. Seligson, K. Chan, S.
Hahn, A. Smith, and F. Reichmeyer. March 2001.
[POLTERM] Policy Terminology. Internet Draft, draft-ietf-policy-
terminology-03.txt, A. Westerinen, et al. April 2001.
[QPIM] Policy Framework QoS Information Model. Internet Draft,
draft-ietf-policy-qos-info-model-03.txt, Y. Snir, Y. Ramberg,
J. Strassner, and R. Cohen. April 2001.
[R791] Postel, J., Editor, "Internet Protocol", STD RFC 791,
September 1981.
[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.
Moore, et al. Expires: May 2001 + 6 months [Page 80]
Internet Draft QoS Device Datapath Info Model May 2001
[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.
[R2836] Per Hop Behavior Identification Codes. S. Brim, B.
Carpenter, and F. Le Faucheur. May 2000.
[RED] See http://www-nrg.ee.lbl.gov/floyd/red.html.
9. Authors' Addresses
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
Joel Halpern
Longitude Systems, Inc.
Suite 5500
15000 Conference Center Dr.
Chantilly, VA 20151
E-mail: joel@longsys.com
John Strassner
INTELLIDEN, Inc.
90 South Cascade Avenue
Colorado Springs, CO 80903
Phone: +1-719-785-0648
E-mail: john.strassner@intelliden.com
Andrea Westerinen
Cisco Systems, Bldg 20
725 Alder Drive
Milpitas, CA 95035
E-mail: andreaw@cisco.com
Walter Weiss
Moore, et al. Expires: May 2001 + 6 months [Page 81]
Internet Draft QoS Device Datapath Info Model May 2001
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 (2001). 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.
Moore, et al. Expires: May 2001 + 6 months [Page 82]
Internet Draft QoS Device Datapath Info Model May 2001
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 the
classes in this model 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 Subclasses of FilterEntryBase
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.
Thus instances of all of the subclasses of FilterEntryBase are
named in the same way: with the four key properties they inherit
from FilterEntryBase.
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
Moore, et al. Expires: May 2001 + 6 months [Page 83]
Internet Draft QoS Device Datapath Info Model May 2001
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 property 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.
11.6. Naming Instances of SchedulingElement
This class has not yet been incorporated into the CIM model, so
it does not have any CIM naming properties yet. If the normal
pattern is followed, however, instances will be named with two
properties CreationClassName and Name.
Moore, et al. Expires: May 2001 + 6 months [Page 84] | PAFTECH AB 2003-2026 | 2026-04-24 00:47:00 |