Policy Framework Working Group Y. Snir INTERNET-DRAFT Y. Ramberg Category: Standards Track J. Strassner Cisco Systems R. Cohen Ntear LLC April 2001 Policy QoS Information Model Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document presents an object-oriented information model for representing network QoS policies. This document is based on the IETF Policy Core Information Model and its extensions as specified by [PCIM] and [PCIMe]. This draft builds upon these two documents to define an information model for QoS enforcement for differentiated and integrated services using policy. It is important to note that this document defines an information model, which by definition is independent of any particular data storage mechanism and access protocol. 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 [KEYWORDS]. Snir, Ramberg, Strassner, Cohen expires November 2001 1 draft-ietf-policy-qos-info-model-03.txt April 2001 Table of Contents 1. Introduction 5 1.1. Goals 5 1.1.1. Modeling Abstract QoS Policies 5 1.1.2. Enhancing Interoperability 6 1.1.3. Intended Audiences 7 1.2. QPIM Characteristics 8 1.3. QPIM and Other Published Standards 10 2. Class Hierarchies 11 2.1. Inheritance Hierarchy 11 2.2. Relationship Hierarchy 13 3. QoS Actions 14 3.1. Overview 14 3.2. RSVP Policy Actions 15 3.3. Provisioning Policy Actions 16 3.3.1. Admission Actions: Controlling Policers and Shapers 17 3.3.2. Controlling Markers 18 3.3.3. Controlling Edge Policies ‚Çô Examples 18 3.4. Per-Hop Behavior Actions 20 3.4.1. Controlling Bandwidth and Delay 21 3.4.2. Congestion Control Actions 21 3.4.3. Using Hierarchical Policies ‚Çô Examples for PHB Actions 22 4. Traffic Profiles 23 4.1. Provisioning Traffic Profiles 24 4.2. RSVP Traffic Profiles 24 5. Pre-Defined QoS-Related Variables 25 6. QoS Related Values 27 7. Class Definitions: Association Hierarchy 28 7.1. The Association "QoSPolicyTrfcProfInAdmissionAction" 28 7.1.1. The Reference "Antecedent" 28 7.1.2. The Reference "Dependent" 28 7.2. The Association "PolicyConformAction" 28 7.2.1. The Reference "Antecedent" 29 7.2.2. The Reference "Dependent" 29 7.3. The Association "PolicyExcessAction" 29 7.3.1. The Reference "Antecedent" 29 7.3.2. The Reference "Dependent" 29 7.4. The Association "PolicyViolateAction" 30 7.4.1. The Reference "Antecedent" 30 7.4.2. The Reference "Dependent" 30 Snir, Ramberg, Strassner, Cohen expires November 2001 2 draft-ietf-policy-qos-info-model-03.txt April 2001 Table of Contents (continued) 8. Class Definitions: Inheritance Hierarchy 31 8.1. The Class QoSPolicyDiscardAction 31 8.2. The Class QoSPolicyAdmissionAction 31 8.2.1. The Property qpAdmissionScope 31 8.3. The Class QoSPolicyPoliceAction 32 8.4. The Class QoSPolicyShapeAction 32 8.5. The Class QoSPolicyRSVPAdmissionAction 33 8.5.1. The Property qpRSVPWarnOnly 33 8.5.2. The Property qpRSVPMaxSessions 33 8.6. The Class QoSPolicyPHBAction 34 8.6.1. The Property qpPacketSize 34 8.7. The Class QoSPolicyBandwidthAction 34 8.7.1. The Property qpForwardingPriority 35 8.7.2. The Property qpBandwidthUnits 35 8.7.3. The Property qpMinBandwidth 35 8.7.4. The Property qpMaxBandwidth 35 8.7.5. The Property qpMaxDelay 36 8.7.6. The Property qpMaxJitter 36 8.7.7. The Property qpFairness 36 8.8. The Class QoSPolicyCongestionControlAction 36 8.8.1. The Property qpSizeUnits 37 8.8.2. The Property qpQueueSize 37 8.8.3. The Property qpDropAlgorithm 37 8.8.4. The Property qpDropThresholdUnits 37 8.8.5. The Property qpDropMinThresholdValue 38 8.8.6. The Property qpDropMaxThresholdValue 38 8.9. The Class QoSPolicyTrfcProf 38 8.10. The Class QoSPolicyTokenBucketTrfcProf 39 8.10.1. The Property qpTBRate 39 8.10.2. The Property qpTBNormalBurst 39 8.10.3. The Property qpTBExcessBurst 39 8.11. The Class QoSPolicyIntServTrfcProf 40 8.11.1. The Property qpISTokenRate 40 8.11.2. The Property qpISPeakRate 40 8.11.3. The Property qpISBucketSize 40 8.11.4. The Property qpISResvRate 41 8.11.5. The Property qpISResvSlack 41 8.11.6. The Property qpISMinPolicedUnit 41 8.11.7. The Property qpISMaxPktSize 41 8.12. The Class QoSPolicyAttributeValue 42 8.12.1. The Property qpAttributeName 42 8.12.2. The Property qpAttributeValueList 42 8.13. The Class QoSPolicyRSVPVariable 42 8.14. The Class QoSPolicyRSVPSourceIPv4Variable 43 8.15. The Class QoSPolicyRSVPDestinationIPv4Variable 43 8.16. The Class QoSPolicyRSVPSourceIPv6Variable 43 8.17. The Class QoSPolicyRSVPDestinationIPv6Variable 44 8.18. The Class QoSPolicyRSVPSourcePortVariable 44 8.19. The Class QoSPolicyRSVPDestinationPortVariable 44 Snir, Ramberg, Strassner, Cohen expires November 2001 3 draft-ietf-policy-qos-info-model-03.txt April 2001 Table of Contents (continued) 8.20. The Class QoSPolicyRSVPIPProtocolVariable 45 8.21. The Class QoSPolicyRSVPIPVersionVariable 45 8.22. The Class QoSPolicyRSVPDCLASSVariable 45 8.23. The Class QoSPolicyRSVPStyleVariable 46 8.24. The Class QoSPolicyRSVPIntServVariable 46 8.25. The Class QoSPolicyRSVPMessageTypeVariable 46 8.26. The Class QoSPolicyRSVPPreemptionPriorityVariable 47 8.27. The Class QoSPolicyRSVPPreemptionDefPriorityVariable 47 8.28. The Class QoSPolicyRSVPUserVariable 48 8.29. The Class QoSPolicyRSVPApplicationVariable 48 8.30. The Class QoSPolicyRSVPAuthMethodVariable 49 8.31. The Class QosPolicyDNValue 49 8.31.1. The Property qpDNList 49 8.32. The Class QoSPolicyRSVPSimpleAction 50 8.32.1. The Property qpRSVPActionType 50 9. Acknowledgements 50 10. Security Considerations 50 11. References 51 12. Authors' Addresses 52 13. Full Copyright Statement 53 Snir, Ramberg, Strassner, Cohen expires November 2001 4 draft-ietf-policy-qos-info-model-03.txt April 2001 1. Introduction This document presents an object-oriented information model for representing network QoS policies. This document is based on the IETF Policy Core Information Model and its extensions as specified by [PCIM] and [PCIMe]. This draft builds upon these two documents to define an information model for QoS enforcement for differentiated and integrated services using policy. It is important to note that this document defines an information model, which by definition is independent of any particular data storage mechanism and access protocol. The following subsections describe the goals and purposes of the QoS Policy Information Model (QPIM), its intended audience, and its relationships to other published standards. 1.1 Goals This section explains the goals for creating QPIM. 1.1.1. Modeling Abstract QoS Policies The main goal of the QPIM is to create an information model that can be used to help bridge part of the conceptual gap between a human policy maker and a network element that is configured to enforce the policy. Clearly this wide gap implies several translation levels, from the abstract to the concrete. At the abstract end are the business QoS policy rules. QPIM facilitates a formal representation of network QoS business rules, thus providing the first concretization level: formally representing humanly expressed QoS policy. When a human business executive defines network policy, it is usually done using informal business terms and language. For example, a human may utter a policy statement that reads: "traffic generated by our human- resources application should have higher priority for making it through to its destination compared to traffic generated by people browsing the WEB during their lunch breaks". While this statement clearly defines QoS policy for the network, the network itself cannot enforce it. Translation to "network terms and language" is required. On the other end of the scale, a network element functioning as a Policy Enforcement Point (PEP, see [TERMS] for its definition), such as a router, can be configured with specific commands that determine the operational parameters of its inner working QoS mechanisms. For example, the (imaginary) command "output-queue-depth = 100" may be an instruction to a network interface card of a router to allow up to 100 packets to be stored before subsequent packets are discarded (not forwarded). On a different device within the same network, the same instruction may take another form, because a different vendor built that device or it has a different set of functions, and hence implementation, even though it is from the same vendor. In addition, a particular PEP may not have the ability to create queues that are longer than, say, 50 packets, which may result in a different instruction implementing the same business policy. Snir, Ramberg, Strassner, Cohen expires November 2001 5 draft-ietf-policy-qos-info-model-03.txt April 2001 The first example illustrates 'abstract policy', while the second illustrates 'concrete configuration'. Furthermore, the first example illustrates end-to-end policy, which covers the conditioning of application traffic throughout the network. The second example illustrates configuration for a particular PEP or a set thereof. While an end-to-end policy statement can only be enforced by configuration of PEPs in various parts of the network, the information model of policy and that of the mechanisms that a PEP uses to implement that policy is vastly different. The translation process from abstract business policy to concrete PEP configuration is roughly expressed as follows: 1. Informal business QoS policy is expressed by a human policy maker (e.g. "All executives' WEB requests should be prioritized") 2. A network administrator models the informal policy by using QPIM constructs, thus creating a formal representation of the abstract policy. (e.g. "If packet's protocol is HTTP and its destination is in the 'EXECUTIVES' user group, then assign IPP 7 to the packet header"). Note that the administrator is very likely to use a particular data model (e.g., LDAP schema) that is mapped to QPIM. 3. The network administrator maps the abstract, formal policy to PEPs (most likely by using roles, as specified in [PCIMe, sections 2.2.4 and 4.6]). 4. A configuration/distribution agent (or a PDP ‚Çô see [TERMS] for its definition) consults a device capability model to determine how to translate the policy into device configuration. An example for a standards-based capability model is [QDDIM]. Note that one or more such translations are possible, depending on the particular capabilities of a given PEP and the implementation of the system. 5. For each PEP in the network, the configuration/distribution agent configures the appropriate instructions to enforce the policy. QPIM is intended to be the bridging mechanism between step #1 and step #2 in the methodology just described. 1.1.2. Enhancing Interoperability Another goal of QPIM is to facilitate interoperability among policy systems, PDPs in particular. QPIM accomplishes its interoperability goal by standardizing a representation of policy. Producers and consumers of QoS policy need only rely on QPIM-based schemata (or data models) to ensure mutual understanding and agreement on the semantics of QoS policy. For example, suppose that a QoS policy management application, built by vendor A, writes its policies based on an LDAP schema that maps from QPIM to a directory implementation.A separately built PDP from vendor B may then read this policy and "understand" it as both the management application and the PDP were architected to comply with the QPIM standard. Snir, Ramberg, Strassner, Cohen expires November 2001 6 draft-ietf-policy-qos-info-model-03.txt April 2001 Interoperability of QPIM producers/consumers is by definition at a high level, and does not guarantee that the same policy will result in the same PEP configuration. First, different PEPs will have different capabilities and functions, which necessitate different individual configurations even if the different PEPs are controlled by the same policy. Second, different PDPs will also have different capabilities and functions, and may choose to translate the high-level QPIM policy differently depending on the functionality of the PDP as well as the capabilities of the PEPs that are being controlled by the PDP. Finally, the same policy may be interpreted slightly differently depending on various factors. For example, a QPIM policy rule that reads "If packet's protocol is HTTP then assign 7 to IPP", may result in different configurations depending on how that rule is implemented. For example, an application recognition mechanism can be used to enforce the policy. If the device does not supports this particular mechanism, then an alternate mechanism must be used. For example, the packets could be classified based on their destination TCP port. Therefore, we define interoperability of QoS policies as the ability to specify a policy rule in a standard format. The advantage is that such a policy can be understood by PDPs and PEPs manufactured from different vendors having different capabilities and functionality, as well as policy-based applications. We specifically do not require a policy to be translated into exactly the same configuration in different PEPs. This is why we view the above two systems that differ in the interpretation of recognizing WEB traffic as interoperable with regard to policy. The advantage of using QPIM policies is that incompatible device capabilities may still be employed and controlled using the QPIM policy. 1.1.3. Intended Audiences QPIM is intended for several audiences. The following lists some of the intended audiences and their respective uses: 1. Application vendors who build QoS policy management applications can use this model as an extensible framework for defining policies to control PEPs and PDPs in an interoperable manner 2. Developers of Policy Decision Point (PDP) systems can use this framework to develop interoperable policies 3. QoS policy makers who seek a standardized model for expressing a formal representation of QoS policy can use this model to control PEPs of varying capabilities and functionality 4. Builders of large organization data and knowledge bases who decide to combine QoS policy information with other networking policy information, assuming all modeling is based on [PCIM] and [PCIMe] 5. Authors of various standards may use constructs introduced in this document to enhance their work. Authors of data models wishing to map a storage specific technology to QPIM must use this document as well. Snir, Ramberg, Strassner, Cohen expires November 2001 7 draft-ietf-policy-qos-info-model-03.txt April 2001 1.2. QPIM Characteristics First, a general statement that characterizes QPIM: "The QoS Policy Information Model (QPIM) establishes a standard framework and constructs for specifying and representing business QoS policies. This framework consists of a set of classes and relationships, organized in an object-oriented information model. It is agnostic of any specific PDP or PEP implementation and independent of any particular QoS technology mechanism. It is intended to be used to control the provisioning of end-to-end network services." In the rest of this section, we itemize and expand the general statement presented above. 1. QPIM, as the name implies, is a QoS Policy Information Model. This means that it only models QoS concepts. These concepts are either derived in this document, or adapted for use in modelingQoS from other documents. 2. QPIM is an information model. As such, it is independent of any specific data storage mechanism and access protocol. QPIM's constructs may be mapped to various storage and data organization technologies. A data model mapped to QPIM can be created in a relational database, an object oriented database, an LDAP directory and more. Because QPIM is not a schema, the reader is encouraged to focus on the conceptual level and not on the data organization methodology. Clearly a mapped schema would include enhancements and optimizations not appropriate in the information-modeling realm. For example, a given association between two classes is always modeled as an association class in QPIM. A given schema may find it useful and efficient to model such a relationship using a reference object attribute in a directory or a key‚Çôforeign key relationship in a relational database. 3. QPIM is standard. The model standardizes the process of specifying business QoS policies. It is an interpretation and extension of the core policy information model as defined in [PCIM] and [PCIMe]. It references other IETF standards (e.g. [TERMS], [DIFFSERV] and others) and is meant to enhance interoperability of QoS systems from different vendors. QPIM establishes a conceptual framework by fully and closely following the core policy framework as specified in [PCIM] and [PCIMe]. QPIM inherits all of its constructs from the core model, providing QoS interpretation and extensions where necessary. 4. QPIM is object oriented. The modeling methodology is based on UML (Unified Modeling Language [UML]. This is a ubiquitous modeling method that is easy to understand and read. In addition, UML-based models lend themselves to further extensions and natural progression toward detailed data models. Snir, Ramberg, Strassner, Cohen expires November 2001 8 draft-ietf-policy-qos-info-model-03.txt April 2001 5. QPIM is a formal model. It expresses its concepts by describing and defining classes and inter-class associations. Classes are formal definitions of major concepts. For example, the concept of a traffic profile is represented by the QosPolicyTrfcProf (abstract) class. A derivative of this class provides several attributes to describe the traffic in terms of average rate and other characteristics. Associations represent relationships among instances of different classes or the same class. For example, the association QoSPolicyViolateAction links a certain restriction on traffic (represented by an instance of the QoSPolicyPoliceAction class) to an action to be taken when the restriction is violated. 6. QPIM is abstract. The model is aimed at the formalization of humanly expressed business QoS policies. For example, QPIM provides the means of expressing formally a business policy that states: "In our network, IP telephony should receive the same service quality as that of our legacy phone systems". QPIM provides the topmost link from the abstract business policy to the concrete device implementation by expressing the abstract business policy in high-level networking terms. QPIM compliant tools can be built to further concretize the high-level QoS policies defined in QPIM terms so that actual network elements (PEPs) can be configured to enforce the abstract business policy. 7. QPIM is QoS technology-agnostic, as it assumes no particular mechanism (e.g., class-based weighted fair queuing) for policy enforcement. For example, a certain policy may require that traffic adhere to a given traffic profile. The traffic profile itself can be represented by an instance of the QosPolicyTrfcProf class. The properties of the profile class may include an attribute representing the average rate of traffic in units of bits per second. However, QPIM neither describes nor mandates a mechanism to perform the measuring mechanism itself. Specifying such mechanisms is in the realm of network modeling, not policy modeling. Though a particular QoS mechanism (e.g., class-based weighted fair queuing) is generic to many types of devices, individual devices may implement this generic mechanism differently. This necessitates a device-independent view of controlling QoS mechanisms, which is precisely what QPIM is intended for. A single QPIM policy can be translated into different configurations of different devices. For example, a network interface card that can be configured to implement several output queues and assign size and bandwidth allocation parameters to each of them is a concrete element whose configuration can be controlled with QPIM policies. Snir, Ramberg, Strassner, Cohen expires November 2001 9 draft-ietf-policy-qos-info-model-03.txt April 2001 8. QPIM adheres to and interprets the two predominant QoS paradigms: Differentiated (DiffServ) Services and Integrated Services (IntServ). While both DiffServ and IntServ inherently model technology, the mechanisms implementing those technologies are not specified and are left to the implementer's interpretation. DiffServ and IntServ are described in [DIFFSERV] and [INTSERV], respectively. The term RSVP refers to a protocol developed to implement IntServ [RSVP]. The terms IntServ and RSVP are sometime used interchangeably. 9. QPIM is a network-end-to-end model. This means that QPIM policies can describe the QoS allocated to traffic throughout the network. QPIM does not represent explicitly network topological concepts. Section 4.6 of [PCIMe] explains a role based mechanism that can be used for mapping policies to PEPs. Neither [PCIM], [PCIMe] nor [QPIM] require a particular topological view of the network in order to express abstract policy. 1.3. QPIM and Other Published Standards QPIM makes extensive use of the concepts and constructs that are introduced by [PCIM] and [PCIMe]. The entire QPIM class hierarchy is derived from [PCIM] and [PCIMe] classes. The concepts of policy, policy groups, policy conditions, reusable objects values and variables are used in QPIM directly. QPIM only introduces extensions where QoS actions, values and variables are necessary to add QoS specific semantics to the framework defined by [PCIM] and [PCIMe]. By modeling the information of both predominant QoS paradigms, DiffServ and IntServ, QPIM unifies the two methodologies using a single class inheritance tree, thus allowing a single context for thinking about QoS policy. Companion documents (e.g., [QoSSCHEMA]) define the mapping of QPIM's classes to specific data models (schemata). For example, [QoSSCHEMA] defines how to map the data in this information model to a form that can be stored in a directory that uses LDAPv3 as its access protocol. QPIM adheres to terminology as defined in [TERMS]. QPIM intentionally avoids references to documents that present network models. A network model is the OBJECT of policy. QPIM models the SUBJECT of policy. The latter distinction makes it inappropriate for QPIM to model the actual network. An example for network modeling is available in [QDDIM], a document that models QoS device data path and capabilities. Snir, Ramberg, Strassner, Cohen expires November 2001 10 draft-ietf-policy-qos-info-model-03.txt April 2001 2. Class Hierarchies 2.1. Inheritance Hierarchy QPIM's inheritance hierarchy is rooted in [PCIM] and [PCIMe]. Figures 1 and 2 depict the QPIM inheritance hierarchy while noting its relationships to [PCIM] and [PCIMe] classes. Figure 1 shows the QPIM inheritance hierarchy,. [ManagedElement] (abstract, PCIM) | +--Policy (abstract, PCIM) | | | +---PolicyAction (abstract, PCIM) | | | | | +---SimplePolicyAction (PCIMe) | | | | | | | +---QoSPolicyRSVPSimpleAction (QPIM) | | | | | +---QoSPolicyDiscardAction (QPIM) | | | | | +---QoSPolicyAdmissionAction (abstract, QPIM) | | | | | | | +---QoSPolicyPoliceAction (QPIM) | | | | | | | +---QoSPolicyShapeActionAction (QPIM) | | | | | | | +---QoSPolicyRSVPAdmissionAction (QPIM) | | | | | +---QosPolicyPHBAction (abstract, QPIM) | | | | | +---QoSPolicyBandwidthAction (QPIM) | | | | | +---QoSPolicyCongestionControlAction (QPIM) | | | +---QosPolicyTrfcProf (abstract, QPIM) | | | | | +---QosPolicyTokenBucketTrfcProf (QPIM) | | | | | +---QosPolicyIntServTrfcProf (QPIM) | | (continued on the next page) Snir, Ramberg, Strassner, Cohen expires November 2001 11 draft-ietf-policy-qos-info-model-03.txt April 2001 (continued from the previous page) [ManagedElement] (abstract, PCIM, repeated for convenience) | +--Policy (abstract, PCIM, repeated for convenience) | | | +---PolicyVariable (abstract, PCIMe) | | | | | +---PolicyImplicitVariable (abstract, PCIMe) | | | | | +---QoSPolicyRSVPVariable (abstract, QPIM) | | | | | +---QoSPolicyRSVPSourceIPv4Variable (QPIM) | | | | | +---QoSPolicyRSVPDestinationIPv4Variable (QPIM) | | | | | +---QoSPolicyRSVPSourceIPv6Variable (QPIM) | | | | | +---QoSPolicyRSVPDestinationIPv6Variable (QPIM) | | | | | +---QoSPolicyRSVPSourcePortVariable (QPIM) | | | | | +---QoSPolicyRSVPDestinationPortVariable (QPIM) | | | | | +---QoSPolicyRSVPIPProtocolVariable (QPIM) | | | | | +---QoSPolicyRSVPIPVersionVariable (QPIM) | | | | | +---QoSPolicyRSVPDCLASSVariable (QPIM) | | | | | +---QoSPolicyRSVPStyleVariable (QPIM) | | | | | +---QoSPolicyRSVPDIntServVariable (QPIM) | | | | | +---QoSPolicyRSVPMessageTypeVariable (QPIM) | | | | | +---QoSPolicyRSVPPreemptionPriorityVariable (QPIM) | | | | | +---QoSPolicyRSVPPreemptionDefPriorityVariable (QPIM) | | | | | +---QoSPolicyRSVPUserVariable (QPIM) | | | | | +---QoSPolicyRSVPApplicationVariable (QPIM) | | | | | +---QoSPolicyRSVPAuthMethodVariable (QPIM) | | | +---PolicyValue (abstract, PCIMe) | | | | | +---QoSPolicyDNValue (QPIM) | | | | | +---QoSPolicyAttributeValue (QPIM) Figure 1. The QPIM Inheritance Hierarchy Snir, Ramberg, Strassner, Cohen expires November 2001 12 draft-ietf-policy-qos-info-model-03.txt April 2001 2.2. Relationship Hierarchy Figure 2 shows the QPIM association hierarchy. [unrooted] (abstract, PCIM) | +---Dependency (abstract) | | | +--- QosPolicyTrfcProfInAdmissionAction (QPIM) | | | +--- QoSPolicyConformAction (QPIM) | | | +--- QoSPolicyExceedAction (QPIM) | | | +--- QoSPolicyViolateAction (QPIM) Figure 2. The QPIM Association Hierarchy Snir, Ramberg, Strassner, Cohen expires November 2001 13 draft-ietf-policy-qos-info-model-03.txt April 2001 3. QoS Actions This section describes the QoS actions that are modeled by QPIM. QoS actions are policy enforced network behaviors that are specified for traffic selected by QoS conditions. QoS actions are modeled using the classes PolicyAction (defined in [PCIM]), SimplePolicyAction (defined in [PCIMe]) and several QoS actions defined in this document (described below). 3.1 Overview QoS policy based systems allow the network administrator to specify a set of rules that control both the selection of the flows that need to be provided with a preferred forwarding treatment, as well as specifying the specific set of preferred forwarding behaviors. QPIM provides an information model for specifying such a set of rules. QoS policy rules allow controlling environments in which RSVP signaling is used to request different forwarding treatment for different traffic types from the network as well as environments where no signaling is used, but preferred treatment is desired for some (not all) traffic. QoS policy rules allow controlling environments where strict QoS guarantees are provided to individual flows as well as environments where QoS is provided to flow aggregates. QoS actions allow a PDP or a PEP to determine which RSVP requests should be admitted because they satisfy a given policy, before network resources are allocated. They allow control of the RSVP signaling content itself, as well as differentiation between priorities of requests. QoS actions also allow specification of the Differential Service edge enforcement including policing, shaping and marking, as well as the per-hop behaviors used in the network core. Finally, QoS actions can be used to control mapping of RSVP request at the edge of a differential service cloud into per hop behaviors. Four groups of actions are derived from action classes defined in [PCIM] and [PCIMe]. The first QoS action group contains a single action, QoSPolicyRSVPSimpleAction. This action is used for both signal control and install actions depending on a type attribute. The second QoS action group determines whether a flow or class of flows should be admitted. This is done by specifying an appropriate traffic profile. These set of actions are called QoS admission actions. The third group of actions control bandwidth allocation and congestion control differentiations, which together specify the per-hop behavior forwarding treatment. The forth QoS action is unconditional packet discard action. This action is used either by itself or as a building block of the QoSPolicyPoliceAction. Note that some QoS actions are not directly modeled. Instead, they are modeled by using the class SimplePolicyAction with the appropriate associations. For example, the three marking actions (DSCP, IPP and CoS) are modeled by using the SimplePolicyAction class, associating it with variables and values of the appropriate type. Snir, Ramberg, Strassner, Cohen expires November 2001 14 draft-ietf-policy-qos-info-model-03.txt April 2001 3.2 RSVP Policy Actions There are three types of decisions a PDP (either remote or within a PEP) can make when it evaluates an RSVP request: 1. Admit or reject the request 2. Use admission parameters to decide whether to admit the request or not 3. Use signaling parameters to decide how to modify the RSVP signaling messages The COPS for RSVP [RFC2749] specification uses different Decision object types to model each of these decisions. QPIM follows the COPS specification and models each decision using a different action class. The QoSPolicyRSVPAdmissionAction with its associated QosPolicyIntServTrfcProf determine whether to accept or reject a given RSVP request by comparing the RSVP request's TSPEC or RSPEC parameters against the traffic profile. For a full description of the comparison method, see section 4, which describes traffic profiles in more detail. Using the QoSPolicyRSVPAdmissionAction, a limit on the number of admitted reservations can be enforced as well. The QoSPolicyRSVPAdmissionAction can specify that a set of RSVP requests will be accepted yet a warning message would be sent to the RSVP end points. The QoSPolicyRSVPAdmissionAction controls the Decision Command and Decision Flags objects used within COPS for RSVP. The class QoSPolicyRSVPSimpleAction, which is derived from the PolicySimpleAction class [PCIMe], can be used to specify RSVP decisions. The property qpRSVPActionType designates the instance of the class to be either of type 'REPLACE', 'STATELESS', or both. For instances carrying a qpRSVPActionType property value of 'REPLACE', the action is interpreted as a COPS Replace Decision, controlling the contents of the RSVP message. For instances carrying a qpRSVPActionType property value of 'STATELESS', the action is interpreted as a COPS Stateless Decision, controlling the admission parameters. If both of these actions are required, this can be done by assigning both of the two qpRSVPActionType values, since it is a multi-valued property. This class is modeled to represent the COPS for RSVP Replace and Stateless decisions. This similarity allows future use of these COPS decisions to be directly controlled by a QoSPolicySimpleAction. The only required extension might be the definition of a new RSVP variable. Snir, Ramberg, Strassner, Cohen expires November 2001 15 draft-ietf-policy-qos-info-model-03.txt April 2001 Example: Controlling COPS Stateless Decision The QoSPolicyRSVPSimpleAction allows the specification of admission parameters. It allows specification of the preemption priority [RFC2751] of a given RSVP Reservation request. Using the preemption priority value, the PEP can determine the importance of a Reservation compared with already admitted reservations, and if necessary can preempt lower priority reservations to make room for the higher priority one. This class can also be used to control mapping of RSVP requests to a differentiated services domain by setting the QoSPolicyRSVPDSCPVariable to the required value. This instructs the PEP to mark traffic matching the Session and Sender specifications carried in an RSVP request to a given DSCP value. Example: Controlling the COPS Replace Decision A Policy system should be able to control the information carried in the RSVP messages. The QoSPolicyRSVPSimpleAction allows control of the content of RSVP signaling messages. An RSVP message can carry a preemption policy object [RFC2751] specifying the priority of the reservation request in comparison to other requests. An RSVP message can also carry a policy object for authentication purposes. An RSVP message can carry a DCLASS [DCLASS] object that specifies to the receiver or sender the particular DSCP value that should be set on the data traffic. A COPS for RSVP Replacement Data Decision controls the content of the RSVP message by specifying a set of RSVP objects replacing or removing the existing ones. 3.3 Provisioning Policy Actions The differentiated Service Architecture [DIFFSERV] was designed to provide a scalable QoS differentiation without requiring any signaling protocols running between the hosts and the network. The QoS actions modeled in QPIM can be used to control all the building blocks of the Differentiated Service architecture, including per-hop behaviors, edge classification, and policing and shaping, without a need to specify the datapath mechanisms used by PEP implementations. This provides an abstraction level hiding the unnecessary details and allowing the network administrator to write rules that express the network requirements in a more natural form. In this architecture, as no signaling between the end host and the network occur before the sender starts sending information, the QoS mechanisms should be setup in advance. This usually means that PEPs need to be provisioned with the set of policy rules in advance. Policing and Shaping actions are modeled as sub-classes of the QoS admission action. DSCP and CoS marking are modeled as sub-classes of the simplePolicyAction class. Bandwidth allocation, scheduling and congestion control actions are modeled as sub-classes of the QoS PHB action. Snir, Ramberg, Strassner, Cohen expires November 2001 16 draft-ietf-policy-qos-info-model-03.txt April 2001 3.3.1. Admission Actions: Controlling Policers and Shapers All Admission Actions have in common an association to a traffic profile and a scope property that determines whether the traffic profile is compared against the rate parameters of each flow or against the aggregate rate of all flows that match the rule's condition. For example, using two provisioned policer actions the following policies can be enforced: - Make sure that each HTTP flow will not exceed 64kb/s - Make sure that the aggregate rate of all HTTP flows will not exceed 512Kb/s Both policies are modeled using the same QoSPolicyPoliceAction. The first policy has its scope property set to 'flow', while the second policy has its scope property set to 'class'. The two policies are modeled using a rule with two police actions that, in a pseudo formal definition, looks like the following: If (HTTP) Action1=police, Traffic Profile1=64kb/s, Scope1=flow Action2=police, Traffic Profile2=512kb/s, Scope2=class The provisioned policer action QoSPolicyPoliceAction has 3 associations, QoSPolicyConformAction, QoSPolicyExceedAction and QoSPolicyViolateAction. The policer action is associated with a three-level token bucket traffic profile carrying rate, burst and excess-burst parameters. Traffic measured by a meter can be classified as conforming traffic when the metered rate is below the rate defined by the traffic profile, as excess traffic when the metered traffic is above the normal burst and below the excess burst size, and violating traffic when rate is above the maximum excess burst. The [DIFF-MIB] defines a two-level meter, and provides a means to combine two-level meters into more complex meters. In this document, a three- level traffic profile is defined. This allows construction of both two- level meters as well as providing an easier definition for three-level meters needed for creating AF [AF] provisioning actions. A policer action with a non-specified conform action implies that conforming traffic should not be modified. A policer action with an associated three-level traffic profile that does not specify an excess action implies that the excess traffic should be treated as either violating or conforming traffic according to some algorithm suitable for the enforcement of the rule. For example, the final enforcement of such a rule may be the use of a random function similar to RED to determine whether traffic is conforming or violating. A policer action with a three-level traffic profile that specifies an exceed action but does not specify a violate action implies that violate action is identical to the specified exceed action. Snir, Ramberg, Strassner, Cohen expires November 2001 17 draft-ietf-policy-qos-info-model-03.txt April 2001 Shapers are used to delay some or all of the packets in a traffic stream in order to bring the stream into compliance with a traffic profile. A shaper usually has a finite-sized buffer, and packets may be discarded if there is not sufficient buffer space to hold the delayed packets. Shaping is controlled by the QoSPolicyShapeAction class. The only required association is a traffic profile that specifies the rate and burst parameters that the outgoing flows should conform with. 3.3.2 Controlling Markers Three types of markers are modeled in QPIM: Differentiated Services Code Point (DSCP), IP Precedence (IPP) and layer-2 Class of Service (CoS). The marking action itself is modeled by using the SimplePolicyAction class associated with the appropriate variables and values. DSCP markers set the DS field of a packet header to a particular DS Code Point (DSCP), adding the marked packet to a particular DS behavior aggregate. The marker may be configured to mark all packets that it receives to a single DSCP, or may be configured to mark a packet to one of a set of DSCPs used to select a PHB in a PHB group according to the state of a meter. This can be achieved by associating a marking action with a policer action using the conform, exceed and violate action associations. The semantics of the DSCP marker is encapsulated in the pairing of a DSCP variable and a DSCP value within a single SimplePolicyAction instance via the appropriate associations. IPP markers set the IPP field of a packet header to a particular IPP value (0 through 7). The semantics of the IPP marker is encapsulated in the pairing of a DSCP variable masked to IPP sub-field and a DSCP value masked to IPP sub-field within a single SimplePolicyAction instance via the appropriate associations. CoS markers control the mapping of a per-hop behavior to a layer-2 Class of Service. For example, mapping of a set of DSCP values into a 802.1q user priority value can be specified using a rule with a condition describing the set of DSCP values, and a CoS marking action that specifies the required mapping to the given user ‚Çôpriority value. The semantics of the CoS marker is encapsulated in the pairing of a CoS variable and a CoS value (integer in the range of 0 through 7) within a single SimplePolicyAction instance via the appropriate associations. 3.3.3 Controlling Edge Policies - Examples Assuming that the AF1 behavior aggregate is enforced within a DS domain, policy rules on the edge of the network should mark packets to one of the AF1x DSCPs depending on conformance to a predetermined three-parameter traffic profile. QPIM models such AF1 policing action as defined in Figure 3. Snir, Ramberg, Strassner, Cohen expires November 2001 18 draft-ietf-policy-qos-info-model-03.txt April 2001 +-----------------------+ +------------------------------+ | QoSPolicyPoliceAction |====| QoSPolicyTokenBucketTrfcProf | | scope = class | | rate = x, bc = y, be = z | +-----------------------+ +------------------------------+ * @ # * @ # * @ +-------------------------+ +--------------------+ * @ | SimplePolicyAction |---| PolicyIntegerValue | * @ +-------------------------+ | AF13 | * @ +--------------------+ * +-------------------------+ +--------------------+ * | SimplePolicyAction |---| PolicyIntegerValue | * +-------------------------+ | AF12 | * +--------------------+ +-------------------------+ +--------------------+ | SimplePolicyAction |---| PolicyIntegerValue | +-------------------------+ | AF11 | +--------------------+ Association and Aggregation Legend: **** QoSPolicyConformAction @@@@ QoSPolicyExceedAction #### QoSPolicyViolateAction ==== QoSTrfcProfInAdmissionAction ---- PolicyValueInSimplePolicyAction ([PCIMe]) &&&& PolicyVariableInSimplePolicyAction ([PCIMe], not shown) Figure 3. AF Policing and Marking The marker is made of an instance of the SimplePolicyAction class. The aggregation PolicyVariableInSimplePolicyAction (which is defined in [PCIMe]) is used to associate the value to mark (contained in the PolicyDSCPValue) with the appropriate traffic action. This aggregation is not shown in this figure for simplicity. AF11 is marked on conforming traffic; AF12 is marked on exceeding action and AF13 on violating traffic. The second example, shown in Figure 4, is the simplest policing action. Traffic below a two-parameter traffic profile is unmodified, while traffic exceeding the traffic profile is discarded. Snir, Ramberg, Strassner, Cohen expires November 2001 19 draft-ietf-policy-qos-info-model-03.txt April 2001 +-----------------------+ +------------------------------+ | QoSPolicyPoliceAction |====| QoSPolicyTokenBucketTrfcProf | | scope = class | | rate = x, bc = y | +-----------------------+ +------------------------------+ @ @ +-------------------------+ | QoSPolicyDiscardAction | +-------------------------+ Association and Aggregation Legend: **** QoSPolicyConformAction (not used) @@@@ QoSPolicyExceedAction #### QoSPolicyViolateAction (not used) ==== QoSTrfcProfInAdmissionAction Figure 4. A Simple Policing Action 3.4 Per-Hop Behavior Actions A Per-Hop Behavior (PHB) is a description of the externally observable forwarding behavior of a DS node applied to a particular DS behavior aggregate [DIFFSERV]. The approach taken here is that a PHB action specifies both observable forwarding behavior (i.e., loss, delay, jitter) as well as specifying the buffer and bandwidth resources that need to be allocated to each of the behavior aggregates in order to achieve this behavior. That is, a rule with a set of PHB actions can specify that an EF packet must not be delayed more than 20 msec in each hop. The same rule may also specify that EF packets need to be treated with preemptive forwarding (e.g., with priority queuing), and specify the maximum bandwidth for this class as well as the maximum buffer resources. PHB actions can therefore be used to both represent the final requirements from PHBs as well as provide enough detail to be able to map the PHB actions into a set of configuration parameters to configure queues, schedulers, droppers and other mechanisms. The QoSPolicyPHBAction abstract class has two subclasses. The QoSPolicyBandwidthAction class is used to control bandwidth, delay and forwarding behavior, while the QoSPolicyCongestionControlAction class is used to control queue size, thresholds and congestion algorithms. The qpPacketSize property of the PHB action specifies the packet size in bytes, and is needed when translating the actions into actual implementation configurations. For example, implementation measuring queue length in bytes will need to use this property to map the qpQueueSize property into queue length in bytes. Snir, Ramberg, Strassner, Cohen expires November 2001 20 draft-ietf-policy-qos-info-model-03.txt April 2001 3.4.1 Controlling Bandwidth and Delay QoSPolicyBandwidthAction allows specifying the minimal bandwidth that should be reserved for a class of traffic. The property qpMinBandwidth can be specified either in Kb/sec or in percentage of the total available bandwidth. The property qpBandwidthUnits is used to determine whether percentage or fixed values are used. The property qpForwardingPriority is used whenever preemptive forwarding is required. A policy rule that defines the EF PHB should indicate a non- zero forwarding priority. The qpForwardingPriority property holds an integer value to enable multiple levels of preemptive forwarding where higher values are used to specify higher priority. The property qpMaxBandwidth specifies the maximum bandwidth that should be allocated to a class of traffic. This property may be specified in PHB actions with non-zero forwarding priority in order to guard against starvation of other PHBs. The properties qpMaxDelay and qpMaxJitter specify limits on the per-hop delay and jitter in milliseconds for any given packet within a traffic class. Enforcement of the maximum delay and jitter may require use of preemptive forwarding as well as minimum and maximum bandwidth controls. Enforcement of low max delay and jitter values may also require fragmentation and interleave mechanisms over low speed links. The Boolean property qpFairness indicates whether flows should have a fair chance to be forwarded without drop or delay. A way to enforce a bandwidth action with qpFairness set to TRUE would be to build a queue per flow for the class of traffic specified in the rule's filter. In this way, interactive flows like terminal access will not be queued behind a bursty flow (like FTP) and therefore have a reasonable response time. 3.4.2 Congestion Control Actions The QoSPolicyCongestionControlAction class controls queue length, thresholds and congestion control algorithms. A PEP should be able to keep in its queues qpQueueSize packets matching the rule's condition. In order to provide a link-speed independent queue size, the qpQueueSize can also be measured in milliseconds. The time interval specifies the time needed to transmit all packets within the queue if the link speed is dedicated entirely for transmission of packets within this queue. The property qpQueueSizeUnit determines whether queue size is measured in number of packets or in milliseconds. The property qpDropAlgorithm selects either tail-drop, head-drop or random-drop algorithms. The set of maximum and minimum threshold values can be specified as well, using qpThresholdMin and qpThresholdMax properties, either in packets or in percentage of the total available queue size as specified by the qpThresholdUnits property. Snir, Ramberg, Strassner, Cohen expires November 2001 21 draft-ietf-policy-qos-info-model-03.txt April 2001 3.4.3 Using Hierarchical Policies ‚Çô Examples for PHB actions Hierarchical policy definition is a primary tool in the QoS Policy Information model. Rule nesting introduced in [PCIMe] allows specification of hierarchical policies controlling RSVP requests, hierarchical shaping, policing and marking actions, as well as hierarchical schedulers and definition of the differences in PHB groups. An example of the use of hierarchical schedulers is provided in [PCIMe]. This example provides a set of rules that specify PHBs enforced within a Differentiated Service Domain. The network administrator chose to enforce the EF, AF11 and AF13 and Best Effort PHBs. For simplicity, AF12 is not differentiated. The set of rules takes the form: If (EF) then do EF actions If (AF1) then do AF1 actions If (AF13) then do AF13 actions If (default) then do Default actions. EF, AF1 and AF13 are conditions that filter traffic according to DSCP values. The AF1 condition matches the entire AF1 PHB group including the AF11, AF12 and AF13 DSCP values. The default rule uses a 'match all' condition and specifies the Best Effort rules. The nesting of the AF13 rule within the AF1 rule specifies that there are further refinements on how AF13 traffic should be treated relative to the entire AF1 PHB group. The set of rules reside in a PolicyGroup with a decision strategy property set to 'MATCH FIRST'. The class instances below specify the set of actions used to describe each of the PHBs. Queue sizes are not specified, but can easily be added to the example. The actions used to describe the Best Effort PHB are simple. No bandwidth is allocated to Best Effort traffic. The first action specifies that Best Effort traffic class should have fairness. QosPolicyBandwidthAction BE-B: qpFairness: True The second action specifies that the congestion algorithm for the Best Effort traffic class should be random, and specifies the thresholds in percentage of the default queue size. QoSPolicyCongestionControlAction BE-C: qpDropAlgorithm: random qpDropThresholdUnits % qpDropMinThreshold: 10% qpDropMaxThreshold: 70% Snir, Ramberg, Strassner, Cohen expires November 2001 22 draft-ietf-policy-qos-info-model-03.txt April 2001 EF requires preemptive forwarding. The maximum bandwidth is also specified to make sure that the EF class does not starve the other classes. EF PHB uses tail drop as the applications using EF are supposed to be UDP-based and therefore would not benefit from a random dropper. QosPolicyBandwidthAction EF-B: qpForwardingPriority: 1 qpBandwidthUnits: % qpMaxBandwidth 50% qpFairness: False QoSPolicyCongestionControlAction EF-C: QpDropAlgorithm: tail-drop qpDropThresholdUnits packet qpDropMaxThreshold: 3 packets The AF1 actions define the bandwidth allocations and thresholds for the entire PHB group: QosPolicyBandwidthAction AF1-B: qpBandwidthUnits: % qpMinBandwidth: 30% QoSPolicyCongestionControlAction AF1-C: QpDropAlgorithm: random qpDropThresholdUnits packet qpDropMinThreshold: 4 packets qpDropMaxThreshold: 20 packets The AF13 action specifies the differentiating refinement for the AF13 PHB within the AF1 PHB group. The lower threshold values provide the higher discard probability of the AF13 PHB. QosPolicyCongestionControlAction AF13-C: QpDropAlgorithm: random qpDropThresholdUnits packet qpDropMinThreshold: 2 packets qpDropMaxThreshold: 10 packets 4. Traffic Profiles Meters measure the temporal state of a flow or a set of flows against a traffic profile. In this document, traffic profiles are modeled by the gpsPolicyTrfcProf class. The association QoSPolicyTrfcProfileInAdmissionAction binds the traffic profile to the admission action using it. Two traffic profiles are derived from the abstract class gpsPolicyTrfcProf. The first is a Token Bucket Provisioning traffic profile carrying rate and burst parameters. The second is an RSVP traffic profile, which enables flows to be compared with RSVP TSPEC and FLOWSPEC parameters. Snir, Ramberg, Strassner, Cohen expires November 2001 23 draft-ietf-policy-qos-info-model-03.txt April 2001 4.1 Provisioning Traffic Profiles Provisioned Admission Actions including Shaping and policing are specified using a two- or three-parameter token bucket traffic profile. The qosPolicyTokenBucketTrfcProf class includes the following properties: 1. Rate measured in kbits/sec 2. Normal burst measured in bytes 3. Excess burst measured in bytes Rate determines the long-term average transmission rate. Traffic that falls under this rate is conforming, as long as the normal burst is not exceeded at any time. Traffic exceeding the normal burst but still below the excess burst is exceeding the traffic profile. Traffic beyond the excess burst is said to be violating the traffic profile. Excess burst size is measured in bytes in addition to the burst size. A zero excess burst size indicates that no excess burst is allowed. 4.2 RSVP traffic profiles RSVP admission policy can condition the decision whether to accept or deny an RSVP request based on the traffic specification of the flow (TSPEC) or the amount of QoS resources requested (FLOWSPEC). The admission decision can be based on matching individual RSVP requests against a traffic profile or by matching the aggregated sum of all FLOWSPECs (TSPECs) currently admitted. The QosPolicyIntesrvTrfcProf class models both such traffic profiles. This class has the following properties: 1. Token Rate (r) measured in bits/sec 2. Peak Rate (p) measured in bits/sec 3. Bucket Size (b) measured in bytes 4. Min Policed unit (m) measured in bytes 5. Max packet size (M) measured in bytes 6. Resv Rate (R) measured in bits/sec 7. Slack term (s) measured in microseconds The first 5 parameters are the traffic specification parameters used in the integrated service architecture. These parameters are used to define a sender TSPEC as well as FLOWSPEC for the Controlled-Load service [CL]. For a definition and full explanation of their meaning, please refer to [RSVP-IS]. Parameters 6 and 7 are the additional parameters used for specification of the Guaranteed Service FLOWSPEC [GS]. Snir, Ramberg, Strassner, Cohen expires November 2001 24 draft-ietf-policy-qos-info-model-03.txt April 2001 A partial order is defined between TSPECs (and FLOWSPECs). The TSPEC A is larger than the TSPEC B if and only if rA>rB, pA>pB, bA>bB, mAMB. A TSPEC (FLOWSPEC) measured against a traffic profile uses the same ordering rule. An RSVP message is accepted only if its TSPEC (FLOWSPEC) is either smaller or equal to the traffic profile. Only parameters specified in the traffic profile are compared. The GS FLOWSPEC is also compared against the rate R and the slack term S. R should not be larger than the traffic profile R parameter, while the FLOWSPEC slack term should not be smaller than that specified in the slack term. TSPECs as well as FLOWSPECs can be added. The sum of two TSPECs is computed by summing the rate r, the peak rate p, the bucket size b, and by taking the minimum value of the minimum policed unit m and the maximum value of the maximum packet size M. GS FLOWSPECs are summed by adding the Resv rate and minimizing the slack term s. These rules are used to compute the temporal state of admitted RSVP states matching the traffic class defined by the rule condition. This state is compared with the traffic profile to arrive to an admission decision when the scope of the QoSPolicyRSVPAdmissionAction is set to 'class'. 5. Pre-Defined QoS-Related Variables Pre-defined variables are necessary for ensuring interoperability among policy servers and policy management tools from different vendors. The purpose of this section is to define frequently used variables in QoS policy domains. Notice that this section only adds to the variable classes as defined in [PCIMe] and reuses the mechanism defined there. The QoS policy information model specifies a set of pre-defined variable classes to support a set of fundamental QoS terms that are commonly used to form conditions and actions and are missing from the [PCIMe]. Examples of these include RSVP related variables. All variable classes defined in this document extend the PolicyImplictVariable class, defined in [PCIMe]. Subclasses specify the data type and semantics of the policy variables. This Draft defines the following RSVP variable classes, for details see class definition: Snir, Ramberg, Strassner, Cohen expires November 2001 25 draft-ietf-policy-qos-info-model-03.txt April 2001 RSVP related Variables: 1. QoSPolicyRSVPSourceIPv4Variable - The source IP address of the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP] objects. 2. QoSPolicyRSVPDestinationIPv4Variable - The destination port of the RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP] objects. 3. QoSPolicyRSVPSourceIPv6Variable - The source IP address of the RSVP signaled flow, as defied in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP] objects. 4. QoSPolicyRSVPDestinationIPv6Variable - The destination port of the RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP] objects. 5. QoSPolicyRSVPSourcePortVariable - The source port of the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP] objects. 6. QoSPolicyRSVPDestinationPortVariable - The destination port of the RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP] objects. 7. QoSPolicyRSVPIPProtocolVariable - The IP Protocol of the RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP] objects. 8. QoSPolicyRSVPIPVersionVariable - The IP version of the IP Addresses carried the RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP] objects. 9. QoSPolicyRSVPDCLASSVariable - The DSCP value as defined in the RSVP DCLASS [DCLASS] object. 10. QoSPolicyRSVPStyleVariable - The reservation style (FF, SE, WF) as defined in the RSVP Resv message [RSVP]. 11. QoSPolicyRSVPIntServVariable - The integrated Service (CL, GS, NULL) requested in the RSVP Reservation message, as defined in the FLOWSPEC RSVP Object [RSVP]. 12. QoSPolicyRSVPMessageTypeVariable - The RSVP message type, either Path, Resv, PathErr or ResvErr [RSVP]. 13. QoSPolicyRSVPPreemptionPriorityVariable - The RSVP reservation priority as defined in [RFC2751]. 14. QoSPolicyRSVPPreemptionDefPriorityVariable - The RSVP preemption reservation defending priority as defined in [RFC2751]. 15. QoSPolicyRSVPUserVariable - The ID of the user that initiated the flow as defined in the User Locator string in the Identity Policy Object [RFC2752]. 16. QoSPolicyRSVPApplicationVariable - The ID of the application that generated the flow as defined in the application locator string in the Application policy object [RFC2872] 17. QoSPolicyRSVPAuthMethodVariable - The RSVP Authentication type used in the Identity Policy Object [RFC2752]. Each class restricts the possible value types associated with a specific variable. For example, the QoSPolicyRSVPSourcePortVariable class is used to define the source port of the RSVP signaled flow. The value associated with this variable is of type integer. Snir, Ramberg, Strassner, Cohen expires November 2001 26 draft-ietf-policy-qos-info-model-03.txt April 2001 6. QoS Related Values Values are used in the information model as building blocks for the policy conditions and policy actions, as described in [PCIM] and [PCIMe]. This section defines a set of auxiliary values that are used for QoS policies as well as other policy domains. All value classes extend the PolicyImplicitValue class [PCIMe]. The subclasses specify specific data/value types that are not defined in [PCIMe]. This document defines the following two subclasses of the PolicyImplicitValue class: QoSPolicyDNValue - This class is used to represent a single or set of Distinguished Name [DNDEF] values, including wildcards. A Distinguished Name is a name that can be used as a key to retrieve an object from a directory service. This value can be used in comparison to reference values carried in RSVP policy objects, as specified in [RFC2752]. This class is defined in Section 8.31. QoSPolicyAttributeValue - This class is used to represent a single or set of property values in an object. This value can be used in conjunction with reference values carried in RSVP objects, as specified in [RFC2752]. The property name is used to specify which of the properties in the object is being used as the condition. The value of this property will then be retrieved, and a match (which is dependent on the property name) will be used to see if the condition is satisfied or not. For example, suppose a User class has a multi-valued Property called 'member-of' that lists the names of groups that this user belongs to. Suppose this property uses caseIgnoreMatch matching. A simple condition can be constructed to match the reference carried in an RSVP Identity policy object to a gpsPolicyAttributeValue with the following characteristics: gpAttributeName="member-of", gpAttributeValueList = "group-A". A User Identity policy object carrying the following reference: "OU=Sales, CN=J. Smith, O=Widget Inc." will match this simple condition only if J. Smith belongs to group-a. Snir, Ramberg, Strassner, Cohen expires November 2001 27 draft-ietf-policy-qos-info-model-03.txt April 2001 7. Class Definitions: Association Hierarchy The following sections define associations that are specified by QPIM. 7.1. The Association "QosPolicyTrfcProfInAdmissionAction" This association links a gpsPolicyTrfcProf object modeling a specific traffic profile to a QoSPolicyAdmissionAction object. The class definition for this association is as follows: NAME QosPolicyTrfcProfInAdmissionAction DESCRIPTION A class representing the association between a traffic profile used for admission decision DERIVED FROM Dependency ABSTRACT FALSE PROPERTIES Antecedent[ref QoSPolicyAdmissionAction [0..n]] Dependent[ref QoSPolicyTrfcProf [0..n]] 7.1.1. The Reference "Antecedent" This property is inherited from the Dependency association, defined in [PCIM]. Its type is overridden to become an object reference to a QoSPolicyAdmissionAction object. This represents the "independent" part of the association. The [0..n] cardinality indicates that a given QoSPolicyAdmissionAction object may have 0 or more traffic profiles that it can use. 7.1.2. The Reference "Dependent" This property is inherited from the Dependency association, and is overridden to become an object reference to a QoSPolicyTrfcProfile object. This represents a specific traffic profile that is used by a given QoSPolicyAdmissionAction. The [0..n] cardinality means that a given traffic profile may be used by 0 or more admission actions. 7.2 The Association "PolicyConformAction" This association links a policer action with an object defining an action to be applied on conforming traffic relative to the associated traffic profile. The class definition for this association is as follows: NAME PolicyConformAction DESCRIPTION A class representing the association between a policer action and the action that should be applied on traffic conforming to an associated traffic profile. DERIVED FROM Dependency ABSTRACT FALSE PROPERTIES Antecedent[ref QoSPolicyPoliceAction[0..n]] Dependent[ref PolicyAction [0..1]] Snir, Ramberg, Strassner, Cohen expires November 2001 28 draft-ietf-policy-qos-info-model-03.txt April 2001 7.2.1. The Reference "Antecedent" This property is inherited from the Dependency association. Its type is overridden to become an object reference to a QoSPolicyPoliceAction object. This represents the "independent" part of the association. The [0..n] cardinality indicates that any number of QoSPolicyPoliceAction objects may be given the same action to be executed as the conforming action. 7.2.2. The Reference "Dependent" This property is inherited from the Dependency association, and is overridden to become an object reference to a PolicyAction object. This represents a specific policy action that is used by a given QoSPolicyPoliceAction. The [1..1] cardinality means that a given conforming action may only be used by a single QoSPolicyPoliceAction. 7.3. The Association "PolicyExcessAction" This association links a policer action with an object defining an action to be applied on traffic exceeding the associated traffic profile. The class definition for this association is as follows: NAME PolicyExcessAction DESCRIPTION A class representing the association between a policer action and the action that should be applied on traffic exceeding an associated traffic profile. DERIVED FROM Dependency ABSTRACT FALSE PROPERTIES Antecedent[ref QoSPolicePoliceAction[0..n]] Dependent[ref PolicyAction [0..1]] 7.3.1. The Reference "Antecedent" This property is inherited from the Dependency association. Its type is overridden to become an object reference to a QoSPolicyPoliceAction object. This represents the "independent" part of the association. The [0..n] cardinality indicates that any number of QoSPolicyPoliceAction objects may be given the same action to be executed as the exceeding action. 7.3.2. The Reference "Dependent" This property is inherited from the Dependency association, and is overridden to become an object reference to a PolicyAction object. This represents a specific policy action that is used by a given QoSPolicyPoliceAction. The [1..1] cardinality means that a given exceeding action may only be used by a single QoSPolicyPoliceAction. Snir, Ramberg, Strassner, Cohen expires November 2001 29 draft-ietf-policy-qos-info-model-03.txt April 2001 7.4. The Association "PolicyViolateAction" This association links a policer action with an object defining an action to be applied on traffic violating the associated traffic profile. The class definition for this association is as follows: NAME PolicyViolateAction DESCRIPTION A class representing the association between a policer action and the action that should be applied on traffic violating an associated traffic profile. DERIVED FROM Dependency ABSTRACT FALSE PROPERTIES Antecedent[ref QoSPolicePoliceAction[0..n]] Dependent[ref PolicyAction [0..1]] 7.4.1. The Reference "Antecedent" This property is inherited from the Dependency association. Its type is overridden to become an object reference to a QoSPolicyPoliceAction object. This represents the "independent" part of the association. The [0..n] cardinality indicates that any number of QoSPolicyPoliceAction objects may be given the same action to be executed as the violating action. 7.4.2. The Reference "Dependent" This property is inherited from the Dependency association, and is overridden to become an object reference to a PolicyAction object. This represents a specific policy action that is used by a given QoSPolicyPoliceAction. The [1..1] cardinality means that a given violating action may only be used by a single QoSPolicyPoliceAction. Snir, Ramberg, Strassner, Cohen expires November 2001 30 draft-ietf-policy-qos-info-model-03.txt April 2001 8. Class Definitions: Inheritance Hierarchy The following sections define object classes that are specified by QPIM. 8.1. The Class QoSPolicyDiscardAction This class is used to specify that packets should be discarded. This is the same as stating that packets should be denied forwarding. The class definition is as follows: NAME QoSPolicyDiscardAction DESCRIPTION This action specify that packets should be discarded. DERIVED FROM PolicyAction ABSTRACT False PROPERTIES None 8.2. The Class QoSPolicyAdmissionAction This class is the base class for performing admission decisions. It is used to determine whether to accept or reject a given RSVP request. This is done by comparing the RSVP request's TSPEC or RSPEC parameters against the traffic profile (as specified in the QosPolicyIntServTrfcProf class). The qpAdmissionScope property controls whether the comparison is done per flow or per class (of flows). Only packets that conform to the traffic profile are admitted for further processing; other packets are discarded. The class definition is as follows: NAME QoSPolicyAdmissionAction DESCRIPTION This action controls admission decisions based on comparison of a meter to a traffic profile. DERIVED FROM PolicyAction ABSTRACT True PROPERTIES qpAdmissionScope 8.2.1. The Property qpAdmissionScope This attribute specifies whether the admission decision is done per flow or per the entire class of flows defined by the rule condition. If the scope is per flow, the actual or requested rate of each flow is compared against the traffic profile. If the scope is set to class, the aggregate actual or requested rate of all flows matching the rule condition is measured against the traffic profile. The property is defined as follows: NAME qpAdmissionScope DESCRIPTION This property specifies whether the admission decision is done per flow or per the entire class of flows SYNTAX Integer VALUE This is an enumerated integer. A value of 0 specifies that admission is done on a per-flow basis, and a value of 1 specifies that admission is done on a per-class basis. Snir, Ramberg, Strassner, Cohen expires November 2001 31 draft-ietf-policy-qos-info-model-03.txt April 2001 8.3. The Class QoSPolicyPoliceAction This is the base class for defining policing actions (e.g., those actions that restrict traffic in some way). Using the three associations QoSPolicyConformAction, QoSPolicyExceedAction and QoSPolicyViolateAction, it is possible to specify different actions to take based on whether the traffic is conforming, exceeding, or violating a traffic profile. The traffic profile is specified in the QosPolicyTokenBucketTrfcProf class. The class definition is as follows: NAME QoSPolicyPoliceAction DESCRIPTION This action controls the operation of policers. The measured rate of flows is measured against a traffic profile. The action the needs to be performed on conforming, exceeding and violating traffic is indicated using the conform, exceed and violate action associations. DERIVED FROM QoSPolicyAdmissionAction ABSTRACT False PROPERTIES None 8.4. The Class QoSPolicyShapeAction This class is the base class for defining shaping actions. Shapers are used to delay some or all of the packets in a traffic stream in order to bring a particular traffic stream into compliance with a given traffic profile. The traffic profile is specified in the QosPolicyTokenBucketTrfcProf class. The class definition is as follows: NAME QoSPolicyShapeAction DESCRIPTION This action indicate that traffic should be shaped to be conforming with a traffic profile. DERIVED FROM QoSPolicyAdmissionAction ABSTRACT False PROPERTIES None Snir, Ramberg, Strassner, Cohen expires November 2001 32 draft-ietf-policy-qos-info-model-03.txt April 2001 8.5. The Class QoSPolicyRSVPAdmissionAction This class determines whether to accept or reject a given RSVP request by comparing the RSVP request's TSPEC or RSPEC parameters against the traffic profile. The traffic profile is specified in the QosPolicyIntServTrfcProf class. This class inherits the qpAdmissionScope property from its superclass. This property specifies whether admission should be done on a per-flow or per-class basis. If the traffic profile is not larger or equal to the requested reservation, or to the sum of the admitted reservation merged with the requested reservation, the result is a deny decision. If no traffic profile is specified, the assumption is that all traffic can be admitted. The class definition is as follows: NAME QoSPolicyRSVPAdmissionAction DESCRIPTION This action controls the admission of RSVP request. Depending on the scope, either a single RSVP request or the total admitted RSVP requests matching the conditions are compared against a traffic profile. DERIVED FROM QoSPolicyAdmissionAction ABSTRACT False PROPERTIES qpRSVPWarnOnly, qpRSVPMaxSessions 8.5.1. The Property qpRSVPWarnOnly When this property is set to True, the RSVP request is admitted, but an RSVP error message carrying a warning is sent to the originator (sender or receiver). This follows the COPS for RSVP send error flag in the Decision Flags object. This property is defined as follows: NAME qpRSVPWarnOnly SYNTAX Boolean Default False VALUE This property can have one of two values. The value 1 (TRUE) means that the request should be admitted AND an RSVP error message should be sent to the originator. The value of 0 (FALSE) means that the request should be admitted without sending an RSVP error message. 8.5.2. The Property qpRSVPMaxSessions This attribute is used to limit the total number of RSVP requests admitted within the specified class of traffic. The qpAdmissionScope property must be set to class (it is not applicable if the qpAdmissionScope property is set to "flow"). The definition of this property is as follows: NAME qpRSVPMaxSessions SYNTAX Integer VALUE Must be greater than 0. Snir, Ramberg, Strassner, Cohen expires November 2001 33 draft-ietf-policy-qos-info-model-03.txt April 2001 8.6. The Class QosPolicyPHBAction This class is a base class that is used to define the per-hop behavior that is to be assigned to behavior aggregates. It defines a common property, qpPacketSize, for use by its subclasses (QoSPolicyBandwidthAction and QoSPolicyCongestionControlAction). The class definition is as follows: NAME QosPolicyPHBAction DESCRIPTION This action controls the Per-Hop-Behavor provided to behavior aggregates. DERIVED FROM PolicyAction ABSTRACT True PROPERTIES qpPacketSize 8.6.1. The Property qpPacketSize This property specifies the maximum packet size in bytes of this class of packet. This attribute is used in translation of QPIM attributes to QoS mechanisms used within a PEP. For example, queue length may be measured in bytes while the minimum number of packets that should be kept in a PEP is defined within QPIM in number of packets. This property is defined as follows: NAME qpPacketSize SYNTAX Integer Value Must be greater than 0 8.7. The Class QoSPolicyBandwidthAction This class is used to control the bandwidth, delay, and forwarding behavior of a PHB. Its class definition is as follows: NAME QoSPolicyBandwidthAction DESCRIPTION This action controls the bandwidth, delay, and forwarding characteristics of the PHB. DERIVED FROM QoSPolicyPBHAction ABSTRACT False PROPERTIES qpForwardingPriority, qpBandwidthUnits, qpMinBandwdith, qpMaxBandwidth, qpMaxDelay, qpMaxJitter, qpFairness Snir, Ramberg, Strassner, Cohen expires November 2001 34 draft-ietf-policy-qos-info-model-03.txt April 2001 8.7.1. The Property qpForwardingPriority This property defines the forwarding priority for this set of flows. A non-zero value indicates that pre-emptive forwarding is required. Higher values represent higher forwarding priority. This property is defined as follows: NAME qpForwardingPriority SYNTAX Integer VALUE Must be non-negative. The value 0 means that pre-emptive forwarding is required. A positive value indicates the priority that is to be assigned for this (set of) flow(s). 8.7.2 The Property qpBandwidthUnits This property defines in what units the properties qpMinBandwidth and qpMaxBandwidth are defined. Bandwidth can either be defined in bits/sec or in percentage of the available bandwidth or scheduler resources. This property is defined as follows. NAME qpBandwidthUnits SYNTAX Integer VALUE Two values are possible. The value of 0 is used to specify units of bits/sec, while the value of 1 is used to specify units as a percentage of the available bandwidth. 8.7.3. The Property qpMinBandwidth This property defines the minimum bandwidth that should be reserved for this class of traffic. Both relative (i.e., a percentage of the bandwidth) and absolute (i.e., bits/second) values can be specified according to the value qpBandwidthUnits property. This property is defined as follows. NAME qpMinBandwidth SYNTAX Integer VALUE The value must be greater than 0. 8.7.4. The Property qpMaxBandwidth This property defines the maximum bandwidth that should be allocated to this class of traffic. Both relative (i.e., a percentage of the bandwidth)and absolute (i.e., bits/second) values can be specified according to the value qpBandwidthUnits property. This property is defined as follows. NAME qpMaxBandwidth SYNTAX Integer VALUE The value must be greater than 0 Snir, Ramberg, Strassner, Cohen expires November 2001 35 draft-ietf-policy-qos-info-model-03.txt April 2001 8.7.5. The Property qpMaxDelay This property defines the maximal per-hop delay that traffic of this class should experience while being forwarded through this hop. The maximum delay is measured in milliseconds. This property is defined as follows. NAME qpMaxDelay SYNTAX Integer (milliseconds) VALUE The value must be greater than 0 8.7.6. The Property qpMaxJitter This property defines the maximal per-hop delay variance that traffic of this class should experience while being forwarded through this hop. The maximum jitter is measured in milliseconds. This property is defined as follows. NAME qpMaxJitter SYNTAX Integer (milliseconds) VALUE The value must be greater than 0 8.7.7. The Property qpFairness This property defines whether fair queuing is required for this class of traffic. This property is defined as follows. NAME qpFairness SYNTAX Integer VALUE The value of 0 (FALSE) means that fair queuing is not required for this class of traffic, while the value of 1 (TRUE) means that fair queuing is required for this class of traffic. 8.8. The Class QoSPolicyCongestionControlAction This class is used to control the characteristics of the congestion control algorithm being used. The class definition is as follows: NAME QoSPolicyCongestionControlAction DESCRIPTION This action control congestion control characteristics of the PHB. DERIVED FROM QoSPolicyPBHAction ABSTRACT False PROPERTIES qpQueueSizeUnits, qpQueueSize, qpDropAlgorithm, qpDropThresholdUnits, qpDropMinThresholdValue, qpDropMaxThresholdValue Snir, Ramberg, Strassner, Cohen expires November 2001 36 draft-ietf-policy-qos-info-model-03.txt April 2001 8.8.1. The property qpQueueSizeUnits This property specifies the units in which the qpQueueSize attribute is measured. The queue size is measured either in number of packets or in units of time. The time interval specifies the time needed to transmit all packets within the queue if the link speed is dedicated entirely for transmission of packets within this queue. The property definition is: NAME qpQueueSizeUnits SYNTAX IntegerVALUE This property can have two values. If the value is set to 0, then the unit of measurement is number of packets. If the value is set to 1, then the unit of measurement is milliseconds. 8.8.2. The Property qpQueueSize This property specifies the queue size in packets or in milliseconds, depending on the value of the qpQueueSizeUnits (0 specifies packets, and 1 specifies milliseconds). This property is defined as follows: NAME qpQueueSize SYNTAX Integer VALUE This value must be greater than 0 8.8.3. The Property qpDropAlgorithm This property specifies the congestion control drop algorithm that should be used for this type of traffic. This property is defined as follows. NAME qpDropAlgorithm SYNTAX Integer VALUES Three values are currently defined. The value 0 specifies a random drop algorithm, the value 1 specifies a tail drop algorithm, and the value 2 specifies a head drop algorithm. 8.8.4. The Property qpDropThresholdUnits This property specifies the units in which the two properties qpDropMinThresholdValue and qpDropMaxThresholdValue are measured. Thresholds can be measured either in packets or in percentage of the available queue sizes. This property is defined as follows. NAME qpDropThresholdUnits SYNTAX Integer VALUES Two values are defined. The value 0 defines the units as number of packets, and the value 1 defines the units as a percentage of the queue size. Snir, Ramberg, Strassner, Cohen expires November 2001 37 draft-ietf-policy-qos-info-model-03.txt April 2001 8.8.5. The Property qpDropMinThresholdValue This property specifies the minimum number of queuing and buffer resources that should be reserved for this class of flows. The threshold can be specified as either relative (i.e., a percentage) or absolute (i.e., number of packets) value according to the value of qpDropThresholdUnits property. If this property specifies a value of 5 packets, then enough buffer and queuing resources should be reserved to hold 5 packets before running the specified congestion control drop algorithm. This property is defined as follows: NAME qpDropMinThresholdValue SYNTAX Integer VALUE This value must be greater than 0 8.8.6. The Property qpDropMaxThresholdValue This property specifies the maximum number of queuing and buffer resources that should be reserved for this class of flows. The threshold can be specified as either relative (i.e., a percentage) or absolute (i.e., number of packets) value according to the value of the qpDropThresholdUnits property. Congestion Control droppers should not keep more packets than the value specified in this property. Note, however, that some droppers may calculate queue occupancy averages, and therefore the actual maximum queue resources should be larger. This property is defined as follows: NAME qpDropMaxThresholdValue SYNTAX Integer VALUE This value must be greater than 0 8.9. Class QoSPolicyTrfcProf This is an abstract base class that models a traffic profile. Traffic profiles specify the maximum rate parameters used within admission decisions. The association QosPolicyTrfcProfInAdmissionAction binds the admission decision to the traffic profile. The class definition is as follows: NAME QoSPolicyTrfcProf DERIVED FROM Policy ABSTRACT True PROPERTIES None Snir, Ramberg, Strassner, Cohen expires November 2001 38 draft-ietf-policy-qos-info-model-03.txt April 2001 8.10. Class QosPolicyTokenBucketTrfcProf This class models a two- or three-level Token Bucket traffic profile. This traffic profile carries the policer or shaper rate values to be enforced on a flow or a set of flows. The class definition is as follows: NAME QosPolicyTokenBucketTrfcProf DERIVED FROM QoSPolicyTrfcProf ABSTRACT False PROPERTIES qpTBRate, qpTBNormalBurst, qpTBExcessBurst 8.10.1. The Property qpTBRate This is a non-negative integer that defines the token rate in kilobits per second. A rate of zero means that all packets will be out of profile. This property is defined as follows: NAME qpTBRate SYNTAX Integer VALUE This value must be greater than 0 8.10.2. The Property qpTBNormalBurst This property is an integer that defines the normal size of a burst measured in bytes. This property is defined as follows: NAME qpTBNormalBurst SYNTAX Integer VALUE This value must be greater than 0 8.10.3. The Property qpTBExcessBurst This property is an integer that defines the excess size of a burst measured in bytes. This property is defined as follows: NAME qpTBExcessBurst SYNTAX Integer VALUE This value must be greater than 0 Snir, Ramberg, Strassner, Cohen expires November 2001 39 draft-ietf-policy-qos-info-model-03.txt April 2001 8.11. Class qosPolicyIntServTrfcProf This class represents an IntServ traffic profile. Values of IntServ traffic profiles are compared against Traffic specification (TSPEC) and QoS Reservation (FLOWSPEC) requests carried in RSVP requests. The class definition is as follows: NAME qosPolicyIntServTrfcProf DERIVED FROM QosPolicyTrfcProf ABSTRACT False PROPERTIES qpISTokenRate, qpISPeakRate, qpISBucketSize, qpISResvRate, qpISResvSlack, qpISMinPolicedUnit, qpISMaxPktSize 8.11.1. The Property qpISTokenRate This property is a non-negative integer that defines the token rate parameter, measured in kilobits per second. This property is defined as follows: NAME qpISTokenRate SYNTAX Integer VALUE This value must be greater than 0 8.11.2. The Property qpISPeakRate This property is a non-negative integer that defines the peak rate parameter, measured in kilobits per second. This property is defined as follows: NAME qpISPeakRate SYNTAX Integer VALUE This value must be greater than 0 8.11.3. The Property qpISBucketSize This property is a non-negative integer that defines the token bucket size parameter, measured in bytes. This property is defined as follows: NAME qpISBucketSize SYNTAX Integer VALUE This value must be greater than 0 Snir, Ramberg, Strassner, Cohen expires November 2001 40 draft-ietf-policy-qos-info-model-03.txt April 2001 8.11.4. The Property qpISResvRate This property is a non-negative integer that defines the reservation rate (R-Spec) in the RSVP guaranteed service reservation. It is measured in kilobits per second. This property is defined as follows: NAME qpISResvRate SYNTAX Integer VALUE This value must be greater than 0 8.11.5. The Property qpISResvSlack This property is a non-negative integer that defines the RSVP slack term in the RSVP guaranteed service reservation. It is measured in microseconds. This property is defined as follows: NAME qpISResvSlack SYNTAX Integer VALUE This value must be greater than 0 8.11.6. The Property qpISMinPolicedUnit This property is a non-negative integer that defines the minimum RSVP policed unit, measured in bytes. This property is defined as follows: NAME qpISMinPolicedUnit SYNTAX Integer VALUE This value must be greater than 0 8.11.7. The Property qpISMaxPktSize This property is a non-negative integer that defines the maximum allowed packet size for RSVP messages, measure in bytes. This property is defined as follows: NAME qpISMaxPktSize SYNTAX Integer VALUE This value must be greater than 0 Snir, Ramberg, Strassner, Cohen expires November 2001 41 draft-ietf-policy-qos-info-model-03.txt April 2001 8.12. The Class QosPolicyAttributeValue This class is used to represent a single or set of property values in an object. This value can be used in conjunction with reference values carried in RSVP objects, as specified in [RFC2751]. The property name is used to specify which of the properties in the object is being used as the condition. The value of this property will then be retrieved, and a match (which is dependent on the property name) will be used to see if the condition is satisfied or not. The class definition is as follows: NAME QosPolicyAttributeValue DERIVED FROM PolicyImplicitValue ABSTRACT False PROPERTIES qpAttributeName, qpAttributeValueList 8.12.1. The Property qpAttributeName This property defines the name of the attribute that the list of values should be compared against. This property is defined as follows: NAME qpAttributeName SYNTAX String 8.12.2. The Property qpAttributeValueList This property contains a list of attribute values. Each value is compared to a value of the property specified by the qpAttributeName property. This property is defined as follows: NAME qpAttributeValueList SYNTAX String 8.13. The Class "QoSPolicyRSVPVariable" This is an abstract class that serves as the base class for all implicit variables that have to do with RSVP conditioning. The class definition is as follows: NAME QoSPolicyRSVPVariable DESCRIPTION An abstract base class used to build other classes that specify different attributes of an RSVP request DERIVED FROM PolicyImplicitVariable ABSTRACT TRUE PROPERTIES None Snir, Ramberg, Strassner, Cohen expires November 2001 42 draft-ietf-policy-qos-info-model-03.txt April 2001 8.14. The Class "QoSPolicyRSVPSourceIPv4Variable" This is a concrete class that contains the source IPv4 address of the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP] objects. The class definition is as follows: NAME QoSPolicyRSVPSourceIPv4Variable DESCRIPTION The source IPv4 address of the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP] objects. ALLOWED VALUE TYPES: PolicyIPv4AddrValue DERIVED FROM QoSPolicyRSVPVariable ABSTRACT FALSE PROPERTIES None 8.15. The Class "QoSPolicyRSVPDestinationIPv4Variable" This is a concrete class that contains the destination IPv4 address of the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP] objects. The class definition is as follows: NAME QoSPolicyRSVPDestinationIPv4Variable DESCRIPTION The destination IPv4 address of the RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP] objects. ALLOWED VALUE TYPES: PolicyIPv4AddrValue DERIVED FROM QoSPolicyRSVPVariable ABSTRACT FALSE PROPERTIES None 8.16. The Class "QoSPolicyRSVPSourceIPv6Variable" This is a concrete class that contains the source IPv6 address of the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP] objects. The class definition is as follows: NAME QoSPolicyRSVPSourceIPv6Variable DESCRIPTION The source IPv6 address of the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP] objects. ALLOWED VALUE TYPES: PolicyIPv6AddrValue DERIVED FROM QoSPolicyRSVPVariable ABSTRACT FALSE PROPERTIES None Snir, Ramberg, Strassner, Cohen expires November 2001 43 draft-ietf-policy-qos-info-model-03.txt April 2001 8.17. The Class "QoSPolicyRSVPDestinationIPv6Variable" This is a concrete class that contains the destination IPv6 address of the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP] objects. The class definition is as follows: NAME QoSPolicyRSVPDestinationIPv6Variable DESCRIPTION The destination IPv6 address of the RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP] objects. ALLOWED VALUE TYPES: PolicyIPv6AddrValue DERIVED FROM QoSPolicyRSVPVariable ABSTRACT FALSE PROPERTIES None 8.18. The Class "QoSPolicyRSVPSourcePortVariable" This is a concrete class that contains the source port of the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP] objects. The class definition is as follows: NAME QoSPolicyRSVPSourcePortVariable DESCRIPTION The source port of the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP] objects. ALLOWED VALUE TYPES: Integer DERIVED FROM QoSPolicyRSVPVariable ABSTRACT FALSE PROPERTIES None 8.19. The Class "QoSPolicyRSVPDestinationPortVariable" This is a concrete class that contains the destination port of the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP] objects. The class definition is as follows: NAME QoSPolicyRSVPDestinationPortVariable DESCRIPTION The destination port of the RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP] objects. ALLOWED VALUE TYPES: Integer DERIVED FROM QoSPolicyRSVPVariable ABSTRACT FALSE PROPERTIES None Snir, Ramberg, Strassner, Cohen expires November 2001 44 draft-ietf-policy-qos-info-model-03.txt April 2001 8.20. The Class "QoSPolicyRSVPIPProtocolVariable" This is a concrete class that contains the IP Protocol number of the RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP] objects. The class definition is as follows: NAME QoSPolicyRSVPIPProtocolVariable DESCRIPTION The IP Protocol number of the RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP] objects. ALLOWED VALUE TYPES: Integer DERIVED FROM QoSPolicyRSVPVariable ABSTRACT FALSE PROPERTIES None 8.21. The Class "QoSPolicyRSVPIPVersionVariable" This is a concrete class that contains the IP Protocol version number of the RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP] objects. The well-known version numbers are 4 and 6. The class definition is as follows: NAME QoSPolicyRSVPIPVersionVariable DESCRIPTION The IP version number of the IP Addresses carried the RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP] objects. ALLOWED VALUE TYPES: Integer DERIVED FROM QoSPolicyRSVPVariable ABSTRACT FALSE PROPERTIES None 8.22. The Class "QoSPolicyRSVPDCLASSVariable" This is a concrete class that contains the DSCP value as defined in the RSVP DCLASS [DCLASS] object. The class definition is as follows: NAME QoSPolicyRSVPDCLASSVariable DESCRIPTION The DSCP value as defined in the RSVP DCLASS [DCLASS] object. ALLOWED VALUE TYPES: Integer, BitString DERIVED FROM QoSPolicyRSVPVariable ABSTRACT FALSE PROPERTIES None Snir, Ramberg, Strassner, Cohen expires November 2001 45 draft-ietf-policy-qos-info-model-03.txt April 2001 8.23. The Class "QoSPolicyRSVPStyleVariable" This is a concrete class that contains the reservation style as defined in the RSVP STYLE object in the RESV message [RSVP]. The class definition is as follows: NAME QoSPolicyRSVPStyleVariable DESCRIPTION The reservation style as defined in the RSVP STYLE object in the RESV message [RSVP]. ALLOWED VALUE TYPES: BitString, Integer (Integer has an enumeration of { Fixed-Filter=1 , Shared-Explicit=2, Wildcard-Filter=3} DERIVED FROM QoSPolicyRSVPVariable ABSTRACT FALSE PROPERTIES None 8.24. The Class "QoSPolicyIntServVariable" This is a concrete class that contains the Integrated Service requested in the RSVP Reservation message, as defined in the FLOWSPEC RSVP Object [RSVP]. The class definition is as follows: NAME QoSPolicyRSVPIntServVariable DESCRIPTION The integrated Service requested in the RSVP Reservation message, as defined in the FLOWSPEC RSVP Object [RSVP]. ALLOWED VALUE TYPES: Integer (An enumerated value of { CL=1 , GS=2, NULL=3} DERIVED FROM QoSPolicyRSVPVariable ABSTRACT FALSE PROPERTIES None 8.25. The Class "QoSPolicyRSVPMessageTypeVariable" This is a concrete class that contains the RSVP message type, as defined in the RSVP message common header [RSVP] object. The class definition is as follows: Snir, Ramberg, Strassner, Cohen expires November 2001 46 draft-ietf-policy-qos-info-model-03.txt April 2001 NAME QoSPolicyRSVPMessageTypeVariable DESCRIPTION The RSVP message type, as defined in the RSVP message common header [RSVP] object. ALLOWED VALUE TYPES: Integer (An enumerated value of { PATH=1 , PATHTEAR=2, RESV=3, RESVTEAR=4, ResvErr=5, CONF=6} DERIVED FROM QoSPolicyRSVPVariable ABSTRACT FALSE PROPERTIES None 8.26. The Class "QoSPolicyRSVPPreemptionPriorityVariable" This is a concrete class that contains the RSVP reservation priority, as defined in [RSVP_PREEMP] object. The class definition is as follows: NAME QoSPolicyRSVPPreemptionPriorityVariable DESCRIPTION The RSVP reservation priority as defined in [RSVP_PREEMP]. ALLOWED VALUE TYPES: Integer DERIVED FROM QoSPolicyRSVPVariable ABSTRACT FALSE PROPERTIES None 8.27. The Class "QoSPolicyRSVPPreemptionDefPriorityVariable" This is a concrete class that contains the RSVP reservation defending priority, as defined in [RSVP_PREEMP] object. The class definition is as follows: NAME QoSPolicyRSVPPreemptionDefPriorityVariable DESCRIPTION The RSVP preemption reservation defending priority as defined in [RSVP_PREEMP]. ALLOWED VALUE TYPES: Integer DERIVED FROM QoSPolicyRSVPVariable ABSTRACT FALSE PROPERTIES None Snir, Ramberg, Strassner, Cohen expires November 2001 47 draft-ietf-policy-qos-info-model-03.txt April 2001 8.28. The Class "QoSPolicyRSVPUserVariable" This is a concrete class that contains the ID of the user that initiated the flow as defined in the User Locator string in the Identity Policy Object [RFC2752]. The class definition is as follows: NAME QoSPolicyRSVPUserVariable DESCRIPTION The ID of the user that initiated the flow as defined in the User Locator string in the Identity Policy Object [RFC2752]. ALLOWED VALUE TYPES: QoSPolicyDNValue, PolicyStringValue, QosPolicyAttributeValue DERIVED FROM QoSPolicyRSVPVariable ABSTRACT FALSE PROPERTIES None 8.29. The Class "QoSPolicyRSVPApplicationVariable" This is a concrete class that contains the ID of the application that generated the flow as defined in the application locator string in the Application policy object [RFC2872]. The class definition is as follows: NAME QoSPolicyRSVPApplicationVariable DESCRIPTION The ID of the application that generated the flow as defined in the application locator string in the Application policy object [RFC2872]. ALLOWED VALUE TYPES: QoSPolicyDNValue, PolicyStringValue, QosPolicyAttributeValue DERIVED FROM QoSPolicyRSVPVariable ABSTRACT FALSE PROPERTIES None Snir, Ramberg, Strassner, Cohen expires November 2001 48 draft-ietf-policy-qos-info-model-03.txt April 2001 8.30. The Class "QoSPolicyRSVPAuthMethodVariable" This is a concrete class that contains the type of authentication used in the Identity Policy Object [RFC2752]. The class definition is as follows: NAME QoSPolicyRSVPAuthMethodVariable DESCRIPTION The RSVP Authentication type used in the Identity Policy Object [RFC2752]. ALLOWED VALUE TYPES: Integer (An enumeration of { NONE=0, PLAIN-TEXT=1, DIGITAL-SIG = 2, KERBEROS_TKT=3, X509_V3_CERT=4, PGP_CERT=5} DERIVED FROM QoSPolicyRSVPVariable ABSTRACT FALSE PROPERTIES None 8.31. The Class QoSPolicyDNValue This class is used to represent a single or set of Distinguished Name [DNDEF] values, including wildcards. A Distinguished Name is a name that can be used as a key to retrieve an object from a directory service. This value can be used in comparison to reference values carried in RSVP policy objects, as specified in [RFC2752]. The class definition is as follows: NAME QoSPolicyDNValue DERIVED FROM PolicyImplicitValue ABSTRACT False PROPERTIES qpDNList 8.31.1. The Property qpDNList This attribute provides an unordered list of strings, each representing a Distinguished Name (DN) with wildcards. The format of a DN is defined in [DNDEF]. The asterisk character ("*") is used as wildcard for either a single attribute value or a wildcard for an RDN. The order of RDNs is significant. For example: A qpDNList attribute carrying the following value: "OU=Sales, CN=*, O=Widget Inc., *, C=US" matches: "OU=Sales, CN=J. Smith, O=Widget Inc, C=US" and also matches: "OU=Sales, CN=J. Smith, O=Widget Inc, C=US, CN=CA". The attribute is defined as follows: NAME qpDNList SYNTAX List of Distinguished Names implemented as strings, each of which serves as a reference to another object. Snir, Ramberg, Strassner, Cohen expires May 2001 49 Draft-ietf-policy-qos-info-model-01.txt November 2000 8.32. The Class QoSPolicyRSVPSimpleAction This action controls the content of RSVP messages and the way RSVP requests are admitted. Depending on the value of its qpRSVPActionType property, this action directly translates into either a COPS Replace Decision or a COPS Stateless Decision, as defined in COPS for RSVP. Only variables that are subclasses of the QoSPolicyRSVPVariable are allowed to be associated with this action. The property definition is as follows: NAME QoSPolicyRSVPSimpleAction DESCRIPTION This action controls the content of RSVP messages and the way RSVP requests are admitted. DERIVED FROM SimplePolicyAction ABSTRACT False PROPERTIES qpRSVPActionType Restricts the PolicyVariableInSimplePolicyAction aggregation to QoSPolicyRSVPVariable. 8.32.1. The Property qpRSVPActionType This property may contain one or two values to denote the type of RSVP action. The value 'REPLACE' denotes a COPS Replace Decision action. The value 'STATELESS' denotes a COPS Stateless Decision action. Refer to [COPS] for details. This property is multi-value, which means that both action types are to be executed. NAME QpRSVPActionType DESCRIPTION This property specifies whether the action type is for COPS Replace or Stateless decision or both. SYNTAX Integer VALUE This is an enumerated integer. A value of 0 specifies a COPS Replace decision. A value 1 specifies a COPS Stateless Decision. 9. Acknowledgements The authors wish to thank the input of the participants of the Policy Framework working group, and especially Bob Moore and Alex Wang for their helpful contributions. 10. Security Considerations The Policy Core Information Model (PCIM) [PCIM] describes the general security considerations related to the general core policy model. The extensions defined in this document do not introduce any additional considerations related to security. Snir, Ramberg, Strassner, Cohen expires November 2001 50 draft-ietf-policy-qos-info-model-03.txt November 2001 11. References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [PCIM] Strassner, J., and E. Ellesson, B. Moore, A. Westerinen, "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001. [PCIMe] B. Moore, L. Rafalow, Y. Ramberg, Y. Snir, J. Strassner, A. Westerinen, R. Chadha, M. Brunner, R. Cohen, "Policy Core Information Model Extensions", [TERMS] A. Westerinen, J. Schnizlein, J. Strassner, M. Scherling, B. Quinn, J. Perry, S. Herzog, A. Huynh, M. Carlson, S. Waldbusser, "Terminology", [QDDIM] J. Strassner, A. Westerinen, B. Moore, D. Durham, W. Weiss, "Information Model for Describing Network Device QoS Mechanisms for Differentiated Services", [DIFFSERV] S. Blake, et. Al., "An Architecture for Differentiated Services", RFC 2475 [UML] Please see the following web page for the latest (1.3 as of this writing) UML specification: http://www.rational.com/uml/resources/documentation/index.jsp [INTSERV] R. Braden, D. Clark, S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633. [RSVP] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC2205 [QoSSCHEMA] Y. Snir, Y. Ramberg, J. Strassner, R. Cohen, "Policy QoS LDAP Schema", [RFC2749] S . Herzog, Ed., J. Boyle, R. Cohen, D. Durham, R. Rajan, A. Sastry, "COPS usage for RSVP", RFC2749 [RFC2751] S. Herzog, "Signaled Preemption Priority Policy Element", RFC2751 [DIFF-MIB] F. Baker, K. Chan, A. Smith, "Management Information Base for the Differentiated Services Architecture", Snir, Ramberg, Strassner, Cohen expires November 2001 51 draft-ietf-policy-qos-info-model-03.txt November 2001 [AF] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured Forwarding PHB Group", RFC2597 [CL] J. Wroclawski, "Specification of the Controlled-Load Network Element Service", RFC2211 [RSVP-IS] J. Wroclawski, "The Use of RSVP with IETF Integrated Services", RFC2210 [GS] S. Shenker, C. Partridge, R. Guerin, "Specification of the Guaranteed Quality of Service", RFC2212 [DCLASS] Y. Bernet, "Format of the RSVP DCLASS Object", RFC2996 [RFC2752] S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, S. Herzog, "Identity Representation for RSVP", RFC2752 [RFC2872] Y. Bernet, R. Pabbati, "Application and Sub Application Identity Policy Element for Use with RSVP", RFC2872 [DNDEF] M. Wahl, S. Kille, and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC2253 12. Authors' Addresses Yoram Ramberg Cisco Systems 4 Maskit Street Herzliya Pituach, Israel 46766 Phone: +972-9-970-0081 Fax: +972-9-970-0219 E-mail: yramberg@cisco.com Yoram Snir Cisco Systems 4 Maskit Street Herzliya Pituach, Israel 46766 Phone: +972-9-970-0085 Fax: +972-9-970-0366 E-mail: ysnir@cisco.com John Strassner Cisco Systems 725 Alder Drive, , Building 20 Milpitas, CA 95035 Phone: +1-408-527-1069 Fax: +1-408-527-2477 E-mail: johns@cisco.com Snir, Ramberg, Strassner, Cohen expires November 2001 52 draft-ietf-policy-qos-info-model-03.txt November 2001 Ron Cohen Ntear LLC Phone: Fax: E-mail: ronc@ntear.com 13. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Snir, Ramberg, Strassner, Cohen expires November 2001 53