Policy Framework Working Group J. Strassner INTERNET-DRAFT A. Westerinen Category: Standards Track Cisco Systems Bob Moore IBM Corporation July 2000 Information Model for Describing Network Device QoS Mechanisms Friday, July 14, 2000, 12:15 PM 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: Jul 2000 + 6 months [Page 1] Internet Draft QoS Device Info Model July 2000 Abstract The purpose of this draft is to define an information model that describes the QoS mechanisms inherent in different network devices. 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]). The next version of this draft will also 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 (e.g., 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 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: Jul 2000 + 6 months [Page 2] Internet Draft QoS Device Info Model July 2000 Table of Contents 1. Introduction...................................................5 1.1. Policy Management Conceptual Model........................6 1.2. Purpose and Relation to Other Policy Work.................6 1.3. Typical Examples of Policy Usage..........................7 2. Approach.......................................................7 2.1. Common Needs Of DiffServ and IntServ......................7 2.2. Specific Needs Of DiffServ................................8 2.3. Specific Needs Of IntServ.................................9 3. Methodology....................................................9 3.1. Level of Abstraction for Expressing QoS Policies..........9 3.2. Specifying Policy Parameters.............................11 3.3. Specifying Policy Services...............................12 3.4. Level of Abstraction for Defining QoS Attributes and Classes.......................................................12 3.5. Characterization of QoS Attributes.......................13 3.6. Identifying Common Shared Policies.......................14 3.7. QoS Information Model Derivation.........................15 3.8. Attribute Representation.................................16 3.9. Mental Model.............................................16 3.9.1. The QoSService Class...................................17 3.9.2. The ConditioningService Class..........................18 3.9.3. QoS Statistics Classes.................................19 4. The Class Hierarchy...........................................19 4.1. Difference Between Inheritance and Relationship Associations..................................................19 4.1.1. Associations...........................................19 4.1.2. Aggregations...........................................20 4.2. The Structure of the Class Hierarchy.....................21 4.2.1. The Class Hierarchy for Modeling State Information.....21 4.2.2. The Class Hierarchy for Modeling Configuration Information...................................................24 4.3. Class Definitions for the State Portion of the Model.....24 4.3.1. The Class ManagedElement...............................25 4.3.2. The Class ManagedSystemElement.........................25 4.3.3. The Class LogicalElement...............................25 4.3.4. The Class Service......................................25 4.3.5. The Class NetworkService...............................25 4.3.6. The Class ForwardingService............................26 4.3.7. The Class ConditioningService..........................26 4.3.8. The Class ClassifierService............................27 4.3.9. The Class MeterService.................................28 4.3.10. The Class AverageRateMeter............................29 4.3.11. The Class EWMAMeter...................................30 4.3.12. The Class TokenBucketMeter............................31 4.3.13. The Class MarkerService...............................32 4.3.14. The Class DropperService..............................33 4.3.15. The Class REDDropperService...........................35 4.3.16. The Class WeightedREDDropperService...................36 4.3.17. The Class QueuingService..............................37 4.3.18. The Class PacketSchedulingService.....................38 Strassner, et al. Expires: Jul 2000 + 6 months [Page 3] Internet Draft QoS Device Info Model July 2000 4.3.19. The Class PrioritySchedulingService...................39 4.3.20. The Class PriorityBandwidthSchedulingService..........40 4.3.21. The Class BandwidthSchedulingService..................40 4.3.22. The Class RoundRobinPacketSchedulingService...........41 4.3.23. The Class WeightedRoundRobinPacketSchedulingService...42 4.3.24. The Class QoSService..................................42 4.3.25. The Class DiffServService.............................43 4.3.26. The Class AFService...................................44 4.3.27. The Class EFService...................................45 4.3.28. The Class PrecedenceService...........................45 4.3.29. The Class 8021PService................................46 4.3.30. The Class FilterEntryBase.............................47 4.3.31. The Class FilterEntry.................................47 4.3.32. The Class FilterList..................................48 4.3.33. The Class ServiceAccessPoint..........................49 4.3.34. The Class ProtocolEndpoint............................49 4.3.35. The Class Collection..................................49 4.3.36. The Class CollectionOfMSEs............................49 4.3.37. The Class BufferPool..................................49 4.4. Relationships Defined in the State Portion of the Model..51 4.4.1. The Association Dependency.............................51 4.4.2. The Association ServiceSAPDependency...................51 4.4.3. The Association ConditioningServiceOnEndpoint..........51 4.4.4. The Association ServiceServiceDependency...............52 4.4.5. The Association QueueHierarchy.........................53 4.4.6. The Association SchedulerUsed..........................54 4.4.7. The Association AFRelatedServices......................54 4.4.8. The Association NextService............................55 4.4.9. The Association NextServiceAfterMeter..................56 4.4.10. The Aggregation Component.............................57 4.4.11. The Aggregation ServiceComponent......................57 4.4.12. The Aggregation QoSSubService.........................57 4.4.13. The Aggregation QoSConditioningSubService.............58 4.4.14. The Aggregation MemberOfCollection....................59 4.4.15. The Aggregation CollectedBufferPool...................59 4.4.16. The Aggregation EntriesInFilterList...................60 5. Intellectual Property.........................................60 6. Acknowledgements..............................................61 7. Security Considerations.......................................61 8. References....................................................61 9. Authors' Addresses............................................63 10. Full Copyright Statement.....................................63 Strassner, et al. Expires: Jul 2000 + 6 months [Page 4] Internet Draft QoS Device Info Model July 2000 1. Introduction The purpose of this draft is to define an information model that describes the QoS mechanisms inherent in different network devices. 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]). The next version of this draft will also 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 (e.g., 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 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 enables a common set of attributes to be defined that can be used to model Differentiated Services QoS. (Integrated Services will be modeled in the next release of this Draft.) Vendors can then map these attributes, either directly or using a proxy agent like a PIB, to their own device-specific implementations. This draft explicitly separates the concepts of configuration and state. Configuration attributes are used to describe the desired state of the device, whereas state attributes reflect the current operation of the device. Both state as well as configuration attributes are necessary in order to model and manage QoS at the device level. Although configuration is discussed, the draft only models state attributes at this time. Configuration will be added in a future draft. The design of the class and relationship hierarchies described in this draft is influenced from the DMTF Network information model [CIM]. It is specifically 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 Strassner, et al. Expires: Jul 2000 + 6 months [Page 5] Internet Draft QoS Device Info Model July 2000 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 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 principle components, operands and operators. Operands can be constants or variables. A policy can not be constructed without specifying the operands to be examined, the operands to be changed, and how they should be bound together. 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. These concepts are defined in this draft and 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.) as well as assignments. Together, operators and operands can express a variety of conditions and actions, such as: If Bob is an Engineer... If the source IP address is in the Marketing Subnet... Set Joe's IP address to 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 attributes (operands) for use in policies. 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., router or switch) that is independent of any specific type of network device. This enables traffic to be Strassner, et al. Expires: Jul 2000 + 6 months [Page 6] Internet Draft QoS Device Info Model July 2000 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 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 Using this approach to representing policies, all the semantics of the policy are preserved. 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 version of this draft focuses on the specification of QoS attributes and classes for the policy management of Differentiated Services. However, the framework defined by the structure of the classes defined in this document has been designed with the needs of IntServ in mind. 2.1. Common Needs Of DiffServ and IntServ First, let us consider IntServ. IntServ has two principle 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, Strassner, et al. Expires: Jul 2000 + 6 months [Page 7] Internet Draft QoS Device Info Model July 2000 manages bandwidth, outsources decision making to policy servers, and interacts with the Routing Table manager. We will take RSVP into consideration 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. 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 policy construction in general. The focus in this iteration of the draft is on QoS as applied to 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 performs classification based solely on the DSCP field, whereas IntServ examines a subset of a standard flow's addressing 5-tuple. However, there are special cases in DiffServ where the addressing 5-tuple (or other parameters) can be examined. Most notably, this can occur at the boundary between a DS domain and a non-DS domain. However, most routers in a DiffServ domain will only need to classify based on the DSCP field. The second difference between IntServ and DiffServ is that the signaling protocol used in IntServ (e.g., RSVP) affects the 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 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], the edge of the network is used to 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). The PHB is defined by a DiffServ Code Point (DSCP). The DSCP is part of the IP header of each Strassner, et al. Expires: Jul 2000 + 6 months [Page 8] Internet Draft QoS Device Info Model July 2000 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 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 DiffServ class (or queue). 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. This draft will initially focus on the core of the DiffServ network. However, it is expected that as the DiffServ standards evolve to better define the semantics of edge devices, these attributes will also be added to the QoS schema presented in this document. 2.3. Specific Needs Of IntServ This first iteration of this document will focus exclusively on the forwarding aspects of network QoS. Therefore, while the forwarding aspects of IntServ will be considered, the management of IntServ will not be considered. This will be addressed in a future iteration of this draft. 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 define the QoS mechanisms used to condition traffic; [QOSPIM] is used to define policies to control the QoS mechanisms defined in this draft. However, there are some very basic issues that 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 Strassner, et al. Expires: Jul 2000 + 6 months [Page 9] Internet Draft QoS Device Info Model July 2000 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 | general 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, 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. 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 different 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 (and hence many different mechanisms) need to be Strassner, et al. Expires: Jul 2000 + 6 months [Page 10] Internet Draft QoS Device Info Model July 2000 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 policies. QoS mechanisms are modeled in sufficient detail as 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. This model also contains hooks to enable it to be combined with the QoS policy information model as described in [QOSPIM]. 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. Lastly, standardizing all of these potential implementation alternatives would be a never-ending task as new implementations appear on the market. Similarly, 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 portray a set of services that are related to each other. In the latter case, these may have different conditioning characteristics. This draft defines a set of parameters that are fit into a canonical model for modeling the elements in the forwarding path of a device. By defining such a model in a device-independent way, the needed parameters can be appropriately abstracted. Strassner, et al. Expires: Jul 2000 + 6 months [Page 11] Internet Draft QoS Device Info Model July 2000 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 the 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: - a flexible way to describe a service - must be able to group different services that may use different technologies (e.g., DiffServ and 802.1P) together - must be able to define a set of sub-services that together make up a higher-level service - must be able to associate a service and the set of QoS mechanisms that are used to condition that service - 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 abstract concepts like "Gold Service" and bind them to a specific set of QoS mechanisms that are used to implement the conditioning required by Gold Service. Furthermore, this draft defines the concept of "sub-services" to enable Gold Service to be defined as a single service or 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 will standardize a set of classes and attributes that are needed to support policies that configure device QoS mechanisms. This iteration of this draft concentrates on the representation of DiffServ services; the next iteration will include IntServ services. The classes and attributes in this draft are intended to be used in conjunction with the QoS policy classes and attributes defined in [QOSPIM]. For example, to preserve the delay characteristics committed to the end-user, a network administrator may wish to create policies that monitor the queue depths in a device and Strassner, et al. Expires: Jul 2000 + 6 months [Page 12] Internet Draft QoS Device Info Model July 2000 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: - Modeling of a generic network service that has QoS capabilities - Modeling of how DiffServ traffic conditioning is defined - 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 the various components that are used to condition DiffServ traffic in a canonical form, such that standard as well as custom DiffServ services may be described. It further generalizes this such that other technologies, such as IntServ, may use the same set of conditioning primitives. Statistics will be added in the next release of this draft. 3.5. Characterization of QoS Attributes The QoS attributes and container 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 the 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. This includes the current ACTUAL value of these configuration attributes in devices, as well as attributes that represent dynamic state Strassner, et al. Expires: Jul 2000 + 6 months [Page 13] Internet Draft QoS Device Info Model July 2000 (queue depths, excess capacity consumption, loss rates, and so forth). These two types of attributes must be modeled using a common information model in order for them to be able to be used together. This draft makes explicit the common information model for modeling state as well as configuration attributes for network 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 are defined in a future release of this draft can be represented and applied to either the same set of devices or 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 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 are exactly the settings that will be configured. Thus, the definition of these 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 relates one schema to the other. 3.6. Identifying Common Shared Policies Another issue that arises is how to distinguish policies for individual devices or even components of a device from policies that apply to a set of devices. These contextual issues depend on more than just the policy schema in order for them to function properly. Hence, ongoing efforts to define devices, services, users, groups, and collections of these objects are all relevant to the proper construction of a policy model. Context is a key aspect of policies that still requires a great deal more work. The next iteration of this draft will include some preliminary results from these modeling efforts. This will focus on using the concepts in this draft, the concepts in [QOSPIM] and some new concepts, to establish a better definition of the context in which a policy is operating. Strassner, et al. Expires: Jul 2000 + 6 months [Page 14] Internet Draft QoS Device Info Model July 2000 3.7. QoS Information Model Derivation The question of context also begs 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. That is not completely accurate, and leads to confusion. QoS is a set of services that can be controlled using policy. These services are represented as device mechanisms. Not all mechanisms are always applicable for building a given service, and so this is further abstracted by referring to the QoS capabilities of a device. However, a key point 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 all devices are indeed not 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 device to queue certain traffic, and a device- specific policy can be used to implement the queuing of 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 largely require different mechanisms than are used by QoS, even though they are both implemented in the same device. Thus, the similarity between QoS and other services is not so much that they contain a few common mechanisms. Rather, they model how a device implements that service. As such, the modeling of QoS should be part of a networking device schema rather than a policy schema. This enables 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 that can 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 Strassner, et al. Expires: Jul 2000 + 6 months [Page 15] Internet Draft QoS Device Info Model July 2000 tightly integrated in order to enable policy to control QoS services. 3.8. 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 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 alternatives to address this problem: o Multiple attributes can be defined to express the same value in various forms. This idea has been rejected because of the likelihood of inconsistencies between the attributes, along with 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.9. 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 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 between the DiffServ Conceptual Model, the DiffServ Strassner, et al. Expires: Jul 2000 + 6 months [Page 16] Internet Draft QoS Device Info Model July 2000 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. 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.9.1. The QoSService Class The first of these classes, 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 vs. 802.1P) as well as two relationships to the second fundamental class, ConditioningService. This set of subclasses is conceptualized as a set of coordinated, cooperating sub-services. The QoS services can be related to each other or 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. This set of sub-services derive from the ConditioningService class, and are related to the QoSService class via the aggregation QoSConditioningSubServices (see section 4 for class and relationship definitions). This document, in its current form, identifies three subclasses of QoS services: 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, each mechanism can be inter-related since they all derive from a common base class, QoSService. These concepts are depicted in Figure 2. Strassner, et al. Expires: Jul 2000 + 6 months [Page 17] Internet Draft QoS Device Info Model July 2000 /\______ 0..1 \/ | +--------------+ | QoSSubService +---------------+ | |0..n | | | | QoSService |----- | Conditioning | | | | Service | | | | | | |0..1 0..n | | | | /\______________________| | | | \/ QoSConditioning | | +--------------+ SubService +---------------+ Figure 2. QoSService and its associations 3.9.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 from an ingress to an egress interface. This is done using a set of classes and relationships. A single base class, ConditioningService, represents the superclass for a set of mechanisms that condition traffic. Its subclasses define device-independent conditioning primitives (including classifiers, meters, markers, droppers, and queues) that together implement the conditioning of traffic. This model abstracts these services into a common set of modular building blocks that can be used, regardless of device implementation, to model the forwarding decisions internal to the 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: - all types of ConditioningServices may not be required - multiple instances of the same mechanism may be required - no set order of application of each ConditioningService exists Therefore, this model does not dictate ordering, or a first or last ConditioningService to be applied. Instead, this model ties together the various ConditioningServices that can be used using the NextService association (see Section 4). And, it allows the special case of ingress and egress conditioning to be described via a separate association, called ConditioningServiceOnEndpoint (see section 4). These concepts are depicted in Figure 3. Strassner, et al. Expires: Jul 2000 + 6 months [Page 18] Internet Draft QoS Device Info Model July 2000 +-------------------+ | |0..n |ConditioningService|--------- | |0..n | NextService | |--------- | | 0..n | |0..1 ConditioningService ----| |---------------- OnEndpoint | +-------------------+ | | | |NextServiceAfterMeter | | |0..1 |0..n +---------+ +------------------+ -----| Meter | | ProtocolEndpoint | +---------+ +------------------+ Figure 3. ConditioningService and its associations 3.9.3. QoS Statistics Classes Various statistics classes were proposed in the previous iteration of this draft. Such statistics are necessary to properly instrument QoS services. However, since the core of this draft has been reworked, the previous statistics classes did not correspond and were removed. The next iteration of this draft will add these classes back into the draft. 4. The Class Hierarchy The following sections describe the class hierarchy of the information model for modeling QoS capabilities at the device level. 4.1. Difference Between Inheritance and Relationship Associations This draft defines two different sets of associations - inheritance and class relationships (such as dependencies and aggregations). Inheritance hierarchies are "the mechanism by which more-specific elements incorporate the structure and behavior of more-general elements." [UMLUG] The next two sections describe the class relationships that are used in this draft and model. 4.1.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 Strassner, et al. Expires: Jul 2000 + 6 months [Page 19] Internet Draft QoS Device Info Model July 2000 object-oriented abilities 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. This has proven to be a very useful abstraction, and will be used in this document as well. It is important to note that associations form a hierarchy that is separate from the inheritance hierarchy. Although associations are inherently 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 higher than binary are rarely used because of their greatly increased complexity and lack of generality. 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 interface of the classes that it is connecting. 4.1.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. "Whole-part" aggregations have some very interesting properties: - cascaded deletion (if you delete the aggregate, you delete all of its constituent components) - 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) - anti-symmetricity (e.g., if Object A is-a-part-of Object B, then Object B can not also be a-part-of Object A) Aggregation is used to represent the physical and/or logical grouping of related objects. Strassner, et al. Expires: Jul 2000 + 6 months [Page 20] Internet Draft QoS Device Info Model July 2000 4.2. The Structure of the Class Hierarchy The following sections discuss the class hierarchies that will be used to model the state of QoS devices and services. A later release will include configuration hierarchies. This model is influenced by [CIM], and is compatible with the Directory Enabled Networks (DEN) effort. 4.2.1. The Class Hierarchy for Modeling State Information The structure of the Class Hierarchy for managing the state of Differentiated and Integrated Services is shown in Figure 4. In this figure, the following definitions apply: - CIMCORE: a class that is defined in the CIM Core Model - CIMNET: a class that is defined in the CIM Network Model All of the remaining classes are defined in this document. Please refer to [CIM] for the definitions of the classes in [CIMCORE] and [CIMNET]. Strassner, et al. Expires: Jul 2000 + 6 months [Page 21] Internet Draft QoS Device Info Model July 2000 +--ManagedElement (defined in [CIMCORE]) | +--ManagedSystemElement (defined in [CIMCORE]) | | | +--LogicalElement (defined in [CIMCORE]) | | | | | +--Service (defined in [CIMCORE]) | | | | | | | +--NetworkService (defined in [CIMNET]) | | | | | | | | | +--ForwardingService (defined in [CIMNET]) | | | | | | | | | | | +--ConditioningService | | | | | | | | | | | | | +--ClassifierService | | | | | | | | | | | | | +--MeterService | | | | | | | | | | | | | | | +--AverageRateMeter | | | | | | | | | | | | | | | +--EWMAMeter | | | | | | | | | | | | | | | +--TokenBucketMeter | | | | | | | | | | | | | +--MarkerService | | | | | | | | | | | | | +--DropperService | | | | | | | | | | | | | | | +--RedDropper | | | | | | | | | | | | | | | | | +--WeightedRedDropper | | | | | | | | | | | | | +--QueuingService | | | | | | | | | | | +--PacketSchedulingService | | | | | | | | | | | | | +--PrioritySchedulingService | | | | | | | | | | | | | | | +--PriorityBandwidth | | | | | | | SchedulingService | | | | | | | | | | | | | +--BandwidthSchedulingService | | | | | | | | | | | | | +--RoundRobinPacketSchedulingService | | | | | | | | | | | | | | | +--WeightedRoundRobinPacket SchedulingService (continued on following page) Strassner, et al. Expires: Jul 2000 + 6 months [Page 22] Internet Draft QoS Device Info Model July 2000 (continued from previous page, first four elements are repeated for convenience) +--ManagedElement (defined in [CIMCORE]) | +--ManagedSystemElement (defined in [CIMCORE]) | | | +--LogicalElement (defined in [CIMCORE]) | | | | | +--Service (defined in [CIMCORE]) | | | | | | | +--NetworkService (defined in [CIMNET]) | | | | | | | | | +--ForwardingService (defined in [CIMNET]) | | | | | | | | | | +--QoSService | | | | | | | | | | | +--DiffServService | | | | | | | | | | | | | +--AFService | | | | | | | | | | | | | +--EFService | | | | | | | | | | | +--PrecedenceService | | | | | | | | | | | +--8021PService | | | | | +--FilterEntryBase (defined in [CIMNET]) | | | | | | | +--FilterEntry (defined in [CIMNET]) | | | | | +--FilterList (defined in [CIMNET]) | | | | | +--ServiceAccessPoint (defined in [CIMCORE]) | | | | | | | +--ProtocolEndpoint (defined in [CIMNET]) | +--Collection (defined in [CIMCORE]) | | | +--CollectionOfMSEs (defined in [CIMCORE]) | | | | | +--BufferPool Figure 4. Inheritance Class Hierarchy The set of associations and aggregations defined in this draft are shown in Figure 5. Strassner, et al. Expires: Jul 2000 + 6 months [Page 23] Internet Draft QoS Device Info Model July 2000 +--Dependency | | | +--ServiceSAPDependency | | | | | +--ConditioningServiceOnEndpoint | | | | +--ServiceServiceDependency | | | | | +--QueueHierarchy | | | | | +--SchedulerUsed | | | | +--QueueAllocation | | | +--ClassifierFilterSet | +--AFRelatedServices | +--NextService | | | +--NextServiceAfterMeter | +--MemberOfCollection | | | +--CollectedBufferPool | +--Component | | | +--ServiceComponent | | | | | +--QoSSubService | | | | | +--QoSConditioningSubService | | | +--EntriesInFilterList Figure 5. Relationship Class Hierarchy 4.2.2. The Class Hierarchy for Modeling Configuration Information The structure of the class hierarchy for managing the configuration of Differentiated and Integrated Services will be presented in the next iteration of this draft. This is due to the above hierarchy being changed significantly to reflect participant feedback. 4.3. Class Definitions for the State Portion of the Model This section will define the classes and attributes that make up the Information Model for describing the QoS-related functionality of network devices. This information is derived from the CIM Network Model [CIM]. Only new classes that are Strassner, et al. Expires: Jul 2000 + 6 months [Page 24] Internet Draft QoS Device Info Model July 2000 presented in this draft will be defined; however, all existing Network Model classes will be described briefly. The reader is encouraged to look at [CIM] for further information. Associations and aggregations will be defined in Section 4.3. 4.3.1. The Class ManagedElement This is an abstract class that is defined in the Core Model of CIM. It is the root of the entire CIM inheritance hierarchy and exists as a referenced class in some generic associations, such as Dependency and MemberOfCollection. ManagedElement's properties are Caption and Description. Both are free-form strings to describe an instantiated object. Please refer to [CIM] for the full definition of this class. 4.3.2. The Class ManagedSystemElement This is an abstract class that is defined in the Core Model of CIM. It is the base class of the System, Physical, and Logical Element class hierarchies. 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). Please refer to [CIM] for the full definition of this class. 4.3.3. The Class LogicalElement This is an abstract class that is defined in the Core Model of CIM. It is a subclass of the ManagedSystemElement class, and is the base class for all components of a managed System, such as Files, Processes, or system capabilities in the form of Logical Devices and Services. Please refer to [CIM] for the full definition of this class. 4.3.4. The Class Service This is an abstract class that is defined in the Core Model of CIM. It is a subclass of the LogicalElement class, and is the base class for all objects which provide a "service" or functionality in a System. Note that a Service is a general- purpose object that is used to configure and manage the implementation of functionality. Please refer to [CIM] for the full definition of this class. 4.3.5. The Class NetworkService This is an abstract class that is defined in the Network Common Model of CIM. It is a subclass of the Service class, and is the base class rooting the network service hierarchy. Network services represent generic functions that are available from the network, and that condition and/or modify one or more parameters Strassner, et al. Expires: Jul 2000 + 6 months [Page 25] Internet Draft QoS Device Info Model July 2000 of the traffic being sent, such as fields in a packet's header. Please refer to [CIM] for the full definition of this class. 4.3.6. The Class ForwardingService This is a concrete class that is defined in the Network Common 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 discarding it or sending it via other communication sources. The properties of ForwardingService are ProtocolType and OtherProtocolType - describing the type of protocol being forwarded. Please refer to [CIM] for the full definition of this class. 4.3.7. The Class ConditioningService This class is a specialization 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 type of conditioning that is done. Five fundamental types of functions are defined in this draft. They are the services performed by a classifier, meter, marker, dropper, and queue. Note that other, more sophisticated, types of conditioning may be defined in future iterations. Two associations of ConditioningService 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. NextService indicates the subsequent conditioning service(s) for different traffic streams. The class definition is as follows: NAME ConditioningService DESCRIPTION A concrete class to define how traffic will be conditioned in the data forwarding path of a network device. DERIVED FROM ForwardingService TYPE Structural PROPERTIES Enabled 4.3.7.1. The property Enabled This property is a boolean that, if TRUE, signifies that one or more conditioning functions can be performed on traffic encountered by the ConditioningService. Strassner, et al. Expires: Jul 2000 + 6 months [Page 26] Internet Draft QoS Device Info Model July 2000 4.3.8. The Class ClassifierService This is a new concrete class that is defined in this model. The concept of a Classifier is defined in [DSMODEL]. It represents a logical entity in the data forwarding path of a device, that takes a single input stream and sorts 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 other attributes associated with the packet). Each output stream is the result of matching a particular filter (or not matching any filter). This version of this model does not generalize the representation of a classifier. Rather, it seeks to portray a classifier as defined by [DSMODEL]. Thus, the principal components of a classifier are its ability to use filters. The association, ClassifierFilterSet, conveys this basic semantic. A Classifier is modeled as a ConditioningService so that it can be aggregated into a QoSService (using the QoSConditioningSubService association), and can use the NextService association to describe 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. DERIVED FROM ConditioningService TYPE Structural PROPERTIES ClassifierType, OtherClassifierType, HaveClassifiedPackets 4.3.8.1. The Property ClassifierType This is an enumerated 16-bit unsigned integer that is used to define the specific type of classifier of this instance. The following types of classifiers are defined in this draft (please see [DSMODEL] for a description of each one): 1 - Other 2 - Behavior Aggregate 3 - IPv4 Multi-Field-5 4 - IPv6 Multi-Field-5 5 - IPv4 Multi-Field-6 6 - IPv6 Multi-Field-6 7 - 802 MAC 8 - IEEE Priority 9 - IEEE VLAN Strassner, et al. Expires: Jul 2000 + 6 months [Page 27] Internet Draft QoS Device Info Model July 2000 10 - Free-form Here, Multi-Field-5 defines a filter to match on source and destination IP address, source and destination port, and IP Protocol. Multi-Field-6 is the same, except that the DSCP value is also matched. 4.3.8.2. The Property OtherClassifierType This is a string attribute that defines a vendor-specific description of the type of classifier. It is used when the value of the ClassifierType attribute of this class is equal to 1. 4.3.8.3. The Property HaveClassifiedPackets This is a Boolean attribute that, if TRUE, means that this Classifier has already processed at least one packet. 4.3.9. The Class MeterService This is a new concrete class, defined in this model. 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. Non-conforming packets 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 subclasses share. It is modeled as a ConditioningService so that it can be aggregated into a QoSService (using the QoSConditioningSubService association) to describe that its functionality underlies that QoS service. Also, it uses a subclass of the NextService association to describe 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 Structural PROPERTIES MeterType, OtherMeterType, ConformanceLevels Strassner, et al. Expires: Jul 2000 + 6 months [Page 28] Internet Draft QoS Device Info Model July 2000 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 assumed that not all MeterServices will require a subclass to define them. Therefore, MeterService will be instantiated directly and the Type property is needed. 4.3.9.1. The Property MeterType This attribute is an enumerated 16-bit unsigned integer that is used to specify the particular type of meter that is being used. Defined values of the enumerations are: 1 - Other 2 - Average Rate Meter 3 - Exponentially Weighted Moving Average Meter 4 - TokenBucketMeter 4.3.9.2. The Property OtherMeterType This is a string attribute that defines a vendor-specific description of the type of meter. It is used when the value of the MeterType attribute of this class is equal to 1. 4.3.9.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" or "out of profile" metering is supported, ConformanceLevels is set to 2. 4.3.10. The Class AverageRateMeter This is a new concrete class, defined in this model. It is a subclass of MeterService and describes 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 describing 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 or not. DERIVED FROM MeterService Strassner, et al. Expires: Jul 2000 + 6 months [Page 29] Internet Draft QoS Device Info Model July 2000 TYPE Structural PROPERTIES AverageRate, DeltaInterval 4.3.10.1. The Property AverageRate This is a 32-bit real number that defines the rate that is used to determine whether admitted packets are in conformance or not. The value is specified in kilobits per second. 4.3.10.2. The Property DeltaInterval This is a 32-bit real number that defines the time period over which the average measurement should be taken. The value is specified in microseconds. 4.3.11. The Class EWMAMeter This is a new concrete class, defined in this model. It is a subclass of the MeterService class, and represents an exponentially weighted moving average meter. This meter is a simple IIR 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 describing admitted traffic as either conforming or non- conforming, depending on whether the arrival of a packet in a small fixed sampling interval causes the average arrival rate to exceed a pre-determined value or not. DERIVED FROM MeterService TYPE Structural PROPERTIES AverageRate, DeltaInterval, Gain 4.3.11.1. The Property AverageRate This attribute is a 32-bit real number 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.3.11.2. The Property DeltaInterval This attribute is a 32-bit real number that defines the sampling interval used to measure the arrival rate in bytes. The Strassner, et al. Expires: Jul 2000 + 6 months [Page 30] Internet Draft QoS Device Info Model July 2000 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.3.11.3. The Property Gain This attribute is a 32-bit real number that defines the time constant (e.g., frequency response) of what is essentially a simple IIR low-pass filter. 4.3.12. The Class TokenBucketMeter This is a new concrete class that is defined in this model. 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. This class also defines an excess burst size, which enables the meter to have three conformance levels (basically, "conforming", "partially conforming", and "non-conforming"). The difference is that packets that exceed the excess burst size are deemed non- conforming, while packets that exceed the smaller BurstSize but are less than the ExcessBurst size are deemed partially conforming. Operation of these meters is described in [DSMODEL]. The class definition is as follows: NAME TokenBucketMeter DESCRIPTION A concrete class describing admitted traffic with respect to a token bucket. Either two or three levels of Conformance can be defined. DERIVED FROM MeterService TYPE Structural PROPERTIES AverageRate, PeakRate, BurstSize, ExcessBurstSize 4.3.12.1. The Property AverageRate This attribute is a 32-bit real number that is used to define the committed rate of the meter. The value is specified in kilobits per second. Strassner, et al. Expires: Jul 2000 + 6 months [Page 31] Internet Draft QoS Device Info Model July 2000 4.3.12.2. The Property PeakRate This attribute is a 32-bit real number that is used to define the peak rate of the meter. The value is specified in kilobits per second. 4.3.12.3. The Property BurstSize This attribute is a 32-bit real number that is used to define the maximum number of tokens available for the committed rate (specified by the AverageRate property). The value is specified in kilobytes. 4.3.12.4. The Property ExcessBurstSize This attribute is a 32-bit real number that is used to define the maximum number of tokens available for the peak rate (specified by the PeakRate property). The value is specified in kilobytes. 4.3.13. The Class MarkerService This is a new concrete class, defined in this model. It describes the marking or re-marking (e.g., setting or resetting of a particular field in a packet header) of network traffic. Markers may act either on unmarked packets or re-mark previously marked ones. Markers are usually invoked as a result of a preceding classifier match. Operation of various types of markers is described in [DSMODEL]. MarkerService is modeled as a ConditioningService so that it can be aggregated into a QoSService (using the QoSConditioningSubService association) to describe that its functionality underlies that QoS service. Also, it uses the NextService association to describe the subsequent ConditioningServices after marking. The class definition is as follows: NAME MarkerService DESCRIPTION A concrete class defining the value of a field in a packet that is "marked" in order to control the conditioning that the packet receives. DERIVED FROM ConditioningService TYPE Structural PROPERTIES CanRemark, RemarkType, OtherRemarkType, RemarkValue 4.3.13.1. The Property CanRemark This is a boolean attribute that, when TRUE, signifies that this Marker can remark the field value specified in the RemarkType Strassner, et al. Expires: Jul 2000 + 6 months [Page 32] Internet Draft QoS Device Info Model July 2000 attribute with the value specified in the RemarkValue attribute. The change will be made to unmarked packets and to remark a previously marked one. Otherwise, if FALSE and the field value is filled in, then NO remarking will be done. If FALSE, only unmarked packets will be changed. 4.3.13.2. The Property RemarkType This attribute is an enumerated 16-bit unsigned integer that defines what type of remarking will be done. Values include: 1 - Other 2 - Mark ToS Byte 3 - Mark the DSCP 4 - Mark the Priority Field 4.3.13.3. The Property OtherRemarkType This is a string attribute that defines a vendor-specific description of the type of remarking that is done. It is used when the value of the RemarkType attribute of this class is equal to 1. 4.3.13.4. The Property RemarkValue This attribute is a 16-bit unsigned integer that is the value to be applied to the field specified in the RemarkType attribute. 4.3.14. The Class DropperService This is a new concrete class, defined in this model. It represents the ability to drop network traffic or invoke another ConditioningService for further processing of the remaining traffic. 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. DropperService is modeled as a ConditioningService so that it can be aggregated into a QoSService (using the QoSConditioningSubService association) to describe that its functionality underlies that QoS service. Also, it uses the NextService association to describe the subsequent ConditioningServices for further processing of any remaining traffic. The class definition is as follows: Strassner, et al. Expires: Jul 2000 + 6 months [Page 33] Internet Draft QoS Device Info Model July 2000 NAME DropperService DESCRIPTION A concrete base class describing the common characteristics of droppers. DERIVED FROM ConditioningService TYPE Structural PROPERTIES DropperType, OtherDropperType, AlwaysDrop, DropStartMetric, DropMaintainMetric Note: The DropperType property and the DropperService subclasses provide similar information. The DropperType property is defined for query purposes and to not require a subclass for all types of DropperServices (for example, to describe a Head or Tail dropper in today's model). Therefore, DropperService can be instantiated directly and the Type property is needed. 4.3.14.1. The Property DropperType This is an enumerated 16-bit unsigned integer that defines the type of dropper. Values are: 1 - Other 2 - Head 3 - Tail 4 - RED 5 - Weighted RED 4.3.14.2. The Property OtherDropperType This string attribute is used in conjunction with the DropperType attribute. When the value of DropperType is 1 (e.g., Other), then the name of the type of dropper (for this instance) is defined in this attribute. 4.3.14.3. The Property AlwaysDrop This is a boolean attribute that, if TRUE, signifies that this Dropper will always drop incoming packets. 4.3.14.4. The Property DropStartMetric This property is an enumerated 16-bit unsigned integer that defines the metric used to trigger the start of dropping packets. This does NOT mean that all packets will be dropped; it does mean that SOME packets will start to be dropped. The number and type of packets dropped is a function of the type of algorithm used by this Dropper. Values are: 1 - Other 2 - Queue Threshold Strassner, et al. Expires: Jul 2000 + 6 months [Page 34] Internet Draft QoS Device Info Model July 2000 3 - Arrival Rate 4.3.14.5. The Property DropMaintainMetric This property is an enumerated 16-bit unsigned integer that defines the metric used to determine when ALL packets will be dropped regardless of the type of algorithm used by this Dropper. Values are: 1 - Other 2 - Queue Threshold 3 - Arrival Rate 4.3.15. The Class REDDropperService This is a new concrete class, defined in this model. It describes the ability to drop network traffic using a Random Early Detection (RED) algorithm. This algorithm is described in [RED]. REDĘs purpose is congestion avoidance (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, asking only those connections to slow down. Please see [DSMODEL] for more information about a dropper. The class definition is as follows: NAME REDDropperService DESCRIPTION A concrete class used to describe Dropping using the RED algorithm (or one of its variants). DERIVED FROM DropperService TYPE Structural PROPERTIES MinQueueThreshold, MaxQueueThreshold, StartProbability, StopProbability 4.3.15.1. The Property MinQueueThreshold This is a 32-bit real number, and is used to define the minimum queue length at which packets are subject to being dropped. 4.3.15.2. The Property MaxQueueThreshold This is a 32-bit real number, and is used to define the maximum queue length at which packets will always be dropped. 4.3.15.3. The Property StartProbability This is a 32-bit real number, and is used in conjunction with the StopProbability attribute to define the slope of the drop Strassner, et al. Expires: Jul 2000 + 6 months [Page 35] Internet Draft QoS Device Info Model July 2000 probability function. The latter 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.3.15.4. The Property StopProbability This is a 32-bit real number, and is used in conjunction with the StartProbability attribute to define the slope of the drop probability function. The latter 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.3.16. The Class WeightedREDDropperService This is a new concrete class, defined in this model. It describes the ability to drop network traffic using a Weighted Random Early Detection (WRED) algorithm. Like RED, the purpose of WRED is to avoid congestion (as opposed to managing congestion). This modification of the basic RED algorithm enables packets belonging to different traffic classes to be dropped at different queue depths. This algorithm also enables discard to be done based on different information contained in the packet header, such as IP Precedence, RSVP session parameters, or even on other factors not directly encoded in the packet header, such as the queue depth. Please see [DSMODEL] for more information about a dropper. The class definition is as follows: NAME WeightedREDDropperService DESCRIPTION A concrete class used to describe Dropping using the weighted RED algorithm. DERIVED FROM REDDropperService TYPE Structural PROPERTIES DropMetric, OtherDropMetric, Weight 4.3.16.1. The Property DropMetric This attribute is an enumerated 16-bit unsigned integer, and defines the type of metric that is used to drop traffic. Values are: 1 - Other 2 - IP Precedence 3 - DSCP Value 4 - 802.1P Priority Value 5 - RSVP Session 6 - Queue Depth Strassner, et al. Expires: Jul 2000 + 6 months [Page 36] Internet Draft QoS Device Info Model July 2000 7 - Packet Arrival Rate 4.3.16.2. The Property OtherDropMetric This string attribute is used in conjunction with the DropMetric attribute. When the value of DropMetric is 1 (e.g., Other), then the type of metric is defined in this attribute. 4.3.16.3. The Property Weight This is a 32-bit real number that representing the weighting factor used to used to determine which queues get more service. Min and max values are 0 to 100. 4.3.17. The Class QueuingService This is a new concrete class that is defined in this model. 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 describe that its functionality underlies that QoS service. Also, it uses the NextService association to describe if there are any subsequent ConditioningServices. 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 Structural PROPERTIES SmoothingWeight, TimeInterval, GiveExcessCapacity 4.3.17.1. The Property SmoothingWeight This attribute is a 32-bit real number, and defines the degree to which each actual queue depth influences the averaged (smoothed) queue depth used for determining long-term congestion in RED-like droppers. This attribute is specified as the percentage/weight that each calculation of averaged queue depth influences the new value of average depth. Min and max values are 0 to 100. Strassner, et al. Expires: Jul 2000 + 6 months [Page 37] Internet Draft QoS Device Info Model July 2000 4.3.17.2. The Property TimeInterval This attribute is a 32-bit unsigned integer, and defines the number of nano-seconds between each calculation of average queue depth. When this attribute is not specified, it implies that the calculation is performed every time a packet departs from the queue under normal operating conditions. In other words, if the queue is serviced intermittently, the calculations will be performed logically to simulate a consistent queue servicing interval. 4.3.17.3. The Property GiveExcessCapacity This property is a boolean attribute that, if TRUE, enables the queue to be made available to other queue/scheduler instances. When true, the queue can be used to hold packets from other traffic classes than normally serviced. For example, assume that queues for Gold, Silver and Bronze traffic classes are defined. Further assume that the Silver queue is full and the others are empty. If this boolean is set for the Gold and Bronze queues, their capacity can be used to hold Silver traffic, as opposed to dropping it. 4.3.18. The Class PacketSchedulingService This is a new concrete class that is defined in this model. It represents a scheduling service, which is a process that determines whether 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 backplanes. 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 queue that it is servicing. One can describe that different schedulers support different queues, or that a scheduler supports several queues. Please see [DSMODEL] for more information about a scheduler. PacketSchedulingService is modeled as a sibling service to ConditioningService. Both are derived from a common root, ForwardingService. The class definition is as follows: NAME PacketSchedulingService DESCRIPTION A concrete class used to determine if an arriving packet should be stored in a queue or not. DERIVED FROM ForwardingService TYPE Structural Strassner, et al. Expires: Jul 2000 + 6 months [Page 38] Internet Draft QoS Device Info Model July 2000 PROPERTIES SchedulerType, OtherSchedulerType Note: The SchedulerType property and the SchedulerService subclasses provide similar information. The SchedulerType property is defined for query purposes and to not require a subclass for all types of SchedulerServices (for example, to describe a FIFO scheduler in today's model). Therefore, SchedulerService can be instantiated directly and the Type property is needed. 4.3.18.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 - Priority Bandwidth 6 - Round Robin Packet 7 - Weighted Round Robin Packet 4.3.18.2. The Property OtherSchedulerType This attribute is used in conjunction with the SchedulerType attribute. When the value of SchedulerType is 1 (e.g., Other), then the type of scheduler is defined in this attribute. 4.3.19. The Class PrioritySchedulingService This is a new concrete class, defined in this model. It represents a simple priority scheduler, which is a process that schedules taking packets from different priority queues. Please see [DSMODEL] for more information about a scheduler. The class definition is as follows: NAME PrioritySchedulingService DESCRIPTION A concrete class used to represent a simple priority scheduling service. DERIVED FROM PacketSchedulingService TYPE Structural PROPERTIES Priority 4.3.19.1. The Property Priority This property is a 16-bit unsigned integer that defines the priority level of the queue that is being scheduled. Strassner, et al. Expires: Jul 2000 + 6 months [Page 39] Internet Draft QoS Device Info Model July 2000 4.3.20. The Class PriorityBandwidthSchedulingService This is a new concrete class, defined in this model. It represents a priority scheduler that is extended to specify an upper limit on the bandwidth that can be sent on the priority queue over some time interval. Please see [DSMODEL] for more information about a scheduler. The class definition is as follows: NAME PriorityBandwidthSchedulingService DESCRIPTION This class represents a priority scheduler that is extended to specify an upper limit on the bandwidth that can be sent on the priority queue over some time interval. DERIVED FROM PrioritySchedulingService TYPE Structural PROPERTIES BandwidthAllocation, BurstsAllowed, BurstAllocation 4.3.20.1. The Property BandwidthAllocation This attribute is a 32-bit unsigned integer, and defines the number of bytes that can be delivered from a queue each cycle. 4.3.20.2. The Property BurstsAllowed This is a boolean attribute which, if TRUE, signifies that a temporary or short-term allocation of additional bandwidth in addition to the amount of bandwidth allocated through the BandwidthAllocation property is allowed. 4.3.20.3. The Property BurstAllocation This attribute is a 32-bit unsigned integer, and specifies the amount of temporary or short-term bandwidth that can be allocated beyond the amount of bandwidth allocated through the BandwidthAllocation property. If the maximum actual bandwidth allocation were to be measured, it would be the sum of the BurstAllocation and the BandwidthAllocation properties. 4.3.21. The Class BandwidthSchedulingService This is a new concrete class, defined in this model. It represents a bandwidth scheduler, which is a process that reserves a portion of the bandwidth of a link for each selected traffic type. The class definition is as follows: NAME BandwidthSchedulingService Strassner, et al. Expires: Jul 2000 + 6 months [Page 40] Internet Draft QoS Device Info Model July 2000 DESCRIPTION A concrete class used to represent a simple bandwidth scheduling service. DERIVED FROM PacketSchedulingService TYPE Structural PROPERTIES BandwidthAllocation, BurstsAllowed, BurstAllocation, CanShare, WorkConserving 4.3.21.1. The Property BandwidthAllocation This attribute is a 32-bit unsigned integer, and defines the number of bytes that can be delivered from a queue each cycle. 4.3.21.2. The Property BurstsAllowed This is a boolean attribute which, if TRUE, signifies that a temporary or short-term allocation of additional bandwidth in addition to the amount of bandwidth allocated through the BandwidthAllocation property is allowed. 4.3.21.3. The Property BurstAllocation This attribute is a 32-bit unsigned integer, and specifies the amount of temporary or short-term bandwidth that can be allocated beyond the amount of bandwidth allocated through the BandwidthAllocation property. If the maximum actual bandwidth allocation were to be measured, it would be the sum of the BurstAllocation and the BandwidthAllocation properties. 4.3.21.4. The Property CanShare This is a boolean attribute that, if TRUE, enables unused bandwidth from the associated queue to be allocated to queues that need additional resources. 4.3.21.5. The Property WorkConserving This is a boolean attribute that, if TRUE, prevents the scheduler from bursting traffic from the queue to which this instance of the scheduler is associated (via SchedulerUsed). When TRUE, this attribute also prevents bandwidth from other idle queues to be consumed by the current queue, thereby preventing resource allocations above the assigned bandwidth. 4.3.22. The Class RoundRobinPacketSchedulingService This is a new concrete class, defined in this model. It represents a round robin packet scheduler, which is a process that guarantees that bandwidth will be allocated fairly at the packet level. With this type of scheduler, each queue is entitled to equal access to the output interface. Strassner, et al. Expires: Jul 2000 + 6 months [Page 41] Internet Draft QoS Device Info Model July 2000 The class definition is as follows: NAME RoundRobinPacketSchedulingService DESCRIPTION A concrete class used to represent a scheduler that fairly allocates packet transmission among its traffic classes. DERIVED FROM PacketSchedulingService TYPE Structural PROPERTIES None 4.3.23. The Class WeightedRoundRobinPacketSchedulingService This is a new concrete class, defined in this model. It represents a weighted packet scheduler, which is the same as a fair packet scheduler except that a per-traffic stream multiplier is applied to each stream. The class definition is as follows: NAME WeightedRoundRobinPacket SchedulingService DESCRIPTION A concrete class used to represent a Weighted packet scheduling service. DERIVED FROM RoundRobinPacketSchedulingService TYPE Structural PROPERTIES WeightingFactor, Priority 4.3.23.1. The Property WeightingFactor This real 32-bit attribute is used to define the weighting factor that will be used to offer some queues a higher probability of being serviced than other queues. This attribute represents this probability. 4.3.23.2. The Property Priority This 16-bit unsigned integer specifies a tie breaker in the event that two or more queues achieve an equal weighting. While this condition may not occur in some implementations of a weighted round robin scheduler, there are many implementations that require a priority to resolve it. However, in instances where this behavior is not necessary or undesirable, this attribute may be left unspecified. 4.3.24. The Class QoSService This is a new concrete class that is defined in this model. It represents the ability to conceptualize a QoS service as a set of coordinated sub-services. This enables the network administrator 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. Strassner, et al. Expires: Jul 2000 + 6 months [Page 42] Internet Draft QoS Device Info Model July 2000 This class has two main purposes. First, it serves as a common base class for defining various sub-services that are needed to build higher-level QoS services. Second, it serves as a way to consolidate 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 perform 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 are instances of the class QoSService, and each require a set of sub-services to be defined as part of their 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 Structural PROPERTIES None 4.3.25. The Class DiffServService This is a new concrete class, defined in this model. 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 specialization 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). The class definition is as follows: NAME DiffServService DESCRIPTION A concrete class used to represent a DiffServ service, or a set of DiffServ Strassner, et al. Expires: Jul 2000 + 6 months [Page 43] Internet Draft QoS Device Info Model July 2000 services. DERIVED FROM QoSService TYPE Structural PROPERTIES DSCP 4.3.25.1. The Property DSCP This attribute is an unsigned 8-bit integer. It defines the Differentiated Services Code Point used to represent various types of differentiated services, through device-specific configuration commands. 4.3.26. The Class AFService This is a new concrete class that is defined in this model. 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 (e.g., a different amount of forwarding resources, such as buffer space and bandwidth, are allocated. 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 with a lower drop precedence value by instead discarding packets with a higher drop precedence value. Note that [R2597] defines 12 DSCPs that together implement 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 a higher-level QoS services as well as to lower-level 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 TYPE Structural PROPERTIES ClassNumber, DropperNumber Strassner, et al. Expires: Jul 2000 + 6 months [Page 44] Internet Draft QoS Device Info Model July 2000 4.3.26.1. The Property ClassNumber This attribute is an 8-bit unsigned integer that defines the number of classes that this AF implementation uses. Implementations should define at least 4 classes. 4.3.26.2. The Property DropperNumber This attribute is an 8-bit unsigned integer that defines the number of drop precedences that this AF implementation uses. The number of drop precedence values are PER AF CLASS. Implementations should define at least three drop precedence values per class. 4.3.27. The Class EFService This is a new concrete class, defined in this model. 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 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. 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 Structural PROPERTIES None 4.3.28. The Class PrecedenceService This is a new concrete class that is defined in this model. It represents a specialization of the general concept of forwarding Strassner, et al. Expires: Jul 2000 + 6 months [Page 45] Internet Draft QoS Device Info Model July 2000 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. This is done by defining a sibling class, DiffServService, to represent devices that forward traffic based on the DiffServ code point. This enables the administrator to define mappings between devices that do not support DiffServ, and instead use IP Precedence, to devices that do support DiffServ, which use DSCPs. Since the PrecedenceService class is a specialization of QoSService, it can be related to higher-level QoS services using the QoSSubService association. Also, it can 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 Structural PROPERTIES PrecedenceValue 4.3.28.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, backward compatibility with the ToS byte of IPv4 traffic, and use of this attribute. 4.3.29. The Class 8021PService This is a new concrete class that is defined in this model. 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 Priority field in the 802.1P header. 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. Strassner, et al. Expires: Jul 2000 + 6 months [Page 46] Internet Draft QoS Device Info Model July 2000 Since the 8021PService class is a specialization of QoSService, it can be related to higher-level QoS services using the QoSSubService association. Also, it can 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 Structural PROPERTIES PriorityValue 4.3.29.1. The Property PriorityValue This attribute is an 8-bit unsigned integer that defines the notion of priority as specified in 802.1P implementations. 4.3.30. The Class FilterEntryBase A simplistic but accurate view of the CIM filter classes is of: - 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 that is defined in the Network Model of CIM. It is a 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.3.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 forwarding/further processing or for dropping. Please refer to [CIM] for the full definition of this class. FilterEntry's properties include: Strassner, et al. Expires: Jul 2000 + 6 months [Page 47] Internet Draft QoS Device Info Model July 2000 - 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 are defined ("IPv4", "IPX" and "IPv6"). - 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. - 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). - ActionType (an enumeration) - Specifies "Permit" or "Deny" actions for the traffic class. - DefaultFilter (a Boolean) - Defines this FilterEntry as the "default" one when aggregated in a FilterList. - TrafficClass (a string) - Specifies the label for the traffic class of a packet, when that packet is matched by the FilterEntry. Traffic class information is carried through the sequence of ConditioningServices via the NextService.TrafficClass property. 4.3.32. The Class FilterList A concrete class defined in the Network Model of CIM. It aggregates instances (of subclasses) of FilterEntryBase via the association, EntriesInFilterList. It is possible to aggregate different types of Filters into a single List - for example, aggregating packet filters (which are instances of FilterEntry) and security filters (which are being defined for the next release of the CIM Network Model). The association property, EntriesInFilterList.EntrySequence, serves to order the filter entries in the FilterList. This is very useful when algorithms such as "Match First" are used to identify traffic based on the aggregated Filters. If EntrySequence is set to 0, then all aggregated Filters should be ANDed together to define a class of traffic. Please refer to [CIM] for the full definition of the FilterList and EntriesInFilterList classes. Strassner, et al. Expires: Jul 2000 + 6 months [Page 48] Internet Draft QoS Device Info Model July 2000 4.3.33. The Class ServiceAccessPoint This is an abstract class that is defined in the Core Model of CIM. It is a subclass of the LogicalElement class, and is the base class for all objects which 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.3.34. The Class ProtocolEndpoint This is a concrete class that is defined in the Network Common Model of CIM. It subclasses 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.3.35. The Class Collection This is an abstract class that is defined in the Core Model of CIM. It is a superclass for all objects that are groupings or bags, and carry no status or "state" (the latter would be more correctly modeled as ManagedSystemElements). Please refer to [CIM] for the full definition of this class. 4.3.36. The Class CollectionOfMSEs This is an abstract class that is defined in the Core Model of CIM. It is a specialization of the Collection superclass, restricting the contents of the Collection to ManagedSystemElements. Please refer to [CIM] for the full definition of this class. 4.3.37. The Class BufferPool This is a new concrete class, defined in this model. 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 association. Note that this class is derived from CollectionOfMSEs, and not from Forwarding or ConditioningService. BufferPool is only a collection of storage, and is NOT a Service. Strassner, et al. Expires: Jul 2000 + 6 months [Page 49] Internet Draft QoS Device Info Model July 2000 The class definition is as follows: NAME BufferPool DESCRIPTION A concrete class describing the a collection of buffers. DERIVED FROM CollectionOfMSEs TYPE Structural PROPERTIES CollectionID, CreationClassName, Name, BufferSize, TotalBuffers, AvailableBuffers, SharedBuffers 4.3.37.1. The Property CollectionID CollectionID is a string property of maximum length 256 characters. It identifies the buffer pool. 4.3.37.2. The Property CreationClassName This attribute is a string property of maximum length 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. 4.3.37.3. The Property Name This attribute is a string of maximum length 256 characters. It is the common name or label by which the object is known. 4.3.37.4. The Property BufferSize This attribute is a 16-bit unsigned integer, defining the number of bytes in each buffer in the buffer pool. 4.3.37.5. The Property TotalBuffers This attribute is a 32-bit unsigned integer, defining the total number of individual buffers in the pool. 4.3.37.6. The Property AvailableBuffers This attribute is a 32-bit unsigned integer, defining 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 (containing packet data), or allocated to a Queue pending the arrival of new packet data. 4.3.37.7. The Property SharedBuffers This attribute is a 32-bit unsigned integer, and defines the number of buffers in the Pool that have been simultaneously allocated to multiple instances of QueuingService. Strassner, et al. Expires: Jul 2000 + 6 months [Page 50] Internet Draft QoS Device Info Model July 2000 4.4. Relationships Defined in the State Portion of the Model This section details the QoS device class associations, that were presented earlier and drawn in Figure 5. These relationships are defined as classes (that can have properties) in the Information Model. 4.4.1. The Association Dependency This abstract association defines two object references (named Antecedent and Dependent) that are used to 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. Please refer to [CIM] for the full definition of this class. 4.4.2. The Association ServiceSAPDependency This association defines two object references that establish a general dependency relationship between a Service object and a ServiceAccessPoint object. This relationship indicates that the referenced Service uses the ServiceAccessPoint of ANOTHER Service. The Service is the Dependent reference, relying on the ServiceAccessPoint to gain access to another Service. The association's cardinality is many to many. The association is defined in the CIM Core Model. Please refer to [CIM] for the full definition of this class. 4.4.3. The Association ConditioningServiceOnEndpoint This association is new, defined in this model. 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 latter is distinguished by the property ServiceType, which indicates whether the ConditioningService object handles incoming or out- going traffic. The ProtocolEndpoint represents whether the traffic arrives at or leave from a network device, and the ConditioningService which begins or ends the traffic conditioning process within a network device. This class is subclassed from the ServiceSapDependency association. It restricts the Antecedent to instances of the ProtocolEndpoint class (instead of the more generic Strassner, et al. Expires: Jul 2000 + 6 months [Page 51] Internet Draft QoS Device Info Model July 2000 ServiceAccessPoint class) and further restricts the cardinality of this end of the relationship to be 0-or-1 (instead of the more generic 0-or-more). It restricts the Dependent to instances of the ConditioningService class (instead of the more generic Service class) and further restricts the cardinality of this end of the relationship to be 0-or-1 (instead of the more generic 0- or-more). 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 Antecedent[ref ProtocolEndpoint[0..1]], Dependent[ref ConditioningService[0..1]], ServiceType 4.4.3.1. The Reference Antecedent This property is inherited from the ServiceSAPDependency association, and overridden for two reasons - To serve as an object reference to a ProtocolEndpoint object (instead of the more general ServiceAccessPoint object), and To update cardinality. This reference defines the ProtocolEndpoint through which traffic arrives at or leaves from a network device. 4.4.3.2. The Reference Dependent This property is inherited from the ServiceSAPDependency association, and overridden to serve as an object reference to a ConditioningService object (instead of the more general Service object) and to update cardinality. This reference indicates the ConditioningService that begins or ends the traffic conditioning processing within a network device. 4.4.3.3. The Property ServiceType This property is a 16-bit unsigned integer that indicates whether a packet is incoming (value = 1, "Ingress") or out-going (value = 2, "Egress") at the ProtocolEndpoint, relative to the ConditioningService. 4.4.4. The Association ServiceServiceDependency This association defines two object references that establish a dependency relationship between two Service objects. The particular type of dependency is described by the TypeOfDependency property; typical examples include that one Strassner, et al. Expires: Jul 2000 + 6 months [Page 52] Internet Draft QoS Device Info Model July 2000 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 CIM Core Model. Please refer to [CIM] for the full definition of this class. 4.4.5. The Association QueueHierarchy This association is new, defined in this model. It is a subclass of ServiceServiceDependency, and defines two object references that are used to establish a dependency relationship between two QueuingService objects. The class definition is as follows: NAME QueueHierarchy DESCRIPTION A generic association used to establish dependency relationships between two QueuingService objects. DERIVED FROM ServiceServiceDependency ABSTRACT False PROPERTIES Antecedent[ref QueuingService[0..1]], Dependent[ref QueuingService[0..n]] 4.4.5.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 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 defines the supporting queue through its QueuingService. This QueuingService can only support at most one higher-level QueuingService. 4.4.5.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 the more general Service object). This reference indicates the QueuingService that depends on another QueuingService. Strassner, et al. Expires: Jul 2000 + 6 months [Page 53] Internet Draft QoS Device Info Model July 2000 4.4.6. The Association SchedulerUsed This association is new, defined in this model. It is a subclass of ServiceServiceDependency, and defines two object references that establish a dependency relationship between a PacketSchedulingService and one or more QueuingService objects. The class definition is as follows: NAME SchedulerUsed DESCRIPTION A generic association used to establish dependency relationships between a specific PacketSchedulingService and one or more QueuingService objects. DERIVED FROM ServiceServiceDependency ABSTRACT False PROPERTIES Antecedent[ref PacketSchedulingServiceService[0..1]], Dependent[ref QueuingService[0..n]] 4.4.6.1. The Reference Antecedent This property is inherited from the ServiceServiceDependency association, and overridden to serve as an object reference to a PacketSchedulingService object (instead of the more general Service object). It also restricts the cardinality of this relationship to exactly 1 instance (instead of the more generic 0-or-more instances). This reference defines the PacketSchedulingService, which is used to empty the queue(s) controlled by the QueuingService. 4.4.6.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 the more general Service object). This reference indicates the queue(s) and the associated QueuingService that depends on the PacketSchedulingService. 4.4.7. The Association AFRelatedServices This association is new, defined in this model. 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: NAME AFRelatedServices DESCRIPTION An association used to establish a dependency relationship between two Strassner, et al. Expires: Jul 2000 + 6 months [Page 54] Internet Draft QoS Device Info Model July 2000 AFService objects. DERIVED FROM Nothing ABSTRACT False PROPERTIES AFLowerDropPrecedence[ref AFService[0..1]], AFHigherDropPrecedence[ref AFService[0..n]] 4.4.7.1. The Reference AFLowerDropPrecedence This property serves as an object reference to an AFService object that has the lower probability of dropping packets. 4.4.7.2. The Reference AFHigherDropPrecedence This property serves as an object reference to an AFService object that has the higher probability of dropping packets. 4.4.8. The Association NextService This association is new, defined in this model. 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 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: Jul 2000 + 6 months [Page 55] Internet Draft QoS Device Info Model July 2000 4.4.8.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.4.8.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. 4.4.8.3. The Property TrafficClass This property is a string that is used to identify different traffic flows that have been separated by the Classifier ConditioningService. This property enables a ConditioningService to forward multiple traffic flows to (for example) the same "next" ConditioningService while maintaining their traffic identity. 4.4.9. The Association NextServiceAfterMeter This association is new, defined in this model. 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 the meter. Therefore, this association also defines a new property, MeterResult, which can be used to identify which output of the meter this traffic originated from. 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: Jul 2000 + 6 months [Page 56] Internet Draft QoS Device Info Model July 2000 4.4.9.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.4.9.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 in- or out-of-profile, or partially conforming. More complicated metering can be built by either extending the enumeration or by cascading meters. The enumerated values are: "Unknown" (0), "In-profile" (1), "Partially Conforming" (2), "Out-of-profile" (3). 4.4.10. The 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 CIM Core Model. Please refer to [CIM] for the full definition of this class. 4.4.11. 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 subclassed from the more generic Component superclass to restrict the types of objects that can participate in this relationship. The association is defined in the CIM Core Model. Please refer to [CIM] for the full definition of this class. 4.4.12. The Aggregation QoSSubService This association is new, defined in this model. It is used to model a set of subordinate QoSServices that are aggregated together to form a higher-level QoSService. A QoSService is a Strassner, et al. Expires: Jul 2000 + 6 months [Page 57] Internet Draft QoS Device Info Model July 2000 specific type of Service that conceptualizes QoS functionality as a set of coordinated sub-services. This aggregation is subclassed 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 set of lower-level QoSServices that are aggregated to create/form it. DERIVED FROM ServiceComponent ABSTRACT False PROPERTIES GroupComponent[ref QoSService[0..1]], PartComponent[ref QoSService[0..n]] 4.4.12.1. The Reference GroupComponent This property is overridden in this relationship to represent an object reference to a QoSService object (instead of the more generic Service object defined in its superclass). This object represents the parent, or aggregate, object in the relationship. 4.4.12.2. The Reference PartComponent This property is overridden in this relationship to represent an object reference to a QoSService object (instead of the more generic Service object defined in its superclass). This object represents the child, or "component", object in the relationship. 4.4.13. The Aggregation QoSConditioningSubService This association is new, defined in this model. 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 a more generic Service object. The class definition for the aggregation is as follows: Strassner, et al. Expires: Jul 2000 + 6 months [Page 58] Internet Draft QoS Device Info Model July 2000 NAME QoSConditioningSubService DESCRIPTION A generic association 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.4.13.1. The Reference GroupComponent This property is overridden in this relationship to represent an object reference to a QoSService object (instead of 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). This object represents the parent, or aggregate, object in the relationship. 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.4.13.2. The Reference PartComponent This property is overridden in this relationship to represent an object reference to a ConditioningService object (instead of 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 define how traffic for a specific QoSService will be conditioned. 4.4.14. 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 association's cardinality is many to many. The association is defined in the CIM Core Model. Please refer to [CIM] for the full definition of this class. 4.4.15. The Aggregation CollectedBufferPool This relationship is used to model 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. Strassner, et al. Expires: Jul 2000 + 6 months [Page 59] Internet Draft QoS Device Info Model July 2000 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..n]], Member[ref BufferPool[0..n]] 4.4.15.1. The Reference Collection This property represents the parent, or aggregate, object in the relationship. It is a BufferPool object. 4.4.15.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.4.16. The Aggregation EntriesInFilterList This aggregation is a specialization of the Component association and is used to define a set of filter entries (subclasses of FilterEntryBase) that are aggregated by a FilterList. Cardinality is many to many. The association 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. Strassner, et al. Expires: Jul 2000 + 6 months [Page 60] Internet Draft QoS Device Info Model July 2000 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 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. 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.x. Distributed Management Task Force, Inc. The components of the CIM 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-03.txt, F. Baker, K. Chan, and A. Smith. May 2000. [DSMODEL] A Conceptual Model for DiffServ Routers. Internet Draft, draft-ietf-diffserv-model-03.txt, Y. Bernet, A. Smith, S. Blake, and D. Grossman. May 2000. Strassner, et al. Expires: Jul 2000 + 6 months [Page 61] Internet Draft QoS Device Info Model July 2000 [PCIM] Policy Core Information Model - Version 1 Specification. Internet Draft, draft-ietf-policy-core-info-model-07.txt, B. Moore, E. Ellison, J. Strassner, and A. Westerinen. July 2000. [PIB] Quality of Service Policy Information Base. Internet Draft, draft-mfine-cops-pib-02.txt, M. Fine, K. McCloughrie, J. Seligson, K. Chan, S. Hahn, and A. Smith. October 1999. [POLTERM] Policy Terminology. Internet Draft, draft-ietf-policy- terminology-00.txt, A. Westerinen, J. Schnizlein, J. Strassner, M. Scherling, B. Quinn, J. Perry, S. Herzog, A. Huynh, and M. Carlson. July 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. [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. [UMLUG] The Unified Modeling Language User Guide. G. Booch, J. Rumbaugh, and I. Jacobson. Addison-Wesley, 1999. Strassner, et al. Expires: Jul 2000 + 6 months [Page 62] Internet Draft QoS Device Info Model July 2000 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 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: Jul 2000 + 6 months [Page 63]