Request for Comments: 3670 IBM Corporation
Category: Standards Track D. Durham
Intel
J. Strassner
INTELLIDEN, Inc.
A. Westerinen
Cisco Systems
W. Weiss
Ellacoya
January 2004
Information Model for Describing
Network Device QoS Datapath Mechanisms
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
The purpose of this document 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 properties 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
and Integrated Services.
This document should 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 documents describe how to write QoS policy rules
to configure and manage the QoS mechanisms present in the datapaths
of devices.
This document, as well as QPIM, are information models. That is,
they represent information independent of a binding to a specific
type of repository.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
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 Properties . . . . . . . . . . . 14
3.6. QoS Information Model Derivation . . . . . . . . . . . . 15
3.7. Attribute Representation . . . . . . . . . . . . . . . . 16
3.8. Mental Model . . . . . . . . . . . . . . . . . . . . . . 17
3.8.1. The QoSService Class . . . . . . . . . . . . . . 17
3.8.2. The ConditioningService Class. . . . . . . . . . 18
3.8.3. Preserving QoS Information from Ingress to
Egress . . . . . . . . . . . . . . . . . . . . . 19
3.9. Classifiers, FilterLists, and Filter Entries . . . . . . 21
3.10. Modeling of Droppers . . . . . . . . . . . . . . . . . . 23
3.10.1. Configuring Head and Tail Droppers . . . . . . . 23
3.10.2. Configuring RED Droppers . . . . . . . . . . . . 24
3.11. Modeling of Queues and Schedulers. . . . . . . . . . . . 25
3.11.1. Simple Hierarchical Scheduler. . . . . . . . . . 25
3.11.2. Complex Hierarchical Scheduler . . . . . . . . . 27
3.11.3. Excess Capacity Scheduler. . . . . . . . . . . . 29
3.11.4. Hierarchical CBQ Scheduler . . . . . . . . . . . 31
4. The Class Hierarchy. . . . . . . . . . . . . . . . . . . . . . 33
4.1. Associations and Aggregations. . . . . . . . . . . . . . 33
4.2. The Structure of the Class Hierarchies . . . . . . . . . 34
4.3. Class Definitions. . . . . . . . . . . . . . . . . . . . 38
4.3.1. The Abstract Class ManagedElement. . . . . . . . 38
4.3.2. The Abstract Class ManagedSystemElement. . . . . 39
4.3.3. The Abstract Class LogicalElement. . . . . . . . 39
4.3.4. The Abstract Class Service . . . . . . . . . . . 39
4.3.5. The Class ConditioningService. . . . . . . . . . 39
4.3.6. The Class ClassifierService. . . . . . . . . . . 40
4.3.7. The Class ClassifierElement. . . . . . . . . . . 41
4.3.8. The Class MeterService . . . . . . . . . . . . . 42
4.3.9. The Class AverageRateMeterService. . . . . . . . 44
4.3.10. The Class EWMAMeterService . . . . . . . . . . . 44
4.3.11. The Class TokenBucketMeterService. . . . . . . . 46
4.3.12. The Class MarkerService. . . . . . . . . . . . . 47
4.3.13. The Class PreambleMarkerService. . . . . . . . . 47
4.3.14. The Class ToSMarkerService . . . . . . . . . . . 48
4.3.15. The Class DSCPMarkerService. . . . . . . . . . . 49
4.3.16. The Class 8021QMarkerService . . . . . . . . . . 49
4.3.17. The Class DropperService . . . . . . . . . . . . 50
4.3.18. The Class HeadTailDropperService . . . . . . . . 52
4.3.19. The Class REDDropperService. . . . . . . . . . . 52
4.3.20. The Class QueuingService . . . . . . . . . . . . 54
4.3.21. The Class PacketSchedulingService. . . . . . . . 55
4.3.22. The Class NonWorkConservingSchedulingService . . 56
4.3.23. The Class QoSService . . . . . . . . . . . . . . 57
4.3.24. The Class DiffServService. . . . . . . . . . . . 58
4.3.25. The Class AFService. . . . . . . . . . . . . . . 59
4.3.26. The Class FlowService. . . . . . . . . . . . . . 60
4.3.27. The Class DropThresholdCalculationService. . . . 60
4.3.28. The Abstract Class FilterEntryBase . . . . . . . 61
4.3.29. The Class IPHeaderFilter . . . . . . . . . . . . 62
4.3.30. The Class 8021Filter . . . . . . . . . . . . . . 62
4.3.31. The Class PreambleFilter . . . . . . . . . . . . 62
4.3.32. The Class FilterList . . . . . . . . . . . . . . 63
4.3.33. The Abstract Class ServiceAccessPoint. . . . . . 63
4.3.34. The Class ProtocolEndpoint . . . . . . . . . . . 63
4.3.35. The Abstract Class Collection. . . . . . . . . . 65
4.3.36. The Abstract Class CollectionOfMSEs. . . . . . . 65
4.3.37. The Class BufferPool . . . . . . . . . . . . . . 65
4.3.38. The Abstract Class SchedulingElement . . . . . . 65
4.3.39. The Class AllocationSchedulingElement. . . . . . 66
4.3.40. The Class WRRSchedulingElement . . . . . . . . . 67
4.3.41. The Class PrioritySchedulingElement. . . . . . . 69
4.3.42. The Class BoundedPrioritySchedulingElement . . . 70
4.4. Association Definitions. . . . . . . . . . . . . . . . . 70
4.4.1. The Abstract Association Dependency. . . . . . . 71
4.4.2. The Association ServiceSAPDependency . . . . . . 71
4.4.3. The Association
IngressConditioningServiceOnEndpoint . . . . . . 71
4.4.4. The Association
EgressConditioningServiceOnEndpoint. . . . . . . 72
4.4.5. The Association HeadTailDropQueueBinding . . . . 72
4.4.6. The Association CalculationBasedOnQueue. . . . . 73
4.4.7. The Association ProvidesServiceToElement . . . . 74
4.4.8. The Association ServiceServiceDependency . . . . 74
4.4.9. The Association CalculationServiceForDropper . . 75
4.4.10. The Association QueueAllocation. . . . . . . . . 75
4.4.11. The Association ClassifierElementUsesFilterList. 76
4.4.12. The Association AFRelatedServices. . . . . . . . 77
4.4.13. The Association NextService. . . . . . . . . . . 78
4.4.14. The Association
NextServiceAfterClassifierElement. . . . . . . . 79
4.4.15. The Association NextScheduler. . . . . . . . . . 80
4.4.16. The Association FailNextScheduler. . . . . . . . 81
4.4.17. The Association NextServiceAfterMeter. . . . . . 82
4.4.18. The Association QueueToSchedule. . . . . . . . . 83
4.4.19. The Association SchedulingServiceToSchedule. . . 84
4.4.20. The Aggregation MemberOfCollection . . . . . . . 85
4.4.21. The Aggregation CollectedBufferPool. . . . . . . 85
4.4.22. The Abstract Aggregation Component . . . . . . . 86
4.4.23. The Aggregation ServiceComponent . . . . . . . . 86
4.4.24. The Aggregation QoSSubService. . . . . . . . . . 86
4.4.25. The Aggregation QoSConditioningSubService. . . . 87
4.4.26. The Aggregation
ClassifierElementInClassifierService . . . . . . 88
4.4.27. The Aggregation EntriesInFilterList. . . . . . . 89
4.4.28. The Aggregation ElementInSchedulingService . . . 90
5. Intellectual Property Statement. . . . . . . . . . . . . . . . 91
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 91
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 91
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 92
8.1. Normative References. . . . . . . . . . . . . . . . . . . 92
8.2. Informative References . . . . . . . . . . . . . . . . . 92
9. Appendix A: Naming Instances in a Native CIM Implementation . 94
9.1. Naming Instances of the Classes Derived from Service. . . 94
9.2. Naming Instances of Subclasses of FilterEntryBase . . . . 94
9.3. Naming Instances of ProtocolEndpoint. . . . . . . . . . . 94
9.4. Naming Instances of BufferPool. . . . . . . . . . . . . . 95
9.4.1. The Property CollectionID. . . . . . . . . . . . 95
9.4.2. The Property CreationClassName . . . . . . . . . 95
9.5. Naming Instances of SchedulingElement . . . . . . . . . . 95
10. Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . 96
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 97
1. Introduction
The purpose of this document 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 document 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 documents describe how to write QoS
policy rules to configure and manage the QoS mechanisms present in
the datapaths of devices.
This document, as well as [QPIM], are information models. That is,
they represent information independent of a binding to a specific
type of repository. A separate document 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 document could be written to provide a
mapping of the data in [QPIM] to a directory. Together, these four
documents (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 document 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 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 document is influenced by the Network QoS submodel
defined by the Distributed Management Task Force (DMTF) - see [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 document) from their control (specified using the
generic policy document [PCIM] augmented by the QoS Policy document
[QPIM]).
While it is not a policy model per se, this document does have a
dependency on the Policy Core Information Model Extensions document
[PCIME]. The device-level packet filtering, through which a
Classifier splits a traffic stream into multiple streams, is based on
the FilterEntryBase and FilterList classes defined in [PCIME].
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 BCP 14, RFC 2119
[R2119].
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 192.0.2.100
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
document (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 document 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
Differentiated Services Code Point (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".
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 document focuses on the
specification of QoS properties 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 document focuses on the datapath, elements of RSVP
applicable to the datapath will be considered in the structure of the