RFC 3670
Information Model for Describing Network Device QoS Datapath Mechanisms
RFC 3670: Information Model for Describing Network Device QoS Datapath Mechanisms 🎀
Okay bestie, this one is from the Network Working Group and it's dated January 2004 📅. Here's who made it 💅:
- B. Moore (IBM Corporation)
- D. Durham (Intel)
- J. Strassner (INTELLIDEN, Inc.)
- A. Westerinen (Cisco Systems)
- W. Weiss (Ellacoya)
It's a Standards Track doc 🦋, and its header doesn't list anything it obsoletes or updates ✨. Fun fact: that's a clean slate!
Status of this Memo 📜
So this doc is an Internet standards track protocol for the Internet community 🌈, and the authors are asking for discussion and suggestions for improvements 🫶. If you want the official standardization state and status of this protocol, go check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. And the distribution of this memo is unlimited, so share it with everyone 💜.
Copyright Notice ©️
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract 🧚
Okay so the whole point of this doc is to define an information model 🗂️ for describing the quality of service (QoS) mechanisms that different network devices have, hosts included 💻. Broadly speaking, these mechanisms are the properties shared by the ways devices select and condition traffic as it moves through the forwarding path (datapath) 🛣️. And this selecting and conditioning in the datapath covers both major QoS architectures: Differentiated Services and Integrated Services ⭐. It's giving full coverage, no cap 💅.
Next, this doc is meant to be paired with the QoS Policy Information Model (QPIM) 🔥. Together they show how to define policies that manage and configure the QoS mechanisms of devices, meaning classification, marking, metering, dropping, queuing, and scheduling 🍓. Basically, the two docs teach you how to write QoS policy rules to set up and manage the QoS mechanisms in device datapaths. Main character energy 👑.
Also, this doc and QPIM are both information models. That means they represent information independent of a binding to a specific type of repository 🌸. Not tied to one storage type, periodt ✨.
Table of Contents 📖
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 . . . . . . . . . . . . . . . . . . . 971. Introduction ✨
okay so the whole point of this doc is to define an information model that describes the quality of service (QoS) mechanisms in different network devices, including hosts 💅 basically these are the attributes everyone shares when it comes to picking and conditioning traffic as it moves through a device's forwarding path (datapath) 🦋 and this selecting and conditioning happens in both major QoS architectures: Differentiated Services (see [R2475]) and Integrated Services (see [R1633]) 🌈
this doc is meant to be used alongside the QoS Policy Information Model [QPIM] to model how policies get defined to manage and configure a device's QoS mechanisms (aka the classification, marking, metering, dropping, queuing, and scheduling stuff) 🎀 together these two docs show you how to write QoS policy rules to configure and manage the QoS mechanisms sitting in the datapaths of devices ✨
this doc and [QPIM] are both information models, which means they describe information without being tied to any one specific type of repository 🧚 someone could write a separate doc mapping the data in this one to a form you can actually implement in a directory that uses (L)DAP as its access protocol 💜 same deal for the data in [QPIM] and a directory 🍓 put those four docs together (the information models plus the directory schema mappings) and you'd have a full picture of how to write QoS policy rules that store info in directories to configure device QoS mechanisms 🙌
the approach here is to define a common set of classes that can be used to model QoS in a device datapath 🫶 vendors can then map those classes, either directly or through something in between like a COP-PR PIB, onto their own device-specific implementations 💖 also, heads up: the admission control element of Integrated Services is NOT in scope for this model 🙈
the class, association, and aggregation hierarchies in this doc were influenced by the Network QoS submodel from the Distributed Management Task Force (DMTF) - see [CIM] 🌸 but they are NOT derived from the Policy Core Information Model [PCIM] 👀 that's because modeling a device's QoS mechanisms is separate and distinct from modeling the policies that manage those mechanisms 💅 so we need to keep QoS mechanisms (this doc) apart from their control (specified using the generic policy doc [PCIM] plus the QoS Policy doc [QPIM]) ✨
not a policy model per se, but this doc DOES depend on the Policy Core Information Model Extensions document [PCIME] 🦋 the device-level packet filtering that a Classifier uses to split one 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
okay the Policy Core Information Model [PCIM] is the one that lays out a general methodology for building policy rules 🧠 PCIM Extensions [PCIME] updates and extends the original PCIM 💜 a policy rule bundles together a set of policy conditions and an ordered set of policy actions ✨ the semantics are simple: if the conditions evaluate to TRUE, then the actions get executed 🎀
policy conditions and actions have two main parts: operands and operators 🍓 operands can be constants or variables 🌈 to specify a policy, you need to specify:
- the operands to be examined (also known as state variables) 👀
- the operands to be changed (also known as configuration variables) 🔥
- the relationships between these two sets of operands 💖
operands can be super high-level, like Joe (a user) or Gold (a service) 🧚 they can also be way finer-grained and much closer to how the device actually operates 🛠️ examples of the latter are an IP Address or a queue's bandwidth allocation 🌸 using operands always comes with binding legal values or ranges of values to them 💅 for example, an IP address value can't be an integer 🙅♀️ the concepts of operands and their ranges are defined in [PCIME] 🦋
the second part of policy conditions and actions is a set of operators 🫶 operators can express relationships (greater than, member of a set, Boolean OR, etc.) and assignments 💜 together, operators and operands can express all sorts of conditions and actions, like:
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 Mbwe fully recognize that defining operator semantics is critical to defining policies 🥹 BUT defining these operators is beyond the scope of this document 🙈 instead, this doc (together with [QPIM]) takes the first steps toward identifying and standardizing a set of properties (operands) for defining policies for Differentiated and Integrated Services 🎀✨
1.2. Purpose and Relation to Other Policy Work
this model sets up a canonical model of the QoS mechanisms of a network device (think a router, switch, or host) that doesn't depend on any specific type of network device 🌈 that way traffic conditioning can be described using one shared set of abstractions, modeled as a set of services and sub-services 💅
when you use the concepts from this doc together with the concepts from [QPIM], you can define policies that bind the services in a network to the needs of the applications using that network 👑 in other words, an organization's business requirements can be reflected in one set of policies, and those policies can get translated into a lower-level set of policies that control and manage how network devices are configured and operate 🫶
1.3. Typical Examples of Policy Usage
policies can be implemented as low-level rules using the information model described in this spec 🧚 for example, in a low-level policy, a condition can be represented as an evaluation of a specific attribute from this model 💖 so a condition like "If filter = HTTP" would be interpreted as a test that checks whether any HTTP filters have been defined for the device 🔍 a high-level policy like "If protocol = HTTP, then mark with Differentiated Services Code Point (DSCP) 24," gets expressed as a series of actions in a low-level policy, using the classes and attributes described below 🦋:
- Create HTTP filter
- Create DSCP marker with the value of 24
- Bind the HTTP filter to the DSCP marker
✨ heads up bestie: unlike "mark with DSCP 24", these low-level actions are NOT performed on a packet as it passes through the device 🙅♀️ they're configuration actions performed on the device itself, to get it ready to perform the correct action(s) on the correct packet(s) 🎀
moving from a high-level policy rule to the right set of low-level device configuration actions is an example of what [POLTERM] characterizes as "policy translation" or "policy conversion" 📚 literally the whole vibe of this section 🫶
2. Approach 🦋
QoS activity in the IETF has mainly focused on two areas, Integrated Services (IntServ) and Differentiated Services (DiffServ) (see [POLTERM], [R1633] and [R2475]) 🌸 this doc focuses on specifying QoS properties and classes for modeling the datapath where packet traffic gets conditioned 🔥 BUT the framework defined by the classes in this doc was also designed with the needs of the admission control portion of IntServ in mind 💜
2.1. Common Needs Of DiffServ and IntServ
first up, let's talk IntServ 💅 IntServ has two principal components 👑 one of them lives in the datapath of the networking device, and its functions include classifying and policing individual flows and scheduling admitted packets for the outbound link 🎀 the other component is admission control, which focuses on managing the signaling protocol (e.g., the PATH and RESV messages of RSVP) 🌈 this one processes reservation requests, manages bandwidth, outsources decision making to policy servers, and interacts with the Routing Table manager 🫶
we'll consider RSVP when defining the structure of this information model ✨ since this doc focuses on the datapath, the elements of RSVP that apply to the datapath will be considered in the structure of the classes 🦋 the complete IntServ device model will, as we've already said, be addressed in a subsequent document 🧚
this doc models a small subset of the QoS policy problem 💖 the hope is to construct a methodology that can be adapted to other aspects of QoS in particular, and to policy construction in general 🌸 the focus here 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 as the IntServ datapath, with two major differences 💅 the first is that DiffServ classifies packets based solely on their DSCP field, whereas IntServ examines a subset of a standard flow's addressing 5-tuple 🙈 the exception is a router or host sitting at the boundary of a DiffServ domain 👀 a device in that spot may examine a packet's DSCP, its addressing 5-tuple, other fields in the packet, or even information wholly outside the packet when deciding which DSCP value to mark the packet with before it's transferred into the DiffServ domain 💜 routers in the interior of a DiffServ domain, though, only need to classify based on the DSCP field 🫶
the second difference is that the signaling protocol used in IntServ (e.g., RSVP) affects the configuration of the datapath in a more dynamic way 🌈 that's because every newly admitted RSVP reservation requires a reconfiguration of the datapath 😭 DiffServ, on the other hand, requires far fewer changes to the datapath once the Per Hop Behaviors (PHBs) have been configured 🎀
the approach this doc takes to creating policies that control the various QoS mechanisms of networking devices is to first identify the attributes the policies will be built from 🧚 these attributes are the parameters used in the expressions needed to construct policies ✨ there's also a parallel goal of defining the operators, relations, and precedence constructs needed to build the conditions and actions that make up these policies 💖 BUT those efforts are beyond the scope of this document 🙈💅
2.2. Specific Needs Of DiffServ ✨
okay so DiffServ has two main vibes it cares about: the core and the edges of the network 🌐 As the DiffServ Architecture document [R2475] explains, devices at the edge sort traffic into different streams 🦋 Then the core forwards those streams using a set of Per Hop Behaviors (PHBs) 💅 Each PHB is identified by a DSCP, and the DSCP lives in the IP header of every packet (as described in [R2474]) 🎀 This is the iconic part: lots of traffic streams get bundled into a small number of aggregated streams, where each aggregate is labeled with one particular DSCP and forwarded using one particular PHB 🧚
The attributes used to manipulate QoS in the core mostly care about how each supported PHB behaves 🔥 Then at the edges of a DiffServ network, things get messier 😭 You've got flow classification, policing, RSVP mappings, remarkings, and other stuff to think about. Additional modeling will be required in this area 🌸 But first, the standards for the edges need more detail, so the edges can actually be pulled into the policy model. It's not ready yet, bestie 🙈
2.3. Specific Needs Of IntServ 💜
This document is laser-focused on the forwarding side of network QoS 🎯 So yes, the forwarding aspects of IntServ get considered, but the management of IntServ does not. That topic is saved for a future document 🫶
3. Methodology 🍓
There's a clear need to define attributes and behavior that together describe how traffic should be conditioned 💖 This document defines a set of classes and relationships that represent the QoS mechanisms used to condition traffic. [QPIM] is what gets used to define policies that control those QoS mechanisms 🌈
Some very basic issues still need to be considered when you combine these documents, though 👀 Thinking them through should help you build a schema for managing the operation and configuration of network QoS mechanisms through QoS policies ✨
3.1. Level of Abstraction for Expressing QoS Policies 🦋
The first thing to figure out is the level of abstraction QoS policies should be written at 💅 If you think of policies as rules that react to events and manipulate attributes or generate new events, then policy is actually a continuum 🌈 It runs from specs that connect business goals and rules all the way down to how a device, or a bunch of devices, conditions traffic 🫶 Like, a business-level policy could be: from 1:00 pm PST to 7:00 am EST, sell off 40% of the network capacity on the open market 💀 Meanwhile 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 😭
Here's the general model for this continuum, 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 ContinuumHigh-level business policies express what the different applications need, and they decide which apps get "better" treatment when the network is congested 👑 The whole goal is to link a device's operational and configuration needs directly to the business rules the network admin is trying to run on the network that the device belongs to 💜
Device-independent policies take those business policies and turn them into generalized operational and configuration policies 🎀 They don't care about any one specific device, but they do depend on a particular set of QoS mechanisms, like random early detection (RED) dropping or weighted round robin scheduling 🌸 This is so good, because it means different kinds of devices (routers, switches, hosts, etc.) can all be controlled by QoS policies. It also means devices from different vendors that use the same types of QoS mechanisms can be controlled too 🔥 That way, each one can supply the correct relative conditioning to the same type of traffic ✨
Device-dependent policies are the opposite vibe 💅 They take the device-independent policies and make them specific to one given device 🙈 The reason there's a split between the two is that in a given network, lots of different devices with lots of different capabilities need to be controlled together 🫶 Device-independent policies give everyone a common layer of abstraction for managing devices with different capabilities, and device-dependent policies handle the exact conditioning each one needs 🦋 This document provides a common set of abstractions for representing QoS mechanisms in a device-independent way 💖
This document focuses on that device-independent representation of QoS mechanisms 🌈 The mechanisms are modeled in enough detail to give a common device-independent representation of QoS policies ✨ They can also serve as a basis for specialization, so each vendor can derive its own vendor-specific classes showing how that vendor's devices do traffic conditioning 🧚
3.2. Specifying Policy Parameters 💜
Policies are a function of parameters (attributes) and operators (boolean, arithmetic, relational, etc.) 🎀 So both have to be defined as part of the same policy, or the traffic won't get conditioned correctly 😭 If the parameters are specified too narrowly, they end up reflecting each device's own implementation of QoS 💀 And since the industry hasn't really agreed on what the correct implementation model for QoS is, most of the defined attributes would only fit the unique quirks of a few individual devices 🙈 Trying to standardize every possible implementation would also be a never-ending task, because new implementations keep showing up on the market 🌸
On the flip side, if the parameters are specified too broadly, you can't build meaningful policies at all 🔥 Like, if we look at the so-called Olympic set of policies, a business policy like "Bob gets Gold Service," is totally meaningless to most existing devices 💅 The device has no way of figuring out who Bob is, or which QoS mechanisms should be configured in what way to give Gold service 😭
And Gold service might be one single service, or it might be a set of related services 👑 If it's the second one, those services might have different conditioning characteristics 🦋
This document defines a set of parameters that fit into a canonical model for the elements in a device's forwarding path that implement QoS traffic conditioning ✨ By defining the model in a device-independent way, the parameters you need can be abstracted properly 🫶
3.3. Specifying Policy Services 🌈
Administrators want to be able to define traffic conditioning without needing a low-level understanding of the different QoS mechanisms behind it 💖 They also want to group different services together, describing a higher-level concept like "Gold Service" 🧚 That higher-level service can be seen as providing the processing that delivers "Gold" quality of service 🎀
Those two goals call for the following set of abstractions:
- a flexible way to describe a service
- must be able to group different services that may use different technologies (e.g., DiffServ and IEEE 802.1Q) together
- must be able to define a set of sub-services that together make up a higher-level service
- must be able to associate a service and the set of QoS mechanisms that are used to condition traffic for that service
- must be able to define policies that manage the QoS mechanisms used to implement a service.
This document handles this set of problems by defining classes and associations that can represent abstract concepts like "Gold Service," and bind each of those abstract services to the specific set of QoS mechanisms that implement the conditioning they need 💅 It also defines the concept of "sub-services," so Gold Service can be defined either as a single service or as a set of services that should be treated together as one atomic entity 🔥
With these abstractions in place, policies (as defined in [QPIM]) can be written to control the QoS mechanisms and services defined in this document 🌸✨
3.4. Level of Abstraction for Defining QoS Attributes and Classes
okay so this part is all about how the classes and properties are pitched at the right level of abstraction 💅🎀 This doc focuses on the stuff in the datapath that does both DiffServ (aggregate traffic conditioning 🌸) and IntServ (flow-based traffic conditioning ✨). IntServ admission control modeling might show up in a future doc, bestie 🧚
The classes and properties here are meant to be used alongside the QoS policy classes and properties in [QPIM] 💜 Like, say a network admin wants to keep the delay promises made to an end-user 😭 they could write policies that watch queue depths in a device and adjust resource allocations when delay budgets are at risk (maybe because the topology changed 🙈). This document defines the specific services and mechanisms needed to make that happen, and [QPIM] gives the overall structure of the policy that manages and configures the service 🫶
So this low-level spec (this doc) plus the high-level structuring (from [QPIM]) is what lets admins define new network services tied to business goals while still keeping them manageable 🔥 But this only works if policies can actually support different QoS implementations across devices 💀 The fix is to model QoS capabilities at the behavioral level ✨ For datapath traffic conditioning, the model has to support:
- modeling a generic network service that has QoS capabilities 💖
- modeling how the traffic conditioning itself is defined 🦋
- modeling how statistics get gathered to monitor QoS traffic conditioning services 📊 (this bit gets added in a future doc, periodt 💅)
This document models a network service and ties it to one or more QoS mechanisms used to implement it 👑 It also models, in a canonical form, the components used to condition traffic, so both standard and custom traffic conditioning services can be described 🌈
3.5. Characterization of QoS Properties
The QoS properties and classes get the full breakdown in Section 4 🎀 But first we should look at their basic characteristics so we get how to represent them 💜
There are basically two types of properties: state and configuration 🦋 Configuration properties describe the desired state of a device, covering things like desired or proposed thresholds, bandwidth allocations, and how traffic gets classified 💖 State properties describe the actual state of the device 👀 That includes the current operational values of attributes configured through the configuration properties, plus stuff like queue depths, excess capacity consumption, loss rates and so forth ✨
To correlate and use these two types together, they have to be modeled in a common information model 🫶 State and its matching configuration can use the same classes in this model 🌸 The catch is that individual instances need to be named appropriately or placed in different containers, so you can tell current state values apart from desired configuration settings 🙈
State info gets only limited treatment in QDDIM 😭 Right now, only CurrentQueueDepth is proposed as an attribute on QueuingService 💅 Most of the model is about configuration 🍓 So this model is assumed to be a direct memory map into a device 🧚 Every manipulation of model classes and properties directly affects the device's state 👑 If someone wants to use these classes to represent desired configuration too, that's up to the implementor 🌈
It's acknowledged that more properties are needed to fully model current state 💀 But a lot of the properties defined here are exactly the state variables that the configuration properties set, so the configuration properties correspond exactly to state properties 🔥 That means they can model both actual state and desired/proposed configuration ✨
3.6. QoS Information Model Derivation
This raises another question: how do the information specified in the core and QoS policy models ([PCIM], [PCIME], and [QPIM], respectively) fit together with the information defined here? 🤔 Put differently, where should device-independent concepts that lead to device-specific QoS attributes come from? 🎀
Past thinking was that QoS was part of the policy model 🙈 That view isn't completely accurate, and it caused confusion 😭 QoS is a set of services that policy can control 💅 Those services are represented as device mechanisms 🦋 Important point: QoS services, like other services (e.g., security), are provided by the mechanisms inherent in a given device 💖 So not all devices are created equal 💀 For example, two devices might both have a queue, but one could be a simple FIFO queue while the other is much more complex and robust (e.g., class-based weighted fair queuing (CBWFQ)) 🌸 Both can deliver QoS services, and both need to be controlled by policy 🫶 So a device-independent policy can tell devices to queue certain traffic, and a device-specific policy can control the queuing on each device 👑
Also, policy is used to control these mechanisms, not to represent them 🧚 QoS services are implemented with classifiers, meters, markers, droppers, queues, and schedulers ✨ Security is also a characteristic of devices, since authentication and encryption are services networked devices perform (whether or not a policy server is involved) 🔒 These security services may reuse some QoS mechanisms, like filters 💜 But they'll mostly need different mechanisms than QoS does, even though both run on the same devices 🙈
So the similarity between the QoS model and models for other services isn't really about sharing a few common mechanisms 💅 It's about how a device implements each respective service 🍓
That means QoS modeling should live in a networking device schema, not a policy schema 🎀 The device schema can focus on modeling device mechanisms, and the policy schema can focus on the semantics of the policy itself (conditions, actions, operators, etc.) 💖 This document defines an information model for QoS services in a device datapath, and the ultimate goal is to apply policies that control these services on network devices 🌈 The two schemata (device and policy) must be tightly integrated so policy can actually control QoS services 🔥
3.7. Attribute Representation
The last question is how attributes get represented 🦋 If QoS attributes are absolute numbers (e.g., Class AF2 gets 2 Mbs of bandwidth), they're harder to keep uniform across multiple ports in a device or across multiple devices, because link capacities vary a lot 😭 But expressing attributes as relative or proportional terms (e.g., Class AF2 gets 5% of the total link bandwidth) makes certain conditions and actions harder to express, like:
(If ConsumedBandwidth = AssignedBandwidth Then ...)There are really three approaches to this problem 💅
- Multiple properties can express the same value in various forms 🌸 This was rejected because keeping the different properties synchronized is hard (e.g., when one property changes, all the others have to be updated) 🙈
- Multi-modal properties can express the same value in different terms, depending on the access or assignment mode 🎀 This was rejected because it significantly complicates the model and can't be expressed in current directory access protocols (e.g., (L)DAP) 💀
- Properties can be expressed as "absolutes", but the operators in the policy schema need to be more sophisticated 🔥 So to represent a percentage, division and multiplication operators are required (e.g., Class AF2 gets .05 * the total link bandwidth) ✨ This is the approach taken in this document 👑
3.8. Mental Model
The mental model for this schema comes from the work done in the Differentiated Services working group 🧚 It's based on the current versions of the DiffServ Informal Management Model [DSMODEL], the DiffServ MIB [DSMIB], the PIB [PIB], and the set of RFCs that form the basic definition of DiffServ itself ([R2475], [R2474], [R2597], and [R3246]) 💖 A common set of terminology is also available in [POLTERM] 🌈
The model is built around two fundamental class hierarchies, bound together with a set of associations 🦋 Both hierarchies derive from the QoSService and ConditioningService base classes 💜 The associations relate lower-level QoSService subclasses to higher-level QoS services, relate different types of conditioning services together when processing a traffic class, and relate a set of conditioning services to a specific QoS service 🫶 Put together, the associations let us view the device as a set of configurable services that can be combined like modular building blocks to build application-specific services ✨ So this document can model existing and future standard as well as application-specific network QoS services 🎀 💅
3.8.1. The QoSService Class ✨
okay so QoSService is the one that gets to be the main character 👑. Its whole job is to represent higher-level network services that need special conditioning of their traffic. An instance of QoSService (or one of its subclasses) bundles together a group of conditioning services that the system manager sees as all working toward one common goal. So the classifiers, markers, and related conditioning services that give premium service to the "selected" user traffic can all be grouped into one premium QoS service 💅
QoSService has subclasses for different ways of delivering IP services. Right now there are two: FlowService, for flow-oriented QoS delivery, and DiffServService, for DiffServ aggregate-oriented QoS delivery 🎀
QoS services can relate to each other as peers, or one can be subservient to another. The QoSSubService aggregation says that one or more QoSService objects are subservient to a particular QoSService object. This is how you can define Gold Service as a combo of two DiffServ services: one for high-quality traffic treatment, and one for everything else. Each of those DiffServService objects gets its own set of classifiers, markers, and so on, so the high-quality traffic gets EF marking and proper queuing 🍓
DiffServService has its own subclass, AFService. It represents the idea that several related markings in the AF PHB Group work together to provide a single service. If other DiffServ PHB Groups get defined that use more than one code point, they'll probably be good candidates for more DiffServService subclasses 🧚
Technology-specific versions of these services, like the specific use of PHB marking or 802.1Q marking, live in the ConditioningService hierarchy instead of in the QoSService subclasses 🌸
Figure 2 shows all of this. Both of the associations here are aggregations: a QoSService object aggregates the QoSService objects subservient to it, and it also aggregates the ConditioningService objects that actually make it happen. See Section 4 for the class and association definitions 🦋
/\______
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 applied to a traffic stream. That happens on the ingress interface where traffic enters a device, and then on the egress interface where it leaves. It's all done with a set of classes and relationships. The routing decision in the device core, which picks the egress interface a packet will use, is NOT part of this model, so it's not represented here 🙈
There's one base class, ConditioningService, that is the superclass for a whole family of subclasses. Each subclass represents a mechanism that conditions traffic.
These subclasses define device-independent conditioning primitives, including classifiers, meters, markers, droppers, queues, and schedulers. Together they do the conditioning of traffic on an interface. The model turns these services into a shared set of modular building blocks. You can use them no matter what the device implementation is, to model the traffic conditioning going on inside a device 🧩
The different conditioning mechanisms need to connect to each other to show how traffic gets conditioned. There are several important variations on how these services relate:
- A particular ingress or egress interface may not need all the types of ConditioningServices.
- Multiple instances of the same mechanism may be needed on an ingress or egress interface.
- There is no set order for applying the ConditioningServices on an ingress or egress interface.
So this model doesn't force a fixed ordering among the subclasses of ConditioningService. It also doesn't pick a subclass that has to come first or last among the ConditioningServices on an interface. Instead, the model links the various ConditioningService instances on an ingress or egress interface using the NextService, NextServiceAfterMeter, and NextServiceAfterConditioningElement associations. There are also two separate associations, IngressConditioningServiceOnEndpoint and EgressConditioningServiceOnEndpoint. The first ties an ingress interface to its first ConditioningService, and the second ties an egress interface to its last ConditioningService(s) 🫶
3.8.3. Preserving QoS Information from Ingress to Egress 🦋
Here's the big way the QDDIM model is different from [DSMODEL] 👑. In [DSMODEL], traffic moves through a network device in three stages:
- It comes in on an ingress interface, where it may get QoS conditioning.
- It goes through the routing core, where logic outside the scope of QoS decides which egress interface it leaves on.
- It may get more QoS conditioning on the selected egress interface, and then it leaves the device.
In that model, no information about the QoS conditioning a packet got on the ingress interface gets passed along with the packet across the routing core to the egress interface. Lowkey a bummer 😭
QDDIM loosens that rule. It lets information about the treatment a packet received on an ingress interface travel with the packet to the egress interface. (This loosening adds a capability that lots of network devices already have 🌈) QDDIM represents this transfer with a packet preamble, which is how many devices actually do it. Implementations are still free to use other mechanisms to get the same result ✨
+---------+
| Meter-A |
a | | b d
--->| In-|---PM-1--->
| | c e
| Out-|---PM-2--->
+---------+Figure 3: Meter Followed by Two Preamble Markers
Figure 3 is an example where meter results get captured in a packet preamble 🍓. The arrows labeled with single letters are instances of either the NextService association (a, d, and e), or its peer association NextServiceAfterMeter (b and c). PreambleMarker PM-1 adds an indication to the packet preamble that the packet exited Meter A as conforming traffic. PreambleMarker PM-2 does something similar for packets that come through it, adding an indication that they exited Meter A as nonconforming traffic. A PreambleMarker adds its information onto whatever is already in a packet preamble. It does NOT overwrite what's already there 💅
To help different implementations work together, the basic format of the information a PreambleMarker captures is specified. (Implementations are of course free to store this information differently on the inside. This is just how the model represents it 🧚) The information is stored as an ordered, multi-valued string property called FilterItemList. Each individual value looks like "<type>,<value>". When a PreambleMarker "appends" its information to what's already in a packet preamble, it adds new items in that format to the end of the list 🎀
QDDIM provides a limited set of <type> values that a PreambleMarker may use:
- ConformingFromMeter: the value is the name of the meter.
- PartConformingFromMeter: the value is the name of the meter.
- NonConformingFromMeter: the value is the name of the meter.
- VlanId: the value is the virtual LAN identifier (VLAN ID).
Implementations may recognize other <type> values in addition to these. If collisions between implementation-specific <type> values turn into a problem, a future revision of this document might make <type> values an IANA-administered range 🌸
To use the information a PreambleMarker stores in a packet preamble, there's a specific subclass called PreambleFilter, of FilterEntryBase. It matches on the "<type>,<value>" strings. To make life easier when a device has just one level of metering but different individual meters on each ingress interface, PreambleFilter lets you use a wildcard "any" for the <value> part of the three meter-related filters. With that wildcard, an administrator can set up a Classifier that picks every packet found to be conforming (or partially conforming, or nonconforming) by its respective meters. They don't have to name each meter in a separate ClassifierElement 🙌
Once a meter result is stored in a packet preamble, any later Classifier can use it. So even though this capability is motivated by carrying QoS conditioning information from an ingress interface to an egress interface, a prior meter result can also be used to classify packets later in the datapath, on the same interface where the meter is 🦋
3.9. Classifiers, FilterLists, and Filter Entries 🎀
okay so this doc uses a bunch of classes to model the classifiers from [DSMODEL] 💅: ClassifierService, ClassifierElement, FilterList, FilterEntryBase, and a bunch of subclasses of FilterEntryBase. There are also two associations, ClassifierElementUsesFilterList and EntriesInFilterList. And the QDDIM model doesn't use CIM's FilterEntry class at all 🙈
In [DSMODEL], one traffic stream comes into a classifier and gets split into multiple streams going out. Which output stream a packet lands in depends on which of an ordered set of filters it matches first 🦋 A filter can match a field in the packet itself, or maybe some other attribute attached to the packet. With a multi-field (MF) classifier, packets get sorted using the contents of several header fields at once. Like, an MF classifier might sort packets by their whole IP-addressing 5-tuple, which is giving main character energy 👑
To keep MF classifiers efficient, there are subclasses of FilterEntryBase that let you pack several related header fields into one object ✨ Those are IPHeaderFilter and 8021Filter. With IPHeaderFilter, for instance, you can describe matching on all five IP 5-tuple fields plus the DiffServ DSCP using a FilterList that holds just one IPHeaderFilter object 🧚 These two classes (and the abstract FilterEntryBase) are actually defined in the more general document [PCIME] instead of here, because they're useful for way more than this doc covers 💜
The FilterList object is always needed, even when it only has one filter entry (so one FilterEntryBase subclass object) 💀 That's because a ClassifierElement can only be tied to a FilterList, never to an individual FilterEntry. FilterList is also defined in [PCIME] 🌸
The EntriesInFilterList aggregation (also defined in [PCIME]) has a property called EntrySequence. Back in the CIM days, that could be used to set an evaluation order on the filter entries in a FilterList. But now EntrySequence only supports one value: '0' 😭 That value means the FilterEntries are ANDed together to decide whether a packet matches the MF selector the FilterList stands for.
A ClassifierElement is the starting point for a specific policy or data path 🍓 Each ClassifierElement uses the NextServiceAfterClassifierElement association to figure out which conditioning service to apply next to packets.
A ClassifierService is a grouping of ClassifierElements 🫶 Sometimes a ClassifierService is actually an aggregation of other ClassifierServices, and that's iconic. One practical example: each ClassifierService holds a group of policies for one particular application, and another ClassifierService groups those application-specific ClassifierService instances. The app-specific ones only get written out once, and then you make the unique combinations you need using other ClassifierService instances 🔥 A ClassifierService that groups other ClassifierService instances may not specify a FilterList using the ClassifierElementUsesFilterList association. This special use is just a classifier-collecting function, nothing more 🌈
3.10. Modeling of Droppers 💧
In [DSMODEL], there's a difference between absolute droppers and algorithmic droppers 🦋 In QDDIM, both types are modeled with the DropperService class, or with one of its subclasses. In both cases, the queue a dropper drops packets from is tied to the dropper by an instance of the NextService association. The dropper always plays the PrecedingService role in these associations, and the queue always plays the FollowingService role. There's always exactly one queue that a dropper drops packets from 💅
An absolute dropper drops every packet in its queue, so it doesn't need any configuration beyond a NextService tie to that queue 💖 An algorithmic dropper, though, needs more configuration:
- a specific drop algorithm;
- parameters for the algorithm (for example, token bucket size);
- the source(s) of input(s) to the algorithm;
- possibly per-input parameters for the algorithm.
The first two of these are represented by properties of the DropperService class, or properties of one of its subclasses. The last two involve additional classes and associations 🎀
3.10.1. Configuring Head and Tail Droppers 🌸
The HeadTailDropQueueBinding is the association that identifies the inputs to the algorithm a tail dropper runs 🧚 It isn't used for a head dropper, because a head dropper always has exactly one input to its drop algorithm, and that input is always the queue it drops packets from. For a tail dropper, this association is defined with a many-to-many cardinality. There are two distinct cases, though 👑
One dropper bound to many queues: this is when the drop algorithm for the dropper takes inputs from more than one queue. The dropper still only drops from one queue, the one it's tied to through a NextService association. But the drop decision can be influenced by the state of several queues 🔥 For the classes HeadTailDropper and HeadTailDropQueueBinding, the rule for combining the multiple inputs is simple addition: if the sum of the lengths of the monitored queues goes over the dropper's QueueThreshold value, then packets get dropped. A subclass of one or both of these classes can override this combining rule with a different one 💜
One queue bound to many droppers: this is when the state of one queue (which is usually also the queue packets get dropped from) feeds into multiple droppers' drop algorithms 🦋 A use case here is a classifier that splits a traffic stream into, say, four parts, representing four classes of traffic. Each part goes through its own HeadTailDropper, and then they all get re-merged onto the same queue. The result is one queue holding packets of four traffic types, with drop thresholds like these:
- Class 1 - 90% full
- Class 2 - 80% full
- Class 3 - 70% full
- Class 4 - 50% full
Here, the percentages are about the queue's overall state 🌈 With this setup, when the queue hits 50% full, Class 4 packets get dropped instead of joining the queue. When it hits 70% full, Class 3 and 4 packets get dropped, and so on 😭
The two cases above can also happen together, if one dropper gets inputs from multiple queues and one or more of those queues are also feeding other droppers 🫶
3.10.2. Configuring RED Droppers ✨
Like a tail dropper, a RED dropper (represented by an instance of the REDDropperService class) can take the states of multiple queues as its inputs 💅 But here there's an extra step: each of those inputs can be smoothed before the RED dropper uses it, and the smoothing process itself must be parameterized 🌸 So, on top of REDDropperService and QueuingService, there's a third class, DropThresholdCalculationService, which represents the per-queue parameterization of that smoothing 🧚
Here's an instance diagram showing how these classes work together:
RDSvc-A
| | |
+-----+ | +-----+
| | |
DTCS-1 DTCS-2 DTCS-3
| | |
Q-1 Q-2 Q-3Figure 4. Inputs for a RED Dropper
So REDDropperService-A (RDSvc-A) is using inputs from three queues to make its drop decision 🦋 (As always, RDSvc-A is linked to the queue it drops packets from via the NextService association.) For each of those three queues, there's a DropThresholdCalculationService (DTCS) instance that represents the smoothing weight and time interval to use when looking at that queue. So each DTCS instance is tied to exactly one queue, although a single queue can be examined (with different weight and time values) by multiple DTCS instances. Also, a DTCS instance and the queue behind it can be thought of as a "unit of reusability" 💖 So a single DTCS can be referred to by multiple RDSvcs 👑
Unless a subclass of REDDropperService overrides it with a different rule, the rule a RED dropper uses to combine the smoothed inputs from the DTCSs into one value for its drop decision is simple addition 🔥
3.11. Modeling of Queues and Schedulers 🌈
To really get why this scheduling model is so complicated, we have to look at how complicated schedulers themselves are 🙈 There are wild variations in algorithms and implementations, and even though those variations are broad, we picked out four examples to test the model and prove its complexity is worth it 🫶💅
3.11.1. Simple Hierarchical Scheduler
okay so a simple hierarchical scheduler has a few vibes 💅 first, when a scheduling opportunity gets handed to a set of queues, ONE viable queue gets picked based on some criteria, like bandwidth or priority 🎀 then the output of that scheduler becomes the input to another scheduler, and that second one treats the first scheduler (and all its queues) as a single logical queue 🦋 so if the first scheduler picked the right packet based on a priority on each queue, the second scheduler could slap a bandwidth limit or allocation on the entire group of queues the first one handled 😭✨
+----------+ NextService
|QueuingSvc+----------------------------------------------+
| Name=EF1 | |
| | QueueTo +--------------+ ElementSched |
| +------------+PrioritySched +---------------+ |
+----------+ Schedule |Element | Service | |
| Name=EF1-Pri | | v
| Priority=1 | +-----------+-+-+
+--------------+ |SchedulingSvc +
| Name=PriSched1+
+--------------+ +----------+--+-+
|PrioritySched | ElementSched | ^
+----------+ |Element +---------------+ |
|QueuingSvc| QueueTo | Name=AF1x-Pri| Service |
| Name=AF1x+------------+ Priority=2 | |
| | Schedule +--------------+ |
| | NextService |
| +----------------------------------------------+
+----------+
:
+---------------+ NextScheduler
|SchedulingSvc +--------------------------------------------+
| Name=PriSched1| |
+-------+-------+ +--------------------+ElementSchedSvc|
| SchedToSched |AllocationScheduling+--------+ |
+---------------+Element | | |
| Name=PriSched1-Band| | |
| Units=Bytes | | v
| Bandwidth=100 | +------+------+--+
+--------------------+ |SchedulingSvc |
| Name=BandSched1|
+--------------------+ +------+------+--+
|AllocationScheduling| | ^
+---------------+ |Element +--------+ |
|QueuingService | | Name=BE-Band |ElementSchedSvc|
| Name=BE |QueueTo+ Units=Bytes | |
| |-------+ Bandwidth=50 | |
| |Sched +--------------------+ |
| | NextService |
| +--------------------------------------------+
+---------------+Figure 5. Example 1: Simple Hierarchical Scheduler
Figure 5 walks through the example and shows how it gets instantiated using the model 🧚 In the figure, NextService tells you the first scheduler after the queue, and NextScheduler tells you the order the schedulers run in after that 🌸 The ElementSchedulingService association is the one that decides which set of scheduling parameters a specific scheduler uses 💜 Those parameters can be bound to either queues or schedulers. For the SchedulingElement EF1-Pri, the binding goes to a queue, so the QueueToSchedule association gets used. For the SchedulingElement PriSched1-Band, the binding goes to another scheduler, so the SchedulerToSchedule association is used instead 🦋 Also, due to space limits in the document, the SchedulingService PRISched1 shows up twice so we can see how it connects to everything else 🙈
3.11.2. Complex Hierarchical Scheduler
okay this one is giving main character energy 👑 a complex hierarchical scheduler has all the same characteristics as a simple one, EXCEPT the criteria for the second scheduler get decided per queue instead of on an aggregate basis 🍓 a super common scenario is a set of bounded priority schedulers. Each queue gets a relative priority, but each queue is ALSO not allowed to go over a bandwidth allocation that's unique to that particular queue 😭 so to make this work, the queue has to be bound to two separate schedulers 💅
Figure 6 shows this situation. It describes an EF queue and a best effort (BE) queue that both point to a priority scheduler through the NextService association 🎀 The NextScheduler association between that priority scheduler and the bandwidth scheduler then defines the ordering of the scheduling hierarchy ✨ Each scheduler also has its own distinct set of scheduling parameters that get bound back to each queue. This is exactly why we need to support two or more parameter sets on a per queue basis 🌈
+----------------+
|QueuingService |
| Name=EF |
| |QueueTo +----------------+ElementSchedSvc
| +----------+AllocationSched +--------+
++---+-----------+Schedule |Element | |
| | | Name=BandEF | |
| |QueueTo | Units=Bytes | |
| |Schedule | Bandwidth=100 | |
| | +----------------+ +------+---------+
| | |SchedulingSvc |
| | +------------------+ | Name=BandSched |
| +------+PriorityScheduling| +------------+--++
| |Element | ^ |
| | Name=PriEF |ElementSchedSvc | |
| | Priority=1 +---------------------+ | |
| +------------------+ | | |
|NextService | | |
+-------------------------------------------------+ | | |
| | | |
NextService | | | |
+-----------------------------------------------+ | | | |
| | | | | |
| +------------------+ElementSchedSvc | | | | |
| |PriorityScheduling+--------+ | | | | |
| |Element | | | | | | |
| | Name=PriBE | | v v | | |
| +------+ Priority=2 | +---+--------+-+-+-+Next| |
| | +------------------+ |SchedulingService +----+ |
| | | Name=PriSched |Sched |
| | +------------------+ |
| |QueueTo |
| |Schedule +----------------+ |
| | |AllocationSched |ElementSchedSvc |
+----+---------+ |Element +-----------------+
|QueuingService|QueueTo | Name=BandBE |
| Name=BE +------------+ Units=Bytes |
| |Schedule | Bandwidth=50 |
| | +----------------+
+--------------+Figure 6. Example 2: Complex Hierarchical Scheduler
3.11.3. Excess Capacity Scheduler ✨
okay so the excess capacity scheduler is giving "two scheduling parameter sets per queue," just like the last one 💅 but the reason is a little different this time. Imagine a bunch of queues that each got a bandwidth limit so no traffic class can starve out another one 🫶. The tea is that one or more queues can hit their limit while the queues that deserve a turn are totally empty 😭
So the big question is: who gets that idle bandwidth? The rules for handing out excess capacity could be completely different from the rules for normal allocation when everything is busy 🙈 You could handle that with a scheduling hierarchy, but there's a catch. The criteria for using the next scheduler are different from the last two cases. The next scheduler should only get used if there's a scheduling opportunity that the prior scheduler walked past 🍓
When a scheduler decides to skip a scheduling decision, it's acting as a non-work conserving scheduler 🦋 A work conserving scheduler always grabs an opportunity, no matter which queue it's serving or how much bandwidth that queue has already used 💜 Here's the iconic insight: a non-work conserving scheduler works just like a meter 🔥 If a packet is in profile, it gets the scheduling opportunity. If it's out of profile, it doesn't. BUT meters also have rules for what happens next, depending on whether the packet is in or out of profile. So a non-work conserving scheduler also needs a way to pick the next scheduler when it chooses not to use an opportunity ✨
Figure 7 shows this exact situation 👑 It looks super similar to Figure 6, except the allocation scheduler and the WRR scheduler are linked with a FailNextScheduler association 🌸 That association basically says the WRR scheduler only gets used when there are non-empty queues that the allocation scheduler turned away 🧚 Also, heads up: Figure 7 isn't the full picture. Usually there would be several more queues bound to an allocation scheduler and a WRR scheduler 💖
+------------+
|QueuingSvc |
| Name=EF |
| |
| |
++-+---------+
| |
| |QueueTo
| |Schedule +--------------+
| | |SchedulingSvc |
| | +------------------+ | Name=WRRSched|
| +------+AllocationSched | +----------+-+-+
| |Element | ^ |
| | Name=BandEF |ElementSchedSvc | |
| | Units=Bytes +--------------------+ | |
| | Bandwidth=100 | | | |
| +------------------+ | | |
|NextService | | |
+----------------------------------------------+ | | |
| | | |
NextService | | | |
+--------------------------------------------+ | | | |
| | | | | |
| +------------------+ElementSchedSvc | | | | |
| |AllocationSched +--------+ | | | | |
| |Element | | | | | | |
| | Name=BandwidthAF1| | | | | | |
| | Units=Bytes | | v v | | |
| +------+ Bandwidth=50 | +--+----------+-+-++FailNext| |
| | +------------------+ |SchedulingService +--------+ |
| |QueueTo | Name=BandSched |Scheduler |
| |Schedule +------------------+ |
| | |
| | +---------------------+ |
++-+-----------+ | WRRSchedulingElement| |
|QueuingService|QueueTo | Name=WRRBE +------------+
| Name=BE +-----------+ Weight=30 |ElementSchedSvc
+--------------+Schedule +---------------------+Figure 7. Example 3: Excess Capacity Scheduler
3.11.4. Hierarchical CBQ Scheduler 🧁
Hierarchical class-based queuing (CBQ) is the fourth scenario on our list, and it's a whole vibe 🌈 Each queue gets its own specific bandwidth allocation. Then queues get grouped together into a logical scheduler, and that logical scheduler's aggregate bandwidth allocation equals the sum of the queues it schedules 💅 Logical schedulers can also be grouped into even higher-level logical schedulers, like a family tree 🌳
If you look at it top down, the top-most logical scheduler has 100% of the link capacity ⭐ That gets split up among the logical schedulers underneath, so the sum of those allocations equals 100%. The second-tier schedulers can split their own allocations across a third tier, and so on, until you hit the bottom tier. That bottom tier divides its allocations among specific queues that represent pretty fine-grained traffic classes 🫶
The unique part of hierarchical CBQ is this: when a specific allocation doesn't have enough bandwidth, the schedulers higher up the tree get checked to see if some other part of the tree has spare capacity 🔥 Literally borrowing from your neighbors, but make it networking 💀
Figure 8 shows this with two tiers 🦋 The example gets split in half because of space limits, so the CBQTier1 scheduling service instance shows up twice. The top tier's total allocation is 50 Mb. The voice allocation is 22 Mb, and the remaining 23 Mb gets split between FTP and Web 🍓 Now say Web traffic is actually using 20 Mb, which is 5 Mb over its allocation, and FTP is using 5 Mb. The CBQTier1 scheduler can offer 3Mb of its allocation to the Web traffic 🌸 But that's not enough, so the FailNextScheduler association has to be traversed to check whether the voice class has any excess capacity to spare 🧚 If voice is only using 15 Mb of its 22 Mb allocation, there are enough resources to let the web traffic through 🎀
Quick note on why FailNextScheduler is the association used here: the CBQTier1 scheduler actually failed to schedule a packet because it ran out of resources 💜 A variant of hierarchical CBQ could also allow a hierarchy for successful scheduling, which is conceivable, so both associations are necessary 👑
Because of space constraints in the document, the SchedulingService CBQTier1 appears twice so it's still shown connected to all the other objects 🙈
+-----------+ NextService
|QueuingSvc +-------------------------------------------+
| Name=Web | |
| |QueueTo+----------------+ ElementSchedSvc |
| +-------+AllocationSched +----------------+ |
+-----------+Sched |Element | | |
| Name=Web-Alloc | | v
| Bandwidth=15 | +-----------+-+-+
+----------------+ |SchedulingSvc +
| Name=CBQTier1 +
+----------------+ +-----------+-+-+
|AllocationSched | ElementSchedSvc| ^
+-----------+ |Element +----------------+ |
|QueuingSvc |QueueTo| Name=FTP-Alloc | |
| Name=FTP +-------+ Bandwidth=8 | |
| |Sched +----------------+ |
| | NextService |
| +-------------------------------------------+
+-----------+
:
+---------------+ FailNextScheduler
|SchedulingSvc +---------------------------------------------+
| Name=CBQTier1 | |
+-------+-------+ +---------------------+ElementSchedSvc|
| SchedToSched |AllocationScheduling +--------+ |
+---------------+Element | | |
| Name=LowPri-Alloc | | |
| Bandwidth=23 | | v
+---------------------+ +-----+------+-+
|SchedulingSvc |
| Name=CBQTop |
+---------------------+ +----------+-+-+
|AllocationScheduling |ElementSchedSvc | ^
+------------+ |Element +----------------+ |
|QueuingSvc |QueueTo| Name=BE-Band | |
| Name=Voice +-------+ Bandwidth=22 | |
| |Sched +---------------------+ |
| | NextService |
| +------------------------------------------------+
+------------+Figure 8. Example 4: Hierarchical CBQ Scheduler
4. The Class Hierarchy ✨
okay now we're entering the class hierarchy era 🎀 The next sections lay out the class and association hierarchies that together make up the information model for modeling QoS capabilities at the device level 💖 Basically, this is the blueprint everything else is built on, so buckle up bestie 🫶
4.1. Associations and Aggregations ✨
Okay so associations and aggregations are how we show that two objects are connected, and bestie, there can be more than two in theory 🦋 Dependency, aggregation, and friends are all modeled as classes that hold two (or more) object references. Aggregations are a special kind of connection, because they represent either a "whole-part" or a "collection" relationship. Like, an aggregation can show how a system contains the components that make it up 🧩
Since associations and aggregations are classes, they get all the object-oriented perks that regular classes get 💅 They can hold properties and methods, and inheritance can make them more specific versions of their superclasses. Iconic behavior, honestly.
Here's the important bit 👑 An association (or aggregation) object is treated as one atomic unit, even though it connects or collects several objects. That's what makes it special. The objects it links still have their own identities, but the association or aggregation built out of them gets its own identity and name too, which is so main character energy 🎀
Also, associations and aggregations form their own inheritance hierarchy, separate from the regular class inheritance hierarchy 🌸 They're usually bi-directional, but nothing stops anyone from defining higher-order associations or aggregations. Ngl, those get messy fast to define, understand, and use. In practice, anything higher than binary is rarely used, because it's so much more complicated and not very general 💀 Every association and aggregation defined in this model is binary, so we're keeping it simple 🫶
Quick reminder: by definition, associations and aggregations can't be unary 🙈
Last thing, and it matters a lot 🔥 Associations and aggregations between two classes don't change the classes themselves. Adding or deleting one doesn't touch the interfaces of the classes it connects. Iykyk, it's giving clean architecture 💜
4.2. The Structure of the Class Hierarchies 🌈
Okay, so here's how the class, association, and aggregation inheritance hierarchies are laid out for managing the datapaths of QoS devices. They're shown in Figure 9, Figure 10, and Figure 11, in that order 🧚 The (CIMCORE) tag means a class from the CIM Core model, so if you want the definitions, go check [CIM] 📚 The [PCIME] tag works the same way, but it's a class from the Policy Core Information Model Extensions document. That model was influenced by [CIM] and is compatible with the Directory Enabled Networks (DEN) effort, which is a very cute bonus 🍓
+--ManagedElement (CIMCORE)
|
+--ManagedSystemElement (CIMCORE)
| |
| +--LogicalElement (CIMCORE)
| |
| +--Service (CIMCORE)
| | |
| | +--ConditioningService
| | | |
| | | +--ClassifierService
| | | | |
| | | | +--ClassifierElement
| | | |
| | | +--MeterService
| | | | |
| | | | +--AverageRateMeterService
| | | | |
| | | | +--EWMAMeterService
| | | | |
| | | | +--TokenBucketMeterService
| | | |
| | | +--MarkerService
| | | | |
| | | | +--PreambleMarkerService
| | | | |
| | | | +--TOSMarkerService
| | | | |
| | | | +--DSCPMarkerService
| | | | |
(continued from previous page;
the first four elements are repeated for convenience)
+--ManagedElement (CIMCORE)
|
+--ManagedSystemElement (CIMCORE)
| |
| +--LogicalElement (CIMCORE)
| |
| +--Service (CIMCORE)
| | | | +--8021QMarkerService
| | | |
| | | +--DropperService
| | | | |
| | | | +--HeadTailDropperService
| | | | |
| | | | +--RedDropperService
| | | |
| | | +--QueuingService
| | | |
| | | +--PacketSchedulingService
| | | |
| | | +--NonWorkConservingSchedulingService
| | |
| | +--QoSService
| | | |
| | | +--DiffServService
| | | | |
| | | | +--AFService
| | | |
| | | +--FlowService
| | |
| | +--DropThresholdCalculationService
| |
| +--FilterEntryBase [PCIME]
| | |
| | +--IPHeaderFilter [PCIME]
| | |
| | +--8021Filter [PCIME]
| | |
| | +--PreambleFilter
| |
| +--FilterList [PCIME]
| |
| +--ServiceAccessPoint (CIMCORE)
| |
| +--ProtocolEndpoint
(continued from previous page;
the first four elements are repeated for convenience)
+--ManagedElement (CIMCORE)
|
+--ManagedSystemElement (CIMCORE)
| |
| +--LogicalElement (CIMCORE)
| |
| +--Service (CIMCORE)
|
+--Collection (CIMCORE)
| |
| +--CollectionOfMSEs (CIMCORE)
| |
| +--BufferPool
|
+--SchedulingElement
|
+--AllocationSchedulingElement
|
+--WRRSchedulingElement
|
+--PrioritySchedulingElement
|
+--BoundedPrioritySchedulingElementFigure 9. Class Inheritance Hierarchy
Next up, the association hierarchy, which is shown in Figure 10 💖
+--Dependency (CIMCORE)
| |
| +--ServiceSAPDependency (CIMCORE)
| | |
| | +--IngressConditioningServiceOnEndpoint
| | |
| | +--EgressConditioningServiceOnEndpoint
| |
| +--HeadTailDropQueueBinding
| |
| +--CalculationBasedOnQueue
| |
| +--ProvidesServiceToElement (CIMCORE)
| | |
| | +--ServiceServiceDependency (CIMCORE)
| | |
| | +--CalculationServiceForDropper
| |
| +--QueueAllocation
| |
| +--ClassifierElementUsesFilterList
|
+--AFRelatedServices
|
+--NextService
| |
| +--NextServiceAfterClassifierElement
| |
| +--NextScheduler
| |
| +--FailNextScheduler
|
+--NextServiceAfterMeter
|
+--QueueToSchedule
|
+--SchedulingServiceToScheduleFigure 10. Association Class Inheritance Hierarchy
And last but not least, the aggregation hierarchy, which is shown in Figure 11 🦋
+--MemberOfCollection (CIMCORE)
| |
| +--CollectedBufferPool
|
+--Component (CIMCORE)
| |
| +--ServiceComponent (CIMCORE)
| | |
| | +--QoSSubService
| | |
| | +--QoSConditioningSubService
| | |
| | +--ClassifierElementInClassifierService
| |
| +--EntriesInFilterList [PCIME]
|
+--ElementInSchedulingServiceFigure 11. Aggregation Class Inheritance Hierarchy
4.3. Class Definitions 🎀
This section is the main event 💅 It presents the classes and properties that make up the Information Model for describing QoS-related functionality in network devices, including hosts. These definitions come from the CIM Core model [CIM]. Only the QoS-related classes are defined in this document, but other classes from the CIM Core model, as well as from [PCIME], get a quick briefing too. Definitely go read [CIM] and [PCIME] for the full story 📚 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's the root of the entire class inheritance hierarchy in CIM, so it's basically the queen 👑 Two associations that refer to it are subclassed in this document: Dependency, and MemberOfCollection, which is an aggregation. ManagedElement's properties are Caption and Description. Both are free-form strings used to describe an instantiated object. For the full definition, check [CIM] 🫶
4.3.2. The Abstract Class ManagedSystemElement ✨
This is an abstract class defined in the Core Model of CIM. It's a subclass of ManagedElement 🧚 ManagedSystemElement is the base class for the PhysicalElement and LogicalElement class hierarchies. LogicalElement, in turn, is the base class for a bunch of important CIM hierarchies, including System. Any distinguishable component of a System is a candidate for this class hierarchy, whether it's physical (like chips and cards) or logical (like software components, services, and other objects) 🔥
None of the associations this class participates in is used directly in the QoS device state model. But 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 💜
For the full definition of this class, see [CIM] 🫶
4.3.3. The Abstract Class LogicalElement 🌈
This is an abstract class defined in the Core Model of CIM. It's a subclass of the ManagedSystemElement class, and it's 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 this class participates in 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's a subclass of the LogicalElement class, and it's the base class for all objects that represent a "service" or functionality in a System 💅 A Service is a general-purpose object 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 ✨
okay bestie, ConditioningService is a concrete subclass of the CIM Core class Service 💅 and it's basically the vibe for how traffic gets conditioned on the data-forwarding path of a device 🌸. The subclasses are where the actual conditioning types live. This document defines six fundamental types: classifier, meter, marker, dropper, queue, and scheduler 🎀. More sophisticated types might show up in future documents ✨.
ConditioningService is concrete because, when it was defined in CIM, its superclass was concrete 🧚. You can instantiate it, but an instance would not accomplish anything 🙈. The nature of the conditioning, and the parameters that control it, are only specified in the subclasses.
Two associations matter most for QoS: QoSConditioningSubService and NextService 👑. QoSConditioningSubService aggregates ConditioningServices into a particular QoS service (such as AF) to describe the specific conditioning that underlies that QoS service on a particular device. NextService tells you 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 representing a logical entity in an ingress or egress interface of a device 💖. It 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 packet contents, or possibly on other attributes associated with the packet. Each output stream is the result of matching a particular filter ✨.
QDDIM's take on classifiers is closely related to [DSMIB] and [DSMODEL] 🍓. Instead of linking a classifier directly to its FilterLists, it's modeled as an aggregation of ClassifierElements. Each ClassifierElement is then linked to a single FilterList, using the association ClassifierElementUsesFilterList 💅.
A Classifier is modeled as a subclass of ConditioningService so that it can be aggregated into a QoSService (using the QoSConditioningSubService aggregation) 🎀. It can also use the NextService association to identify the subsequent ConditioningService objects for the different traffic streams ✨.
ClassifierService is designed for hierarchical classification 👑. When that's in use, a ClassifierElement may point to another ClassifierService. When it's used this way, the ClassifierElement must not use the ClassifierElementUsesFilterList association 🙈.
The class definition is as follows:
NAME ClassifierService
DESCRIPTION A concrete class describing how an input
traffic stream is sorted into multiple
output streams using one or more
filters.
DERIVED FROM ConditioningService
TYPE Concrete
PROPERTIES (none)4.3.7. The Class ClassifierElement 🦋
The concept of a ClassifierElement comes from [DSMIB] 🌸. This concrete class is the linkage, inside a single ClassifierService, between a FilterList (the criteria for picking packets out of the stream coming into the ClassifierService) and the next ConditioningService that the selected packets go to after they leave the ClassifierService 💜. ClassifierElement has no properties of its own. It exists to anchor an aggregation with its classifier, and to hold associations with its FilterList and its next ConditioningService 🧚.
When a ClassifierElement is associated with a ClassifierService through the NextServiceAfterClassifierElement association, the ClassifierElement may not use the ClassifierElementUsesFilterList association 💅. Also, once a ClassifierElement is associated with a ClassifierService like this, the order of processing is a function of the ClassifierOrder property of the ClassifierElementInClassifierService aggregation 🫶.
Here's an example, because it's easier to see it in action 🎀. Let's assume the following:
- ClassifierService (C1) aggregates ClassifierElements (E1), (E2) and (E3), with relative ClassifierOrder values of 1, 2, and 3.
- ClassifierElements (E1) and (E3) associate to FilterLists (F1) and (F3) respectively, using the ClassifierElementUsesFilterList association.
- (E1) and (E3) are associated with Meters (M1) and (M3) through their respective NextServiceAfterClassifierElement associations.
- (E2) is associated with ClassifierService (C2) through its NextServiceAfterClassifierElement association.
- ClassifierService (C2) aggregates ClassifierElements (E4) and (E5) with relative ClassifierOrder values of 1 and 2.
- ClassifierElements (E4) and (E5) have associations to FilterLists (F4) and (F5) respectively, using the ClassifierElementUsesFilterList association.
In this example, packet processing would match FilterLists in the order (F1), (F4), (F5), and (F3) 😭✨.
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 representing the metering of network traffic 🌈. Metering is the function of monitoring the arrival times of packets in a traffic stream, and figuring out how well each packet conforms to a pre-established traffic profile 📏. A meter can invoke different ConditioningServices for conforming and non-conforming traffic 🔥. Traffic leaving a meter may be further conditioned (for example, dropped or queued) by routing the packet to another conditioning element 🫶. For more on metering, see [DSMODEL] 📚.
This class is the base class for defining different types of meters, so it holds the common properties that all meter subclasses share 👑. It's modeled as a ConditioningService so it can be aggregated into a QoSService (using the QoSConditioningSubService association), showing that its functionality underlies that QoS service 🎀. MeterService also takes part in the NextServiceAfterMeter association, which identifies the subsequent ConditioningService objects for conforming and non-conforming traffic 🦋.
The class definition is as follows:
NAME MeterService
DESCRIPTION A concrete class describing the
monitoring of traffic with respect to a
pre-established traffic profile.
DERIVED FROM ConditioningService
TYPE Concrete
PROPERTIES MeterType, OtherMeterType,
ConformanceLevelsNote: The MeterType property and the MeterService subclasses give similar info 👀. The MeterType property is there for query purposes and future expansion. Not every MeterService will need a subclass to define it. In those cases, MeterService gets instantiated directly, and the MeterType property is the only way to identify the type of the meter 🙈.
4.3.8.1. The Property MeterType
This property is an enumerated 16-bit unsigned integer 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 - Token Bucket MeterNote: if the value of MeterType is not one of these four values, it SHOULD be interpreted as if it had the value '1' (Other) 🧚.
4.3.8.2. The Property OtherMeterType
This is a string property that defines a vendor-specific description of a type of meter 💅. It's used when the value of the MeterType property in the instance is equal to 1 ✨.
4.3.8.3. The Property ConformanceLevels
This property 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 AverageRateMeterService 🍓
This is a concrete subclass of MeterService representing a simple meter, called an Average Rate Meter 💖. It measures the average rate at which packets are submitted to it over a specified time ⏱️. Packets are conformant if their average arrival rate does not exceed the specified measuring rate of the meter. Any packet that causes the specified measuring rate to be exceeded is non-conforming 🙈. For more info, see [DSMODEL] 📚.
The class definition is as follows:
NAME AverageRateMeterService
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, DeltaInterval4.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 EWMAMeterService 🦋
This is a concrete subclass of the MeterService class, representing an exponentially weighted moving average meter 🌈. It's 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 non-conforming 😤. For more, see [DSMODEL] 💜.
The class definition is as follows:
NAME EWMAMeterService
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, Gain4.3.10.1. The Property AverageRate ✨
okay so this one is an unsigned 32-bit integer 🎀 it's the average rate that the sampled arrival rate of packets gets measured against. if a packet pushes the sampled rate over this number, it's deemed non-conforming 💀 and the value is in kilobits per second.
4.3.10.2. The Property DeltaInterval 🦋
this is an unsigned 64-bit integer that sets the sampling interval used to measure the arrival rate. the calculated rate gets averaged over this interval and then checked against the AverageRate property. all packets whose computed average arrival rate is less than the AverageRate are deemed conforming 🫶
the value is in microseconds ⏱️
4.3.10.3. The Property Gain 🌸
this is an unsigned 32-bit integer that's the reciprocal of the time constant (e.g., frequency response) of what is basically a simple low-pass filter 🧚 so for example, the value 64 for this property means a time constant of 1/64. iykyk 💅
4.3.11. The Class TokenBucketMeterService 🪣
this is a concrete subclass of the MeterService class that represents metering network traffic with a token bucket meter. two kinds of token bucket meters get 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 it has two conformance levels: "conforming" and "non-conforming" 🍓 this class also defines an excess burst size, which lets the meter have three conformance levels ("conforming", "partially conforming", and "non-conforming") ✨ in that 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. the operation of these meters is described in [DSMODEL] 📚
the class definition goes like this:
NAME TokenBucketMeterService
DESCRIPTION A concrete class classifying admitted
traffic with respect to a token bucket.
Either two or three levels of
conformance can be defined.
DERIVED FROM MeterService
TYPE Concrete
PROPERTIES AverageRate, PeakRate,
BurstSize, ExcessBurstSize4.3.11.1. The Property AverageRate 💖
this 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 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 is an unsigned 32-bit integer that specifies the maximum number of tokens available for the committed rate (the one set by the AverageRate property). the value is expressed in kilobytes 💜
4.3.11.4. The Property ExcessBurstSize 🌙
this is an unsigned 32-bit integer that specifies the maximum number of tokens available for the peak rate (the one set 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 pick out the particular fields to be marked, and they bring in properties for the values used to do the marking 🎨 markers are usually invoked because of a preceding classifier match. the operation of markers of various types is described in [DSMODEL] 💅
MarkerService is a concrete class because, when it was defined in CIM, its superclass was concrete 🤓 even though this class can be instantiated, an instance of it wouldn't accomplish anything, because both the field to be marked and the value to use for marking it only get specified in subclasses of MarkerService 💀
MarkerService is modeled as a ConditioningService so it can be aggregated into a QoSService (using the QoSConditioningSubService association) to show that its functionality underlies that QoS service 🫶 it also takes part in the NextService association to identify the next ConditioningService object that acts on traffic after the marker has marked it ✨
the class definition goes like this:
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 storing traffic-conditioning results in a packet preamble. see Section 3.8.3 for a discussion of how, and why, QDDIM models the capability to store these results in a packet preamble 📖 an instance of PreambleMarkerService appends a two-part string of the form "<type>,<value>" to a packet preamble. Section 3.8.3 has the list of <type> strings defined by QDDIM. implementations may support other <type>'s on top of those 🌷
the class definition goes like this:
NAME PreambleMarkerService
DESCRIPTION A concrete class representing the
saving of traffic-conditioning
results in a packet preamble.
DERIVED FROM MarkerService
TYPE Concrete
PROPERTIES FilterItemList[ ]4.3.13.1. The Multi-valued Property FilterItemList 📝
this property is an ordered list of strings, where each string has the format "<type>,<value>" 🪄 see Section 3.8.3 for the list of <type>'s defined in QDDIM, and the nature of the associated <value> for each of these types 💫
4.3.14. The Class ToSMarkerService 🌺
this is a concrete class that represents marking the ToS field in the IPv4 packet header [R791] 🦋 following common practice, the value written into the field is represented as an unsigned 8-bit integer 🍒
the class definition goes like this:
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 ToSValue4.3.14.1. The Property ToSValue 🎀
this 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 marking 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 written into the field is represented as an unsigned 8-bit integer 🫧
the class definition goes like this:
NAME DSCPMarkerService
DESCRIPTION A concrete class representing the
process of marking the DSCP field
in a packet with a specified
value. Packets are marked in order
to control the conditioning that
they will subsequently receive.
DERIVED FROM MarkerService
TYPE Concrete
PROPERTIES DSCPValue4.3.15.1. The Property DSCPValue 🌟
this 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 marking the user priority field defined in the IEEE 802.1Q specification [IEEE802Q] 🫶 following common practice, the value written into the field is represented as an unsigned 8-bit integer 🍓
the class definition goes like this:
NAME 8021QMarkerService
DESCRIPTION A concrete class representing the
process of marking 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 PriorityValue4.3.16.1. The Property PriorityValue 👑
this 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 ✨
Okay bestie, the DropperService is a concrete class for selectively dropping network traffic 🗑️✨. It can also hand whatever isn't dropped off to another ConditioningService for more processing. This is the base class for every type of dropper, and droppers are told apart by the algorithm they use to drop traffic 🦋. For the full tea on the different dropper types, check out [DSMODEL]. Also, this class covers both Absolute Droppers and Algorithmic Droppers from [DSMODEL], so it's giving everything 💅.
DropperService is modeled as a ConditioningService so it can be aggregated into a QoSService (through the QoSConditioningSubService association) to show that it powers that QoS service 👑. It uses the NextService association to point at the next ConditioningService object, the one that handles whatever traffic survives the drop 🌸.
NextService has extra special semantics for droppers on top of the usual "what happens next" stuff every ConditioningService gets 🫶. To find the queue(s) a dropper drops packets from, you follow the chain(s) of NextService associations "rightwards" from the dropper until you hit a queue 🧚.
The class definition goes like this:
NAME DropperService
DESCRIPTION A concrete base class describing the
common characteristics of droppers.
DERIVED FROM ConditioningService
TYPE Concrete
PROPERTIES DropperType, OtherDropperType, DropFromNote: The DropperType property and the DropperService subclasses give similar info 🤓. DropperType exists for query purposes, and for cases where you don't need a DropperService subclass to model a certain type of dropper 💜. For example, the Absolute Dropper from [DSMODEL] is modeled as an instance of the DropperService class with its DropperType set to '4' ("Absolute Dropper") 🍓.
4.3.17.1. The Property DropperType
DropperType is an enumerated 16-bit unsigned integer that tells you what kind of dropper this is 🎀. The values are:
1 - Other
2 - Random
3 - HeadTail
4 - Absolute DropperNote: if DropperType isn't one of these four values, it SHOULD be interpreted as if it had the value '1' (Other) ⭐.
4.3.17.2. The Property OtherDropperType
This string property works together with DropperType 💖. When DropperType is '1' (aka Other), the name of the dropper type goes right here 🌈.
4.3.17.3. The Property DropFrom
DropFrom is an unsigned 16-bit integer enumeration that says where in the associated queue packets should get dropped from 👀. The defined values are:
unknown(0)
head(1)
tail(2)Note: if DropFrom is '0' (unknown), or if it isn't one of the three values listed here, then packets MAY be dropped from any location in the associated queue 🙈.
4.3.18. The Class HeadTailDropperService 🦋
HeadTailDropperService is a concrete class for the threshold info of a head or tail dropper 💅. The inherited DropFrom property tells you whether a given instance is a head dropper or a tail dropper ✨.
A head dropper always looks at the same queue it drops packets from, and that queue is always related to the dropper as the following service in the NextService association 🫶.
The class definition is:
NAME HeadTailDropperService
DESCRIPTION A concrete class used to describe
a head or tail dropper.
DERIVED FROM DropperService
TYPE Concrete
PROPERTIES QueueThreshold4.3.18.1. The Property QueueThreshold
QueueThreshold is an unsigned 32-bit integer for the queue depth at which traffic gets dropped 🔥. With a tail dropper, all newly arriving traffic gets dropped 🙅♀️. With a head dropper, packets at the front of the queue get dropped to make room for new packets, which get added at the end 🚪. The value is in bytes 🧮.
4.3.19. The Class REDDropperService 🌸
REDDropperService is a concrete class for dropping traffic with a Random Early Detection (RED) algorithm, which is described in [RED] 🌈. The whole point of RED is to avoid congestion, instead of just managing it once it's already happening 🧠. Rather than waiting for the queues to fill up and then dumping a huge pile of packets, RED keeps an eye on the average queue depth 👀. When the queue depth goes over a minimum threshold, packets get randomly discarded 🎲. Those discards make TCP slow down its transmission rate for the connections that got hit, while other TCP connections are not affected 🫠. For more about droppers, see [DSMODEL] 💖.
A RED dropper always drops packets from a single queue, and that queue is related to the dropper as the following service in the NextService association 🧚. To find the queue(s) the drop algorithm looks at, you follow the CalculationServiceForDropper association to get the dropper's DropThresholdCalculationService, then follow the CalculationBasedOnQueue association(s) to find the queue(s) being watched 🕵️♀️.
The class definition is:
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,
StopProbabilityNOTE: In [DSMIB], there's a single diffServRandomDropTable, which covers the general category of random dropping 📚. (RED is one kind of random dropping, but there are other kinds of random dropping that are different from RED 🦋.) The REDDropperService class lines up with the columns in that table that apply to the RED algorithm specifically 💅.
4.3.19.1. The Property MinQueueThreshold
MinQueueThreshold is an unsigned 32-bit integer for the minimum average queue depth at which packets are subject to being dropped 🫶. Its units are identified by the ThresholdUnits property 📏. The slope of the drop probability function is described by the StartProbability and StopProbability properties 📈.
4.3.19.2. The Property MaxQueueThreshold
MaxQueueThreshold is an unsigned 32-bit integer for the maximum average queue length at which packets are subject to always being dropped, no matter which dropping algorithm or probabilities are in use 💀. Its units are identified by the ThresholdUnits property 📏.
4.3.19.3. The Property ThresholdUnits
ThresholdUnits is an unsigned 16-bit integer enumeration that identifies the units for the MinQueueThreshold and MaxQueueThreshold properties 🍓. The defined values are:
bytes(1)
packets(2)Note: if ThresholdUnits isn't one of these two values, it SHOULD be interpreted as if it had the value '1' (bytes) 🌸.
4.3.19.4. The Property StartProbability
StartProbability is an unsigned 32-bit integer. Together with the StopProbability property, it defines the slope of the drop probability function 📉. That function controls how fast packets are subject to being dropped, as a function of the queue length 🧮.
This property expresses a drop probability in drops per thousand packets 💜. For example, the value 100 means a drop probability of 100 per 1000 packets, which is 10% 🎀. Min and max values are 0 to 1000 ✨.
4.3.19.5. The Property StopProbability
StopProbability is an unsigned 32-bit integer. Together with the StartProbability property, it defines the slope of the drop probability function 📉. That function controls how fast packets are subject to being dropped, as a function of the queue length 🧮.
This property expresses a drop probability in drops per thousand packets 💜. For example, the value 100 means a drop probability of 100 per 1000 packets, which is 10% 🎀. Min and max values are 0 to 1000 ✨.
4.3.20. The Class QueuingService 🧚
QueuingService is a concrete class for the ability to queue network traffic and to set the characteristics used to determine long-term congestion 🫶. For more on queuing, check [DSMODEL] 📚.
QueuingService is modeled as a ConditioningService so it can be aggregated into a QoSService (through the QoSConditioningSubService association), showing that its functionality is the foundation of that QoS service 👑.
The class definition is:
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, DepthUnits4.3.20.1. The Property CurrentQueueDepth
CurrentQueueDepth is an unsigned 32-bit integer that works as a read-only gauge for the current depth of this one queue 📊. This value can be a big help when you're trying to figure out weird behavior from a DropThresholdCalculationService 🕵️♀️.
4.3.20.2. The Property DepthUnits
DepthUnits is an unsigned 16-bit integer enumeration that identifies the units for the CurrentQueueDepth property 📏. The defined values are:
bytes(1)
packets(2)Note: if DepthUnits isn't one of these two values, it SHOULD be interpreted as if it had the value '1' (bytes). The
4.3.21. Class PacketSchedulingService 🎀
PacketSchedulingService is a concrete class for a scheduling service, which is a process that decides when a queued packet gets pulled out of a queue and sent to an output interface 🚀. Output interfaces can be physical network interfaces, or interfaces to components inside systems, like crossbars or back planes 🔌. Either way, if multiple queues are involved, schedulers are what give access to the interface 🫶.
Each instance of a PacketSchedulingService describes a scheduler from the point of view of the queues it's servicing 👀. For more on schedulers, see [DSMODEL] 💖.
PacketSchedulingService is modeled as a ConditioningService so it can be aggregated into a QoSService (through the QoSConditioningSubService association), showing that its functionality powers that QoS service 👑. It uses the NextService association to point at the next ConditioningService object (if there is one) that acts on traffic after the scheduler has processed it 🧚.
The class definition is:
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, OtherSchedulerType4.3.21.1. The Property SchedulerType ✨
bestie, this one's a 16-bit unsigned integer that's an enum 🎀 It tells you what type of scheduler you're dealing with. The values are:
1 - Other
2 - FIFO
3 - Priority
4 - Allocation
5 - Bounded Priority
6 - Weighted Round Robin PacketNote: if the value of SchedulerType is not one of these six values, it SHOULD be interpreted as if it had the value '2' (FIFO). 💅
4.3.21.2. The Property OtherSchedulerType 🦋
This string property is the sidekick of SchedulerType 👯♀️ When SchedulerType is 1 (aka Other), this is where you spell out what the scheduler actually is.
4.3.22. The Class NonWorkConservingSchedulingService 🌸
okay so this class doesn't add any new properties of its own. It just inherits everything from its superclass, PacketSchedulingService. What makes it special is that it joins one extra association, FailNextScheduler 🔥
Here's the class definition:
NAME NonWorkConservingSchedulingService
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 Class QoSService 👑
this is a concrete class that lets you think of a QoS service as a squad of coordinated sub-services working together 🫶 It's giving organization. Network admins can map business rules onto the network, and designers can build it so different traffic streams get different treatment.
It has two main jobs ✨ First, it's the common base class for defining the sub-services you need to build higher-level QoS services. Second, it's the place where relationships between different QoS services and different ConditioningServices get consolidated. Iconic 🙌
Here's an example that had me screaming 😭 Gold Service could be a QoSService that aggregates two QoS services. Each of those could be its own thing: one DiffServService instance (the one for very high demand packets, which is represented by an instance of DiffServService itself), and one for the service most packets get, represented by an instance of AFService, which is a subclass of DiffServService.
The high demand DiffServService instance uses the QoSConditioningSubService aggregation to pull together everything it needs: the classifiers that say which traffic it applies to, the appropriate meters for contract limits, the marker that tags packets with the EF PHB, and the queuing-related conditioning services. The AFService instance also uses QoSConditioningSubService, gathering its classifiers and meters, the several markers used to tag packets with the different AF PHBs, and the queuing-related conditioning services needed to deliver that packet treatment. Main character energy 💖
QoSService is modeled as a type of Service. It's the anchor point for a set of sub-services that implement the conditioning characteristics you want for different kinds of flows. It's the boss that decides which conditioning services get used to make this service happen 💅
Class definition:
NAME QoSService
DESCRIPTION A concrete class used to represent a QoS
service or set of services, as defined
by a network administrator.
DERIVED FROM Service
TYPE Concrete
PROPERTIES (none)4.3.24. The Class DiffServService 🧚
this is a concrete class for using standard or custom DiffServ services to build a (higher-level) QoS service. Heads up: a DiffServService object might be just one piece of a bigger set of coordinated QoSSubServices objects that together make up the higher-level service 🧩
DiffServService is modeled as a subclass of QoSService. That's what lets it hook up to a higher-level QoS service through QoSSubService, and to specific ConditioningService objects (like metering, dropping, queuing, and others) through QoSConditioningSubService 🎀
Class definition:
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 PHBID4.3.24.1. The Property PHBID 🌈
this is a 16-bit unsigned integer that identifies a particular per hop behavior, or a whole family of them. The value is a Per Hop Behavior Identification Code, defined in [R3140]. Quick tea ☕: those identification codes bake in the default, recommended code points for PHBs as part of their structure. The value in the actual marker can be different, because the marked value is domain-dependent 🙈
Why bother with it? Because it helps you tie a QoS Service back to reference documents, and it makes inter-domain coordination and operation way smoother 🤝
4.3.25. The Class AFService 🦋
this concrete class is a specialization of forwarding network traffic, adding the specific semantics for how the Assured Forwarding (AF) Service ([R2597]) behaves 💜
[R2597] defines four different AF classes, each one representing a different treatment of traffic. Each AF class gets a different amount of forwarding resources, like buffer space and bandwidth 🍓 Inside each AF class, IP packets get marked with one of three possible drop precedence values. Drop precedence decides how important a packet is compared to the others in the same AF class when congestion happens. A congested interface tries to protect packets with a lower drop precedence value, and instead throws away packets marked with a higher one. Gentle reminder: it's the higher ones that get the boot 😤
Also, [R2597] defines 12 DSCPs that together represent the AF Per Hop Behavior (PHB) group. Implementations are free to extend this, like adding more classes and/or drop precedences ✨
AFService is modeled as a specialization of DiffServService, which is itself a specialization of QoSService. So it can hook up to higher-level QoS services, and to lower-level conditioning sub-services (like classification, metering, dropping, queuing, and others) 🫶
Class definition:
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, DropperNumber4.3.25.1. The Property ClassNumber 💅
this is an 8-bit unsigned integer that tells you how many AF classes this AF implementation uses. Among the instances aggregated through QoSConditioningSubService with an instance of AFService, you SHOULD find markers with as many distinct values as the ClassNumber of that AFService instance 🌸
4.3.25.2. The Property DropperNumber 🎀
this is also an 8-bit unsigned integer, and it counts how many drop precedence values this AF implementation uses. The number of drop precedence values is per AF class, so it's the number PER AF CLASS 👑 The matching droppers are found in the collection of conditioning services aggregated through the QoSConditioningSubService aggregation.
4.3.26. The Class FlowService 💖
this class represents a service that supports one particular microflow. The microflow is identified by the string-valued property FlowID. In some implementations, each instance of this class lines up with an entry in the implementation's flow table 📋
Class definition:
NAME FlowService
DESCRIPTION A concrete class representing a
microflow.
DERIVED FROM QoSService
TYPE Concrete
PROPERTIES FlowID4.3.26.1. The Property FlowID 🧚
this is a string containing an identifier for a microflow. Simple, cute, and to the point 🦋
4.3.27. The Class DropThresholdCalculationService 🌈
this class is a logical entity that calculates an average queue depth for a queue, using a smoothing weight and a sampling time interval. It does this on behalf of a RED dropper, so the dropper can decide whether to drop packets based on a smoothed average queue depth for the queue. Smart, no cap 🧠
Class definition:
NAME DropThresholdCalculationService
DESCRIPTION A concrete class representing a logical
entity that calculates an average queue
depth for a queue, 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, TimeInterval4.3.27.1. The Property SmoothingWeight 💜
this is a 32-bit unsigned integer ranging between 0 and 100,000, specified in thousandths. It sets how much weight past history gets when calculating the current average queue depth. The current queue depth calculation uses the inverse of this value as its factor, and one minus that inverse as the factor for the historical average. The formula goes like this:
average = (old_average*(1-inverse of SmoothingWeight))
+ (current_queue_depth*inverse of SmoothingWeight)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.27.2. The Property TimeInterval ⭐
this is a 32-bit unsigned integer that defines the number of nanoseconds between each calculation of the average/smoothed queue depth. If this property is not specified, the CalculationService may determine an appropriate interval itself 🙌
4.3.28. The Abstract Class FilterEntryBase 🌸
FilterEntryBase is the abstract base class that all filter entry classes come from. It's the endpoint for the EntriesInFilterList aggregation, which groups filter entries into filter lists. Its properties include CIM naming properties and an IsNegated boolean property, which lets you easily "NOT" the match information specified in an instance of one of its subclasses 🙈
Because FilterEntryBase has general applicability, it's defined in [PCIME]. Go to [PCIME] for the full definition of this class 📖
4.3.29. The Class IPHeaderFilter 🎀
this concrete class lets you represent an entire IP header filter in a single object 🫶 A property called IpVersion tells you 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're always the same type. Literally always 💅)
See [PCIME] for the definition of this class.
4.3.30. The Class 8021Filter ✨
okay so this one is a concrete class, and it's giving one-stop shop 🎀 It lets you pack the 802.1 source and destination MAC addresses, plus the 802.1 protocol ID, priority, and VLAN identifier fields, into a single object. Iconic, honestly 💅
See [PCIME] for the definition of this class.
4.3.31. The Class PreambleFilter 🦋
bestie, this is a concrete class that lets you sort packets using traffic-conditioning results that a PreambleMarkerService tucked into a packet preamble 🧚 See Section 3.8.3 for the discussion of how, and why, QDDIM models the ability to store these results in a packet preamble. An instance of PreambleFilter picks out packets using a two-part string that names one specific result. The logic for the match is "at least one", so a packet with multiple results in its preamble matches the filter if at least one of those results matches. Main character energy, no cap 💜
The class definition is as follows:
NAME PreambleFilter
DESCRIPTION A concrete class representing criteria
for selecting packets based on prior
traffic-conditioning results stored in
a packet preamble.
DERIVED FROM FilterEntryBase
TYPE Concrete
PROPERTIES FilterItemList[ ]4.3.31.1. The Multi-valued Property FilterItemList 🌈
this property is an ordered list of strings, and every string follows the format "<type>,<value>" 🫶 Check Section 3.8.3 for the list of <type>'s defined in QDDIM and what the matching <value> looks like for each one.
Quick heads up, because this part is so easy to mix up: there are two parallel ways of describing meter results ✨ The enumeration value conforming(1) is sometimes called "in profile", and the value nonConforming(3) is sometimes called "out of profile". Same vibe, two names 🙈
4.3.32. The Class FilterList 🌸
this is a concrete class that gathers up instances of (subclasses of) FilterEntryBase through the EntriesInFilterList aggregation. You can mix different kinds of filters into one FilterList, which is so useful. For example, you can combine packet header filters (the IPHeaderFilter class) with security filters (the subclasses of FilterEntryBase that IPsec defines) 🔥
The aggregation property EntriesInFilterList.EntrySequence is always set to 0, which means the aggregated filter entries get ANDed together to form a selector for a class of traffic. Lock it in 🔒
See [PCIME] for the definition of this class.
4.3.33. The Abstract Class ServiceAccessPoint 💜
this is an abstract class defined in the Core Model of CIM 🧚 It's a subclass of the LogicalElement class, and it's the base class for every object that manages access to CIM_Services. It represents the management of using or invoking a Service. Please refer to [CIM] for the full definition of this class.
4.3.34. The Class ProtocolEndpoint 🦋
this is a concrete class derived from ServiceAccessPoint. It describes a communication point where you can get to the services of the network or the system's protocol stack. Please refer to [CIM] for the full definition of this class.
4.3.35. The Abstract Class Collection 🍓
this is an abstract class defined in the Core Model of CIM, and it's the superclass for every class that represents groupings or bags 🛍️ These 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.36. The Abstract Class CollectionOfMSEs 🌷
this is an abstract class defined in the Core Model of CIM. It's a subclass of the Collection superclass, and it restricts the contents of the Collection to ManagedSystemElements. Please refer to [CIM] for the full definition of this class.
4.3.37. The Class BufferPool ✨
this is a concrete class that represents the collection of buffers a QueuingService uses. (The association QueueAllocation represents this usage.) Managing individual buffers may be modeled in a future document 👀 At the current level of abstraction, though, modeling the existence of the BufferPool is necessary. Long term, it is not sufficient.
If there are multiple buffer sizes in an implementation, an instance of BufferPool should be defined for each set of buffers with identical or similar sizes. Those buffer pool instances can then be grouped together using the CollectedBuffersPool aggregation 🧺
Heads up, 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. Don't mix them up, bestie 🙅♀️
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, SharedBuffers4.3.37.1. The Property Name 🎀
this property is a string with a maximum length of 256 characters. It's the common name or label that the object goes by.
4.3.37.2. The Property BufferSize 🌸
this property is a 32-bit unsigned integer that identifies the approximate number of bytes in each buffer in the pool. An implementation will typically group buffers of roughly the same size together, which cuts down on how many buffer pools it has to manage. This model doesn't specify how much buffers in the same pool can differ in size, so that's up to the implementation 🤷♀️
4.3.37.3. The Property TotalBuffers 💜
this property is a 32-bit unsigned integer that reports the total number of individual buffers in the pool.
4.3.37.4. The Property AvailableBuffers 🦋
this property is a 32-bit unsigned integer that reports how many buffers in the Pool are not currently allocated to any instance of a QueuingService. Buffers that are allocated to a QueuingService can either be in use (meaning they currently hold packet data), or be allocated to a queue while they wait for new packet data to arrive ⏳
4.3.37.5. The Property SharedBuffers 🌈
this property is a 32-bit unsigned integer that reports how many buffers in the Pool have been allocated to multiple instances of QueuingService at the same time 🫱🫲
4.3.38. The Abstract Class SchedulingElement 🧚
this is an abstract class that represents the configuration info a PacketSchedulingService has for one of the elements it's scheduling. The scheduled element is either a QueuingService or another PacketSchedulingService.
Some subclasses of this class are defined so that all of their instances are work conserving. Other subclasses may have instances that either are or aren't work conserving. In this class, the boolean property WorkConserving indicates whether an instance is work conserving or not. The range of values for WorkConserving is restricted to TRUE in the subclasses that are inherently work conserving, since their instances can't 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 WorkConserving4.3.38.1. The Property WorkConserving 🍓
this boolean property indicates whether the PacketSchedulingService tied to this instance through the ElementInSchedulingService aggregation is treating the input tied to this instance (via the QueueToSchedule or SchedulingServiceToSchedule association) in a work-conserving manner. Note that this property is writable, so an administrator can change how the SchedulingElement behaves. That said, this only works for elements that can operate in a non-workconserving mode 🔧
4.3.39. The Class AllocationSchedulingElement 👑
this class is a subclass of the abstract class SchedulingElement, and it adds five new properties to support bandwidth-based scheduling 💖 Like every subclass of SchedulingElement, the input for an instance of AllocationSchedulingElement is one of two types: either a queue, or another scheduler.
The class definition is as follows:
NAME AllocationSchedulingElement
DESCRIPTION A concrete class containing parameters
for controlling bandwidth-based
scheduling.
DERIVED FROM SchedulingElement
TYPE Concrete
PROPERTIES AllocationUnits, BandwidthAllocation,
BurstAllocation, CanShare,
WorkFlexible4.3.39.1. The Property AllocationUnits 🌸
this is a 16-bit unsigned integer enumeration that identifies the units used by the BandwidthAllocation and BurstAllocation properties. These values are defined:
o bytes(1)
o packets(2)
o cells(3) -- fixed-size, for example, ATMNote: if the value of AllocationUnits is not one of these three values, it SHOULD be interpreted as if it had the value 1 (bytes). Good to know, babe 🫶
4.3.39.2. The Property BandwidthAllocation 💜
this 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.39.3. The Property BurstAllocation 🌈
this is a 32-bit unsigned integer that specifies the amount of temporary or short-term bandwidth (in units per second) that can be given to an input, on top of what it already gets from the BandwidthAllocation property. If you measured the maximum actual bandwidth allocation for the input, it would be the sum of BurstAllocation and BandwidthAllocation. The units are identified by the AllocationUnits property ⚡
4.3.39.4. The Property CanShare 🧚
this is a boolean property that, if TRUE, lets unused bandwidth from the associated input be allocated to other inputs that the Scheduler services. Sharing is caring 🤝
4.3.39.5. The Property WorkFlexible 🎀
this is a boolean property that, if TRUE, shows that the scheduler's behavior relative to this input can be changed by altering the value of the inherited property WorkConserving. Flexible queen behavior 👑
4.3.40. The Class WRRSchedulingElement 🎀
okay bestie, this class is a subclass of the abstract class SchedulingElement 💅 and it represents a weighted round robin (WRR) scheduling discipline 🦋. It introduces a new property called WeightingFactor so some inputs get a higher probability of being serviced than others ✨. It also brings in Priority, which acts as a tiebreaker when inputs have equal weighting factors 🫶. Same as every SchedulingElement subclass, the input on a WRRSchedulingElement is one of two types: either a queue, or another scheduler 🧚.
Since this kind of scheduling is always work conserving, the inherited boolean property WorkConserving is locked to TRUE in this class 🔒. no cap, it's giving consistency 💖.
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, Priority4.3.40.1. The Property WeightingFactor 🍓
this one is a 32-bit unsigned integer that defines the weighting factor, the thing that gives some inputs a higher chance of being serviced than others 💜. This property represents that probability itself ✨. Its minimum value is 0, its maximum value is 100000, and its units are thousandths 🌸.
4.3.40.2. The Property Priority 👑
this is a 16-bit unsigned integer that acts as a tiebreaker in case two or more inputs have equal weights 🎀. A larger value means a higher priority, obviously 💅. Here's the tea: if this property is specified for any of the WRRSchedulingElements belonging to a PacketSchedulingService, then it must be specified for all WRRSchedulingElements for that PacketSchedulingService too, and the property values for these WRRSchedulingElements must all be different 😭.
While this condition may not occur in some implementations of a weighted round-robin scheduler, many implementations need a priority to resolve an equal-weight situation 🔥. If this behaviour isn't necessary, or it's kinda undesirable in a particular case, this property may be left unspecified 🌈.
4.3.41. The Class PrioritySchedulingElement 🌸
this class is a subclass of the abstract class SchedulingElement 💖. It tells you that a scheduler is taking packets from a set of inputs using the priority scheduling discipline 🫶. As with all SchedulingElement subclasses, the input on a PrioritySchedulingElement is either a queue or another scheduler 🧚. The property Priority here represents the priority for an input, relative to the priorities of all the other inputs that the scheduler aggregating this PrioritySchedulingElement is associated with 💅. Inputs connected to that scheduler through other scheduling disciplines don't count in this ranking 🙈.
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 Priority4.3.41.1. The Property Priority 🦋
this is a 16-bit unsigned integer that shows the priority level of a scheduler input compared with the other inputs serviced by this PacketSchedulingService 🎀. A larger value means a higher priority ✨.
4.3.42. The Class BoundedPrioritySchedulingElement 💜
this class is a subclass of PrioritySchedulingElement, which is itself derived from the abstract class SchedulingElement 🌈. As with all SchedulingElement subclasses, the input on a BoundedPrioritySchedulingElement is one of two types: either a queue, or another scheduler 🧚. It adds an upper bound, in kilobits per second, on how much traffic can be handled from an input 🍓. That data is specific to that one input, and it's needed when bounded strict priority scheduling is performed 👑.
This class inherits the restriction from its superclass PrioritySchedulingElement, so the inherited boolean property WorkConserving is restricted 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 BandwidthBound4.3.42.1. The Property BandwidthBound 💅
this 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's a strict bound, which limits 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 shown earlier in Figures 4 and 5 🧚. These associations are defined as classes in the Information Model 💜. Each of these classes has two properties that refer to instances of the two classes the association links, and some of them have extra properties as well 🫶.
4.4.1. The Abstract Association Dependency 🦋
this abstract association defines two object references, named Antecedent and Dependent, that set up general dependency relationships between different managed objects in the information model 🌈. The Antecedent reference identifies the independent object in the association, while the Dependent reference identifies the entity that IS dependent 💅.
The association's cardinality is many to many 🍓.
The association is defined in the 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 it 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 ✨. On the other hand, a single ConditioningService can be the first to process packets received via multiple protocol endpoints, so 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]]4.4.4. The Association EgressConditioningServiceOnEndpoint 🌈
this association is derived from the association ServiceSAPDependency, and it 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 🫶. However, a single ConditioningService cannot be the last one to process packets for multiple protocol endpoints, so 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, and it describes the association between a head or tail dropper and a 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..n on the queue side, since a head/tail dropper must monitor at least one queue 🔥. For the classes HeadTailDropper and HeadTailDropQueueBinding, the rule for combining the inputs from multiple queues is simple addition: if the sum of the lengths of the monitored queues exceeds the dropper's QueueThreshold value, then packets are dropped 😭. This rule for combining inputs may, however, be overridden by a different rule in subclasses of one or both of these classes 🎀.
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 a queue that it
monitors.
DERIVED FROM Dependency
ABSTRACT False
PROPERTIES Antecedent[ref QueuingService[1..n]],
Dependent[ref
HeadTailDropperService [0..n]]4.4.6. The Association CalculationBasedOnQueue ✨
This one's a subclass of Dependency 💅 and it links a QueuingService to a DropThresholdCalculationService with two object references 🔗. The calc service reads the queue's current depth to work out an average queue depth 📊, so the queue is literally feeding it the numbers it needs 🫶.
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[1..1]],
Dependent[ref
DropThresholdCalculationService [0..n]]4.4.6.1. The Reference Antecedent 🎀
This one's inherited from Dependency, but it's been overridden 🙈 so it points at a QueuingService instead of the broader ManagedElement. It's the queue the DropThresholdCalculationService uses when it does its average queue depth math 🧮.
4.4.6.2. The Reference Dependent 🦋
Also inherited from Dependency and overridden, this time to point at a DropThresholdCalculationService instead of a general ManagedElement 💖. It names the calc service that takes the referenced queue's current depth as one of its inputs for the average queue depth calculation ✨.
4.4.7. The Association ProvidesServiceToElement 🌸
This association has two object references that set up a dependency where a ManagedSystemElement relies on the functionality of one or more Services 🧚. It's many to many, and it's defined in the Core Model of CIM, so for the full definition you'll want to check out [CIM] 📚.
4.4.8. The Association ServiceServiceDependency 🍓
Here we go, two object references linking two Service objects 🔗. The TypeOfDependency property says what kind of dependency it is, and the typical examples are one Service being required to be present or required to have completed before the other Service can operate 🫶.
It's super similar to ServiceSAPDependency, just with a twist 🌈. In that one, the Service depends on an AccessPoint to reach another Service. Here, the association points straight at the Service dependency itself 💅. Both relationships should not be instantiated, because the info would be repeated, which is kinda redundant, bestie 💀.
It's many to many, and it's defined in the Core Model of CIM, so [CIM] has the full definition 💜.
4.4.9. The Association CalculationServiceForDropper 🔥
This is a subclass of ServiceServiceDependency 💖. It has two object references that capture how a REDDropperService relies on a DropThresholdCalculationService, which works out an average queue depth from the observed depths of one or more queues 📊.
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..n]],
Dependent[ref REDDropperService[0..n]]4.4.9.1. The Reference Antecedent 🧁
This is inherited from ServiceServiceDependency and overridden to point at a DropThresholdCalculationService, not just any Service 🌷. The cardinality is 1..n, which means a RED dropper can be served by one or more calculation services 💜.
4.4.9.2. The Reference Dependent 🌈
Inherited from ServiceServiceDependency and overridden to point at a REDDropperService instead of a general Service ✨. It identifies a RED dropper that a DropThresholdCalculationService is serving 🫶.
4.4.10. The Association QueueAllocation 🦋
This is another subclass of Dependency 💅. It links a QueuingService with a BufferPool, which provides the storage space for the packets sitting in that queue 🎀.
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]]
AllocationPercentage4.4.10.1. The Reference Antecedent 🏊
Inherited from Dependency and overridden to point at a BufferPool object 🫧. It identifies the BufferPool where the packets on the QueuingService's queue are stored 📦.
4.4.10.2. The Reference Dependent 💖
Also inherited from Dependency and overridden, this time to a QueuingService object 🌸. It names the QueuingService whose packets are being kept in the BufferPool's buffers 🧚.
4.4.10.3. The Property AllocationPercentage 🍓
This is an 8-bit unsigned integer, with a minimum of zero and a maximum of 100 💯. It sets the percentage of the BufferPool that should be given to the referenced QueuingService 🥧. If you want absolute sizes instead, the trick is to define separate BufferPools of the sizes you want, then set QueueAllocation.AllocationPercentages to 100 for each one 🙌.
4.4.11. The Association ClassifierElementUsesFilterList 🎀
This is a subclass of the Dependency association 🌈. It connects one or more ClassifierElements with a FilterList, which holds the criteria for picking the packets each ClassifierElement should process 🔍.
In the QDDIM model, a classifier is always modeled as a ClassifierService that aggregates a set of ClassifierElements 🧩. Now here's the important bit 👀: when ClassifierElements use the NextServiceAfterClassifierElement association to bind to another ClassifierService, which builds a hierarchical classifier, the ClassifierElementUsesFilterList association must not be specified 🙈.
NAME ClassifierElementUsesFilterList
DESCRIPTION An association relating a
ClassifierElement to the FilterList
representing the criteria for selecting
packets for that
ClassifierElement to process.
DERIVED FROM Dependency
ABSTRACT False
PROPERTIES Antecedent[ref FilterList [0..1]],
Dependent[ref ClassifierElement [0..n]]4.4.11.1. The Reference Antecedent 🫶
This is inherited from Dependency and overridden to point at a FilterList object, not the more general ManagedElement 💫. Its cardinality is 0 to 1, which means a ClassifierElement either uses one FilterList to select its packets, or uses none at all when it's chained to another ClassifierService through NextServiceAfterClassifierElement to make a hierarchical classifier 🪄.
4.4.11.2. The Reference Dependent 🌸
Inherited from Dependency and overridden to point at a ClassifierElement object, instead of a general ManagedElement 🧚. It identifies a ClassifierElement that depends on the associated FilterList to define its packet-selection criteria 🔍.
4.4.12. The Association AFRelatedServices 💅
This association has two object references that set up a dependency between two AFService objects 🦋. The dependency is about precedence, meaning which of the individual AF drop-related Services comes first within an AF IP packet-forwarding class 👑.
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 points at an AFService object with the lower probability of dropping packets 🌷.
4.4.12.2. The Reference AFHigherDropPrecedence 🔥
This property points at an AFService object with the higher probability of dropping packets 🌈.
4.4.13. The Association NextService 🧚
This association has two object references that set up a predecessor-successor relationship between two ConditioningService objects 🔗. It's how you show the order of ConditioningServices needed to process a given type of traffic 🫶.
Instances of this dependency describe how different ConditioningServices relate to each other, like classifiers, meters, droppers, and so on, that work together to condition traffic 🎀. You can describe both one-to-one setups and the more complicated fan-in and fan-out ones 🍓. The ConditioningServices can feed right into one another, or they can be mapped to several "next" Services depending on the characteristics of the packet 🦋.
NAME NextService
DESCRIPTION An association used to establish
a predecessor-successor relationship
between two ConditioningService objects.
DERIVED FROM Nothing
ABSTRACT False
PROPERTIES PrecedingService[ref
ConditioningService[0..n]],
FollowingService[ref
ConditioningService[0..n]]4.4.13.1. The Reference PrecedingService 💜
This property points at a ConditioningService object that comes earlier in the processing sequence for a given type of traffic 🌸.
4.4.13.2. The Reference FollowingService ✨
This property points at a ConditioningService object that comes later in the processing sequence for a given type of traffic. It sits immediately after the ConditioningService identified by the PrecedingService object reference 🫶💅
4.4.14. The Association NextServiceAfterClassifierElement ✨
okay so this one is a glow-up of NextService bestie 💅 it changes two things:
- it limits the PrecedingService object reference to the class ClassifierElement 🎀
- it limits the cardinality of the FollowingService object reference to exactly 1 🦋
here's the class definition 👑
NAME NextServiceAfterClassifierElement
DESCRIPTION An association used to establish
a predecessor-successor 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.14.1. The Reference PrecedingService 🌸
this one is inherited from NextService, but it gets overridden here so it points at a ClassifierElement instead of the more general ConditioningService from the superclass 🧚
a ClassifierElement is a piece of a single ClassifierService, and any packets it selects always get passed on to the ConditioningService named by FollowingService. no cap, that's the whole point 💖
4.4.14.2. The Reference FollowingService 💜
also inherited from NextService and overridden here to lock the cardinality to exactly 1 🔒 this is because a DiffServ classifier must be deterministic. the packets picked by a given ClassifierElement in a given ClassifierService have to go to one and only one next ConditioningService, no exceptions, periodt 💅
4.4.15. The Association NextScheduler 🍓
this one is a subclass of NextService, and it has two object references that set up a predecessor-successor relationship between PacketSchedulingServices 🧁 it's for hierarchical queuing, where a second scheduler treats the output of a first scheduler as one single aggregated input. when that happens, the two schedulers are linked through NextScheduler ✨
here's the class definition 💖
NAME NextScheduler
DESCRIPTION An association used to establish
predecessor-successor relationships
between PacketSchedulingService objects
for simple hierarchical scheduling.
DERIVED FROM NextService
ABSTRACT False
PROPERTIES PrecedingService[ref
PacketSchedulingService[0..n]],
FollowingService[ref
PacketSchedulingService[0..1]]4.4.15.1. The Reference PrecedingService 🦋
inherited from NextService, then overridden so it points at a PacketSchedulingService object instead of the broader ConditioningService 🎀 it names a scheduler whose output gets treated as one aggregated input by the scheduler in the FollowingService reference. the [0..n] cardinality means one FollowingService scheduler can gather up the aggregated outputs of several earlier schedulers, which is so cool 🧚
4.4.15.2. The Reference FollowingService 🌈
inherited from NextService and overridden the same way, to point at a PacketSchedulingService object rather than a ConditioningService 🌸 it names a scheduler that takes in, among its inputs, the aggregated outputs of one or more PrecedingService schedulers 💅
4.4.16. The Association FailNextScheduler 🔥
this is a subclass of NextScheduler, and it describes what's going on between two schedulers when the first one passes up a scheduling opportunity 🙈 that makes it non-work-conserving, and the bandwidth it skips gets handed over to the second scheduler to use. if you want examples of where this might be used, check out Sections 3.11.3 and 3.11.4 🫶
here's the class definition ✨
NAME FailNextScheduler
DESCRIPTION This association specializes the
NextScheduler association. It
establishes a relationship between a
non-work-conserving scheduler and a
second scheduler to which it makes
available the bandwidth that it elects
not to use.
DERIVED FROM NextScheduler
ABSTRACT False
PROPERTIES PrecedingService[ref
NonWorkConservingSchedulingService[0..n]]4.4.16.1. The Reference PrecedingService 🧚
inherited from NextScheduler, then overridden to point at a NonWorkConservingSchedulingService object instead of the more general PacketSchedulingService 💜 it identifies a non-work-conserving scheduler whose spare bandwidth is made available to the scheduler in the FollowingService reference. the [0..n] cardinality means one FollowingService scheduler might get the chance to use the leftover bandwidth from several earlier non-work-conserving schedulers, ngl that's a lot of bandwidth sharing 🌈
4.4.17. The Association NextServiceAfterMeter 🎀
this one describes a predecessor-successor relationship between a MeterService and one or more ConditioningService objects that process the traffic coming out of the meter 💖 for example, on devices that do preamble marking, the FollowingService reference (after the meter) is a PreambleMarkerService, which records the results of the metering in the preamble 🧁
you'd expect NextServiceAfterMeter to be a subclass of NextService, right? 🙃 nope. meters are 1:n fan-out elements, so they need a way to tell apart their different results and outputs. this association therefore adds a brand-new key property, MeterResult, which records the result and identifies the output the traffic left the meter through. because of that extra key, NextServiceAfterMeter cannot be a subclass of NextService 💅
here's the class definition 👑
NAME NextServiceAfterMeter
DESCRIPTION An association used to establish
a predecessor-successor relationship
between a particular output of a
MeterService and the next
ConditioningService object that is
responsible for further processing of
the traffic.
DERIVED FROM Nothing
ABSTRACT False
PROPERTIES PrecedingService[ref MeterService[0..n]],
FollowingService[ref
ConditioningService[0..n]],
MeterResult4.4.17.1. The Reference PrecedingService 🦋
this is the MeterService that comes before, "earlier" in the processing order for a packet 🕰️ since meters are 1:n fan-out devices, this relationship ties one particular output of a MeterService (named by the MeterResult property) to the next ConditioningService that keeps processing that traffic ✨
4.4.17.2. The Reference FollowingService 🌸
this is the "next" or following ConditioningService 🧚
4.4.17.3. The Property MeterResult 🌈
this property is an enumerated 16-bit unsigned integer, and it stores info about the result of the metering 🍓 traffic gets sorted as conforming, non-conforming, or partially conforming. if you want fancier metering, you can extend the enumeration or chain meters together 🔥
the enumerated values are: "Unknown" (0), "Conforming" (1), "PartiallyConforming" (2), "NonConforming" (3) 💖
"Unknown" (0)
"Conforming" (1)
"PartiallyConforming" (2)
"NonConforming" (3)4.4.18. The Association QueueToSchedule 💜
this is a top-level association that links a queue (QueuingService) to a SchedulingElement 🫶 the SchedulingElement holds the info from a packet scheduling service that's specific to that queue, like relative priority or allocated bandwidth 🧁
it can't be fully expressed with association cardinalities, so there's an extra rule on participation. a particular instance of (a subclass of) SchedulingElement always takes part in exactly one instance of this association, or in exactly one instance of the association SchedulingServiceToSchedule 🙈
here's the class definition ✨
NAME QueueToSchedule
DESCRIPTION This association relates a queue to
the SchedulingElement containing
information specific to the queue.
DERIVED FROM Nothing
ABSTRACT False
PROPERTIES Queue[ref QueuingService[0..1]],
SchedElement[ref
SchedulingElement[0..n]]4.4.18.1. The Reference Queue 🎀
this points to a QueuingService object. a QueuingService object can be associated with 0 or more SchedulingElement objects 💅
4.4.18.2. The Reference SchedElement 🌈
this points to a SchedulingElement object. a SchedulingElement is always associated with exactly one QueuingService or with exactly one upstream scheduler (PacketSchedulingService) 👑
4.4.19. The Association SchedulingServiceToSchedule 🦋
this is another top-level association, and it relates a scheduler (PacketSchedulingService) to a SchedulingElement in a configuration with cascaded schedulers 🌸 the SchedulingElement holds info from a subsequent packet scheduling service that's specific to this scheduler, like relative priority or allocated bandwidth 🧚
same deal as before, it can't be expressed fully with cardinalities. a particular instance of (a subclass of) SchedulingElement always takes part in exactly one instance of this association, or in exactly one instance of the association QueueToSchedule 💖
here's the class definition 🍓
NAME SchedulingServiceToSchedule
DESCRIPTION This association relates a scheduler to
the SchedulingElement in a subsequent
scheduler containing information specific
to this scheduler.
DERIVED FROM Nothing
ABSTRACT False
PROPERTIES SchedService[ref
PacketSchedulingService[0..1]],
SchedElement[ref
SchedulingElement[0..n]]4.4.19.1. The Reference SchedService 💜
this points to a PacketSchedulingService object. a PacketSchedulingService object can be associated with 0 or more SchedulingElement objects 🫶
4.4.19.2. The Reference SchedElement 🎀
okay so this property is an object reference to a SchedulingElement object 🧚 and a SchedulingElement is always tied to exactly one of two things: either exactly one QueuingService, or exactly one upstream scheduler (a PacketSchedulingService) ✨ no in-between, no cap 💅
4.4.20. The Aggregation MemberOfCollection 🦋
this aggregation is a generic relationship that models a bunch of ManagedElements getting grouped into one generalized Collection object 🌸 the cardinality is many to many, so lots of members can belong to lots of collections, bestie 🫶
MemberOfCollection is defined in the Core Model of CIM 💜 go check [CIM] if you want the full definition of this class 📚
4.4.21. The Aggregation CollectedBufferPool 🧺
this one models the idea of treating a group of buffers as a pool, or collection, which can then sit inside a "higher-level" buffer pool 🍓 it's a more specific version of MemberOfCollection that only lets BufferPool instances be the aggregate and the part components, so it's super locked in 🔒 like iconic
here's the class definition:
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 is the parent, or aggregate, object in the relationship 👑 it's a BufferPool object ✨
4.4.21.2. The Reference Member 💖
this property is the child, or lower-level pool, in the relationship 🫧 it's one of the BufferPools that together make up the higher-level pool 🧁
4.4.22. The Abstract Aggregation Component 🌷
this abstract aggregation is a generic relationship for setting up "part-of" relationships between managed objects, called GroupComponent and PartComponent 🧩 the cardinality is many to many, lowkey the most flexible one 💜
the association is defined in the Core Model of CIM, so please refer to [CIM] for the full definition of this class 📖
4.4.23. The Aggregation ServiceComponent 🍭
this aggregation models a set of subordinate Services that get aggregated together to form a higher-level Service 🎀 it's derived from the more generic Component superclass, which restricts what kinds of objects can take part in the relationship 💅 the cardinality is many to many ✨
the association is defined in the Core Model of CIM, so please refer to [CIM] for the full definition of this class 🫶
4.4.24. The Aggregation QoSSubService 👑
this aggregation represents a set of subordinate QoSService objects (so, a set of instances of subclasses of the QoSService class) that get aggregated together to form a higher-level QoSService 🔥 a QoSService is a specific type of Service that treats QoS functionality as a set of coordinated sub-services, which is so smart 🧠
this aggregation is derived from the more generic ServiceComponent superclass, and it restricts the participants 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) 🌸
here's the class definition:
NAME QoSSubService
DESCRIPTION A generic association used to establish
"part-of" relationships between a
higher-level QoSService object and the
set of lower-level QoSServices that
are aggregated to create/form it.
DERIVED FROM ServiceComponent
ABSTRACT False
PROPERTIES GroupComponent[ref QoSService[0..1]],
PartComponent[ref QoSService[0..n]]4.4.24.1. The Reference GroupComponent ✨
this property is overridden in this aggregation so it's an object reference to a QoSService object (instead of the more generic Service object from its superclass) 🎀 this object is the parent, or aggregate, in the relationship 👑
4.4.24.2. The Reference PartComponent 💅
this property is also overridden so it's an object reference to a QoSService object (not the generic Service object) 🫶 this object is the child, or "component", in the relationship 🧚
4.4.25. The Aggregation QoSConditioningSubService 🌈
this aggregation identifies the set of conditioning services that together condition traffic for a particular QoS service 🚦 it's derived from the more generic ServiceComponent superclass, and it restricts what can participate to ConditioningService and QoSService objects instead of generic Service objects 💜
here's the class definition:
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 here so it's an object reference to a QoSService object (not the generic Service object from its superclass) 🌸 the cardinality stays 0..n, which means a given ConditioningService can condition traffic for 0, 1, or more than 1 QoSService objects 🍓
this object is the parent, or aggregate, in the association 👑 in this case it's the QoSService that aggregates one or more ConditioningService objects to do the right traffic conditioning for its traffic 💖
4.4.25.2. The Reference PartComponent 🧁
this property is overridden so it's an object reference to a ConditioningService object (instead of the generic Service object) 🫧 this object is the child, or "component", in the relationship 🌷 here it's one or more ConditioningService objects that together show how traffic for a specific QoSService gets conditioned 🔥
4.4.26. The Aggregation ClassifierElementInClassifierService 🧚
this aggregation is the relationship between a classifier and the classifier elements that provide its fan-out function 🌈 a classifier typically aggregates multiple classifier elements, but a classifier element is only ever aggregated by a single classifier 💅 for more about classifiers and classifier elements, see [DSMODEL] and [DSMIB] 📚
here's the class definition:
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],
ClassifierOrder4.4.26.1. The Reference GroupComponent 🎀
this property is overridden so it's an object reference to a ClassifierService object (not the generic Service object from its superclass) 👑 it also restricts the cardinality of the aggregate to 1..1 (instead of the more generic 0-or-more) ✨ that's because a ClassifierElement always exists within the context of exactly one ClassifierService, no exceptions 🫶
4.4.26.2. The Reference PartComponent 💖
this property is overridden so it's an object reference to a ClassifierElement object (not the generic Service object) 🦋 this object is a single traffic selector for the classifier 🚦 a ClassifierElement usually has an association to a FilterList, which gives the selection criteria for packets from the traffic stream coming into the classifier, and to a ConditioningService, which packets selected by those criteria go to next 🌸
4.4.26.3. The Property ClassifierOrder 🍓
because the filters for a classifier can overlap, it's necessary to specify the order in which the ClassifierElements aggregated by a ClassifierService get presented with packets coming into the classifier 🧠 this property is an unsigned 32-bit integer representing that order 🔢 values go 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's used to define a set of filter entries (subclasses of FilterEntryBase) that get aggregated by a FilterList ✨
the cardinalities of the aggregation itself are 0..1 on the FilterList end and 0..n on the FilterEntryBase end 🌷 so 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 getting aggregated into a FilterList by this aggregation 👑
see [PCIME] for the definition of this aggregation 📖
4.4.28. The Aggregation ElementInSchedulingService 🌸
this concrete aggregation represents the relationship between a PacketSchedulingService and the set of SchedulingElements that tie it to its inputs 🎀
here's the class definition:
NAME ElementInSchedulingService
DESCRIPTION An aggregation used to tie a
PacketSchedlingService to the
configuration information for one of
the elements (either a QueuingService or
another PacketSchedulingService) that it
schedules.
DERIVED FROM Component
ABSTRACT False
PROPERTIES GroupComponent[ref
PacketSchedulingService[0..1]],
PartComponent[ref
SchedulingElement[1..n]4.4.28.1. The Reference GroupComponent 🫶
this property is overridden in this aggregation so it's an object reference to a PacketSchedulingService object (instead of the more generic Service object from its superclass) 🧚 it also restricts the cardinality of the aggregate to 0..1 (instead of the more generic 0-or-more) 💅 that's because a SchedulingElement exists within the context of at most one PacketSchedulingService 🦋
4.4.28.2. The Reference PartComponent 🎀
Okay bestie, this property gets overridden in this aggregation so it points at a SchedulingElement object 🫶 Its superclass only points at the generic Service object, which is kinda basic compared to what we need here. Each one of these represents a single scheduling element for the scheduler ⏰ It also locks the cardinality of SchedulingElement to 1..n instead of the usual 0-or-more, because a PacketSchedulingService always includes at least one SchedulingElement. No empty schedulers allowed, periodt 💅
5. Intellectual Property Statement 🦋
So the IETF doesn't take a side on whether any intellectual property or other rights claimed for the technology in this document are valid or how far they reach. It also doesn't say it has tried to find any such rights 🤷♀️ If you want the details on how the IETF handles rights for standards-track and standards-related documents, check out BCP-11.
Copies of any rights claims that have been made available for publication, plus any assurances of licenses that are promised, or the outcome of any attempt to get a general license or permission for implementers or users to use those proprietary rights, can be requested from the IETF Secretariat 📬
The IETF also invites anyone who's interested to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to practice this standard. Send that info to the IETF Executive Director 💌
6. Acknowledgements 🫶
The authors want to give a huge shoutout to everyone in the Policy Framework and Differentiated Services working groups for their super helpful comments and suggestions 🌸 Special thanks to Joel Halpern, who gave some key technical direction in the later stages of the document's development. Iconic behaviour from Joel 👑
7. Security Considerations 💀
Okay, serious moment ✨ Like [PCIM] and [PCIME], this document defines an information model that cannot be implemented directly. So security issues don't pop up until it gets mapped to an actual, implementable data model, like a MIB, PIB, or LDAP schema. For a general discussion of security considerations for information models, see [PCIM]. You should also check out [DSMIB], which is actually a data model that matches up pretty closely with the QDDIM information model. It covers the security implications of specific objects in the model 🔐 Don't skip it, it's giving real stakes.
8. References 📚
8.1. Normative References
[CIM] Common Information Model (CIM) Schema, version 2.5.
Distributed Management Task Force, Inc., available at
http://www.dmtf.org/standards/cim_schema_v25.php.
[IEEE802Q] Virtual Bridged Local Area Networks, ANSI/IEEE std 802.1Q,
1998 edition. Approved December 8, 1998
[PCIM] Moore, B., Ellesson, E., Strassner, J. and A. Westerinen,
"Policy Core Information Model - Version 1 Specification",
RFC 3060, February 2001.
[PCIME] Moore, B., Ed., "Policy Core Information Model (PCIM)
Extensions", RFC 3460, January 2003.
[R791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[R2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[R2474] Nichols, K., Blake, S., Baker, F. and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.
[R2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[R3140] Black, D., Brim, S., Carpenter, B. and F. Le Faucheur,
"Per Hop Behavior Identification Codes", RFC 3140, June
2001.8.2. Informative References
[DSMIB] Baker, F., Chan, K. and A. Smith, "Management Information
Base for the Differentiated Services Architecture", RFC
3289, May 2002.
[DSMODEL] Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An
Informal Management Model for DiffServ Routers", RFC 3290,
May 2002.
[PIB] Chan, K., Sahita, R., Hahn, S. and K. McCloghrie,
"Differentiated Services Quality of Service Policy
Information Base", RFC 3317, March 2003.
[POLTERM] Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,
J. and S. Waldbusser, "Terminology for Policy-Based
Management", RFC 3198, November 2001.
[QPIM] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R. and B.
Moore, "Policy Quality of Service (QoS) Information
Model", RFC 3644, November 2003.
[R1633] Braden, R., Clark, D. and S. Shenker, "Integrated Services
in the Internet Architecture: An Overview", RFC 1633,
June 1994.
[R2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated
Service", RFC 2475, December 1998.
[R3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le
Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V. and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002.
[RED] See `http://www.aciri.org/floyd/red.html`9. Appendix A: Naming Instances in a Native CIM Implementation 🧚
Following the precedent set in [PCIM], this document puts the details on how to name instances of its classes in a native CIM implementation right here in an appendix 🍓 Appendix A in [PCIM] already has a long chat about the general principles of CIM naming, so this one won't repeat it. If you want the big-picture version of how instances get named in a native CIM implementation, go read [PCIM].
9.1. Naming Instances of the Classes Derived from Service
Most of the classes in this model come from the CIM class Service. Service is abstract, but it still has key properties in its definition. Why? Because the whole point of key properties in an abstract class is to make sure all of its instantiable subclasses get named the same way ✨ So most classes here name their instances in exactly the same way, using the two key properties they inherit from Service: CreationClassName and Name.
9.2. Naming Instances of Subclasses of FilterEntryBase
Like Service, FilterEntryBase (defined in [PCIME]) is an abstract class with key properties built right into its definition. It has four key properties total. Two of them, SystemCreationClassName and SystemName, get propagated to it through the weak association FilterEntryInSystem. The other two, CreationClassName and Name, belong natively to FilterEntryBase.
So every subclass of FilterEntryBase, including the PreambleFilter class defined here, gets named the same way: with the four key properties it inherits from FilterEntryBase 🦋
9.3. Naming Instances of ProtocolEndpoint
The class ProtocolEndpoint inherits its key properties from its superclass, ServiceAccessPoint. Same naming structure as before, bestie 💜 You get two propagated key properties, SystemCreationClassName and SystemName, plus two native key properties, CreationClassName and Name.
9.4. Naming Instances of BufferPool
BufferPool is the odd one out here 🙈 It isn't derived from Service, so it doesn't inherit its key properties from there. Instead, it inherits one key property, CollectionID, from its superclass Collection, and adds its other key property, CreationClassName, in its own definition.
9.4.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 it is not a key property there. It gets overridden in BufferPool to make it part of this class's composite key 🔑
9.4.2. The Property CreationClassName
This property is a string property 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.
9.5. Naming Instances of SchedulingElement
This class hasn't been incorporated into the CIM model yet, so it doesn't have any CIM naming properties yet 😭 If the normal pattern gets followed, though, instances will be named with two properties, CreationClassName and Name.
10. Authors' Addresses 💌
Bob Moore
P. O. Box 12195, BRQA/B501/G206
3039 Cornwallis Rd.
Research Triangle Park, NC 27709-2195
Phone: (919) 254-4436
EMail: remoore@us.ibm.com
David Durham
Intel
2111 NE 25th Avenue
Hillsboro, OR 97124
Phone: (503) 264-6232
EMail: david.durham@intel.com
John Strassner
INTELLIDEN, Inc.
90 South Cascade Avenue
Colorado Springs, CO 80903
Phone: (719) 785-0648
EMail: john.strassner@intelliden.com
Andrea Westerinen
Cisco Systems, Bldg 20
725 Alder Drive
Milpitas, CA 95035
EMail: andreaw@cisco.com
Walter Weiss
Ellacoya Networks
7 Henry Clay Dr.
Merrimack, NH 03054
Phone: (603) 879-7364
EMail: walterweiss@attbi.com11. Full Copyright Statement 🌈
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and handed out to others, and derivative works that comment on or explain it, or help with its implementation, may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind. The condition is 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. The exceptions are developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or translating 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 assignees.
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society 💖
📦 where this page comes from
- ietf: rfc3670 2004-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms