Policy Framework Working Group J. Strassner (Cisco) INTERNET-DRAFT W. Weiss (Lucent) March 2000 D. Durham (Intel) A. Westerinen (SNIA) Information Model for Describing Network Device QoS Mechanisms 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. Abstract The purpose of this draft is to define an information model that describes the QoS capabilities of different devices. These capabilities define the attributes common to the classification, conditioning, queuing, and forwarding characteristics of network devices running Differentiated Services QoS as well as (in the future) RSVP. 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 capabilities) 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 second draft [QCAPSCH] 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 draft is similarly paired with the draft specified in [QOSSCH], which describes a mapping of the data in [QOSPIM] to a form suitable for implementation in a directory that uses (L)DAP as its access protocol. These two drafts then describe how to write QoS policy rules that can be used to store information in directories that can be used to configure device QoS mechanisms. Strassner, et. al. Expires September 2000 [Page 1 INTERNET-DRAFT QoS Device Info Model March, 2000 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, reference [5]. Table of Contents Status of this memo 1 Copyright Notice 1 Abstract 1 Definition of Key Word Usage 2 Table of Contents 2 1. Introduction 5 1.1 Policy Management Conceptual Model 6 1.2 Typical Examples of Policy Usage 7 2. Approach 8 2.1. Common Needs Of DiffServ and IntServ 8 2.2. Specific Needs Of DiffServ 9 2.3. Specific Needs Of IntServ 9 3. Methodology 10 3.1 Level of Abstraction for Expressing QoS Policies 10 3.2 Level of Abstraction for Defining QoS Attributes and Classes 12 3.3 Characterization of QoS Attributes 12 3.4 Identifying Common Shared Policies 13 3.5 QoS Information Model Derivation 13 3.6 Attribute Representation 14 3.7 Mental Model 15 4. The Class Hierarchy 16 4.1 Difference Between Inheritance and Relationship Hierarchies 16 4.1.1 Associations 16 4.1.2. Aggregations 17 4.2. The Structure of the Class Hierarchy 17 4.2.1 The Class Hierarchy for Modeling State Information 17 4.2.2 The Class Hierarchy for Modeling Configuration Information 20 4.3 Class Definitions for the State Portion of the Model 21 4.3.1 The Class ManagedSystemElement 21 4.3.2 The Class LogicalElement 21 4.3.3 The Class Service 21 4.3.4 The Class NetworkService 21 4.3.5 The Class ForwardingService 22 4.3.6 The Class TrafficConditioningBlock 22 4.3.6.1 The Attribute Enabled 22 4.3.6.2 The Attribute ID 23 Strassner, et. al. Expires September 2000 [Page 2 INTERNET-DRAFT QoS Device Info Model March, 2000 4.3.7 ClassifierService 23 4.3.7.1 The Attribute ClassifierType 23 4.3.7.2 The Attribute OtherClassifierType 24 4.3.7.3 The Attribute IsIngress 24 4.3.7.4 The Attribute Status 24 4.3.7.5 The Attribute TrafficClasses 24 4.3.8 MeterService 24 4.3.8.1 The Attribute MeterType 25 4.3.8.2 The Attribute ConformanceLevels 25 4.3.8.3 The Attribute OtherMeterConformance 25 4.3.8.4 The Attribute FailAction 26 4.3.8.5 The Attribute SucceedAction 26 4.3.9 The Class AverageRateMeter 26 4.3.9.1 The Attribute Rate 26 4.3.9.2 The Attribute Interval 26 4.3.10 The Class EWMAMeter 27 4.3.10.1 The Attribute AverageRate 27 4.3.10.2 The Attribute Delta 27 4.3.10.3 The Attribute Interval 27 4.3.10.4 The Attribute Gain 28 4.3.11 The Class TokenBucketMeter 28 4.3.11.1 The Attribute AverageRate 28 4.3.11.2 The Attribute PeakRate 29 4.3.11.3 The Attribute BurstSize 29 4.3.11.4 The Attribute ExcessBurstSize 29 4.3.12 The Class MarkerService 29 4.3.12.1 The Attribute CanRemark 29 4.3.12.2 The Attribute RemarkType 30 4.3.12.3 The Attribute RemarkValue 30 4.3.13 The Class DropperService 30 4.3.13.1 The Attribute DropperType 30 4.3.13.2 The Attribute OtherDropperType 31 4.3.13.3 The Attribute AlwaysDrop 31 4.3.13.4 MinQueueThreshold 31 4.3.13.5 MaxQueueThreshold 31 4.3.14 The Class HeadTailDropper 31 4.3.14.1 The Attribute IsTailDropper 32 4.3.15 The Class REDDropper 32 4.3.15.1 The Attribute StartProbability 32 4.3.15.2 The Attribute StopProbability 32 4.3.15.3 The Attribute StartPercent 32 4.3.15.4 The Attribute StopPercent 33 4.3.16 The Class WeightedREDDropper 33 4.3.16.1 The Attribute DropMetric 33 4.3.16.2 The Attribute OtherDropMetric 33 4.3.16.3 The Attribute Weight 34 4.3.17 The Class QueuingService 34 4.3.17.1 The Attribute SmoothingWeight 34 4.3.17.2 The Attribute Interval 34 Strassner, et. al. Expires September 2000 [Page 3 INTERNET-DRAFT QoS Device Info Model March, 2000 4.3.18 The Class BufferManagementService 35 4.3.18.1 The Attribute BufferSize 35 4.3.18.2 The Attribute TotalBuffers 35 4.3.18.3 The Attribute AvailableBuffers 35 4.3.18.4 The Attribute SharedBuffers 35 4.3.19 The Class PacketSchedulingService 36 4.3.19.1 The Attribute SchedulerType 36 4.3.19.2 The Attribute OtherSchedulerType 36 4.3.19.3 The Attribute GiveExcessCapacity 37 4.3.20 The Class PriorityScheduler 37 4.3.21 The Class PriorityBandwidthScheduler 37 4.3.21.1 The Attribute BandwidthAllocation 38 4.3.21.2 The Attribute BurstsAllowed 38 4.3.21.3 The Attribute BurstAllocation 38 4.3.22 The Class BandwidthScheduler 38 4.3.22.1 The Attribute BandwidthAllocation 38 4.3.22.2 The Attribute BurstsAllowed 39 4.3.22.3 The Attribute BurstAllocation 39 4.3.22.4 The Attribute CanShare 39 4.3.22.5 The Attribute WorkConserving 39 4.3.23 The Class RoundRobinPacketScheduler 39 4.3.24 The Class WeightedRoundRobinPacketScheduler 40 4.3.24.1 The Attribute WeightingFactor 40 4.3.24.2 The Attribute Priority 40 4.3.25 The Class QoSService 40 4.3.25.1 The Attribute AllowClassificationService 41 4.3.25.2 The Attribute AllowMarkingService 41 4.3.25.3 The Attribute AllowDroppingService 41 4.3.25.4 The Attribute AllowMeteringService 41 4.3.25.5 The Attribute AllowQueuingService 42 4.3.25.6 The Attribute AllowSchedulingService 42 4.3.25.7 The Attribute AllowSignalingService 42 4.3.26 The Class DiffService 42 4.3.26.1 The Attribute DSCP 42 4.3.27 The Class AFService 43 4.3.27.1 The Attribute ClassNumber 43 4.3.27.2 The Attribute DropperNumber 43 4.3.28 The Class EFService 43 4.3.29 The Class PrecedenceService 44 4.3.29.1 The Attribute PrecedenceValue 44 4.3.30 The Class 8021PService 45 4.3.30.1 The Attribute PriorityValue 45 4.4 Relationships Defined in the State Portion of the Model 45 4.5 Classes Defined in the Configuration Portion of the Model 46 4.6 Relationships Defined in the Configuration Portion of the Model 46 5. Mapping to Example Policies 47 6. Security Considerations 48 7. Acknowledgments 48 8. References 48 9. Author's Addresses 50 10. Full Copyright Statement 50 Strassner, et. al. Expires September 2000 [Page 4 INTERNET-DRAFT QoS Device Info Model March, 2000 1. Introduction The purpose of this draft is to define an information model that describes the QoS capabilities of different devices. These capabilities define the attributes common to the classification, conditioning, queuing, and forwarding characteristics of network devices running Differentiated Services QoS as well as (in the future) RSVP. 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 capabilities) 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 second draft [QCAPSCH] 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 draft is similarly paired with the draft specified in [QOSSCH], which describes a mapping of the data in [QOSPIM] to a form suitable for implementation in a directory that uses (L)DAP as its access protocol. These two drafts then describe how to write QoS policy rules that can be used to store information in directories that can be used 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 services as well as RSVP at the behavioral level. Vendors can then map these attributes, either directly or using a proxy agent like a PIB, to their own device-specific implementations. This draft also concentrates on separating the concepts of state and configuration. Configuration attributes are used to describe the desired state of the device, whereas state attributes reflect the current condition of the device. Both state as well as configuration attributes are necessary in order to model and manage QoS at the device level. The data in this draft is influenced from the DMTF Network information model. It is specifically not derived from the core Policy information model. There are two reasons for this. First, this draft expresses the fundamental QoS capabilities of a device. As such, this draft models the mechanisms that are controlled by policy. Hence, there is a need to separate QoS mechanisms (this draft) from their control (generic policy draft [PCIM] augmented by the QoS Policy draft [QOSPIM]). Second, this draft describes the general capabilities of a device. These capabilities can be expanded to support broader policies that can encompass not only QoS, but also security, address management, network topology management, and routing policies, to name a few. Therefore, it makes more sense to derive the attributes from an information model that is already modeling these devices and services rather than reinventing them under the umbrella of the policy information model. Strassner, et. al. Expires September 2000 [Page 5 INTERNET-DRAFT QoS Device Info Model March, 2000 Finally, this draft considers various aggregation methods for describing groups of devices and groups of interfaces that require a common configuration. This approach draws on the concepts of roles that have been discussed in the Policy Framework, DiffServ, and RAP working groups. A future iteration of this draft will expand the information model to include modeling and managing the signaling characteristics of RSVP. A separate draft ([QCAPSCH] will map the information model presented in this draft to a form suitable for implementation in a directory that uses (L)DAP as its access protocol. 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 combined. 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. Regardless of what level the operands are specified at, they still need to be specified and standardized. The Policy Framework draft ([FRAME]) discusses how these different forms of policy can be used by different elements in a policy system. 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 takes the first steps in identifying and standardizing a set of operands for use in policies. Strassner, et. al. Expires September 2000 [Page 6 INTERNET-DRAFT QoS Device Info Model March, 2000 1.2 Typical Examples of Policy Usage Typical examples of policies described in the Policy Framework would be implemented as low-level policies using the information model described in this specification. For example, in the low-level policy model, a condition represents an actual evaluation of a specified attribute in the information model described in this specification. Therefore, a condition such as 'If filter = HTTP' would be interpreted as a test determining whether any HTTP filters have been specified 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. Further, this low-level policy model provides all the same benefits that have been ascribed to policy-based management paradigms. Strassner, et. al. Expires September 2000 [Page 7 INTERNET-DRAFT QoS Device Info Model March, 2000 2. Approach QoS activities in the IETF have mainly focused in two areas, Integrated Services (IntServ) and Differentiated Services (DiffServ). This draft initially focuses on the specification of QoS attributes and classes for the policy management of Differentiated Services capabilities. However, the framework defined by the structure of the classes defined in this document is designed to cover the needs of managing policies for signaling, such as RSVP. 2.1. Common Needs Of DiffServ and IntServ First, we consider the common needs for IntServ and DiffServ. 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, 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 this information model. This draft focuses on 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. Strassner, et. al. Expires September 2000 [Page 8 INTERNET-DRAFT QoS Device Info Model March, 2000 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 of the network and the edges of the network. As explained in the DiffServ Architecture document [DSARCH], 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 packet (as described in [DSFIELD]). 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. In addition, the standards for edges of the DiffServ network need more detail before the edges can 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 considered in a future iteration of this draft. Strassner, et. al. Expires September 2000 [Page 9 INTERNET-DRAFT QoS Device Info Model March, 2000 3. Methodology As there is a clear need to define QoS attributes from which to construct policies, there are some very basic issues that need to be considered. Considering these issues should help in constructing a schema for managing the configuration of network QoS mechanisms through the use of QoS policies. 3.1 Level of Abstraction for Expressing QoS Policies The first issue requiring consideration is the level of abstraction at which QoS policies should be expressed. If we consider policies as a set of rules used to react to events and manipulate attributes or generate new events, we realize that policy represents a continuum of specifications that relate business goals and rules to the conditioning of traffic done by a device or a set of devices. An example of 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. As policies are a function of parameters (attributes) and operators (boolean, arithmetic, relational, etc.), both need to be defined in order to construct policies that are broadly implementable. 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, but as a whole have different conditioning characteristics based on a number of different factors with respect to other collections of services (e.g., Silver, Bronze, and Best Effort). In other words, what is lacking is the set of specifications for the set of services that make up Gold Service, and how policies are used to control device mechanisms to implement different types of traffic conditioning in response to each of the services that make up Gold Service. Strassner, et. al. Expires September 2000 [Page 10 INTERNET-DRAFT QoS Device Info Model March, 2000 We also have to define the service semantics (i.e., for Gold Service in the above example) if we want to have uniform application of the policy in all network devices. Any service definition would have to be grounded in semantics like Delay, Jitter, Bandwidth, Reliability, Loss, and over-subscription rules, just to name a few. Finally, it can not be overstressed that policy must be thought of as a continuum of specifications. Network administrators want to specify policies in terms that they are familiar with (e.g., Gold Service get lets latency and jitter than Silver Service) and donÆt necessarily want to deal with configuring QoS capabilities at a low level (e.g., specifying queue configuration). However, devices need to be configured at a significantly lower level, with much more low-level parameters driving their configuration. The goal, then, is to use policies to relate the 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. In addition, policies must be specified at a device-independent level. 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. The Policy Framework draft ([FRAME]) describes a continuum of policies as: - high-level policies, which express business rules - device-independent policies, which express a common set of configuration parameters that can be used by any device to implement a specific type of traffic conditioning - device-specific policies, which map the device-independent policies into a form that is specific to a particular type of device or set of devices 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 ss described in [QOSPIM]. Strassner, et. al. Expires September 2000 [Page 11 INTERNET-DRAFT QoS Device Info Model March, 2000 3.2 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 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: - the modeling of a generic network service that has QoS capabilities - the modeling of how DiffServ traffic conditioning is defined - the modeling of how statistics are gathered to monitor DiffServ (and other types of QoS) services 3.3 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 the 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 (queue depths, excess capacity consumption, loss rates, and so forth). Strassner, et. al. Expires September 2000 [Page 12 INTERNET-DRAFT QoS Device Info Model March, 2000 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 state attributes tend to be device-specific. In contrast, a configuration attribute can be represented and applied to a set of devices (e.g., 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). This suggests that the schema for configuration attributes will not be exactly the same as the schema that supports state attributes. However, there will be significant overlap in the definition of these attributes, and significant dependencies between the configuration and state attributes that are used to manage a QoS service. Specifically, the configuration schema is likely to be very general, whereas the state schema will focus on the needs of specific devices. The intersection of these two schemata (e.g., through a set of associations and aggregations that relates one schema to the other) defines where it is possible to model the configuration of QoS services that apply to one or more devices. 3.4 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. 3.5 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-specific QoS attributes be derived from? Strassner, et. al. Expires September 2000 [Page 13 INTERNET-DRAFT QoS Device Info Model March, 2000 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 characteristics of a networking device. Not all characteristics are always applicable, and so this abstraction is represented by referring to the 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 device mechanisms. Furthermore, policy is used to control those mechanisms, not to represent them. For example, QoS services are implemented with schedulers, classifiers, policers, and buffer managers. 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 different mechanisms than are used by QoS services, even though they are both implemented in the same device. As such, QoS attributes should be part of a networking device schema rather than a policy schema. Although a policy schema may use QoS attributes to define policies, the policy schema really needs 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, the ultimate goal is to be able to apply policies that control these features in network devices. Furthermore, these two schemata must be tightly integrated in order to enable policy to control QoS services. 3.6 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. First, 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). The second alternative is to create multi-modal attributes that express the same value but 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). Strassner, et. al. Expires September 2000 [Page 14 INTERNET-DRAFT QoS Device Info Model March, 2000 The last option is to express all attributes in absolutes, but make the operators in the policy schema 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.7 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 the 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 ([DSARCH], [DSFIELD], [AF], and [EF]). This model assumes that there is a class that represents a set of QoS 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 in turn 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. This document, in its current form, identifies three types of QoS services: DiffServ, 802.1P, and IntServ. For DiffServ, it further differentiates between AF, EF, and Precedence. This latter is meant to be able to map between DiffServ domains and non-DiffServ domains that only use the precedence bits in the ToS byte to communicate QoS requirements. This document also defines a standard set of sub-services that are used to implement a DiffServ service. These sub-services model the concept of a Traffic Conditioning Block (TCB, as defined in [DSMODEL]), along with additional services that are used in conjunction with the TCB to implement network QoS. Thus, classification, metering, marking, and queuing are defined as sub-services of a TCB, while the buffer manager and scheduler are defined to support the TCB. Finally, various statistics are proposed to properly instrument QoS services. Some of these are defined by the DiffServ MIB [DSMIB] and are reproduced here; others are new and instrument different aspects of traffic conditioning that are not yet covered by the DiffServ MIB. Strassner, et. al. Expires September 2000 [Page 15 INTERNET-DRAFT QoS Device Info Model March, 2000 4. The Class Hierarchy The following sections describe the class hierarchy of the information model for modeling QoS capabilities at the device level. Section 4.1 defines the structure of the class hierarchy, and section 4.2 defines the classes and their attributes that make up this class hierarchy. 4.1 Difference Between Inheritance and Relationship Hierarchies This draft defines two different class hierarchies that are not necessarily rooted from the same point in the overall schema. However, it is intended that these two hierarchies be used together to control and administer devices that are running Differentiated and Integrated Services. Therefore, we propose one class hierarchy to manage the state of these services, and a different (but related) class hierarchy to manage the configuration of these services. Both of these hierarchies are influenced from the Common Information Model, and are compatible with the Directory Enabled Networks (DEN) effort. These two hierarchies are integrated through the use of associations and aggregations. 4.1.1 Associations An association is a means of representing a dependency relationship between two or more objects. In CIM and DEN, this type of relationship is modeled as a class containing two or more object references. Since the association is itself a class, it can benefit from all of the object-oriented abilities that other non-association classes have. For example, it can contain properties and methods, and inheritance can be used to refine the semantics of an association such that it represents a more specialized type of dependency. Since this has proven to be a very useful abstraction, this implementation of associations 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 ternary 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. Strassner, et. al. Expires September 2000 [Page 16 INTERNET-DRAFT QoS Device Info Model March, 2000 4.1.2. Aggregations An aggregation is a strong form of an association, which usually represents a "whole-part" relationship. For example, CIM uses an aggregation to represent the containment relationship between a system and the components that make up the system. An aggregate object is treated as an atomic unit, even though an aggregate object is comprised of 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. Aggregations therefore 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. 4.2. The Structure of the Class Hierarchy The following sections discuss the class hierarchies that will be used to model the state and the configuration inheritance hierarchies. 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 1 in the next page. 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 September 2000 [Page 17 INTERNET-DRAFT QoS Device Info Model March, 2000 | +--ManagedSystemElement (defined in [CIMCORE]) | | | +--LogicalElement (defined in [CIMCORE]) | | | | | +--Service (defined in [CIMCORE]) | | | | | | | +--NetworkService (defined in [CIMNET]) | | | | | | | | | +--ForwardingService (defined in [CIMNET]) | | | | | | | | | | | +--TrafficConditioningBlock | | | | | | | | | | | | | +--ClassifierService | | | | | | | | | | | | | +--MeterService | | | | | | | | | | | | | | | +--AverageRateMeter | | | | | | | | | | | | | | | +--EWMAMeter | | | | | | | | | | | | | | | +--TokenBucketMeter | | | | | | | | | | | | | +--MarkerService | | | | | | | | | | | | | +--DropperService | | | | | | | | | | | | | | | +--HeadTailDropper | | | | | | | | | | | | | | | +--RedDropper | | | | | | | | | | | | | | | | | +--WeightedRedDropper | | | | | | | | | | | | | | | | | | | +--PercentageDropper | | | | | | | | | | | | | +--QueuingService | | | | | | | | | | | | | +--SchedulingService | | | | | | | | | | | | | | | +--PriorityScheduler | | | | | | | | | | | | | | | +--BandwidthScheduler | | | | | | | | | | | | | | | +--WeightedPacketScheduler | | | | | | | (continued on following page) Strassner, et. al. Expires September 2000 [Page 18 INTERNET-DRAFT QoS Device Info Model March, 2000 (continued from previous page, first four are repeated for convenience) +--ManagedSystemElement (defined in [CIMCORE]) | | | +--LogicalElement (defined in [CIMCORE]) | | | | | +--Service (defined in [CIMCORE]) | | | | | | | +--NetworkService (defined in [CIMNET]) | | | | | | | | | +--ForwardingService | | | | | | | | | | | +--PacketSchedulingService | | | | | | | | | | | | | +--PriorityScheduler | | | | | | | | | | | | | | | +--PriorityBandwidthScheduler | | | | | | | | | | | | | +--BandwidthScheduler | | | | | | | | | | | | | +--RoundRobinPacketScheduler | | | | | | | | | | | | | | | +--WeightedRoundRobinPacketScheduler | | | | | | | | | +--BufferManagerService | | | | | | | | | +--QoSService | | | | | | | | | | | +--DiffServService | | | | | | | | | | | | | +--AFService | | | | | | | | | | | | | +--EFService | | | | | | | | | | | | | +--PrecedenceService | | | | | | | | | | | | +--8021PService | | | | | +--ServiceTime | | | | | +--FilterEntry | | | | | +--FilterList | | | (continued on following page) Strassner, et. al. Expires September 2000 [Page 19 INTERNET-DRAFT QoS Device Info Model March, 2000 (continued from previous page, first four are repeated for convenience) +--StatisticalInformation (defined in [CIMCORE]) | | | +--ServiceStatisticalInformation (defined in [CIMCORE]) | | | | | +--FilterListStatistics | | | | | +--QoSStatistics | | | | | +--DiffServStatistics | | | | | | | +--PrecedenceStatistics | | | | | +--TCBStatistics | | | | | +--ClassifierStatistics | | | | | +--MeterStatistics | | | | | +--MarkerStatistics | | | | | +--DropperStatistics | | | | | +--QueuingStatistics | | | | | +--BufferManagerStatistics | | | | | +--SchedulerStatistics Figure 1. Inheritance 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. Strassner, et. al. Expires September 2000 [Page 20 INTERNET-DRAFT QoS Device Info Model March, 2000 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 capabilities of network devices. This information is derived from the Networks Common Model. Only new classes that are 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 ManagedSystemElement This is an abstract class that is defined in the Core Model of CIM. This 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.2 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. This is the base class for all components of a managed System that represent abstract system components, 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.3 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. This is the base class for all objects that contain the information necessary to represent and manage the functionality provided by a Device and/or SoftwareFeature. Note that a Service is a general-purpose object that is used to configure and manage the implementation of functionality. It is not the functionality itself. Please refer to [CIM] for the full definition of this class. 4.3.4 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. This is the base class that serves as the root of the network service hierarchy. Network services represent generic functions that are available from the network that condition and/or modify one or more parameters of the traffic being sent, such as fields in its header. Please refer to [CIM] for the full definition of this class. Strassner, et. al. Expires September 2000 [Page 21 INTERNET-DRAFT QoS Device Info Model March, 2000 4.3.5 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. This class represents the forwarding of network traffic by receiving data from one or more communication sources and sending that data via other communication sources. NAME ForwardingService DESCRIPTION A concrete class for describing the common characteristics of network forwarding services that examine traffic and either forward it or drop it. The dropping is done through an active queue management mechanism (e.g., RED [RED]). DERIVED FROM NetworkService TYPE Structural PROPERTIES ProtocolType OtherProtocolType 4.3.6 The Class TrafficConditioningBlock This is a new concrete class that is defined in this model. The concept of a Traffic Conditioning Block (TCB) is defined in [DSMODEL]. It represents a logical entity in the data forwarding path that is made up of a set of lower-level entities interconnected in such a way as to perform a specific set of traffic conditioning functions on an incoming traffic stream. These conditioning functions consist of a combination of a classifier, meter, queue, and an action. Note that this is modeled as a set of sub-services that are managed and configured together that operate on the traffic. Its definition is as follows: NAME TrafficConditioningBlock DESCRIPTION A concrete class for describing how an input traffic stream is conditioned using a common set of building blocks that provide different types of forwarding services (e.g., metering and dropping). DERIVED FROM ForwardingService TYPE Structural PROPERTIES Enabled ID 4.3.6.1 The Attribute Enabled This is a boolean attribute that, if TRUE, signifies that forwarding can be done on this port. Strassner, et. al. Expires September 2000 [Page 22 INTERNET-DRAFT QoS Device Info Model March, 2000 4.3.6.2 The Attribute ID This is a string attribute that can be used to contain unique information that helps disambiguate this ForwardingService from other ForwardingServices on the same device. 4.3.7 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 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). 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 one or more filters to sort an input stream into one or more output streams, where each output stream is the result of matching a particular filter (or not matching any filter). This is modeled as a sub-service that is part of a TCB that aggregates one or more filters, defines a set of traffic classes that represent its outputs, and has the ability to invoke another TCB element. Its definition is as follows: NAME ClassifierService DESCRIPTION A concrete class for describing how an input traffic stream is sorted into multiple output streams using one or more filters. DERIVED FROM TrafficConditioningBlock TYPE Structural PROPERTIES ClassifierType, OtherClassifierType, IsIngress, Status, TrafficClasses 4.3.7.1 The Attribute ClassifierType This is an enumerated 16-bit unsigned integer that is used to define the specific type of classifier that this instance is. 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; 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. Strassner, et. al. Expires September 2000 [Page 23 INTERNET-DRAFT QoS Device Info Model March, 2000 4.3.7.2 The Attribute 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.7.3 The Attribute IsIngress This is a boolean attribute that, if TRUE, means that this filter is used to sort input traffic. 4.3.7.4 The Attribute Status This is an enumerated 16-bit unsigned integer that describes the status of this classifier. Possible values include: 0 û Unknown; 1 û OK; 2 û Error; 3 û Degraded; 4 û Failed; 5 û Starting; 6 û Stopping; 7 û Ready The values are interpreted as follows: 1 (OK) represents a running device that is fully operational 2 (Error) represents a generic error; the device is stopped 3 (Degraded) means that the device is functioning, but in a degraded way. 4 (Failed) means that the device has failed and is stopped. 5 (Starting) means that the device is being initialized, but is not yet ready to operate. 6 (Stopping) means that the device is in the process of stopping operation 7 (Ready) indicates that the device is stopped and is ready to be started. 4.3.7.5 The Attribute TrafficClasses This is an array of strings. Each string represents a different traffic class that the input stream can be sorted into. 4.3.8 MeterService This is a new concrete class that is 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. Non-conforming packets may be further conditioned (e.g., dropped or queued) by routing the packet to an appropriate conditioning element. Please see [DSMODEL] for more information on metering. Strassner, et. al. Expires September 2000 [Page 24 INTERNET-DRAFT QoS Device Info Model March, 2000 This class is the base class for defining different types of meters. As such, it contains common properties that all meter subclasses share. This is modeled as a sub-service that is part of a TCB that has the ability to invoke another TCB element for conforming traffic and a different TCB element for non-conforming traffic. Its definition is as follows: NAME MeterService DESCRIPTION A concrete class for describing the monitoring of traffic with respect to a pre-established traffic profile. DERIVED FROM TrafficConditioningBlock TYPE Structural PROPERTIES MeterType ConformanceLevels OtherMeterConformance FailAction SucceedAction 4.3.8.1 The Attribute 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 enumerations are: 1: Other 2: AverageRateMeter 3: EWMAMeter 4: TokenBucketMeter 4.3.8.2 The Attribute ConformanceLevels This attribute is an enumerated 16-bit unsigned integer. This contains the names of different conformance levels. Recommended values are: 1: Other 2: Fully conformant 3: Partially conformant 4: Non-conformant 4.3.8.3 The Attribute OtherMeterConformance This string attribute is used in conjunction with the ConformanceLevels attribute. When the value of ConformanceLevels is 1 (e.g., Other), then the name of the conformance level for this meter is defined in this attribute. Strassner, et. al. Expires September 2000 [Page 25 INTERNET-DRAFT QoS Device Info Model March, 2000 4.3.8.4 The Attribute FailAction This attribute is a string that contains the name of the TCB element to send non-conforming traffic to. 4.3.8.5 The Attribute SucceedAction This attribute is a string that contains the name of the TCB element to send conforming traffic to. 4.3.9 The Class AverageRateMeter This is a new concrete class that is defined in this model. It is a subclass of the MeterService class. This class is used to describe a simple meter, called an Average Rate Meter, which 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]. This is modeled as a sub-service that is part of a TCB that has the ability to invoke another TCB element for conforming traffic and a different TCB element for non-conforming traffic. Its definition is as follows: NAME AverageRateMeter DESCRIPTION A concrete class for describing admitted 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 TYPE Structural PROPERTIES Rate Interval 4.3.9.1 The Attribute Rate This is a 32-bit real number that defines the rate that is used to determine whether admitted packets are in conformance or not. 4.3.9.2 The Attribute Interval This is a 32-bit real number that defines the time period over which the average measurement should be taken. Strassner, et. al. Expires September 2000 [Page 26 INTERNET-DRAFT QoS Device Info Model March, 2000 4.3.10 The Class EWMAMeter This is a new concrete class that is defined in this model. It is a subclass of the MeterService class. This class 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. This is modeled as a sub-service that is part of a TCB that has the ability to invoke another TCB element for conforming traffic and a different TCB element for non-conforming traffic. Its definition is as follows: NAME EWMAMeter DESCRIPTION A concrete class for 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 Delta Interval Gain 4.3.10.1 The Attribute 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. 4.3.10.2 The Attribute Delta This attribute is a 32-bit real number that defines the sampling interval used to measure the arrival rate in bytes. This rate is averaged over a pre-defined sampling interval (defined in the Interval attribute) and checked against the AverageRate attribute. All packets whose computed average arrival rate is less than the AverageRate are deemed conforming. 4.3.10.3 The Attribute Interval This attribute is a 32-bit real number that defines the average arrival rate of packets. Strassner, et. al. Expires September 2000 [Page 27 INTERNET-DRAFT QoS Device Info Model March, 2000 4.3.10.4 The Attribute Gain This attribute is a 32-bit real number that defines the time constant over which to measure the incoming packet rate. 4.3.11 The Class TokenBucketMeter This is a new concrete class that is defined in this model. This class defines a general token bucket meter. A simple token bucket usually has two parameters, an average token rate and a burst size. This type of meter compares the packet arrival rate to the average token rate. Packets of length L bytes are defined to be conforming if L tokens are available at the time of the arrival of the packet. Packets are allowed to exceed the average rate in bursts up to the burst size. Packets that exceed the burst size are deemed non-conforming. Such meters have two conformance levels û conforming and non-conforming. This class also defines an excess burst size, which enables it to have three conformance levels û 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 burst size but are less than the excess burst size are deemed partially conforming. Operation of this meter is described in [DSMODEL]. This is modeled as a sub-service that is part of a TCB that has the ability to invoke another TCB element for conforming traffic and a different TCB element for non-conforming traffic. Its definition is as follows: NAME TokenBucketMeter DESCRIPTION A concrete class for 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.11.1 The Attribute AverageRate This attribute is a 32-bit real number that is used to define the committed rate of the meter. Strassner, et. al. Expires September 2000 [Page 28 INTERNET-DRAFT QoS Device Info Model March, 2000 4.3.11.2 The Attribute PeakRate This attribute is a 32-bit real number that is used to define the peak rate of the meter. 4.3.11.3 The Attribute BurstSize This attribute is a 32-bit real number that is used to define the maximum number of tokens available for the committed rate. 4.3.11.4 The Attribute ExcessBurstSize This attribute is a 32-bit real number that is used to define the maximum number of tokens available for the peak rate. 4.3.12 The Class MarkerService This is a new concrete class that is defined in this model. This class describes markers, which are functional elements that are use to (re)set a particular field in a packet header. Markers may act either on unmarked packets or re-mark previously marked packets. Markers are usually invoked as a result of a preceding classifier match. Operation of various types of markers is described in [DSMODEL]. This is modeled as a sub-service that is part of a TCB that has the ability to mark traffic and then invoke another TCB element for further processing of the traffic. Its definition is as follows: NAME MarkerService DESCRIPTION A concrete class for defining the value of a field in a packet that is used to control the conditioning that the packet receives. DERIVED FROM TrafficConditioningBlock TYPE Structural PROPERTIES CanRemark RemarkType RemarkValue 4.3.12.1 The Attribute CanRemark This is a boolean attribute that, when TRUE, signifies that this Marker can remark the field value specified in the RemarkType attribute with the value specified in the RemarkValue attribute. Otherwise, if the field value is filled in, then NO remarking will be done. Strassner, et. al. Expires September 2000 [Page 29 INTERNET-DRAFT QoS Device Info Model March, 2000 4.3.12.2 The Attribute 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.12.3 The Attribute 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.13 The Class DropperService This is a new concrete class that is defined in this model. This class represents the ability to drop network traffic. This is the base class for different types of droppers. These droppers are distinguished by the algorithm that they use to drop traffic. Please see [DSMODEL] for more information about a dropper. This is modeled as a sub-service that is part of a TCB that has the ability to drop traffic. Its definition is as follows: NAME DropperService DESCRIPTION A concrete base class used to describe the common characteristics of droppers. DERIVED FROM TrafficConditioningBlock TYPE Structural PROPERTIES DropperType OtherDropperType AlwaysDrop MinQueueThreshold MaxQueueThreshold 4.3.13.1 The Attribute DropperType This is an enumerated 16-bit attribute that defines the type of dropper that this instance is. Values include: 1: Other 2: HeadTail 3: RED 4: WRED Strassner, et. al. Expires September 2000 [Page 30 INTERNET-DRAFT QoS Device Info Model March, 2000 4.3.13.2 The Attribute 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.13.3 The Attribute AlwaysDrop This is a boolean attribute that, if TRUE, signifies that this Dropper will always drop incoming packets regardless of its type. 4.3.13.4 MinQueueThreshold This is a 32-bit unsigned integer that defines the minimum queue level. If there are more packets than this level, then dropping of packets will commence according to the algorithm employed by this particular interface. 4.3.13.5 MaxQueueThreshold This is a 32-bit attribute that defines the maximum queue level. If there are more packets than this level, then all packets above this level will be dropped regardless of the type of dropper used by this particular interface. 4.3.14 The Class HeadTailDropper This is a new concrete class that is defined in this model. This class represents the dropping of network traffic from either the front or the rear of the queue, depending on whether this instance is a head or a tail dropper. Please see [DSMODEL] for more information about a dropper. This is modeled as a sub-service that is part of a TCB that has the ability to drop traffic. Its definition is as follows: NAME HeadTailDropper DESCRIPTION A concrete class used to describe either head Or tail droppers. DERIVED FROM DropperService TYPE Structural PROPERTIES IsTailDropper Strassner, et. al. Expires September 2000 [Page 31 INTERNET-DRAFT QoS Device Info Model March, 2000 4.3.14.1 The Attribute IsTailDropper This is a boolean attribute that, if TRUE, signifies that this instance is a TailDropper. In other words, the dropper will drop packets from the end of the queue. If this attribute is FALSE, then it is a HeadDropper, and packets from the front of the queue will be dropped. 4.3.15 The Class REDDropper This is a new concrete class that is defined in this model. This class represents the dropping of network traffic using the RED algorithm as described in, for example, [RED]. REDÆs purpose is congestion avoidance. 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. This is modeled as a sub-service that is part of a TCB that has the ability to drop traffic. Its definition is as follows: NAME REDDropper DESCRIPTION A concrete class used to describe dropping using the RED algorithm (or one of its variants). DERIVED FROM DropperService TYPE Structural PROPERTIES StartProbability, StopProbability StartPercent, StopPercent 4.3.15.1 The Attribute StartProbability 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 Attribute StopProbability 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 Attribute StartPercent This is a 32-bit real number, and is used in conjunction with the StopPercent attribute to define the slope of the drop probability function which governs the rate at which packets are subject to being dropped as a function of the queue length. Strassner, et. al. Expires September 2000 [Page 32 INTERNET-DRAFT QoS Device Info Model March, 2000 4.3.15.4 The Attribute StopPercent This is a 32-bit real number, and is used in conjunction with the StartPercent attribute to define the slope of the drop probability function which governs the rate at which packets are subject to being dropped as a function of the queue length. 4.3.16 The Class WeightedREDDropper This is a new concrete class that is defined in this model. This class represents the dropping of network traffic using the weighted RED algorithm as described in, for example, [WRED]. This modification of the basic RED algorithm enables packets belonging to different traffic classes to be dropped at different queue depths. This algorithm also enable discard to be done based on different information contained in the packetÆs header, such as IP Precedence or RSVP session parameters, or on other factors, such as the queue depth. Please see [DSMODEL] for more information about a dropper. This is modeled as a sub-service that is part of a TCB that has the ability to drop traffic. Its definition is as follows: NAME WeightedREDDropper DESCRIPTION A concrete class used to describe dropping using the weighted RED algorithm. DERIVED FROM REDDropper TYPE Structural PROPERTIES DropMetric, OtherDropMetric, Weight 4.3.16.1 The Attribute DropMetric This attribute is an enumerated 16-bit unsigned integer, and defines the type of metric that is used to drop traffic with. Values include: 1: Other 2: IP Precedence 3: DSCP Value 4: 802.1Q Priority Value 5: RSVP Session 6: Queue Depth 4.3.16.2 The Attribute 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 to be used is defined in this attribute. Strassner, et. al. Expires September 2000 [Page 33 INTERNET-DRAFT QoS Device Info Model March, 2000 4.3.16.3 The Attribute Weight This is a 32-bit real number that representing the weighting factor used to determine the weighted average queue length. 4.3.17 The Class QueuingService This is a new concrete class that is defined in this model. This class 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. This is modeled as a sub-service that is part of a TCB that has the ability to queue traffic. Its definition is as follows: NAME QueuingService DESCRIPTION A concrete class used to describe the ability to queue network traffic and to specify the characteristics for determining long-term congestion. DERIVED FROM TrafficConditioningBlock TYPE Structural PROPERTIES SmoothingWeight, Interval 4.3.17.1 The Attribute 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 queue depth. 4.3.17.2 The Attribute Interval This attribute is a 32-bit unsigned integer, and defines the number of nano-seconds between each calculation. 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. Strassner, et. al. Expires September 2000 [Page 34 INTERNET-DRAFT QoS Device Info Model March, 2000 4.3.18 The Class BufferManagementService This is a new concrete class that is defined in this model. This class represents the management of the buffer(s) used by the Queuing Service. In implementations where there are multiple buffer sizes, an instance of BufferManagementService 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 BuffersPartOf association. Please see [DSMODEL] for more information about queuing functionality. This is modeled as a separate service that a TCB uses, not as a sub- service of the TCB, for managing queuing. Note that this class is derived from NetworkService, not TrafficConditioningBlock. Its definition is as follows: NAME BufferManagementService DESCRIPTION A concrete class used to represent the buffer(s) used by the queuing service. DERIVED FROM NetworkService TYPE Structural PROPERTIES BufferSize, TotalBuffers, AvailableBuffers, SharedBuffers 4.3.18.1 The Attribute BufferSize This attribute is a 16-bit unsigned integer, and that specifies the number of bytes in each buffer. 4.3.18.2 The Attribute TotalBuffers This attribute is a 32-bit unsigned integer, and defines the total number of buffers in the buffer pool described by this instance of the BufferManagementService class. 4.3.18.3 The Attribute AvailableBuffers This attribute is a 32-bit unsigned integer, and represents the number of buffers in the pool that are currently not allocated to any instance of a queuing service. Buffers allocated to a queuing service could either be in use (containing packet data), or allocated to a queue pending the arrival of new packet data. 4.3.18.4 The Attribute SharedBuffers This attribute is a 32-bit unsigned integer, and indicates the number of buffers in the buffer pool that are been simultaneously being allocated to multiple instances of queuing services. Strassner, et. al. Expires September 2000 [Page 35 INTERNET-DRAFT QoS Device Info Model March, 2000 4.3.19 The Class PacketSchedulingService This is a new concrete class that is defined in this model. This class represents the scheduling service, which is a process that determines whether a queued packet should be removed from the queue and sent to the output interface or not. 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 the scheduler is servicing. This allows implementations that support different schedulers for different queues to be supported. Please see [DSMODEL] for more information about a scheduler. This is modeled as a sibling service to the TCB. Both are derived from a common root, ForwardingService. Its 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 PROPERTIES SchedulerType, OtherSchedulerType, GiveExcessCapacity 4.3.19.1 The Attribute SchedulerType This attribute is an enumerated 16-bit unsigned integer, and defines the type of scheduler that this instance is. Values include: 1: Other 2: Priority 3: Bandwidth 4: Priority Bandwidth 5: Round Robin Packet 6: Weighted Round Robin Packet 4.3.19.2 The Attribute 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. Strassner, et. al. Expires September 2000 [Page 36 INTERNET-DRAFT QoS Device Info Model March, 2000 4.3.19.3 The Attribute GiveExcessCapacity This is a boolean attribute, and determines if the scheduling resources from the current queue is available to other queues/scheduler instances. Note that when this attribute is true, the association ExcessCapacity scheduler is used to describe how excess resources are allocated. 4.3.20 The Class PriorityScheduler This is a new concrete class that is defined in this model. This class represents a simple priority scheduler, which is a process that schedules arriving packets into different priority queues. Please see [DSMODEL] for more information about a scheduler. This is modeled as a specialization of the PacketSchedulingService, which is a sibling service to the TCB. Both PacketSchedulingService and TCB are derived from a common root, ForwardingService. Its definition is as follows: NAME PriorityScheduler DESCRIPTION A concrete class used to represent a simple priority scheduling service. DERIVED FROM PacketSchedulingService TYPE Structural PROPERTIES None 4.3.21 The Class PriorityBandwidthScheduler This is a new concrete class that is defined in this model. 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. Please see [DSMODEL] for more information about a scheduler. This is modeled as a specialization of the PacketSchedulingService, which is a sibling service to the TCB. Both PacketSchedulingService and TCB are derived from a common root, ForwardingService. Its definition is as follows: NAME PriorityBandwidthScheduler 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 PriorityScheduler TYPE Structural PROPERTIES BandwidthAllocation, BurstsAllowed, BurstAllocation Strassner, et. al. Expires September 2000 [Page 37 INTERNET-DRAFT QoS Device Info Model March, 2000 4.3.21.1 The Attribute 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 Attribute 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 attribute is allowed. 4.3.21.3 The Attribute 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 attribute. If the maximum actual bandwidth allocation were to be measured, it would be the sum of the BurstAllocation and the Bandwidth allocation attributes. 4.3.22 The Class BandwidthScheduler This is a new concrete class that is defined in this model. This class represents a bandwidth scheduler, which is a process that reserves a portion of the bandwidth of a link for each selected traffic type. This is modeled as a specialization of the PacketSchedulingService, which is a sibling service to the TCB. Both PacketSchedulingService and TCB are derived from a common root, ForwardingService. Its definition is as follows: NAME BandwidthScheduler 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.22.1 The Attribute BandwidthAllocation This attribute is a 32-bit unsigned integer, and defines the number of bytes that can be delivered from a queue each cycle. Strassner, et. al. Expires September 2000 [Page 38 INTERNET-DRAFT QoS Device Info Model March, 2000 4.3.22.2 The Attribute 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 attribute is allowed. 4.3.22.3 The Attribute 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 attribute. If the maximum actual bandwidth allocation were to be measured, it would be the sum of the BurstAllocation and the Bandwidth allocation attributes. 4.3.22.4 The Attribute 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.22.5 The Attribute 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. 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.23 The Class RoundRobinPacketScheduler This is a new concrete class that is defined in this model. This class 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. This is modeled as a specialization of the PacketSchedulingService, which is a sibling service to the TCB. Both PacketSchedulingService and TCB are derived from a common root, ForwardingService. Its definition is as follows: NAME RoundRobinPacketScheduler 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 Strassner, et. al. Expires September 2000 [Page 39 INTERNET-DRAFT QoS Device Info Model March, 2000 4.3.24 The Class WeightedRoundRobinPacketScheduler This is a new concrete class that is defined in this model. This class 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. This is modeled as a specialization of the PacketSchedulingService, which is a sibling service to the TCB. Both PacketSchedulingService and TCB are derived from a common root, ForwardingService. Its definition is as follows: NAME WeightedRoundRobinPacketScheduler DESCRIPTION A concrete class used to represent a weighted packet scheduling service. DERIVED FROM RoundRobinPacketScheduler TYPE Structural PROPERTIES WeightingFactor, Priority 4.3.24.1 The Attribute 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.24.2 The Attribute 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 this condition. However, in instances where this behavior is not necessary or undesirable, this attribute may be left unspecified. 4.3.25 The Class QoSService This is a new concrete class that is defined in this model. This class 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. This class defines a set of attributes that describe how to build TCBs and other sub-services that it needs for building higher-level QoS services, as well as relationships for defining the structure of various QoS services and sub-services. Strassner, et. al. Expires September 2000 [Page 40 INTERNET-DRAFT QoS Device Info Model March, 2000 For example, Gold Service may represent 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 traffic conditioning characteristics for different types of flows. It will direct the specific type of TCB(s) and action elements to be used in order to implement this service. Its 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 AllowClassificationService, AllowMarkingService, AllowDroppingService, AllowMeteringService, AllowQueuingService, AllowSchedulingService, AllowSignalingService 4.3.25.1 The Attribute AllowClassificationService This is a boolean attribute that, if TRUE, enables a classification sub-service to be enabled for this QoS service. 4.3.25.2 The Attribute AllowMarkingService This is a boolean attribute that, if TRUE, enables a marking sub- service to be enabled for this QoS service. 4.3.25.3 The Attribute AllowDroppingService This is a boolean attribute that, if TRUE, enables a dropping sub- service to be enabled for this QoS service. 4.3.25.4 The Attribute AllowMeteringService This is a boolean attribute that, if TRUE, enables a metering sub- service to be enabled for this QoS service. Strassner, et. al. Expires September 2000 [Page 41 INTERNET-DRAFT QoS Device Info Model March, 2000 4.3.25.5 The Attribute AllowQueuingService This is a boolean attribute that, if TRUE, enables a queuing sub- service to be enabled for this QoS service. 4.3.25.6 The Attribute AllowSchedulingService This is a boolean attribute that, if TRUE, enables a scheduling sub- service to be enabled for this QoS service. 4.3.25.7 The Attribute AllowSignalingService This is a boolean attribute that, if TRUE, enables a signaling sub- service to be enabled for this QoS service. 4.3.26 The Class DiffService This is a new concrete class that is defined in this model. This class represents using standard or custom DiffServ services to implement a (higher-level) QoS service. Note that the DiffServ service may be only one of a set of coordinated sub-services that together implement a higher-level QoS service. The DiffServ service is modeled as 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). Its definition is as follows: NAME DiffServService DESCRIPTION A concrete class used to represent a DiffServ service or set of DiffServ services. DERIVED FROM QoSService TYPE Structural PROPERTIES DSCP 4.3.26.1 The Attribute DSCP This attribute is an unsigned 8-bit integer. The DSCP attribute defines the Differentiated Services Code Point that this link uses to represent various types of differentiated services through device-specific configuration commands. Strassner, et. al. Expires September 2000 [Page 42 INTERNET-DRAFT QoS Device Info Model March, 2000 4.3.27 The Class AFService This is a new concrete class that is defined in this model. This class represents a specialization to the general concept of forwarding network traffic by adding specific semantics that characterize the operation of the Assured Forwarding Service RFC [AF]. 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 service as well as to lower-level sub- services (e.g., classification, metering, dropping, queuing, and others). Its 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 4.3.27.1 The Attribute ClassNumber This attribute is an 8-bit unsigned integer that defines the number of classes that this AF implementation uses. 4.3.27.2 The Attribute DropperNumber This attribute is an 8-bit unsigned integer that defines the number of drop precedences that this AF implementation uses. 4.3.28 The Class EFService This is a new concrete class that is defined in this model. This class represents a specialization to the general concept of forwarding network traffic by adding specific semantics that characterize the operation of the Expedited Forwarding Service RFC [EF]. 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 service as well as to lower-level sub- services (e.g., classification, metering, dropping, queuing, and others). Its definition is as follows: Strassner, et. al. Expires September 2000 [Page 43 INTERNET-DRAFT QoS Device Info Model March, 2000 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.29 The Class PrecedenceService This is a new concrete class that is defined in this model. This class represents a specialization to the general concept of forwarding network traffic by adding specific semantics that define how traffic is forwarded based on the value of their ToS byte. This class is used to enable DiffServ domains and non-DiffServ domains to exchange traffic. It represents the mapping between implementations that do not support DiffServ, and instead use IP Precedence, to be mapped to implementations that do support DiffServ, which use DSCPs. The PrecedenceService 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). Its 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.29.1 The Attribute PrecedenceValue This attribute is an 8-bit unsigned integer that defines the notion of precedence for different types of traffic. See [DIFFSERV] for more information on the definition, backward compatibility with the ToS byte of IPv4 traffic, and use of this attribute. Strassner, et. al. Expires September 2000 [Page 44 INTERNET-DRAFT QoS Device Info Model March, 2000 4.3.30 The Class 8021PService This is a new concrete class that is defined in this model. This class represents a specialization to 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 domains and domains that support 802.1P only to exchange traffic. It represents the mapping between implementations that only support 802.1P priority marking to be mapped to implementations that do support DiffServ, which use DSCPs. The 8021PService class is modeled as 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). Its 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.30.1 The Attribute PriorityValue This attribute is an 8-bit unsigned integer that defines the notion of priority as specified in 802.1P implementations. 4.4 Relationships Defined in the State Portion of the Model This section will define the relationships described in the previous section. These relationships are implemented as classes (that can have attributes) in the Information Model. Strassner, et. al. Expires September 2000 [Page 45 INTERNET-DRAFT QoS Device Info Model March, 2000 4.5 Classes Defined in the Configuration Portion of the Model 4.6 Relationships Defined in the Configuration Portion of the Model This section will define the relationships described in the previous section. These relationships are implemented as classes (that can have attributes) in the Information Model. Strassner, et. al. Expires September 2000 [Page 46 INTERNET-DRAFT QoS Device Info Model March, 2000 5. Mapping to Example Policies This section will define some simple use cases that demonstrate how these classes and attributes can be expressed and used to create policies. In order to express these attributes in a meaningful way, they have to be bound to a router or an interface on a router. This requires the introduction of two additional concepts that can flexibly group the set of devices and interfaces. The first concept is a means for binding a particular policy to a set of devices that execute or act on the policy. To support this capability, we will use the two weak relationships, PolicyGroupInSystem and PolicyRuleInSystem, that are part of the Policy Core Information Model. These relationships define the device or set of devices that this policy is applicable for. The second concept is a means for binding an attribute to a specific interface or set of interfaces. This binding, called a Role, takes the form of a qualifier preceding the instance name. Roles are described in [PCIM]. So let's consider the following condition: Customer1.ReliableService.ConsumedBandwidth > 1500 The qualifier "Customer1" is a Role that refers to a specific interface of one or more devices. The DiffServ class, or queue (e.g., AF2, precedence 6, or EF) is represented in the directory with a unique instance with a unique name. In this example, ReliableService is the instance name for an AFService class using the DSCPs for AF2. ConsumedBandwidth is an attribute containing the current bandwidth rate being sent on specified DiffServ class (queue) of the specified interface. Hence, the condition reads: If Customer1 is receiving more then 1500 Kb of AF2 traffic, then.... However, the concept of Roles has additional benefits because we can also express a single policy that can be applied to a set of interfaces simultaneously. Let's consider the following sample action: CoreInterfaces.LowDelayConfig.MaxDelay = 20 In this particular case, we are qualifying this action to only apply to the interfaces as specified by the CoreInterfaces role. In this case we are assuming that this is the set of interfaces in a device participating in the core of the DiffServ domain. Strassner, et. al. Expires September 2000 [Page 47 INTERNET-DRAFT QoS Device Info Model March, 2000 Further, LowDelayConfig is an instance of some class that is used to specify the configuration of the EF service. As mentioned earlier, configuration classes are used to request a change in the configuration of device or service while state classes are used to model the actual state of the device or service. So, this action expresses the changing of the upper bound on the maximum delay that will be tolerated for this service on each sending interface to the core. As a side note, the intent of the attribute MaxDelay is to provide a simple way of expressing an upper bound on the number of packets that can be queued up while avoiding implementation details for where or how packets are queued or scheduled. 6. 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. However, the information in this draft explicitly makes use of the security measures recommended in the policy architecture defined by the Policy Framework working group. 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 (such as PEPs and PDPs) 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 [IPSEC] 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. 7. Acknowledgments The authors wish to thank the participants of the Policy Framework working group for their many helpful comments and suggestions. 8. References [TERMS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", Internet RFC 2119, March 1997. [PFCORE] B. Moore, E. Ellesson, J. Strassner, Policy Framework Core Information Model, Internet Draft, draft-ietf-policy-core-info-model-01.txt Strassner, et. al. Expires September 2000 [Page 48 INTERNET-DRAFT QoS Device Info Model March, 2000 [PFSCHEMA] J. Strassner, E. Ellesson, B. Moore, Policy Framework LDAP Core Schema, Internet Draft, draft-ietf-policy-core-schema-05.txt [QOSPIM] Y. Snir, Y. Ramberg, J. Strassner, R. Cohen, QoS Policy Information Model, Internet draft, draft-ietf-policy-qos-info-model-00.txt, March 2000 [QOSSCH] Y. Snir, Y. Ramberg, J. Strassner, R. Cohen, QoS Policy Information Schema, Internet Draft, draft-itef-policy-qos-schema-00.txt [FRAME] M. Stevens, W. Weiss, H. Mahon, B. Moore, J. Strassner, G. Waters, A. Westerinen, J. Wheeler, Internet Draft Policy Framework, draft-ietf-policy-framework-00.txt [DSARCH] D. Black, S. Blake, M. Carlson, E. Davies, Z. Whang, W. Weiss, "An Architecture for Differentiated Services", RFC2475, December 1998 [DSFIELD] K. Nichols, S. Blake, F. Baker, and D. Black, "Definition of the Differentiated Services Field (DS Byte) in the IPv4 and IPv6 Headers", RFC2474, December 1998 [DSMODEL] Y. Bernet, A. Smith, S. Blake, A Conceptual Model for DiffServ Routers, Internet Draft, draft-ietf-diffserv-model-01.txt [DSMIB] F. Baker, Differentiated Services MIB, Internet Draft, draft-ietf-diffserv-mib-00.txt, June 1999 [PIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, A. Smith, Quality of Service Policy Information Base, Internet Draft draft-mfine-cops-pib-01.txt, June 1999 [AF] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured Forwarding PHB Group", RFC2597, June 1999 [EF] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding PHB", RFC2598, June 1999 [RAPFRAME] R. Yavatkar, D. Pendarakis, R. Guerin, "A Framework for Policy-based Admission Control", Internet Draft, , May 1998 [CIM] CIM Specification and CIM Schemata are available at: http://www.dmtf.org/spec/cims.html [IPSEC] R. Atkinson, "Security Architecture for the Internet Protocol", RFC1825, Aug. 1995. [RED] See http://www-nrg.ee.lbl.gov/floyd/red.html Strassner, et. al. Expires September 2000 [Page 49 INTERNET-DRAFT QoS Device Info Model March, 2000 9. Authors' Addresses John Strassner Cisco Systems, Building 15 170 West Tasman Drive San Jose, CA 95134 Phone: +1-408-527-1069 Fax: +1-408-527-2477 E-mail: johns@cisco.com Walter Weiss Lucent Technologies 300 Baker Ave. Concord, MA. 01742 Phone: +1-978-287-9130 Fax: +1-978-287-9050 E-mail: wweiss@lucent.com David Durham Intel 2111 NE 25th Avenue Hillsboro, OR 97124 Phone: 503.264.6232 David_Durham@mail.intel.com Andrea Westerinen SNIA E-mail: andreawest@mindspring.com 10. Full Copyright Statement Copyright (C) The Internet Society (1999). 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. Strassner, et. al. Expires September 2000 [Page 50 INTERNET-DRAFT QoS Device Info Model March, 2000 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 September 2000 [Page 51]