Policy Framework Working Group J. Strassner INTERNET-DRAFT A. Westerinen Category: Standards Track Cisco Systems Bob Moore IBM Corporation David Durham Intel Walter Weiss Ellacoya November 2000 Information Model for Describing Network Device QoS Mechanisms for Differentiated Services Friday, November 24, 2000, 10:20 AM Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Strassner, et al. Expires: Nov 2000 + 6 months [Page 1] Internet Draft QoS Device Info Model November 2000 Abstract The purpose of this draft is to define an information model that describes the QoS mechanisms inherent in different network devices, including hosts. Broadly speaking, these mechanisms describe the attributes common to selecting and conditioning traffic through the forwarding path of network devices running Differentiated Services (see [R2475]). Another draft will address Integrated Services (see [R1633]). This draft is intended to be used with the QoS Policy Information Model [QOSPIM] to model how policies can be defined to manage and configure the QoS mechanisms (i.e., the classification, marking, metering, dropping, queuing, and scheduling functionality) of devices. Together, these two drafts describe how to write QoS policy rules to configure and manage the QoS mechanisms of devices. This draft, as well as [QOSPIM], are information models. That is, they represent information independent of a binding to a specific type of repository. A separate draft will be written to provide a mapping of the data contained in this document to a form suitable for implementation in a directory that uses (L)DAP as its access protocol. This latter draft is analogous to [QOSSCH], which provides a similar mapping of the data in [QOSPIM] to a directory. Together, these drafts (information models and schema mappings) then describe how to write QoS policy rules that can be used to store information in directories to configure device QoS mechanisms. Definition of Key Word Usage The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [R2119]. Strassner, et al. Expires: Nov 2000 + 6 months [Page 2] Internet Draft QoS Device Info Model November 2000 Table of Contents 1. Introduction......................................................5 1.1. Policy Management Conceptual Model...........................6 1.2. Purpose and Relation to Other Policy Work....................7 1.3. Typical Examples of Policy Usage.............................7 2. Approach..........................................................8 2.1. Common Needs Of DiffServ and IntServ.........................8 2.2. Specific Needs Of DiffServ...................................9 2.3. Specific Needs Of IntServ....................................9 3. Methodology......................................................10 3.1. Level of Abstraction for Expressing QoS Policies............10 3.2. Specifying Policy Parameters................................11 3.3. Specifying Policy Services..................................12 3.4. Level of Abstraction for Defining QoS Attributes and Classes..........................................................13 3.5. Characterization of QoS Attributes..........................14 3.6. QoS Information Model Derivation............................15 3.7. Attribute Representation....................................16 3.8. Mental Model................................................16 3.8.1. The QoSService Class......................................17 3.8.2. The ConditioningService Class.............................18 3.8.3. QoS Statistics Classes....................................19 3.9. Classifiers, FilterLists, and FilterEntries.................19 4. The Class Hierarchy..............................................20 4.1. Associations................................................20 4.2. Aggregations................................................21 4.3. The Structure of the Class Hierarchies......................21 4.3.1. The Class Hierarchies for Modeling State Information......21 4.3.2. The Class Hierarchies for Modeling Configuration Information......................................................26 4.4. Class Definitions for the State Portion of the Model........26 4.4.1. The Abstract Class ManagedElement.........................26 4.4.2. The Abstract Class ManagedSystemElement...................27 4.4.3. The Abstract Class LogicalElement.........................27 4.4.4. The Abstract Class Service................................27 4.4.5. The Abstract Class NetworkService.........................27 4.4.6. The Class ForwardingService...............................28 4.4.7. The Class ConditioningService.............................28 4.4.8. The Class ClassifierService...............................29 4.4.9. The Class ClassifierElement...............................30 4.4.10. The Class MeterService...................................30 4.4.11. The Class AverageRateMeter...............................32 4.4.12. The Class EWMAMeter......................................32 4.4.13. The Class TokenBucketMeter...............................33 4.4.14. The Class MarkerService..................................34 4.4.15. The Class ToSMarkerService...............................35 4.4.16. The Class DSCPMarkerService..............................36 4.4.17. The Class PriorityMarkerService..........................36 4.4.18. The Class DropperService.................................37 4.4.19. The Class HeadTailDropperService.........................38 4.4.20. The Class REDDropperService..............................38 4.4.21. The Class QueuingService.................................40 Strassner, et al. Expires: Nov 2000 + 6 months [Page 3] Internet Draft QoS Device Info Model November 2000 4.4.22. The Class PacketSchedulingService........................40 4.4.23. The Class QoSService.....................................41 4.4.24. The Class DiffServService................................42 4.4.25. The Class AFService......................................43 4.4.26. The Class EFService......................................44 4.4.27. The Class PrecedenceService..............................45 4.4.28. The Class 8021PService...................................45 4.4.29. The Class DropThresholdCalculationService................46 4.4.30. The Abstract Class FilterEntryBase.......................47 4.4.31. The Class FilterEntry....................................47 4.4.32. The Class IP6TupleFilter.................................48 4.4.33. The Class 8021Filter.....................................49 4.4.34. The Class 8021PQFilter...................................49 4.4.35. The Class FilterList.....................................50 4.4.36. The Abstract Class ServiceAccessPoint....................50 4.4.37. The Class ProtocolEndpoint...............................50 4.4.38. The Abstract Class Collection............................50 4.4.39. The Abstract Class CollectionOfMSEs......................51 4.4.40. The Class BufferPool.....................................51 4.5. Association Definitions for the State Portion of the Model............................................................52 4.5.1. The Abstract Association Dependency.......................52 4.5.2. The Association ServiceSAPDependency......................52 4.5.3. The Association Forwards Among............................53 4.5.4. The Association ConditioningServiceOnEndpoint.............53 4.5.5. The Association IngressConditioningServiceOnEndpoint......54 4.5.6. The Association EgressConditioningServiceOnEndpoint.......54 4.5.7. The Association HeadTailDropQueueBinding..................55 4.5.8. The Association CalculationBasedOnQueue...................55 4.5.9. The Association ProvidesServiceToElement..................56 4.5.10. The Association ServiceServiceDependency.................56 4.5.11. The Association QueueHierarchy...........................56 4.5.12. The Association CalculationServiceForDropper.............57 4.5.13. The Association QueueAllocation..........................58 4.5.14. The Association ClassifierFilterSet......................59 4.5.15. The Association ClassifierElementUsesFilterList..........60 4.5.16. The Association AFRelatedServices........................60 4.5.17. The Association NextService..............................61 4.5.18. The Association NextServiceAfterMeter....................62 4.5.19. The Association NextServiceAfterClassifierElement........63 4.5.20. The Association SchedulerUsed............................64 4.5.21. The Association PrioritySchedulerUsed....................65 4.5.22. The Association BoundedPrioritySchedulerUsed.............66 4.5.23. The Association BandwidthSchedulerUsed...................66 4.5.24. The Association WRRSchedulerUsed.........................67 4.5.25. The Aggregation MemberOfCollection.......................68 4.5.26. The Aggregation CollectedBufferPool......................68 4.5.27. The Abstract Aggregation Component.......................69 4.5.28. The Aggregation ServiceComponent.........................69 4.5.29. The Aggregation QoSSubService............................69 4.5.30. The Aggregation QoSConditioningSubService................70 4.5.31. The Aggregation ClassifierElementInClassifierService.....71 4.5.32. The Aggregation EntriesInFilterList......................72 Strassner, et al. Expires: Nov 2000 + 6 months [Page 4] Internet Draft QoS Device Info Model November 2000 5. Intellectual Property............................................73 6. Acknowledgements.................................................73 7. Security Considerations..........................................73 8. References.......................................................74 9. Authors' Addresses...............................................75 10. Full Copyright Statement........................................76 11. Appendix A: Naming Instances in a Native CIM Implementation....77 11.1. Naming Instances of the Classes Derived from Service.......77 11.2. Naming Instances of FilterEntry............................77 11.3. Naming Instances of FilterList.............................77 11.4. Naming Instances of ProtocolEndpoint.......................77 11.5. Naming Instances of BufferPool.............................78 11.5.1. The Property CollectionID................................78 11.5.2. The Property CreationClassName...........................78 1. Introduction The purpose of this draft is to define an information model that describes the QoS mechanisms inherent in different network devices, including hosts. Broadly speaking, these mechanisms describe the attributes common to selecting and conditioning traffic through the forwarding path of network devices running Differentiated Services (see [R2475]). Another draft will address Integrated Services (see [R1633]). This draft is intended to be used with the QoS Policy Information Model [QOSPIM] to model how policies can be defined to manage and configure the QoS mechanisms (i.e., the classification, marking, metering, dropping, queuing, and scheduling functionality) of devices. Together, these two drafts describe how to write QoS policy rules to configure and manage the QoS mechanisms of devices. This draft, as well as [QOSPIM], are information models. That is, they represent information independent of a binding to a specific type of repository. A separate draft will be written to provide a mapping of the data contained in this document to a form suitable for implementation in a directory that uses (L)DAP as its access protocol. This latter draft is analogous to [QOSSCH], which provides a similar mapping of the data in [QOSPIM] to a directory. Together, these drafts (information models and schema mappings) then describe how to write QoS policy rules that can be used to store information in directories to configure device QoS mechanisms. The approach taken in this draft defines a common set of attributes that can be used to model Differentiated Services QoS. (Integrated Services will be modeled in a separate draft.) Vendors can then map these attributes, either directly or using an intervening format like a COP-PR PIB, to their own device- specific implementations. Strassner, et al. Expires: Nov 2000 + 6 months [Page 5] Internet Draft QoS Device Info Model November 2000 This draft explicitly separates the concepts of configuration and state. Configuration attributes are used to describe the desired state of a device, whereas state attributes reflect the current operation of the device. Both state and configuration attributes are necessary in order to model and manage QoS at the device level. Although configuration is discussed, this draft only models state attributes at this time. Configuration attributes will be added in a future version of the draft. The design of the class and relationship hierarchies described in this draft is influenced by the DMTF Network QoS submodel [CIM]. These hierarchies are not derived from the Policy Core Information Model [PCIM]. This is because the modeling of the QoS mechanisms of a device is separate and distinct from the modeling of policies that manage those mechanisms. Hence, there is a need to separate QoS mechanisms (this draft) from their control (specified using the generic policy draft [PCIM] augmented by the QoS Policy draft [QOSPIM]). 1.1. Policy Management Conceptual Model The [PCIM] describes a general methodology for constructing policy rules. A policy rule aggregates a set of policy conditions and a set of policy actions. The semantics of a policy rule are such that if the set of conditions evaluates to TRUE, then the set of actions are executed. Policy conditions and actions have two principal components: operands and operators. Operands can be constants or variables. To specify a policy, it is necessary to specify: o the operands to be examined (also known as state variables); o the operands to be changed (also known as configuration variables); o the relationships between these two sets of operands. Operands can be specified at a high-level, such as Joe (a user) or Gold (a service). Operands can also be specified at a much finer level of detail, one that is much closer to the operation of the device. Examples of the latter include an IP Address or a queue's bandwidth allocation. Implicit in the use of operands is the binding of legal values or ranges of values to an operand. For example, the value of an IP address cannot be an integer. The concepts of operands and their ranges are defined in [QOSPIM]. The second component of policy conditions and actions is a set of operators. Operators can express both relationships (greater than, member of a set, Boolean OR, etc.) and assignments. Together, operators and operands can express a variety of conditions and actions, such as: Strassner, et al. Expires: Nov 2000 + 6 months [Page 6] Internet Draft QoS Device Info Model November 2000 If Bob is an Engineer... If the source IP address is in the Marketing Subnet... Set Joe's IP address to 2.3.4.5 Limit the bandwidth of application x to 10 Mb We recognize that the definition of operator semantics is critical to the definition of policies. However, the definition of these operators is beyond the scope of this document. Rather, this draft (with [QOSPIM]) takes the first steps in identifying and standardizing a set of properties (operands) for use in defining policies for Differentiated Services. 1.2. Purpose and Relation to Other Policy Work This model establishes a canonical model of the QoS mechanisms of a network device (e.g., a router, switch, or host) that is independent of any specific type of network device. This enables traffic conditioning to be described using a common set of abstractions, modeled as a set of services and sub-services. When the concepts of this draft are used in conjunction with the concepts of [QOSPIM], then one is able to define policies that bind the services in a network to the needs of applications using that network. In other words, the business requirements of an organization can be reflected in one set of policies, and those policies can be translated to a lower-level set of policies that control and manage the configuration and operation of network devices. 1.3. Typical Examples of Policy Usage Policies could be implemented as low-level rules using the information model described in this specification. For example, in a low-level policy, a condition could be represented as an evaluation of a specific attribute from this model. Therefore, a condition such as "If filter = HTTP" would be interpreted as a test determining whether any HTTP filters have been defined for the device. A high-level policy, such as "If protocol = HTTP, then mark with DSCP 24," would be expressed as a series of actions in a low-level policy using the classes and attributes described below: 1. Create HTTP filter 2. Create DSCP marker with the value of 24 3. Bind the HTTP filter to the DSCP marker Note that unlike "mark with DSCP 24," these low-level actions are not performed on a packet as it passes through the device. Rather, they are configuration actions performed on the device itself, to make it ready to perform the correct action(s) on the correct packet(s). The act of moving from a high-level policy rule to the correct set of low-level device configuration actions Strassner, et al. Expires: Nov 2000 + 6 months [Page 7] Internet Draft QoS Device Info Model November 2000 is an example of what [POLTERM] characterizes as "policy translation" or "policy conversion". 2. Approach QoS activities in the IETF have mainly focused in two areas, Integrated Services (IntServ) and Differentiated Services (DiffServ) (see [POLTERM], [R1633] and [R2475]). This draft focuses on the specification of QoS attributes and classes for Differentiated Services. However, the framework defined by the structure of the classes defined in this document has been designed with the needs of IntServ as well as DiffServ in mind. 2.1. Common Needs Of DiffServ and IntServ First, let us consider IntServ. IntServ has two principal components. One component is embedded in the forwarding engine of the networking device. Its functions include the classification and policing of individual flows, and scheduling admitted packets for the outbound link. The other component of IntServ is the management of the signaling protocol (e.g., the PATH and RESV messages of RSVP). This component processes reservation requests, manages bandwidth, outsources decision making to policy servers, and interacts with the Routing Table manager. We will consider RSVP when defining the structure of this information model. As this draft initially focuses on the forwarding engine, elements of RSVP applicable to the forwarding engine will be considered in the structure of the classes. The complete IntServ device model will, as we have indicated earlier, be addressed in a subsequent document. This draft models a small subset of the QoS policy problem, in hopes of constructing a methodology that can be adapted for other aspects of QoS in particular, and of policy construction in general. The focus in this draft is on QoS for devices that implement DiffServ. DiffServ operates exclusively in the forwarding engine. It has all of the same components of the IntServ forwarding engine with two major differences. First, DiffServ classifies packets based solely on their DSCP field, whereas IntServ examines a subset of a standard flow's addressing 5-tuple. The exception to this rule occurs in a router or host at the boundary of a DiffServ domain. A device in this position may examine a packet's DSCP, its addressing 5-tuple, other fields in the packet, or even information wholly outside the packet, in determining the DSCP value with which to mark the packet prior to its transfer into the DiffServ domain. However, routers in the interior of a DiffServ domain will only need to classify based on the DSCP field. Strassner, et al. Expires: Nov 2000 + 6 months [Page 8] Internet Draft QoS Device Info Model November 2000 The second difference between IntServ and DiffServ is that the signaling protocol used in IntServ (e.g., RSVP) affects the forwarding engine in a more dynamic fashion. This is because each newly admitted RSVP reservation requires a reconfiguration of the forwarding engine. In contrast, DiffServ requires far fewer changes to the forwarding engine after the Per-Hop Behaviors (PHBs) have been configured. The approach advocated in this draft for the creation of policies that control the various QoS mechanisms of networking devices is to first identify the attributes with which policies are to be constructed. These attributes are the parameters used in expressions that are necessary to construct policies. There is also a parallel desire to define the operators, relations, and precedence constructs necessary to construct the conditions and actions that constitute these policies. However, these efforts are beyond the scope of this document. 2.2. Specific Needs Of DiffServ DiffServ-specific rules focus on two particular areas: the core and the edges of the network. As explained in the DiffServ Architecture document [R2475], devices at the edge of the network classify traffic into different traffic streams. The core of the network then forwards traffic from different streams by using a set of Per-Hop Behaviors (PHBs). A DiffServ Code Point (DSCP) identifies each PHB. The DSCP is part of the IP header of each packet (as described in [R2474]). This enables multiple traffic streams to be aggregated into a small number of aggregated traffic streams, where each aggregate traffic stream is identified by a particular DSCP, and forwarded using a particular PHB. The attributes used to manipulate QoS capabilities in the core of the network primarily address the behavioral characteristics of each supported PHB. At the edges of the DiffServ network, the additional complexities of flow classification, policing, RSVP mappings, remarkings, and other factors have to be considered. Additional modeling will be required in this area. However, first, the standards for edges of the DiffServ network need more detail - to allow the edges to be incorporated into the policy model. 2.3. Specific Needs Of IntServ This document focuses exclusively on the forwarding aspects of network QoS. Therefore, while the forwarding aspects of IntServ are considered, the management of IntServ is not considered. This topic will be addressed in a future draft. Strassner, et al. Expires: Nov 2000 + 6 months [Page 9] Internet Draft QoS Device Info Model November 2000 3. Methodology There is a clear need to define attributes and behavior that together define how traffic should be conditioned. This draft defines a set of classes and relationships that represent the QoS mechanisms used to condition traffic; [QOSPIM] is used to define policies to control the QoS mechanisms defined in this draft. However, some very basic issues need to be considered when combining these drafts. Considering these issues should help in constructing a schema for managing the operation and configuration of network QoS mechanisms through the use of QoS policies. 3.1. Level of Abstraction for Expressing QoS Policies The first issue requiring consideration is the level of abstraction at which QoS policies should be expressed. If we consider policies as a set of rules used to react to events and manipulate attributes or generate new events, we realize that policy represents a continuum of specifications that relate business goals and rules to the conditioning of traffic done by a device or a set of devices. An example of a business level policy might be: from 1:00 pm PST to 7:00 am EST, sell off 40% of the network capacity on the open market. In contrast, a device- specific policy might be: if the queue depth grows at a geometric rate over a specified duration, trigger a potential link failure event. A general model for this continuum is shown in Figure 1 below. +---------------------+ | High-Level Business | Not directly related to device | Policies | operation and configuration details +---------------------+ | | +---------V-----------+ | Device-Independent | Translate high-level policies to | Policies | generic device operational and +---------------------+ configuration information | | +---------V-----------+ | Device-Dependent | Translate generic device information | Policies | to specify how particular devices +---------------------+ should operate and be configured Figure 1. The Policy Continuum High-level business policies are used to express the requirements of the different applications, and prioritize which applications get "better" treatment when the network is congested. The goal, Strassner, et al. Expires: Nov 2000 + 6 months [Page 10] Internet Draft QoS Device Info Model November 2000 then, is to use policies to relate the operational and configuration needs of a device directly to the business rules that the network administrator is trying to implement in the network that the device belongs to. Device-independent policies translate business policies into a set of generalized operational and configuration policies that are independent of any specific device, but dependent on a particular set of QoS mechanisms, such as RED dropping or weighted round robin scheduling. Not only does this enable different types of devices (i.e., routers, switches, firewalls, and hosts) to be controlled by QoS policies, it also enables devices made by different vendors that use the same types of QoS mechanisms to be controlled. This enables these different devices to each supply the correct relative conditioning to the same type of traffic. In contrast, device-dependent policies translate device- independent policies into ones that are specific for a given device. The reason that a distinction is made between device- independent and device-dependent policies is that in a given network, many different devices having many different capabilities need to be controlled together. Device-independent policies provide a common layer of abstraction for managing multiple devices of different capabilities, while device- dependent policies implement the specific conditioning that is required. This draft provides a common set of abstractions for representing QoS mechanisms in a device-independent way. This draft is focused on the device-independent representation of QoS mechanisms. QoS mechanisms are modeled in sufficient detail to provide a common device-independent representation of QoS policies. They can also be used to provide a basis for specialization, enabling each vendor to derive a set of vendor- specific classes that represent how traffic conditioning is done for that vendor's set of devices. 3.2. Specifying Policy Parameters Policies are a function of parameters (attributes) and operators (boolean, arithmetic, relational, etc.). Therefore, both need to be defined as part of the same policy in order to correctly condition the traffic. If the parameters of the policy are specified too narrowly, they will reflect the individual implementations of QoS in each device. As there is currently little consensus in the industry on what the correct implementation model for QoS is, most defined attributes would only be applicable to the unique characteristics of a few individual devices. Moreover, standardizing all of these potential implementation alternatives would be a never-ending task as new implementations continued to appear on the market. Strassner, et al. Expires: Nov 2000 + 6 months [Page 11] Internet Draft QoS Device Info Model November 2000 On the other hand, if the parameters of the policy are specified too broadly, it is impossible to develop meaningful policies. For example, if we concentrate on the so-called Olympic set of policies, a business policy like "Bob gets Gold Service," is clearly meaningless to the large majority of existing devices. This is because the device has no way of determining who Bob is, or what QoS mechanisms should be configured in what way to provide Gold service. Furthermore, Gold service may represent a single service, or it may identify a set of services that are related to each other. In the latter case, these services may have different conditioning characteristics. This draft defines a set of parameters that fit into a canonical model for modeling the elements in the forwarding path of a device implementing DiffServ. By defining this model in a device-independent way, the needed parameters can be appropriately abstracted. 3.3. Specifying Policy Services Administrators want the flexibility to be able to define traffic conditioning without having to have a low-level understanding of the different QoS mechanisms that implement that conditioning. Furthermore, administrators want the flexibility to group different services together, so that one group of services as a whole will receive "better" treatment than another group of services. These two goals dictate the need for the following set of abstractions: o a flexible way to describe a service o must be able to group different services that may use different technologies (e.g., DiffServ and 802.1P) together o must be able to define a set of sub-services that together make up a higher-level service o must be able to associate a service and the set of QoS mechanisms that are used to condition traffic for that service o must be able to define policies that manage the QoS mechanisms used to implement a service. This draft addresses this set of problems by defining a set of classes and relationships that can represent abstract concepts like "Gold Service," and bind each of these abstract services to a specific set of QoS mechanisms that implement the conditioning Strassner, et al. Expires: Nov 2000 + 6 months [Page 12] Internet Draft QoS Device Info Model November 2000 that they require. Furthermore, this draft defines the concept of "sub-services," to enable Gold Service to be defined either as a single service or as a set of services that together should be treated as an atomic entity. Given these abstractions, policies (as defined in [QOSPIM]) can be written to control the QoS mechanisms and services defined in this draft. 3.4. Level of Abstraction for Defining QoS Attributes and Classes This draft defines a set of classes and attributes to support policies that configure device QoS mechanisms. This draft concentrates on the representation of DiffServ services. A future draft will define classes and attributes for IntServ services. The classes and attributes in this draft are designed to be used in conjunction with the QoS policy classes and attributes defined in [QOSPIM]. For example, to preserve the delay characteristics committed to an end-user, a network administrator may wish to create policies that monitor the queue depths in a device, and adjust resource allocations when delay budgets are at risk (perhaps as a result of a network topology change). The classes and attributes in this document define the specific services and mechanisms required to implement those services. The classes and attributes defined in [QOSPIM] provide the overall structure of the policy that manages and configures this service. This combination of low-level specification (using this draft) and high-level structuring (using [QOSPIM]) of network services enables network administrators to define new services required of the network, that are directly related to business goals, while ensuring that such services can be managed. However, this goal (of creating and managing service-oriented policies) can only be realized if policies can be constructed that are capable of supporting diverse implementations of QoS. The solution is to model the QoS capabilities of devices at the behavioral level. This means that for DiffServ, the model must support the following characteristics: o modeling of a generic network service that has QoS capabilities o modeling of how DiffServ traffic conditioning is defined o modeling of how statistics are gathered to monitor DiffServ (and other types of QoS) services This draft models a network service, and associates it with one or more QoS mechanisms that are used to implement that service. It also models in a canonical form the various components that Strassner, et al. Expires: Nov 2000 + 6 months [Page 13] Internet Draft QoS Device Info Model November 2000 are used to condition DiffServ traffic, such that standard as well as custom DiffServ services may be described. Statistics will be added in the next release of this draft. 3.5. Characterization of QoS Attributes The QoS attributes and classes will be described in more detail in section 4. However, we should consider the basic characteristics of these attributes, to understand the methodology for representing them. There are essentially two types of attributes, state and configuration. Configuration attributes describe the desired state of a device, and include attributes and classes for representing desired or proposed thresholds, bandwidth allocations, and how to classify traffic. State attributes describe the actual state of the device. These include attributes to represent the current ACTUAL values of the quantities in devices configured via the configuration attributes, as well as attributes that represent dynamic state (queue depths, excess capacity consumption, loss rates, and so forth). In order for them to be used together, these two types of attributes must be modeled using a common information model. This draft makes explicit the common information model for modeling state as well as configuration attributes for DiffServ QoS mechanisms. In addition, it emphasizes the need to separate these two types of attributes. One should note that the state attributes defined in this draft are purposely device-independent. In contrast, configuration attributes that will be defined in a future release of this draft can be represented and applied to either the same set of devices or to a specific device. Examples of the former are setting one or more attributes in all devices in the same domain that share the same AS (autonomous system) number, or in all core devices that share the same delay bound for a specific service. Examples of the latter are setting a specific set of attributes that configures how a device-specific implementation of a conditioning mechanism will operate. This difference between state and configuration attributes suggests that the schema for configuration attributes will not be exactly the same as the schema that supports state attributes. However, many of the attributes defined in this draft represent exactly the quantities that will be configured by the configuration attributes. Thus, the definition of these state and configuration attributes provides the link between modeling the operational state of a device and setting configuration parameters of that device. The intersection of these two schemata will be through the set of attributes, associations, and aggregations that relate one schema to the other. Strassner, et al. Expires: Nov 2000 + 6 months [Page 14] Internet Draft QoS Device Info Model November 2000 3.6. QoS Information Model Derivation The question of context also leads to another question: how does the information specified in the core and QoS policy models ([PCIM] and [QOSPIM], respectively) integrate with the information defined in this draft? Put another way, where should device-independent concepts that lead to device-specific QoS attributes be derived from? Past thinking was that QoS was part of the policy model. This view is not completely accurate, and it leads to confusion. QoS is a set of services that can be controlled using policy. These services are represented as device mechanisms. An important point here is that QoS services, as well as other types of services (e.g., security), are provided by the mechanisms inherent in a given device. This means that not all devices are indeed created equal. For example, although two devices may have the same type of mechanism (e.g., a queue), one may be a simple implementation (i.e., a FIFO queue) whereas one may be much more complex and robust (i.e., CBWFQ). However, both of these devices can be used to deliver QoS services, and both need to be controlled by policy. Thus, a device-independent policy can instruct the devices to queue certain traffic, and a device- specific policy can be used to control the queuing in each device. Furthermore, policy is used to control these mechanisms, not to represent them. For example, QoS services are implemented with classifiers, meters, markers, droppers, queues, and schedulers. Similarly, security is also a characteristic of devices, as authentication and encryption capabilities represent services that networked devices perform (irrespective of interactions with policy servers). These security services may use some of the same mechanisms that are used by QoS services, such as the concepts of filters. However, they will mostly require different mechanisms than the ones used by QoS, even though both sets of services are implemented in the same devices. Thus, the similarity between the QoS model and models for other services is not so much that they contain a few common mechanisms. Rather, they model how a device implements their respective services. As such, the modeling of QoS should be part of a networking device schema rather than a policy schema. This allows the networking device schema to concentrate on modeling device mechanisms, and the policy schema to focus on the semantics of representing the policy itself (conditions, actions, operators, etc.). While this iteration of this draft concentrates on defining an information model to represent DiffServ QoS services, the ultimate goal is to be able to apply policies that control these services in network devices. Furthermore, these two schemata (device and policy) must be tightly integrated in order to enable policy to control QoS services. Strassner, et al. Expires: Nov 2000 + 6 months [Page 15] Internet Draft QoS Device Info Model November 2000 3.7. Attribute Representation The last issue to be considered is the question of how attributes are represented. If QoS attributes are represented as absolute numbers (e.g., Class AF2 gets 2 Mbs of bandwidth), it is more difficult to make them uniform across multiple ports in a device or across multiple devices, because of the broad variation in link capacities. However, expressing attributes in relative or proportional terms (e.g., Class AF2 gets 5% of the total link bandwidth) makes it more difficult to express certain types of conditions and actions, such as: (If ConsumedBandwidth = AssignedBandwidth Then ...) There are really three approaches to addressing this problem: o Multiple attributes can be defined to express the same value in various forms. This idea has been rejected because of the difficulty in keeping these different attributes synchronized (e.g., when one attribute changes, the others all have to be updated). o Multi-modal attributes can be defined to express the same value, in different terms, based on the access or assignment mode. This option was rejected because it significantly complicates the model and is impossible to express in current directory access protocols (e.g., (L)DAP). o Attributes can be expressed as "absolutes", but the operators in the policy schema would need to be more sophisticated. Thus, to represent a percentage, division and multiplication operators are required (e.g., Class AF2 gets .05 * the total link bandwidth). This is the approach that has been taken in this draft. 3.8. Mental Model The mental model for constructing this schema is based on the work done in the Differentiated Services working group. This schema is based on information provided in the current versions of the DiffServ Conceptual Model [DSMODEL], the DiffServ MIB [DSMIB], the PIB [PIB], as well as on information in the set of RFCs that constitute the basic definition of DiffServ itself ([R2475], [R2474], [R2597], and [R2598]). In addition, a common set of terminology is available in [POLTERM]. Note that this work is not yet completely aligned, as there are differences among the DiffServ Conceptual Model, the DiffServ MIB, the DiffServ PIB, and this draft. Work to finish aligning these drafts is in progress, and will be reflected in the next revision of this draft. Strassner, et al. Expires: Nov 2000 + 6 months [Page 16] Internet Draft QoS Device Info Model November 2000 This model is built around two fundamental class hierarchies that are bound together using a set of relationships. The two class hierarchies derive from the QoSService and ConditioningService base classes. A set of associations relate lower-level QoSService subclasses to higher-level QoSServices, relate different types of ConditioningServices together in processing a traffic class, and relate a set of ConditioningServices to a specific QoSService. This combination of relationships enables us to view the device as providing a set of services that can be configured, in a modular building block fashion, to construct application-specific services. Thus, this document can be used to model existing and future standard as well as application-specific network QoS services. 3.8.1. The QoSService Class The first of the classes defined here, QoSService, is used to represent higher-level network services that require special conditioning of their traffic. QoSService has a set of subclasses that represent technology-specific implementations of QoS (e.g., DiffServ and 802.1P), as well as a relationship to the second fundamental class, ConditioningService. The subclasses of QoSService typically model a set of coordinated, cooperating sub- services. The QoS services can be related to each other as peers, or they can be implemented as subservient services to each other. This enables us to define Gold Service as (for example) a combination of the EF PHB to implement a voice service and a set of AF PHBs to condition data traffic. Furthermore, it lets us think of AF as a service that requires different sub-services (e.g., a classification service, a dropping service, etc.) to implement it. These sub-services derive from the ConditioningService class, and are related to the QoSService class via the aggregation QoSConditioningSubService (see section 4 for class and relationship definitions). This document, in its current form, identifies three subclasses of QoSService: DiffServ, 802.1P, and Precedence. The purpose of these subclasses is to enable administrators to manage the application of QoS according to the specific technologies that they are using. Thus, a network consisting of a set of DiffServ- and non-DiffServ-compliant devices that each provided QoS traffic conditioning would be modeled using different subclasses of QoSService. However, the mechanisms can be inter-related, since they all derive from a common base class, QoSService. These concepts are depicted in Figure 2. Note that both of the associations are aggregations: a QoSService aggregates both the set of QoSServices subservient to it, and the set of ConditioningServices that realize it. Strassner, et al. Expires: Nov 2000 + 6 months [Page 17] Internet Draft QoS Device Info Model November 2000 /\______ 0..1 \/ | +--------------+ | QoSSubService +---------------+ | |0..n | | | | QoSService |----- | Conditioning | | | | Service | | | | | | |0..1 0..n| | | | /\______________________| | | | \/ QoSConditioning | | +--------------+ SubService +---------------+ Figure 2. QoSService and its Aggregations 3.8.2. The ConditioningService Class The goal of the ConditioningService classes is to describe the sequence of traffic conditioning that is applied to a given traffic stream on the ingress interface through which it enters a device, and then on the egress interface through which it leaves the device. This is done using a set of classes and relationships. The routing decision in the device core, which selects which egress interface a particular packet will use, is not represented in this model. A single base class, ConditioningService, is the superclass for a set of subclasses representing the mechanisms that condition traffic. These subclasses define device-independent conditioning primitives (including classifiers, meters, markers, droppers, queues, and schedulers) that together implement the conditioning of traffic on an interface. This model abstracts these services into a common set of modular building blocks that can be used, regardless of device implementation, to model the traffic conditioning internal to a device. The different conditioning mechanisms need to be related to each other to describe how traffic is conditioned. Several important variations of how these services are related together exist: o A particular ingress or egress interface may not require all the types of ConditioningServices. o Multiple instances of the same mechanism may be required on an ingress or egress interface. o There is no set order of application for the ConditioningServices on an ingress or egress interface. Therefore, this model does not dictate a fixed ordering among the subclasses of ConditioningService, or identify a subclass of ConditioningService that must appear first or last among the ConditioningServices on an ingress or egress interface. Instead, Strassner, et al. Expires: Nov 2000 + 6 months [Page 18] Internet Draft QoS Device Info Model November 2000 this model ties together the various ConditioningService instances on an ingress or egress interface using the NextService, NextServiceAfterMeter, and NextServiceAfterConditioningElement associations (see Section 4). There is also a separate association, called ConditioningServiceOnEndpoint (see section 4), with subclasses that tie an ingress interface to its first ConditioningService, and tie an egress interface to its last ConditioningService. 3.8.3. QoS Statistics Classes Various statistics classes were proposed in an earlier iteration of this draft. Such statistics are necessary to properly instrument QoS services. However, since the core of the draft has been reworked, the previous statistics classes are no longer aligned with the rest of the document. Consequently, they have been removed. The next iteration of this draft will add these classes back into the draft. 3.9. Classifiers, FilterLists, and FilterEntries This draft uses a number of classes to model the classifiers defined in [DSMODEL]: ClassifierService, ClassifierElement, FilterList, FilterEntry, and various subclasses of FilterEntry. There are also two associations involved: ClassifierElementUsesFilterList and EntriesInFilterList. (The association ClassifierFilterSet, which is available in the CIM model for representing other types of classifiers, is not used in the representation of DiffServ classifiers.) The FilterList and FilterEntry classes, and the EntriesInFilterList association that relates them, are used in other models such as BGP and IPsec, as well as in the QoS device model specified in this draft. Because they are used in other models, the FilterList and FilterEntry classes contain elements that are not needed in the QoS device model. This section identifies the unused elements from these two classes, while also providing a summary of how all of the classes are used to model a DiffServ classifier. In [DSMODEL], a single traffic stream coming into a classifier is split into multiple traffic streams leaving it, based on which of an ordered set of filters each packet in the incoming stream matches. A filter matches either a field in the packet itself, or possibly "other attributes associated with the packet." In the case of a multi-field (MF) classifier, packets are assigned to output streams based on the contents of multiple fields in the packet header. For example, an MF classifier might assign packets to an output stream based on their complete IP-addressing 5-tuple. The FilterEntry class models the process of matching a single field in a packet (or a single attribute associated with a packet) against a specified value. Consequently, it takes multiple FilterEntries to model a selector in an MF classifier. Strassner, et al. Expires: Nov 2000 + 6 months [Page 19] Internet Draft QoS Device Info Model November 2000 These FilterEntries are combined into a FilterList, using the EntriesInFilterList aggregation. EntriesInFilterList has a property EntrySequence, which ordinarily imposes an evaluation order on the FilterEntries in a FilterList. In the case of a selector for an MF classifier, however, the EntrySequence property takes its default value: '0'. This value indicates that the FilterEntries are ANDed together to determine whether a packet matches the MF selector that the FilterList represents. To optimize the representation of MF classifiers, subclasses of FilterEntry are introduced, which allow multiple related packet header fields to be represented in a single object. These subclasses are IP6TupleFilter, 8021Filter, and 8021PQFilter. With IP6TupleFilter, for example, a test that selects packets based on all 6 of the IP 6-tuple header fields can be represented by a FilterList containing one IP6TupleFilter object, as opposed to a FilterList containing six FilterEntry objects. The FilterList object is always needed, even if it contains only one FilterEntry (or one FilterEntry subclass) object. This is because it is the ClassifierElementUsesFilterList association that ties a filter back to the classifier in which it is used. 4. The Class Hierarchy The following sections present the class and association hierarchies that together comprise the information model for modeling QoS capabilities at the device level. 4.1. Associations An association is a means of representing a dependency relationship between two (or theoretically more) objects. In CIM and DEN, this type of relationship is modeled as a class containing two (or more) object references. Since the association is itself a class, it can benefit from all of the object-oriented features that other non-association classes have. For example, it can contain properties and methods, and inheritance can be used to refine its semantics such that it represents a more specialized type of dependency. It is important to note that associations form an inheritance hierarchy that is separate from the class inheritance hierarchy. Although associations are typically bi-directional, there is nothing that prevents higher order associations from being defined. However, such associations are inherently more complex to define, understand, and use. In practice, associations of orders higher than binary are rarely used, because of their greatly increased complexity and lack of generality. All of the associations defined in this model are binary. Strassner, et al. Expires: Nov 2000 + 6 months [Page 20] Internet Draft QoS Device Info Model November 2000 Finally, note that associations that are defined between two classes do not affect the classes themselves. That is, the addition or deletion of an association does not affect the interfaces of the classes that it is connecting. 4.2. Aggregations An aggregation is a strong form of an association, which usually represents a "whole-part" or a "collection" relationship. For example, CIM uses an aggregation to represent the containment relationship between a system and the components that make it up. In this draft, all aggregations represent "whole-part" relationships. Note that an aggregate object is treated as an atomic unit, even though it is comprised of, or collects, multiple objects. This is a defining feature of an aggregation - although the individual components that make up an aggregate object have their own identities, the aggregate object that is constructed from these objects has its own identity and name as well. "Whole-part" aggregations have some very interesting properties: o cascaded deletion (if you delete the aggregate, you delete all of its constituent components) o transitivity (e.g., if Object A is-a-part-of Object B, and if Object B is-a-part-of Object C, then Object A is- a-part-of Object C) o anti-symmetry (e.g., if Object A is-a-part-of Object B, then Object B cannot also be a-part-of Object A) Aggregation is used to represent the physical and/or logical grouping of related objects. 4.3. The Structure of the Class Hierarchies The following sections discuss the class hierarchies used to model the state of QoS devices and services. A later release will include configuration hierarchies. This model has been influenced by [CIM], and is compatible with the Directory Enabled Networks (DEN) effort. 4.3.1. The Class Hierarchies for Modeling State Information The structure of the class, association, and aggregation class inheritance hierarchies for managing the state of Differentiated Services devices is shown, respectively, in Figure 3, Figure 4, and Figure 5. The following notation is used in these figures: o (CIMCORE) identifies a class defined in the CIM Core Model. Strassner, et al. Expires: Nov 2000 + 6 months [Page 21] Internet Draft QoS Device Info Model November 2000 o (CIMNET) identifies a class defined in the CIM Network Model. Note that the CIM Network model currently has a number of Change Requests (CRs) open, which seek to better align it with the model in this draft. The (CIMNET) notation indicates an element that is either in the CIM Network Model now, or is an addition to the model proposed in one of these CRs. Please refer to [CIM] for the definitions of the classes in (CIMCORE) and (CIMNET). Strassner, et al. Expires: Nov 2000 + 6 months [Page 22] Internet Draft QoS Device Info Model November 2000 +--ManagedElement (CIMCORE) | +--ManagedSystemElement (CIMCORE) | | | +--LogicalElement (CIMCORE) | | | | | +--Service (CIMCORE) | | | | | | | +--NetworkService (CIMNET) | | | | | | | | | +--ForwardingService (CIMNET) | | | | | | | | | | | +--ConditioningService (CIMNET) | | | | | | | | | | | +--ClassifierService (CIMNET) | | | | | | | | | | | | | +--ClassifierElement | | | | | | | | | | | +--MeterService (CIMNET) | | | | | | | | | | | | | +--AverageRateMeterService (CIMNET) | | | | | | | | | | | | | +--EWMAMeterService (CIMNET) | | | | | | | | | | | | | +--TokenBucketMeterService (CIMNET) | | | | | | | | | | | +--MarkerService (CIMNET) | | | | | | | | | | | | | +--TOSMarkerService (CIMNET) | | | | | | | | | | | | | +--DSCPMarkerService (CIMNET) | | | | | | | | | | | | | +--8021PMarkerService (CIMNET) | | | | | | | | | | | +--DropperService (CIMNET) | | | | | | | | | | | | | +--HeadTailDropperService (CIMNET) | | | | | | | | | | | | | +--RedDropperService (CIMNET) | | | | | | | | | | | +--QueuingService (CIMNET) | | | | | | | | | | | +--PacketSchedulingService (CIMNET) (continued on following page) Strassner, et al. Expires: Nov 2000 + 6 months [Page 23] Internet Draft QoS Device Info Model November 2000 (continued from previous page; the first five elements are repeated for convenience) +--ManagedElement (CIMCORE) | +--ManagedSystemElement (CIMCORE) | | | +--LogicalElement (CIMCORE) | | | +--Service (CIMCORE) | | | | | +--NetworkService (CIMNET) | | | | | | | +--QoSService (CIMNET) | | | | | | | +--DiffServService (CIMNET) | | | | | | | | | +--AFService (CIMNET) | | | | | | | | | +--EFService (CIMNET) | | | | | | | +--PrecedenceService (CIMNET) | | | | | | | +--8021PService (CIMNET) | | | | | +--DropThresholdCalculationService (CIMNET) | | | +--FilterEntryBase (CIMNET) | | | | | +--FilterEntry (CIMNET) | | | | | +--IP6TupleFilter | | | | | +--8021Filter | | | | | +--8021PQFilter | | | +--FilterList (CIMNET) | | | +--ServiceAccessPoint (CIMCORE) | | | +--ProtocolEndpoint (CIMNET) | +--Collection (CIMCORE) | +--CollectionOfMSEs (CIMCORE) | +--BufferPool (CIMNET) Figure 3. Class Inheritance Hierarchy Strassner, et al. Expires: Nov 2000 + 6 months [Page 24] Internet Draft QoS Device Info Model November 2000 The inheritance hierarchy for the associations defined in this draft is shown in Figure 4. +--Dependency (CIMCORE) | | | +--ServiceSAPDependency (CIMCORE) | | | | | +--ForwardsAmong (CIMNET) | | | | | +--ConditioningServiceOnEndpoint (CIMNET) | | | | | +--IngressConditioningServiceOnEndpoint | | | | | +--EgressConditioningServiceOnEndpoint | | | +--HeadTailDropQueueBinding (CIMNET) | | | +--CalculationBasedOnQueue (CIMNET) | | | +--ProvidesServiceToElement (CIMCORE) | | | | | +--ServiceServiceDependency (CIMCORE) | | | | | +--QueueHierarchy (CIMNET) | | | | | +--CalculationServiceForDropper (CIMNET) | | | +--QueueAllocation (CIMNET) | | | +--ClassifierFilterSet (CIMNET) | | | +--ClassifierElementUsesFilterList | +--AFRelatedServices (CIMNET) | +--NextService (CIMNET) | +--NextServiceAfterMeter (CIMNET) | +--NextServiceAfterClassifierElement | +--SchedulerUsed (CIMNET) | +--PrioritySchedulerUsed (CIMNET) | | | +--BoundedPrioritySchedulerUsed (CIMNET) | +--BandwidthSchedulerUsed (CIMNET) | +--WRRSchedulerUsed (CIMNET) Figure 4. Association Class Inheritance Hierarchy Strassner, et al. Expires: Nov 2000 + 6 months [Page 25] Internet Draft QoS Device Info Model November 2000 The inheritance hierarchy for the aggregations defined in this draft is shown in Figure 5. +--MemberOfCollection (CIMCORE) | | | +--CollectedBufferPool (CIMNET) | +--Component (CIMCORE) | +--ServiceComponent (CIMCORE) | | | +--QoSSubService (CIMNET) | | | +--QoSConditioningSubService (CIMNET) | | | +--ClassifierElementInClassifierService | +--EntriesInFilterList (CIMNET) Figure 5. Aggregation Class Inheritance Hierarchy 4.3.2. The Class Hierarchies for Modeling Configuration Information The structure of the class and association class hierarchies for managing the configuration of Differentiated Services will be presented in the next iteration of this draft. These hierarchies are being held back now because the hierarchies for representing state information that are included here have undergone significant changes to reflect participant feedback. Once the state hierarchies have stabilized, the configuration hierarchies can be added back in. 4.4. Class Definitions for the State Portion of the Model This section presents the classes and attributes that make up the Information Model for describing QoS-related functionality in network devices, including hosts. These definitions are derived from definitions in the CIM Core and Network Models [CIM]. Only the QoS-related classes will be defined in this draft. However, other classes drawn from the CIM Core and Network Models will be described briefly. The reader is encouraged to look at [CIM] for further information. Associations and aggregations will be defined in Section 4.5. 4.4.1. The Abstract Class ManagedElement This is an abstract class defined in the Core Model of CIM. It is the root of the entire class inheritance hierarchy in CIM. Among the associations that refer to it are two that are subclassed in this document: Dependency and MemberOfCollection, which is an aggregation. ManagedElement's properties are Caption and Description. Both are free-form strings to describe an Strassner, et al. Expires: Nov 2000 + 6 months [Page 26] Internet Draft QoS Device Info Model November 2000 instantiated object. Please refer to [CIM] for the full definition of this class. 4.4.2. The Abstract Class ManagedSystemElement This is an abstract class defined in the Core Model of CIM; it is a subclass of ManagedElement. ManagedSystemElement serves as the base class for the PhysicalElement and LogicalElement class hierarchies. LogicalElement, in turn, is the base class for a number of important CIM hierarchies, including System. Any distinguishable component of a System is a candidate for inclusion in this class hierarchy, including physical components (e.g., chips and cards) and logical components (e.g., software components, services, and other objects). None of the associations in which this class participates is used directly in the QoS device state model. However, the aggregation Component, which relates one ManagedSystemElement to another, is the base class for the two aggregations that form the core of the QoS device state model: QoSSubService and QoSConditioningSubService. Similarly, the association ProvidesServiceToElement, which relates a ManagedSystemElement to a Service, is the base class for the model's QueueHierarchy and CalculationServiceForDropper associations. Please refer to [CIM] for the full definition of this class. 4.4.3. The Abstract Class LogicalElement This is an abstract class defined in the Core Model of CIM. It is a subclass of the ManagedSystemElement class, and is the base class for all logical components of a managed System, such as Files, Processes, or system capabilities in the form of Logical Devices and Services. None of the associations in which this class participates is relevant to the QoS device state model. Please refer to [CIM] for the full definition of this class. 4.4.4. The Abstract Class Service This is an abstract class defined in the Core Model of CIM. It is a subclass of the LogicalElement class, and is the base class for all objects that represent a "service" or functionality in a System. A Service is a general-purpose object that is used to configure and manage the implementation of functionality. As noted above in section 4.4.2, this class participates in the ProvidesServiceToElement association. Please refer to [CIM] for the full definition of this class. 4.4.5. The Abstract Class NetworkService This is an abstract class defined in the Network Model of CIM. It is a subclass of the Service class, and serves as the base class rooting the network service hierarchy. Network services Strassner, et al. Expires: Nov 2000 + 6 months [Page 27] Internet Draft QoS Device Info Model November 2000 represent generic functions that are available from the network, and that condition and/or modify one or more parameters of the traffic being sent, such as fields in a packet's header. Note that the network services discussed here are provided by a network's hosts, as well as by its network devices; for example, a host might provide classification and conditioning of packets on its egress interfaces. None of the associations in which this class participates is used in the QoS device state model. Please refer to [CIM] for the full definition of this class. 4.4.6. The Class ForwardingService This is a concrete class defined in the Network Model of CIM. It is a subclass of the NetworkService class, and represents the forwarding of network traffic by receiving data from one or more communication sources, and either discarding it or sending it via other communication sources. The properties of ForwardingService are ProtocolType and OtherProtocolType, describing the type of protocol being forwarded. None of the associations in which this class participates is used directly in the QoS device state model. The ForwardsAmong association is, however, the superclass for the model's ConditioningServiceOnEndpoint association. Please refer to [CIM] for the full definition of this class. 4.4.7. The Class ConditioningService This is a concrete class defined in the Network Model of CIM. It is a subclass of ForwardingService, and represents the ability to define how traffic is conditioned in the data-forwarding path of a device. The subclasses of ConditioningService define the particular types of conditioning that are done. Six fundamental types of conditioning are defined in this draft. These are the services performed by a classifier, a meter, a marker, a dropper, a queue, and a scheduler. Other, more sophisticated types of conditioning may be defined in future iterations. ConditioningService is a concrete class because of considerations related to CIM naming. While this class can be instantiated, an instance of it would not accomplish anything, because the nature of the conditioning, and the parameters that control it, are specified only in the subclasses of ConditioningService. Two associations in which ConditioningService participates are critical to its usage in QoS - QoSConditioningSubService and NextService. QoSConditioningSubService aggregates ConditioningServices into a particular QoS service (such as AF), to describe the specific conditioning functionality that underlies that QoS service in a particular device. NextService indicates the subsequent conditioning service(s) for different traffic streams. Strassner, et al. Expires: Nov 2000 + 6 months [Page 28] Internet Draft QoS Device Info Model November 2000 The class definition is as follows: NAME ConditioningService DESCRIPTION A concrete class to define how traffic is conditioned in the data forwarding path of a host or network device. DERIVED FROM ForwardingService TYPE Concrete PROPERTIES Enabled 4.4.7.1 The Property Enabled This property is a boolean that, if TRUE, signifies that the instance's conditioning function can be performed on traffic that it encounters. 4.4.8. The Class ClassifierService This is a concrete class defined in the Network Model of CIM. The concept of a Classifier comes from [DSMODEL]. It represents a logical entity in an ingress or egress interface of a device, that takes a single input stream, and sorts it into one or more output streams. The sorting is done by a set of filters that select packets based on the packet contents, or possibly based on other attributes associated with the packet. (Currently the only filters defined in the model make their selections based only on a packet's contents.) Each output stream is the result of matching a particular filter. In the CIM QoS model, the association ClassifierFilterSet links a classifier to the set of FilterLists that it uses to sort traffic. In this document, however, the representation of classifiers is closer to that presented in [DSMIB] and [DSMODEL]. Rather than being linked directly to its FilterLists by the ClassifierFilterSet association, a classifier is modeled here as an aggregation of ClassifierFilterElements. Each of these ClassifierFilterElements is then linked to a single FilterList by the association ClassifierElementUsesFilterList, which is derived from the more general association ClassifierFilterSet. A Classifier is modeled as a ConditioningService so that it can be aggregated into a QoSService (using the QoSConditioningSubService aggregation), and can use the NextService association to identify the subsequent ConditioningServices for different traffic streams. The class definition is as follows: NAME ClassifierService DESCRIPTION A concrete class describing how an input traffic stream is sorted into multiple output streams using one or more filters. Strassner, et al. Expires: Nov 2000 + 6 months [Page 29] Internet Draft QoS Device Info Model November 2000 DERIVED FROM ConditioningService TYPE Concrete PROPERTIES HaveClassifiedPackets 4.4.8.1 The Property HaveClassifiedPackets This is a boolean property that, if TRUE, indicates that this Classifier has already processed at least one packet. 4.4.9. The Class ClassifierElement This concrete class is not currently defined in the Network Model of CIM, although it may be added to the model at some point in the future. The concept of a ClassifierElement comes from [DSMIB]. It represents the linkage, within a single ClassifierService, between a FilterList that selects packets from the stream of packets coming into the ClassifierService, and the next ConditioningService to which the selected packets go after they leave the ClassifierService. ClassifierElement has no properties of its own, although it inherits HaveClassifiedPackets from its superclass, ClassifierService. It is present to serve as the anchor for an aggregation with its classifier, and for associations with its FilterList and its next ConditioningService. The class definition is as follows: NAME ClassifierElement DESCRIPTION A concrete class representing the process by which a classifier uses a filter to select packets to forward to a specific next conditioning service. DERIVED FROM ClassifierService TYPE Concrete PROPERTIES 4.4.10. The Class MeterService This is a concrete class defined in the Network Model of CIM. This class represents the metering of network traffic. Metering is the function of monitoring the arrival times of packets of a traffic stream, and determining the level of conformance of each packet with respect to a pre-established traffic profile. A meter has the ability to invoke different ConditioningServices for conforming and non-conforming traffic. Traffic leaving a meter may be further conditioned (e.g., dropped or queued) by routing the packet to another conditioning element. Please see [DSMODEL] for more information on metering. This class is the base class for defining different types of meters. As such, it contains common properties that all meter Strassner, et al. Expires: Nov 2000 + 6 months [Page 30] Internet Draft QoS Device Info Model November 2000 subclasses share. It is modeled as a ConditioningService so that it can be aggregated into a QoSService (using the QoSConditioningSubService association), to indicate that its functionality underlies that QoS service. MeterService also participates in a subclass of the NextService association, to identify the subsequent ConditioningServices for conforming and non-conforming traffic. The class definition is as follows: NAME MeterService DESCRIPTION A concrete class describing the monitoring of traffic with respect to a pre-established traffic profile. DERIVED FROM ConditioningService TYPE Concrete PROPERTIES MeterType, OtherMeterType, ConformanceLevels Note: The MeterType property and the MeterService subclasses provide similar information. The MeterType property is defined for query purposes and for future expansion. It is possible that not all MeterServices will require a subclass to define them. In these cases, MeterService will be instantiated directly, and the MeterType property will provide the only way of identifying the type of the meter. 4.4.10.1 The Property MeterType This attribute is an enumerated 16-bit unsigned integer that is used to specify the particular type of meter represented by an instance of MeterService. The following enumeration values are defined: 1 - Other 2 - Average Rate Meter 3 - Exponentially Weighted Moving Average Meter 4 - TokenBucketMeter 4.4.10.2 The Property OtherMeterType This is a string attribute that defines a vendor-specific description of a type of meter. It is used when the value of the MeterType attribute in the instance is equal to 1. 4.4.10.3 The Property ConformanceLevels This attribute is a 16-bit unsigned integer. It indicates the number of conformance levels supported by the meter. For example, when only "in-profile" versus "out of profile" metering is supported, ConformanceLevels is equal to 2. Strassner, et al. Expires: Nov 2000 + 6 months [Page 31] Internet Draft QoS Device Info Model November 2000 4.4.11. The Class AverageRateMeter This is a concrete class, defined in the Network Model of CIM. It is a subclass of MeterService, and represents a simple meter, called an Average Rate Meter. This type of meter measures the average rate at which packets are submitted to it over a specified time. Packets are defined as conformant if their average arrival rate does not exceed the specified measuring rate of the meter. Any packet that causes the specified measuring rate to be exceeded is defined to be non-conforming. For more information, please see [DSMODEL]. The class definition is as follows: NAME AverageRateMeter DESCRIPTION A concrete class classifying traffic as either conforming or non-conforming, depending on whether the arrival of a packet causes the average arrival rate to exceed a pre-determined value. DERIVED FROM MeterService TYPE Concrete PROPERTIES AverageRate, DeltaInterval 4.4.11.1 The Property AverageRate This is an unsigned 32-bit integer that defines the rate used to determine whether admitted packets are in conformance or not. The value is specified in kilobits per second. 4.4.11.2 The Property DeltaInterval This is an unsigned 64-bit integer that defines the time period over which the average measurement should be taken. The value is specified in microseconds. 4.4.12. The Class EWMAMeter This is a concrete class, defined in the Network Model of CIM. It is a subclass of the MeterService class, and represents an exponentially weighted moving average meter. This meter is a simple low-pass filter that measures the rate of incoming packets over a small, fixed sampling interval. Any admitted packet that pushes the average rate over a pre-defined limit is defined to be non-conforming. Please see [DSMODEL] for more information. The class definition is as follows: NAME EWMAMeter DESCRIPTION A concrete class classifying admitted traffic as either conforming or non- conforming, depending on whether the arrival of a packet causes the average Strassner, et al. Expires: Nov 2000 + 6 months [Page 32] Internet Draft QoS Device Info Model November 2000 arrival rate in a small fixed sampling interval to exceed a pre-determined value or not. DERIVED FROM MeterService TYPE Concrete PROPERTIES AverageRate, DeltaInterval, Gain 4.4.12.1 The Property AverageRate This attribute is an unsigned 32-bit integer that defines the average rate against which the sampled arrival rate of packets should be measured. Any packet that causes the sampled rate to exceed this rate is deemed non-conforming. The value is specified in kilobits per second. 4.4.12.2 The Property DeltaInterval This attribute is an unsigned 64-bit integer that defines the sampling interval used to measure the arrival rate in bytes. The calculated rate is averaged over this interval and checked against the AverageRate attribute. All packets whose computed average arrival rate is less than the AverageRate are deemed conforming. The value is specified in microseconds. 4.4.12.3 The Property Gain This attribute is an unsigned 32-bit integer representing the reciprocal of the time constant (e.g., frequency response) of what is essentially a simple low-pass filter. For example, the value 64 for this attribute represents a time constant value of 1/64. 4.4.13. The Class TokenBucketMeter This is a concrete class defined in the Network Model of CIM. It describes the metering of network traffic using a token bucket meter. Two types of token bucket meters are defined using this class - a simple, two-parameter bucket meter, and a multi-stage meter. A simple token bucket usually has two parameters, an average token rate and a burst size, and has two conformance levels: "conforming" and "non-conforming". This class also defines an excess burst size, which enables the meter to have three conformance levels ("conforming", "partially conforming", and "non-conforming"). In this case, packets that exceed the excess burst size are deemed non-conforming, while packets that exceed the smaller burst size but are less than the excess burst size are deemed partially conforming. Operation of these meters is described in [DSMODEL]. Strassner, et al. Expires: Nov 2000 + 6 months [Page 33] Internet Draft QoS Device Info Model November 2000 The class definition is as follows: NAME TokenBucketMeter DESCRIPTION A concrete class classifying admitted traffic with respect to a token bucket. Either two or three levels of conformance can be defined. DERIVED FROM MeterService TYPE Concrete PROPERTIES AverageRate, PeakRate, BurstSize, ExcessBurstSize 4.4.13.1 The Property AverageRate This attribute is an unsigned 32-bit integer that specifies the committed rate of the meter. The value is expressed in kilobits per second. 4.4.13.2 The Property PeakRate This attribute is an unsigned 32-bit integer that specifies the peak rate of the meter. The value is expressed in kilobits per second. 4.4.13.3 The Property BurstSize This attribute is an unsigned 32-bit integer that specifies the maximum number of tokens available for the committed rate (specified by the AverageRate property). The value is expressed in kilobytes. 4.4.13.4 The Property ExcessBurstSize This attribute is am unsigned 32-bit integer that specifies the maximum number of tokens available for the peak rate (specified by the PeakRate property). The value is expressed in kilobytes. 4.4.14. The Class MarkerService This is a concrete class, defined in the Network Model of CIM. It represents the general process of marking some field in a network packet with some value. Subclasses of MarkerService identify particular fields to be marked, and introduce properties to represent the values to be used in marking these fields. Markers are usually invoked as a result of a preceding classifier match. Operation of markers of various types is described in [DSMODEL]. MarkerService is a concrete class because of considerations related to CIM naming. While this class can be instantiated, an instance of it would not accomplish anything, because both the field to be marked and the value to be used to mark it are specified only in subclasses of MarkerService. Strassner, et al. Expires: Nov 2000 + 6 months [Page 34] Internet Draft QoS Device Info Model November 2000 MarkerService is modeled as a ConditioningService so that it can be aggregated into a QoSService (using the QoSConditioningSubService association) to indicate that its functionality underlies that QoS service. It participates in the NextService association to identify the subsequent ConditioningService that acts on traffic after it has been marked by the marker. The class definition is as follows: NAME MarkerService DESCRIPTION A concrete class representing the general process of marking a selected field in a packet with a specified value. Packets are marked in order to control the conditioning that they will subsequently receive. DERIVED FROM ConditioningService TYPE Concrete PROPERTIES 4.4.15. The Class ToSMarkerService This is a concrete class, defined in the Network Model of CIM. It represents the marking of the ToS field in the IPv4 packet header [R791]. Following common practice, the value to be written into the field is represented as an unsigned 8-bit integer. The class definition is as follows: NAME ToSMarkerService DESCRIPTION A concrete class representing the process of marking the type of service (ToS) field in the IPv4 packet header with a specified value. Packets are marked in order to control the conditioning that they will subsequently receive. DERIVED FROM MarkerService TYPE Concrete PROPERTIES ToSValue 4.4.15.1 The Property ToSValue This property is an unsigned 8-bit integer, representing a value to be used for marking the type of service (ToS) field in the IPv4 packet header. The ToS field is defined to be a complete octet, so the range for this property is 0..255. Some implementations, however, require that the lowest-order bit in the ToS field always be '0'. Such an implementation is consequently unable to support an odd TosValue. Strassner, et al. Expires: Nov 2000 + 6 months [Page 35] Internet Draft QoS Device Info Model November 2000 4.4.16. The Class DSCPMarkerService This is a concrete class, defined in the Network Model of CIM. It represents the marking of the differentiated services codepoint (DSCP) within the DS field in the IPv4 and IPv6 packet headers, as defined in [R2474]. Following common practice, the value to be written into the field is represented as an unsigned 8-bit integer. The class definition is as follows: NAME DSCPMarkerService DESCRIPTION A concrete class representing the process of marking the DSCP field in a packet with a specified value. Packets are marked in order to control the conditioning that they will subsequently receive. DERIVED FROM MarkerService TYPE Concrete PROPERTIES DSCPValue 4.4.16.1 The Property DSCPValue This property is an unsigned 8-bit integer, representing a value to be used for marking the DSCP within the DS field in an IPv4 or IPv6 packet header. Since the DSCP consists of 6 bits, the values for this property are limited to the range 0..63. When the DSCP is marked, the remaining two bit in the DS field are left unchanged. 4.4.17. The Class PriorityMarkerService This is a concrete class, defined in the Network Model of CIM. It represents the marking of the the user priority field defined in the IEEE P802.1Q specification [IEEE802Q]. Following common practice, the value to be written into the field is represented as an unsigned 8-bit integer. The class definition is as follows: NAME PriorityMarkerService DESCRIPTION A concrete class representing the process of marking the the Priority field in an 802.1Q-compliant frame with a specified value. Frames are marked in order to control the conditioning that they will subsequently receive. DERIVED FROM MarkerService TYPE Concrete PROPERTIES PriorityValue Strassner, et al. Expires: Nov 2000 + 6 months [Page 36] Internet Draft QoS Device Info Model November 2000 4.4.17.1 The Property PriorityValue This property is an unsigned 8-bit integer, representing a value to be used for marking the Priority field in the 802.1Q header. Since the Priority field consists of 3 bits, the values for this property are limited to the range 0..7. When the Priority field is marked, the remaining bits in its octet are left unchanged. 4.4.18. The Class DropperService This is a concrete class, defined in the Network Model of CIM. It represents the ability to selectively drop network traffic, or to invoke another ConditioningService for further processing of traffic that is not dropped. This is the base class for different types of droppers. Droppers are distinguished by the algorithm that they use to drop traffic. Please see [DSMODEL] for more information about the various types of droppers. Note that this class encompasses both Absolute Droppers and Algorithmic Droppers from [DSMODEL]. DropperService is modeled as a ConditioningService so that it can be aggregated into a QoSService (using the QoSConditioningSubService association) to indicate that its functionality underlies that QoS service. It participates in the NextService association to identify the subsequent ConditioningService that acts on any remaining traffic that is not dropped. The class definition is as follows: NAME DropperService DESCRIPTION A concrete base class describing the common characteristics of droppers. DERIVED FROM ConditioningService TYPE Concrete PROPERTIES DropperType, OtherDropperType Note: The DropperType property and the DropperService subclasses provide similar information. The DropperType property is defined for query purposes, as well as for those cases where a subclass of DropperService is not needed to model a particular type of dropper. For example, the Absolute Dropper defined in [DSMODEL] is modeled as an instance of the DropperService class with its DropperType set to '6' ("Absolute Dropper"). 4.4.18.1 The Property DropperType This is an enumerated 16-bit unsigned integer that defines the type of dropper. Values include: 1 - Other Strassner, et al. Expires: Nov 2000 + 6 months [Page 37] Internet Draft QoS Device Info Model November 2000 2 - Head 3 - Tail 4 - RED 5 - Weighted RED 6 - Absolute Dropper 4.4.18.2 The Property OtherDropperType This string attribute is used in conjunction with the DropperType attribute. When the value of DropperType is '1' (i.e., Other), then the name of the type of dropper (for this instance) appears in this attribute. 4.4.19. The Class HeadTailDropperService This is a concrete class, defined in the Network Model of CIM. It describes the threshold information of a head or tail dropper. The class definition is as follows: NAME HeadTailDropperService DESCRIPTION A concrete class used to describe a head or tail dropper. DERIVED FROM DropperService TYPE Concrete PROPERTIES QueueThreshold 4.4.19.1 The Property QueueThreshold This is an unsigned 32-bit integer that indicates the queue depth at which traffic will be dropped. For a tail dropper, all newly arriving traffic is dropped. For a head dropper, packets at the front of the queue are dropped to make room for new packets, which are added at the end. The value is expressed in bytes. 4.4.20. The Class REDDropperService This is a concrete class, defined in the Network Model of CIM. It describes the ability to drop network traffic using a Random Early Detection (RED) algorithm. This algorithm is described in [RED]. The purpose of a RED algorithm is to avoid congestion (as opposed to managing congestion). Instead of waiting for the queues to fill up, and then dropping large numbers of packets, RED works by monitoring the average queue depth. When the queue depth exceeds a minimum threshold, packets are randomly discarded. These discards cause TCP to slow down its transmission rate for those connections that experienced the packet discards. Other TCP connections are not affected by these discards. Please see [DSMODEL] for more information about a dropper. The class definition is as follows: Strassner, et al. Expires: Nov 2000 + 6 months [Page 38] Internet Draft QoS Device Info Model November 2000 NAME REDDropperService DESCRIPTION A concrete class used to describe dropping using the RED algorithm (or one of its variants). DERIVED FROM DropperService TYPE Concrete PROPERTIES MinQueueThreshold, MaxQueueThreshold, StartProbability, StopProbability NOTE: In [DSMIB], there is a single diffServRandomDropTable, which represents the general category of random dropping. (RED is one type of random dropping, but there are also types of random dropping distinct from RED.) The REDDropperService class corresponds to the columns in the table that apply to the RED algorithm in particular. Work is ongoing to decide how/whether this model should represent the other columns in the table. 4.4.20.1 The Property MinQueueThreshold This is an unsigned 32-bit integer that defines the minimum average queue depth (in bytes) at which packets are subject to being dropped. The slope of the drop probability function is described by the Start/StopProbability properties. 4.4.20.2 The Property MaxQueueThreshold This is an unsigned 32-bit integer that defines the maximum average queue length (in bytes) at which packets are subject to always being dropped, regardless of the dropping algorithm and probabilities being used 4.4.20.3 The Property StartProbability This is an unsigned 32-bit integer; in conjunction with the StopProbability attribute, it defines the slope of the drop probability function. This function governs the rate at which packets are subject to being dropped, as a function of the queue length. Min and max values are 0 to 100. 4.4.20.4 The Property StopProbability This is an unsigned 32-bit integer; in conjunction with the StartProbability attribute, it defines the slope of the drop probability function. This function governs the rate at which packets are subject to being dropped, as a function of the queue length. Min and max values are 0 to 100. Strassner, et al. Expires: Nov 2000 + 6 months [Page 39] Internet Draft QoS Device Info Model November 2000 4.4.21. The Class QueuingService This is a concrete class defined in the Network Model of CIM. It represents the ability to queue network traffic, and to specify the characteristics for determining long-term congestion. Please see [DSMODEL] for more information about queuing functionality. QueuingService is modeled as a ConditioningService so that it can be aggregated into a QoSService (using the QoSConditioningSubService association) to indicate that its functionality underlies that QoS service. The class definition is as follows: NAME QueuingService DESCRIPTION A concrete class describing the ability to queue network traffic and to specify the characteristics for determining long-term congestion. DERIVED FROM ConditioningService TYPE Concrete PROPERTIES NOTE: While they are not (yet) part of the Network Model of CIM, the authors are investigating adding two properties to the QueuingService class: o An unsigned 32-bit integer CurrentQueueDepth, to function as a gauge that represents the current depth of this one queue. This value may be important in diagnosing unexpected behavior by a DropThresholdCalculationService. o A boolean property VirtualQueue, to identify "queues" in a hierarchy of bandwidth-scheduled queues that have bandwidth to share with other queues in the hierarchy, but do not themselves enqueue any packets. 4.4.22. The Class PacketSchedulingService This is a concrete class defined in the Network Model of CIM. It represents a scheduling service, which is a process that determines when a queued packet should be removed from a queue and sent to an output interface. Note that output interfaces can be physical network interfaces or interfaces to components internal to systems, such as crossbars or back planes. In either case, if multiple queues are involved, schedulers are used to provide access to the interface. Each instance of a PacketSchedulingService describes a scheduler from the perspective of the queues that it is servicing. Please see [DSMODEL] for more information about a scheduler. Strassner, et al. Expires: Nov 2000 + 6 months [Page 40] Internet Draft QoS Device Info Model November 2000 PacketSchedulingService is modeled as a ConditioningService so that it can be aggregated into a QoSService (using the QoSConditioningSubService association) to indicate that its functionality underlies that QoS service. It participates in the NextService association to identify the subsequent ConditioningService, if any, that acts on traffic after it has been processed by the scheduler. The class definition is as follows: NAME PacketSchedulingService DESCRIPTION A concrete class used to determine when a packet should be removed from a queue and sent to an output interface. DERIVED FROM ConditioningService TYPE Concrete PROPERTIES SchedulerType, OtherSchedulerType, WorkConserving 4.4.22.1 The Property SchedulerType This attribute is an enumerated 16-bit unsigned integer, and defines the type of scheduler. Values are: 1 - Other 2 - FIFO 3 - Priority 4 - Bandwidth 5 - Bounded Strict Priority 6 - Round Robin Packet 7 - Weighted Round Robin Packet 8 - Class-Based Queuing 9.- Custom Queuing 10 - Weighted Fair Queuing 11 - Weighted Interleaved Round Robin 4.4.22.2 The Property OtherSchedulerType This attribute is used in conjunction with the SchedulerType attribute. When the value of SchedulerType is 1 (i.e., Other), then the type of scheduler is specified in this attribute. 4.4.22.3 The Property WorkConserving If the value of this boolean attribute is TRUE, then the scheduling algorithm services a packet, if one is available, at every transmission opportunity. 4.4.23. The Class QoSService This is a concrete class defined in the Network Model of CIM. It represents the ability to conceptualize a QoS service as a set of coordinated sub-services. This enables the network administrator Strassner, et al. Expires: Nov 2000 + 6 months [Page 41] Internet Draft QoS Device Info Model November 2000 to map business rules to the network, and the network designer to engineer the network such that it can provide different functions for different traffic streams. This class has two main purposes. First, it serves as a common base class for defining the various sub-services needed to build higher-level QoS services. Second, it serves as a way to consolidate the relationships between different types of QoS services and different types of ConditioningServices. For example, Gold Service may be defined as a set of sub- services, where each of these sub-services performs one or more different functions required by the higher-level service. Continuing the example, Gold Service may be used to specify EF for one traffic stream, along with different AF services for other different traffic streams. Each of these services is an instance of the class QoSService, and each requires a set of sub- services to be defined as part of its implementation. For example, one would expect to see different marking, dropping, and queuing sub-services to be defined for each of these services. This is modeled as a type of NetworkService, which is used as the anchor point for defining a set of sub-services that implement the desired conditioning characteristics for different types of flows. It will direct the specific type of ConditioningServices to be used in order to implement this service. The class definition is as follows: NAME QoSService DESCRIPTION A concrete class used to represent a QoS service or set of services, as defined by a network administrator. DERIVED FROM NetworkService TYPE Concrete PROPERTIES 4.4.24. The Class DiffServService This is a concrete class defined in the Network Model of CIM. This class represents using standard or custom DiffServ services to implement a (higher-level) QoS service. Note that the DiffServService may be just one of a set of coordinated QoSSubServices that together implement a higher-level QoS service. DiffServService is modeled as a subclass of QoSService. This enables it to be related to a higher-level QoS service via QoSSubService, as well as to specific ConditioningServices (e.g., classification, metering, dropping, queuing, and others) via QoSConditioningSubService. The class definition is as follows: Strassner, et al. Expires: Nov 2000 + 6 months [Page 42] Internet Draft QoS Device Info Model November 2000 NAME DiffServService DESCRIPTION A concrete class used to represent a DiffServ service, or a set of DiffServ services. DERIVED FROM QoSService TYPE Concrete PROPERTIES DSCP 4.4.24.1 The Property DSCP This attribute is an unsigned 8-bit integer. It identifies a Differentiated Services Code Point used to represent various types of differentiated services, through device-specific configuration commands. 4.4.25. The Class AFService This is a concrete class defined in the Network Model of CIM. It represents a specialization of the general concept of forwarding network traffic by adding specific semantics that characterize the operation of the Assured Forwarding (AF) Service ([R2597]). [R2597] defines four different AF classes, to represent four different treatments of traffic. A different amount of forwarding resources, such as buffer space and bandwidth, are allocated to each AF class. Within each AF class, IP packets are marked with one of three possible drop precedence values. The drop precedence of a packet determines the relative importance of that packet compared to other packets within the same AF class, if congestion occurs. A congested interface will try to avoid dropping packets marked with a lower drop precedence value, by instead discarding packets marked with a higher drop precedence value. Note that [R2597] defines 12 DSCPs that together represent the AF Per-Hop Behavior (PHB) group. Implementations are free to extend this (e.g., add more classes and/or drop precedences). The AFService class is modeled as a specialization of DiffServService, which is in turn a specialization of QoSService. This enables it to be related to higher-level QoS services, as well as to lower-level conditioning sub-services (e.g., classification, metering, dropping, queuing, and others). The class definition is as follows: NAME AFService DESCRIPTION A concrete class for describing the common characteristics of differentiated services that are used to affect traffic forwarding, using the AF PHB Group. DERIVED FROM DiffServService Strassner, et al. Expires: Nov 2000 + 6 months [Page 43] Internet Draft QoS Device Info Model November 2000 TYPE Concrete PROPERTIES ClassNumber, DropperNumber 4.4.25.1 The Property ClassNumber This attribute is an 8-bit unsigned integer that indicates the number of AF classes that this AF implementation uses. Implementations should define at least four classes. 4.4.25.2 The Property DropperNumber This attribute is an 8-bit unsigned integer that indicates the number of drop precedence values that this AF implementation uses. The number of drop precedence values is the number PER AF CLASS. Implementations should define at least three drop precedence values per class. 4.4.26. The Class EFService This is a concrete class defined in the Network Model of CIM. It represents a specialization of the general concept of forwarding network traffic by adding specific semantics that characterize the operation of the Expedited Forwarding (EF) Service ([R2598]). The EFService class is modeled as a specialization of DiffServService, which is in turn a specialization of QoSService. This enables it to be related to a higher-level QoS service, as well as to lower-level conditioning sub-services (e.g., classification, metering, dropping, queuing, and others). The EF PHB can be used to build a low loss, low latency, low jitter, assured bandwidth, end-to-end service through DiffServ domains. Such a service appears to the endpoints like a point- to-point connection or a virtual leased line. This service has also been described as Premium service. [R2598] defines one DSCP for the EF service. The inherited DSCP property will contain this value for all instances of EFService. The class definition is as follows: NAME EFService DESCRIPTION A concrete class for describing the common characteristics of differentiated services that are used to affect traffic forwarding using the EF PHB Group. DERIVED FROM DiffServService TYPE Concrete PROPERTIES Strassner, et al. Expires: Nov 2000 + 6 months [Page 44] Internet Draft QoS Device Info Model November 2000 4.4.27. The Class PrecedenceService This is a concrete class defined in the NetworkModel of CIM. It represents a specialization of the general concept of forwarding network traffic by adding specific semantics that define how traffic is forwarded based on the value of the ToS byte of a packet. This class is used to enable DiffServ devices and non-DiffServ devices to exchange traffic. The sibling class DiffServService is used to represent devices that forward traffic based on the DiffServ code point, while this class represents devices that use the ToS byte. Using these two classes, the administrator can define mappings between devices that do not support DiffServ, and instead use IP Precedence, and devices that do support DiffServ, which use DSCPs. Since the PrecedenceService class is a specialization of QoSService, instances can be related to higher-level QoS services using the QoSSubService association. Instances can also be related to lower-level sub-services (e.g., classification, metering, dropping, queuing, and others), using the QoSConditioingSubService association. The class definition is as follows: NAME PrecedenceService DESCRIPTION A concrete class for describing the common characteristics of forwarding traffic based on the value of the ToS byte. DERIVED FROM DiffServService TYPE Concrete PROPERTIES PrecedenceValue 4.4.27.1 The Property PrecedenceValue This attribute is an 8-bit unsigned integer that defines the notion of precedence for different types of traffic. See [R2474] for more information on the definition and use of this attribute, as well as on its backward compatibility with the ToS byte of IPv4. 4.4.28. The Class 8021PService This is a concrete class defined in the Network Model of CIM. It represents a specialization of the general concept of forwarding network traffic by adding specific semantics that define how traffic is forwarded based on the value of the user priority field defined in the IEEE P802.1Q specification [IEEE802Q]. Strassner, et al. Expires: Nov 2000 + 6 months [Page 45] Internet Draft QoS Device Info Model November 2000 This class is used to enable DiffServ devices and domains that support 802.1P, to exchange traffic. It allows implementations that only support 802.1P priority marking to be mapped to implementations that support DiffServ, which uses DSCPs. Since the 8021PService class is a specialization of QoSService, instances can be related to higher-level QoS services using the QoSSubService association. Instances can also be related to lower-level sub-services (e.g., classification, metering, dropping, queuing, and others), using the QoSConditioingSubService association. The class definition is as follows: NAME 8021PService DESCRIPTION A concrete class for describing the common characteristics of forwarding traffic based on the value of the Priority field in the 802.1P header. DERIVED FROM QoSService TYPE Concrete PROPERTIES PriorityValue 4.4.28.1 The Property PriorityValue This attribute is an 8-bit unsigned integer that represents a priority value, as specified in the 802.1Q standards. 4.4.29. The Class DropThresholdCalculationService This class represents a logical entity that calculates an average queue depth, possibly across several queues, based on a smoothing weight and a sampling time interval. It does this calculation on behalf of a RED dropper, to allow the dropper to make its decisions whether to drop packets based on an average queue depth calculated across a set of queues. The class definition is as follows: NAME DropThresholdCalculationService DESCRIPTION A concrete class representing a logical entity that calculates an average queue depth, possibly across several queues, based on a smoothing weight and a sampling time interval. The latter are properties of this Service, describing how it operates and its necessary parameters. DERIVED FROM Service TYPE Concrete PROPERTIES SmoothingWeight, TimeInterval Strassner, et al. Expires: Nov 2000 + 6 months [Page 46] Internet Draft QoS Device Info Model November 2000 4.4.29.1 The Property SmoothingWeight This property is a 32-bit unsigned integer, ranging between 0 and 100,000 - specified in thousandths. It defines the weighting of past history in affecting the calculation of the current queue average. When performing this calculation over a single queue, the current queue depth uses the inverse of this value as its factor, and one minus that inverse as the factor for the historical average. The calculation takes the form: average = (old_average*(1-inverse of SmoothingWeight)) + (current_queue_depth*inverse of SmoothingWeight) When performing this calculation over multiple queues, the value for current_queue_depth is based on the current depths of all the queues being monitored. Implementations may choose to limit the acceptable set of values to a specified set, such as powers of 2. Min and max values are 0 and 100000. 4.4.29.2 The Property TimeInterval This property is a 32-bit unsigned integer, defining the number of nano-seconds between each calculation of average/smoothed queue depth. If this property is not specified, the CalculationService may determine an appropriate interval. 4.4.30. The Abstract Class FilterEntryBase A simplistic but accurate view of the CIM filter classes is: - FilterEntries aggregated into FilterLists, - Which are then used by the ClassifierService - To separate incoming traffic into different traffic classes (and service levels). FilterEntryBase is an abstract class defined in the Network Model of CIM. It is the base class for all filter entries, and is the endpoint of the association aggregating filter entries into filter lists. Its properties include CIM naming attributes and an IsNegated boolean property (to easily "NOT" the match information specified in FilterEntryBase's subclasses). Please refer to [CIM] for the full definition of this class. 4.4.31. The Class FilterEntry FilterEntry is a concrete class defined in the Network Model of CIM. It is specific to packet filtering, identifying traffic for Strassner, et al. Expires: Nov 2000 + 6 months [Page 47] Internet Draft QoS Device Info Model November 2000 forwarding/further processing or for dropping. Please refer to [CIM] for the full definition of this class. FilterEntry's properties include: - TrafficType (an enumeration) - Indicates the type of traffic that is filtered. This property affects what can be specified in MatchCondition. Currently, only IP-related values ("IPv4", "IPX", and "IPv6") and the special value "Any" are defined. "Any" is used when the DefaultFilter property indicates that this is the default FilterEntry for its FilterList. - MatchConditionType (an enumeration) - Specifies the type of condition that will be matched - source/destination address and mask, port or port range, protocol type, DiffServ codepoint, ToS Value, 802.1 Priority, etc. The special value "Any" is also defined here, for use, once again, in the default FilterEntry in a FilterList. - OtherMatchConditionType (a string) - When the MatchConditionType is "Other" (value = 1), this string explicitly describes the type of MatchCondition. - MatchConditionValue (a string) - Indicates the specific value(s) to match (or NOT match if the inherited IsNegated property is TRUE). When the value of MatchConditionType is "Any", this property's value is the empty string. - ActionType (an enumeration) - This property is not used in modeling DiffServ classifiers. It always takes its default value 3 ("Filter Only"). - DefaultFilter (a boolean) - This property is not used in modeling DiffServ classifiers. It always takes its default value FALSE. - TrafficClass (a string) - Specifies the label for the traffic class of a packet, when this FilterEntry selects the packet. (A FilterEntry selects a packet if the packet matches it and its IsNegated property is FALSE, or if the packet fails to match it and its IsNegated property is TRUE.) This property is not used in modeling DiffServ classifiers. It always takes its default value "N/A", not applicable. 4.4.32. The Class IP6TupleFilter This concrete class is not currently defined in the Network Model of CIM, although it may be added to the model at some point in the future. It is an optimization of the FilterEntry class, that allows an entire IP 6-tuple filter to be expressed in a single object. Strassner, et al. Expires: Nov 2000 + 6 months [Page 48] Internet Draft QoS Device Info Model November 2000 The class definition is as follows: NAME IP6TupleFilter DESCRIPTION An optimization of FilterEntry, which allows an IP 6-tuple filter (or any subset of one) to be expressed in a single object. DERIVED FROM FilterEntry TYPE Concrete PROPERTIES SrcAddress, SrcMask, DestAddress, DestMask, DSCP, ProtocolID, SrcPortStart, SrcPortEnd, DestPortStart, DestPortEnd Since IP6TupleFilter is a subclass of FilterEntry, it has the TrafficType property to categorize its source and destination addresses as either IPv4 or IPv6. Note that this mechanism requires that the two addresses be of the same type. <
> 4.4.33. The Class 8021Filter This concrete class is not currently defined in the Network Model of CIM, although it may be added to the model at some point in the future. It is an optimization of the FilterEntry class, that allows 802.1.source and destination MAC addresses, as well as the 802.1 protocol ID, to be expressed in a single object The class definition is as follows: NAME 8021Filter DESCRIPTION An optimization of FilterEntry, which allows the 802.1 source and destination MAC addresses and the protocol ID to be expressed in a single object. DERIVED FROM FilterEntry TYPE Concrete PROPERTIES SrcMAC, DestMAC, ProtocolID <
> 4.4.34. The Class 8021PQFilter This concrete class is not currently defined in the Network Model of CIM, although it may be added to the model at some point in the future. It continues the optimization of the FilterEntry class begun in the 8021Filter class, by adding 802.1Q priority and VLAN identifier fields to the 802.1 fields already combined in the 8021Filter class. The class definition is as follows: Strassner, et al. Expires: Nov 2000 + 6 months [Page 49] Internet Draft QoS Device Info Model November 2000 NAME 8021PQFilter DESCRIPTION An optimization of 8021Filter, which adds 802.1 priority and VLAN identifier fields. DERIVED FROM 8021Filter TYPE Concrete PROPERTIES PriorityValue, VLANID <
> 4.4.35. The Class FilterList This is a concrete class defined in the Network Model of CIM. It aggregates instances (of subclasses) of FilterEntryBase via the aggregation EntriesInFilterList. It is possible to aggregate different types of filters into a single FilterList - for example, aggregating packet filters (which are instances of FilterEntry or its subclasses) and security filters (which are subclasses of FilterEntryBase defined in the IPsec portion of the CIM Network Model). The aggregation property EntriesInFilterList.EntrySequence serves to order the filter entries in the FilterList. This is necessary when algorithms such as "Match First" are used to identify traffic based on an aggregated set of FilterEntries. In modeling DiffServ classifiers, however, this property is always set to 0, to indicate that the aggregated FilterEntries are ANDed together to form a selector for a class of traffic. Please refer to [CIM] for the full definition of the FilterList and EntriesInFilterList classes. 4.4.36. The Abstract Class ServiceAccessPoint This is an abstract class defined in the Core Model of CIM. It is a subclass of the LogicalElement class, and is the base class for all objects that manage access to CIM_Services. It represents the management of utilizing or invoking a Service. Please refer to [CIM] for the full definition of this class. 4.4.37. The Class ProtocolEndpoint This is a concrete class defined in the Network Model of CIM. It is derived from ServiceAccessPoint, and describes a communication point from which the services of the network or the system's protocol stack may be accessed. Please refer to [CIM] for the full definition of this class. 4.4.38. The Abstract Class Collection This is an abstract class defined in the Core Model of CIM. It is the superclass for all classes that represent groupings or bags, and that carry no status or "state". (The latter would be Strassner, et al. Expires: Nov 2000 + 6 months [Page 50] Internet Draft QoS Device Info Model November 2000 more correctly modeled as ManagedSystemElements.) Please refer to [CIM] for the full definition of this class. 4.4.39. The Abstract Class CollectionOfMSEs This is an abstract class defined in the Core Model of CIM. It is a subclass of the Collection superclass, restricting the contents of the Collection to ManagedSystemElements. Please refer to [CIM] for the full definition of this class. 4.4.40. The Class BufferPool This is a concrete class, defined in the NetworkModel of CIM. It represents the collection of buffers used by a QueuingService. (The association QueueAllocation describes this usage semantic.) The existence and management of individual buffers will be modeled in a future release. At the current level of abstraction, modeling the existence of the BufferPool is necessary. Long term, it is not sufficient. In implementations where there are multiple buffer sizes, an instance of BufferPool should be defined for each set of buffers with identical or similar sizes. These instances of buffer pools can then be grouped together using the CollectedBuffersPool aggregation. Note that this class is derived from CollectionOfMSEs, and not from Forwarding or ConditioningService. A BufferPool is only a collection of storage, and is NOT a Service. The class definition is as follows: NAME BufferPool DESCRIPTION A concrete class representing a collection of buffers. DERIVED FROM CollectionOfMSEs TYPE Concrete PROPERTIES Name, BufferSize, TotalBuffers, AvailableBuffers, SharedBuffers 4.4.40.1 The Property Name This attribute is a string with a maximum length of 256 characters. It is the common name or label by which the object is known. 4.4.40.2 The Property BufferSize This attribute is a 16-bit unsigned integer, identifying the approximate number of bytes in each buffer in the buffer pool. An implementation will typically group buffers of roughly the same size together, to reduce the number of buffer pools it needs Strassner, et al. Expires: Nov 2000 + 6 months [Page 51] Internet Draft QoS Device Info Model November 2000 to manage. This model does not specify the degree to which buffers in the same buffer pool may differ in size. 4.4.40.3 The Property TotalBuffers This attribute is a 32-bit unsigned integer, reporting the total number of individual buffers in the pool. 4.4.40.4 The Property AvailableBuffers This attribute is a 32-bit unsigned integer, reporting the number of buffers in the Pool that are currently not allocated to any instance of a QueuingService. Buffers allocated to a QueuingService could either be in use (that is, currently contain packet data), or be allocated to a queue pending the arrival of new packet data. 4.4.40.5 The Property SharedBuffers This attribute is a 32-bit unsigned integer, reporting the number of buffers in the Pool that have been simultaneously allocated to multiple instances of QueuingService. 4.5. Association Definitions for the State Portion of the Model This section details the QoS device class associations, which were shown earlier in Figure 5. These associations are defined as classes (that can have properties) in the Information Model. 4.5.1. The Abstract Association Dependency This abstract association defines two object references (named Antecedent and Dependent) that establish general dependency relationships between different managed objects in the information model. The Antecedent reference identifies the independent object in the association, while the Dependent reference identifies the entity that IS dependent. The association's cardinality is many to many. The association is defined in the CIM Core Model of CIM. Please refer to [CIM] for the full definition of this class. 4.5.2. The Association ServiceSAPDependency This association defines two object references that establish a general dependency relationship between a Service object and a ServiceAccessPoint object. This relationship indicates that the referenced Service uses the ServiceAccessPoint of ANOTHER Service. The Service is the Dependent reference, relying on the ServiceAccessPoint to gain access to another Service. The association's cardinality is many to many. Strassner, et al. Expires: Nov 2000 + 6 months [Page 52] Internet Draft QoS Device Info Model November 2000 The association is defined in the Core Model of CIM. Please refer to [CIM] for the full definition of this class. 4.5.3. The Association Forwards Among This association defines two object references that establish a general dependency relationship between the ProtocolEndpoints that are used to forward data and the ForwardingService that is performing the forwarding. The ProtocolEndpoints that are used to forward the data are the Antecedent reference. The service that is forwarding the data is the Dependent reference. The association's cardinality is many to many. The association is defined in the Network Model of CIM. Please refer to [CIM] for the full definition of this class. 4.5.4. The Association ConditioningServiceOnEndpoint This association is defined in the Network Model of CIM. It establishes a dependency relationship between a ProtocolEndpoint object and a ConditioningService object. This relationship indicates that the referenced ProtocolEndpoint is used by the ConditioningService for traffic to enter or leave the device. The direction of the traffic is represented by the property ServiceType, which indicates whether the ConditioningService object handles incoming or outgoing traffic. The ProtocolEndpoint represents whether the traffic arrives at or leaves from a network device, and the ConditioningService that begins or ends the traffic conditioning process within a network device. This class is derived from the ForwardsAmong association. It restricts the Dependent to instances of the ConditioningService class (instead of the more generic ForwardingService class). The class definition for this association is as follows: NAME ConditioningServiceOnEndpoint DESCRIPTION A generic association used to establish dependency relationships between a ConditioningService object and a ProtocolEndpoint object. DERIVED FROM ServiceSAPDependency ABSTRACT False PROPERTIES Dependent[ref ConditioningService[0..n]], ServiceType 4.5.4.1 The Reference Dependent This property is inherited from the ForwardsAmong association, and overridden to serve as an object reference to a ConditioningService object (instead of to the more general Strassner, et al. Expires: Nov 2000 + 6 months [Page 53] Internet Draft QoS Device Info Model November 2000 Service object). This reference indicates the ConditioningService that begins or ends the traffic conditioning processing within a network device. When the ServiceType property indicates the ingress direction, then this reference identifies the first ConditioningService encountered by traffic entering the device via this ProtcolEndpoint. When the ServiceType property indicates the egress direction, then this reference identifies the last ConditioningService to process traffic leaving the device via this ProtocolEndpoint. 4.5.4.2 The Property ServiceType This property is a 16-bit unsigned integer that indicates whether a packet is incoming (value = 1, "Ingress") or outgoing (value = 2, "Egress") at the ProtocolEndpoint, relative to the ConditioningService. 4.5.5. The Association IngressConditioningServiceOnEndpoint This association is not currently defined in the Network Model of CIM, although it may be added to the model at some point in the future. It is derived from ConditioningServiceOnEndpoint, and represents the binding, in the ingress direction, between a protocol endpoint and the first ConditioningService that processes packets received via that protocol endpoint. Since there can only be one "first" ConditioningService for a protocol endpoint, the cardinality for the Dependent object reference is narrowed from 0..n to 0..1. Since, on the other hand, a single ConditioningService can be the first to process packets received via multiple protocol endpoints, the cardinality of the Antecedent object reference remains 0..n. Finally, the value of the ServiceType property, which is inherited from ConditioningServiceOnEndpoint, is fixed at '1' ("Ingress"). 4.5.6. The Association EgressConditioningServiceOnEndpoint This association is not currently defined in the Network Model of CIM, although it may be added to the model at some point in the future. It is derived from ConditioningServiceOnEndpoint, and represents the binding, in the egress direction, between a protocol endpoint and the last ConditioningService that processes packets before they leave a network device via that protocol endpoint. (This "last" ConditioningService is ordinarily a scheduler, but it doesn't have to be.) Since there can only be one "last" ConditioningService for a protocol endpoint, the cardinality for the Dependent object reference is narrowed from 0..n to 0..1. Similarly, since a single ConditioningService cannot be the last one to process packets for multiple protocol endpoints, the cardinality of the Antecedent object reference is also narrowed from 0..n to 0..1. Finally, the value of the ServiceType property, which is inherited from ConditioningServiceOnEndpoint, is fixed at '2' ("Egress"). Strassner, et al. Expires: Nov 2000 + 6 months [Page 54] Internet Draft QoS Device Info Model November 2000 4.5.7. The Association HeadTailDropQueueBinding This association is defined in the Network Model of CIM. It is a subclass of Dependency, describing the association between a head or tail dropper and the queue that it monitors to determine when to drop traffic. The referenced queue is the one whose queue depth is compared against the Dropper's threshold. The cardinality is 1 on the queue side, since a head/tail dropper must monitor a queue. The class definition is as follows: NAME HeadTailDropQueueBinding DESCRIPTION A generic association used to establish a dependency relationship between a head or tail dropper and the queue that it monitors. DERIVED FROM Dependency ABSTRACT False PROPERTIES Antecedent[ref QueuingService[1..1]], Dependent[ref HeadTailDropperService [0..n]] 4.5.8. The Association CalculationBasedOnQueue This association is defined in the Network Model of CIM. It is a subclass of Dependency, and defines two object references that establish a dependency relationship between a QueuingService and an instance of the DropThresholdCalculationService class. The queue's current depth is used by the calculation service in calculating an average queue depth. The class definition is as follows: NAME CalculationBasedOnQueue DESCRIPTION A generic association used to establish a dependency relationship between a QueuingService object and a DropThresholdCalculationService object. DERIVED FROM ServiceServiceDependency ABSTRACT False PROPERTIES Antecedent[ref QueuingService[0..n]], Dependent[ref DropThresholdCalculationService [0..n]] 4.5.8.1 The Reference Antecedent This property is inherited from the Dependency association, and overridden to serve as an object reference to a QueuingService object (instead of to the more general ManagedElement). This reference identifies a queue that the Strassner, et al. Expires: Nov 2000 + 6 months [Page 55] Internet Draft QoS Device Info Model November 2000 DropThresholdCalculationService will use in its calculation of average queue depth. 4.5.8.2 The Reference Dependent This property is inherited from the Dependency association, and overridden to serve as an object reference to a DropThresholdCalculationService object (instead of to the more general ManagedElement). This reference identifies a DropThresholdCalculationService that uses the referenced queue's current depth as one of the inputs to its calculation of average queue depth. 4.5.9. The Association ProvidesServiceToElement This association defines two object references that establish a dependency relationship in which a ManagedSystemElement depends on the functionality of one or more Services. The association's cardinality is many to many. The association is defined in the Core Model of CIM. Please refer to [CIM] for the full definition of this class. 4.5.10. The Association ServiceServiceDependency This association defines two object references that establish a dependency relationship between two Service objects. The particular type of dependency is represented by the TypeOfDependency property; typical examples include that one Service is required to be present or required to have completed for the other Service to operate. This association is very similar to the ServiceSAPDependency relationship. For the latter, the Service is dependent on an AccessPoint to get at another Service. In this relationship, it directly identifies its Service dependency. Both relationships should not be instantiated, since their information is repetitive. The association's cardinality is many to many. The association is defined in the Core Model of CIM. Please refer to [CIM] for the full definition of this class. 4.5.11. The Association QueueHierarchy This association is defined in the Network Model of CIM. It is a subclass of ServiceServiceDependency, and defines two object references that establish a dependency relationship between two QueuingService objects. The class definition is as follows: Strassner, et al. Expires: Nov 2000 + 6 months [Page 56] Internet Draft QoS Device Info Model November 2000 NAME QueueHierarchy DESCRIPTION A generic association used to establish a dependency relationship between two QueuingService objects. DERIVED FROM ServiceServiceDependency ABSTRACT False PROPERTIES Antecedent[ref QueuingService[0..n]], Dependent[ref QueuingService[0..1]] 4.5.11.1 The Reference Antecedent This property is inherited from the ServiceServiceDependency association, and overridden to serve as an object reference to a QueuingService object (instead of to the more general Service object). This reference defines the supporting queue through its QueuingService. This QueuingService can only support at most one higher-level QueuingService. 4.5.11.2 The Reference Dependent This property is inherited from the ServiceServiceDependency association, and overridden to serve as an object reference to a QueuingService object (instead of to the more general Service object). It also restricts the cardinality of this end of the relationship to 0-or-1 (instead of the more generic 0-or-more). This reference indicates the QueuingService that depends on one or more other, lower-level QueuingServices. 4.5.12. The Association CalculationServiceForDropper This association is defined in the Network Model of CIM. It is a subclass of ServiceServiceDependency, and defines two object references that represent the reliance of a REDDropperService on a DropThresholdCalculationService - calculating an average queue depth based on the observed depths of one or more queues. The class definition is as follows: NAME CalculationServiceForDropper DESCRIPTION A generic association used to establish a dependency relationship between a calculation service and a REDDropperSrevice for which it performs average queue depth calculations DERIVED FROM ServiceServiceDependency ABSTRACT False PROPERTIES Antecedent[ref DropThresholdCalculationService[1..1]], Dependent[ref REDDropperService[0..n]] Strassner, et al. Expires: Nov 2000 + 6 months [Page 57] Internet Draft QoS Device Info Model November 2000 4.5.12.1 The Reference Antecedent This property is inherited from the ServiceServiceDependency association, and overridden to serve as an object reference to a DropThresholdCalculationService object (instead of to the more general Service object). The cardinality of the object reference is also restricted to 1, indicating that a RED dropper is always served by exactly one calculation service. 4.5.12.2 The Reference Dependent This property is inherited from the ServiceServiceDependency association, and overridden to serve as an object reference to a REDDropperService object (instead of to the more general Service object). This reference identifies a RED dropper served by a DropThresholdCalculationService. 4.5.13. The Association QueueAllocation This association is defined in the Network Model of CIM. It is a subclass of Dependency, and defines two object references that establish a dependency relationship between a QueuingService and a BufferPool that provides storage space for the packets in the queue. The class definition is as follows: NAME QueueAllocation DESCRIPTION A generic association used to establish a dependency relationship between a QueuingService object and a BufferPool object. DERIVED FROM Dependency ABSTRACT False PROPERTIES Antecedent[ref BufferPool[0..n]], Dependent[ref QueuingService[0..n]] 4.5.13.1 The Reference Antecedent This property is inherited from the Dependency association, and overridden to serve as an object reference to a BufferPool object. This reference identifies the BufferPool in which packets on the QueuingService's queue are stored. 4.5.13.2 The Reference Dependent This property is inherited from the Dependency association, and overridden to serve as an object reference to a QueuingService object. This reference identifies the QueuingService whose packets are being stored in the BufferPool's buffers. Strassner, et al. Expires: Nov 2000 + 6 months [Page 58] Internet Draft QoS Device Info Model November 2000 4.5.14. The Association ClassifierFilterSet This association is defined in the Network Model of CIM. In order for a ClassifierService to correctly identify and process network traffic, that traffic must be described by FilterEntries, which are aggregated into FilterLists. This association defines the Dependency of a ClassifierService on FilterLists (and, therefore, on their FilterEntries). In the DiffServ model, a classifier is always modeled as a ClassifierService that aggregates a set of ClassifierElements. A consequence of this modeling choice is that there is never a ClassifierFilterSet association between a DiffServ ClassifierService and a FilterList. Instead, there is an instance of the association ClassifierElementUsesFilterList, which is itself a subclass of ClassifierFilterSet, between each of the ClassifierElements and a FilterList. The class definition is as follows: NAME ClassifierFilterSet DESCRIPTION A generic association used to establish a dependency relationship between a ClassifierService object and a FilterList object. DERIVED FROM Dependency ABSTRACT False PROPERTIES Antecedent[ref FilterList [0..n]], Dependent[ref ClassifierService [0..n]], FilterListPosition 4.5.14.1 The Reference Antecedent This property is inherited from the Dependency association, and overridden to serve as an object reference to a FilterList object, instead of to the more general ManagedElement object. 4.5.14.2 The Reference Dependent This property is inherited from the Dependency association, and overridden to serve as an object reference to a ClassifierService object, instead of to the more general ManagedElement object. This reference identifies a ClassifierService that depends on the associated FilterList objects to provide its classification logic. 4.5.14.3 The Property FilterListPosition This property is a 32-bit unsigned integer, that provides an ordering of the FilterLists used in the classification and forwarding functions of the ClassifierService. The semantics of this ordering are left unspecified in this model. Strassner, et al. Expires: Nov 2000 + 6 months [Page 59] Internet Draft QoS Device Info Model November 2000 4.5.15. The Association ClassifierElementUsesFilterList This association is not currently defined in the Network Model of CIM, although it may be added to the model at some point in the future. It is a subclass of the ClassifierFilterSet association. It relates one or more ClassifierElements with a FilterList that selects packets for each ClassifierElement to process. Since a given ClassifierElement is always associated with exactly one FilterList, the FilterListPosition property inherited from ClassifierFilterSet has no significance, and thus always returns its default value '0'. In the DiffServ model, a classifier is always modeled as a ClassifierService that aggregates a set of ClassifierElements. The class definition is as follows: NAME ClassifierElementUsesFilterList DESCRIPTION An association relating a ClassifierElement to the FilterList that selects packets for that ClassifierElement to process. DERIVED FROM ClassifierFilterSet ABSTRACT False PROPERTIES Antecedent[ref FilterList [1..1]], Dependent[ref ClassifierElement [0..n]] 4.5.15.1 The Reference Antecedent This property is inherited from the ClassifierFilterSet association. Its cardinality is restricted to 1, indicating that a ClassifierElement always has exactly one FilterList to select packets for it. 4.5.15.2 The Reference Dependent This property is inherited from the ClassifierFilterSet association, and overridden to serve as an object reference to a ClassifierElement object, instead of to the more general ClassifierService object. This reference identifies a ClassifierElement that depends on the associated FilterList object to select packets for it. 4.5.16. The Association AFRelatedServices This association is defined in the Network Model of CIM. It defines two object references that establish a dependency relationship between two AFService objects. This dependency is the precedence of the individual AF drop-related Services within an AF IP packet-forwarding class. The class definition is as follows: Strassner, et al. Expires: Nov 2000 + 6 months [Page 60] Internet Draft QoS Device Info Model November 2000 NAME AFRelatedServices DESCRIPTION An association used to establish a dependency relationship between two AFService objects. DERIVED FROM Nothing ABSTRACT False PROPERTIES AFLowerDropPrecedence[ref AFService[0..1]], AFHigherDropPrecedence[ref AFService[0..n]] 4.5.16.1 The Reference AFLowerDropPrecedence This property serves as an object reference to an AFService object that has the lower probability of dropping packets. 4.5.16.2 The Reference AFHigherDropPrecedence This property serves as an object reference to an AFService object that has the higher probability of dropping packets. 4.5.17. The Association NextService This association is defined in the Network Model of CIM. It defines two object references that establish a dependency relationship between two ConditioningService objects. This association is used to indicate the sequence of ConditioningServices required to process a particular type of traffic. Instances of this dependency describe the various relationships between different ConditioningServices (such as classifiers, meters, droppers, etc.) that are used collectively to condition traffic. Both one-to-one and more complicated fan-in and/or fan- out relationships can be described. The ConditioningServices may feed one another directly, or they may be mapped to multiple "next" Services based on the characteristics of the packet. The class definition is as follows: NAME NextService DESCRIPTION An association used to establish a dependency relationship between two ConditioningService objects. DERIVED FROM Nothing ABSTRACT False PROPERTIES PrecedingService[ref ConditioningService[0..n]], FollowingService[ref ConditioningService[0..n]], TrafficClass Strassner, et al. Expires: Nov 2000 + 6 months [Page 61] Internet Draft QoS Device Info Model November 2000 4.5.17.1 The Reference PrecedingService This property serves as an object reference to a ConditioningService object that occurs earlier in the processing sequence for a given type of traffic. 4.5.17.2 The Reference FollowingService This property serves as an object reference to a ConditioningService object that occurs later in the processing sequence for a given type of traffic, immediately after the ConditioningService identified by the PrecedingService object reference. 4.5.17.3 The Property TrafficClass This property is a string used to identify different traffic flows that have been separated by a Classifier. In environments such as Differentiated Services, in which microflows are not tracked, the value of this property is defaulted to "N/A", indicating that microflow-level tracking is not applicable. 4.5.18. The Association NextServiceAfterMeter This association is defined in the Network Model of CIM. It defines two object references that establish a dependency relationship between a MeterService and one or more ConditioningService objects that process traffic from the MeterService. It subclasses the NextService association to restrict the independent (or PrecedingService) to be a MeterService. Meters are 1:n fan-out elements, which means that we need a way to distinguish between the different outputs of a meter. Therefore, this association also defines a new property, MeterResult, which can be used to identify the output through which this traffic left the meter. The class definition is as follows: NAME NextServiceAfterMeter DESCRIPTION An association used to establish a dependency relationship between a particular output of a MeterService and the next ConditioningService object that is responsible for further processing of the traffic. DERIVED FROM NextService ABSTRACT False PROPERTIES PrecedingService[ref MeterService[0..n]], MeterResult Strassner, et al. Expires: Nov 2000 + 6 months [Page 62] Internet Draft QoS Device Info Model November 2000 4.5.18.1 The Reference PrecedingService This property is inherited from the NextService association. It is overridden in this subclass to restrict the object reference to a MeterService, as opposed to the more general ConditioningService defined in the NextService superclass. This property serves as an object reference to a MeterService object that occurs earlier in the processing sequence for a given type of traffic. Since Meters are 1:n fan-out devices, this relationship associates a particular output of a MeterService (identified by the MeterResult property) to the next ConditioningService that is used to further process the traffic. 4.5.18.2 The Property MeterResult This property is an enumerated 16-bit unsigned integer, and represents information describing the result of the metering. Traffic is distinguished as being conforming, non-conforming, or partially conforming. More complicated metering can be built either by extending the enumeration or by cascading meters. The enumerated values are: "Unknown" (0), "Conforming" (1), "PartiallyConforming" (2), "NonConforming" (3). 4.5.19. The Association NextServiceAfterClassifierElement This association is not currently defined in the Network Model of CIM, although it may be added to the model at some point in the future. It refines the definition of its superclass, the NextService association, in two ways: o It restricts the PrecedingService object reference to the class ClassifierElement. o It restricts the cardinality of the FollowingService object reference to exactly 1. The class definition is as follows: NAME NextServiceAfterClassifierElement DESCRIPTION An association used to establish a dependency relationship between a single ClassifierElement within a Classifier and the next ConditioningService object that is responsible for further processing of the traffic selected by that ClassifierElement. DERIVED FROM NextService ABSTRACT False PROPERTIES PrecedingService [ref ClassifierElement[0..n]], Strassner, et al. Expires: Nov 2000 + 6 months [Page 63] Internet Draft QoS Device Info Model November 2000 FollowingService [ref ConditioningService[1..1] 4.5.19.1 The Reference PrecedingService This property is inherited from the NextService association. It is overridden in this subclass to restrict the object reference to a ClassifierElement, as opposed to the more general ConditioningService defined in the NextService superclass. This property serves as an object reference to a ClassifierElement, which is a component of a single ClassifierService. Packets selected by this ClassifierElement are always passed to the ConditioningService identified by the FollowingService object reference. 4.5.19.2 The Reference FollowingService This property is inherited from the NextService association. It is overridden in this subclass to restrict the cardinality of the reference to exactly 1. This reflects the requirement that the behavior of a DiffServ classifier must be deterministic: the packets selected by a given ClassifierElement in a given ClassifierService must always go to one and only one next ConditioningService. 4.5.20. The Association SchedulerUsed This association is defined in the Network Model of CIM. It is a subclass of NextService, and defines two object references that establish a dependency relationship between one or more QueuingService objects and a PacketSchedulingService that removes packets from the queues. A scheduler is thus represented as the NextService after each of the queues that it empties. There are some usage restrictions related to this association that cannot be expressed via its cardinality. Ideally, the association should convey that a QueuingService has one associated PacketSchedulingService - i.e., that the cardinality is '1' on the PacketSchedulingService side. However, at the instance level, it is not required that the SchedulerUsed class be instantiated. In addition, AT MOST one of the association's subclasses will be appropriate/instantiated. Therefore, cardinality is set to '0..1', with the usage stipulation that one instance of SchedulerUsed or one of its subclasses MUST relate a QueuingService to a PacketSchedulingService. The class definition is as follows: NAME SchedulerUsed DESCRIPTION A generic association used to establish dependency relationships between a PacketSchedulingService object and Strassner, et al. Expires: Nov 2000 + 6 months [Page 64] Internet Draft QoS Device Info Model November 2000 one or more QueuingService objects. DERIVED FROM NextService ABSTRACT False PROPERTIES PrecedingService[ref QueuingService[0..n]], FollowingService[ref PacketSchedulingService[0..1]] 4.5.20.1 The Reference PrecedingService This property is inherited from the NextService association, and overridden to serve as an object reference to a QueuingService object (instead of to the more general ConditioningService object). This reference indicates the queue(s) and the associated QueuingService(s) that depend on the PacketSchedulingService. 4.5.20.2 The Reference FollowingService This property is inherited from the NextService association, and overridden to serve as an object reference to a PacketSchedulingService object (instead of to the more general ConditioningService object). This reference identifies the PacketSchedulingService that is used to empty the queue(s) represented by the QueuingService(s). 4.5.21. The Association PrioritySchedulerUsed This association is defined in the Network Model of CIM; it is a subclass of the SchedulerUsed association. PrioritySchedulerUsed indicates that a scheduler is taking packets from a set of queues using the priority scheduling discipline. The property Priority on the association represents the priority for a queue, relative to the priorities of all the other queues to which the scheduler is related via the PrioritySchedulerUsed association. Queues to which a scheduler is related via other subclasses of SchedulerUsed do not figure in this prioritization. The class definition is as follows: NAME PrioritySchedulerUsed DESCRIPTION This association specializes the SchedulerUsed association to add a Priority property. This property is used by a SchedulingService that is doing priority scheduling for a set of queues. DERIVED FROM SchedulerUsed ABSTRACT False PROPERTIES Priority Strassner, et al. Expires: Nov 2000 + 6 months [Page 65] Internet Draft QoS Device Info Model November 2000 4.5.21.1 The Property Priority This property is a 16-bit unsigned integer that indicates the priority level of a queue relative to the other queues serviced by this PacketSchedulingService. A larger value represents a higher priority. 4.5.22. The Association BoundedPrioritySchedulerUsed This association is defined in the Network Model of CIM; it is a subclass of the PrioritySchedulerUsed association. BoundedPrioritySchedulerUsed adds an upper bound (in kilobits per second) on how much traffic can be transmitted from a queue. This data is specific to the queue, handled by the referenced scheduler. It is needed when bounded strict priority scheduling is performed. The class definition is as follows: NAME BoundedPrioritySchedulerUsed DESCRIPTION This association specializes the PrioritySchedulerUsed association to add a BandwidthBound property. This property bounds the rate at which traffic from the referenced queue can be transmitted. DERIVED FROM PrioritySchedulerUsed ABSTRACT False PROPERTIES BandwidthBound 4.5.22.1 The Property BandwidthBound This property is a 32-bit unsigned integer that defines the upper limit on the amount of traffic that can be transmitted from the queue. This is not a shaped upper bound, since bursts can occur. It is a strict bound, limiting the impact of the queue. The units are kilobits per second. 4.5.23. The Association BandwidthSchedulerUsed This association is defined in the Network Model of CIM; it is a subclass of the SchedulerUsed association. BandwidthSchedulerUsed introduces three new properties related to bandwidth scheduling. The class definition is as follows: NAME BandwidthSchedulerUsed DESCRIPTION This association specializes the SchedulerUsed relationship to add bandwidth allocation. This is used by a BandwidthSchedulingService when handling its associated queues. Strassner, et al. Expires: Nov 2000 + 6 months [Page 66] Internet Draft QoS Device Info Model November 2000 DERIVED FROM SchedulerUsed ABSTRACT False PROPERTIES BandwidthAllocation, BurstAlloccation, CanShare 4.5.23.1 The Property BandwidthAllocation This property is a 32-bit unsigned integer that defines the number of kilobits/second that should be allocated to the associated queue. 4.5.23.2 The Property BurstAllocation This property is a 32-bit unsigned integer that specifies the amount of temporary or short-term bandwidth (in kilobits per second) that can be allocated to a queue, beyond the amount of bandwidth allocated through the BandwidthAllocation attribute. If the maximum actual bandwidth allocation for the queue were to be measured, it would be the sum of the BurstAllocation and the BandwidthAllocation properties 4.5.23.3 The Property CanShare This is a boolean property that, if TRUE, enables unused bandwidth from the associated queue to be allocated to other queues serviced by the Scheduler. 4.5.24. The Association WRRSchedulerUsed This association is defined in the Network Model of CIM; it is a subclass of the SchedulerUsed association. WRRSchedulerUsed introduces a new property WeightingFactor, to give some queues a higher probability of being serviced than other queues. It also introduces a property Priority, to serve as a tiebreaker to be used when queues have equal weighting factors. The class definition is as follows: NAME WRRSchedulerUsed DESCRIPTION This association specializes the SchedulerUsed association to add a per-queue weight. This is used by a weighted round robin packet scheduler when it handles its associated queues. DERIVED FROM SchedulerUsed ABSTRACT False PROPERTIES WeightingFactor, Priority Strassner, et al. Expires: Nov 2000 + 6 months [Page 67] Internet Draft QoS Device Info Model November 2000 4.5.24.1 The Property WeightingFactor This property is a 32-bit unsigned integer, which defines the weighting factor that offers some queues a higher probability of being serviced than other queues. This property represents this probability. Its minimum value is 0, its maximum value is 100000, and its units are thousandths. 4.5.24.2 The Property Priority This property is a 16-bit unsigned integer, which serves as a tiebreaker, in the event that two or more queues have equal weights. A larger value represents a higher priority. While this condition may not occur in some implementations of a weighted round robin scheduler, many implementations require a priority to resolve an equal-weight condition. In instances where this behavior is not necessary or is undesirable, this property may be left unspecified. 4.5.25. The Aggregation MemberOfCollection This aggregation is a generic relationship used to model the aggregation of a set of ManagedElements in a generalized Collection object. The aggregation's cardinality is many to many. MemberOfCollection is defined in the Core Model of CIM. Please refer to [CIM] for the full definition of this class. 4.5.26. The Aggregation CollectedBufferPool This aggregation is defined in the Network Model of CIM. It models the ability to treat a set of buffers as a pool, or collection, that can in turn be contained in a "higher-level" buffer pool. This class overrides the more generic MemberOfCollection aggregation to restrict both the aggregate and the part component objects to be instances only of the BufferPool class. The class definition for the aggregation is as follows: NAME CollectedBufferPool DESCRIPTION A generic association used to aggregate a set of related buffers into a higher-level buffer pool. DERIVED FROM MemberOfCollection ABSTRACT False PROPERTIES Collection[ref BufferPool[0..1]], Member[ref BufferPool[0..n]] Strassner, et al. Expires: Nov 2000 + 6 months [Page 68] Internet Draft QoS Device Info Model November 2000 4.5.26.1 The Reference Collection This property represents the parent, or aggregate, object in the relationship. It is a BufferPool object. 4.5.26.2 The Reference Member This property represents the child, or lower level pool, in the relationship. It is one of the set of BufferPools that together make up the higher-level pool. 4.5.27. The Abstract Aggregation Component This abstract aggregation is a generic relationship used to establish "part-of" relationships between managed objects (named GroupComponent and PartComponent). The association's cardinality is many to many. The association is defined in the Core Model of CIM. Please refer to [CIM] for the full definition of this class. 4.5.28. The Aggregation ServiceComponent This aggregation is used to model a set of subordinate Services that are aggregated together to form a higher-level Service. This aggregation is derived from the more generic Component superclass to restrict the types of objects that can participate in this relationship. The association is defined in the Core Model of CIM. Please refer to [CIM] for the full definition of this class. 4.5.29. The Aggregation QoSSubService This aggregation is defined in the Network Model of CIM. It represents a set of subordinate QoSServices that are aggregated together to form a higher-level QoSService. A QoSService is a specific type of Service that conceptualizes QoS functionality as a set of coordinated sub-services. This aggregation is derived from the more generic ServiceComponent superclass to restrict the types of objects that can participate in this relationship to QoSService objects, instead of a more generic Service object. It also restricts the cardinality of the aggregate to 0-or-1 (instead of the more generic 0-or-more). The class definition for the aggregation is as follows: NAME QoSSubService DESCRIPTION A generic association used to establish "part-of" relationships between a higher-level QoSService object and the Strassner, et al. Expires: Nov 2000 + 6 months [Page 69] Internet Draft QoS Device Info Model November 2000 set of lower-level QoSServices that are aggregated to create/form it. DERIVED FROM ServiceComponent ABSTRACT False PROPERTIES GroupComponent[ref QoSService[0..1]], PartComponent[ref QoSService[0..n]] 4.5.29.1 The Reference GroupComponent This property is overridden in this aggregation to represent an object reference to a QoSService object (instead of to the more generic Service object defined in its superclass). This object represents the parent, or aggregate, object in the relationship. 4.5.29.2 The Reference PartComponent This property is overridden in this aggregation to represent an object reference to a QoSService object (instead of to the more generic Service object defined in its superclass). This object represents the child, or "component", object in the relationship. 4.5.30. The Aggregation QoSConditioningSubService This aggregation is defined in the Network Model of CIM. It is used to define the set of ConditioningServices that together condition traffic for a particular QoSService. This aggregation is subclassed from the more generic ServiceComponent superclass to restrict the types of objects that can participate in this relationship to ConditioningService and QoSService objects, instead of the more generic Service objects. The class definition for the aggregation is as follows: NAME QoSConditioningSubService DESCRIPTION A generic aggregation used to establish "part-of" relationships between a set of ConditioningService objects and the particular QoSService object that they provide traffic conditioning for. DERIVED FROM ServiceComponent ABSTRACT False PROPERTIES GroupComponent[ref QoSService[0..1]], PartComponent[ref ConditioningService[0..n]] 4.5.30.1 The Reference GroupComponent This property is overridden in this aggregation to represent an object reference to a QoSService object (instead of to the more generic Service object defined in its superclass). It also restricts the cardinality of the aggregate to 0-or-1 (instead of the more generic 0-or-more). Strassner, et al. Expires: Nov 2000 + 6 months [Page 70] Internet Draft QoS Device Info Model November 2000 This object represents the parent, or aggregate, object in the association. In this case, this object represents the QoSService that aggregates one or more ConditioningService objects to implement the appropriate traffic conditioning for its traffic. 4.5.30.2 The Reference PartComponent This property is overridden in this aggregation to represent an object reference to a ConditioningService object (instead of to the more generic Service object defined in its superclass). This object represents the child, or "component", object in the relationship. In this case, this object represents one or more ConditioningService objects that together indicate how traffic for a specific QoSService is conditioned. 4.5.31. The Aggregation ClassifierElementInClassifierService This aggregation is not currently defined in the Network Model of CIM, although it may be added to the model at some point in the future. It represents the relationship between a classifier and the classifier elements that provide the fan-out function for the classifier. A classifier typically aggregates multiple classifier elements. A classifier element, however, is aggregated only by a single classifier. See [DSMODEL] and [DSMIB] for more about classifiers and classifier elements. The class definition for the aggregation is as follows: Strassner, et al. Expires: Nov 2000 + 6 months [Page 71] Internet Draft QoS Device Info Model November 2000 NAME ClassifierElementInClassifierService DESCRIPTION An aggregation representing the relationship between a classifier and its classifier elements. DERIVED FROM ServiceComponent ABSTRACT False PROPERTIES GroupComponent[ref ClassifierService[1..1]], PartComponent[ref ClassifierElement[0..n], ClassifierOrder 4.5.31.1 The Reference GroupComponent This property is overridden in this aggregation to represent an object reference to a ClassifierService object (instead of to the more generic Service object defined in its superclass). It also restricts the cardinality of the aggregate to 1..1 (instead of the more generic 0-or-more), representing the fact that a ClassifierElement always exists within the context of exactly one ClassifierService. 4.5.31.2 The Reference PartComponent This property is overridden in this aggregation to represent an object reference to a ClassifierElement object (instead of to the more generic Service object defined in its superclass). This object represents a single traffic selector for the classifier. A ClassifierElement has associations to a FilterList that selects packets from the traffic stream coming into the classifier, and to a ConditioningService to which packets selected by this FilterList are next forwarded. 4.5.31.3 The Property ClassifierOrder Because the filters for a classifier can overlap, it is necessary to specify the order in which the ClassifierElements aggregated by a ClassifierService are presented with packets coming into the classifier. This property is an unsigned 32-bit integer representing this order. Values are represented in ascending order: first '1', then '2', and so on. 4.5.32. The Aggregation EntriesInFilterList This aggregation is a specialization of the Component aggregation; it is used to define a set of filter entries (subclasses of FilterEntryBase) that are aggregated by a FilterList. The cardinalities of the aggregation itself are 0..1 on the FilterList end, and 0..n on the FilterEntryBase end. Thus in the general case, a filter entry can exist without being aggregated into any FilterList. However, the only way a FilterEntry can Strassner, et al. Expires: Nov 2000 + 6 months [Page 72] Internet Draft QoS Device Info Model November 2000 figure in the QoS Device model is by being aggregated into a FilterList by this aggregation. The aggregation is defined in the Network Model of CIM. Please refer to [CIM] for the full class definition. 5. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 6. Acknowledgements The authors wish to thank the participants of the Policy Framework and Differentiated Services working group for their many helpful comments and suggestions. 7. Security Considerations Security and denial of service considerations are not explicitly considered in this memo, as they are appropriate for the underlying policy architecture implementing the distribution and communication of the information described in this draft. Specifically, any mechanisms used to distribute and communicate the information described in this draft must minimize theft and denial of service threats. Second, it must be ensured that the entities involved in policy control can verify each other's identity and establish necessary trust before communicating. The communication tunnel between policy clients and policy servers SHOULD be secured by the use of an IPSEC [R1825] channel. Strassner, et al. Expires: Nov 2000 + 6 months [Page 73] Internet Draft QoS Device Info Model November 2000 It is advisable that this tunnel makes use of both the AH (Authentication Header) and ESP (Encapsulating Security Payload) protocols, in order to provide confidentiality, data origin authentication, integrity and replay prevention. 8. References [CIM] Common Information Model (CIM) Schema, version 2.4. Distributed Management Task Force, Inc. The components of the CIM v2.4 schema are available via links on the following DMTF web page: http://www.dmtf.org/spec/cims.html. [DSMIB] Management Information Base for the Differentiated Services Architecture. Internet Draft, draft-ietf-diffserv- mib-06.txt, F. Baker, K. Chan, and A. Smith. November 2000. [DSMODEL] An Informal Management Model for DiffServ Routers. Internet Draft, draft-ietf-diffserv-model-05.txt, Y. Bernet, A. Smith, S. Blake, and D. Grossman. November 2000. [IEEE802Q] Virtual Bridged Local Area Networks, ANSI/IEEE std 802.1Q, 1998 edition. Approved December 8, 1998 [PCIM] Policy Core Information Model - Version 1 Specification. Internet Draft, draft-ietf-policy-core-info-model-08.txt, B. Moore, E. Ellison, J. Strassner, and A. Westerinen. October 2000. [PIB] Differentiated Services Quality of Service Policy Information Base. Internet Draft, draft-ietf-diffserv-pib- 01.txt, M. Fine, K. McCloughrie, J. Seligson, K. Chan, S. Hahn, A. Smith, and F. Reichmeyer. July 2000. [POLTERM] Policy Terminology. Internet Draft, draft-ietf-policy- terminology-01.txt, A. Westerinen, J. Schnizlein, J. Strassner, M. Scherling, B. Quinn, J. Perry, S. Herzog, A. Huynh, and M. Carlson. November 2000. [QOSPIM] Policy Framework QoS Information Model. Internet Draft, draft-ietf-policy-qos-info-model-01.txt, Y. Snir, Y. Ramberg, J. Strassner, and R. Cohen. April 2000. [QOSSCH] QoS Policy Schema. Internet Draft, draft-itef-policy- qos-schema-01.txt, Y. Snir, Y. Ramberg, J. Strassner, and R. Cohen. February 2000. [R791] Postel, J., Editor, "Internet Protocol", STD RFC 791, September 1981. Strassner, et al. Expires: Nov 2000 + 6 months [Page 74] Internet Draft QoS Device Info Model November 2000 [R1633] Integrated Services in the Internet Architecture: An Overview. R. Braden, D. Clark, and S. Shenker. June 1994. [R1825] Security Architecture for the Internet Protocol. R. Atkinson. August 1995. [R2119] Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. March 1997. [R2474] Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. K. Nichols, S. Blake, F. Baker, and D. Black. December 1998. [R2475] An Architecture for Differentiated Service. S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss. December 1998. [R2597] Assured Forwarding PHB Group. J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski. June 1999. [R2598] An Expedited Forwarding PHB. V. Jacobson, K. Nichols, and K. Poduri. June 1999. [RED] See http://www-nrg.ee.lbl.gov/floyd/red.html. 9. Authors' Addresses John Strassner Cisco Systems, Bldg 15 170 West Tasman Drive San Jose, CA 95134 E-mail: johns@cisco.com Andrea Westerinen Cisco Systems, Bldg 15 170 West Tasman Drive San Jose, CA 95134 E-mail: andreaw@cisco.com Bob Moore IBM Corporation, BRQA/502 4205 S. Miami Blvd. Research Triangle Park, NC 27709 E-mail: remoore@us.ibm.com David Durham Intel 2111 NE 25th Avenue Hillsboro, OR 97124 Phone: (503) 264-6232 Email: david.durham@intel.com Strassner, et al. Expires: Nov 2000 + 6 months [Page 75] Internet Draft QoS Device Info Model November 2000 Walter Weiss Ellacoya Networks 7 Henry Clay Dr. Merrimack, NH. 03054 Phone: +1-603-879-7364 E-mail: wweiss@ellacoya.com 10. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Strassner, et al. Expires: Nov 2000 + 6 months [Page 76] Internet Draft QoS Device Info Model November 2000 11. Appendix A: Naming Instances in a Native CIM Implementation Following the precedent established in [PCIM], this document has placed the details of how to name instances of its classes in a native CIM implementation here in an appendix. Since Appendix A in [PCIM] has a lengthy discussion of the general principles of CIM naming, this appendix does not repeat that information here. Readers interested in a more global discussion of how instances are named in a native CIM implementation should refer to [PCIM]. 11.1. Naming Instances of the Classes Derived from Service Most of the classes defined in this model are derived from the CIM class Service. Even though Service is an abstract class, it nevertheless has key properties included as part of its definition. The purpose of including key properties in an abstract class is to have instances of all of its instantiable subclasses named in the same way. Thus the majority of this model's classes name their instances in exactly the same way: with the two key properties CreationClassName and Name that they inherit from Service. 11.2. Naming Instances of FilterEntry Like Service, FilterEntryBase is an abstract class that includes key properties in its definition. FilterEntryBase has four key properties. Two of them, SystemCreationClassName and SystemName, are propagated to it via the weak association FilterEntryInSystem. The other two, CreationClassName and Name, are native to FilterEntryBase. Since FilterEntry is a subclass of FilterEntryBase, its instances are named with the four key properties it inherits from FilterEntryBase. Instances of the other subclasses of FilterEntryBase are named in exactly the same way. 11.3. Naming Instances of FilterList Instances of the class FilterList are named in exactly the same way that instances of the subclasses of FilterEntryBase are named. Because it is defined as being weak to System, FilterList has propagated to it the two key properties SystemCreationClassName and SystemName. It also has two key properties of its own: CreationClassName and Name. Taken together, these four key properties uniquely identify an instance of FilterList. 11.4. Naming Instances of ProtocolEndpoint The class ProtocolEndpoint inherits its key properties from its superclass, ServiceAccessPoint. These key properties provide the same naming structure that we've seen before: two propagated key Strassner, et al. Expires: Nov 2000 + 6 months [Page 77] Internet Draft QoS Device Info Model November 2000 properties SystemCreationClassName and SystemName, plus two native key properties CreationClassName and Name. 11.5. Naming Instances of BufferPool Unlike the other classes in this model, BufferPool is not derived from Service. Consequently, it does not inherit its key properties from Service. Instead, it inherits one of its key properties, CollectionID, from its superclass Collection, and adds its other key property, CreationClassName, in its own definition. 11.5.1. The Property CollectionID CollectionID is a string property with a maximum length of 256 characters. It identifies the buffer pool. Note that this property is defined in the BufferPool class's superclass, CollectionOfMSEs, but not as a key property. It is overridden in BufferPool, to make it part of this class's composite key. 11.5.2. The Property CreationClassName This attribute is a string property of with a maximum length of 256 characters. It is set to "CIM_BufferPool" if this class is directly instantiated, or to the class name of the BufferPool subclass that is created. Strassner, et al. Expires: Nov 2000 + 6 months [Page 78]