RFC 3670
Information Model for Describing Network Device QoS Datapath Mechanisms
Pages: 97
Proposed Standard
Proposed Standard
Part 1 of 4 – Pages 1 to 9
Network Working Group B. Moore 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 classes. The complete IntServ device model will, as we have indicated earlier, be addressed in a subsequent document. This document 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 document 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 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 document 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 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 document.