idnits 2.17.1 draft-ietf-policy-qos-device-info-model-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 120 instances of too long lines in the document, the longest one being 62 characters in excess of 72. ** The abstract seems to contain references ([R2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 87 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 3227 has weird spacing: '... set of input...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2003) is 7649 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'R1825' is defined on line 4315, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CIM' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802Q' -- Possible downref: Non-RFC (?) normative reference: ref. 'R2119' -- Possible downref: Non-RFC (?) normative reference: ref. 'R2474' -- Possible downref: Non-RFC (?) normative reference: ref. 'R2597' -- Possible downref: Non-RFC (?) normative reference: ref. 'R3140' Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Policy Framework Working Group B Moore 2 INTERNET-DRAFT IBM Corporation 3 Category: Standards Track D. Durham 4 Intel 5 J. Strassner 6 INTELLIDEN, Inc. 7 A. Westerinen 8 Cisco Systems 9 W. Weiss 10 Ellacoya 11 May 2003 13 Information Model for Describing Network Device QoS Datapath 14 Mechanisms 16 17 Friday, May 23, 2003, 2:17 PM 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance 22 with all provisions of Section 10 of RFC2026. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other 31 documents at any time. It is inappropriate to use Internet- 32 Drafts as reference material or to cite them other than as "work 33 in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Copyright Notice 43 Copyright (C) The Internet Society (2003). All Rights Reserved. 45 Abstract 47 The purpose of this document is to define an information model to 48 describe the quality of service (QoS) mechanisms inherent in 49 different network devices, including hosts. Broadly speaking, 50 these mechanisms describe the properties common to selecting and 51 conditioning traffic through the forwarding path (datapath) of a 52 network device. This selection and conditioning of traffic in 53 the datapath spans both major QoS architectures: Differentiated 54 Services and Integrated Services. 56 This documenthis document should be used with the QoS Policy 57 Information Model (QPIM) to model how policies can be defined to 58 manage and configure the QoS mechanisms (i.e., the 59 classification, marking, metering, dropping, queuing, and 60 scheduling functionality) of devices. Together, these two drafts 61 describe how to write QoS policy rules to configure and manage 62 the QoS mechanisms present in the datapaths of devices. 64 This document, as well as QPIM, are information models. That is, 65 they represent information independent of a binding to a specific 66 type of repository. 68 Definition of Key Word Usage 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 71 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 72 "OPTIONAL" in this document are to be interpreted as described in 73 RFC 2119 [R2119]. 75 Table of Contents 77 1. Introduction......................................................4 78 1.1. Policy Management Conceptual Model...........................5 79 1.2. Purpose and Relation to Other Policy Work....................6 80 1.3. Typical Examples of Policy Usage.............................7 81 2. Approach..........................................................7 82 2.1. Common Needs Of DiffServ and IntServ.........................7 83 2.2. Specific Needs Of DiffServ...................................9 84 2.3. Specific Needs Of IntServ....................................9 85 3. Methodology.......................................................9 86 3.1. Level of Abstraction for Expressing QoS Policies.............9 87 3.2. Specifying Policy Parameters................................12 88 3.3. Specifying Policy Services..................................12 89 3.4. Level of Abstraction for Defining QoS Attributes and 90 Classes..........................................................13 91 3.5. Characterization of QoS Properties..........................14 92 3.6. QoS Information Model Derivation............................15 93 3.7. Attribute Representation....................................16 94 3.8. Mental Model................................................17 95 3.8.1. The QoSService Class......................................17 96 3.8.2. The ConditioningService Class.............................18 97 3.8.3. Preserving QoS Information from Ingress to Egress.........19 98 3.9. Classifiers, FilterLists, and Filter Entries................21 99 3.10. Modeling of Droppers.......................................23 100 3.10.1. Configuring Head and Tail Droppers.......................23 101 3.10.2. Configuring RED Droppers.................................24 102 3.11. Modeling of Queues and Schedulers..........................25 103 3.11.1. Simple Hierarchical Scheduler............................25 104 3.11.2. Complex Hierarchical Scheduler...........................27 105 3.11.3. Excess Capacity Scheduler................................28 106 3.11.4. Hierarchical CBQ Scheduler...............................30 107 4. The Class Hierarchy..............................................32 108 4.1. Associations and Aggregations...............................33 109 4.2. The Structure of the Class Hierarchies......................33 110 4.3. Class Definitions...........................................38 111 4.3.1. The Abstract Class ManagedElement.........................38 112 4.3.2. The Abstract Class ManagedSystemElement...................38 113 4.3.3. The Abstract Class LogicalElement.........................39 114 4.3.4. The Abstract Class Service................................39 115 4.3.5. The Class ConditioningService.............................39 116 4.3.6. The Class ClassifierService...............................40 117 4.3.7. The Class ClassifierElement...............................41 118 4.3.8. The Class MeterService....................................42 119 4.3.9. The Class AverageRateMeterService.........................43 120 4.3.10. The Class EWMAMeterService...............................44 121 4.3.11. The Class TokenBucketMeterService........................45 122 4.3.12. The Class MarkerService..................................46 123 4.3.13. The Class PreambleMarkerService..........................47 124 4.3.14. The Class ToSMarkerService...............................47 125 4.3.15. The Class DSCPMarkerService..............................48 126 4.3.16. The Class 8021QMarkerService.............................49 127 4.3.17. The Class DropperService.................................49 128 4.3.18. The Class HeadTailDropperService.........................51 129 4.3.19. The Class REDDropperService..............................51 130 4.3.20. The Class QueuingService.................................53 131 4.3.21. The Class PacketSchedulingService........................54 132 4.3.22. The Class NonWorkConservingSchedulingService.............55 133 4.3.23. The Class QoSService.....................................55 134 4.3.24. The Class DiffServService................................56 135 4.3.25. The Class AFService......................................57 136 4.3.26. The Class FlowService....................................58 137 4.3.27. The Class DropThresholdCalculationService................59 138 4.3.28. The Abstract Class FilterEntryBase.......................59 139 4.3.29. The Class IPHeaderFilter.................................60 140 4.3.30. The Class 8021Filter.....................................60 141 4.3.31. The Class PreambleFilter.................................60 142 4.3.32. The Class FilterList.....................................61 143 4.3.33. The Abstract Class ServiceAccessPoint....................61 144 4.3.34. The Class ProtocolEndpoint...............................61 145 4.3.35. The Abstract Class Collection............................61 146 4.3.36. The Abstract Class CollectionOfMSEs......................62 147 4.3.37. The Class BufferPool.....................................62 148 4.3.38. The Abstract Class SchedulingElement.....................63 149 4.3.39. The Class AllocationSchedulingElement....................64 150 4.3.40. The Class WRRSchedulingElement...........................65 151 4.3.41. The Class PrioritySchedulingElement......................66 152 4.3.42. The Class BoundedPrioritySchedulingElement...............67 153 4.4. Association Definitions.....................................68 154 4.4.1. The Abstract Association Dependency.......................68 155 4.4.2. The Association ServiceSAPDependency......................68 156 4.4.3. The Association IngressConditioningServiceOnEndpoint......68 157 4.4.4. The Association EgressConditioningServiceOnEndpoint.......69 158 4.4.5. The Association HeadTailDropQueueBinding..................69 159 4.4.6. The Association CalculationBasedOnQueue...................70 160 4.4.7. The Association ProvidesServiceToElement..................71 161 4.4.8. The Association ServiceServiceDependency..................71 162 4.4.9. The Association CalculationServiceForDropper..............71 163 4.4.10. The Association QueueAllocation..........................72 164 4.4.11. The Association ClassifierElementUsesFilterList..........73 165 4.4.12. The Association AFRelatedServices........................74 166 4.4.13. The Association NextService..............................74 167 4.4.14. The Association NextServiceAfterClassifierElement........75 168 4.4.15. The Association NextScheduler............................76 169 4.4.16. The Association FailNextScheduler........................77 170 4.4.17. The Association NextServiceAfterMeter....................78 171 4.4.18. The Association QueueToSchedule..........................79 172 4.4.19. The Association SchedulingServiceToSchedule..............80 173 4.4.20. The Aggregation MemberOfCollection.......................81 174 4.4.21. The Aggregation CollectedBufferPool......................81 175 4.4.22. The Abstract Aggregation Component.......................82 176 4.4.23. The Aggregation ServiceComponent.........................82 177 4.4.24. The Aggregation QoSSubService............................82 178 4.4.25. The Aggregation QoSConditioningSubService................83 179 4.4.26. The Aggregation ClassifierElementInClassifierService.....84 180 4.4.27. The Aggregation EntriesInFilterList......................85 181 4.4.28. The Aggregation ElementInSchedulingService...............85 182 5. Intellectual Property............................................86 183 6. Acknowledgements.................................................86 184 7. Security Considerations..........................................87 185 8. Normative References.............................................87 186 9. Informative References...........................................88 187 10. Authors' Addresses..............................................88 188 11. Full Copyright Statement........................................89 189 12. Appendix A: Naming Instances in a Native CIM Implementation....90 190 12.1. Naming Instances of the Classes Derived from Service.......90 191 12.2. Naming Instances of Subclasses of FilterEntryBase..........90 192 12.3. Naming Instances of ProtocolEndpoint.......................90 193 12.4. Naming Instances of BufferPool.............................90 194 12.4.1. The Property CollectionID................................91 195 12.4.2. The Property CreationClassName...........................91 196 12.5. Naming Instances of SchedulingElement......................91 198 1. Introduction 200 The purpose of this document is to define an information model to 201 describe the quality of service (QoS) mechanisms inherent in 202 different network devices, including hosts. Broadly speaking, 203 these mechanisms describe the attributes common to selecting and 204 conditioning traffic through the forwarding path (datapath) of a 205 network device. This selection and conditioning of traffic in 206 the datapath spans both major QoS architectures: Differentiated 207 Services (see [R2475]) and Integrated Services (see [R1633]). 209 This document is intended to be used with the QoS Policy 210 Information Model [QPIM] to model how policies can be defined to 211 manage and configure the QoS mechanisms (i.e., the 212 classification, marking, metering, dropping, queuing, and 213 scheduling functionality) of devices. Together, these two drafts 214 describe how to write QoS policy rules to configure and manage 215 the QoS mechanisms present in the datapaths of devices. 217 This document, as well as [QPIM], are information models. That 218 is, they represent information independent of a binding to a 219 specific type of repository. A separate draft could be written 220 to provide a mapping of the data contained in this document to a 221 form suitable for implementation in a directory that uses (L)DAP 222 as its access protocol. Similarly, a draft could be written to 223 provide a mapping of the data in [QPIM] to a directory. 224 Together, these four drafts (information models and directory 225 schema mappings) would then describe how to write QoS policy 226 rules that can be used to store information in directories to 227 configure device QoS mechanisms. 229 The approach taken in this document defines a common set of 230 classes that can be used to model QoS in a device datapath. 231 Vendors can then map these classes, either directly or using an 232 intervening format like a COP-PR PIB, to their own device- 233 specific implementations. Note that the admission control 234 element of Integrated Services is not included in the scope of 235 this model. 237 The design of the class, association, and aggregation hierarchies 238 described in this document is influenced by the Network QoS 239 submodel defined by the Distributed Management Task Force (DMTF) 240 - see [CIM]. These hierarchies are not derived from the Policy 241 Core Information Model [PCIM]. This is because the modeling of 242 the QoS mechanisms of a device is separate and distinct from the 243 modeling of policies that manage those mechanisms. Hence, there 244 is a need to separate QoS mechanisms (this document) from their 245 control (specified using the generic policy draft [PCIM] 246 augmented by the QoS Policy draft [QPIM]). 248 While it is not a policy model per se, this document does have a 249 dependency on the Policy Core Information Model Extensions draft 250 [PCIME]. The device-level packet filtering, through which a 251 Classifier splits a traffic stream into multiple streams, is 252 based on the FilterEntryBase and FilterList classes defined in 253 [PCIME]. 255 1.1. Policy Management Conceptual Model 257 The Policy Core Information Model [PCIM] describes a general 258 methodology for constructing policy rules. PCIM Extensions 259 [PCIME] updates and extends the original PCIM. A policy rule 260 aggregates a set of policy conditions and an ordered set of 261 policy actions. The semantics of a policy rule are such that if 262 the set of conditions evaluates to TRUE, then the set of actions 263 are executed. 265 Policy conditions and actions have two principal components: 266 operands and operators. Operands can be constants or variables. 267 To specify a policy, it is necessary to specify: 269 o the operands to be examined (also known as state variables); 271 o the operands to be changed (also known as configuration 272 variables); 274 o the relationships between these two sets of operands. 276 Operands can be specified at a high-level, such as Joe (a user) 277 or Gold (a service). Operands can also be specified at a much 278 finer level of detail, one that is much closer to the operation 279 of the device. Examples of the latter include an IP Address or a 280 queue's bandwidth allocation. Implicit in the use of operands is 281 the binding of legal values or ranges of values to an operand. 282 For example, the value of an IP address cannot be an integer. 283 The concepts of operands and their ranges are defined in [PCIME]. 285 The second component of policy conditions and actions is a set of 286 operators. Operators can express both relationships (greater 287 than, member of a set, Boolean OR, etc.) and assignments. 288 Together, operators and operands can express a variety of 289 conditions and actions, such as: 291 If Bob is an Engineer... 292 If the source IP address is in the Marketing Subnet... 293 Set Joe's IP address to 192.0.2.100 294 Limit the bandwidth of application x to 10 Mb 296 We recognize that the definition of operator semantics is 297 critical to the definition of policies. However, the definition 298 of these operators is beyond the scope of this document. Rather, 299 this document (with [QPIM]) takes the first steps in identifying 300 and standardizing a set of properties (operands) for use in 301 defining policies for Differentiated and Integrated Services. 303 1.2. Purpose and Relation to Other Policy Work 305 This model establishes a canonical model of the QoS mechanisms of 306 a network device (e.g., a router, switch, or host) that is 307 independent of any specific type of network device. This enables 308 traffic conditioning to be described using a common set of 309 abstractions, modeled as a set of services and sub-services. 311 When the concepts of this document are used in conjunction with 312 the concepts of [QPIM], one is able to define policies that bind 313 the services in a network to the needs of applications using that 314 network. In other words, the business requirements of an 315 organization can be reflected in one set of policies, and those 316 policies can be translated to a lower-level set of policies that 317 control and manage the configuration and operation of network 318 devices. 320 1.3. Typical Examples of Policy Usage 322 Policies could be implemented as low-level rules using the 323 information model described in this specification. For example, 324 in a low-level policy, a condition could be represented as an 325 evaluation of a specific attribute from this model. Therefore, a 326 condition such as "If filter = HTTP" would be interpreted as a 327 test determining whether any HTTP filters have been defined for 328 the device. A high-level policy, such as "If protocol = HTTP, 329 then mark with Differentiated Services Code Point (DSCP) 24," 330 would be expressed as a series of actions in a low-level policy 331 using the classes and attributes described below: 333 1. Create HTTP filter 334 2. Create DSCP marker with the value of 24 335 3. Bind the HTTP filter to the DSCP marker 337 Note that unlike "mark with DSCP 24," these low-level actions are 338 not performed on a packet as it passes through the device. 339 Rather, they are configuration actions performed on the device 340 itself, to make it ready to perform the correct action(s) on the 341 correct packet(s). The act of moving from a high-level policy 342 rule to the correct set of low-level device configuration actions 343 is an example of what [POLTERM] characterizes as "policy 344 translation" or "policy conversion". 346 2. Approach 348 QoS activities in the IETF have mainly focused in two areas, 349 Integrated Services (IntServ) and Differentiated Services 350 (DiffServ) (see [POLTERM], [R1633] and [R2475]). This document 351 focuses on the specification of QoS properties and classes for 352 modeling the datapath where packet traffic is conditioned. 353 However, the framework defined by the classes in this document 354 has been designed with the needs of the admission control portion 355 of IntServ in mind as well. 357 2.1. Common Needs Of DiffServ and IntServ 359 First, let us consider IntServ. IntServ has two principal 360 components. One component is embedded in the datapath of the 361 networking device. Its functions include the classification and 362 policing of individual flows, and scheduling admitted packets for 363 the outbound link. The other component of IntServ is admission 364 control, which focuses on the management of the signaling 365 protocol (e.g., the PATH and RESV messages of RSVP). This 366 component processes reservation requests, manages bandwidth, 367 outsources decision making to policy servers, and interacts with 368 the Routing Table manager. 370 We will consider RSVP when defining the structure of this 371 information model. As this document focuses on the datapath, 372 elements of RSVP applicable to the datapath will be considered in 373 the structure of the classes. The complete IntServ device model 374 will, as we have indicated earlier, be addressed in a subsequent 375 document. 377 This document models a small subset of the QoS policy problem, in 378 hopes of constructing a methodology that can be adapted for other 379 aspects of QoS in particular, and of policy construction in 380 general. The focus in this document is on QoS for devices that 381 implement traffic conditioning in the datapath. 383 DiffServ operates exclusively in the datapath. It has all of the 384 same components of the IntServ datapath, with two major 385 differences. First, DiffServ classifies packets based solely on 386 their DSCP field, whereas IntServ examines a subset of a standard 387 flow's addressing 5-tuple. The exception to this rule occurs in 388 a router or host at the boundary of a DiffServ domain. A device 389 in this position may examine a packet's DSCP, its addressing 5- 390 tuple, other fields in the packet, or even information wholly 391 outside the packet, in determining the DSCP value with which to 392 mark the packet prior to its transfer into the DiffServ domain. 393 However, routers in the interior of a DiffServ domain will only 394 need to classify based on the DSCP field. 396 The second difference between IntServ and DiffServ is that the 397 signaling protocol used in IntServ (e.g., RSVP) affects the 398 configuration of the datapath in a more dynamic fashion. This is 399 because each newly admitted RSVP reservation requires a 400 reconfiguration of the datapath. In contrast, DiffServ requires 401 far fewer changes to the datapath after the Per Hop Behaviors 402 (PHBs) have been configured. 404 The approach advocated in this document for the creation of 405 policies that control the various QoS mechanisms of networking 406 devices is to first identify the attributes with which policies 407 are to be constructed. These attributes are the parameters used 408 in expressions that are necessary to construct policies. There 409 is also a parallel desire to define the operators, relations, and 410 precedence constructs necessary to construct the conditions and 411 actions that constitute these policies. However, these efforts 412 are beyond the scope of this document. 414 2.2. Specific Needs Of DiffServ 416 DiffServ-specific rules focus on two particular areas: the core 417 and the edges of the network. As explained in the DiffServ 418 Architecture document [R2475], devices at the edge of the network 419 classify traffic into different traffic streams. The core of the 420 network then forwards traffic from different streams by using a 421 set of Per Hop Behaviors (PHBs). A DSCP identifies each PHB. 422 The DSCP is part of the IP header of each packet (as described in 423 [R2474]). This enables multiple traffic streams to be aggregated 424 into a small number of aggregated traffic streams, where each 425 aggregate traffic stream is identified by a particular DSCP, and 426 forwarded using a particular PHB. 428 The attributes used to manipulate QoS capabilities in the core of 429 the network primarily address the behavioral characteristics of 430 each supported PHB. At the edges of the DiffServ network, the 431 additional complexities of flow classification, policing, RSVP 432 mappings, remarkings, and other factors have to be considered. 433 Additional modeling will be required in this area. However, 434 first, the standards for edges of the DiffServ network need more 435 detail - to allow the edges to be incorporated into the policy 436 model. 438 2.3. Specific Needs Of IntServ 440 This document focuses exclusively on the forwarding aspects of 441 network QoS. Therefore, while the forwarding aspects of IntServ 442 are considered, the management of IntServ is not considered. 443 This topic will be addressed in a future draft. 445 3. Methodology 447 There is a clear need to define attributes and behavior that 448 together define how traffic should be conditioned. This document 449 defines a set of classes and relationships that represent the QoS 450 mechanisms used to condition traffic; [QPIM] is used to define 451 policies to control the QoS mechanisms defined in this document. 453 However, some very basic issues need to be considered when 454 combining these drafts. Considering these issues should help in 455 constructing a schema for managing the operation and 456 configuration of network QoS mechanisms through the use of QoS 457 policies. 459 3.1. Level of Abstraction for Expressing QoS Policies 461 The first issue requiring consideration is the level of 462 abstraction at which QoS policies should be expressed. If we 463 consider policies as a set of rules used to react to events and 464 manipulate attributes or generate new events, we realize that 465 policy represents a continuum of specifications that relate 466 business goals and rules to the conditioning of traffic done by a 467 device or a set of devices. An example of a business level policy 468 might be: from 1:00 pm PST to 7:00 am EST, sell off 40% of the 469 network capacity on the open market. In contrast, a device- 470 specific policy might be: if the queue depth grows at a geometric 471 rate over a specified duration, trigger a potential link failure 472 event. 474 A general model for this continuum is shown in Figure 1 below. 476 +---------------------+ 477 | High-Level Business | Not directly related to device 478 | Policies | operation and configuration details 479 +---------------------+ 480 | 481 | 482 +---------V-----------+ 483 | Device-Independent | Translate high-level policies to 484 | Policies | generic device operational and 485 +---------------------+ configuration information 486 | 487 | 488 +---------V-----------+ 489 | Device-Dependent | Translate generic device information 490 | Policies | to specify how particular devices 491 +---------------------+ should operate and be configured 493 Figure 1. The Policy Continuum 495 High-level business policies are used to express the requirements 496 of the different applications, and prioritize which applications 497 get "better" treatment when the network is congested. The goal, 498 then, is to use policies to relate the operational and 499 configuration needs of a device directly to the business rules 500 that the network administrator is trying to implement in the 501 network that the device belongs to. 503 Device-independent policies translate business policies into a 504 set of generalized operational and configuration policies that 505 are independent of any specific device, but dependent on a 506 particular set of QoS mechanisms, such as random early detection 507 (RED) dropping or weighted round robin scheduling. Not only does 508 this enable different types of devices (routers, switches, hosts, 509 etc.) to be controlled by QoS policies, it also enables devices 510 made by different vendors that use the same types of QoS 511 mechanisms to be controlled. This enables these different 512 devices to each supply the correct relative conditioning to the 513 same type of traffic. 515 In contrast, device-dependent policies translate device- 516 independent policies into ones that are specific for a given 517 device. The reason that a distinction is made between device- 518 independent and device-dependent policies is that in a given 519 network, many different devices having many different 520 capabilities need to be controlled together. Device-independent 521 policies provide a common layer of abstraction for managing 522 multiple devices of different capabilities, while device- 523 dependent policies implement the specific conditioning that is 524 required. This document provides a common set of abstractions 525 for representing QoS mechanisms in a device-independent way. 527 This document is focused on the device-independent representation 528 of QoS mechanisms. QoS mechanisms are modeled in sufficient 529 detail to provide a common device-independent representation of 530 QoS policies. They can also be used to provide a basis for 531 specialization, enabling each vendor to derive a set of vendor- 532 specific classes that represent how traffic conditioning is done 533 for that vendor's set of devices. 535 3.2. Specifying Policy Parameters 537 Policies are a function of parameters (attributes) and operators 538 (boolean, arithmetic, relational, etc.). Therefore, both need to 539 be defined as part of the same policy in order to correctly 540 condition the traffic. If the parameters of the policy are 541 specified too narrowly, they will reflect the individual 542 implementations of QoS in each device. As there is currently 543 little consensus in the industry on what the correct 544 implementation model for QoS is, most defined attributes would 545 only be applicable to the unique characteristics of a few 546 individual devices. Moreover, standardizing all of these 547 potential implementation alternatives would be a never-ending 548 task as new implementations continued to appear on the market. 550 On the other hand, if the parameters of the policy are specified 551 too broadly, it is impossible to develop meaningful policies. 552 For example, if we concentrate on the so-called Olympic set of 553 policies, a business policy like "Bob gets Gold Service," is 554 clearly meaningless to the large majority of existing devices. 555 This is because the device has no way of determining who Bob is, 556 or what QoS mechanisms should be configured in what way to 557 provide Gold service. 559 Furthermore, Gold service may represent a single service, or it 560 may identify a set of services that are related to each other. 561 In the latter case, these services may have different 562 conditioning characteristics. 564 This document defines a set of parameters that fit into a 565 canonical model for modeling the elements in the forwarding path 566 of a device implementing QoS traffic conditioning. By defining 567 this model in a device-independent way, the needed parameters can 568 be appropriately abstracted. 570 3.3. Specifying Policy Services 572 Administrators want the flexibility to be able to define traffic 573 conditioning without having to have a low-level understanding of 574 the different QoS mechanisms that implement that conditioning. 575 Furthermore, administrators want the flexibility to group 576 different services together, describing a higher-level concept 577 such as "Gold Service". This higher-level service could be 578 viewed as providing the processing to deliver "Gold" quality of 579 service. 581 These two goals dictate the need for the following set of 582 abstractions: 584 o a flexible way to describe a service 586 o must be able to group different services that may use 587 different technologies (e.g., DiffServ and IEEE 802.1Q) 588 together 590 o must be able to define a set of sub-services that 591 together make up a higher-level service 593 o must be able to associate a service and the set of QoS 594 mechanisms that are used to condition traffic for that 595 service 597 o must be able to define policies that manage the QoS 598 mechanisms used to implement a service. 600 This document addresses this set of problems by defining a set of 601 classes and associations that can represent abstract concepts 602 like "Gold Service," and bind each of these abstract services to 603 a specific set of QoS mechanisms that implement the conditioning 604 that they require. Furthermore, this document defines the 605 concept of "sub-services," to enable Gold Service to be defined 606 either as a single service or as a set of services that together 607 should be treated as an atomic entity. 609 Given these abstractions, policies (as defined in [QPIM]) can be 610 written to control the QoS mechanisms and services defined in 611 this document. 613 3.4. Level of Abstraction for Defining QoS Attributes and Classes 615 This document defines a set of classes and properties to support 616 policies that configure device QoS mechanisms. This document 617 concentrates on the representation of services in the datapath 618 that support both DiffServ (for aggregate traffic conditioning) 619 and IntServ (for flow-based traffic conditioning). Classes and 620 properties for modeling IntServ admission control services may be 621 defined in a future draft. 623 The classes and properties in this document are designed to be 624 used in conjunction with the QoS policy classes and properties 625 defined in [QPIM]. For example, to preserve the delay 626 characteristics committed to an end-user, a network administrator 627 may wish to create policies that monitor the queue depths in a 628 device, and adjust resource allocations when delay budgets are at 629 risk (perhaps as a result of a network topology change). The 630 classes and properties in this document define the specific 631 services and mechanisms required to implement those services. 632 The classes and properties defined in [QPIM] provide the overall 633 structure of the policy that manages and configures this service. 635 This combination of low-level specification (using this document) 636 and high-level structuring (using [QPIM]) of network services 637 enables network administrators to define new services required of 638 the network, that are directly related to business goals, while 639 ensuring that such services can be managed. However, this goal 640 (of creating and managing service-oriented policies) can only be 641 realized if policies can be constructed that are capable of 642 supporting diverse implementations of QoS. The solution is to 643 model the QoS capabilities of devices at the behavioral level. 644 This means that for traffic conditioning services realized in the 645 datapath, the model must support the following characteristics: 647 o modeling of a generic network service that has QoS 648 capabilities 650 o modeling of how the traffic conditioning itself is 651 defined 653 o modeling of how statistics are gathered to monitor QoS 654 traffic conditioning services - this facet of the model 655 will be added in a future draft. 657 This document models a network service, and associates it with 658 one or more QoS mechanisms that are used to implement that 659 service. It also models in a canonical form the various 660 components that are used to condition traffic, such that standard 661 as well as custom traffic conditioning services may be described. 663 3.5. Characterization of QoS Properties 665 The QoS properties and classes will be described in more detail 666 in Section 4. However, we should consider the basic 667 characteristics of these properties, to understand the 668 methodology for representing them. 670 There are essentially two types of properties, state and 671 configuration. Configuration properties describe the desired 672 state of a device, and include properties and classes for 673 representing desired or proposed thresholds, bandwidth 674 allocations, and how to classify traffic. State properties 675 describe the actual state of the device. These include 676 properties to represent the current operational values of the 677 attributes in devices configured via the configuration 678 properties, as well as properties that represent state (queue 679 depths, excess capacity consumption, loss rates, and so forth). 681 In order to be correlated and used together, these two types of 682 properties must be modeled using a common information model. The 683 possibility of modeling state properties and their corresponding 684 configuration settings is accomplished using the same classes in 685 this model - although individual instances of the classes would 686 have to be appropriately named or placed in different containers 687 to distinguish current state values from desired configuration 688 settings. 690 State information is addressed in a very limited fashion by 691 QDDIM. Currently, only CurrentQueueDepth is proposed as an 692 attribute on QueuingService. The majority of the model is 693 related to configuration. Given this fact, it is assumed that 694 this model is a direct memory map into a device. All 695 manipulation of model classes and properties directly affects the 696 state of the device. If it is desired to also use these classes 697 to represent desired configuration, that is left to the 698 discretion of the implementor. 700 It is acknowledged that additional properties are needed to 701 completely model current state. However, many of the properties 702 defined in this document represent exactly the state variables 703 that will be configured by the configuration properties. Thus, 704 the definition of the configuration properties has an exact 705 correspondence with the state properties, and can be used in 706 modeling both actual (state) and desired/proposed configuration. 708 3.6. QoS Information Model Derivation 710 The question of context also leads to another question: how does 711 the information specified in the core and QoS policy models 712 ([PCIM], [PCIME], and [QPIM], respectively) integrate with the 713 information defined in this document? Put another way, where 714 should device-independent concepts that lead to device-specific 715 QoS attributes be derived from? 717 Past thinking was that QoS was part of the policy model. This 718 view is not completely accurate, and it leads to confusion. QoS 719 is a set of services that can be controlled using policy. These 720 services are represented as device mechanisms. An important 721 point here is that QoS services, as well as other types of 722 services (e.g., security), are provided by the mechanisms 723 inherent in a given device. This means that not all devices are 724 indeed created equal. For example, although two devices may have 725 the same type of mechanism (e.g., a queue), one may be a simple 726 implementation (i.e., a FIFO queue) whereas one may be much more 727 complex and robust (e.g., class-based weighted fair queuing 728 (CBWFQ)). However, both of these devices can be used to deliver 729 QoS services, and both need to be controlled by policy. Thus, a 730 device-independent policy can instruct the devices to queue 731 certain traffic, and a device-specific policy can be used to 732 control the queuing in each device. 734 Furthermore, policy is used to control these mechanisms, not to 735 represent them. For example, QoS services are implemented with 736 classifiers, meters, markers, droppers, queues, and schedulers. 737 Similarly, security is also a characteristic of devices, as 738 authentication and encryption capabilities represent services 739 that networked devices perform (irrespective of interactions with 740 policy servers). These security services may use some of the 741 same mechanisms that are used by QoS services, such as the 742 concepts of filters. However, they will mostly require different 743 mechanisms than the ones used by QoS, even though both sets of 744 services are implemented in the same devices. 746 Thus, the similarity between the QoS model and models for other 747 services is not so much that they contain a few common 748 mechanisms. Rather, they model how a device implements their 749 respective services. As such, the modeling of QoS should be part 750 of a networking device schema rather than a policy schema. This 751 allows the networking device schema to concentrate on modeling 752 device mechanisms, and the policy schema to focus on the 753 semantics of representing the policy itself (conditions, actions, 754 operators, etc.). While this document concentrates on defining 755 an information model to represent QoS services in a device 756 datapath, the ultimate goal is to be able to apply policies that 757 control these services in network devices. Furthermore, these 758 two schemata (device and policy) must be tightly integrated in 759 order to enable policy to control QoS services. 761 3.7. Attribute Representation 763 The last issue to be considered is the question of how attributes 764 are represented. If QoS attributes are represented as absolute 765 numbers (e.g., Class AF2 gets 2 Mbs of bandwidth), it is more 766 difficult to make them uniform across multiple ports in a device 767 or across multiple devices, because of the broad variation in 768 link capacities. However, expressing attributes in relative or 769 proportional terms (e.g., Class AF2 gets 5% of the total link 770 bandwidth) makes it more difficult to express certain types of 771 conditions and actions, such as: 773 (If ConsumedBandwidth = AssignedBandwidth Then ...) 775 There are really three approaches to addressing this problem: 777 o Multiple properties can be defined to express the same 778 value in various forms. This idea has been rejected 779 because of the difficulty in keeping these different 780 properties synchronized (e.g., when one property changes, 781 the others all have to be updated). 783 o Multi-modal properties can be defined to express the same 784 value, in different terms, based on the access or 785 assignment mode. This option was rejected because it 786 significantly complicates the model and is impossible to 787 express in current directory access protocols (e.g., 788 (L)DAP). 790 o Properties can be expressed as "absolutes", but the 791 operators in the policy schema would need to be more 792 sophisticated. Thus, to represent a percentage, division 793 and multiplication operators are required (e.g., Class 794 AF2 gets .05 * the total link bandwidth). This is the 795 approach that has been taken in this document. 797 3.8. Mental Model 799 The mental model for constructing this schema is based on the 800 work done in the Differentiated Services working group. This 801 schema is based on information provided in the current versions 802 of the DiffServ Informal Management Model [DSMODEL], the DiffServ 803 MIB [DSMIB], the PIB [PIB], as well as on information in the set 804 of RFCs that constitute the basic definition of DiffServ itself 805 ([R2475], [R2474], [R2597], and [R2598]). In addition, a common 806 set of terminology is available in [POLTERM]. 808 This model is built around two fundamental class hierarchies that 809 are bound together using a set of associations. The two class 810 hierarchies derive from the QoSService and ConditioningService 811 base classes. A set of associations relate lower-level 812 QoSService subclasses to higher-level QoS services, relate 813 different types of conditioning services together in processing a 814 traffic class, and relate a set of conditioning services to a 815 specific QoS service. This combination of associations enables 816 us to view the device as providing a set of services that can be 817 configured, in a modular building block fashion, to construct 818 application-specific services. Thus, this document can be used 819 to model existing and future standard as well as application- 820 specific network QoS services. 822 3.8.1. The QoSService Class 824 The first of the classes defined here, QoSService, is used to 825 represent higher-level network services that require special 826 conditioning of their traffic. An instance of QoSService (or one 827 of its subclasses) is used to bring together a group of 828 conditioning services that, from the perspective of the system 829 manager, are all used to deliver a common service. Thus, the set 830 of classifiers, markers, and related conditioning services that 831 provide premium service to the "selected" set of user traffic may 832 be grouped together into a premium QoS service. 834 QoSService has a set of subclasses that represent different 835 approaches to delivering IP services. The currently defined set 836 of subclasses are a FlowService for flow-oriented QoS delivery 837 and a DiffServService for DiffServ aggregate-oriented QoS service 838 delivery. 840 The QoS services can be related to each other as peers, or they 841 can be implemented as subservient services to each other. The 842 QoSSubService aggregation indicates that one or more QoSService 843 objects are subservient to a particular QoSService object. For 844 example, this enables us to define Gold Service as a combination 845 of two DiffServ services, one for high quality traffic treatment, 846 and one for servicing the rest of the traffic. Each of these 847 DiffServService objects would be associated with a set of 848 classifiers, markers, etc, such that the high quality traffic 849 would get EF marking and appropriate queuing. 851 The DiffServService class itself has an AFService subclass. This 852 subclass is used to represent the specific notion that several 853 related markings within the AF PHB Group work together to provide 854 a single service. When other DiffServ PHB Groups are defined 855 that use more than one code point, these will be likely 856 candidates for additional DiffServService subclasses. 858 Technology-specific mappings of these services, representing the 859 specific use of PHB marking or 802.1Q marking, are captured 860 within the ConditioningService hierarchy, rather than in the 861 subclasses of QoSService. 863 These concepts are depicted in Figure 2. Note that both of the 864 associations are aggregations: a QoSService object aggregates 865 both the set of QoSService objects subservient to it, and the set 866 of ConditioningService objects that realize it. See Section 4 867 for class and association definitions. 869 /\______ 870 0..1 \/ | 871 +--------------+ | QoSSubService +---------------+ 872 | |0..n | | | 873 | QoSService |----- | Conditioning | 874 | | | Service | 875 | | | | 876 | |0..n 0..n| | 877 | | /\______________________| | 878 | | \/ QoSConditioning | | 879 +--------------+ SubService +---------------+ 881 Figure 2. QoSService and its Aggregations 883 3.8.2. The ConditioningService Class 885 The goal of the ConditioningService classes is to describe the 886 sequence of traffic conditioning that is applied to a given 887 traffic stream on the ingress interface through which it enters a 888 device, and then on the egress interface through which it leaves 889 the device. This is done using a set of classes and 890 relationships. The routing decision in the device core, which 891 selects which egress interface a particular packet will use, is 892 not represented in this model. 894 A single base class, ConditioningService, is the superclass for a 895 set of subclasses representing the mechanisms that condition 896 traffic. These subclasses define device-independent conditioning 897 primitives (including classifiers, meters, markers, droppers, 898 queues, and schedulers) that together implement the conditioning 899 of traffic on an interface. This model abstracts these services 900 into a common set of modular building blocks that can be used, 901 regardless of device implementation, to model the traffic 902 conditioning internal to a device. 904 The different conditioning mechanisms need to be related to each 905 other to describe how traffic is conditioned. Several important 906 variations of how these services are related together exist: 908 o A particular ingress or egress interface may not require 909 all the types of ConditioningServices. 911 o Multiple instances of the same mechanism may be required 912 on an ingress or egress interface. 914 o There is no set order of application for the 915 ConditioningServices on an ingress or egress interface. 917 Therefore, this model does not dictate a fixed ordering among the 918 subclasses of ConditioningService, or identify a subclass of 919 ConditioningService that must appear first or last among the 920 ConditioningServices on an ingress or egress interface. Instead, 921 this model ties together the various ConditioningService 922 instances on an ingress or egress interface using the 923 NextService, NextServiceAfterMeter, and 924 NextServiceAfterConditioningElement associations. There are also 925 separate associations, called 926 IngressConditioningServiceOnEndpoint and 927 EgressConditioningServiceOnEndpoint, which, respectively, tie an 928 ingress interface to its first ConditioningService, and tie an 929 egress interface to its last ConditioningService(s). 931 3.8.3. Preserving QoS Information from Ingress to Egress 933 There is one important way in which the QDDIM model diverges from 934 the [DSMODEL]. In [DSMODEL], traffic passes through a network 935 device in three stages: 937 o It comes in on an ingress interface, where it may receive 938 QoS conditioning. 940 o It traverses the routing core, where logic outside the 941 scope of QoS determines which egress interface it will 942 use to leave the device. 943 o It may receive further QoS conditioning on the selected 944 egress interface, and then it leaves the device. 946 In this model, no information about the QoS conditioning that a 947 packet receives on the ingress interface is communicated with the 948 packet across the routing core to the egress interface. 950 The QDDIM model relaxes this restriction, to allow information 951 about the treatment that a packet received on an ingress 952 interface to be communicated along with the packet to the egress 953 interface. (This relaxation adds a capability that is present in 954 many network devices.) QDDIM represents this information 955 transfer in terms of a packet preamble, which is how many devices 956 implement it. But implementations are free to use other 957 mechanisms to achieve the same result. 959 +---------+ 960 | Meter-A | 961 a | | b d 962 --->| In-|---PM-1---> 963 | | c e 964 | Out-|---PM-2---> 965 +---------+ 967 Figure 3: Meter Followed by Two Preamble Markers 969 Figure 3 shows an example in which meter results are captured in 970 a packet preamble. The arrows labeled with single letters 971 represent instances of either the NextService association (a, d, 972 and e), or of its peer association NextServiceAfterMeter (b and 973 c). PreambleMarker PM-1 adds to the packet preamble an 974 indication that the packet exited Meter A as conforming traffic. 975 Similarly, PreambleMarker PM-2 adds to the preambles of packets 976 that come through it indications that they exited Meter A as 977 nonconforming traffic. A PreambleMarker appends its information 978 to whatever is already present in a packet preamble, as opposed 979 to overwriting what is already there. 981 To foster interoperability, the basic format of the information 982 captured by a PreambleMarker is specified. (Implementations, of 983 course, are free to represent this information in a different way 984 internally - this is just how it is represented in the model.) 985 The information is represented by an ordered, multi-valued string 986 property FilterItemList, where each individual value of the 987 property is of the form ",". When a PreambleMarker 988 "appends" its information to the information that was already 989 present in a packet preamble, it does so by adding additional 990 items of the indicated format to the end of the list. 992 QDDIM provides a limited set of 's that a PreambleMarker 993 may use: 995 o ConformingFromMeter: the value is the name of the meter. 996 o PartConformingFromMeter: the value is the name of the 997 meter. 998 o NonConformingFromMeter: the value is the name of the 999 meter. 1000 o VlanId: the value is the virtual LAN identifier (VLAN 1001 ID). 1003 Implementations may recognize other 's in addition to 1004 these. If collisions of implementation-specific 's become 1005 a problem, it is possible that 's may become an IANA- 1006 administered range in a future revision of this document. 1008 To make use of the information that a PreambleMarker stores in a 1009 packet preamble, a specific subclass PreambleFilter of 1010 FilterEntryBase is defined, to match on the "," 1011 strings. To simplify the case where there's just a single level 1012 of metering in a device, but different individual meters on each 1013 ingress interface, PreambleFilter allows a wildcard "any" for the 1014 part of the three meter-related filters. With this 1015 wildcard, an administrator can specify a Classifier to select all 1016 packets that were found to be conforming (or partially 1017 conforming, or non-conforming) by their respective meters, 1018 without having to name each meter individually in a separate 1019 ClassifierElement. 1021 Once a meter result has been stored in a packet preamble, it is 1022 available for any subsequent Classifier to use. So while the 1023 motivation for this capability has been described in terms of 1024 preserving QoS conditioning information from an ingress interface 1025 to an egress interface, a prior meter result may also be used for 1026 classifying packets later in the datapath on the same interface 1027 where the meter resides. 1029 3.9. Classifiers, FilterLists, and Filter Entries 1031 This document uses a number of classes to model the classifiers 1032 defined in [DSMODEL]: ClassifierService, ClassifierElement, 1033 FilterList, FilterEntryBase, and various subclasses of 1034 FilterEntryBase. There are also two associations involved: 1035 ClassifierElementUsesFilterList and EntriesInFilterList. The 1036 QDDIM model makes no use of CIM's FilterEntry class. 1038 In [DSMODEL], a single traffic stream coming into a classifier is 1039 split into multiple traffic streams leaving it, based on which of 1040 an ordered set of filters each packet in the incoming stream 1041 matches. A filter matches either a field in the packet itself, 1042 or possibly other attributes associated with the packet. In the 1043 case of a multi-field (MF) classifier, packets are assigned to 1044 output streams based on the contents of multiple fields in the 1045 packet header. For example, an MF classifier might assign 1046 packets to an output stream based on their complete IP-addressing 1047 5-tuple. 1049 To optimize the representation of MF classifiers, subclasses of 1050 FilterEntryBase are introduced, which allow multiple related 1051 packet header fields to be represented in a single object. These 1052 subclasses are IPHeaderFilter and 8021Filter. With 1053 IPHeaderFilter, for example, criteria for selecting packets based 1054 on all five of the IP 5-tuple header fields and the DiffServ DSCP 1055 can be represented by a FilterList containing one IPHeaderFilter 1056 object. Because these two classes have applications beyond those 1057 considered in this document, they, as well as the abstract class 1058 FilterEntryBase, are defined in the more general draft [PCIME] 1059 rather than here. 1061 The FilterList object is always needed, even if it contains only 1062 one filter entry (that is, one FilterEntryBase subclass) object. 1063 This is because a ClassifierElement can only be associated with a 1064 Filter List, as opposed to an individual FilterEntry. FilterList 1065 is also defined in [PCIME]. 1067 The EntriesInFilterList aggregation (also defined in [PCIME]) has 1068 a property EntrySequence, which in the past (in CIM) could be 1069 used to specify an evaluation order on the filter entries in a 1070 FilterList. Now, however, the EntrySequence property supports 1071 only a single value: '0'. This value indicates that the 1072 FilterEntries are ANDed together to determine whether a packet 1073 matches the MF selector that the FilterList represents. 1075 A ClassifierElement specifies the starting point for a specific 1076 policy or data path. Each ClassifierElement uses the 1077 NextServiceAfterClassifierElement association to determine the 1078 next conditioning service to apply for packets to. 1080 A ClassifierService defines a grouping of ClassifierElements. 1081 There are certain instances where a ClassifierService actually 1082 specifies an aggregation of ClassifierServices. One practical 1083 case would be where each ClassifierService specifies a group of 1084 policies associated with a particular application and another 1085 ClassifierService groups the application-specific 1086 ClassifierService instances. In this particular case, the 1087 application-specific ClassifierService instances are specified 1088 once, but unique combinations of these ClassifierServices are 1089 specified, as needed, using other ClassifierService instances. 1090 ClassifierService instances grouping other ClassifierService 1091 instances may not specify a FilterList using the 1092 ClassifierElementUsesFilterList association. This special use of 1093 ClassifierService serves just as a Classifier collecting 1094 function. 1096 3.10. Modeling of Droppers 1098 In [DSMODEL], a distinction is made between absolute droppers and 1099 algorithmic droppers. In QDDIM, both of these types of droppers 1100 are modeled with the DropperService class, or with one of its 1101 subclasses. In both cases, the queue from which the dropper 1102 drops packets is tied to the dropper by an instance of the 1103 NextService association. The dropper always plays the 1104 PrecedingService role in these associations, and the queue always 1105 plays the FollowingService role. There is always exactly one 1106 queue from which a dropper drops packets. 1108 Since an absolute dropper drops all packets in its queue, it 1109 needs no configuration beyond a NextService tie to that queue. 1110 For an algorithmic dropper, however, further configuration is 1111 needed: 1113 o a specific drop algorithm; 1114 o parameters for the algorithm (for example, token bucket 1115 size); 1116 o the source(s) of input(s) to the algorithm; 1117 o possibly per-input parameters for the algorithm. 1119 The first two of these items are represented by properties of the 1120 DropperService class, or properties of one of its subclasses. 1121 The last two, however, involve additional classes and 1122 associations. 1124 3.10.1. Configuring Head and Tail Droppers 1126 The HeadTailDropQueueBinding is the association that identifies 1127 the inputs for the algorithm executed by a tail dropper. This 1128 association is not used for a head dropper, because a head 1129 dropper always has exactly one input to its drop algorithm, and 1130 this input is always the queue from which it drops packets. For 1131 a tail dropper, this association is defined to have a many-to- 1132 many cardinality. There are, however, two distinct cases: 1134 One dropper bound to many queues: This represents the case where 1135 the drop algorithm for the dropper involves inputs from more than 1136 one queue. The dropper still drops from only one queue, the one 1137 to which it is tied by a NextService association. But the drop 1138 decision may be influenced by the state of several queues. For 1139 the classes HeadTailDropper and HeadTailDropQueueBinding, the 1140 rule for combining the multiple inputs is simple addition: if the 1141 sum of the lengths of the monitored queues exceeds the dropper's 1142 QueueThreshold value, then packets are dropped. This rule for 1143 combining inputs may, however, be overridden by a different rule 1144 in subclasses of one or both of these classes. 1146 One queue bound to many droppers: This represents the case where 1147 the state of one queue (which is typically also the queue from 1148 which packets are dropped) provides an input to multiple 1149 droppers' drop algorithms. A use case here is a classifier that 1150 splits a traffic stream into, say, four parts, representing four 1151 classes of traffic. Each of the parts goes through a separate 1152 HeadTailDropper, then they're re-merged onto the same queue. The 1153 net is a single queue containing packets of four traffic types, 1154 with, say, the following drop thresholds: 1156 o Class 1 - 90% full 1157 o Class 2 - 80% full 1158 o Class 3 - 70% full 1159 o Class 4 - 50% full 1161 Here the percentages represent the overall state of the queue. 1162 With this configuration, when the queue in question becomes 50% 1163 full, Class 4 packets will be dropped rather than joining the 1164 queue, when it becomes 70% full, Class 3 and 4 packets will be 1165 dropped, etc. 1167 The two cases described here can also occur together, if a 1168 dropper receives inputs from multiple queues, one or more of 1169 which are also providing inputs to other droppers. 1171 3.10.2. Configuring RED Droppers 1173 Like a tail dropper, a RED dropper, represented by an instance of 1174 the REDDropperService class, may take as its inputs the states of 1175 multiple queues. In this case, however, there is an additional 1176 step: each of these inputs may be smoothed before the RED dropper 1177 uses it, and the smoothing process itself must be parameterized. 1178 Consequently, in addition to REDDropperService and 1179 QueuingService, a third class, DropThresholdCalculationService, 1180 is introduced, to represent the per-queue parameterization of 1181 this smoothing process. 1183 The following instance diagram illustrates how these classes work 1184 with each other: 1186 RDSvc-A 1187 | | | 1188 +-----+ | +-----+ 1189 | | | 1190 DTCS-1 DTCS-2 DTCS-3 1191 | | | 1192 Q-1 Q-2 Q-3 1194 Figure 4. Inputs for a RED Dropper 1196 So REDDropperService-A (RDSvc-A) is using inputs from three 1197 queues to make its drop decision. (As always, RDSvc-A is linked 1198 to the queue from which it drops packets via the NextService 1199 association.) For each of these three queues, there is a 1200 (DropThresholdCalculationService) DTCS instance that represents 1201 the smoothing weight and time interval to use when looking at 1202 that queue. Thus each DTCS instance is tied to exactly one 1203 queue, although a single queue may be examined (with different 1204 weight and time values) by multiple DTCS instances. Also, a DTCS 1205 instance and the queue behind it can be thought of as a "unit of 1206 reusability." So a single DTCS can be referred to by multiple 1207 RDSvc's. 1209 Unless it is overridden by a different rule in a subclass of 1210 REDDropperService, the rule that a RED dropper uses to combine 1211 the smoothed inputs from the DTCS's to create a value to use in 1212 making its drop decision is simple addition. 1214 3.11. Modeling of Queues and Schedulers 1216 In order to appreciate the rationale behind this rather complex 1217 model for scheduling, we must consider the rather complex nature 1218 of schedulers, as well as the extreme variations in algorithms 1219 and implementations. Although these variations are broad, we 1220 have identified four examples that serve to test the model and 1221 justify its complexity. 1223 3.11.1. Simple Hierarchical Scheduler 1225 A simple, hierarchical scheduler has the following properties. 1226 First, when a scheduling opportunity is given to a set of queues, 1227 a single, viable queue is determined based on some scheduling 1228 criteria, such as bandwidth or priority. The output of the 1229 scheduler is the input to another scheduler that treats the first 1230 scheduler (and its queues) as a single logical queue. Hence, if 1231 the first scheduler determined the appropriate packet to release 1232 based on a priority assigned to each queue, the second scheduler 1233 might specify a bandwidth limit/allocation for the entire set of 1234 queues aggregated by the first scheduler. 1236 +----------+ NextService 1237 |QueuingSvc+----------------------------------------------+ 1238 | Name=EF1 | | 1239 | | QueueTo +--------------+ ElementSched | 1240 | +------------+PrioritySched +---------------+ | 1241 +----------+ Schedule |Element | Service | | 1242 | Name=EF1-Pri | | v 1243 | Priority=1 | +-----------+-+-+ 1244 +--------------+ |SchedulingSvc + 1245 | Name=PriSched1+ 1246 +--------------+ +----------+--+-+ 1247 |PrioritySched | ElementSched | ^ 1248 +----------+ |Element +---------------+ | 1249 |QueuingSvc| QueueTo | Name=AF1x-Pri| Service | 1250 | Name=AF1x+------------+ Priority=2 | | 1251 | | Schedule +--------------+ | 1252 | | NextService | 1253 | +----------------------------------------------+ 1254 +----------+ 1255 . 1256 : 1257 +---------------+ NextScheduler 1258 |SchedulingSvc +--------------------------------------------+ 1259 | Name=PriSched1| | 1260 +-------+-------+ +--------------------+ElementSchedSvc| 1261 | SchedToSched |AllocationScheduling+--------+ | 1262 +---------------+Element | | | 1263 | Name=PriSched1-Band| | | 1264 | Units=Bytes | | v 1265 | Bandwidth=100 | +------+------+--+ 1266 +--------------------+ |SchedulingSvc | 1267 | Name=BandSched1| 1268 +--------------------+ +------+------+--+ 1269 |AllocationScheduling| | ^ 1270 +---------------+ |Element +--------+ | 1271 |QueuingService | | Name=BE-Band |ElementSchedSvc| 1272 | Name=BE |QueueTo+ Units=Bytes | | 1273 | |-------+ Bandwidth=50 | | 1274 | |Sched +--------------------+ | 1275 | | NextService | 1276 | +--------------------------------------------+ 1277 +---------------+ 1279 Figure 5. Example 1: Simple Hierarchical Scheduler 1281 Figure 5 illustrates the example and how it would be instantiated 1282 using the model. In the figure, NextService determines the first 1283 scheduler after the queue. NextScheduler determines the 1284 subsequent ordering of schedulers. In addition, the 1285 ElementSchedulingService association determines the set of 1286 scheduling parameters used by a specific scheduler. Scheduling 1287 parameters can be bound either to queues or to schedulers. In 1288 the case of the SchedulingElement EF1-Pri, the binding is to a 1289 queue, so the QueueToSchedule association is used. In the case 1290 of the SchedulingElement PriSched1-Band, the binding is to 1291 another scheduler, so the SchedulerToSchedule association is 1292 used. Note that due to space constraints of the document, the 1293 SchedulingService PRISched1 is represented twice, to show how it 1294 is connected to all the other objects. 1296 3.11.2. Complex Hierarchical Scheduler 1298 A complex, hierarchical scheduler has the same characteristics as 1299 a simple scheduler, except that the criteria for the second 1300 scheduler are determined on a per queue basis rather than on an 1301 aggregate basis. One scenario might be a set of bounded priority 1302 schedulers. In this case, each queue is assigned a relative 1303 priority. However, each queue is also not allowed to exceed a 1304 bandwidth allocation that is unique to that queue. In order to 1305 support this scenario, the queue must be bound to two separate 1306 schedulers. Figure 6 illustrates this situation, by describing 1307 an EF queue and a best effort (BE) queue both pointing to a 1308 priority scheduler via the NextService association. The 1309 NextScheduler association between the priority scheduler and the 1310 bandwidth scheduler in turn defines the ordering of the 1311 scheduling hierarchy. Also note that each scheduler has a 1312 distinct set of scheduling parameters that are bound back to each 1313 queue. This demonstrates the need to support two or more 1314 parameter sets on a per queue basis. 1316 +----------------+ 1317 |QueuingService | 1318 | Name=EF | 1319 | |QueueTo +----------------+ElementSchedSvc 1320 | +----------+AllocationSched +--------+ 1321 ++---+-----------+Schedule |Element | | 1322 | | | Name=BandEF | | 1323 | |QueueTo | Units=Bytes | | 1324 | |Schedule | Bandwidth=100 | | 1325 | | +----------------+ +------+---------+ 1326 | | |SchedulingSvc | 1327 | | +------------------+ | Name=BandSched | 1328 | +------+PriorityScheduling| +------------+--++ 1329 | |Element | ^ | 1330 | | Name=PriEF |ElementSchedSvc | | 1331 | | Priority=1 +---------------------+ | | 1332 | +------------------+ | | | 1333 |NextService | | | 1334 +-------------------------------------------------+ | | | 1335 | | | | 1336 NextService | | | | 1337 +-----------------------------------------------+ | | | | 1338 | | | | | | 1339 | +------------------+ElementSchedSvc | | | | | 1340 | |PriorityScheduling+--------+ | | | | | 1341 | |Element | | | | | | | 1342 | | Name=PriBE | | v v | | | 1343 | +------+ Priority=2 | +---+--------+-+-+-+Next| | 1344 | | +------------------+ |SchedulingService +----+ | 1345 | | | Name=PriSched |Sched | 1346 | | +------------------+ | 1347 | |QueueTo | 1348 | |Schedule +----------------+ | 1349 | | |AllocationSched |ElementSchedSvc | 1350 +----+---------+ |Element +-----------------+ 1351 |QueuingService|QueueTo | Name=BandBE | 1352 | Name=BE +------------+ Units=Bytes | 1353 | |Schedule | Bandwidth=50 | 1354 | | +----------------+ 1355 +--------------+ 1357 Figure 6. Example 2: Complex Hierarchical Scheduler 1359 3.11.3. Excess Capacity Scheduler 1361 An excess capacity scheduler offers a similar requirement to 1362 support two scheduling parameter sets per queue. However, in 1363 this scenario the reasons are a little different. Suppose a set 1364 of queues have each been assigned bandwidth limits to ensure that 1365 no traffic class starves out another traffic class. The result 1366 may be that one or more queues have exceeded their allocation 1367 while the queues that deserve scheduling opportunities are empty. 1369 The question then is how is the excess (idle) bandwidth 1370 allocated. Conceivably, the scheduling criteria for excess 1371 capacity are completely different from the criteria that 1372 determine allocations under uniform load. This could be 1373 supported with a scheduling hierarchy. However, the problem is 1374 that the criteria for using the subsequent scheduler are 1375 different from those in the last two cases. Specifically, the 1376 next scheduler should only be used if a scheduling opportunity 1377 exists that was passed over by the prior scheduler. 1379 When a scheduler chooses to forgo a scheduling decision, it is 1380 behaving as a non-work conserving scheduler. Work conserving 1381 schedulers by definition will always take advantage of a 1382 scheduling opportunity, irrespective of which queue is being 1383 serviced and how much bandwidth it has consumed in the past. 1384 This point leads to an interesting insight. The semantics of a 1385 non-work conserving scheduler are equivalent to those of a meter, 1386 in that if a packet is in profile it is given the scheduling 1387 opportunity, and if it is out of profile it does not get a 1388 scheduling opportunity. However, with meters there are semantics 1389 that determine the next action behavior when the packet is in 1390 profile and when the packet is out of profile. Similarly, with 1391 the non-work conserving scheduler, there needs to be a means for 1392 determining the next scheduler when a scheduler chooses not to 1393 utilize a scheduling opportunity. 1395 Figure 7 illustrates this last scenario. It appears very similar 1396 to Figure 6, except that the binding between the allocation 1397 scheduler and the WRR scheduler is using a FailNextScheduler 1398 association. This association is explicitly indicating the fact 1399 that the only time the WRR scheduler would be used is when there 1400 are non-empty queues that the allocation scheduler rejected for 1401 scheduling consideration. Note that Figure 7 is incomplete, in 1402 that typically there would be several more queues that are bound 1403 to an allocation scheduler and a WRR scheduler. 1405 +------------+ 1406 |QueuingSvc | 1407 | Name=EF | 1408 | | 1409 | | 1410 ++-+---------+ 1411 | | 1412 | |QueueTo 1413 | |Schedule +--------------+ 1414 | | |SchedulingSvc | 1415 | | +------------------+ | Name=WRRSched| 1416 | +------+AllocationSched | +----------+-+-+ 1417 | |Element | ^ | 1418 | | Name=BandEF |ElementSchedSvc | | 1419 | | Units=Bytes +--------------------+ | | 1420 | | Bandwidth=100 | | | | 1421 | +------------------+ | | | 1422 |NextService | | | 1423 +----------------------------------------------+ | | | 1424 | | | | 1425 NextService | | | | 1426 +--------------------------------------------+ | | | | 1427 | | | | | | 1428 | +------------------+ElementSchedSvc | | | | | 1429 | |AllocationSched +--------+ | | | | | 1430 | |Element | | | | | | | 1431 | | Name=BandwidthAF1| | | | | | | 1432 | | Units=Bytes | | v v | | | 1433 | +------+ Bandwidth=50 | +--+----------+-+-++FailNext| | 1434 | | +------------------+ |SchedulingService +--------+ | 1435 | |QueueTo | Name=BandSched |Scheduler | 1436 | |Schedule +------------------+ | 1437 | | | 1438 | | +---------------------+ | 1439 ++-+-----------+ | WRRSchedulingElement| | 1440 |QueuingService|QueueTo | Name=WRRBE +------------+ 1441 | Name=BE +-----------+ Weight=30 |ElementSchedSvc 1442 +--------------+Schedule +---------------------+ 1444 Figure 7. Example 3: Excess Capacity Scheduler 1446 3.11.4. Hierarchical CBQ Scheduler 1448 A hierarchical class-based queuing (CBQ) scheduler is the fourth 1449 scenario to be considered. In hierarchical CBQ, each queue is 1450 allocated a specific bandwidth allocation. Queues are grouped 1451 together into a logical scheduler. This logical scheduler in 1452 turn has an aggregate bandwidth allocation that equals the sum of 1453 the queues it is scheduling. In turn, logical schedulers can be 1454 aggregated into higher-level logical schedulers. Changing 1455 perspectives and looking top down, the top-most logical scheduler 1456 has 100% of the link capacity. This allocation is parceled out 1457 to logical schedulers below it such that the sum of the 1458 allocations is equal to 100%. These second tier schedulers may 1459 in turn parcel out their allocation across a third tier of 1460 schedulers and so forth until the lowest tier that parcels out 1461 their allocations to specific queues representing relatively 1462 fine-grained classes of traffic. The unique aspect of 1463 hierarchical CBQ is that when there is insufficient bandwidth for 1464 a specific allocation, schedulers higher in the tree are tested 1465 to see if another portion of the tree has capacity to spare. 1467 Figure 8 demonstrates this example with two tiers. The example 1468 is split in half because of space constraints, resulting in the 1469 CBQTier1 scheduling service instance being represented twice. 1470 Note that the total allocation at the top tier is 50 Mb. The 1471 voice allocation is 22 Mb. The remaining 23 Mb is split between 1472 FTP and Web. Hence, if Web traffic is actually consuming 20 Mb 1473 (5 Mb in excess of the allocation). If FTP is consuming 5 Mb, 1474 then it is possible for the CBQTier1 scheduler to offer 3Mb of 1475 its allocation to Web traffic. However, this is not enough, so 1476 the FailNextScheduler association needs to be traversed to 1477 determine if there is any excess capacity available from the 1478 voice class. If the voice class is only consuming 15 Mb of its 1479 22 Mb allocation, there are sufficient resources to allow the web 1480 traffic through. Note that FailNextScheduler is used as the 1481 association. The reason is because the CBQTier1 scheduler in 1482 fact failed to schedule a packet because of insufficient 1483 resources. It is conceivable that a variant of hierarchical CBQ 1484 allows a hierarchy for successful scheduling as well. Hence, 1485 both associations are necessary. 1487 Note that due to space constraints of the document, the 1488 SchedulingService CBQTier1 is represented twice, to show how it 1489 is connected to all the other objects. 1491 +-----------+ NextService 1492 |QueuingSvc +-------------------------------------------+ 1493 | Name=Web | | 1494 | |QueueTo+----------------+ ElementSchedSvc | 1495 | +-------+AllocationSched +----------------+ | 1496 +-----------+Sched |Element | | | 1497 | Name=Web-Alloc | | v 1498 | Bandwidth=15 | +-----------+-+-+ 1499 +----------------+ |SchedulingSvc + 1500 | Name=CBQTier1 + 1501 +----------------+ +-----------+-+-+ 1502 |AllocationSched | ElementSchedSvc| ^ 1503 +-----------+ |Element +----------------+ | 1504 |QueuingSvc |QueueTo| Name=FTP-Alloc | | 1505 | Name=FTP +-------+ Bandwidth=8 | | 1506 | |Sched +----------------+ | 1507 | | NextService | 1508 | +-------------------------------------------+ 1509 +-----------+ 1510 . 1511 : 1513 +---------------+ FailNextScheduler 1514 |SchedulingSvc +---------------------------------------------+ 1515 | Name=CBQTier1 | | 1516 +-------+-------+ +---------------------+ElementSchedSvc| 1517 | SchedToSched |AllocationScheduling +--------+ | 1518 +---------------+Element | | | 1519 | Name=LowPri-Alloc | | | 1520 | Bandwidth=23 | | v 1521 +---------------------+ +-----+------+-+ 1522 |SchedulingSvc | 1523 | Name=CBQTop | 1524 +---------------------+ +----------+-+-+ 1525 |AllocationScheduling |ElementSchedSvc | ^ 1526 +------------+ |Element +----------------+ | 1527 |QueuingSvc |QueueTo| Name=BE-Band | | 1528 | Name=Voice +-------+ Bandwidth=22 | | 1529 | |Sched +---------------------+ | 1530 | | NextService | 1531 | +------------------------------------------------+ 1532 +------------+ 1534 Figure 8. Example 4: Hierarchical CBQ Scheduler 1536 4. The Class Hierarchy 1538 The following sections present the class and association 1539 hierarchies that together comprise the information model for 1540 modeling QoS capabilities at the device level. 1542 4.1. Associations and Aggregations 1544 Associations and aggregations are a means of representing 1545 relationships between two (or theoretically more) objects. 1546 Dependency, aggregation, and other relationships are modeled as 1547 classes containing two (or more) object references. It should be 1548 noted that aggregations represent either "whole-part" or 1549 "collection" relationships. For example, aggregation can be used 1550 to represent the containment relationship between a system and 1551 the components that constitute the system. 1553 Since associations and aggregations are classes, they can benefit 1554 from all of the object-oriented features that other non- 1555 relationship classes have. For example, they can contain 1556 properties and methods, and inheritance can be used to refine 1557 their semantics such that they represent more specialized types 1558 of their superclasses. 1560 Note that an association (or an aggregation) object is treated as 1561 an atomic unit (individual instance), even though it 1562 relates/collects/is comprised of multiple objects. This is a 1563 defining feature of an association (or an aggregation) - although 1564 the individual elements that are related to other objects have 1565 their own identities, the association (or aggregation) object 1566 that is constructed using these objects has its own identity and 1567 name as well. 1569 It is important to note that associations and aggregations form 1570 an inheritance hierarchy that is separate from the class 1571 inheritance hierarchy. Although associations and aggregations 1572 are typically bi-directional, there is nothing that prevents 1573 higher order associations or aggregations from being defined. 1574 However, such associations and aggregations are inherently more 1575 complex to define, understand, and use. In practice, 1576 associations and aggregations of orders higher than binary are 1577 rarely used, because of their greatly increased complexity and 1578 lack of generality. All of the associations and aggregations 1579 defined in this model are binary. 1581 Note also that by definition, associations and aggregations 1582 cannot be unary. 1584 Finally, note that associations and aggregations that are defined 1585 between two classes do not affect the classes themselves. That 1586 is, the addition or deletion of an association or an aggregation 1587 does not affect the interfaces of the classes that it is 1588 connecting. 1590 4.2. The Structure of the Class Hierarchies 1592 The structure of the class, association, and aggregation class 1593 inheritance hierarchies for managing the datapaths of QoS devices 1594 is shown, respectively, in Figure 9, Figure 10, and Figure 11. 1595 The notation (CIMCORE) identifies a class defined in the CIM Core 1596 model. Please refer to [CIM] for the definitions of these 1597 classes. Similarly, the notation [PCIME] identifies a class 1598 defined in the Policy Core Information Model Extensions draft. 1599 This model has been influenced by [CIM], and is compatible with 1600 the Directory Enabled Networks (DEN) effort. 1602 +--ManagedElement (CIMCORE) 1603 | 1604 +--ManagedSystemElement (CIMCORE) 1605 | | 1606 | +--LogicalElement (CIMCORE) 1607 | | 1608 | +--Service (CIMCORE) 1609 | | | 1610 | | +--ConditioningService 1611 | | | | 1612 | | | +--ClassifierService 1613 | | | | | 1614 | | | | +--ClassifierElement 1615 | | | | 1616 | | | +--MeterService 1617 | | | | | 1618 | | | | +--AverageRateMeterService 1619 | | | | | 1620 | | | | +--EWMAMeterService 1621 | | | | | 1622 | | | | +--TokenBucketMeterService 1623 | | | | 1624 | | | +--MarkerService 1625 | | | | | 1626 | | | | +--PreambleMarkerService 1627 | | | | | 1628 | | | | +--TOSMarkerService 1629 | | | | | 1630 | | | | +--DSCPMarkerService 1631 | | | | | 1632 | | | | +--8021QMarkerService 1633 | | | | 1634 | | | +--DropperService 1635 | | | | | 1636 | | | | +--HeadTailDropperService 1637 | | | | | 1638 | | | | +--RedDropperService 1639 | | | | 1640 | | | +--QueuingService 1641 | | | | 1642 | | | +--PacketSchedulingService 1643 | | | | 1644 | | | +--NonWorkConservingSchedulingService 1645 | | | 1646 | | +--QoSService 1647 | | | | 1648 | | | +--DiffServService 1649 | | | | | 1650 | | | | +--AFService 1651 | | | | 1652 | | | +--FlowService 1653 (continued on following page) 1654 (continued from previous page; 1655 the first four elements are repeated for convenience) 1657 +--ManagedElement (CIMCORE) 1658 | 1659 +--ManagedSystemElement (CIMCORE) 1660 | | 1661 | +--LogicalElement (CIMCORE) 1662 | | 1663 | +--Service (CIMCORE) 1664 | | | 1665 | | +--DropThresholdCalculationService 1666 | | 1667 | +--FilterEntryBase [PCIME] 1668 | | | 1669 | | +--IPHeaderFilter [PCIME] 1670 | | | 1671 | | +--8021Filter [PCIME] 1672 | | | 1673 | | +--PreambleFilter 1674 | | 1675 | +--FilterList [PCIME] 1676 | | 1677 | +--ServiceAccessPoint (CIMCORE) 1678 | | 1679 | +--ProtocolEndpoint 1680 | 1681 +--Collection (CIMCORE) 1682 | | 1683 | +--CollectionOfMSEs (CIMCORE) 1684 | | 1685 | +--BufferPool 1686 | 1687 +--SchedulingElement 1688 | 1689 +--AllocationSchedulingElement 1690 | 1691 +--WRRSchedulingElement 1692 | 1693 +--PrioritySchedulingElement 1694 | 1695 +--BoundedPrioritySchedulingElement 1697 Figure 9. Class Inheritance Hierarchy 1698 The inheritance hierarchy for the associations defined in this 1699 document is shown in Figure 10. 1701 +--Dependency (CIMCORE) 1702 | | 1703 | +--ServiceSAPDependency (CIMCORE) 1704 | | | 1705 | | +--IngressConditioningServiceOnEndpoint 1706 | | | 1707 | | +--EgressConditioningServiceOnEndpoint 1708 | | 1709 | +--HeadTailDropQueueBinding 1710 | | 1711 | +--CalculationBasedOnQueue 1712 | | 1713 | +--ProvidesServiceToElement (CIMCORE) 1714 | | | 1715 | | +--ServiceServiceDependency (CIMCORE) 1716 | | | 1717 | | +--CalculationServiceForDropper 1718 | | 1719 | +--QueueAllocation 1720 | | 1721 | +--ClassifierElementUsesFilterList 1722 | 1723 +--AFRelatedServices 1724 | 1725 +--NextService 1726 | | 1727 | +--NextServiceAfterClassifierElement 1728 | | 1729 | +--NextScheduler 1730 | | 1731 | +--FailNextScheduler 1732 | 1733 +--NextServiceAfterMeter 1734 | 1735 +--QueueToSchedule 1736 | 1737 +--SchedulingServiceToSchedule 1739 Figure 10. Association Class Inheritance Hierarchy 1740 The inheritance hierarchy for the aggregations defined in this 1741 document is shown in Figure 11. 1743 +--MemberOfCollection (CIMCORE) 1744 | | 1745 | +--CollectedBufferPool 1746 | 1747 +--Component (CIMCORE) 1748 | | 1749 | +--ServiceComponent (CIMCORE) 1750 | | | 1751 | | +--QoSSubService 1752 | | | 1753 | | +--QoSConditioningSubService 1754 | | | 1755 | | +--ClassifierElementInClassifierService 1756 | | 1757 | +--EntriesInFilterList [PCIME] 1758 | 1759 +--ElementInSchedulingService 1761 Figure 11. Aggregation Class Inheritance Hierarchy 1763 4.3. Class Definitions 1765 This section presents the classes and properties that make up the 1766 Information Model for describing QoS-related functionality in 1767 network devices, including hosts. These definitions are derived 1768 from definitions in the CIM Core model [CIM]. Only the QoS- 1769 related classes are defined in this document. However, other 1770 classes drawn from the CIM Core model, as well as from [PCIME], 1771 are described briefly. The reader is encouraged to look at [CIM] 1772 and at [PCIME] for further information. Associations and 1773 aggregations are defined in Section 4.4. 1775 4.3.1. The Abstract Class ManagedElement 1777 This is an abstract class defined in the Core Model of CIM. It 1778 is the root of the entire class inheritance hierarchy in CIM. 1779 Among the associations that refer to it are two that are 1780 subclassed in this document: Dependency and MemberOfCollection, 1781 which is an aggregation. ManagedElement's properties are Caption 1782 and Description. Both are free-form strings to describe an 1783 instantiated object. Please refer to [CIM] for the full 1784 definition of this class. 1786 4.3.2. The Abstract Class ManagedSystemElement 1788 This is an abstract class defined in the Core Model of CIM; it is 1789 a subclass of ManagedElement. ManagedSystemElement serves as the 1790 base class for the PhysicalElement and LogicalElement class 1791 hierarchies. LogicalElement, in turn, is the base class for a 1792 number of important CIM hierarchies, including System. Any 1793 distinguishable component of a System is a candidate for 1794 inclusion in this class hierarchy, including physical components 1795 (e.g., chips and cards) and logical components (e.g., software 1796 components, services, and other objects). 1798 None of the associations in which this class participates is used 1799 directly in the QoS device state model. However, the aggregation 1800 Component, which relates one ManagedSystemElement to another, is 1801 the base class for the two aggregations that form the core of the 1802 QoS device state model: QoSSubService and 1803 QoSConditioningSubService. Similarly, the association 1804 ProvidesServiceToElement, which relates a ManagedSystemElement to 1805 a Service, is the base class for the model's 1806 CalculationServiceForDropper association. 1808 Please refer to [CIM] for the full definition of this class. 1810 4.3.3. The Abstract Class LogicalElement 1812 This is an abstract class defined in the Core Model of CIM. It 1813 is a subclass of the ManagedSystemElement class, and is the base 1814 class for all logical components of a managed System, such as 1815 Files, Processes, or system capabilities in the form of Logical 1816 Devices and Services. None of the associations in which this 1817 class participates is relevant to the QoS device state model. 1818 Please refer to [CIM] for the full definition of this class. 1820 4.3.4. The Abstract Class Service 1822 This is an abstract class defined in the Core Model of CIM. It 1823 is a subclass of the LogicalElement class, and is the base class 1824 for all objects that represent a "service" or functionality in a 1825 System. A Service is a general-purpose object that is used to 1826 configure and manage the implementation of functionality. As 1827 noted above in section 4.3.2, this class participates in the 1828 ProvidesServiceToElement association. Please refer to [CIM] for 1829 the full definition of this class. 1831 4.3.5. The Class ConditioningService 1833 This is a concrete subclass of the CIM Core class Service; it 1834 represents the ability to define how traffic is conditioned in 1835 the data-forwarding path of a device. The subclasses of 1836 ConditioningService define the particular types of conditioning 1837 that are done. Six fundamental types of conditioning are defined 1838 in this document. These are the services performed by a 1839 classifier, a meter, a marker, a dropper, a queue, and a 1840 scheduler. Other, more sophisticated types of conditioning may 1841 be defined in future documents. 1843 ConditioningService is a concrete class because at the time it 1844 was defined in CIM, its superclass was concrete. While this 1845 class can be instantiated, an instance of it would not accomplish 1846 anything, because the nature of the conditioning, and the 1847 parameters that control it, are specified only in the subclasses 1848 of ConditioningService. 1850 Two associations in which ConditioningService participates are 1851 critical to its usage in QoS - QoSConditioningSubService and 1852 NextService. QoSConditioningSubService aggregates 1853 ConditioningServices into a particular QoS service (such as AF), 1854 to describe the specific conditioning functionality that 1855 underlies that QoS service in a particular device. NextService 1856 indicates the subsequent conditioning service(s) for different 1857 traffic streams. 1859 The class definition is as follows: 1861 NAME ConditioningService 1862 DESCRIPTION A concrete class to define how traffic 1863 is conditioned in the data forwarding 1864 path of a host or network device. 1865 DERIVED FROM Service 1866 TYPE Concrete 1867 PROPERTIES (none) 1869 4.3.6. The Class ClassifierService 1871 The concept of a Classifier comes from [DSMODEL]. 1872 ClassifierService is a concrete class that represents a logical 1873 entity in an ingress or egress interface of a device, that takes 1874 a single input stream, and sorts it into one or more output 1875 streams. The sorting is done by a set of filters that select 1876 packets based on the packet contents, or possibly based on other 1877 attributes associated with the packet. Each output stream is the 1878 result of matching a particular filter. 1880 The representation of classifiers in QDDIM is closely related to 1881 that presented in [DSMIB] and [DSMODEL]. Rather than being 1882 linked directly to its FilterLists, a classifier is modeled here 1883 as an aggregation of ClassifierElements. Each of these 1884 ClassifierElements is then linked to a single FilterList, by the 1885 association ClassifierElementUsesFilterList. 1887 A Classifier is modeled as a subclass of ConditioningService so 1888 that it can be aggregated into a QoSService (using the 1889 QoSConditioningSubService aggregation), and can use the 1890 NextService association to identify the subsequent 1891 ConditioningService objects for the different traffic streams. 1893 ClassifierService is designed to allow hierarchical 1894 classification. When hierarchical classification is used, a 1895 ClassifierElement may point to another ClassifierService. When 1896 used for this purpose, the ClassifierElement must not use the 1897 ClassifierElementUsesFilterList association. 1899 The class definition is as follows: 1901 NAME ClassifierService 1902 DESCRIPTION A concrete class describing how an input 1903 traffic stream is sorted into multiple 1904 output streams using one or more 1905 filters. 1906 DERIVED FROM ConditioningService 1907 TYPE Concrete 1908 PROPERTIES (none) 1910 4.3.7. The Class ClassifierElement 1912 The concept of a ClassifierElement comes from [DSMIB]. This 1913 concrete class represents the linkage, within a single 1914 ClassifierService, between a FilterList that specifies a set of 1915 criteria for selecting packets from the stream of packets coming 1916 into the ClassifierService, and the next ConditioningService to 1917 which the selected packets go after they leave the 1918 ClassifierService. ClassifierElement has no properties of its 1919 own. It is present to serve as the anchor for an aggregation 1920 with its classifier, and for associations with its FilterList and 1921 its next ConditioningService. 1923 When a ClassifierElement is associated with a ClassifierService 1924 through the NextServiceAfterClassifierElement association, the 1925 ClassifierElement may not use the ClassifierElementUsesFilterList 1926 association. Further, when a ClassifierElement is associated with 1927 a ClassifierService as described above, the order of processing 1928 of the associated ClassifierService is a function of the 1929 ClassifierOrder property of the 1930 ClassifierElementInClassifierService aggregation. For example, 1931 lets assume the following: 1933 1. ClassifierService (C1) aggregates ClassifierElements (E1), 1934 (E2) and (E3), with relative ClassifierOrder values of 1, 2, 1935 and 3. 1937 2. ClassifierElements (E1) and (E3) associations to FilterLists 1938 (F1) and (F3) respectively using the 1939 ClassifierElementUsesFilterList association. 1941 3. (E1) & (E3) are associated with Meters (M1) and (M3) through 1942 their respective NextServiceAfterClassifierElement 1943 associations. 1945 4. (E2) is associated with ClassifierService (C2) through its 1946 NextServiceAfterClassifierElement association. 1948 5. ClassifierService (C2) aggregates ClassifierElements (E4) and 1949 (E5) with relative ClassifierOrder values of 1 and 2. 1951 6. ClassifierElements (E4) and (E5) have associations to 1952 FilterLists (F4) and (F5) respectively using the 1953 ClassifierElementUsesFilterList association. 1955 In this example, packet processing would match FilterLists in the 1956 order of (F1), (F4), (F5), and (F3). 1958 The class definition is as follows: 1960 NAME ClassifierElement 1961 DESCRIPTION A concrete class representing 1962 the process by which a classifier 1963 uses a filter to select packets 1964 to forward to a specific next 1965 conditioning service. 1966 DERIVED FROM ClassifierService 1967 TYPE Concrete 1968 PROPERTIES (none) 1970 4.3.8. The Class MeterService 1972 This is a concrete class that represents the metering of network 1973 traffic. Metering is the function of monitoring the arrival 1974 times of packets of a traffic stream, and determining the level 1975 of conformance of each packet with respect to a pre-established 1976 traffic profile. A meter has the ability to invoke different 1977 ConditioningServices for conforming and non-conforming traffic. 1978 Traffic leaving a meter may be further conditioned (e.g., dropped 1979 or queued) by routing the packet to another conditioning element. 1980 Please see [DSMODEL] for more information on metering. 1982 This class is the base class for defining different types of 1983 meters. As such, it contains common properties that all meter 1984 subclasses share. It is modeled as a ConditioningService so that 1985 it can be aggregated into a QoSService (using the 1986 QoSConditioningSubService association), to indicate that its 1987 functionality underlies that QoS service. MeterService also 1988 participates in the NextServiceAfterMeter association, to 1989 identify the subsequent ConditioningService objects for 1990 conforming and non-conforming traffic. 1992 The class definition is as follows: 1994 NAME MeterService 1995 DESCRIPTION A concrete class describing the 1996 monitoring of traffic with respect to a 1997 pre-established traffic profile. 1998 DERIVED FROM ConditioningService 1999 TYPE Concrete 2000 PROPERTIES MeterType, OtherMeterType, 2001 ConformanceLevels 2003 Note: The MeterType property and the MeterService subclasses 2004 provide similar information. The MeterType property is defined 2005 for query purposes and for future expansion. It is possible that 2006 not all MeterServices will require a subclass to define them. In 2007 these cases, MeterService will be instantiated directly, and the 2008 MeterType property will provide the only way of identifying the 2009 type of the meter. 2011 4.3.8.1 The Property MeterType 2013 This property is an enumerated 16-bit unsigned integer that is 2014 used to specify the particular type of meter represented by an 2015 instance of MeterService. The following enumeration values are 2016 defined: 2018 1 - Other 2019 2 - Average Rate Meter 2020 3 - Exponentially Weighted Moving Average Meter 2021 4 - Token Bucket Meter 2023 Note: if the value of MeterType is not one of these four values, 2024 it SHOULD be interpreted as if it had the value '1' (Other). 2026 4.3.8.2 The Property OtherMeterType 2028 This is a string property that defines a vendor-specific 2029 description of a type of meter. It is used when the value of the 2030 MeterType property in the instance is equal to 1. 2032 4.3.8.3 The Property ConformanceLevels 2034 This property is a 16-bit unsigned integer. It indicates the 2035 number of conformance levels supported by the meter. For 2036 example, when only "in profile" versus "out of profile" metering 2037 is supported, ConformanceLevels is equal to 2. 2039 4.3.9. The Class AverageRateMeterService 2041 This is a concrete subclass of MeterService that represents a 2042 simple meter, called an Average Rate Meter. This type of meter 2043 measures the average rate at which packets are submitted to it 2044 over a specified time. Packets are defined as conformant if 2045 their average arrival rate does not exceed the specified 2046 measuring rate of the meter. Any packet that causes the 2047 specified measuring rate to be exceeded is defined to be non- 2048 conforming. For more information, please see [DSMODEL]. 2050 The class definition is as follows: 2052 NAME AverageRateMeterService 2053 DESCRIPTION A concrete class classifying traffic as 2054 either conforming or non-conforming, 2055 depending on whether the arrival of a 2056 packet causes the average arrival rate 2057 to exceed a pre-determined value. 2058 DERIVED FROM MeterService 2059 TYPE Concrete 2060 PROPERTIES AverageRate, DeltaInterval 2062 4.3.9.1 The Property AverageRate 2064 This is an unsigned 32-bit integer that defines the rate used to 2065 determine whether admitted packets are in conformance or not. 2066 The value is specified in kilobits per second. 2068 4.3.9.2 The Property DeltaInterval 2070 This is an unsigned 64-bit integer that defines the time period 2071 over which the average measurement should be taken. The value is 2072 specified in microseconds. 2074 4.3.10. The Class EWMAMeterService 2076 This is a concrete subclass of the MeterService class that 2077 represents an exponentially weighted moving average meter. This 2078 meter is a simple low-pass filter that measures the rate of 2079 incoming packets over a small, fixed sampling interval. Any 2080 admitted packet that pushes the average rate over a pre-defined 2081 limit is defined to be non-conforming. Please see [DSMODEL] for 2082 more information. 2084 The class definition is as follows: 2086 NAME EWMAMeterService 2087 DESCRIPTION A concrete class classifying admitted 2088 traffic as either conforming or non- 2089 conforming, depending on whether the 2090 arrival of a packet causes the average 2091 arrival rate in a small fixed 2092 sampling interval to exceed a 2093 pre-determined value or not. 2094 DERIVED FROM MeterService 2095 TYPE Concrete 2096 PROPERTIES AverageRate, DeltaInterval, Gain 2098 4.3.10.1 The Property AverageRate 2100 This property is an unsigned 32-bit integer that defines the 2101 average rate against which the sampled arrival rate of packets 2102 should be measured. Any packet that causes the sampled rate to 2103 exceed this rate is deemed non-conforming. The value is 2104 specified in kilobits per second. 2106 4.3.10.2 The Property DeltaInterval 2108 This property is an unsigned 64-bit integer that defines the 2109 sampling interval used to measure the arrival rate. The 2110 calculated rate is averaged over this interval and checked 2111 against the AverageRate property. All packets whose computed 2112 average arrival rate is less than the AverageRate are deemed 2113 conforming. 2115 The value is specified in microseconds. 2117 4.3.10.3 The Property Gain 2119 This property is an unsigned 32-bit integer representing the 2120 reciprocal of the time constant (e.g., frequency response) of 2121 what is essentially a simple low-pass filter. For example, the 2122 value 64 for this property represents a time constant value of 2123 1/64. 2125 4.3.11. The Class TokenBucketMeterService 2127 This is a concrete subclass of the MeterService class that 2128 represents the metering of network traffic using a token bucket 2129 meter. Two types of token bucket meters are defined using this 2130 class - a simple, two-parameter bucket meter, and a multi-stage 2131 meter. 2133 A simple token bucket usually has two parameters, an average 2134 token rate and a burst size, and has two conformance levels: 2135 "conforming" and "non-conforming". This class also defines an 2136 excess burst size, which enables the meter to have three 2137 conformance levels ("conforming", "partially conforming", and 2138 "non-conforming"). In this case, packets that exceed the excess 2139 burst size are deemed non-conforming, while packets that exceed 2140 the smaller burst size but are less than the excess burst size 2141 are deemed partially conforming. Operation of these meters is 2142 described in [DSMODEL]. 2144 The class definition is as follows: 2146 NAME TokenBucketMeterService 2147 DESCRIPTION A concrete class classifying admitted 2148 traffic with respect to a token bucket. 2149 Either two or three levels of 2150 conformance can be defined. 2151 DERIVED FROM MeterService 2152 TYPE Concrete 2153 PROPERTIES AverageRate, PeakRate, 2154 BurstSize, ExcessBurstSize 2155 4.3.11.1 The Property AverageRate 2157 This property is an unsigned 32-bit integer that specifies the 2158 committed rate of the meter. The value is expressed in kilobits 2159 per second. 2161 4.3.11.2 The Property PeakRate 2163 This property is an unsigned 32-bit integer that specifies the 2164 peak rate of the meter. The value is expressed in kilobits per 2165 second. 2167 4.3.11.3 The Property BurstSize 2169 This property is an unsigned 32-bit integer that specifies the 2170 maximum number of tokens available for the committed rate 2171 (specified by the AverageRate property). The value is expressed 2172 in kilobytes. 2174 4.3.11.4 The Property ExcessBurstSize 2176 This property is am unsigned 32-bit integer that specifies the 2177 maximum number of tokens available for the peak rate (specified 2178 by the PeakRate property). The value is expressed in kilobytes. 2180 4.3.12. The Class MarkerService 2182 This is a concrete class that represents the general process of 2183 marking some field in a network packet with some value. 2184 Subclasses of MarkerService identify particular fields to be 2185 marked, and introduce properties to represent the values to be 2186 used in marking these fields. Markers are usually invoked as a 2187 result of a preceding classifier match. Operation of markers of 2188 various types is described in [DSMODEL]. 2190 MarkerService is a concrete class because at the time it was 2191 defined in CIM, its superclass was concrete. While this class 2192 can be instantiated, an instance of it would not accomplish 2193 anything, because both the field to be marked and the value to be 2194 used to mark it are specified only in subclasses of 2195 MarkerService. 2197 MarkerService is modeled as a ConditioningService so that it can 2198 be aggregated into a QoSService (using the 2199 QoSConditioningSubService association) to indicate that its 2200 functionality underlies that QoS service. It participates in the 2201 NextService association to identify the subsequent 2202 ConditioningService object that acts on traffic after it has been 2203 marked by the marker. 2205 The class definition is as follows: 2207 NAME MarkerService 2208 DESCRIPTION A concrete class representing the 2209 general process of marking a selected 2210 field in a packet with a specified 2211 value. Packets are marked in order 2212 to control the conditioning that 2213 they will subsequently receive. 2214 DERIVED FROM ConditioningService 2215 TYPE Concrete 2216 PROPERTIES (none) 2218 4.3.13. The Class PreambleMarkerService 2220 This is a concrete class that models the storing of traffic- 2221 conditioning results in a packet preamble. See Section 3.8.3 for 2222 a discussion of how, and why, QDDIM models the capability to 2223 store these results in a packet preamble. An instance of 2224 PreambleMarkerService appends to a packet preamble a two-part 2225 string of the form ",". Section 3.8.3 provides a 2226 list of the strings defined by QDDIM. Implementations may 2227 support other 's in addition to these. 2229 The class definition is as follows: 2231 NAME PreambleMarkerService 2232 DESCRIPTION A concrete class representing the saving 2233 of traffic-conditioning results in a 2234 packet preamble. 2235 DERIVED FROM MarkerService 2236 TYPE Concrete 2237 PROPERTIES FilterItemList[ ] 2239 4.3.13.1 The Multi-valued Property FilterItemList 2241 This property is an ordered list of strings, where each string has 2242 the format ",". See Section 3.8.3 for a list of 2243 's defined in QDDIM, and the nature of the associated 2244 for each of these types. 2246 4.3.14. The Class ToSMarkerService 2248 This is a concrete class that represents the marking of the ToS 2249 field in the IPv4 packet header [R791]. Following common 2250 practice, the value to be written into the field is represented 2251 as an unsigned 8-bit integer. 2253 The class definition is as follows: 2255 NAME ToSMarkerService 2256 DESCRIPTION A concrete class representing the 2257 process of marking the type of service 2258 (ToS) field in the IPv4 packet header 2259 with a specified value. Packets are 2260 marked in order to control the 2261 conditioning that they will subsequently 2262 receive. 2263 DERIVED FROM MarkerService 2264 TYPE Concrete 2265 PROPERTIES ToSValue 2267 4.3.14.1 The Property ToSValue 2269 This property is an unsigned 8-bit integer, representing a value 2270 to be used for marking the type of service (ToS) field in the 2271 IPv4 packet header. The ToS field is defined to be a complete 2272 octet, so the range for this property is 0..255. Some 2273 implementations, however, require that the lowest-order bit in 2274 the ToS field always be '0'. Such an implementation is 2275 consequently unable to support an odd TosValue. 2277 4.3.15. The Class DSCPMarkerService 2279 This is a concrete class that represents the marking of the 2280 differentiated services codepoint (DSCP) within the DS field in 2281 the IPv4 and IPv6 packet headers, as defined in [R2474]. 2282 Following common practice, the value to be written into the field 2283 is represented as an unsigned 8-bit integer. 2285 The class definition is as follows: 2287 NAME DSCPMarkerService 2288 DESCRIPTION A concrete class representing the 2289 process of marking the DSCP field 2290 in a packet with a specified 2291 value. Packets are marked in order 2292 to control the conditioning that 2293 they will subsequently receive. 2294 DERIVED FROM MarkerService 2295 TYPE Concrete 2296 PROPERTIES DSCPValue 2298 4.3.15.1 The Property DSCPValue 2300 This property is an unsigned 8-bit integer, representing a value 2301 to be used for marking the DSCP within the DS field in an IPv4 or 2302 IPv6 packet header. Since the DSCP consists of 6 bits, the 2303 values for this property are limited to the range 0..63. When 2304 the DSCP is marked, the remaining two bit in the DS field are 2305 left unchanged. 2307 4.3.16. The Class 8021QMarkerService 2309 This is a concrete class that represents the marking of the user 2310 priority field defined in the IEEE 802.1Q specification 2311 [IEEE802Q]. Following common practice, the value to be written 2312 into the field is represented as an unsigned 8-bit integer. 2314 The class definition is as follows: 2316 NAME 8021QMarkerService 2317 DESCRIPTION A concrete class representing the 2318 process of marking the Priority 2319 field in an 802.1Q-compliant frame 2320 with a specified value. Frames are 2321 marked in order to control the 2322 conditioning that they will 2323 subsequently receive. 2324 DERIVED FROM MarkerService 2325 TYPE Concrete 2326 PROPERTIES PriorityValue 2328 4.3.16.1 The Property PriorityValue 2330 This property is an unsigned 8-bit integer, representing a value 2331 to be used for marking the Priority field in the 802.1Q header. 2332 Since the Priority field consists of 3 bits, the values for this 2333 property are limited to the range 0..7. When the Priority field 2334 is marked, the remaining bits in its octet are left unchanged. 2336 4.3.17. The Class DropperService 2338 This is a concrete class that represents the ability to 2339 selectively drop network traffic, or to invoke another 2340 ConditioningService for further processing of traffic that is not 2341 dropped. This is the base class for different types of droppers. 2342 Droppers are distinguished by the algorithm that they use to drop 2343 traffic. Please see [DSMODEL] for more information about the 2344 various types of droppers. Note that this class encompasses both 2345 Absolute Droppers and Algorithmic Droppers from [DSMODEL]. 2347 DropperService is modeled as a ConditioningService so that it can 2348 be aggregated into a QoSService (using the 2349 QoSConditioningSubService association) to indicate that its 2350 functionality underlies that QoS service. It participates in the 2351 NextService association to identify the subsequent 2352 ConditioningService object that acts on any remaining traffic 2353 that is not dropped. 2355 NextService has special semantics for droppers, in addition to 2356 the general "what happens next" semantics that apply to all 2357 ConditioningServices. The queue(s) from which a particular 2358 dropper drops packets are identified by following chain(s) of 2359 NextService associations "rightwards" from the dropper until they 2360 reach a queue. 2362 The class definition is as follows: 2364 NAME DropperService 2365 DESCRIPTION A concrete base class describing the 2366 common characteristics of droppers. 2367 DERIVED FROM ConditioningService 2368 TYPE Concrete 2369 PROPERTIES DropperType, OtherDropperType, DropFrom 2371 Note: The DropperType property and the DropperService subclasses 2372 provide similar information. The DropperType property is defined 2373 for query purposes, as well as for those cases where a subclass 2374 of DropperService is not needed to model a particular type of 2375 dropper. For example, the Absolute Dropper defined in [DSMODEL] 2376 is modeled as an instance of the DropperService class with its 2377 DropperType set to '4' ("Absolute Dropper"). 2379 4.3.17.1 The Property DropperType 2381 This is an enumerated 16-bit unsigned integer that defines the 2382 type of dropper. Values include: 2384 1 - Other 2385 2 - Random 2386 3 - HeadTail 2387 4 - Absolute Dropper 2389 Note: if the value of DropperType is not one of these four 2390 values, it SHOULD be interpreted as if it had the value '1' 2391 (Other). 2393 4.3.17.2 The Property OtherDropperType 2395 This string property is used in conjunction with the DropperType 2396 property. When the value of DropperType is '1' (i.e., Other), 2397 then the name of the type of dropper appears in this property. 2399 4.3.17.3 The Property DropFrom 2401 This is an unsigned 16-bit integer enumeration that indicates the 2402 point in the associated queue from which packets should be 2403 dropped. Defined enumeration values are 2405 o unknown(0) 2406 o head(1) 2407 o tail(2) 2408 Note: if the value of DropFrom is '0' (unknown), or if it is not 2409 one of the three values listed here, then packets MAY be dropped 2410 from any location in the associated queue. 2412 4.3.18. The Class HeadTailDropperService 2414 This is a concrete class that represents the threshold 2415 information of a head or tail dropper. The inherited property 2416 DropFrom indicates whether a particular instance of this class 2417 represents a head dropper or a tail dropper. 2419 A head dropper always examines the same queue from which it drops 2420 packets, and this queue is always related to the dropper as the 2421 following service in the NextService association. 2423 The class definition is as follows: 2425 NAME HeadTailDropperService 2426 DESCRIPTION A concrete class used to describe 2427 a head or tail dropper. 2428 DERIVED FROM DropperService 2429 TYPE Concrete 2430 PROPERTIES QueueThreshold 2432 4.3.18.1 The Property QueueThreshold 2434 This is an unsigned 32-bit integer that indicates the queue depth 2435 at which traffic will be dropped. For a tail dropper, all newly 2436 arriving traffic is dropped. For a head dropper, packets at the 2437 front of the queue are dropped to make room for new packets, 2438 which are added at the end. The value is expressed in bytes. 2440 4.3.19. The Class REDDropperService 2442 This is a concrete class that represents the ability to drop 2443 network traffic using a Random Early Detection (RED) algorithm. 2444 This algorithm is described in [RED]. The purpose of a RED 2445 algorithm is to avoid congestion (as opposed to managing 2446 congestion). Instead of waiting for the queues to fill up, and 2447 then dropping large numbers of packets, RED works by monitoring 2448 the average queue depth. When the queue depth exceeds a minimum 2449 threshold, packets are randomly discarded. These discards cause 2450 TCP to slow its transmission rate for those connections that 2451 experienced the packet discards. Other TCP connections are not 2452 affected by these discards. Please see [DSMODEL] for more 2453 information about a dropper. 2455 A RED dropper always drops packets from a single queue, which is 2456 related to the dropper as the following service in the 2457 NextService association. The queue(s) examined by the drop 2458 algorithm are found by following the CalculationServiceForDropper 2459 association to find the dropper's 2460 DropThresholdCalculationService, and then following the 2461 CalculationBasedOnQueue association(s) to find the queue(s) being 2462 watched. 2464 The class definition is as follows: 2466 NAME REDDropperService 2467 DESCRIPTION A concrete class used to describe 2468 dropping using the RED algorithm (or 2469 one of its variants). 2470 DERIVED FROM DropperService 2471 TYPE Concrete 2472 PROPERTIES MinQueueThreshold, MaxQueueThreshold, 2473 ThresholdUnits, StartProbability, 2474 StopProbability 2476 NOTE: In [DSMIB], there is a single diffServRandomDropTable, 2477 which represents the general category of random dropping. (RED 2478 is one type of random dropping, but there are also types of 2479 random dropping distinct from RED.) The REDDropperService class 2480 corresponds to the columns in the table that apply to the RED 2481 algorithm in particular. 2483 4.3.19.1 The Property MinQueueThreshold 2485 This is an unsigned 32-bit integer that defines the minimum 2486 average queue depth at which packets are subject to being 2487 dropped. The units are identified by the ThresholdUnits 2488 property. The slope of the drop probability function is 2489 described by the Start/StopProbability properties. 2491 4.3.19.2 The Property MaxQueueThreshold 2493 This is an unsigned 32-bit integer that defines the maximum 2494 average queue length at which packets are subject to always being 2495 dropped, regardless of the dropping algorithm and probabilities 2496 being used. The units are identified by the ThresholdUnits 2497 property. 2499 4.3.19.3 The Property ThresholdUnits 2501 This is an unsigned 16-bit integer enumeration that identifies 2502 the units for the MinQueueThreshold and MaxQueueThreshold 2503 properties. Defined enumeration values are 2505 o bytes(1) 2506 o packets(2) 2508 Note: if the value of ThresholdUnits is not one of these two 2509 values, it SHOULD be interpreted as if it had the value '1' 2510 (bytes). 2512 4.3.19.4 The Property StartProbability 2514 This is an unsigned 32-bit integer; in conjunction with the 2515 StopProbability property, it defines the slope of the drop 2516 probability function. This function governs the rate at which 2517 packets are subject to being dropped, as a function of the queue 2518 length. 2520 This property expresses a drop probability in drops per thousand 2521 packets. For example, the value 100 indicates a drop probability 2522 of 100 per 1000 packets, that is, 10%. Min and max values are 0 2523 to 1000. 2525 4.3.19.5 The Property StopProbability 2527 This is an unsigned 32-bit integer; in conjunction with the 2528 StartProbability property, it defines the slope of the drop 2529 probability function. This function governs the rate at which 2530 packets are subject to being dropped, as a function of the queue 2531 length. 2533 This property expresses a drop probability in drops per thousand 2534 packets. For example, the value 100 indicates a drop probability 2535 of 100 per 1000 packets, that is, 10%. Min and max values are 0 2536 to 1000. 2538 4.3.20. The Class QueuingService 2540 This is a concrete class that represents the ability to queue 2541 network traffic, and to specify the characteristics for 2542 determining long-term congestion. Please see [DSMODEL] for more 2543 information about queuing functionality. 2545 QueuingService is modeled as a ConditioningService so that it can 2546 be aggregated into a QoSService (using the 2547 QoSConditioningSubService association) to indicate that its 2548 functionality underlies that QoS service. 2550 The class definition is as follows: 2552 NAME QueuingService 2553 DESCRIPTION A concrete class describing the ability 2554 to queue network traffic and to specify 2555 the characteristics for determining 2556 long-term congestion. 2557 DERIVED FROM ConditioningService 2558 TYPE Concrete 2559 PROPERTIES CurrentQueueDepth, DepthUnits 2560 4.3.20.1 The Property CurrentQueueDepth 2562 This is an unsigned 32-bit integer, which functions as a (read- 2563 only) gauge representing the current depth of this one queue. 2564 This value may be important in diagnosing unexpected behavior by 2565 a DropThresholdCalculationService. 2567 4.3.20.2 The Property DepthUnits 2569 This is an unsigned 16-bit integer enumeration that identifies 2570 the units for the CurrentQueueDepth property. Defined 2571 enumeration values are 2573 o bytes(1) 2574 o packets(2) 2576 Note: if the value of DepthUnits is not one of these two values, 2577 it SHOULD be interpreted as if it had the value '1' (bytes).The 2578 Class PacketSchedulingService 2580 This is a concrete class that represents a scheduling service, 2581 which is a process that determines when a queued packet should be 2582 removed from a queue and sent to an output interface. Note that 2583 output interfaces can be physical network interfaces or 2584 interfaces to components internal to systems, such as crossbars 2585 or back planes. In either case, if multiple queues are involved, 2586 schedulers are used to provide access to the interface. 2588 Each instance of a PacketSchedulingService describes a scheduler 2589 from the perspective of the queues that it is servicing. Please 2590 see [DSMODEL] for more information about a scheduler. 2592 PacketSchedulingService is modeled as a ConditioningService so 2593 that it can be aggregated into a QoSService (using the 2594 QoSConditioningSubService association) to indicate that its 2595 functionality underlies that QoS service. It participates in the 2596 NextService association to identify the subsequent 2597 ConditioningService object, if any, that acts on traffic after it 2598 has been processed by the scheduler. 2600 The class definition is as follows: 2602 NAME PacketSchedulingService 2603 DESCRIPTION A concrete class used to determine when 2604 a packet should be removed from a 2605 queue and sent to an output interface. 2606 DERIVED FROM ConditioningService 2607 TYPE Concrete 2608 PROPERTIES SchedulerType, OtherSchedulerType 2609 4.3.21.1 The Property SchedulerType 2611 This property is an enumerated 16-bit unsigned integer, and 2612 defines the type of scheduler. Values are: 2614 1 - Other 2615 2 - FIFO 2616 3 - Priority 2617 4 - Allocation 2618 5 - Bounded Priority 2619 6 - Weighted Round Robin Packet 2621 Note: if the value of SchedulerType is not one of these six 2622 values, it SHOULD be interpreted as if it had the value '2' 2623 (FIFO). 2625 4.3.21.2 The Property OtherSchedulerType 2627 This string property is used in conjunction with the 2628 SchedulerType property. When the value of SchedulerType is 1 2629 (i.e., Other), then the type of scheduler is specified in this 2630 property. 2632 4.3.22. The Class NonWorkConservingSchedulingService 2634 This class does not add any properties beyond those it inherits 2635 from its superclass, PacketSchedulingService. It does, however, 2636 participate in one additional association, FailNextScheduler. 2638 The class definition is as follows: 2640 NAME NonWorkConservingSchedulingService 2641 DESCRIPTION A concrete class representing a 2642 scheduler that is capable of operating 2643 in a non-work conserving manner. 2644 DERIVED FROM PacketSchedulingService 2645 TYPE Concrete 2646 PROPERTIES (none) 2648 4.3.23. The Class QoSService 2650 This is a concrete class that represents the ability to 2651 conceptualize a QoS service as a set of coordinated sub-services. 2652 This enables the network administrator to map business rules to 2653 the network, and the network designer to engineer the network 2654 such that it can provide different functions for different 2655 traffic streams. 2657 This class has two main purposes. First, it serves as a common 2658 base class for defining the various sub-services needed to build 2659 higher-level QoS services. Second, it serves as a way to 2660 consolidate the relationships between different types of QoS 2661 services and different types of ConditioningServices. 2663 For example, Gold Service may be defined as a QoSService which 2664 aggregates two QoS services together. Each of these QoS services 2665 could be represented by an instance of the class DiffServService, 2666 one for servicing of very high demand packets (represented by an 2667 instance of DiffServService itself), and one for the service 2668 given to most of the packets, represented by an instance of 2669 AFService, which is a subclass of DiffServService. The high 2670 demand DiffServService instance will then use the 2671 QoSConditioningSubService aggregation to aggregate together the 2672 necessary classifiers to indicate which traffic it applies to, 2673 and the appropriate meters for contract limits, the marker to 2674 mark the EF PHB in the packets, and the queuing-related 2675 conditioning services. The AFService instance will also use the 2676 QoSConditioningSubService aggregation, to aggregate its 2677 classifiers and meters, the several markers used to mark the 2678 different AF PHBs in the packets, and the queuing-related 2679 conditioning services needed to deliver the packet treatment. 2681 QoSService is modeled as a type of Service, which is used as the 2682 anchor point for defining a set of sub-services that implement 2683 the desired conditioning characteristics for different types of 2684 flows. It will direct the specific type of conditioning services 2685 to be used in order to implement this service. 2687 The class definition is as follows: 2689 NAME QoSService 2690 DESCRIPTION A concrete class used to represent a QoS 2691 service or set of services, as defined 2692 by a network administrator. 2693 DERIVED FROM Service 2694 TYPE Concrete 2695 PROPERTIES (none) 2697 4.3.24. The Class DiffServService 2699 This is a concrete class representing the use of standard or 2700 custom DiffServ services to implement a (higher-level) QoS 2701 service. Note that a DiffServService object may be just one of a 2702 set of coordinated QoSSubServices objects that together implement 2703 a higher-level QoS service. 2705 DiffServService is modeled as a subclass of QoSService. This 2706 enables it to be related to a higher-level QoS service via 2707 QoSSubService, as well as to specific ConditioningService objects 2708 (e.g., metering, dropping, queuing, and others) via 2709 QoSConditioningSubService. 2711 The class definition is as follows: 2713 NAME DiffServService 2714 DESCRIPTION A concrete class used to represent a 2715 DiffServ service associated with a 2716 particular Per Hop Behavior. 2717 DERIVED FROM QoSService 2718 TYPE Concrete 2719 PROPERTIES PHBID 2721 4.3.24.1 The Property PHBID 2723 This property is a 16-bit unsigned integer, which identifies a 2724 particular per hop behavior, or family of per hop behaviors. The 2725 value here is a Per Hop Behavior Identification Code, as defined 2726 in [R3140]. Note that as defined, these identification codes use 2727 the default, recommended, code points for PHBs as part of their 2728 structure. These values may well be different from the actual 2729 value used in the marker, as the marked value is a domain- 2730 dependent value. The ability to indicate the PHB Identification 2731 Code associated with a service is helpful for tying the QoS 2732 Service to reference documents, and for inter-domain coordination 2733 and operation. 2735 4.3.25. The Class AFService 2737 This is a concrete class that represents a specialization of the 2738 general concept of forwarding network traffic, by adding specific 2739 semantics that characterize the operation of the Assured 2740 Forwarding (AF) Service ([R2597]). 2742 [R2597] defines four different AF classes, to represent four 2743 different treatments of traffic. A different amount of 2744 forwarding resources, such as buffer space and bandwidth, are 2745 allocated to each AF class. Within each AF class, IP packets are 2746 marked with one of three possible drop precedence values. The 2747 drop precedence of a packet determines the relative importance of 2748 that packet compared to other packets within the same AF class, 2749 if congestion occurs. A congested interface will try to avoid 2750 dropping packets marked with a lower drop precedence value, by 2751 instead discarding packets marked with a higher drop precedence 2752 value. 2754 Note that [R2597] defines 12 DSCPs that together represent the AF 2755 Per Hop Behavior (PHB) group. Implementations are free to extend 2756 this (e.g., add more classes and/or drop precedences). 2758 The AFService class is modeled as a specialization of 2759 DiffServService, which is in turn a specialization of QoSService. 2760 This enables it to be related to higher-level QoS services, as 2761 well as to lower-level conditioning sub-services (e.g., 2762 classification, metering, dropping, queuing, and others). 2764 The class definition is as follows: 2766 NAME AFService 2767 DESCRIPTION A concrete class for describing the 2768 common characteristics of differentiated 2769 services that are used to affect 2770 traffic forwarding, using the AF 2771 PHB Group. 2772 DERIVED FROM DiffServService 2773 TYPE Concrete 2774 PROPERTIES ClassNumber, DropperNumber 2776 4.3.25.1 The Property ClassNumber 2778 This property is an 8-bit unsigned integer that indicates the 2779 number of AF classes that this AF implementation uses. Among the 2780 instances aggregated using the QoSConditioningSubService 2781 aggregation with an instance of AFService, one SHOULD find 2782 markers with as many distinct values as the ClassNumber of the 2783 AFService instance. 2785 4.3.25.2 The Property DropperNumber 2787 This property is an 8-bit unsigned integer that indicates the 2788 number of drop precedence values that this AF implementation 2789 uses. The number of drop precedence values is the number PER AF 2790 CLASS. The corresponding droppers will be found in the 2791 collection of conditioning services aggregated with the 2792 QoSConditioningSubService aggregation. 2794 4.3.26. The Class FlowService 2796 This class represents a service that supports a particular 2797 microflow. The microflow is identified by the string-valued 2798 property FlowID. In some implementations, an instance of this 2799 class corresponds to an entry in the implementation's flow table. 2801 The class definition is as follows: 2803 NAME FlowService 2804 DESCRIPTION A concrete class representing a 2805 microflow. 2806 DERIVED FROM QoSService 2807 TYPE Concrete 2808 PROPERTIES FlowID 2810 4.3.26.1 The Property FlowID 2812 This property is a string containing an identifier for a 2813 microflow. 2815 4.3.27. The Class DropThresholdCalculationService 2817 This class represents a logical entity that calculates an average 2818 queue depth for a queue, based on a smoothing weight and a 2819 sampling time interval. It does this calculation on behalf of a 2820 RED dropper, to allow the dropper to make its decisions whether 2821 to drop packets based on a smoothed average queue depth for the 2822 queue. 2824 The class definition is as follows: 2826 NAME DropThresholdCalculationService 2827 DESCRIPTION A concrete class representing a logical 2828 entity that calculates an average queue 2829 depth for a queue, based on a smoothing 2830 weight and a sampling time interval. 2831 The latter are properties of this 2832 Service, describing how it operates and 2833 its necessary parameters. 2834 DERIVED FROM Service 2835 TYPE Concrete 2836 PROPERTIES SmoothingWeight, TimeInterval 2838 4.3.27.1 The Property SmoothingWeight 2840 This property is a 32-bit unsigned integer, ranging between 0 and 2841 100,000 - specified in thousandths. It defines the weighting of 2842 past history in affecting the calculation of the current average 2843 queue depth. The current queue depth calculation uses the 2844 inverse of this value as its factor, and one minus that inverse 2845 as the factor for the historical average. The calculation takes 2846 the form: 2848 average = (old_average*(1-inverse of SmoothingWeight)) 2849 + (current_queue_depth*inverse of SmoothingWeight) 2851 Implementations may choose to limit the acceptable set of values 2852 to a specified set, such as powers of 2. 2854 Min and max values are 0 and 100000. 2856 4.3.27.2 The Property TimeInterval 2858 This property is a 32-bit unsigned integer, defining the number 2859 of nanoseconds between each calculation of average/smoothed queue 2860 depth. If this property is not specified, the CalculationService 2861 may determine an appropriate interval. 2863 4.3.28. The Abstract Class FilterEntryBase 2865 FilterEntryBase is the abstract base class from which all filter 2866 entry classes are derived. It serves as the endpoint for the 2867 EntriesInFilterList aggregation, which groups filter entries into 2868 filter lists. Its properties include CIM naming properties and 2869 an IsNegated boolean property (to easily "NOT" the match 2870 information specified in an instance of one of its subclasses). 2872 Because FilterEntryBase has general applicability, it is defined 2873 in [PCIME]. See [PCIME] for the definition of this class. 2875 4.3.29. The Class IPHeaderFilter 2877 This concrete class makes it possible to represent an entire IP 2878 header filter in a single object. A property IpVersion 2879 identifies whether the IP addresses in an instance are IPv4 or 2880 IPv6 addresses. (Since the source and destination IP addresses 2881 come from the same packet header, they will always be of the same 2882 type.) 2884 See [PCIME] for the definition of this class. 2886 4.3.30. The Class 8021Filter 2888 This concrete class allows 802.1.source and destination MAC 2889 addresses, as well as the 802.1 protocol ID, priority, and VLAN 2890 identifier fields, to be expressed in a single object 2892 See [PCIME] for the definition of this class. 2894 4.3.31. The Class PreambleFilter 2896 This is a concrete class that models classifying packets using 2897 traffic-conditioning results stored in a packet preamble by a 2898 PreambleMarkerService. See Section 3.8.3 for a discussion of 2899 how, and why, QDDIM models the capability to store these results 2900 in a packet preamble. An instance of PreambleFilter is used to 2901 select packets based on a two-part string identifying a specific 2902 result. The logic for this match is "at least one." That is, a 2903 packet with multiple results in its preamble matches a filter if 2904 at least one of these results matches the filter. 2906 The class definition is as follows: 2908 NAME PreambleFilter 2909 DESCRIPTION A concrete class representing criteria 2910 for selecting packets based on prior 2911 traffic-conditioning results stored in 2912 a packet preamble. 2913 DERIVED FROM FilterEntryBase 2914 TYPE Concrete 2915 PROPERTIES FilterItemList[ ] 2916 4.3.31.1 The Multi-valued Property FilterItemList 2918 This property is an ordered list of strings, where each string 2919 has the format ",". See Section 3.8.3 for a list of 2920 's defined in QDDIM, and the nature of the associated 2921 for each of these types. 2923 Note that there are two parallel terminologies for characterizing 2924 meter results. The enumeration value "conforming(1)" is 2925 sometimes described as "in profile," and the value 2926 "nonConforming(3)" is sometimes described as "out of profile." 2928 4.3.32. The Class FilterList 2930 This is a concrete class that aggregates instances of (subclasses 2931 of) FilterEntryBase via the aggregation EntriesInFilterList. It 2932 is possible to aggregate different types of filters into a single 2933 FilterList - for example, packet header filters (represented by 2934 the IPHeaderFilter class) and security filters (represented by 2935 subclasses of FilterEntryBase defined by IPsec). 2937 The aggregation property EntriesInFilterList.EntrySequence is 2938 always set to 0, to indicate that the aggregated filter entries 2939 are ANDed together to form a selector for a class of traffic. 2941 See [PCIME] for the definition of this class. 2943 4.3.33. The Abstract Class ServiceAccessPoint 2945 This is an abstract class defined in the Core Model of CIM. It 2946 is a subclass of the LogicalElement class, and is the base class 2947 for all objects that manage access to CIM_Services. It 2948 represents the management of utilizing or invoking a Service. 2949 Please refer to [CIM] for the full definition of this class. 2951 4.3.34. The Class ProtocolEndpoint 2953 This is a concrete class derived from ServiceAccessPoint, which 2954 describes a communication point from which the services of the 2955 network or the system's protocol stack may be accessed. Please 2956 refer to [CIM] for the full definition of this class. 2958 4.3.35. The Abstract Class Collection 2960 This is an abstract class defined in the Core Model of CIM. It 2961 is the superclass for all classes that represent groupings or 2962 bags, and that carry no status or "state". (The latter would be 2963 more correctly modeled as ManagedSystemElements.) Please refer 2964 to [CIM] for the full definition of this class. 2966 4.3.36. The Abstract Class CollectionOfMSEs 2968 This is an abstract class defined in the Core Model of CIM. It 2969 is a subclass of the Collection superclass, restricting the 2970 contents of the Collection to ManagedSystemElements. Please 2971 refer to [CIM] for the full definition of this class. 2973 4.3.37. The Class BufferPool 2975 This is a concrete class that represents the collection of 2976 buffers used by a QueuingService. (The association 2977 QueueAllocation represents this usage.) The existence and 2978 management of individual buffers may be modeled in a future 2979 document. At the current level of abstraction, modeling the 2980 existence of the BufferPool is necessary. Long term, it is not 2981 sufficient. 2983 In implementations where there are multiple buffer sizes, an 2984 instance of BufferPool should be defined for each set of buffers 2985 with identical or similar sizes. These instances of buffer pools 2986 can then be grouped together using the CollectedBuffersPool 2987 aggregation. 2989 Note that this class is derived from CollectionOfMSEs, and not 2990 from Forwarding or ConditioningService. A BufferPool is only a 2991 collection of storage, and is NOT a Service. 2993 The class definition is as follows: 2995 NAME BufferPool 2996 DESCRIPTION A concrete class representing 2997 a collection of buffers. 2998 DERIVED FROM CollectionOfMSEs 2999 TYPE Concrete 3000 PROPERTIES Name, BufferSize, TotalBuffers, 3001 AvailableBuffers, SharedBuffers 3003 4.3.37.1 The Property Name 3005 This property is a string with a maximum length of 256 3006 characters. It is the common name or label by which the object 3007 is known. 3009 4.3.37.2 The Property BufferSize 3011 This property is a 32-bit unsigned integer, identifying the 3012 approximate number of bytes in each buffer in the buffer pool. 3013 An implementation will typically group buffers of roughly the 3014 same size together, to reduce the number of buffer pools it needs 3015 to manage. This model does not specify the degree to which 3016 buffers in the same buffer pool may differ in size. 3018 4.3.37.3 The Property TotalBuffers 3020 This property is a 32-bit unsigned integer, reporting the total 3021 number of individual buffers in the pool. 3023 4.3.37.4 The Property AvailableBuffers 3025 This property is a 32-bit unsigned integer, reporting the number 3026 of buffers in the Pool that are currently not allocated to any 3027 instance of a QueuingService. Buffers allocated to a 3028 QueuingService could either be in use (that is, currently contain 3029 packet data), or be allocated to a queue pending the arrival of 3030 new packet data. 3032 4.3.37.5 The Property SharedBuffers 3034 This property is a 32-bit unsigned integer, reporting the number 3035 of buffers in the Pool that have been simultaneously allocated to 3036 multiple instances of QueuingService. 3038 4.3.38. The Abstract Class SchedulingElement 3040 This is an abstract class that represents the configuration 3041 information that a PacketSchedulingService has for one of the 3042 elements that it is scheduling. The scheduled element is either 3043 a QueuingService or another PacketSchedulingService. 3045 Among the subclasses of this class, some are defined in such a 3046 way that all of their instances are work conserving. Other 3047 subclasses, however, may have instances that either are or are 3048 not work conserving. In this class, the boolean property 3049 WorkConserving indicates whether an instance is or is not work 3050 conserving. The range of values for WorkConserving is restricted 3051 to TRUE in the subclasses that are inherently work conserving, 3052 since instances of these classes cannot be anything other than 3053 work conserving. 3055 The class definition is as follows: 3057 NAME SchedulingElement 3058 DESCRIPTION An abstract class representing the 3059 configuration information that a 3060 PacketSchedulingService has for one of 3061 the elements that it is scheduling. 3062 DERIVED FROM ManagedElement 3063 TYPE Abstract 3064 PROPERTIES WorkConserving 3066 4.3.38.1 The Property WorkConserving 3068 This boolean property indicates whether the 3069 PacketSchedulingService tied to this instance by the 3070 ElementInSchedulingService aggregation is treating the input tied 3071 to this instance by the QueueToSchedule or 3072 SchedulingServiceToSchedule association in a work-conserving 3073 manner. Note that this property is writeable, indicating that an 3074 administrator can change the behavior of the SchedulingElement - - 3075 but only for those elements that can operate in a non-work 3076 conserving mode. 3078 4.3.39. The Class AllocationSchedulingElement 3080 This class is a subclass of the abstract class SchedulingElement. 3081 It introduces five new properties to support bandwidth-based 3082 scheduling. As is the case with all subclasses of 3083 SchedulingElement, the input associated with an instance of 3084 AllocationSchedulingElement is of one of two types: either a 3085 queue, or another scheduler. 3087 The class definition is as follows: 3089 NAME AllocationSchedulingElement 3090 DESCRIPTION A concrete class containing parameters 3091 for controlling bandwidth-based 3092 scheduling. 3094 DERIVED FROM SchedulingElement 3095 TYPE Concrete 3096 PROPERTIES AllocationUnits, BandwidthAllocation, 3097 BurstAllocation, CanShare, 3098 WorkFlexible 3100 4.3.39.1 The Property AllocationUnits 3102 This property is a 16-bit unsigned integer enumeration that 3103 identifies the units in which the BandwidthAllocation and 3104 BurstAllocation properties are expressed. The following values 3105 are defined: 3107 o bytes(1) 3108 o packets(2) 3109 o cells(3) -- fixed-size, for example, ATM 3111 Note: if the value of AllocationUnits is not one of these three 3112 values, it SHOULD be interpreted as if it had the value '1' 3113 (bytes). 3115 4.3.39.2 The Property BandwidthAllocation 3117 This property is a 32-bit unsigned integer that defines the 3118 number of units/second that should be allocated to the associated 3119 input. The units are identified by the AllocationUnits property. 3121 4.3.39.3 The Property BurstAllocation 3123 This property is a 32-bit unsigned integer that specifies the 3124 amount of temporary or short-term bandwidth (in units per second) 3125 that can be allocated to an input, beyond the amount of bandwidth 3126 allocated through the BandwidthAllocation property. If the 3127 maximum actual bandwidth allocation for the input were to be 3128 measured, it would be the sum of the BurstAllocation and the 3129 BandwidthAllocation properties. The units are identified by the 3130 AllocationUnits property. 3132 4.3.39.4 The Property CanShare 3134 This is a boolean property that, if TRUE, enables unused 3135 bandwidth from the associated input to be allocated to other 3136 inputs serviced by the Scheduler. 3138 4.3.39.5 The Property WorkFlexible 3140 This is a boolean property that, if TRUE, indicates that the 3141 behavior of the scheduler relative to this input can be altered 3142 by changing the value of the inherited property WorkConserving. 3144 4.3.40. The Class WRRSchedulingElement 3146 This class is a subclass of the abstract class SchedulingElement, 3147 representing a weighted round robin (WRR) scheduling discipline. 3148 It introduces a new property WeightingFactor, to give some inputs 3149 a higher probability of being serviced than other inputs. It 3150 also introduces a property Priority, to serve as a tiebreaker to 3151 be used when inputs have equal weighting factors. As is the case 3152 with all subclasses of SchedulingElement, the input associated 3153 with an instance of WRRSchedulingElement is of one of two types: 3154 either a queue, or another scheduler. 3156 Because scheduling of this type is always work conserving, the 3157 inherited boolean property WorkConserving is restricted to the 3158 value TRUE in this class. 3160 The class definition is as follows: 3162 NAME WRRSchedulingElement 3163 DESCRIPTION This class specializes the 3164 SchedulingElement class to add 3165 a per-input weight. This is used 3166 by a weighted round robin packet 3167 scheduler when it handles its 3168 associated inputs. It also adds a 3169 second property to serve as a tie-breaker 3170 in the case where multiple inputs have 3171 been assigned the same weight. 3172 DERIVED FROM SchedulingElement 3173 TYPE Concrete 3174 PROPERTIES WeightingFactor, Priority 3176 4.3.40.1 The Property WeightingFactor 3178 This property is a 32-bit unsigned integer, which defines the 3179 weighting factor that offers some inputs a higher probability of 3180 being serviced than other inputs. This property represents this 3181 probability. Its minimum value is 0, its maximum value is 3182 100000, and its units are thousandths. 3184 4.3.40.2 The Property Priority 3186 This property is a 16-bit unsigned integer, which serves as a 3187 tiebreaker, in the event that two or more inputs have equal 3188 weights. A larger value represents a higher priority. If this 3189 property is specified for any of the WRRSchedulingElements 3190 associated with a PacketSchedulingService, then it must be 3191 specified for all WRRSchedulingElements for that 3192 PacketSchedulingService, and the property values for these 3193 WRRSchedulingElements must all be different. 3195 While this condition may not occur in some implementations of a 3196 weighted round robin scheduler, many implementations require a 3197 priority to resolve an equal-weight condition. In instances 3198 where this behavior is not necessary or is undesirable, this 3199 property may be left unspecified. 3201 4.3.41. The Class PrioritySchedulingElement 3203 This class is a subclass of the abstract class SchedulingElement. 3204 It indicates that a scheduler is taking packets from a set of 3205 inputs using the priority scheduling discipline. As is the case 3206 with all subclasses of SchedulingElement, the input associated 3207 with an instance of PrioritySchedulingElement is of one of two 3208 types: either a queue, or another scheduler. The property 3209 Priority in PrioritySchedulingElement represents the priority for 3210 an input, relative to the priorities of all the other inputs to 3211 which the scheduler that aggregates this 3212 PrioritySchedulingElement is associated. Inputs to which the 3213 scheduler is related via other scheduling disciplines do not 3214 figure in this prioritization. 3216 Because scheduling of this type is always work conserving, the 3217 inherited boolean property WorkConserving is restricted to the 3218 value TRUE in this class. 3220 The class definition is as follows: 3222 NAME PrioritySchedulingElement 3223 DESCRIPTION A concrete class that specializes the 3224 SchedulingElement class to add a 3225 Priority property. This property is 3226 used by a SchedulingService that is doing 3227 priority scheduling for a set of inputs. 3229 DERIVED FROM SchedulingElement 3230 TYPE Concrete 3231 PROPERTIES Priority 3233 4.3.41.1 The Property Priority 3235 This property is a 16-bit unsigned integer that indicates the 3236 priority level of a scheduler input relative to the other inputs 3237 serviced by this PacketSchedulingService. A larger value 3238 represents a higher priority. 3240 4.3.42. The Class BoundedPrioritySchedulingElement 3242 This class is a subclass of the class PrioritySchedulingElement, 3243 which is itself derived from the abstract class 3244 SchedulingElement. As is the case with all subclasses of 3245 SchedulingElement, the input associated with an instance of 3246 BoundedPrioritySchedulingElement is of one of two types: either a 3247 queue, or another scheduler. BoundedPrioritySchedulingElement 3248 adds an upper bound (in kilobits per second) on how much traffic 3249 can be handled from an input. This data is specific to that one 3250 input. It is needed when bounded strict priority scheduling is 3251 performed. 3253 This class inherits from its superclass PrioritySchedulingElement 3254 the restriction of the inherited boolean property WorkConserving 3255 to the value TRUE. 3257 The class definition is as follows: 3259 NAME BoundedPrioritySchedulingElement 3260 DESCRIPTION This concrete class specializes the 3261 PrioritySchedulingElement class to add 3262 a BandwidthBound property. This property 3263 bounds the rate at which traffic from the 3264 associated input can be handled. 3266 DERIVED FROM PrioritySchedulingElement 3267 TYPE Concrete 3268 PROPERTIES BandwidthBound 3270 4.3.42.1 The Property BandwidthBound 3272 This property is a 32-bit unsigned integer that defines the upper 3273 limit on the amount of traffic that can be handled from the 3274 input. This is not a shaped upper bound, since bursts can occur. 3275 It is a strict bound, limiting the impact of the input. The 3276 units are kilobits per second. 3278 4.4. Association Definitions 3280 This section details the QoS device datapath associations, 3281 including the aggregations, which were shown earlier in Figures 4 3282 and 5. These associations are defined as classes in the 3283 Information Model. Each of these classes has two properties 3284 referring to instances of the two classes that the association 3285 links. Some of the association classes have additional 3286 properties as well. 3288 4.4.1. The Abstract Association Dependency 3290 This abstract association defines two object references (named 3291 Antecedent and Dependent) that establish general dependency 3292 relationships between different managed objects in the 3293 information model. The Antecedent reference identifies the 3294 independent object in the association, while the Dependent 3295 reference identifies the entity that IS dependent. 3297 The association's cardinality is many to many. 3299 The association is defined in the Core Model of CIM. Please 3300 refer to [CIM] for the full definition of this class. 3302 4.4.2. The Association ServiceSAPDependency 3304 This association defines two object references that establish a 3305 general dependency relationship between a Service object and a 3306 ServiceAccessPoint object. This relationship indicates that the 3307 referenced Service uses the ServiceAccessPoint of ANOTHER 3308 Service. The Service is the Dependent reference, relying on the 3309 ServiceAccessPoint to gain access to another Service. 3311 The association's cardinality is many to many. 3313 The association is defined in the Core Model of CIM. Please 3314 refer to [CIM] for the full definition of this class. 3316 4.4.3. The Association IngressConditioningServiceOnEndpoint 3318 This association is derived from the association 3319 ServiceSAPDependency, and represents the binding, in the ingress 3320 direction, between a protocol endpoint and the first 3321 ConditioningService that processes packets received via that 3322 protocol endpoint. Since there can only be one "first" 3323 ConditioningService for a protocol endpoint, the cardinality for 3324 the Dependent object reference is narrowed from 0..n to 0..1. 3325 Since, on the other hand, a single ConditioningService can be the 3326 first to process packets received via multiple protocol 3327 endpoints, the cardinality of the Antecedent object reference 3328 remains 0..n. 3330 The class definition is as follows: 3332 NAME IngressConditioningServiceOnEndpoint 3333 DESCRIPTION An association that establishes a 3334 dependency relationship between a protocol 3335 endpoint and the first conditioning 3336 service that processes traffic arriving 3337 via that protocol endpoint. 3338 DERIVED FROM ServiceSAPDependency 3339 ABSTRACT False 3340 PROPERTIES Antecedent[ref ProtocolEndpoint[0..n]], 3341 Dependent[ref ConditioningService[0..1]] 3343 4.4.4. The Association EgressConditioningServiceOnEndpoint 3345 This association is derived from the association 3346 ServiceSAPDependency, and represents the binding, in the egress 3347 direction, between a protocol endpoint and the last 3348 ConditioningService that processes packets before they leave a 3349 network device via that protocol endpoint. (This "last" 3350 ConditioningService is ordinarily a scheduler, but it doesn't 3351 have to be.) Since there can be multiple "last" 3352 ConditioningServices for a protocol endpoint in the case of a 3353 fallback scheduler, the cardinality for the Dependent object 3354 reference remains 0..n. Since, however, a single 3355 ConditioningService cannot be the last one to process packets for 3356 multiple protocol endpoints, the cardinality of the Antecedent 3357 object reference is narrowed from 0..n to 0..1. 3359 The class definition is as follows: 3361 NAME EgressConditioningServiceOnEndpoint 3362 DESCRIPTION An association that establishes a 3363 dependency relationship between a protocol 3364 endpoint and the last conditioning 3365 service(s) that process traffic to be 3366 transmitted via that protocol endpoint. 3367 DERIVED FROM ServiceSAPDependency 3368 ABSTRACT False 3369 PROPERTIES Antecedent[ref ProtocolEndpoint[0..1]], 3370 Dependent[ref ConditioningService[0..n]] 3372 4.4.5. The Association HeadTailDropQueueBinding 3374 This association is a subclass of Dependency, describing the 3375 association between a head or tail dropper and a queue that it 3376 monitors to determine when to drop traffic. The referenced queue 3377 is the one whose queue depth is compared against the Dropper's 3378 threshold. The cardinality is 1..n on the queue side, since a 3379 head/tail dropper must monitor at least one queue. For the 3380 classes HeadTailDropper and HeadTailDropQueueBinding, the rule 3381 for combining the inputs from multiple queues is simple addition: 3383 if the sum of the lengths of the monitored queues exceeds the 3384 dropper's QueueThreshold value, then packets are dropped. This 3385 rule for combining inputs may, however, be overridden by a 3386 different rule in subclasses of one or both of these classes. 3388 The class definition is as follows: 3390 NAME HeadTailDropQueueBinding 3391 DESCRIPTION A generic association used to establish a 3392 dependency relationship between a 3393 head or tail dropper and a queue that it 3394 monitors. 3395 DERIVED FROM Dependency 3396 ABSTRACT False 3397 PROPERTIES Antecedent[ref QueuingService[1..n]], 3398 Dependent[ref 3399 HeadTailDropperService [0..n]] 3401 4.4.6. The Association CalculationBasedOnQueue 3403 This association is a subclass of Dependency, which defines two 3404 object references that establish a dependency relationship 3405 between a QueuingService and an instance of the 3406 DropThresholdCalculationService class. The queue's current depth 3407 is used by the calculation service in calculating an average 3408 queue depth. 3410 The class definition is as follows: 3412 NAME CalculationBasedOnQueue 3413 DESCRIPTION A generic association used to establish a 3414 dependency relationship between a 3415 QueuingService object and a 3416 DropThresholdCalculationService object. 3417 DERIVED FROM ServiceServiceDependency 3418 ABSTRACT False 3419 PROPERTIES Antecedent[ref QueuingService[1..1]], 3420 Dependent[ref 3421 DropThresholdCalculationService [0..n]] 3423 4.4.6.1 The Reference Antecedent 3425 This property is inherited from the Dependency association, and 3426 overridden to serve as an object reference to a QueuingService 3427 object (instead of to the more general ManagedElement). This 3428 reference identifies the queue that the 3429 DropThresholdCalculationService will use in its calculation of 3430 average queue depth. 3432 4.4.6.2 The Reference Dependent 3434 This property is inherited from the Dependency association, and 3435 overridden to serve as an object reference to a 3436 DropThresholdCalculationService object (instead of to the more 3437 general ManagedElement). This reference identifies a 3438 DropThresholdCalculationService that uses the referenced queue's 3439 current depth as one of the inputs to its calculation of average 3440 queue depth. 3442 4.4.7. The Association ProvidesServiceToElement 3444 This association defines two object references that establish a 3445 dependency relationship in which a ManagedSystemElement depends 3446 on the functionality of one or more Services. The association's 3447 cardinality is many to many. 3449 The association is defined in the Core Model of CIM. Please 3450 refer to [CIM] for the full definition of this class. 3452 4.4.8. The Association ServiceServiceDependency 3454 This association defines two object references that establish a 3455 dependency relationship between two Service objects. The 3456 particular type of dependency is represented by the 3457 TypeOfDependency property; typical examples include that one 3458 Service is required to be present or required to have completed 3459 for the other Service to operate. 3461 This association is very similar to the ServiceSAPDependency 3462 relationship. For the latter, the Service is dependent on an 3463 AccessPoint to get at another Service. In this relationship, it 3464 directly identifies its Service dependency. Both relationships 3465 should not be instantiated, since their information is 3466 repetitive. 3468 The association's cardinality is many to many. 3470 The association is defined in the Core Model of CIM. Please 3471 refer to [CIM] for the full definition of this class. 3473 4.4.9. The Association CalculationServiceForDropper 3475 This association is a subclass of ServiceServiceDependency, which 3476 defines two object references that represent the reliance of a 3477 REDDropperService on a DropThresholdCalculationService - 3478 calculating an average queue depth based on the observed depths 3479 of one or more queues. 3481 The class definition is as follows: 3483 NAME CalculationServiceForDropper 3484 DESCRIPTION A generic association used to establish a 3485 dependency relationship between a 3486 calculation service and a 3487 REDDropperSrevice for which it performs 3488 average queue depth calculations 3489 DERIVED FROM ServiceServiceDependency 3490 ABSTRACT False 3491 PROPERTIES Antecedent[ref 3492 DropThresholdCalculationService[1..n]], 3493 Dependent[ref REDDropperService[0..n]] 3495 4.4.9.1 The Reference Antecedent 3497 This property is inherited from the ServiceServiceDependency 3498 association, and overridden to serve as an object reference to a 3499 DropThresholdCalculationService object (instead of to the more 3500 general Service object). The cardinality of the object reference 3501 is 1..n, indicating that a RED dropper may be served by one or 3502 more calculation services. 3504 4.4.9.2 The Reference Dependent 3506 This property is inherited from the ServiceServiceDependency 3507 association, and overridden to serve as an object reference to a 3508 REDDropperService object (instead of to the more general Service 3509 object). This reference identifies a RED dropper served by a 3510 DropThresholdCalculationService. 3512 4.4.10. The Association QueueAllocation 3514 This association is a subclass of Dependency, which defines two 3515 object references that establish a dependency relationship 3516 between a QueuingService and a BufferPool that provides storage 3517 space for the packets in the queue. 3519 The class definition is as follows: 3521 NAME QueueAllocation 3522 DESCRIPTION A generic association used to establish a 3523 dependency relationship between a 3524 QueuingService object and a BufferPool 3525 object. 3526 DERIVED FROM Dependency 3527 ABSTRACT False 3528 PROPERTIES Antecedent[ref BufferPool[0..n]], 3529 Dependent[ref QueuingService[0..n]] 3530 AllocationPercentage 3532 4.4.10.1 The Reference Antecedent 3534 This property is inherited from the Dependency association, and 3535 overridden to serve as an object reference to a BufferPool 3536 object. This reference identifies the BufferPool in which 3537 packets on the QueuingService's queue are stored. 3539 4.4.10.2 The Reference Dependent 3541 This property is inherited from the Dependency association, and 3542 overridden to serve as an object reference to a QueuingService 3543 object. This reference identifies the QueuingService whose 3544 packets are being stored in the BufferPool's buffers. 3546 4.4.10.3 The Property AllocationPercentage 3548 This property is an 8-bit unsigned integer with minimum value of 3549 zero and maximum value of 100. It defines the percentage of the 3550 BufferPool that should be allocated to the referenced 3551 QueuingService. If absolute sizes are desired, this would be 3552 accomplished by defining individual BufferPools of the specified 3553 sizes, with QueueAllocation.AllocationPercentages set to 100. 3555 4.4.11. The Association ClassifierElementUsesFilterList 3557 This association is a subclass of the Dependency association. It 3558 relates one or more ClassifierElements with a FilterList 3559 representing the criteria for selecting packets for each of the 3560 ClassifierElements to process. 3562 In the QDDIM model, a classifier is always modeled as a 3563 ClassifierService that aggregates a set of ClassifierElements. 3564 When ClassifierElements use the NextServiceAfterClassifierElement 3565 association to bind to another ClassifierService (to construct a 3566 hierarchical classifier), the ClassifierElementUsesFilterList 3567 association must not be specified. 3569 The class definition is as follows: 3571 NAME ClassifierElementUsesFilterList 3572 DESCRIPTION An association relating a 3573 ClassifierElement to the FilterList 3574 representing the criteria for selecting 3575 packets for that 3576 ClassifierElement to process. 3577 DERIVED FROM Dependency 3578 ABSTRACT False 3579 PROPERTIES Antecedent[ref FilterList [0..1]], 3580 Dependent[ref ClassifierElement [0..n]] 3582 4.4.11.1 The Reference Antecedent 3584 This property is inherited from the Dependency association, and 3585 overridden to serve as an object reference to a FilterList 3586 object, instead of to the more general ManagedElement object. 3587 Also, its cardinality is restricted to 0 and 1, indicating that a 3588 ClassifierElement uses either one FilterList to select packets 3589 for it or no FilterList when the ClassifierElement uses the 3590 NextServiceAfterClassifierElement association to bind to another 3591 ClassifierService to form a hierarchical classifier. 3593 4.4.11.2 The Reference Dependent 3595 This property is inherited from the Dependency association, and 3596 overridden to serve as an object reference to a ClassifierElement 3597 object, instead of to the more general ManagedElement object. 3598 This reference identifies a ClassifierElement that depends on the 3599 associated FilterList object to represent its packet-selection 3600 criteria. 3602 4.4.12. The Association AFRelatedServices 3604 This association defines two object references that establish a 3605 dependency relationship between two AFService objects. This 3606 dependency is the precedence of the individual AF drop-related 3607 Services within an AF IP packet-forwarding class. 3609 The class definition is as follows: 3611 NAME AFRelatedServices 3612 DESCRIPTION An association used to establish 3613 a dependency relationship between two 3614 AFService objects. 3615 DERIVED FROM Nothing 3616 ABSTRACT False 3617 PROPERTIES AFLowerDropPrecedence[ref 3618 AFService[0..1]], 3619 AFHigherDropPrecedence[ref 3620 AFService[0..n]] 3622 4.4.12.1 The Reference AFLowerDropPrecedence 3624 This property serves as an object reference to an AFService 3625 object that has the lower probability of dropping packets. 3627 4.4.12.2 The Reference AFHigherDropPrecedence 3629 This property serves as an object reference to an AFService 3630 object that has the higher probability of dropping packets. 3632 4.4.13. The Association NextService 3634 This association defines two object references that establish a 3635 predecessor-successor relationship between two 3636 ConditioningService objects. This association is used to 3637 indicate the sequence of ConditioningServices required to process 3638 a particular type of traffic. 3640 Instances of this dependency describe the various relationships 3641 between different ConditioningServices (such as classifiers, 3642 meters, droppers, etc.) that are used collectively to condition 3643 traffic. Both one-to-one and more complicated fan-in and/or fan- 3644 out relationships can be described. The ConditioningServices may 3645 feed one another directly, or they may be mapped to multiple 3646 "next" Services based on the characteristics of the packet. 3648 The class definition is as follows: 3650 NAME NextService 3651 DESCRIPTION An association used to establish 3652 a predecessor-successor relationship 3653 between two ConditioningService objects. 3654 DERIVED FROM Nothing 3655 ABSTRACT False 3656 PROPERTIES PrecedingService[ref 3657 ConditioningService[0..n]], 3658 FollowingService[ref 3659 ConditioningService[0..n]] 3661 4.4.13.1 The Reference PrecedingService 3663 This property serves as an object reference to a 3664 ConditioningService object that occurs earlier in the processing 3665 sequence for a given type of traffic. 3667 4.4.13.2 The Reference FollowingService 3669 This property serves as an object reference to a 3670 ConditioningService object that occurs later in the processing 3671 sequence for a given type of traffic, immediately after the 3672 ConditioningService identified by the PrecedingService object 3673 reference. 3675 4.4.14. The Association NextServiceAfterClassifierElement 3677 This association refines the definition of its superclass, the 3678 NextService association, in two ways: 3680 o It restricts the PrecedingService object reference to the 3681 class ClassifierElement. 3683 o It restricts the cardinality of the FollowingService 3684 object reference to exactly 1. 3686 The class definition is as follows: 3688 NAME NextServiceAfterClassifierElement 3689 DESCRIPTION An association used to establish 3690 a predecessor-successor relationship 3691 between a single ClassifierElement within 3692 a Classifier and the next 3693 ConditioningService object that is 3694 responsible for further processing of 3695 the traffic selected by that 3696 ClassifierElement. 3697 DERIVED FROM NextService 3698 ABSTRACT False 3699 PROPERTIES PrecedingService 3700 [ref ClassifierElement[0..n]], 3701 FollowingService 3702 [ref ConditioningService[1..1] 3704 4.4.14.1 The Reference PrecedingService 3706 This property is inherited from the NextService association. It 3707 is overridden in this subclass to restrict the object reference 3708 to a ClassifierElement, as opposed to the more general 3709 ConditioningService defined in the NextService superclass. 3711 This property serves as an object reference to a 3712 ClassifierElement, which is a component of a single 3713 ClassifierService. Packets selected by this ClassifierElement 3714 are always passed to the ConditioningService identified by the 3715 FollowingService object reference. 3717 4.4.14.2 The Reference FollowingService 3719 This property is inherited from the NextService association. It 3720 is overridden in this subclass to restrict the cardinality of the 3721 reference to exactly 1. This reflects the requirement that the 3722 behavior of a DiffServ classifier must be deterministic: the 3723 packets selected by a given ClassifierElement in a given 3724 ClassifierService must always go to one and only one next 3725 ConditioningService. 3727 4.4.15. The Association NextScheduler 3729 This association is a subclass of NextService, and defines two 3730 object references that establish a predecessor-successor 3731 relationship between PacketSchedulingServices. In a hierarchical 3732 queuing configuration where a second scheduler treats the output 3733 of a first scheduler as a single, aggregated input, the two 3734 schedulers are related via the NextScheduler association. 3736 The class definition is as follows: 3738 NAME NextScheduler 3739 DESCRIPTION An association used to establish 3740 predecessor-successor relationships 3741 between PacketSchedulingService objects 3742 for simple hierarchical scheduling. 3743 DERIVED FROM NextService 3744 ABSTRACT False 3745 PROPERTIES PrecedingService[ref 3746 PacketSchedulingService[0..n]], 3747 FollowingService[ref 3748 PacketSchedulingService[0..1]] 3750 4.4.15.1 The Reference PrecedingService 3752 This property is inherited from the NextService association, and 3753 overridden to serve as an object reference to a 3754 PacketSchedulingService object (instead of to the more general 3755 ConditioningService object). This reference identifies a 3756 scheduler whose output is being treated as a single, aggregated 3757 input by the scheduler identified by the FollowingService 3758 reference. The [0..n] cardinality indicates that a single 3759 FollowingService scheduler may bring together the aggregated 3760 outputs of multiple prior schedulers. 3762 4.4.15.2 The Reference FollowingService 3764 This property is inherited from the NextService association, and 3765 overridden to serve as an object reference to a 3766 PacketSchedulingService object (instead of to the more general 3767 ConditioningService object). This reference identifies a 3768 scheduler that includes among its inputs the aggregated outputs 3769 of one or more PrecedingService schedulers. 3771 4.4.16. The Association FailNextScheduler 3773 This association is a subclass of the NextScheduler association. 3774 FailNextScheduler represents the relationship between two 3775 schedulers when the first scheduler passes up a scheduling 3776 opportunity (thereby behaving in a non-work conserving manner), 3777 and makes the resulting bandwidth available to the second 3778 scheduler for its use. See Sections 3.11.3 and 3.11.4 for 3779 examples of where this association might be used. 3781 The class definition is as follows: 3783 NAME FailNextScheduler 3784 DESCRIPTION This association specializes the 3785 NextScheduler association. It 3786 establishes a relationship between a 3787 non-work-conserving scheduler and a 3788 second scheduler to which it makes 3789 available the bandwidth that it elects 3790 not to use. 3791 DERIVED FROM NextScheduler 3792 ABSTRACT False 3793 PROPERTIES PrecedingService[ref 3794 NonWorkConservingSchedulingService[0..n]] 3795 4.4.16.1 The Reference PrecedingService 3797 This property is inherited from the NextScheduler association, 3798 and overridden to serve as an object reference to a 3799 NonWorkConservingSchedulingService object (instead of to the more 3800 general PacketSchedulingService object). This reference 3801 identifies a non-work-conserving scheduler whose excess bandwidth 3802 is being made available to the scheduler identified by the 3803 FollowingService reference. The [0..n] cardinality indicates 3804 that a single FollowingService scheduler may have the opportunity 3805 to use the unused bandwidth of multiple prior non-work-conserving 3806 schedulers. 3808 4.4.17. The Association NextServiceAfterMeter 3810 This association describes a predecessor-successor relationship 3811 between a MeterService and one or more ConditioningService 3812 objects that process traffic from the meter. For example, for 3813 devices that implement preamble marking, the FollowingService 3814 reference (after the meter) is a PreambleMarkerService, to record 3815 the results of the metering in the preamble. 3817 It might be expected that the NextServiceAfterMeter association 3818 would subclass from NextService. However, meters are 1:n fan-out 3819 elements, and require a mechanism to distinguish between the 3820 different results/outputs of the meter. Therefore, this 3821 association defines a new key property, MeterResult, which is 3822 used to record the result and identify the output through which 3823 this traffic left the meter. Because of this additional key, 3824 NextServiceAfterMeter cannot be a subclass of NextService. 3826 The class definition is as follows: 3828 NAME NextServiceAfterMeter 3829 DESCRIPTION An association used to establish 3830 a predecessor-successor relationship 3831 between a particular output of a 3832 MeterService and the next 3833 ConditioningService object that is 3834 responsible for further processing of 3835 the traffic. 3836 DERIVED FROM Nothing 3837 ABSTRACT False 3838 PROPERTIES PrecedingService[ref MeterService[0..n]], 3839 FollowingService[ref 3840 ConditioningService[0..n]], 3841 MeterResult 3842 4.4.17.1 The Reference PrecedingService 3844 The preceding MeterService, 'earlier' in the processing sequence 3845 for a packet. Since Meters are 1:n fan-out devices, this 3846 relationship associates a particular output of a MeterService 3847 (identified by the MeterResult property) to the next 3848 ConditioningService that is used to further process the traffic. 3850 4.4.17.2 The Reference FollowingService 3852 The 'next' or following ConditioningService. 3854 4.4.17.3 The Property MeterResult 3856 This property is an enumerated 16-bit unsigned integer, and 3857 represents information describing the result of the metering. 3858 Traffic is distinguished as being conforming, non-conforming, or 3859 partially conforming. More complicated metering can be built 3860 either by extending the enumeration or by cascading meters. 3862 The enumerated values are: "Unknown" (0), "Conforming" (1), 3863 "PartiallyConforming" (2), "NonConforming" (3). 3865 4.4.18. The Association QueueToSchedule 3867 This is a top-level association, representing the relationship 3868 between a queue (QueuingService) and a SchedulingElement. The 3869 SchedulingElement, in turn, represents the information in a 3870 packet scheduling service that is specific to this queue, such as 3871 relative priority or allocated bandwidth. 3873 It cannot be expressed formally with the association 3874 cardinalities, but there is an additional constraint on 3875 participation in this association. A particular instance of (a 3876 subclass of) SchedulingElement always participates either in 3877 exactly one instance of this association, or in exactly one 3878 instance of the association SchedulingServiceToSchedule. 3880 The class definition is as follows: 3882 NAME QueueToSchedule 3883 DESCRIPTION This association relates a queue to 3884 the SchedulingElement containing 3885 information specific to the queue. 3886 DERIVED FROM Nothing 3887 ABSTRACT False 3888 PROPERTIES Queue[ref QueuingService[0..1]], 3889 SchedElement[ref 3890 SchedulingElement[0..n]] 3891 4.4.18.1 The Reference Queue 3893 This property serves as an object reference to a QueuingService 3894 object. A QueuingService object may be associated 0 or more 3895 SchedulingElement objects. 3897 4.4.18.2 The Reference SchedElement 3899 This property serves as an object reference to a 3900 SchedulingElement object. A SchedulingElement is always 3901 associated either with exactly one QueuingService or with exactly 3902 one upstream scheduler (PacketSchedulingService). 3904 4.4.19. The Association SchedulingServiceToSchedule 3906 This is a top-level association, representing the relationship 3907 between a scheduler (PacketSchedulingService) and a 3908 SchedulingElement, in a configuration involving cascaded 3909 schedulers. The SchedulingElement, in turn, represents the 3910 information in a subsequent packet scheduling service that is 3911 specific to this scheduler, such as relative priority or 3912 allocated bandwidth. 3914 It cannot be expressed formally with the association 3915 cardinalities, but there is an additional constraint on 3916 participation in this association. A particular instance of (a 3917 subclass of) SchedulingElement always participates either in 3918 exactly one instance of this association, or in exactly one 3919 instance of the association QueueToSchedule. 3921 The class definition is as follows: 3923 NAME SchedulingServiceToSchedule 3924 DESCRIPTION This association relates a scheduler to 3925 the SchedulingElement in a subsequent 3926 scheduler containing information specific 3927 to this scheduler. 3928 DERIVED FROM Nothing 3929 ABSTRACT False 3930 PROPERTIES SchedService[ref 3931 PacketSchedulingService[0..1]], 3932 SchedElement[ref 3933 SchedulingElement[0..n]] 3935 4.4.19.1 The Reference SchedService 3937 This property serves as an object reference to a 3938 PacketSchedulingService object. A PacketSchedulingService object 3939 may be associated 0 or more SchedulingElement objects. 3941 4.4.19.2 The Reference SchedElement 3943 This property serves as an object reference to a 3944 SchedulingElement object. A SchedulingElement is always 3945 associated either with exactly one QueuingService or with exactly 3946 one upstream scheduler (PacketSchedulingService). 3948 4.4.20. The Aggregation MemberOfCollection 3950 This aggregation is a generic relationship used to model the 3951 aggregation of a set of ManagedElements in a generalized 3952 Collection object. The aggregation's cardinality is many to 3953 many. 3955 MemberOfCollection is defined in the Core Model of CIM. Please 3956 refer to [CIM] for the full definition of this class. 3958 4.4.21. The Aggregation CollectedBufferPool 3960 This aggregation models the ability to treat a set of buffers as 3961 a pool, or collection, that can in turn be contained in a 3962 "higher-level" buffer pool. This class overrides the more 3963 generic MemberOfCollection aggregation to restrict both the 3964 aggregate and the part component objects to be instances only of 3965 the BufferPool class. 3967 The class definition for the aggregation is as follows: 3969 NAME CollectedBufferPool 3970 DESCRIPTION A generic association used to aggregate 3971 a set of related buffers into a 3972 higher-level buffer pool. 3973 DERIVED FROM MemberOfCollection 3974 ABSTRACT False 3975 PROPERTIES Collection[ref BufferPool[0..1]], 3976 Member[ref BufferPool[0..n]] 3978 4.4.21.1 The Reference Collection 3980 This property represents the parent, or aggregate, object in the 3981 relationship. It is a BufferPool object. 3983 4.4.21.2 The Reference Member 3985 This property represents the child, or lower level pool, in the 3986 relationship. It is one of the set of BufferPools that together 3987 make up the higher-level pool. 3989 4.4.22. The Abstract Aggregation Component 3991 This abstract aggregation is a generic relationship used to 3992 establish "part-of" relationships between managed objects (named 3993 GroupComponent and PartComponent). The association's cardinality 3994 is many to many. 3996 The association is defined in the Core Model of CIM. Please 3997 refer to [CIM] for the full definition of this class. 3999 4.4.23. The Aggregation ServiceComponent 4001 This aggregation is used to model a set of subordinate Services 4002 that are aggregated together to form a higher-level Service. 4003 This aggregation is derived from the more generic Component 4004 superclass to restrict the types of objects that can participate 4005 in this relationship. The association's cardinality is many to 4006 many. 4008 The association is defined in the Core Model of CIM. Please 4009 refer to [CIM] for the full definition of this class. 4011 4.4.24. The Aggregation QoSSubService 4013 This aggregation represents a set of subordinate QoSService 4014 objects (that is, a set of instances of subclasses of the 4015 QoSService class) that are aggregated together to form a higher- 4016 level QoSService. A QoSService is a specific type of Service 4017 that conceptualizes QoS functionality as a set of coordinated 4018 sub-services. 4020 This aggregation is derived from the more generic 4021 ServiceComponent superclass to restrict the types of objects that 4022 can participate in this relationship to QoSService objects, 4023 instead of a more generic Service object. It also restricts the 4024 cardinality of the aggregate to 0-or-1 (instead of the more 4025 generic 0-or-more). 4027 The class definition for the aggregation is as follows: 4029 NAME QoSSubService 4030 DESCRIPTION A generic association used to establish 4031 "part-of" relationships between a 4032 higher-level QoSService object and the 4033 set of lower-level QoSServices that 4034 are aggregated to create/form it. 4035 DERIVED FROM ServiceComponent 4036 ABSTRACT False 4037 PROPERTIES GroupComponent[ref QoSService[0..1]], 4038 PartComponent[ref QoSService[0..n]] 4039 4.4.24.1 The Reference GroupComponent 4041 This property is overridden in this aggregation to represent an 4042 object reference to a QoSService object (instead of to the more 4043 generic Service object defined in its superclass). This object 4044 represents the parent, or aggregate, object in the relationship. 4046 4.4.24.2 The Reference PartComponent 4048 This property is overridden in this aggregation to represent an 4049 object reference to a QoSService object (instead of to the more 4050 generic Service object defined in its superclass). This object 4051 represents the child, or "component", object in the relationship. 4053 4.4.25. The Aggregation QoSConditioningSubService 4055 This aggregation identifies the set of conditioning services that 4056 together condition traffic for a particular QoS service. 4058 This aggregation is derived from the more generic 4059 ServiceComponent superclass; it restricts the types of objects 4060 that can participate in it to ConditioningService and QoSService 4061 objects, instead of the more generic Service objects. 4063 The class definition for the aggregation is as follows: 4065 NAME QoSConditioningSubService 4066 DESCRIPTION A generic aggregation used to establish 4067 "part-of" relationships between a set 4068 of ConditioningService objects and the 4069 particular QoSService object(s) that they 4070 provide traffic conditioning for. 4071 DERIVED FROM ServiceComponent 4072 ABSTRACT False 4073 PROPERTIES GroupComponent[ref QoSService[0..n]], 4074 PartComponent[ref 4075 ConditioningService[0..n]] 4077 4.4.25.1 The Reference GroupComponent 4079 This property is overridden in this aggregation to represent an 4080 object reference to a QoSService object (instead of to the more 4081 generic Service object defined in its superclass). The 4082 cardinality of the reference remains 0..n, to indicate that a 4083 given ConditioningService may provide traffic conditioning for 0, 4084 1, or more than 1 QoSService objects. 4086 This object represents the parent, or aggregate, object in the 4087 association. In this case, this object represents the QoSService 4088 that aggregates one or more ConditioningService objects to 4089 implement the appropriate traffic conditioning for its traffic. 4091 4.4.25.2 The Reference PartComponent 4093 This property is overridden in this aggregation to represent an 4094 object reference to a ConditioningService object (instead of to 4095 the more generic Service object defined in its superclass). This 4096 object represents the child, or "component", object in the 4097 relationship. In this case, this object represents one or more 4098 ConditioningService objects that together indicate how traffic 4099 for a specific QoSService is conditioned. 4101 4.4.26. The Aggregation ClassifierElementInClassifierService 4103 This aggregation represents the relationship between a classifier 4104 and the classifier elements that provide the fan-out function for 4105 the classifier. A classifier typically aggregates multiple 4106 classifier elements. A classifier element, however, is 4107 aggregated only by a single classifier. See [DSMODEL] and 4108 [DSMIB] for more about classifiers and classifier elements. 4110 The class definition for the aggregation is as follows: 4112 NAME ClassifierElementInClassifierService 4113 DESCRIPTION An aggregation representing the 4114 relationship between a classifier 4115 and its classifier elements. 4116 DERIVED FROM ServiceComponent 4117 ABSTRACT False 4118 PROPERTIES GroupComponent[ref 4119 ClassifierService[1..1]], 4120 PartComponent[ref 4121 ClassifierElement[0..n], 4122 ClassifierOrder 4124 4.4.26.1 The Reference GroupComponent 4126 This property is overridden in this aggregation to represent an 4127 object reference to a ClassifierService object (instead of to the 4128 more generic Service object defined in its superclass). It also 4129 restricts the cardinality of the aggregate to 1..1 (instead of 4130 the more generic 0-or-more), representing the fact that a 4131 ClassifierElement always exists within the context of exactly one 4132 ClassifierService. 4134 4.4.26.2 The Reference PartComponent 4136 This property is overridden in this aggregation to represent an 4137 object reference to a ClassifierElement object (instead of to the 4138 more generic Service object defined in its superclass). This 4139 object represents a single traffic selector for the classifier. 4140 A ClassifierElement usually has an association to a FilterList 4141 that provides selection criteria for packets from the traffic 4142 stream coming into the classifier, and to a ConditioningService 4143 to which packets selected by these criteria are next forwarded. 4145 4.4.26.3 The Property ClassifierOrder 4147 Because the filters for a classifier can overlap, it is necessary 4148 to specify the order in which the ClassifierElements aggregated 4149 by a ClassifierService are presented with packets coming into the 4150 classifier. This property is an unsigned 32-bit integer 4151 representing this order. Values are represented in ascending 4152 order: first '1', then '2', and so on. Different values MUST be 4153 assigned for each of the ClassifierElements aggregated by a given 4154 ClassifierService. 4156 4.4.27. The Aggregation EntriesInFilterList 4158 This aggregation is a specialization of the Component 4159 aggregation; it is used to define a set of filter entries 4160 (subclasses of FilterEntryBase) that are aggregated by a 4161 FilterList. 4163 The cardinalities of the aggregation itself are 0..1 on the 4164 FilterList end, and 0..n on the FilterEntryBase end. Thus in the 4165 general case, a filter entry can exist without being aggregated 4166 into any FilterList. However, the only way a filter entry can 4167 figure in the QoS Device model is by being aggregated into a 4168 FilterList by this aggregation. 4170 See [PCIME] for the definition of this aggregation. 4172 4.4.28. The Aggregation ElementInSchedulingService 4174 This concrete aggregation represents the relationship between a 4175 PacketSchedulingService and the set of SchedulingElements that 4176 tie it to its inputs. 4178 The class definition for the aggregation is as follows: 4180 NAME ElementInSchedulingService 4181 DESCRIPTION An aggregation used to tie a 4182 PacketSchedlingService to the 4183 configuration information for one of 4184 the elements (either a QueuingService or 4185 another PacketSchedulingService) that it 4186 schedules. 4187 DERIVED FROM Component 4188 ABSTRACT False 4189 PROPERTIES GroupComponent[ref 4190 PacketSchedulingService[0..1]], 4191 PartComponent[ref 4192 SchedulingElement[1..n] 4193 4.4.28.1 The Reference GroupComponent 4195 This property is overridden in this aggregation to represent an 4196 object reference to a PacketSchedulingService object (instead of 4197 to the more generic Service object defined in its superclass). 4198 It also restricts the cardinality of the aggregate to 0..1 4199 (instead of the more generic 0-or-more), representing the fact 4200 that a SchedulingElement exists within the context of at most one 4201 PacketSchedulingService. 4203 4.4.28.2 The Reference PartComponent 4205 This property is overridden in this aggregation to represent an 4206 object reference to a SchedulingElement object (instead of to the 4207 more generic Service object defined in its superclass). This 4208 object represents a single scheduling element for the scheduler. 4209 It also restricts the cardinality of the SchedulingElement to 4210 1..n (instead of the more generic 0-or-more), representing the 4211 fact that a PacketSchedulingService always includes at least one 4212 SchedulingElement. 4214 5. Intellectual Property 4216 The IETF takes no position regarding the validity or scope of any 4217 intellectual property or other rights that might be claimed to 4218 pertain to the implementation or use of the technology described 4219 in this document or the extent to which any license under such 4220 rights might or might not be available; neither does it represent 4221 that it has made any effort to identify any such rights. 4222 Information on the IETF's procedures with respect to rights in 4223 standards-track and standards-related documentation can be found 4224 in BCP-11. 4226 Copies of claims of rights made available for publication and any 4227 assurances of licenses to be made available, or the result of an 4228 attempt made to obtain a general license or permission for the 4229 use of such proprietary rights by implementers or users of this 4230 specification can be obtained from the IETF Secretariat. 4232 The IETF invites any interested party to bring to its attention 4233 any copyrights, patents or patent applications, or other 4234 proprietary rights which may cover technology that may be 4235 required to practice this standard. Please address the 4236 information to the IETF Executive Director. 4238 6. Acknowledgements 4240 The authors wish to thank the participants of the Policy 4241 Framework and Differentiated Services working groups for their 4242 many helpful comments and suggestions. Special thanks to Joel 4243 Halpern, who provided some key technical direction during the 4244 latter stages of the document's development. 4246 7. Security Considerations 4248 Like [PCIM} and {PCiME}, this document defines an information 4249 model that cannot be implemented directly. Consequently, 4250 security issues do not arise until it is mapped to an actual, 4251 implementable data model such as a MIB, PIB, or LDAP schema. See 4252 [PCIM] for a general discussion of security considerations for 4253 information models. See also [DSMIB] (which in fact is a data 4254 model that corresponds to a large extent with the QDDIM 4255 information model), for a discussion of the security implications 4256 of specific objects in the model. 4258 8. Normative References 4260 [CIM] Common Information Model (CIM) Schema, version 2.5. 4261 Distributed Management Task Force, Inc., available at 4262 http://www.dmtf.org/standards/cim_schema_v25.php. 4264 [IEEE802Q] Virtual Bridged Local Area Networks, ANSI/IEEE std 4265 802.1Q, 1998 edition. Approved December 8, 1998 4267 [PCIM] Policy Core Information Model - Version 1 Specification. 4268 RFC 3060, B. Moore, E. Ellesson, J. Strassner, and A. 4269 Westerinen. February 2001. 4271 [PCIME] Policy Core Information Model Extensions. Internet- 4272 Draft, RFC 3460, B. Moore, January 2003. 4274 [R791] Postel, J., Editor, "Internet Protocol", STD RFC 791, 4275 September 1981. 4277 [R2119] Key words for use in RFCs to Indicate Requirement 4278 Levels. S. Bradner. March 1997. 4280 [R2474] Definition of the Differentiated Services Field (DS 4281 Field) in the IPv4 and IPv6 Headers. K. Nichols, S. 4282 Blake, F. Baker, and D. Black. December 1998. 4284 [R2597] Assured Forwarding PHB Group. J. Heinanen, F. Baker, 4285 W. Weiss, and J. Wroclawski. June 1999. 4287 [R3140] Per Hop Behavior Identification Codes. D. Black, S. 4288 Brim, B. Carpenter, and F. Le Faucheur. June 2001. 4290 9. Informative References 4292 [DSMIB] Management Information Base for the Differentiated 4293 Services Architecture. RFC 3289, F. Baker, K. Chan, and 4294 A. Smith. May 2002. 4296 [DSMODEL] An Informal Management Model for DiffServ Routers. 4297 Internet Draft, RFC 3290, Y. Bernet, A. Smith, S. Blake, 4298 and D. Grossman. May 2002. 4300 [PIB] Differentiated Services Quality of Service Policy 4301 Information Base. RFC 3317, K. Chan, S. Hahn, R. Sahita, 4302 K. McCloghrie. March 2003. 4304 [POLTERM] Policy Terminology. RFC 3198, A. Westerinen, et al. 4305 November 2001. 4307 [QPIM] Policy Framework QoS Information Model. Internet Draft, 4308 draft-ietf-policy-qos-info-model-05.txt, Y. Snir, Y. 4309 Ramberg, J. Strassner, R. Cohen, and B. Moore. May 2003. 4311 [R1633] Integrated Services in the Internet Architecture: An 4312 Overview. R. Braden, D. Clark, and S. Shenker. June 4313 1994. 4315 [R1825] Security Architecture for the Internet Protocol. R. 4316 Atkinson. August 1995. 4318 [R2475] An Architecture for Differentiated Service. S. Blake, 4319 D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss. 4320 December 1998. 4322 [R2598] An Expedited Forwarding PHB. V. Jacobson, K. Nichols, 4323 and K. Poduri. June 1999. 4325 [RED] See http://www.aciri.org/floyd/red.html. 4327 10. Authors' Addresses 4329 Bob Moore 4330 P. O. Box 12195, BRQA/B501/G206 4331 3039 Cornwallis Rd. 4332 Research Triangle Park, NC 27709-2195 4333 Phone: +1-919-254-4436 4334 E-mail: remoore@us.ibm.com 4336 David Durham 4337 Intel 4338 2111 NE 25th Avenue 4339 Hillsboro, OR 97124 4340 Phone: (503) 264-6232 4341 Email: david.durham@intel.com 4343 John Strassner 4344 INTELLIDEN, Inc. 4345 90 South Cascade Avenue 4346 Colorado Springs, CO 80903 4347 Phone: +1-719-785-0648 4348 E-mail: john.strassner@intelliden.com 4350 Andrea Westerinen 4351 Cisco Systems, Bldg 20 4352 725 Alder Drive 4353 Milpitas, CA 95035 4354 E-mail: andreaw@cisco.com 4356 Walter Weiss 4357 Ellacoya Networks 4358 7 Henry Clay Dr. 4359 Merrimack, NH 03054 4360 Phone: +1-603-879-7364 4361 E-mail: wweiss@ellacoya.com 4363 11. Full Copyright Statement 4365 Copyright (C) The Internet Society (2003). All Rights Reserved. 4367 This document and translations of it may be copied and furnished 4368 to others, and derivative works that comment on or otherwise 4369 explain it or assist in its implementation may be prepared, 4370 copied, published and distributed, in whole or in part, without 4371 restriction of any kind, provided that the above copyright notice 4372 and this paragraph are included on all such copies and derivative 4373 works. However, this document itself may not be modified in any 4374 way, such as by removing the copyright notice or references to 4375 the Internet Society or other Internet organizations, except as 4376 needed for the purpose of developing Internet standards in which 4377 case the procedures for copyrights defined in the Internet 4378 Standards process must be followed, or as required to translate 4379 it into languages other than English. 4381 The limited permissions granted above are perpetual and will not 4382 be revoked by the Internet Society or its successors or assigns. 4384 This document and the information contained herein is provided on 4385 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 4386 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 4387 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 4388 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 4389 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 4390 PURPOSE. 4392 12. Appendix A: Naming Instances in a Native CIM Implementation 4394 Following the precedent established in [PCIM], this document has 4395 placed the details of how to name instances of its classes in a 4396 native CIM implementation here in an appendix. Since Appendix A 4397 in [PCIM] has a lengthy discussion of the general principles of 4398 CIM naming, this appendix does not repeat that information here. 4399 Readers interested in a more global discussion of how instances 4400 are named in a native CIM implementation should refer to [PCIM]. 4402 12.1. Naming Instances of the Classes Derived from Service 4404 Most of the classes defined in this model are derived from the 4405 CIM class Service. Although Service is an abstract class, it 4406 nevertheless has key properties included as part of its 4407 definition. The purpose of including key properties in an 4408 abstract class is to have instances of all of its instantiable 4409 subclasses named in the same way. Thus, the majority of the 4410 classes in this model name their instances in exactly the same 4411 way: with the two key properties CreationClassName and Name that 4412 they inherit from Service. 4414 12.2. Naming Instances of Subclasses of FilterEntryBase 4416 Like Service, FilterEntryBase (defined in [PCIME]) is an abstract 4417 class that includes key properties in its definition. 4418 FilterEntryBase has four key properties. Two of them, 4419 SystemCreationClassName and SystemName, are propagated to it via 4420 the weak association FilterEntryInSystem. The other two, 4421 CreationClassName and Name, are native to FilterEntryBase. 4423 Thus instances of all of the subclasses of FilterEntryBase, 4424 including the PreambleFilter class defined here, are named in the 4425 same way: with the four key properties they inherit from 4426 FilterEntryBase. 4428 12.3. Naming Instances of ProtocolEndpoint 4430 The class ProtocolEndpoint inherits its key properties from its 4431 superclass, ServiceAccessPoint. These key properties provide the 4432 same naming structure that we've seen before: two propagated key 4433 properties SystemCreationClassName and SystemName, plus two 4434 native key properties CreationClassName and Name. 4436 12.4. Naming Instances of BufferPool 4438 Unlike the other classes in this model, BufferPool is not derived 4439 from Service. Consequently, it does not inherit its key 4440 properties from Service. Instead, it inherits one of its key 4441 properties, CollectionID, from its superclass Collection, and 4442 adds its other key property, CreationClassName, in its own 4443 definition. 4445 12.4.1. The Property CollectionID 4447 CollectionID is a string property with a maximum length of 256 4448 characters. It identifies the buffer pool. Note that this 4449 property is defined in the BufferPool class's superclass, 4450 CollectionOfMSEs, but not as a key property. It is overridden in 4451 BufferPool, to make it part of this class's composite key. 4453 12.4.2. The Property CreationClassName 4455 This property is a string property of with a maximum length of 4456 256 characters. It is set to "CIM_BufferPool" if this class is 4457 directly instantiated, or to the class name of the BufferPool 4458 subclass that is created. 4460 12.5. Naming Instances of SchedulingElement 4462 This class has not yet been incorporated into the CIM model, so 4463 it does not have any CIM naming properties yet. If the normal 4464 pattern is followed, however, instances will be named with two 4465 properties CreationClassName and Name.