Policy Framework Y. Snir Internet Draft Y. Ramberg Expires May 2001 J. Strassner draft-ietf-policy-qos-info-model-02.txt R. Cohen November 2000 Cisco Systems Policy Framework 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 Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). 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 as specified by [PCIM]. This draft refines the concept of generic policy rules, conditions and actions defined in [PCIM] in order to define extensions necessary for representing IntServ and DiffServ QoS policies. It also provides refinement of additional concepts that are important for building rule- specific as well as reusable QoS policy rules. This information model covers Differentiated Services QoS enforcement, and Integrated Service QoS enforcement via policy control on RSVP admission. 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. Companion documents (e.g., [QoSSCHEMA]) define the mapping of these classes to specific data models (schemata). Snir, Ramberg, Strassner, Cohen expires May 2001 1 Draft-ietf-policy-qos-info-model-02.txt November 2000 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. Table of Contents 1. Introduction 6 1.1 Goals 7 1.2 Approach and Related Documents 7 2. Information Model Hierarchy 8 2.1 Interaction Between the PCIM and This Document 8 2.1.1. Extension of Concepts in the PCIM 8 2.1.1.1 Hierarchical Policy Repositories 9 2.1.1.2 Extensions to Reusable Objects 9 2.1.1.3 Extensions to the Structure of a Policy Rule 9 2.1.2 Addition of New Concepts Not in the PCIM 9 2.1.2.1 Rule Nesting 9 2.1.2.2 Rule Decision Strategy 10 2.1.2.3 Compound Conditions 10 2.1.2.4 Pre-Defined Variables and Constants 10 2.1.2.5 Per-Hop Behaviors 11 2.1.3 Mapping to a Directory 11 2.2 High-Level Class Hierarchy 11 3. QPIM Hierarchies 13 3.1. Class and Relationship Hierarchies Defined in the QPIM 14 3.2. Implementation Guidelines 15 3.2.1 Modeling Containment 16 3.2.2. Implementing Relationships 17 3.2.2.1. Relationship modeling 17 3.2.2.2. Representing Containment in a Consistent Manner 18 3.2.3. Mapping Differences and Examples 18 3.3. QoS Domain Data Tree 19 3.4. Types of Grouping Classes 22 3.5. QoS Policy Domain Grouping and Nesting 23 3.6. Resource Sharing 25 3.7. Instance Location 26 3.8. Policy Containers 27 3.8.1 Semantics of a gpsPolicyGroup 27 3.8.2 Priority and Decision Strategy Applied to Containers 29 3.8.3 Sharing Policy Containers 30 3.9 Policy Roles associated with gpsPolicyGroup 31 3.10 Policy Rules 32 3.11 Conditions and Actions 33 3.12 Data Tree Example 33 3.13 Reusable-Object Repositories 34 3.14 Relationships Between QoS Domains and Repositories 35 Snir, Ramberg, Strassner, Cohen expires May 2001 2 Draft-ietf-policy-qos-info-model-02.txt November 2000 4. Constructing a QoS Policy Rule 36 4.1 Policy Rule Structure 36 4.2 QoS Policy Conditions 37 4.2.1. Simple Conditions 38 4.2.2. Compound Conditions 38 4.2.3. Using Simple Conditions 39 4.2.4. Using Compound Conditions 41 4.2.5. Reusable vs. Rule-Specific Conditions 42 4.3 Simple Condition Operator 43 4.4 QoS Policy Variables 43 4.4.1 Variable Binding 45 4.4.2 Pre-Defined Variables 46 4.5 QoS Policy Value 49 4.6. PolicyTimePeriodCondition 50 4.7. Actions 50 4.7.1 Provisioning Actions 52 4.7.1.1 Meters 52 4.7.1.2 Markers 53 4.7.1.3 Shapers 54 4.7.1.4 Droppers 54 4.7.1.5 Examples 55 4.7.2 PHB actions 57 4.7.2.1 Bandwidth and Delay management 57 4.7.2.2 Congestion Control and Buffer management 58 4.7.2.3 Queues and PHB groups 58 4.7.2.4 Using hierarchical policies 59 4.7.2.5 Examples 59 4.7.3 Signaling Actions 61 4.7.3.1 Admission Control 62 4.7.3.2 Forwarding Behavior 62 4.7.3.3 Signaling Control 63 4.7.3.4 Examples 63 4.8 Meters and Traffic Profiles 64 4.8.1 Provisioning Traffic Profiles 65 4.8.2 RSVP Traffic Profiles 66 5. Decision strategy 67 5.1 Organizing the Application of Decision Strategies 67 5.2 Decision Strategies 68 5.2.1. First Match Decision Strategy 68 5.2.2. Match All Decision Strategy 68 5.3. Decision Strategy example 69 6. Per Hop Behavior 70 7. QoS Policy Class Inheritance 71 8. Class Definitions 75 8.1 The Aggregation "PolicyGroupInPolicyRule" 75 8.1.1. The Reference "GroupComponent" 75 Snir, Ramberg, Strassner, Cohen expires May 2001 3 Draft-ietf-policy-qos-info-model-02.txt November 2000 8.1.2. The Reference "PartComponent" 75 8.2 The Aggregation "PolicyRuleInPolicyRule" 76 8.2.1. The Reference "GroupComponent" 76 8.2.2. The Reference "PartComponent" 76 8.3 The Aggregation "PolicyConditionInCompoundCondition " 77 8.3.1. The Reference "GroupComponent" 77 8.3.2. The Reference "PartComponent" 77 8.4 The Aggregation " PolicyVariableInPolicySimpleCondition " 77 8.4.1. The Reference "GroupComponent" 78 8.4.2. The Reference "PartComponent" 78 8.5 The Aggregation " PolicyValueInPolicySimpleCondition " 78 8.5.1. The Reference "GroupComponent" 79 8.5.2. The Reference "PartComponent" 79 8.6. The Association "PolicyElementInPolicyRepository" 79 8.6.1. The Reference "Antecedent" 80 8.6.2. The Reference "Dependent" 80 8.7. The Association "PolicyValueConstraintsInVariable" 80 8.7.1. The Reference "Antecedent" 81 8.7.2. The Reference "Dependent" 81 8.8. The Association "PolicyMeterInAction" 81 8.8.1. The Reference "Antecedent" 81 8.8.2. The Reference "Dependent" 81 8.9. The Association "PolicyTrfcProfileInMeter" 82 8.9.1. The Reference "Antecedent" 82 8.9.2. The Reference "Dependent" 82 8.10. The Association "PolicyQueueInPHBAction" 82 8.10.1. The Reference "Antecedent" 82 8.10.2. The Reference "Dependent" 83 8.11. The Association "PolicyConformNextAction" 83 8.11.1. The Reference "Antecedent" 83 8.11.2. The Reference "Dependent" 83 8.12. The Association "PolicyExcessNextAction" 84 8.12.1. The Reference "Antecedent" 84 8.12.2. The Reference "Dependent" 84 8.13. The Association "PolicyViolateNextAction" 84 8.13.1. The Reference "Antecedent" 85 8.13.2. The Reference "Dependent" 85 8.14. Class qosPolicyDomain 85 8.14.1. The Property qpDomainName 85 8.14.2. The Property qpPolicyRuleMatchMethod 86 8.15. Class gpsPolicyGroup 86 8.15.1. The Property gpPriority 86 8.15.2. The Property gpNamedPolicyRuleMatchMethod 87 8.15.3. The Property gpPolicyRoles 87 8.16. Class qosPolicyPRAction 87 8.16.1. The Property qpDirection 87 8.16.2. The Property qpMarkvalue 88 8.16.3. The Property qpMarkValueType 88 8.16.4. The Property qpExcessAction 88 8.16.5. The Property qpExcessMarkValue 88 8.16.6. The Property qpViolateAction 89 8.16.7. The Property qpViolateMarkValue 89 Snir, Ramberg, Strassner, Cohen expires May 2001 4 Draft-ietf-policy-qos-info-model-02.txt November 2000 8.17. Class qosPolicyPHBAction 89 8.17.1. The Property qpPHBDirection 89 8.17.2. The Property qpDropAlgorithm 90 8.17.3. The Property qpDropTreshholdValueType 90 8.17.4. The Property qpDropMinTreshholdValue 90 8.17.5. The Property qpDropMaxTreshholdValue 90 8.17.6. The Property qpRandomDropInvWeight 91 8.17.7. The Property qpRandomDropProbMax 91 8.17.8 The Property qpPacketSize 91 8.18. Class qosPolicyRSVPAction 91 8.18.1. The Property qpRSVPDirection 92 8.18.2. The Property qpRSVPMessageType 92 8.18.3. The Property qpRSVPStyle 92 8.18.4. The Property qpRSVPServiceType 92 8.19. Class qosPolicyRSVPSignalCtrlAction 93 8.19.1. The Property qpForwardingMode 93 8.19.2. The Property qpSendError 93 8.19.3. The Property qpReplaceDSCP 93 8.19.4. The Property qpReplacePreemptionPriority 94 8.19.5. The Property qpReplaceDefendingPriority 94 8.20. Class qosPolicyRSVPInstallAction 94 8.20.1. The Property qpSetDSCPValue 95 8.20.2. The Property qpSetDefendingPriority 95 8.20.3. The Property qpSetPreemptionPriority 95 8.21. Class gpsPolicyTrfcProf 95 8.22. Class qosPolicyPRTrfcProf 96 8.22.1. The Property qpPRRate 96 8.22.2. The Property qpPRNormalBurst 96 8.22.3. The Property qpPRExcessBurst 96 8.23. Class qosPolicyRSVPTrfcProf 96 8.23.1. The Property qpRSVPTokenRate 96 8.23.2. The Property qpRSVPPeakRate 97 8.23.3. The Property qpRSVPBucketSize 97 8.23.4. The Property qpRSVPResvRate 97 8.23.5. The Property qpRSVPResvSlack 97 8.23.6. The Property qpRSVPSessionNum 97 8.23.7. The Property qpMinPolicedUnit 98 8.23.8. The Property qpMaxPktSize 98 8.24. Class gpsPolicySimpleCondition 98 8.24.1. The Property gpOperator 99 8.25. Class gpsPolicyCompoundCondition 99 8.25.1 The Property gpPolicyConditionListType 99 8.26. Class gpsPolicyVariable 100 8.26.1. The Property gpVariableName 100 8.26.2. The Property gpVariableDescription 101 8.27. Class gpsPolicyValue 101 8.28. Class gpsPolicyIPv4AddrValue 101 8.28.1. The Property gpIPv4AddrList 102 8.29. Class gpsPolicyIPv6AddrValue 102 8.29.1. The Property gpIPv6AddrList 102 Snir, Ramberg, Strassner, Cohen expires May 2001 5 Draft-ietf-policy-qos-info-model-02.txt November 2000 8.30. Class gpsPolicyMACAddrValue 103 8.30.1. The Property gpMACAddrList 103 8.31. Class gpsPolicyStringValue 104 8.31.1. The Property gpStringList 104 8.32 Class gpsPolicyBitStringValue 104 8.32.1. The Property gpBitStringList 104 8.33. Class gpsPolicyDNValue 105 8.33.1. The Property gpDNList 105 8.34. Class gpsPolicyAttributeValue 106 8.34.1. The Property gpAttributeName 106 8.34.2. The Property gpAttributeValueList 106 8.35. Class gpsPolicyIntegerValue 107 8.35.1. The Property gpIntegerList 107 8.36. Class gpsPolicyMeter 108 8.36.1. The Property gpMeterScope 108 8.36.2. The Property gpMeterTimeInterval 108 8.37. Class qosPolicyQueue 109 8.37.1. The Property qpForwardingPriority 109 8.37.2. The Property qpBandwidthValueType 109 8.37.3. The Property qpMinBandwidth 109 8.37.4. The Property qpMaxBandwidth 110 8.37.5 The Property qpMaxDelay 110 8.37.6 The Property qpMaxJitter 110 8.37.7 The Property qpPacketSize 110 8.37.8 The Property qpFairQueue 110 9. Extending the QoS Policy Schema 111 9.1. Extending gpsPolicyValue 111 9.2. Extending gpsPolicySimpleCondition 111 9.3. Extending qosPolicyAction 111 10. Security Considerations 112 11. Editorial Changes 112 12. Acknowledgments 113 13. References 113 14. Author's Addresses 115 15. Full Copyright Statement 115 1. Introduction This document presents an object-oriented information model for representing network QoS policies. As such, it is independent of any specific data storage mechanism and access protocol. This document is based on the IETF Policy Core Information Model as specified by [PCIM]. Specifically, this draft refines the concept of generic policy rules, conditions and actions to cover extensions necessary for representing IntServ and DiffServ QoS policies. Snir, Ramberg, Strassner, Cohen expires May 2001 6 Draft-ietf-policy-qos-info-model-02.txt November 2000 This information model covers Differentiated Service QoS enforcement, and Integrated Service QoS enforcement via policy control on RSVP admission. Companion documents (e.g., [QoSSCHEMA]) define the mapping of these 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. 1.1 Goals This document defines a set of classes that can be used to build high level policies that can be used to configure and enforce consistent QoS behavior across a network. Specifically, the policies defined in this document can be used to control and manage different vendor-specific device mechanisms that are used to build different IntServ and DiffServ QoS behaviors. The purpose of introducing a standard information model is to allow interoperability between policy servers, policy management applications, and network devices. This document solves two problems. First, different devices have different capabilities, and may respond differently to the same high- level policy rule. This document solves this problem by defining a set of common abstractions that can be used to build high-level QoS policies. These high-level QoS policies control and manage low-level QoS device mechanisms independent of the specific type of device that is being managed. This enables different devices to use the same low- level abstractions of mechanisms to implement QoS services, which are controlled by the QoS policy rules defined in this document. Second, different policy servers and applications may provision parts of the network differently if no common high-level policy description exists. This document defines a standard information model that provides common definitions and semantics to be assigned to build, interpret and enforce high-level policy rules. 1.2 Approach and Related Documents The information model presented in this document contains information that can be shared by other network policy managers (e.g., Security managers, IP address managers, and others). Examples include sharing of the same definition of well-known application port numbers, IP addresses of servers and other network attributes. It allows checking of consistent behaviors of the interaction between the different managers by comparing, for example, the set of QoS and security actions enforced on the same set of flows. The remainder of this document presents, describes and defines the QoS Policy Information Model (QPIM). QPIM is a set of entities and relationships (both modeled by classes) that define managed objects and Snir, Ramberg, Strassner, Cohen expires May 2001 7 Draft-ietf-policy-qos-info-model-02.txt November 2000 interactions between managed objects that can be used to define, manage, and control IntServ and DiffServ QoS mechanisms using policies. It uses basic concepts defined in [PCIM] but extends those to control IntServ and DiffServ QoS mechanisms. Since QPIM is an information model (and is therefore independent of any specific data storage mechanism and access protocol limitations), this document is limited to discussing the different managed objects that are used to define and provision IntServ and DiffServ QoS policies. Relationships to the Core schema [PCLS] and issues related to mapping this information to a form suitable for implementation in a directory, along with correct usage of the mapped schema, are defined in [QOSSCHEMA]. 2. Information Model Hierarchy This section discusses the relationships between the Policy Core Information Model [PCIM], the QoS Policy Information Model (QPIM, which is this document) and future extensions of the QPIM. 2.1 Relationship Between the PCIM and This Document This document both extends concepts that are part of the [PCIM] and adds new functions that are not part of the [PCIM]. The [PCIM] models high-level policy concepts and introduces structural conventions and nomenclature common to all types of policies. The fundamental purpose of the [PCIM] is to provide a generic representation of the structure of a policy rule, along with a set of classes and relationships that can serve as a common representation of policy groups, rules, conditions, and actions. This enables derived information models and schemata to use a common set of terminology, classes, and approaches, thus facilitating interoperability. The QPIM refines and extends the concepts of the [PCIM] by introducing a framework of classes and relationships dedicated to model IntServ and DiffServ QoS Policies. This set of classes and relationships can be used to configure and manage devices that are compliant with either the integrated services [Intserv] and/or with the differentiated service approach [Diffserv]. 2.1.1 Extension of Concepts in the PCIM The QPIM extends three fundamental concepts defined in [PCIM] in order to be able to define policies that can control, manage and provision the QoS mechanisms of devices. These are hierarchical policy repositories, extensions to reusable objects, and extensions to the structure of a policy rule. Snir, Ramberg, Strassner, Cohen expires May 2001 8 Draft-ietf-policy-qos-info-model-02.txt November 2000 2.1.1.1 Hierarchical Policy Repositories The concept of a "nested" policy repository (i.e., a repository that is embedded within another repository) that contains policy information, was originally defined in an earlier version of the QPIM. It has subsequently been moved into the [PCIM], since it is a general concept that is not limited to QoS, and can be used by other applications. This document reuses this concept, but defines specific refinements for using "embedded policy repositories" to accommodate the application-specific needs of QoS provisioning. These reflect the need to provide nested levels of administration and scoping to policies and policy information. 2.1.1.2 Extensions to Reusable Objects Similarly, the concepts of reusable objects vs. rule-specific objects have been moved from an earlier version of this document to the [PCIM]. In addition, this document defines specific extensions to guide the implementation of reusable- vs. rule-specific QoS objects. 2.1.1.3 Extensions to the Structure of a Policy Rule This document also extends the concept of a policy rule. It is important to note that this is done without having to redefine or subclass of PolicyRule (as defined in [PCIM]), because if that was done, then interoperability would be adversely affected. This document also defines additional conditions and actions that are specific to QoS. It further defines different types of actions that target DiffServ and IntServ actions. 2.1.2 Addition of New Concepts Not in the PCIM There are several notable new concepts that are not part of the [PCIM]. These include rule nesting, rule decision strategy, compound conditions, pre-defined variables and constants, and Per Hop Behavior definition, as part of the QoS actions. 2.1.2.1 Rule Nesting The [PCIM] defines the ability to group policy rules by defining the policyGroup class. This class can be used to contain a set of policyRules and/or a set of policyGroups. This grouping mechanism allows for constructing a flexible and extensible information model. However, it treats PolicyRules as atomic objects that can contain only conditions and actions. In practice, this is not flexible enough for some of the needs of IntServ and DiffServ. Snir, Ramberg, Strassner, Cohen expires May 2001 9 Draft-ietf-policy-qos-info-model-02.txt November 2000 Therefore, this document adds the concept of nesting one or more policy rules within a policy rule. For example, one could think of a policy rule that controls how a user logs onto the network as consisting of two parts. A high-level rule is used to group together a set of lower- level rules that are invoked at various stages of processing (e.g., how the user is authenticated, how the IP Address is assigned, etc.). The high-level rule would also contain information to properly control the execution sequence of the lower-level rules, as well as to provide a consistent and conceptually simpler interface to other objects in the system. This is implemented by allowing a PolicyRule to contain a PolicyRule or a PolicyGroup as one of its components. 2.1.2.2 Rule Decision Strategy Since there is no concept of nested rules in the [PCIM], there is no need for a decision strategy to be used to define the order of processing of these rules. However, since QPIM allows for nested rules, different examples of decision strategies must be defined in this document and shown that they can work in this new environment. This document defines two such decision strategies: match-first and match- all. Both define an ordering that can be applied to a set of policyRules and policyGroup objects within a larger context (e.g., a policy domain). This in turn controls the execution of different policy actions. Note that choosing a different decision strategy is one way to change the result of executing a set of policy rules without changing the policy rules themselves. 2.1.2.3 Compound Conditions [PCIM] defines conditions that consist of a single term. [PCIM] allows such conditions to be logically combined using 'AND' and 'OR' terms. This makes sense, because all conditions can be constructed from such primitives. However, a richer means of representing common conditions is called for. This document extends the concept of a simple (i.e., one-term) condition to define compound conditions. This is conceptually equivalent to using a set of simple conditions. However, supporting compound conditions enables a better matching of the information model to the environment that it is modeling, and also simplifies the mapping of the information model to different types of data models. In addition, it enhances the manageability and reusability of complex conditions. Therefore, the classes and relationships needed to build this in as efficient a manner as possible are defined in this document. 2.1.2.4 Pre-Defined Variables and Constants This document also defines a set of variable and constant definitions for use with QoS policies. This concept is not present in the [PCIM] Snir, Ramberg, Strassner, Cohen expires May 2001 10 Draft-ietf-policy-qos-info-model-02.txt November 2000 because the purpose of the [PCIM] is to provide a general structure for representing policy rules, conditions and actions. Variable and constant definitions represent specific concepts that have pre-defined semantics. This version of this draft has these elements residing in this draft. However, they have been generalized so that other applications besides QoS can use them. 2.1.2.5 Per-Hop Behaviors Finally, QoS Policy definition may require the notion of a Per-Hop Behavior (specified by the differentiated services paradigm). This document provides interpretation for this notion by providing a way to represent Per-Hop Behaviors using policy rules. 2.1.3 Mapping to a Directory The PCIM and QPIM are both inherently extensible. Furthermore, they are designed to fit together to produce one "virtual" information model. As such, both are independent of any particular data storage mechanism and access protocol. However, mappings can be defined to translate the data from this single virtual information model to a form that can be implemented in a specific type of data storage mechanism that uses one or more specific access protocols. Examples of mapping the concepts of the [PCIM] and this document to a form that can be implemented in a directory that uses LDAP as its access protocol are provided in [PFSCHEMA] and [QOSSCHEMA], respectively. This document specifies an extensible information model. While this document defines facilities for building policy rules, conditions and actions to build QoS policies, it is recognized that not all required functionality can or should be defined in this document. Therefore, any implementation-specific schema that is derived from this information model should further concretize the QoS concepts of the QoS Policy schema to suit its own application-specific needs. This is best done by extending the set of classes and relationships defined in this document, as opposed to redefining new concepts that are not compatible with either this document or PCIM. 2.2 High-Level Class Hierarchy The following diagram shows how the classes in this document relate to the classes defined in the PCIM. Snir, Ramberg, Strassner, Cohen expires May 2001 11 Draft-ietf-policy-qos-info-model-02.txt November 2000 [unrooted] | +--Policy (abstract, defined in PCIM) | | | +---PolicyGroup (PCIM) | | | | | +---qosPolicyDomain (this document) | | | | | +---gpsPolicyGroup (this document) | | | +---PolicyRule (PCIM) | | | +---PolicyCondition (abstract, defined in PCIM) | | | | | +---PolicyTimePeriodCondition (PCIM) | | | | | +---VendorPolicyCondition (PCIM) | | | | | +---gpsPolicySimpleCondition (this document) | | | | | +---gpsPolicyCompoundCondition (this document) | | | +---PolicyAction (abstract, defined in PCIM) | | | | | +---VendorPolicyAction (PCIM) | | | | | +---qosPolicyPRAction (this document) | | | | | +---qosPolicyPHBAction (this document) | | | | | +---qosPolicyRSVPAction (this document) | | | | | +---qosPolicyRSVPSignalCtrlAction (this document) | | | | | +---qosPolicyRSVPInstallAction (this document) | | | +---gpsPolicyTrfcProf (this document) | | | | | +---qosPolicyPRTrfcProf (this document) | | | | | +---qosPolicyRSVPTrfcProf (this document) | | | +---gpsPolicyVariable (abstract, this document) | | | +---gpsPolicyValue (abstract, this document) | | | | | +---gpsPolicyIPv4AddrValue (this document) | | | | | +---gpsPolicyIPv6AddrValue (this document) (continued on next page) Snir, Ramberg, Strassner, Cohen expires May 2001 12 Draft-ietf-policy-qos-info-model-02.txt November 2000 (continued from previous page) [unrooted] | +--Policy (abstract, defined in PCIM, repeated for convenience) | | | +---gpsPolicyValue (this document, repeated for convenience) | | | | | +---gpsPolicyMACAddrValue (this document) | | | | | +---gpsPolicyStringValue (this document) | | | | | +---gpsPolicyBitStringValue (this document) | | | | | +---gpsPolicyDNValue (this document) | | | | | +---gpsPolicyAttributeValue (this document) | | | | | +---gpsPolicyIntegerValue (this document) | | | +---gpsPolicyMeter | | | +---qosPolicyQueue | | +--CIM_ManagedSystemElement (abstract, defined in PCIM) | +--CIM_LogicalElement (abstract, defined in PCIM) | +--CIM_System (abstract, defined in PCIM) | +---CIM_AdminDomain (abstract, defined in PCIM) | +---PolicyRepository (PCIM) 3. QPIM Hierarchies QPIM, following the information organizational paradigm of [PCIM], is an object-oriented information model. As in [PCIM], this model defines two hierarchies of object classes: structural classes representing policy information and control of policies, and relationship classes that indicate how instances of the structural classes are related to each other. In the rest of this section, we describe the organization and structure of the QPIM hierarchies. Section 3.1 expands the previous paragraph and describes the inheritance and relationship hierarchies that are used in the construction of the QoS information hierarchies. Section 3.2 describes how the different information hierarchies can be used to build the desired information hierarchies of the policy application. Snir, Ramberg, Strassner, Cohen expires May 2001 13 Draft-ietf-policy-qos-info-model-02.txt November 2000 Section 3.3 describes the structure of the reusable objects repository. Finally, section 3.4 explains the relationships between the domain data tree and the reusable-object repositories. 3.1 Class and Relationship Hierarchies Defined in the QPIM The QPIM consists of two hierarchies: an inheritance hierarchy that is used to define a set of classes that represent entities in the managed policy environment, and a relationship hierarchy that is used to define a hierarchy of relationships that describe how different objects interact with each other. These hierarchies work together to describe entities in the managed environment and how they relate to and interact with each other. Two relationship constructs are used in the formal presentation of QPIM. The first is an association, which models different types of dependency relationships between two (or theoretically more) objects. The second is an aggregation, which is a strong form of association that typically represents a "whole-part" or a "containment" relationship. Both associations and aggregations are modeled as classes that contain references to the objects that are participating in the relationship. In addition, both associations and aggregations can be defined between classes without affecting any of the related classes. That is, the addition of either an association or an aggregation does not affect the function or structure of the related classes. Note that containment is a directional relationship - the containing entity is known as the aggregate (the "whole" side of the relationship), and the contained entities are known as the components (the "part of" side of the relationship). For example, the relationship between a policy container (e.g., gpsPolicyGroup, which is defined in this document as a subclass of PolicyGroup, which is defined in [PCIM]) and the rules it contains (e.g., PolicyRule, which is defined in [PCIM]) is modeled by an aggregation (PolicyRuleInPolicyGroup, which is defined in [PCIM]). However, the association between a reusable object and the repository in which it resides models a "resides-in" relationship rather than "part-of" relationship. This is because a given reusable object can reside in any repository according to the discretion of the administrator - there is no whole-part relationship connoted by placing a reusable object in a repository. Rather, there is only a dependency relationship that states that in order to find the given reusable object, you must look in this particular repository. On the other hand, there is a whole-part relationship established when a policy container, such as a PolicyGroup or a gpsPolicyGroup, is used to contain a particular PolicyRule. Now, we are adding specific semantics that say that a particular PolicyRule is-a-part-of a given policy container. Snir, Ramberg, Strassner, Cohen expires May 2001 14 Draft-ietf-policy-qos-info-model-02.txt November 2000 Relationship classes may be used to extend the semantics of the relationship beyond the basic containment or reference concepts. For example, a relationship class may contain added attributes that add particular semantics. For example, the PolicyConditionInPolicyRule aggregation defines the relationship between a PolicyRule and a set of policy conditions (PolicyCondition, defined in [PCIM]). In this case, the PolicyRule acts as a container, and can hold zero or more PolicyConditions (which are the contained objects). Since this is expressing a whole-part relationship, it is modeled as an aggregation. However, this aggregation class carries two additional properties: GroupNumber and ConditionNegated. These properties are used to add to the relationship itself the semantics of sub-grouping of conditions and whether to prepend a Boolean 'NOT' operator to the condition. Implementers of a particular QoS Policy system may further sub-class relationships to incorporate additional application-specific semantics as required. Comprehensive presentation of relationships and their modeling is available in [PCIM]. Two important examples of using aggregation are composition and scoping. An example of composition is the PolicyRule. It has its own attributes, but it is only complete when it is used in conjunction with a set of conditions and actions. Conceptually, a PolicyRule serves as a container that aggregates a set of PolicyCondition objects and a set of PolicyAction objects. An example of scoping is grouping objects under a single container (e.g., qosPolicyDomain) so that common administrative rules can be applied to all of the objects in a container. 3.2 Implementation Guidelines The QPIM defines two information hierarchies. Objects that are to be managed are represented by the classes in the inheritance hierarchy. Behavior that is to be represented and managed is represented by the classes in the relationship hierarchies. An implementation is not complete if just the class inheritance hierarchy is implemented - both hierarchies MUST be implemented. Many data storage technologies are incapable of directly representing relationships. However, all data storage mechanisms of interest can either emulate relationships or have specific constructs that can implement some, but not all, relationships. For example, an LDAP based directory does not have the concept of a general dependency relationship (although one can be implemented in a variety of ways), but it does have the concept of a containment relationship. In general, an implementation will define two types of information. The first type of information is policy definition data. This information consists of policy rules and groups, and the components of policy Snir, Ramberg, Strassner, Cohen expires May 2001 15 Draft-ietf-policy-qos-info-model-02.txt November 2000 rules, that are used to govern the application of policies to manage entities. The second type of information is a set of nested containers that form a hierarchy for storing and managing reusable objects. For applications that want to manage and control QoS, containers provide significant convenience benefits. Containers can be used to group similar policies and policy information together in order to make the policy data easier to manage. They also enable an organization to impose its own views of organizing policies and policy information in the data store. This is done in QPIM by enabling a single monolithic repository to be conceptually divided into a set of repositories that reflect the administrative use of the policies. To this end, the QPIM not only supports the use of containers for grouping information, but also for determining execution semantics of policy rules. 3.2.1 Modeling Containment Containment is a general concept that is expressed in an information model using either an association or (more usually) an aggregation. Different data stores have different characteristics (e.g., data structures, organization of data, and access protocols). Therefore, there will be many mappings from a single information model, one for each type of data store. This means that containment may be expressed differently in each mapping. However, this document makes no explicit or implicit assumptions about the storage mechanism, access protocol, or other characteristics of different data stores. The information model presented here can be mapped to most storage mechanisms and models, such as LDAP directories, relational DBMS, SMI, and others. For example, the basic mechanism used for expressing containment when mapping to a directory is placement of the objects in the data tree. To express the relationship of "container - contained" between a container object and the objects it contains, the contained objects are placed below the container object. In a relational database system, on the other hand, this relationship may be implemented by means of various key/foreign-key join mechanisms. In QPIM (as well as in [PCIM]) an object may be related to its container in one of two ways. We refer to these methods as "ad-hoc" containment and "indirect" containment, as follows: 1. To establish ad-hoc containment the object is created and is associated to its container by means of an instance of the appropriate aggregation class. 2. To establish indirect containment the object is created and placed in a reusable-object repository The contained object must be given a unique name that is scoped by the containing repository. The instance of the aggregation class must now contain a reference to the reusable object. Snir, Ramberg, Strassner, Cohen expires May 2001 16 Draft-ietf-policy-qos-info-model-02.txt November 2000 The difference between ad-hoc objects and reusable objects is that ad- hoc objects need not be named - they are implicitly scoped by their containing object. However, reusable objects must be uniquely named so that the object that is referencing them can differentiate between reusable objects of the same type. Reusable-object repositories facilitate the central management of commonly referenced objects like named conditions and actions, or commonly occurring variables and values that are used in conditions. 3.2.2 Implementing Relationships [PCIM] recommends that relationships be implemented as classes. In [PCIM] (as well as in QPIM), aggregation and association classes serve these two purposes: 1. Model a relationship between two objects. One of the most important types of relationships for QoS is containment. Relationships are used in QPIM to model the relation between a container entity and its contained entities. 2. Unify the containment model so that both ad-hoc and indirectly contained objects (which are accessed in a reusable-object repository) are treated identically The following paragraphs explain how the three purposes are accomplished. 3.2.2.1 Relationship modeling A relationship class models containment (as well as other types of dependencies) as a set of (usually bi-directional) references. For a binary relationship (which is the overwhelming majority of relationships used), one reference property points to an object on one side of the relationship while another property points an object in the other side of the relationship. Sometimes it is important for a relationship to express added semantics. Since a relationship is modeled as a class, the relationship itself may use all the power of class design. This means that in [PCIM] and QPIM, relationships can contain properties and methods, and may take advantage of inheritance. For example, the relationship may be assigned properties that are used to represent specific semantics of the relationship itself. For example, if the information order requires some sub-grouping of the contained object, as is the case for conditions in a policy rule (e.g., PolicyCondition, which is defined in [PCIM]), then the corresponding relationship class (e.g., PolicyConditionInPolicyRule, which is defined in [PCIM]) will have a corresponding property (i.e., GroupNumber) that represents the group membership number. This is a technique that enhances the independence of the two objects on both ends of a relationship, because such Snir, Ramberg, Strassner, Cohen expires May 2001 17 Draft-ietf-policy-qos-info-model-02.txt November 2000 properties connote that their values reflect the relationship itself and not an inherent property of either object participating in the relationship. In other words, the container doesn't carry constituent specific information, and the contained object is independent from other contained objects and its container. 3.2.2.2 Representing Containment in a Consistent Manner Recall that a container may contain reusable objects as well as "ad- hoc" objects. The contained objects themselves are not "aware" of their reusability status; there's no property in the contained object class that denotes reusability. The aggregation relationship is also unaware of whether the contained object happens to be reusable or not. It merely carries a reference to this object in one of its properties (e.g., the PartComponent property of the PolicyConditionInPolicyRule class, defined in [PCIM]). The membership of an object in a reusable- object repository is represented by an association between the particular repository and the member object. It is fully expressed by this association so that the repository, the container and the contained objects can be independent. This approach also contributes to data integrity and scalable data storage mapping implementation. 3.2.3 Mapping Differences and Examples Mapping the information model to different data storage mechanisms may result in various interpretations and implementations. To end this section we'll discuss two comprehensive examples to illustrate some of the issues concerning implementation and to highlight the flexible design this model provides. Note that even for an LDAP directory, there could be many different interpretations that result in different data models. Two companion documents to QPIM, [PFSCHEMA] and [QOSSCHEMA], specify a standard mapping of QPIM to an LDAP directory. Example 1: Aggregation in LDAP directories An LDAP aggregation class is specified to implement each aggregation class in the information model. When adding a contained object to a container, an instance of the aggregation class is created and the aggregation property that points toward the contained object is assigned a DN for that object. No distinction is possible (nor is it desired!) between an aggregation instance for an ad-hoc object and that of a reusable object. All instances of the aggregation as well as all ad-hoc objects are placed directly under the container instance in the DIT. When collecting the contained object, a single LDAP search may be used to fetch all objects residing directly under the container. A simple procedure can determine if reusable objects exist and require added fetch operations. The procedure scans the aggregation instances and fetches those that have not already been fetched because they did not reside in the node directly under the container. Fetching a reusable Snir, Ramberg, Strassner, Cohen expires May 2001 18 Draft-ietf-policy-qos-info-model-02.txt November 2000 object is done by using the DN in the aggregation property that contains a reference to the contained object. Example 2: Aggregation in a relational DBMS No standards-based mapping has yet been defined for any RDBMS at this time. This example merely studies a possible implementation. We'll assume that the aggregation is "simple" and does not define any additional properties to carry added semantics beyond the container- contained relationship. Two tables are of interest: 1. Container object class: A row exists for each container object of this class. 2. Contained object class: A row exists for each contained object of this class. Because this is a "simple" relationship as described above, no special relationship class is necessary. Instead, the contained object table has a column that is a foreign key to the container object. For example, suppose a container class C is implemented in a table CT with a primary key column pkc. A contained object class CO is implemented in a table COT with a foreign key column fkc (referencing CT). When collecting contained objects in table COT for the container object (which is table CT), the following SQL statement can do the job through a simple join: Select <properties list> from COT, C where COT.fkc == C.pkc; Note, however, that this is a very restrictive implementation. It might be advisable to implement a third table for the aggregation itself so that adding columns to carry added semantics can be done without having to redefine the schema. 3.3. QoS Domain Data Tree The entity that represents a single policy hierarchy is called a QOS Domain, and is modeled by the qosPolicyDomain class. This class is a derivative of the PolicyGroup class in [PCIM]. Figure 1 shows a summary view of the QoS domain data tree hierarchy. The text in parentheses refers to the explanations below the figure, which provide specific semantics for each object in the hierarchy. Snir, Ramberg, Strassner, Cohen expires May 2001 19 Draft-ietf-policy-qos-info-model-02.txt November 2000 +---------------+ |qosPolicyDomain| (root of the data hierarchy) +---------------+ | +----------+ |-->|policyRule| (a) | +----------+ | | +------------------------+ | |-->|gpsPolicySimpleCondition| (b) | | +------------------------+ | | +--------------------------+ | |-->|gpsPolicyCompoundCondition| (b) | | +--------------------------+ | | | +------------------------+ | | |-->|gpsPolicySimpleCondition| (c) | | | +------------------------+ | | | +--------------------------+ | | |-->|gpsPolicyCompoundCondition| (d) | | +--------------------------+ | | +---------------+ | |-->|qosPolicyAction| (e) | | +---------------+ | | +----------+ | |-->|policyRule| (f) | | +----------+ | | +--------------+ | |-->|gpsPolicyGroup| (g) | +--------------+ | +--------------+ |-->|gpsPolicyGroup| (h) | +--------------+ | | +----------+ | |-->|PolicyRule| (i) | | +----------+ | | +--------------+ | |-->|gpsPolicyGroup| (j) | +--------------+ | +---------------+ |-->|qosPolicyDomain| (k) +---------------+ Figure 1: Qos Domain Data Tree Hierarchy Explanation to the relationships defined in figure 1: a - Any number of PolicyRule instances may be contained by a given qosPolicyDomain instance in the hierarchy by using the PolicyRuleInPolicyGroup aggregation. This has the effect of making such policyRules global for that container. Finer granularity can be obtained by either nesting qosPolicyDomain instances (shown in relationship (k)), or by embedding other types of containers (e.g., Snir, Ramberg, Strassner, Cohen expires May 2001 20 Draft-ietf-policy-qos-info-model-02.txt November 2000 gpsPolicyGroup, which is shown in relationship h) within a given qosPolicyDomain container. Note that gpsPolicyGroup objects can also be nested, as shown in relationship (j). b - Any number of qpsPolicySimpleCondition and gpsPolicyCompoundCondition instances may be contained by a PolicyRule instance via the PolicyConditionInPolicyRule aggregation. c - Any number of gpsPolicySimpleCondition instances may be contained by an instance of a gpsPolicyCompoundCondition via the PolicyConditionInPolicyCompoundCondition aggregation. d - Any number of gpsPolicyCompoundCondition instances may be contained by an instance of a gpsPolicyCompoundCondition via the PolicyConditionInPolicyCompoundCondition aggregation. The nested containment combined with (c) above facilitates formation of arbitrary Boolean expression and reuse of existing conditions as components of such expressions. e - Any number of qosPolicyAction instances may be contained by a PolicyRule instance via the PolicyActionInPolicyRule aggregation. f - Any number of PolicyRule instances may be contained by another PolicyRule instance by using the PolicyRuleInPolicyRule aggregation. This allows for recursively nesting policy rules within a given policyRule instance, thus forming rule/sub-rule semantics. g - Any number of gpsPolicyGroup instances may be contained by an instance of PolicyRule via the PolicyGroupInPolicyRule aggregation. This aggregation also implements a rule/sub-rule relationship similar to the one defined in (f). However, it is somewhat richer, in that it allows a complete policy container (i.e., a group of rules) to be nested within a rule as a reusable unit. h - Any number of gpsPolicyGroup instances may be contained by an instance of a qosPolicyDomain via the PolicyGroupInPolicyGroup aggregation. i - Any number of PolicyRule instances may be contained by an instance of a gpsPolicyGroup via the PolicyRuleInPolicyGroup aggregation. j - Any number of gpsPolicyGroup instances may be contained within another gpsPolicyGroup instance by using the PolicyGroupInPolicyGroup aggregation. This allows for recursive nesting of groups of rules within a given gpsPolicyGroup instance. This enables one policy container to scope other contained policy containers. Note also that all subclasses of PolicyGroup (e.g., both the gpsPolicyGroup as well as the qosPolicyDomain class) inherit this relationship. Snir, Ramberg, Strassner, Cohen expires May 2001 21 Draft-ietf-policy-qos-info-model-02.txt November 2000 k - Any number of qosPolicyDomain instances may be contained by an instance of a qosPolicyDomain class via the PolicyGroupInPolicyGroup aggregation. This effectively enables the administrator to define a hierarchical set of administrative roots within a single, larger administrative scope. 3.4 Types of Grouping Classes There are three fundamental types of grouping mechanisms defined in this document, represented by three different classes. These are the PolicyGroup, QoSPolicyDomain, and gpsPolicyGroup classes. The PolicyGroup class is defined in PCIM. This class is a generalized aggregation container. It enables either PolicyRules or PolicyGroups to be aggregated in a single container. It has no properties and no additional semantics. The qosPolicyDomain class is defined in section 8.14 of this document. This class is a subclass of PolicyGroup, and is used to define the root of a single administrative QoS policy domain. As such, it contains the domain's policy rules and other associated data. Note that additional containers that are aggregated by this object can define additional policy rules and other policy data that are specific to that level of scoping. This class defines the following additional semantics compared to a PolicyGroup: - the root of a single administrative policy domain - the decision match strategy to be employed by default for all objects that are aggregated by this object (note that individual containers may override this default behavior by defining their own match strategies at their scoping level) The gpsPolicyGroup class is defined in section 8.15 of this document. This class is also a subclass of PolicyGroup, and represents an administratively-defined policy rule container. All policies that are commonly administered are defined in a particular gpsPolicyGroup. This class defines the following additional semantics compared to a PolicyGroup: - the container is allowed to have its own priority; this enables it to be treated the same as a policy rule when the order of execution is determined - the container is allowed to have its own decision match strategy (note that this may be used to override the default match strategy defined in a qosPolicyDomain) - the container has a property that collects the roles and role- combinations that are associated with all of the policy rules that are aggregated by this container. Snir, Ramberg, Strassner, Cohen expires May 2001 22 Draft-ietf-policy-qos-info-model-02.txt November 2000 The difference between the qosPolicyDomain and the gpsPolicyGroup classes are: - the qosPolicyDomain class serves as the root of a policy domain; the gpsPolicyGroup is not to be used for this purpose - conceptually, gpsPolicyGroups are aggregated by a qosPolicyDomain; the gpsPolicyGroups serve to provide a finer level of granularity in defining and applying policies - gpsPolicyGroups have roles and role-combinations, while qosPolicyDomains do not - gpsPolicyGroups have priorities, which qosPolicyDomains do not One final note: each of these classes can serve as a container in various data store implementations. Thus, the more general term "container" will be used in this document to refer to a class that can aggregate objects. If special semantics are required, then either a qosPolicyDomain or a gpsPolicyGroup will be specifically called out, according to the desired semantics. 3.5. QoS Policy Domain Grouping and Nesting The qosPolicyDomain class is used to establish a QoS policy domain within a particular data store. Different objects can be placed in this policy domain so that they can then be grouped together and managed according to a common set of policies. However, sometimes a more sophisticated organization of policy information is required. In this case, multiple QoS policy domains may be grouped together to provide more granular management of policy data. Each domain may be viewed as a contiguous set of nodes that operate under a common system of administration and provide a common set of services. Each node can contain policy rules and/or policy information. Grouping may be desired to enhance various administrative tasks (e.g., ensure that a set of objects are all updated), or it may be required by a particular policy application. For example, a particular policy application may need a combination of policy rules and other data. Storing these different data in a common container in a domain that belongs to that application considerably simplifies this process. The grouping strategy (as well as all location-oriented strategies) is left for users and vendors to model, based on their unique situations and requirements. This document presents guidelines and recommendations for constructing QoS domains and grouping objects within a QoS domain. Specific implementations may use other techniques to construct QoS domains and to group objects within a QoS domain without violating the integrity and consistency of the QPIM as long as two constraints are met. First, the implementation MUST NOT define a class that performs the same function as a QPIM class. If a QPIM class is deemed Snir, Ramberg, Strassner, Cohen expires May 2001 23 Draft-ietf-policy-qos-info-model-02.txt November 2000 insufficient for a specific application, then that application SHOULD derive a subclass from the QPIM class (as opposed to build a parallel class that conflicts with the QPIM class). Second, the implementation MUST NOT redefine QPIM classes in any way. This includes, but is not limited to, canceling (also called deleting) attributes, renaming attributes, or changing the purpose that a class or attribute was designed for. One way to group QoS policy domains is by creating a common root (which is not necessarily modeled in this document) for several QoS policy domain data tree instances. This can be done by using the PolicyGroup (defined in [PCIM]) class as a root for the multi-domain tree (but other objects may be used as well). In this case, all that is needed is to implement a containment of a the appropriate number of qosPolicyDomain (defined in this document) instances within the appropriate PolicyGroup instance. Figure 2 is an example that depicts the ability to provide different classes of service to different organizations within a single enterprise. In this example, the enterprise is represented by an instance of the PolicyGroup class. The different organizations are each represented by a separate QoS policy domain (which is an instance of the qosPolicyDomain class). Each qosPolicyDomain class is used as a container to hold all of the policies for a given portion of the organization. In Figure 2, this level is represented by the nesting level of qosPolicyDomain classes that constitute the hierarchy of container classes shown in Figure 2. Each qosPolicyDomain instance serves as a container that contains an ordered list of related QoS policy rules that apply to a different part or function of the domain (e.g., Eastern Sales vs. Western Sales). This grouping is done using instances of the gpsPolicyGroup class. The gpsPolicyGroup class would in turn contain either a set of PolicyRule instances, a set of PolicyGroup instances (to provide further grouping of policy rules that are scoped by a given gpsPolicyGroup), or both. Snir, Ramberg, Strassner, Cohen expires May 2001 24 Draft-ietf-policy-qos-info-model-02.txt November 2000 +-------------+ |policyGroup | <------------------- QoS policies for an enterprise +-------------+ | | +---------------+ -->|qosPolicyDomain| <----------- QoS policies for the Sales group +---------------+ | | +---------------+ |-->|qosPolicyDomain| <-------- QoS policies for Western Sales | +---------------+ | | | | +--------------+ | |-->|gpsPolicyGroup| <--Qos Policies for group | | +--------------+ A within Western Region | | | | +--------------+ | -->|gpsPolicyGroup| <--Qos Policies for group | +--------------+ B within Western Region | | +---------------+ -->|qosPolicyDomain| <--------QoS policies for Eastern Sales +---------------+ | | +--------------+ |-->|gpsPolicyGroup| <--Qos Policies for group | +--------------+ C within Eastern Region | | +--------------+ -->|gpsPolicyGroup| <--Qos Policies for group +--------------+ D within Eastern Region Figure 2: Top-level Policy Data Tree Example The modeling approach used in the previous example is but one possible strategy among many. This information model allows for arbitrary nesting of containers, groups and rules, thus providing the means for modeling both wide and deep policy hierarchies. 3.6. Resource Sharing Object instances residing in different branches of the data tree are independent of each other. That is, there is no cross-referencing among objects located in different QoS policy domains. However, multiple QoS policy domains may still share data by using a special mechanism. This mechanism is called referencing reusable objects. A reusable object is an object that is placed in a special portion of the data store dedicated to sharing information among multiple clients that Snir, Ramberg, Strassner, Cohen expires May 2001 25 Draft-ietf-policy-qos-info-model-02.txt November 2000 wish to access the same information. In fact, there may be multiple such repositories, each used for collecting a different set of related reusable objects. In this document, we will call such repositories reusable-object repositories. (Note that [PCIM] refers to this object as a PolicyRepository; we are using the term "reusable-object repository" to emphasize the fact that this is a special "repository- in-a-repository" for containing reusable objects). The sharing of global or common objects enhances the interoperability of various policy applications, thus serving the primary goal of this information model. Such commonly used building blocks as PolicyGroup and its subclasses (e.g., gpsPolicyGroup and qosPolicyDomain), subclasses of PolicyCondition (e.g., qpsPolicySimpleCondition and gpsPolicyCompoundCondition)and PolicyAction (e.g., qosPolicyPRAction and qosPolicyRSVPAction), as well as lower-level objects (e.g., instances of qpsPolicyVariable and qpsPolicyValue) can be placed in the reusable-object repository and used by multiple policy rules from multiple domains. Both the PCIM and the QPIM do not restrict the number of reusable- object repositories that can be referenced from a single domain. Even a single instance of a policy rule may contain references to objects residing in more than one repository. It is important to note that the QPIM does not dictate a QoS domain-wide scope for reusable objects, so as to keep this concept as general as possible. 3.7. Instance Location The purpose of the QPIM is to define a flexible structure of information that does not pre-impose harsh restrictions on building the data tree. When a data tree is derived from the QPIM, it is important to ensure that this derivation is as free of restrictions as possible. Although each data store has its own special considerations to be taken into account, one of the most important considerations in mapping for directories concerns placement of entries. The QPIM MUST NOT contain any hidden assumptions about the placement of particular QoS policy domain hierarchies (including, for that matter, placement of reusable- object repositories as explained in section 3.13 below). Consequently, the QPIM does not require any pre-defined locations for the portion of the data tree that is dedicated to policy. An instance of the global data tree (a corporate directory, for example) may in fact contain several QoS policy domains that exist within the global date tree in various places. Zero or more reusable-object repositories may also be present in the global data tree. In addition, the QPIM does not dictate any standard organization of objects to be controlled via policy, either for QoS policy classes and relationships or for reusable-object repositories that are used by QoS applications. Snir, Ramberg, Strassner, Cohen expires May 2001 26 Draft-ietf-policy-qos-info-model-02.txt November 2000 The only location/organizational rule that must be followed is: Each QoS policy domain must contain complete policy information that is necessary to describe that particular policy domain. Reusable objects SHOULD be placed in one or more reusable-object repositories and referenced by one or more objects that exist in the QoS policy domain, as appropriate. Note specifically that there is no requirement for reusable objects to be placed in the policy domain itself. Furthermore, reusable objects MUST be referenced using the properties defined in the appropriate [PCIM] and QPIM classes. 3.8. Policy Containers A QoS policy domain is a container that provides scoping for QoS policy containers, policy rules, and other policy information, as mentioned previously. There are two information model class that are used to represent QoS policy containers: the qosPolicyDomain and the gpsPolicyGroup classes. Both classes extend the PolicyGroup class, which is defined in [PCIM]. The ability to "divide" a given QoS policy domain's policy rules among a set of policy containers provides a flexible framework to realize a fine-grained administrative (or functional) structure. As the example in figure 2 illustrates, it makes sense to divide policies for the sales organization into two regional containers: Western and Eastern. This enables a change in policies for one region to not affect the policies currently in place for the other region. Both the gpsPolicyGroup as well as the qosPolicyDomain policy containers can be nested (e.g., a container may contain multiple containers). A particular data tree, then, may be constructed with as deep a hierarchy as needed. 3.8.1 Semantics of a gpsPolicyGroup A (non-empty) gpsPolicyGroup holds an ordered list (i.e., a set) of PolicyRule and/or gpsPolicyGroup instances. Both the gpsPolicyGroup class and the PolicyRule class carry a priority property (called gpPriority and Priority, respectively). Note that the PolicyGroup class does NOT have a priority property - this is one of the reasons that the PolicyGroup class has been subclassed in this document to provide these semantics (through the gpsPolicyGroup class). These properties are used to specify the order in which objects within a gpsPolicyGroup are processed. The gpPriority property added to the gpsPolicyGroup enables it to be treated the same way as a PolicyRule. That is, both the gpsPolicyGroup as well as the PolicyRule will appear as atomic objects that each has their own distinct priority. Snir, Ramberg, Strassner, Cohen expires May 2001 27 Draft-ietf-policy-qos-info-model-02.txt November 2000 The semantics of the gpPriority property in the gpsPolicyGroup class are identical to the semantics of the Priority property in the PolicyRule class. Larger values mean higher priority (i.e., objects having a higher priority will be processed before objects that have a lower priority). If two or more objects have equal values, then those objects may be evaluated in any order with respect to each other. For example, if there are four objects A, B, C, and D having priorities 3, 5, 5, and 8, respectively, acceptable processing orders are {D, C, B, A} and {D, B, C, A}. Note that the gpPriority and Priority properties of the gpsPolicyGroup and PolicyRule classes respectively may be unassigned, in which case they are treated as having the numerical value of 0. The reason to define a priority for the gpsPolicyGroup is to be able to assign a "match strategy" (this is the gpNamedPolicyRuleMatchMethod property of the gpsPolicyGroup class) to the gpsPolicyGroup. Remember that a gpsPolicyGroup contains its own set of PolicyRules (and possibly additional gpsPolicyGroups). Therefore, we need a way to evaluate the PolicyRules that are contained in a gpsPolicyGroup relative to PolicyRules that exist at the same level as the gpsPolicyGroup. This property dictates the execution order of the contained QoS policy rules, based on the values of the priority properties of the contained instances. For example, a 'First Match' strategy means that the groups and/or rules will be "matched" according to ascending order of their Priority attribute. Decision strategies are explained in section 5. Note also that the specific semantics of "execution order" depend on the match decision strategy that is being used. For example, if a "match-first" strategy is being used, then the first rule whose conditions match (i.e., evaluated to Boolean 'TRUE') will have its actions executed. However, if a "match-all" strategy is being used, then all rules will be scanned for conditions that match. Then, the actions for each rule that has matched will be executed in priority order for all rules whose conditions were matched. Figure 3 shows a simple example of the above execution process. Section 4 describes policy rules in more detail. Snir, Ramberg, Strassner, Cohen expires May 2001 28 Draft-ietf-policy-qos-info-model-02.txt November 2000 +---------------+ |qosPolicyDomain| +---------------+ | | +--------------+ |-->|PolicyRule A | | | Priority=19 | | +--------------+ | | +-----------------------+ +-------------+ |-->|gpsPolicyGroup |--->|PolicyRule C | | | gpPriority=5 | | | Priority=7 | | +-----------------------+ | +-------------+ | | | +-------------+ | +-------------+ -->|PolicyRule B | ->|PolicyRule D | | Priority=3 | | Priority=2 | +-------------+ +-------------+ Figure 3. Example Ordering for a QoS Policy Decision In this example, the ordering is A, then C, then D, then B. This is because the gpPriority property of the gpsPolicyGroup is higher than the Priority property of PolicyRule B, so each of the PolicyRules contained in the gpsPolicyGroup (i.e., PolicyRule C and PolicyRule D) are executed (in priority order) before PolicyRule B. If the gpsPolicyGroup's priority was not defined, then the order between the policy rules would have been A, then C, then B, and finally D (note in this last example that the Priority property of a PolicyRule is treated identically to the gpPriority property of a gpsPolicyGroup). 3.8.2 Priority and Decision Strategy Applied to Containers Each policy rule as well as each policy container may have an order attribute (Priority for PolicyRule and gpPriority for gpsPolicyGroup, respectively). The ordering is interpreted as a function of the priority value AND the particular level of aggregation that the PolicyRule or gpsPolicyGroup resides in. For example, in Figure 3 above, PolicyRule A and PolicyRule B, as well as the gpsPolicyGroup, are all at the same level of containment. The priority of each of these objects must be compared with each other. Note that it would be incorrect to ignore the priority of the gpsPolicyGroup and try and compare the priorities of the policy rules that it contains (C and D) to the priorities of policy rules A and B. Snir, Ramberg, Strassner, Cohen expires May 2001 29 Draft-ietf-policy-qos-info-model-02.txt November 2000 3.8.3 Sharing Policy Containers For shared (reusable) containers, the priority assigned to the shared container must be correct for all containing objects. This restriction makes it impractical to share a particular policy container directly (i.e., for two applications belonging to two different QoS policy domains to share the same policy container). This is because a policy container can contain not just policy rules, but also additional policy containers. However, sharing (i.e, reusing) a policy container can be made possible by "enclosing" a shared container within an exclusive container (i.e., a container that is used to contain just a single instance of a gpsPolicyGroup object). This in effect makes the gpsPolicyGroup act as a single-level container. Depending on the sharing context, the following techniques can be used for sharing an instance of the gpsPolicyGroup class: 1. Reusing a gpsPolicyGroup inside a gpsPolicyGroup To reference a container C1 with priority P1 from a container C, an enclosing container D is created and is assigned the desired priority P1 within the context of the C container. The D container is placed under the C container in the data tree implementation. The D container contains a single object, C1, by means of the PolicyGroupInPolicyGroup aggregation. The D container complies with the naming and ordering restrictions -- it is only created in the context of the C container and can not be reused by any other container. This means that the container C1 can not contain additional containers, even though it is normally able to. 2. Reusing a gpsPolicyGroup inside a policyRule To reference a container C1 with priority P1 from a policy rule R (making it a "sub-rule" object, as opposed to a (more general) container that is shareable by multiple policy rules), an enclosing container D is created and is assigned the desired priority P1 within the context of the sub-rule. The D container is contained in the rule by using the PolicyRuleInPolicyRule aggregation. This aggregation effectively places a given rule under an existing rule (in our example, PolicyRule R contains a set of conditions and actions as well as the container D; container D contains a single object, which is another policy rule, but this policy rule acts as a sub-rule of R) using the PolicyGroupInPolicyGroup aggregation. This structure enables either another rule, R', or a policy container, C', or both, to now share the C1 container by similar means. Note that a shared container (C1 in the descriptions under #1 and #2 above) MUST be named so that it can be placed in a reusable-object repository (see section 3.13). Snir, Ramberg, Strassner, Cohen expires May 2001 30 Draft-ietf-policy-qos-info-model-02.txt November 2000 Figure 4 illustrates the above example of sharing a policy container between a policy container and a policy rule. The numbers in parentheses denote in-context ordering. (rest of the hierarchy) | | +-------+ |-->| C (1) | | +-------+ | | +--------+ (cont.) |-->| R1 (1) | | +--------+ | +-------+ |-->| D (2) | | +-------+ | | +--------+ | |--PolicyGroupInPolicyGroup-->| C1 (*) |<----+ | +--------+ ^ | +--------+ | |-->| R2 (3) | | | +--------+ | | +--------+ | |-->| R3 (4) | | | +--------+ | | | +--------+ | (cont.) |-->| R5 (1) | | | +--------+ | | +--------+ | |-->| D' (2) | | | +--------+ | (cont.) | | |--PolicyGroupInPolicyGroup---------->+ (*) denotes a priority which is always ignored for reusable (shared) policy containers. Figure 4. Sharing policy containers 3.9 Policy Roles associated with gpsPolicyGroup The property gpPolicyRoles in the gpsPolicyGroup class represents the roles and role-combinations associated with the set of policy rules and gpsPolicyGroups aggregated by a gpsPolicyGroup. Roles and role-combinations are defined in [POLTERM] and further elaborated on in [PCIM]. Each value represents one role-combination. Since this is a multi- valued property, more than one role-combination can be associated with a single gpsPolicyGroup. Snir, Ramberg, Strassner, Cohen expires May 2001 31 Draft-ietf-policy-qos-info-model-02.txt November 2000 After identifying the relevant set of rules to be used, rules should be prioritized according to the procedures and rules defined in Section 5. The PolicyRoles values defined per gpsPolicyGroup include implicitly the roles defined for the contained policy containers.Overriding a role or role-combination that is defined for a containing policy container is not allowed. The following example illustrates this situation: gpsPolicyGroup 1 : PolicyRoles: Role A, Role B | +--PolicyRule 1.1 : PolicyRoles: <Not defined> | +--PolicyRule 1.2 : PolicyRoles: Role A, Role D | +--PolicyRule 1.3 : PolicyRoles: <Not defined> | +--PolicyRule 1.3.1 : PolicyRoles: Role E PolicyRule 1.1 will be associated with roles A & B, because it inherits both of these roles from gpsPolicyGroup 1 PolicyRule 1.2 will be associated with roles A, B, & D, because it inherits roles A and B from gpsPolicyGroup 1 and adds D PolicyRule 1.3 will be associated with roles A & B, because it inherits both of these roles from gpsPolicyGroup 1 PolicyRule 1.3.1 will be associated with Roles A, B, & E, because it inherits roles A & B from PolicyRule 1.3 and adds E For a definition of the gpsPolicyGroup's PolicyRole property, refer to section 8.2.3. Extended explanation on the definition and usage of Roles is provided in [PCIM], section 5.2. Note: A role or role-combination defined in contained and containing policy objects does not imply any special behavior. The example above illustrates this situation in PolicyRule 1.2, regarding role A. 3.10. Policy Rules QoS policy rules are modeled by the [PCIM] class PolicyRule. All new behavior in [PCIM] is obtained not by altering the definition of a PolicyRule, but rather by adding new types of PolicyConditions and PolicyActions (along with other associated objects) that are used by the PolicyRule. The semantics of a policy rule is, in essence, a conditional imperative statement in the form 'if <condition> then <action>'. Applying a rule means evaluating its condition and, depending on the truth value of the condition, to either execute the action or to do nothing. Evaluating a condition is known as 'matching the rule', an expression we'll be using in later sections of this document. [PCIM] requires that Snir, Ramberg, Strassner, Cohen expires May 2001 32 Draft-ietf-policy-qos-info-model-02.txt November 2000 a given policy rule SHOULD belong to one (and only one) gpsPolicyGroup. These semantics are enforced by a special association, PolicyRuleInPolicyContainer (defined in [PCIM]), with the appropriate cardinality (1 policy container can contain zero-or-more PolicyRules). However, a policy designer may, in some cases, wish to reuse a particular rule in more than one policy container. The designer MAY do so by encapsulating the would-be reusable rule within a single, reusable policy container and sharing that container, using the technique described in section 3.8.3. The order of the policy rules inside a container is based on the relative values of the Priority attribute of each of the PolicyRules (please see [PCIM] for more information). The enforcement of policy rules also depends on particular settings belonging to the group. The match strategy to be applied to the policy rules contained in a given container is defined in the policyRuleMatchMethod attribute of the gpsPolicyGroup object. Policy rules may be nested. Placing a rule under another rule in the data tree creates a nested rule. This is done by using the PolicyRuleInPilicyRule aggregation. 3.11. Conditions and Actions A policy rule is a composite object. The most important components of a rule are the conditions and actions it contains. A condition is a Boolean expression that is evaluated to find out if the rule should be applied. An application of a rule means that the actions that it contains will be executed. An action is a specification of one or more QoS operations enforced on the designated set of flows that MUST be done if the given policy rule is to be applied. Actions are applied if the condition is TRUE (see [PCIM] for more details). 3.12. Data Tree Example The following example illustrates the hierarchical nature of the QoS Policy data tree. Each organizational entity is related to a specific type of class, which is shown in parentheses. There are two QoS policy domains in this example, grouped together under the same root (domain grouping). The QoS policy domains are: 1. EastCoast 2. WestCost Snir, Ramberg, Strassner, Cohen expires May 2001 33 Draft-ietf-policy-qos-info-model-02.txt November 2000 Assume that each of these two qosPolicyDomains has its own PHB set modeled by a gpsPolicyGroup with a set of policy rules defining the per hop behavior for different DSCP values. The EastCoast domain has 2 named policy containers. The first deals only with ERP traffic and the second handles all other traffic: 1. EastCoast (implemented as a qosPolicyDomain) 1.1. ERP (implemented as a gpsPolicyGroup) 1.2. General (implemented as a gpsPolicyGroup) The WestCoast domain has three named policy containers. The first deals only with ERP traffic, the second deals with VoIP traffic, and the third with all other traffic: 2. WestCoast 2.1. ERP (implemented as a gpsPolicyGroup) 2.2. VoIP (implemented as a gpsPolicyGroup) 2.3. General (implemented as a gpsPolicyGroup). Each one of the gpsPolicyGroup entries can contain a prioritized rule set. For example, the WestCoast ERP group contains the rules relevant to ERP applications administered by the west coast domain administrator. We see from the above structure that this structure provides the administrator with a great deal of flexibility. For example, similarly containers, represented by the ERP and General gpsPolicyGroups, can reuse common policy conditions and actions. However, they are implemented as physically different containers to enable the administrator to administer them according to their own domain-specific needs. 3.13. Reusable-Object Repositories Reusable objects are objects that can be referred by (hence "used by") other objects. For example, the reference could be accomplished by allocating an attribute on the referencing object that contains the location of the referenced object. In this information model, association classes (and naming rules) are used to establish reusability of an object by creating a "resides-in" relationship between the reusable object and the repository in which it resides. For example, the PolicyConditionInPolicyRepository association is used to enable an instance of a PolicyCondition class, or its subclasses, to reside in an instance of a PolicyRepository class, or its subclasses. The concept of reusable-object repositories is introduced by [PCIM] for the purpose of allowing data tree constructors to share data among many users. This document enhances this concept to model the needs of QoS policy rules. Snir, Ramberg, Strassner, Cohen expires May 2001 34 Draft-ietf-policy-qos-info-model-02.txt November 2000 A reusable-object repository hierarchy is rooted in an instance of the policyRepository class (defined in [PCIM]). Individual reusable-object repositories are named containers for reusable objects. Note that [PCIM] allows arbitrary nesting of reusable-object repositories. This can be conceptually thought of as a repository of repositories. Each named reusable-object repository is a container of "reusable objects" that can be used for a common purpose, and/or are administered in a common way. A reusable object MUST have a unique name within the the container that it resides in. The complete aggregation model for the reusable-object repositories, as well as detailed description of the various mechanisms for constructing and maintaining such repositories, is described in detail in [PCIM]. Common candidates for reusability are named instances of these classes and their derivatives: - gpsPolicyVariable - gpsPolicyValue - gpsPolicySimpleCondition - gpsPolicyCompoundCondition - policyAction - gpsPolicyMeter, QoSPolicyTrfcProf, QoSPolicyQueue - gpsPolicyGroup for policy rule reusability 3.14. Relationships Between QoS Domains and Repositories As explained above, a QoS policy domain contains within it groups of policy rules. A policy rule can contain ordered lists of conditions and actions. The conditions and actions may be reusable objects that reside in reusable-object repositories, or they may be rule-specific conditions and actions that are embedded within the rule, or a combination of both. The advantage of reusable objects is that many different policy rules may reference the same reusable object . References to reusable objects need not all point to the same reusable-object repository; any policy rule may contain references to reusable objects that reside in different repositories. The maintenance of the policy system is made somewhat more complicated due to the flexibility provided by the ability to use multiple repositories. For example, it is more difficult to prevent "dangling" references to repositories that are no longer present. Schema designers are encouraged to pay extra attention to this problem and exercise any technique available from their implementation platform to maintain integrity of their data trees. [PCIM] discusses this issue as well. Snir, Ramberg, Strassner, Cohen expires May 2001 35 Draft-ietf-policy-qos-info-model-02.txt November 2000 4. Constructing a QoS Policy Rule A policy rule modeled in [PCIM] represents the "If Condition then Action" semantics associated with a policy. The QPIM extends these semantics by refining the type of policy conditions and actions that can be represented, extending the use of containers that hold policy information, and providing additional features (nesting of rules, aggregation of groups inside rules, defining extensible rule decision strategies, linking to PHBs, and providing pre-defined variables and constants that can be used to express the required semantics of QoS policy rules in more detail). The following sections describe these characteristics in more detail. 4.1 Policy Rule Structure A policy rule has the following attributes (defined in [PCIM]) that can be used to provide important semantics for QoS policy applications; these are in addition to the attributes which serve as a key and provide its name: 1. An Enable flag that indicates whether a policy rule is administratively enabled, administratively disabled, or enabled for debug mode. 2. A set of conditions,contained in the rules by means of the PolicyConditionInPolicyRule aggregation. Note that the new subclasses of PolicyCondition that the QPIM defines automatically inherits this relationships 3. A flag indicating whether the rule's condition is in disjunctive or conjunctive normal form 4. An (optionally ordered) list of actions, contained in the rule by means of the PolicyActionInPolicyRule aggregation. 5. A priority value, defining the ordinal position of this rule relative to other rules (or any other contained objects) in the same container 6. The attribute named mandatory, which is used to define whether the evaluation of conditions (and the subsequent execution of actions if the conditions evaluate to TRUE) is mandatory or not 7. A SequencedActions attribute that defines how to execute the actions if the condition is TRUE 8. An array of PolicyRoles attributes, that define the roles or role-combinations that are used in this rule 9. A RuleUsage attribute, that contains a description of how this rule should be used The Boolean condition is evaluated in order to determine if the set of actions should be performed on a network flow by matching the network flow attributes against the condition. The PCIM defines a generic simple policy condition class, called PolicyCondition, which can be Snir, Ramberg, Strassner, Cohen expires May 2001 36 Draft-ietf-policy-qos-info-model-02.txt November 2000 used to contain a single condition term to be tested. This document defines two new policy condition classes. The first, gpsPolicySimpleCondition, extends the semantics of a policy condition to contain an ordered triplet ({variable, operator, value}). The second, gpsPolicyCompoundCondition, uses the gpsPolicySimpleCondition class to build a more generic compound condition class. QoS-specific conditions SHOULD be formed by using the gpsPolicySimpleCondition class and/or the gpsPolicyCompoundCondition class (both of these classes are defined in this document) and/or the policyTimePeriodCondition class defined in [PCIM] (or their subclasses, of course). Note that QoS- specific conditions MAY be mixed with more generic conditions that are not derived from either of these classes. However, these non-QoS- specific conditions SHOULD be derived from the PolicyCondition class (defined in [PCIM]). The combination of individual conditions in a policy rule is defined in [PCIM] using the PolicyConditionInPolicyRule aggregation. Each action in the list is modeled by an class derived from the PolicyAction class. The collection of individual actions in a policy rule is defined in [PCIM] using the PolicyActionInPolicyRule aggregation. This class also contains a property, ActionOrder, that defines the order in which policy actions are performed. . The interpretation of a policy rule in regard to a given network flow may be expressed as follows: If the rule is enabled and the Boolean expression is evaluated to TRUE, then use the Action list to extract the prescribed treatment for this flow. The rest of this section describes the components of the policyRule class and their relationships to the other classes defined in this information model. 4.2 QoS Policy Conditions A policy rule, as modeled in [PCIM], represents the "If Condition then Action" semantics associated with a policy. A condition is represented as either an ORed set of ANDed terms (disjunctive normal form) or an ANDed set of Ored terms (conjunctive normal form). Individual conditions may either be negated (NOT C) or not negated (C). The actions specified by a policy rule are to be performed if and only if the policy rule condition evaluates to TRUE. The semantics of an individual condition are not specified in [PCIM]. Rather, the PCIM limits itself to specifying the structure of a condition and its naming attributes. This document provides semantics for common QoS policy conditions. For example, conditions such as: "If the source IP address of the flow belongs to 10.1.x.x subnet" as well as "If the IP protocol number of the flow equals the TCP protocol number" are modeled in this document. Snir, Ramberg, Strassner, Cohen expires May 2001 37 Draft-ietf-policy-qos-info-model-02.txt November 2000 4.2.1 Simple Conditions The gpsPolicySimpleCondition class models individual conditions. This class refines the basic structure of the PolicyCondition class defined in [PCIM] by specifying the contents of the condition using the triplet <variable>, <operator> and <value> to form the condition. The variable specifies the attribute of a flow that should be matched when evaluating the condition. A set of predefined variables that cover network attributes that are commonly used for filtering are introduced to encourage interoperability. This list covers layer 3 IP attributes such as IP network addresses, protocols and ports, as well as a set of layer 2 attributes (e.g., MAC addresses) and higher level attributes such as application and user identity. The QPIM defines a single operator, "match", as explained in the 'Simple Condition Operator' section. The bound variable is matched against a value to produce the Boolean result. In the first example above, a source IP address variable is matched against a 10.1.x.x subnet value. The operator specifies the type of relation between the variable and the value evaluated in the condition. The match operator that is defined in QPIM is not just a simple equal operator - it carries additional semantics (which are defined in the PolicyValueConstraintsInVariable association) that ensure that it contains an allowed value that belongs to a pre-defined acceptable range of values. For example, an IPv4SourceAddress variable is defined as a string. But the literal value of the string must conform to the defined semantics of an IPv4 address, and must represent a legal IPv4 address in either dotted decimal or CIDR format. Similarly, a port is defined to be an integer. But negative values, or positive values greater than 65535, are not allowed. 4.2.2 Compound Conditions Sometimes it is convenient to model a general Boolean expression as an atomic condition. For example, many packet-related conditions in policy rules, from a networking perspective, can be modeled as Filters. Filters are not modeled directly in the PCIM (i.e., no Filter class is defined). However, the filter concept is central in the QoS Policy data model. Note that a filter may consist of multiple terms. The problem, then, is that if all we have are the PolicyCondition, PolicyTimePeriodCondition, and gpsPolicySimpleCondition classes, we can't refer to a filter as an atomic condition, because we will need to combine multiple instances of one or more of these classes to construct the filter. This is why the QPIM has defined the gpsPolicyCompoundCondition class. Snir, Ramberg, Strassner, Cohen expires May 2001 38 Draft-ietf-policy-qos-info-model-02.txt November 2000 The gpsPolicyCompoundCondition class enables multiple instances of the PolicyCondition, the PolicyTimePeriodCondition, the gpsPolicySimpleCondition, and/or the gpsPolicyCompoundCondition classes to be combined and treated as a single atomic entity. This enables the gpsPolicyCompoundCondition class to be used to model any general Boolean expression, including common traffic filters. A filter is constructed by the mechanisms supplied in the following PCIM attributes: 1. The ConditionListType attribute of the policyRule, which is a Boolean expression type that defines whether the simple condition is in conjunctive or disjunctive normal form. 2. The PolicyConditionInPolicyRule aggregation class that does three things: associates conditions with a particular policy rule, defines whether the condition is negated or not, and partitions the referenced conditions into one or more groups. For more details, please see [PCIM], section 6.3. 4.2.3. Using Simple Conditions Simple conditions can be used in policy rules directly or as building blocks for creating compound conditions. Simple condition composition MUST enforce the following data type conformance rule: The gpValueTypes property of the variable must be compatible with the value class name. This ensures that the binding of the variable to an acceptable value can be done. The QPIM defines four different ways to compose a simple condition through the combination of representations of variables and values. The following combinations of representing a simple condition are possible: Variable representation 1. An "ad-hoc" instance of the class gpsPolicyVariable may be contained by the gpsPolicySimpleCondition instance using the PolicyVariableInPolicySimpleCondition. 2. A reusable, named instance of the class gpsPolicyVariable, which resides in a reusable-object repository may be indirectly linked with the gpsPolicySimpleCondition instance (using the same aggregation as above) Value representation 1. An "ad-hoc" instance of the class gpsPolicyValue may be contained by the gpsPolicySimpleCondition class using the PolicyValueInPolicySimpleCondition aggregation. Snir, Ramberg, Strassner, Cohen expires May 2001 39 Draft-ietf-policy-qos-info-model-02.txt November 2000 2. A reusable, named instance of the class gpsPolicyValue may be indirectly linked with the gpsPolicySimpleCondition instance using the same aggregation as above). The first method for representing variables and values enables either to be embedded directly in a policy condition. This is important for allowing simple and efficient access to the policy condition and its embedded variables and/or values. It also enables the condition along with its embedded variables and values to be treated as an atomic object. The second method for representing variables and values enables the condition to reuse the variable and/or value. In this case, both would be stored in a PolicyRepository. Note that the method described here for composing conditions out of variables and values allows for uniform handling for both "ad-hoc" reusable objects, as the relationships between the aggregator and aggregated objects are unaware of the reusability vs. ad-hoc status of the aggregated objects. A simple condition can be added to a PolicyRule or to a gpsPolicyCompoundCondition in two ways: 1. Building a rule-specific ("ad-hoc") condition. In this case, the goal is to embed the condition directly in either the PolicyRule or the gpsPolicyCompoundCondition instance. In many data storage mechanism implementations, this will be realized by treating the PolicyRule or the gpsPolicyCompoundCondition instance as a container, and placing an instance of the condition in the container. For example, in a directory implementation, the condition will be added as a leaf object in the container. In the information model, we describe this case using either the PolicyConditionInPolicyRule aggregation (in the case of a embedding a condition directly in a PolicyRule) or the PolicyConditionInCompoundCondition aggregation (for embedding either gpsPolicySimpleConditions or gpsPolicyCompoundConditions in a gpsPolicyCompoundCondition). This case is called an "ad-hoc" simple condition. This method allows the creation of a "private" simple condition, meaning that this instance of the condition can't be used by any other policy rule or compound condition, hence it is not reusable. However, this case enables the condition and its container to be treated and managed atomically. 2. Building a reusable condition. In this case, the goal is to treat the condition as a reusable building block. Therefore, it will be placed in a PolicyRepository and referenced by its containing object (either a PolicyRule or a qpsCompoundPolicyCondition). In many data storage mechanism implementations, this will be realized by treating the PolicyRule or the gpsPolicyCompoundCondition instance as a container, treating the PolicyRepository as a separate container, and using an attribute in the PolicyRule or gpsPolicyCompoundCondition to reference the condition in the PolicyRepository. For example, in a Snir, Ramberg, Strassner, Cohen expires May 2001 40 Draft-ietf-policy-qos-info-model-02.txt November 2000 directory implementation, a DN pointer will be used to refer to the condition. In the information model, we describe this case using two relationship classes. One class, the PolicyConditionInPolicyRepository association, establishes the "resides-in" relationship between the reusable object and the reusable-object repository in which it resides. Another class, the PolicyConditionInPolicyRule aggregation class, establishes the "contained-in" relationship between the condition and the rule that contains it. The advantage of this approach is that by using an indirect reference to refer to an instance of a condition that resides in a reusable- object repository, this method allows the sharing of reusable conditions by multiple policy rules or compound conditions. Schema designers should keep in mind that in some cases, an implementation platform introduces an added cost to access reusable objects that are located in different areas of the data store than the referencing object is located in. For example, in LDAP based storage, fetching a sub-tree (i.e., a container object and its "leaves") is a single operation while accessing a referenced object is an additional operation. 4.2.4. Using Compound Conditions Compound conditions should be used when the definition of a set of terms that should be treated atomically (e.g., as a single condition) is required. One such example is the common case of filtering on a five- or six-tuple (e.g., the source and destination address and ports, protocol, and DSCP). This type of filter can be modeled as a container that holds one or more simple conditions. If filter reusability is not required, then an ad-hoc set of simple conditions that implement a rule-specific condition is sufficient (it carries the same semantics except for reusability). All instances of the gpsPolicyCompoundCondition MUST carry unique names. A name is a MUST property for reusable objects (this is required by [PCIM]). The gpPolicyConditionListType of the gpsPolicyCompoundCondition is set to DNF or CNF (disjunctive or conjunctive normal form, respectively), as required. Each of the conditions that are to be used in this compound condition are defined using the PolicyConditionInCompoundCondition aggregation. This aggregation enables the condition to be treated as a container so that it can aggregate other conditions, and is defined in QPIM. Each condition that is contained in the compound condition can be either directly contained the compound condition (in which case it is a rule-specific, ad-hoc condition) or be a reusable condition that resides in a PolicyRepository. Snir, Ramberg, Strassner, Cohen expires May 2001 41 Draft-ietf-policy-qos-info-model-02.txt November 2000 An implementation may realize these three relationships in any way desired to implement their semantics. Sometimes, this means that these relationships will be implemented as their own classes, and sometimes it means that they will be implemented in some other way that is particular to that type of data store. For example, the [PFSCHEMA] uses a combination of a class and a mechanism (DIT containment) to implement these three relationships. The class is used to specify an optional NOT operation to be applied to a condition (e.g., the condition is matched if the term is NOT true), and to define the interpretation of the term (i.e., which terms are grouped together, and whether they are ORED or ANDed together). The following example illustrates the construction of a reusable compound condition, named "My-Server", that expresses the following logic: SourceIPAddress=1.1.1.1 AND SourcePort=7777: A compound condition is created and is assigned a unique name, in this case, "My-Server". The gpsPolicyCompoundCondition property policyConditionListType is set to DNF. The compound condition is built by ANDing two gpsPolicySimpleCondition instances. The first simple condition is implemented using a gpsPolicySimpleCondition object. It includes a SourceIPAddress variable and an IP address value of "1.1.1.1". The second simple condition is also implemented using a gpsPolicySimpleCondition object. It includes a SourcePort variable and an integer value of 7777. Each of the simple conditions is linked to the compound condition container using the PolicyConditionInCompoundCondition aggregation. The qpsPolicyCompoundCondition is then made reusable by placing it in a reusable-object repository using the PolicyConditionInPolicyRepository association. To use this compound condition in a policy rule, the PolicyConditionInPolicyRule aggregation is used. 4.2.5 Reusable vs. Rule-Specific Conditions This information model facilitates reuse of simple conditions (using the qpsPolicySimpleCondition class) as well as more complex expressions (using the qosPolicyCompoundCondition class) by placing them in a common portion of the policy information tree (called the reusable- object repository). In order for a condition to be placed in this repository, it must carry a unique name. A reusable gpsPolicySimpleCondition contains a value and a variable. There are two different ways to build simple (or compound) conditions. One way is for the values and variables to be embedded within the condition directly. Conceptually, this can be thought of as specifying that when the condition is instantiated, its variables and values will also be instantiated as part of the same object that is used to build Snir, Ramberg, Strassner, Cohen expires May 2001 42 Draft-ietf-policy-qos-info-model-02.txt November 2000 the condition itself. In this case, embedding the values and variables within the policy condition is specified by the PolicyValueInPolicyCondition and PolicyVariableInPolicyCondition aggregations, respectively. This is called a rule-specific condition, because its components can not be shared with other rules. Alternatively, a policy variable and/or a policy value can be instantiated in a reusable-object repository and then referenced by the (simple or compound) condition. The values (or variables) are linked to the PolicyRepository using the PolicyElementInPolicyRepository association; the condition is linked to the PolicyRepository using the PolicyConditionInPolicyRepository association. Note that the reusable- object repository may be part of the same data store as that which contains the aggregating condition, or it may be a physically different data store.. 4.3 Simple Condition Operator The QoS policy simple condition includes the gpOperator property, which specifies the type of relation between the variable and the value evaluated in the condition. In many cases, a generic 'match' operator can be used, and the interpretation of the relation between the variable and value is implied by the value itself. For example, the variable SourceIPAddress can be matched to an IP address, where the 'equal' relation is implied, to a hostname in which the 'resolve to' relation is implied, or to a subnet address in which 'belongs to' relation is implied. Similarly, this same variable (which is a string) has semantics that determine the acceptable values that the string can take. For example, an improperly formed address in either CIDR or dotted decimal notation can be detected and rejected. The QPIM defines a single operator, "match", that models the most generic relation: that of being equal or belonging to. 4.4 QoS Policy Variables QoS policy variables are used for building individual conditions, as defined in section 4.2. The variable specifies the attribute of a flow that should be bound and evaluated according to a set of pre-defined semantics in a condition. Its purpose is to act as a binding point, associating a condition with an object whose data is evaluated according to the specified operator/value. The QPIM has defined semantics for some of the most common of these variables based upon these sources to guide the binding of common data. However, such binding could also be determined from a variety of other standard and proprietary sources such as public or private MIBs or application- specific data. Snir, Ramberg, Strassner, Cohen expires May 2001 43 Draft-ietf-policy-qos-info-model-02.txt November 2000 Not every combination of a variable and a value creates a meaningful condition. For example, a source IP address variable can not be matched against a value that specifies a port number. The QPIM defines a set of variables that can be used to model common QoS policy conditions, and assigns appropriate semantics for each. Each type of variable inherently selects the set of value types that it can be matched against (i.e. a value that could be compared and evaluated to a Boolean expression). Variables have data types. Many of the variables defined in this draft have associated semantics that limit the set of values within a particular value type that can be matched against it in a condition. This may be viewed as a second level of integrity checking. For example, a variable representing the source-port must limit the set of values that it can assume to the valid range of integers that correspond to legal source-port values; values such as -3 or 2000000 are not legal values and can not be matched to this variable. Thus, it is not enough to say that the data type of the source-port variable is an integer; we also need to ensure that the value to be tested is within a valid range of integers. This is achieved by associating the source port variable with an integer value object that contains the appropriate value range for that variable. In this first implementation, simple semantics such as those described above are realized by defining a separate class whose properties contain the constraints. This constraint class is then linked to the PolicyValue class through the PolicyValueConstraintsInVariable. In the future, a more robust mechanism, such as an object constraint language, may be integrated with the information model to provide even more metadata to describe legal behavior, values and operations on the variable. Currently, such a language is not integrated with either this information model or PCIM. The mechanism defined in this draft enables implementation experience to be gained to help guide the integration of a constraint language in the future. The QPIM defines one attribute, one association, and one general purpose mechanism that together characterize each of the variables that it defines: 1. The property gpVariableName of the qpsPolicyVariable class defines the well-known name used for logically binding all variables that are defined in this document to a set of allowed value data types. 2. The PolicyValueConstraintsInVariable association defines the set of value classes that could be matched to this variable. 3. The list of constraints on the values that the PolicyVariable can hold (i.e., values that the variable must match) are defined by the appropriate properties of an associated PolicyValue class. Snir, Ramberg, Strassner, Cohen expires May 2001 44 Draft-ietf-policy-qos-info-model-02.txt November 2000 For example, if a PolicyVariable represents the SourcePort of incoming traffic, then a PolicyValueConstraintsInVariable association can be used to link the PolicyVariable instance to an qosPolicyIntegerValue instance. This association by itself constrains the data type of the SourcePort PolicyVariable to be an integer. However, we can further constrain the particular values that the SourcePort PolicyVariable can hold by entering valid ranges in the qpIntegerList property of the qosPolicyIntegerValue instance. Note that implementations are free to realize the semantics defined by these two associations in a number of different ways. The information model defines these semantics based around an association, because that is the most general form describing how this information is related. An implementation could conceivably realize this using zero or more actual relationships. The combination of the qpVariableName and the PolicyValueConstraintsInVariable assocation provide a consistent and extensible set of metadata that define the semantics of variables that are used to form QoS conditions. Since the PolicyValueConstraintsInVariable association points to another class, any of the properties in the PolicyValue class can be used to constrain values that the PolicyVariable can hold. For example: - The gpVariableName can be used to identify common processing rules for a variable having a specific name. - The PolicyValueConstraintsInVariable association can be used to ensure that only proper classes are used in the expression. For example, the SourcePort variable will not be allowed to associate to the qpsPolicyIPv4AddrValue class, since source ports have different semantics than IP addresses and may not be matched. However, it will associate to a gpsPolicyIntegerValue class. - The PolicyValueConstraintsInVariable association also ensures that variable-specific semantics are enforced (e.g., the SourcePort variable may include a constraint association to a value object defining a specific integer range that should be matched). 4.4.1. Variable Binding For the QoS Policy schema to be interoperable, different policy management systems and policy servers must instantiate the same variables with identical values (in the same evaluation operation). While different policy servers may use a different binding mechanism, the binding logic must result in an identical instantiation. Each variable defined in the QoS policy data store must be bound to a logical entity such as a specific field in the IP header, a specific class or property in the QPIM or in a related Information or Data Model, an application unique identifier or an application-specific parameter. Snir, Ramberg, Strassner, Cohen expires May 2001 45 Draft-ietf-policy-qos-info-model-02.txt November 2000 When a policy server attempts to evaluate an expression containing variables, it must instantiate the variables. To instantiate a variable, that variable must be bound to a specific value (or values, depending on its type category) and associated with a logical entity. For example, in the expression 'SourcePort == 80', the variable 'SourcePort' must be instantiated to a value and logically associated with the packet header field containing the source port number, for the expression to be evaluated. If, in this example, the variable SourcePort is bound to a value of '80', then the expression is evaluated to TRUE for each packet that the source port number in the IP header field equal to 80. Otherwise it is evaluated to FALSE. 4.4.2. Pre-Defined Variables The purpose of this section is to explain the need and define the relationship of standard, frequently used variables with their logical entities. Pre-defined variables are necessary for ensuring interoperability among policy servers and policy management tools from different vendors. For example, different policy servers may have to evaluate the same policy rule. If each policy server uses a common set of variables, this helps to abstract the condition term such that its evaluation can be performed in the same way by all of those policy servers. If no such set of common variables exist, then each policy server is free to define its own set of variables. Variations in each variable that each policy server defines will impede interoperability, and prevent the same semantics and interpretation to be achieved when each policy server implements the same policy rule. The QoS Policy information model specifies a set of pre-defined variables to support a set of fundamental QoS terms that are commonly used to form conditions. Examples of these include IP header field values, user information, applications, and others. A pre-defined variable MUST always have the same name and binding semantics. For example, a given pre-defined variable should be bound to the same logical entity by all client systems (typically policy devices). Similarly, the pre-defined variable should be stored in the reusable- object repository to enable reuse and sharing of the pre-defined variable. Snir, Ramberg, Strassner, Cohen expires May 2001 46 Draft-ietf-policy-qos-info-model-02.txt November 2000 All standard variable names are case insensitive and do not include spaces or other non-standard characters to promote ease of use. The implementers of client systems that map the QPIM to a specific repository-based implementation MUST provide binding methods to bind pre-defined variables according to the semantics specified in this section. Following is a table that defines the predefined variable names and their binding. The table indicates which fields are checked in actual filters used in provisioning policies as well as in RSVP signaling messages. +-----------------+---------------------------------------------------+ |Variable name | Logical binding | +-----------------+---------------------------------------------------+ | SourceIP | The source IP address of the flow. Compared to the| | | source IP header field, or the sender address in | | | the RSVP Filter spec object [RSVP]. | +-----------------+---------------------------------------------------+ | SourcePort | The source Port of a UDP/TCP flow. Compared to the| | | source port field in the TCP/UDP header, or the | | | sender port in the RSVP Filter spec object [RSVP].| +-----------------+---------------------------------------------------+ | DestinationIP | The destination IP address of the flow. Compared | | | to the destination IP header field, or the session| | | address in the RSVP SESSION object [RSVP]. | +-----------------+---------------------------------------------------+ | DestinationPort | The destination Port of a UDP/TCP flow. Compared | | | to the destination port field in the TCP/UDP | | | header, or the session port in the RSVP SESSION | | | object [RSVP]. | +-----------------+---------------------------------------------------+ | IPProtocol | The IP protocol number. Compared to the protocol | | | number in the IP header field or to the IP | | | protocol in the RSVP SESSION object [RSVP]. | +-----------------+---------------------------------------------------+ | ToS | The ToS variable is bound to the IP header ToS | | | byte. | +-----------------+---------------------------------------------------+ | DSCP | The DSCP variable is bound to the IP header DSCP | | | byte or to the DCLASS RSVP object. | +-----------------+---------------------------------------------------+ | DestinationMAC | The destination MAC address variable is bound the | | | frame destination MAC address. | +-----------------+---------------------------------------------------+ | SourceMAC | The source MAC address variable is bound the frame| | | source MAC address. | +-----------------+---------------------------------------------------+ (Table continued in next page) Snir, Ramberg, Strassner, Cohen expires May 2001 47 Draft-ietf-policy-qos-info-model-02.txt November 2000 (Table continued from the previous page) +-----------------+---------------------------------------------------+ | 8021QID | The VLAN ID is bound to the 802.1Q field of | | | the header. | +-----------------+---------------------------------------------------+ | Snap | The snap protocol variable is bound to the | | | protocol type carried over SNAP encapsulation. | +-----------------+---------------------------------------------------+ | Ethertype | The ethertype variable is bound to the frame | | | header ethertype value. | +-----------------+---------------------------------------------------+ | Ssap | The source sap variable is bound the frame header | | | field containing the source SAP. | +-----------------+---------------------------------------------------+ |Variable name | Logical binding | +-----------------+---------------------------------------------------+ | Dsap | The destination sap variable is bound the frame | | | header field containing the destination SAP. | +-----------------+---------------------------------------------------+ | Application | The ID of the application that generated the flow.| +-----------------+---------------------------------------------------+ | User | The ID of the user that initiated the flow, or is | | | designated as the flow owner. | +-----------------+---------------------------------------------------+ Table 1. Pre-defined Variables and Their Bindings The definition of each predefined variable includes a standard name and the allowed value types. The VariableHasDataValues association is used to associate a variable object with a value object. Following is a table of variable names and the value types defined within this document that can be used together in a simple condition. In reality, these are individual specializations of the general association, PolicyValueConstraintsInVariable, that exists between the PolicyVariable and PolicyValue classes and their subclasses. A given variable can further restrict the values that can be combined with it in a given condition. This is done by restricting the values that can be held by the appropriate attributes of the PolicyValue class that is used to represent the constraining object in the PolicyValueConstraintsInVariable association. For example, by default, a condition including a variable with the name "SourceIP" should also include either a gpsPolicyIPv4AddrValue or a gpsPolicyIPv6AddrValue value object. But, if there is a need to restrict values within a condition to only IPv6 addresses of a certain range, then the PolicyValueConstraintsInVariable association can be used to indicate that only gpsPolicyIPv6Values of that range should be used. This is done by placing this information into the qpIPv6AddrList attribute of the gpsPolicyIPv6AddrValue class. The table below does not restrict new Snir, Ramberg, Strassner, Cohen expires May 2001 48 Draft-ietf-policy-qos-info-model-02.txt November 2000 value classes defined elsewhere to be combined with variables defined in this document. +-----------------+---------------------------------------------------+ |Variable name | Allowed value types | +-----------------+---------------------------------------------------+ | SourceIP | gpsPolicyIPv4AddrValue, gpsPolicyIPv6AddrValue | +-----------------+---------------------------------------------------+ | SourcePort | gpsPolicyIntegerValue | +-----------------+---------------------------------------------------+ | DestinationIP | gpsPolicyIPv4AddrValue, gpsPolicyIPv6AddrValue | +-----------------+---------------------------------------------------+ | DestinationPort | gpsPolicyIntegerValue | +-----------------+---------------------------------------------------+ | IPProtocol | gpsPolicyIntegerValue | +-----------------+---------------------------------------------------+ | ToS | gpsPolicyIntegerValue, gpsPolicyBitStringValue | +-----------------+---------------------------------------------------+ | DSCP | gpsPolicyIntegerValue, gpsPolicyBitStringValue | +-----------------+---------------------------------------------------+ | DestinationMAC | gpsPolicyMACAddrValue | +-----------------+---------------------------------------------------+ | SourceMAC | gpsPolicyMACAddrValue | +-----------------+---------------------------------------------------+ | 8021QID | gpsPolicyIntegerValue, gpsPolicyBitStringValue | +-----------------+---------------------------------------------------+ | Snap | gpsPolicyIntegerValue | +-----------------+---------------------------------------------------+ | Ethertype | gpsPolicyIntegerValue | +-----------------+---------------------------------------------------+ | Ssap | gpsPolicyIntegerValue | +-----------------+---------------------------------------------------+ | Dsap | gpsPolicyIntegerValue | +-----------------+---------------------------------------------------+ | Application | gpsPolicyDNValue, gpsPolicyStringValue, | | | gpsPolicyAttributeValue | +-----------------+---------------------------------------------------+ | User | gpsPolicyDNValue, gpsPolicyStringValue, | | | gpsPolicyAttributeValue | +-----------------+---------------------------------------------------+ Table 2. Variable Names and Their Default Class Mappings Note: Values are defined in section 4.5. 4.5 QoS Policy Value The abstract class gpsPolicyValue is used for defining values and constants used in policy conditions. Different value types are derived Snir, Ramberg, Strassner, Cohen expires May 2001 49 Draft-ietf-policy-qos-info-model-02.txt November 2000 from this class and represent the various attributes required. Extensions of the qpsPolicyValue class, defined in this document provide a list of values for representing the basic network attribute. Values can be used to represent constants as named values. Named values could be kept in a reusable-object repository to be reused by multiple conditions. Examples of constants include well-known ports, well-known protocols, server addresses, and other similar concepts. The qpsPolicyValue classes define 3 basic types of values: scalars, ranges and sets. For example, a well-known port number could be defined using the gpsPolicyIntegerValue class, defining a single value (80 for HTTP), a range (80-88), or a set (80, 82, 8080) of ports, respectively. For details, please see the class definition for each value type in section 8 of this document. The QoS policy information model provide the following classes, all of them extending the qpsPolicyValue class: Classes for general use: GpsPolicyStringValue, gpsPolicyIntegerValue, gpsPolicyBitStringValue, gpsPolicyDNValue, gpsPolicyAttributeValue. Classes for layer 3 Network values: gpsPolicyIPv4AddrValue, gpsPolicyIPv6AddrValue. Classes for layer 2 Network values: gpsPolicyMACAddrValue. For details, please see the class definition section of each value in section 8 of this document. 4.6. PolicyTimePeriodCondition The QoS Policy Information model uses the policyTimePeriodCondition class (defined in [PCIM]) to define time based QoS policy rules. For details, please see [PCIM], section 6.5.4.7. Actions 4.7 Actions The QoS Policy information model defines actions to control QoS enforcement in both the Integrated Service model as well as the Differentiated Service model. Three types of actions are provided: Signaling, Provisioning and Per-Hop-Behvior (PHB) actions. Snir, Ramberg, Strassner, Cohen expires May 2001 50 Draft-ietf-policy-qos-info-model-02.txt November 2000 Signaling actions are used to provide policy control on RSVP requests. Provisioning actions are used to enforce differentiated service edge policies including marking, policing and shaping operations. PHB actions are used to enforce per-hop behaviors across the differentiated services domain. A policy rule may aggregate zero or more policy actions. A QoS policy rule extends this definition to include 0..n provisioning actions, o..k PHB actions and 0..m signaling actions, each defined by an object or objects describing the action(s) to perform. This extension is done seamlessly by requiring all QoS action classes to be subclasses of the PolicyAction class defined in [PCIM]. As such, all QoS action subclasses automatically inherit the two relationships (PolicyActionInPolicyRule and PolicyActionInPolicyRepository) that are used by a policy rule to aggregate actions. Actions are ordered (as opposed to rules, which are prioritized). The order of actions is specified in [PCIM] using the ActionOrder property. The property SequencedActions in the aggregating instance of a PolicyRule (see section 6.3.6 of [PCIM]) defines whether a specified action order is required, recommended, or of no significance. Ordering semantics depend on how actions are represented. If actions are represented as separate objects that are aggregated by PolicyRule, the PolicyActionInPolicyRule aggregation can be used to express an order. In this case, three attributes are used: - GroupComponent, which defines zero or more PolicyRules that can contain the same PolicyAction - PartComponent, which defines zero or more PolicyActions that are contained by a given policyRule - ActionOrder, which is an unsigned integer 'n' that indicates the relative position of an action in the sequence of actions that are associated with a given policy rule. When 'n' is a positive integer, it indicates a place in the sequence of actions to be performed, with smaller integers indicating earlier positions in the sequence. The special value '0' indicates "don't care". If two or more actions have the same non-zero sequence number, they may be performed in any order, but they must all be performed at the appropriate place in the overall action sequence. For actions defined explicitly in a subclass of policyRule, the ordering mechanism must be specified in the subclass definition. Note that QPIM does not define any policyRule subclasses. Instead, the QPIM defines subclasses of policyCondition and policyAction to extend the semantics of these classes. Provisioning, PHB and signaling actions can be intermixed in a QoS policy rule. Policy consumers (such as PDPs) MAY separate the actions into separate lists, but MUST respect the internal order of the specified actions. Snir, Ramberg, Strassner, Cohen expires May 2001 51 Draft-ietf-policy-qos-info-model-02.txt November 2000 4.7.1 Provisioning Actions QoS policy provisioning actions configure traffic conditioner elements, as specified in [DIFF-SERV-ARCH]. Actions configure meters, markers, shapers and droppers. The qosPolicyPRAction class is a generic class that defines a set of DiffServ actions that can be applied to an individual flow or to a group of flows. 4.7.1.1 Meters Meters measure the temporal properties of a stream of packets selected by a classifier against a traffic profile. A meter is associated with a provisioning action using the PolicyMeterInAction association. A meter can be shared among (i.e., used by) policy actions of different rules. If this is desired, then the meter SHOULD reside in a reusable-object repository. Meters measure flows matching the rule condition per flow, per interface, per role within a device, per device or per role across all devices. A per flow meter conceptually creates a new meter for each flow, measuring each flow against the profile. A per interface meter measures the aggregate set of flows matching the rule condition forwarded via a single interface. Other options measure traffic across a set of interfaces assigned with the same role or across a whole device. The gpMeterScope property of the gpsPolicyMeter class is used to determine which of the options above is selected.Meters are measured against traffic profile modeled by the qosPolicyPRTrfcProf object. The association PolicyTrfcProfileInMeter is used to associate between a meter and its traffic profile. The traffic profile used for provisioning actions is a template containing rate and burst values, modeled by the qosPolicyPRTrfcProf class. 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] definition of a meter combines the traffic profile and a meter as one unit. Separation of the concepts provides more flexibility in reuse of traffic profiles across different rules. The [DIFF-MIB] defines a two level meter, and provides 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. Snir, Ramberg, Strassner, Cohen expires May 2001 52 Draft-ietf-policy-qos-info-model-02.txt November 2000 A metered provisioning action using three level traffic profile specifies the actions that should be enforced on excess and violating traffic using the qpExcessAction and qpViolateAction properties. A three level metered action that does not specify an excess action implies that the excess traffic should be treated as either violating or conforming traffic according to an algorithm suitable for the enforcement of the rule. For example, the final enforcement of such a rule may be the use of a RED like behavior to determine whether traffic is conforming or violating. A metered action with 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. A metered provisioning action allows additional flexibility by linking actions that should be enforced only on traffic that either conforms, exceeds or violates a meter. The associations PolicyConformNextAction, PolicyExcessNextAction and PolicyViolateNextAction define actions that are not associated with the set of actions aggregated via the PolicyActionInPolicyRule aggregation relationship (defined in [PCIM]), and are enforced only according to the state of the meter. Once an a action is enforced, all actions associated to it using one of the next action association should be enforced prior to other actions associated to the rule using the policyActionInPolicyRule aggregation. For example, a rule may contain two actions A and B via the aggregation policyActionInPolicyRule. The aggregation property ActionOrder specifies that action A should be performed prior to action B. Action A is a metered provisioning action that specifies that exceeding traffic should be marked with DSCP 5 and associates a third action, action C to be enforced only on exceeding traffic. The order of enforcement of the three actions A, B and C is as follows: First, action A is performed. If traffic exceeds the traffic profile, C is performed. Action B is always performed following A or C. 4.7.1.2 Markers Markers are used to set the DS field of a packet 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. The marker may also be configured to allow or not allow remarking of packets. When the marker changes the DSCP in a packet, it is said to have "re-marked" the packet. Provisioning actions can include both DSCP (re)marking as well as 802.1Q, Precedence and CoS marking. Precedence marking is required for legacy devices, i.e., devices that do not support the full DSCP field (6 bits) in the ToS byte of the IP packet header for IPv4. CoS marking is required when crossing a link layer that supports QoS via CoS. Snir, Ramberg, Strassner, Cohen expires May 2001 53 Draft-ietf-policy-qos-info-model-02.txt November 2000 The qosPolicyPRAction class contains a number of properties that can be used to control the behavior of a marker. For example, the values of the property qpExcessAction or qpViolateAction should be set to 'remark' in order to model a marker that marks packets according to a state of a meter. The properties qpExcessRemarkValue and qpViolateMarkValue carries the marking values. The value type is determined by the property qpMarkValueType. Both excess and violate actions may be specified when measuring a meter against a three level traffic profile. Please see section 8.3 for more detail. 4.7.1.3 Shapers 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. Again, the qosPolicyPRAction class contains a number of properties that can be used to control the behavior of a shaper. For example, the value of the property qpExcessAction or qpViolateAction should be set to 'shape' in order to model a shaper. Traffic should be shaped according to a traffic profile defined by a qosPolicyPRTrfcProf class. 4.7.1.4. Droppers Droppers are used to discard some or all of the packets in a traffic Stream. Usually, this is done in order to bring the stream into compliance with a traffic profile. This process is also known as "policing" the stream. Again, the qosPolicyPRAction class contains a number of properties that can be used to control the behavior of a shaper. For example, the value of the property qpExcessAction or qpViolateAction should be set to 'drop' to model a policer that drops packets according to the traffic-profile specified by a qosPolicyPRTrfcProf class. Snir, Ramberg, Strassner, Cohen expires May 2001 54 Draft-ietf-policy-qos-info-model-02.txt November 2000 4.7.1.5 Examples Below are two examples on how this document models rules specifying provisioning actions to be enforced on the edge of a differential service domain. Example 1: Traffic flowing from one machine to another should be marked with DSCP X to provide it with the correct per hop behavior. This traffic should not exceed 1Mb/sec. Each flow should not exceed more than 300Kb/sec. A single policy rule can be constructed to enforce this set of actions. The condition can be built from two simple conditions matching the source IP address of one machine and the destination of the other machine. A set of three provisioning actions can be used in the following form: Action 1: Object: qosPolicyPRAction qpMarkValueType: DSCP qpMarkValue: X Action 2: Object: qosPolicyPRAction PolicyMeterInAction association to: Meter-1 qpExcessAction: Drop Action 3: Object: qosPolicyPRAction PolicyMeterInAction association to: Meter-2 qpExcessAction: Drop The meters and traffic profile can take the form of: Meter 1: Object: GpsPolicyMeter gpMeterScope: interface PolicyTrfcProfileInMeter association to: Profile-1 Meter 2: Object: GpsPolicyMeter gpMeterScope: flow PolicyTrfcProfileInMeter association to: Profile-2 Profile 1: Object: QosPolicyPRTrfcProf QpPRRate: 1Mb/sec QpPRNormalBurst: 1000 bytes Snir, Ramberg, Strassner, Cohen expires May 2001 55 Draft-ietf-policy-qos-info-model-02.txt November 2000 Profile 2: Object: QosPolicyPRTrfcProf QpPRRate: 300Kb/sec QpPRNormalBurst: 1000 bytes Example 2: Conditioning traffic Some PHBs require the successive application of a set of traffic conditioners to properly process the traffic. An example of a policy with two levels of traffic conditioning is the following: Mark packets to DSCP=24 if the rate is within profile x=<64Kb/s>, else mark packets with DSCP=25 if rate is within profile y=<128kb/s>, else drop out-of-profile packets. This policy rule can be modeled by using two actions. The first action measures the traffic against the first profile. If the traffic is within this profile, then the traffic is (re)marked with a DSCP of 24. If the traffic is out of profile, then the subsequent action measures the traffic against the second higher profile. If the traffic is within this profile, then the traffic is (re)marked with a DSCP of 25. Otherwise, the traffic is out of profile, and it will be dropped. In this way, an arbitrary cascading of traffic conditioners can be constructed, where each action measures traffic against a higher traffic profile and change only the out-of-profile action as required. This policy rule can be build in another way using associations to actions that should be performed on exceeding or violating traffic. In this way, the first action measures traffic according to the first traffic profile, and reference the second action using policyExcessNextAction association. The second action than base its decision whether to discard or remark traffic according to the higher traffic profile. Snir, Ramberg, Strassner, Cohen expires May 2001 56 Draft-ietf-policy-qos-info-model-02.txt November 2000 4.7.2 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 [DIFF-SERV-ARCH]. 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 needs to be allocated to each of the behavior aggregates in order to achieve these observables. 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 that EF packets needs to be treated with preemptive forwarding (priority queuing), and specify the maximal bandwidth for this class as well as the maximal 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 configures queues, schedulers, droppers and other mechanism. In particular, the PHB actions includes attributes that are directly mapped to the differential service MIB configuration scheme [DUFF-MIB]. Description of the properties of the PHB Action that are directly mapped to the diffserv MIB [DIFF-MIB] are aligned with the definition in the MIB. We refer to the MIB for a thorough discussion of these properties and for an explanation of why this minimal set of parameters where chosen to describe each mechanism. 4.7.2.1 Bandwidth and Delay Management PHB actions 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 qpBandwidthValueType is used to determine whether percentage of fixed values are used. The property qpForwardingPriority is used whenever preemptive forwarding is required. A policy rule that defines EF PHB should indicate a non zero forwarding priority. QpForwardingPriority holds an integer value to enable multiple levels of preemptive forwarding where higher values specifies higher priority. The property qpMaxBandwidth specifies the maximal 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 specifies limits on the per hop delay and jitter in milliseconds for any given packet within a traffic class. Enforcement of the maximal delay and jitter may require use of preemptive forwarding as well as minimal and maximal bandwidth controls. Enforcement of low max delay and jitter values may also require fragmentation and interleave mechanisms over low speed links. Snir, Ramberg, Strassner, Cohen expires May 2001 57 Draft-ietf-policy-qos-info-model-02.txt November 2000 4.7.2.2 Congestion Control and Buffer Management PHB actions provide buffer resources and congestion control management. The property qpDropAlgorithm can be used to select either tail- drop, head-drop or random-drop algorithms. The set of maximal and minimal threshold values can be specified as well, either in bytes, in packets or in percentage of the total available buffers. Two additional properties are provided for controlling random drop, as explained in [DIFF-MIB]. The properties are qpRandomDropInvWeight and qpRandomDropProbMax that control the RED weight factor and worst probability, see [DIFF-MIB] for more details. 4.7.2.3 Queues and PHB groups PHB actions provide control on the way packets that match a rule should be queued for forwarding. The qosPolicyQueue class specify the queuing properties of the PHB action. Two PHB actions, used within two different rules may reference the same qosPolicyQueue object, indicating that flows matched by these rules should use the same queue. For example, rules specifying PHB actions for AF11 and AF12 [AF] PHBs should indicate that AF11 and AF12 belong to the same PHB group and should be queued together to avoid packet reordering affects. This can be achieved by reusing a PHB action within the AF1x rules that specify the bandwidth and delay properties as well as indicating that the same queue must be used. The association PolicyQueueInPHBAction associates between a PHB action and a qosPolicyQueue. The qosPolicyQueue class carries all properties described in the bandwidth and delay management section. The Boolean property qpFairQueue indicates whether flows should have a fair chance to be forwarded without drop or delay. A way to enforce a PHB action with qpFairQueue 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 ftp flow and therefore have a reasonable response time. Schedulers and Queue sets are not modeled directly in the QoS Policy Information model. Nevertheless, hierarchical policy rules may require enforcement using more than a single scheduler or queue set. This is explained in the next section. Snir, Ramberg, Strassner, Cohen expires May 2001 58 Draft-ietf-policy-qos-info-model-02.txt November 2000 4.7.2.4 Using Hierarchical policies The ability to define sub rules within rules allow for definition of hierarchical policies. Hierarchical policies form a hierarchy of classification and specification of actions for each level of the hierarchy. For example, a rule may specify the actions that should be performed on all UDP traffic, while its sub rules specify the actions that should be performed on various UDP applications. Rules specified higher in the hierarchy also apply to all sub rules and are logically performed first [see Section 5.3]. Bandwidth and Buffer resources specified in relative terms (percentage of total resources) relate to the resources allocated higher in the hierarchy. For example, bandwidth resources can be shared between UDP applications summing up to 100% of the resources allocated to UDP traffic. Hierarchical policies defining PHB actions may therefore require hierarchical scheduler for correct enforcement. 4.7.2.5 Examples This example provides a set of rules that specify PHBs enforced within a Differential Service Domain. In this example the PHBs selected to be enforced within the domain are EF, AF11 and AF12 and Best Effort. There may be alternate ways to construct policy rules to represent these PHBs. The set of rules takes the form: If (EF) than do EF actions If (AF11) than do AF11 actions If (AF12) than do AF12 actions If (default) than do Default actions. EF, AF11, AF12 represent conditions that filter traffic according to DSCP values. These filters are represented using either a reusable or ad-hoc policy conditions. The default rule uses a 'catch all' filter and specifies the Best Effort rules. The set of rules reside in a gpsPolicyGroup. The decision strategy is defined to be 'FIRST MATCH'. The objects below specifies the set of actions used to describe each of the PHBs: QosPolicyPHBAction BE: PolicyQueueInPHBAction association to: Beq QpDropAlgorithm: random qpDropThresholdValueType packet qpDropMinThreshold: 6pckts qpDropMaxThreshold: 40pckts Snir, Ramberg, Strassner, Cohen expires May 2001 59 Draft-ietf-policy-qos-info-model-02.txt November 2000 QosPolicyPHBAction AF11: PolicyQueueInPHBAction association to: AF1xq QpDropAlgorithm: random qpDropThresholdValueType packet qpDropMinThreshold: 4pckts qpDropMaxThreshold: 20pckts QosPolicyPHBAction AF12: PolicyQueueInPHBAction association to: AF1xq QpDropAlgorithm: random qpDropThresholdValueType packet qpDropMinThreshold: 2pckts qpDropMaxThreshold: 10pckts QosPolicyPHBAction EF: PolicyQueueInPHBAction association to: EFq QpDropAlgorithm: drop qpDropThresholdValueType packet qpDropMaxThreshold: 3pckts AF11 and AF12 share the same queue, indicating that they belong to the same PHB group. Following are the qosPolicyQueue objects defined in this example: qosPolicyQueue BEq: qpBandwidthValueType qpFairQueue: TRUE qosPolicyQueue AF1xq: qpBandwidthValueType: kb/sec qpMinBandwidth: 512Kb/sec qosPolicyQueue EFq: qpForwardingPriority: 1 qpBandwidthValueType: % qpMaxBandwidth 50% qpFairQueue: FALSE AF1x actions are associated with the same qosPolicyQueue indicating that all AF rules performing this action belong to the same PHB group. The AF1x queue specify the minimal bandwidth that should be allocated to this PHB group. AF11 and AF12 actions indicate the maximal and minimal thresholds for AF1x packets. Snir, Ramberg, Strassner, Cohen expires May 2001 60 Draft-ietf-policy-qos-info-model-02.txt November 2000 qpForwardingPriority property of the EF action specify that preemptive forwarding is required for this PHB. qpMaxBandwidth property specify that EF should not use more than 50% of the link bandwidth. Random Drop is enforced by AF and BE PHBs. EF PHB uses tail drop as the applications using EF are supposed to be UDP based and rate controlled and will not benefit from a random dropper. The set of minimal and maximal thresholds in this example are defined in packets. The remaining random drop parameters are not specified and left for the enforcer defaults. QpFairQueue property indicates that Best Effort traffic should provide fairness among flows. 4.7.3 Signaling Actions RSVP is the standard protocol used for requesting QoS resources >From the network. The QoS policy signaling actions defined in this document can be used to control whether to admit or reject an RSVP request based on the request's attributes and the specified policy. The QoS policy signaling actions allow modifying the content and forwarding behavior of RSVP requests. The signaling policies control the admission priority of resources and provide preemption support. Mapping of integrated services signaled by RSVP to differential services in a core network is controlled by signaling policies as well, by assigning appropriate DSCPs to flows on the boundary of the differential service core. The set of policies specified allow a policy server (policy Decision point) to instruct an RSVP node (policy enforcement point) to Enforce all set of controls defined in the COPS protocol specification. The actions defined here follow the different decision types of the COPS protocol [COPS] and the guidelines for its use in an RSVP Environment [COPS-RSVP]. The basic decision to accept or deny a reservation is modeled by the qosPolicyRSVPAction class. Additional control is provided through the use of two classes. The content and forwarding behavior of RSVP flows is controlled by the osPolicyRSVPSignalCtrlAction class. The qosPolicyRSVPInstallAction class controls the processing of RSVP requests and accompanying flows within the RSVP node itself. QoS signaling policies does not require a policy server for decision making. A local policy module can use signaling policies for making local decisions or use either COPS or any other outsourcing protocol for enforcement of these signaling policies. Snir, Ramberg, Strassner, Cohen expires May 2001 61 Draft-ietf-policy-qos-info-model-02.txt November 2000 The qosPolicyRSVPAction action includes a specification of the Subset of RSVP flows on which the action should be taken. The following parameters can be specified: 1. Direction - in/out 2. Message type - Path/Resv/PathErr/ResvErr 3. Service type - Guaranteed Service / Controlled Load / Null 4. Service style - SE, WF, FF The direction refers to the direction of the flow, hence the Direction of the RSVP Path messages. Therefore, out-direction policies Control outgoing Path messages as well as incoming Resv messages. 4.7.3.1 Admission Control The basic decision modeled by the qosPolicyRSVPAction class is whether to admit or reject the RSVP request. The decision can be based on comparison of the request TSPEC or FLOWSPEC against a meter. This allows basing an admission decision both on the properties of the reservation request itself as well as on the current temporal resource allocation. Meters allow enforcement of policies of the form: "Allow allocation of resource via RSVP for flows coming from subnet x up to a total aggregated rate of 256kb/sec". The meter tracks the current state of resource allocated to subnet x, and compares any new request for resources against a 256Kb/sec traffic profile. A meter can be reused by two signaling actions of two rules, indicating that the this meter should measure the aggregated resource allocation for both rules. Note that if a traffic profile is not provided, it is implicitly assumed that the RSVP request should be accepted. Rejecting all RSVP requests matching the condition is specified by a zero valued traffic profile. 4.7.3.2 Forwarding Behavior The qosPolicyRSVPInstallAction class provides control on the way resource allocation requests are handles within the RSVP node, without changing the content of the RSVP messages themselves. In particular it allows instructing the RSVP node to: 1. Set the DSCP value of the flows for which the reservation was made. 2. Set the preemption priority of the RSVP request. Setting the DSCP of the flow on the edge of a differential service core allow provisioning of QoS, end-to-end, over mixed integrated and differential service clouds. Snir, Ramberg, Strassner, Cohen expires May 2001 62 Draft-ietf-policy-qos-info-model-02.txt November 2000 An RSVP node is responsible for deciding whether to admit flows or not, based on its available resources. Setting the preemption priority [RSVP_PREEMP] allows the RSVP node to decide which of its reservations should be admitted, and when to make room for a newer reservation by preempting an already installed one. This class should be extended to cover other COPS install decisions if required. 4.7.3.3 Signaling Control The qosPolicyRSVPSignalCtrlAction class provides control on the content of RSVP signaling message and their processing rules. In particular it may include the following controls: 1. Replace/add DCLASS object in RSVP message. 2. Replace/add Preemption priority object in RSVP message. 3. Trigger an error/warning RSVP message. 4. Instruct the RSVP node to proxy RSVP message as if sent by the RSVP end nodes. Modifying the content of messages can be enforced using a COPS replacement decision. This class should be extended to cover other object replacements and, in particular, replacement of policy objects. Triggering errors and warnings is important in scenarios when there is a need to notify the end nodes that their reservation is about to expire and various other information. There are scenarios in which it makes sense not to carry RSVP requests end-to-end. An RSVP node on the boundary of a differential service core may map the RSVP request to specific PHB by setting the DSCP on the flow packets, without forwarding the Path message downstream. Still, this RSVP node may send back an RSVP Resv message as if the receiver has sent it, to complete the RSVP cycle. 4.7.3.4 Examples Below is an example on how this document models rules specifying a set of signaling actions: Admit RSVP reservation requests for VoIP traffic with FF style only if the request asks for less the 64Kb/sec. Do not allow more than 5 VoIP reservations to be admitted on any single interface. In this examples two actions are used to represent the required policy. qosPolicyRSVPAction 1: qpRSVPMessageType: Resv qpRSVPStyle: FF PolicyMeterInAction association to: Meter-1 Snir, Ramberg, Strassner, Cohen expires May 2001 63 Draft-ietf-policy-qos-info-model-02.txt November 2000 qosPolicyRSVPAction 2: qpRSVPMessageType: Resv qpRSVPStyle: FF PolicyMeterInAction association to: Meter-2 The two meters specify the different scopes of each of the meters and a traffic profile. The first traffic profile limits the maximal resources allocated to a single request while the second traffic profile limits the number of reservations admitted at any given time. gpsPolicyMeter Meter-1: qpRSVPMeterScope: flow PolicyTrfcProfileInMeter association to: Prof-1 gpsPolicyMeter Meter-1: qpRSVPMeterScope: interface PolicyTrfcProfileInMeter association to: Prof-2 qosPolicyRSVPTrfcProf Prof-1: qpRSVPTokenRate: 64kb/sec qosPolicyRSVPTrfcProf Prof-2: qpRSVPSessionNum: 5 The various attributes of RSVP traffic profiles are described in the next section. 4.8. Meters and Traffic Profiles Meters measure the a temporal state of a flow or a set of flows against a traffic profile. In this document meters are modeled by psPolicyMeter class, while traffic profiles are modeled by gpsPolicyTrfcProf class. The association PolicyTrfcProfileInMeter models the relation between a meter and a traffic profile. Two traffic profiles are derived from the abstract class gpsPolicyTrfcProf. Provisioning traffic profiles carry rate and burst parameters to be compared with flow meters. RSVP traffic profiles are compared with RSVPTSPEC and FLOWSPEC parameters, and with meters aggregating the temporal state of admitted RSVP reservations and states. Snir, Ramberg, Strassner, Cohen expires May 2001 64 Draft-ietf-policy-qos-info-model-02.txt November 2000 4.8.1. Provisioning traffic profiles Shaping, policing and remarking provisioning actions compare a provisioning traffic profile against a meter. The provisioning traffic profile is a template containing rate and burst values, modeled by the qosPolicyPRTrfcProf class. The qosPolicyPRTrfcProf 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 will always conform. The normal burst size determines how large traffic bursts can be before some traffic exceeds the traffic profile. The Excess Burst size determines how large traffic bursts can be before all traffic exceeds the rate limit. Traffic that falls between the normal burst size and the Excess Burst size exceeds the traffic profile with a probability that increases as the burst size increases. This provides a Random Discard mechanism for policers, markers and shapers. Excess burst size SHOULD be greater than or equal to the normal burst size. If the excess burst size is not specified, it is assumed that excess burst size is equal to the normal burst size. In this case, burst larger than the normal burst size will always be counted as out-of-profile packets. Snir, Ramberg, Strassner, Cohen expires May 2001 65 Draft-ietf-policy-qos-info-model-02.txt November 2000 4.8.2. RSVP traffic profiles RSVP signaling QoS 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 TSPEC and FLOWSPEC objects are either compared directly with a traffic profile, or aggregated to a meter that measures the temporal admitted RSVP states and than compared to the traffic specification. The qosPolicyRSVPTrfcProf class models such a traffic profile. The qosPolicyRSVPTrfcProf 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. 8. Number of sessions. 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]. The last parameter is used to specify the maximum number of allowed RSVP sessions. This provides an easy way to limit the number of admitted RSVP requests without requiring pre-knowledge of the aggregated rates requested. A partial order is defined between TSPECs (and FLOWSPECs). A TSPEC A is larger than TSPEC B if and only if rA>rB, pA>pB, bA>bB, mA<mB and MA>MB. A TSPEC 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 of min policed unit m and the maximum of the max packet size M. GS FLOWSPECs are summed by adding the Resv rate and minimizing the slack term s. These rules are used to compute a meter that measures the temporal state of admitted RSVP states. The meter is than compared with the traffic profile specified in the signaling Snir, Ramberg, Strassner, Cohen expires May 2001 66 Draft-ietf-policy-qos-info-model-02.txt November 2000 policy using the same rules for comparison of TSPECs (FLOWSPECs) to a traffic profile. 5. Decision strategy Section 5.1 discusses how policy rules are organized into containers so that decision strategies can be applied to groups of policy rules. Section 5.2 defines two different decision strategies. Section 5.3 provides examples to illustrate how the different decision strategies affect the policy rules they operate on. 5.1 Organizing the Application of Decision Strategies This document recommends the following approach to be used by policy servers and other policy decision points in the network for QoS applications. The set of policies to be used is managed by first assigning them to their respective policy domains or reusable-object repositories. The policy rules will then be grouped into a set of gpsPolicyGroup groups. The organization of these gpsPolicyGroup groups is to be used to reflect any administrative, geographical, or other constraints that should be enforced by the policy system. This set of gpsPolicyGroup groups is used to partition behavior in the different QoS policy domains. The goal is to ensure that different policy servers using the same group of policy rules will enforce consistent behavior. That is, they will treat the conditions of the rules in the same way, and execute the same actions in the same order. Therefore, the priority of the policy rules must be pre-defined and the decision strategy implemented by each different policy server must be defined explicitly. The decision strategy is defined per domain and can be overridden by any PolicyDomain or gpsPolicyGroup instances that are contained within the domain. When a policy decision point evaluates a set of rules, it implements the decision strategy defined in each PolicyDomain or gpsPolicyGroup instance for that set of rules. Nested PolicyDomain or gpsPolicyGroup instances can override the decision strategy of the PolicyDomain or gpsPolicyGroup instances that contain them. The order of decision making for policy rules is based on the rule priority of PCIM. However, this rule priority has been extended in two important ways. The first is that nested rules can be defined. For nested rules, the contained, or innermost, rule has a higher priority than the containing, or outermost, rule. The second extension is that the gpsPolicyGroup class is given its own priority. This enables it to be treated in the same way that a PolicyRule is. In fact, this is purposely done so that the priority of a PolicyRule can be directly compared to the priority of a gpsPolicyGroup. The comparison is done for all instances at the same nesting level. Notice that nested rules are affected in the following way from their containing rules: Snir, Ramberg, Strassner, Cohen expires May 2001 67 Draft-ietf-policy-qos-info-model-02.txt November 2000 1. The containing rule's condition list is ANDed to the sub-rule condition list. 2. The containing rule actions are added to the sub-rule action list and performed in the appropriate order BEFORE the sub-rule actions. The following example helps clarify rule and sub-rule policy application. Rule 1.1 is nested within Rule 1 in the following form: Rule 1: If (Condition A) then Action A | +--- Rule 1.1 If (Condition B) then Action B These two rules can be ordered in a non hierarchical form and enforced as follows: Rule 1.1 If (Condition A AND Condition B) then Action A, Action B Rule 1: If (Condition A) then Action A Replacing the conditions and actions with concrete values: Rule 1: If (UDP) then guarantee 50% BW. | +--- Rule 1.1 If (TFTP) then Mark to DSCP=3 Leads to: Rule 1.1 IF (UDP AND TFTP) THEN guarantee 50% BW sharing queue x, Mark DSCP=3 Rule 1: IF (UDP) THEN guarantee 50% BW sharing queue x. 5.2 Decision Strategies Many different types of decision strategies can be defined. This section defines two different decision strategies: 1. "FIRST MATCH" 2. "MATCH ALL" 5.2.1. First Match Decision Strategy The first match decision strategy is defined as a process that evaluates the policy rules in the defined order, evaluating the conditions of each rule, until a condition is evaluated to TRUE. The rule's actions are then applied and the process of decision-making is terminated. 5.2.2. Match All Decision Strategy The match all decision strategy is defined as first scanning the complete set of rules according to their defined order of priority and then applying the actions of each rule that satisfies the rule's conditions. This matching strategy may in many cases mean that a Snir, Ramberg, Strassner, Cohen expires May 2001 68 Draft-ietf-policy-qos-info-model-02.txt November 2000 number of rules may satisfy the same set of conditions, and all of their actions will be applied. A Match All strategy may result in applying conflicting rules. Handling conflicts is outside the scope of this draft. The implementers of QoS systems must provide proprietary conflict detection and avoidance or resolution mechanisms to use this or any type of decision strategy that allows the execution of more than one rule for a given condition. 5.3. Decision Strategy example This section demonstrates both decision strategies and rule prioritization. The rules to be evaluated are shown in Figure 4 below. Domain | +--Rule1 (priority 19) | +--PolicyContainer1 (priority 5) | | | +--Rule 1.1 (priority 3) | | | +--Rule 1.2 (priority 33) | +--Rule3 (priority 4) | +--Rule4 (priority 2) Figure 4: Decision Strategy example This figure illustrates two extensions to PCIM. The first is that a special type of PolicyGroup, the gpsPolicyGroup, can be assigned a priority and have its priority compared to other PolicyRules and gpsPolicyGroups. The second is rule nesting, as illustrated by Rule 3 and Rule 4. The order of rule processing for the example above is: 1. Rule1 (higher priority between Rule1, PolicyContainer1 and Rule3 2. Rule1.2 (both Rule 1.1 and 1.2 will be considered next, because the priority of PolicyContainer1 is higher than the priority of Rule 3; Rule 1.2 executes next because its priority is higher than the priority of Rule1.1) 3. Rule1.1 (because its container has a higher priority than Rule3 4. Rule4 (because it is nested in Rule 3) 5. Rule3 If the decision strategy of the domain is 'first-match' and it is not overridden by PolicyContainer1, the decision process will stop once a rule's condition is matched. Snir, Ramberg, Strassner, Cohen expires May 2001 69 Draft-ietf-policy-qos-info-model-02.txt November 2000 If the decision strategy of the domain is 'match-all' and it is not overridden by PolicyContainerr1, the match all decision process will run over all rules according to the order above. If the decision strategy of the domain is 'first-match' and the decision process of PolicyContainer1 is match all, Rule1 will be evaluated first. If its condition matches, the decision process stops. Else, both Rules 1.1 and 1.2 will be evaluated (because the priority of the named container is higher than the priority of Rule 3). However, since the decision strategy is overridden in the named container, one or both of Rule 1.1 and Rule 1.2 will be executed if their conditions match. If one or both of these rules in the named container match, the decision process stops. Else Rules 3 and 4 will be evaluated using 'first-match' decision strategy. If the decision strategy of the domain is 'match-all' and the decision process of PolicyContainer1 is first match, the decision process will evaluate Rule1 and continue to evaluate both the PolicyContainer1 rules as well as Rule 3. Rules 1.1 and 1.2 will be evaluated using first match strategy. The decision process continues to evaluate rules 3 and 4 according to a 'match-all' decision strategy. 6. Per Hop Behavior 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. A PHB is selected at a node by the DSCP contained in a received packet. A set of PHBs is enforced on a QoS domain. The set of PHBs share buffer and scheduler resources among them. QPIM provides the means for defining a set of PHBs per qos domain by definition of a gpsPolicyGroup that includes a set of PHB rules. Each of this rules would classify packets based on DSCP value and define the action to be performed on this qos Class. PHB sets can be defined as reusable objects in the policy reusable-object repository to allow different domains to share the same per hop behavior. Snir, Ramberg, Strassner, Cohen expires May 2001 70 Draft-ietf-policy-qos-info-model-01.txt November 2000 7. QoS Policy Class Inheritance The following diagram illustrates the class hierarchy for the QPIM. Relevant classes from the PCIM are also included for completeness: top | +--policy (abstract, [PCIM]) | | | +--policyGroup ([PCIM]) | | | | | +--qosPolicyDomain | | | | | +--gpsPolicyGroup | | | +--policyRule ([PCIM]) | | | +--policyCondition ([PCIM]) | | | | | +--policyTimePeriodCondition ([PCIM]) | | | | | +--vendorPolicyCondition ([PCIM]) | | | | | +--gpsPolicySimpleCondition | | | | | +--gpsPolicyCompoundCondition | | | +--policyAction ([PCIM]) | | | | | +--vendorPolicyAction ([PCIM]) | | +-- qosPolicyPRAction | | | | | +-- qosPolicyPHBAction | | | | | +-- qosPolicyRSVPAction | | | | | +-- qosPolicyRSVPSignalCtrlAction | | | | | +-- qosPolicyRSVPInstallAction | | | +--gpsPolicyVariable | | | +--gpsPolicyValue(abstract) | | | | | +--gpsPolicyIPv4AddrValue | | | | | +--gpsPolicyIPv6AddrValue | | | | | | (diagram continued in next page) Snir, Ramberg, Strassner, Cohen expires May 2001 71 Draft-ietf-policy-qos-info-model-01.txt November 2000 (continued from the previous page) top | | +--gpsPolicyMACAddrValue | | | | | +--gpsPolicyStringValue | | | | | +--gpsPolicyBitStringValue | | | | +--policy (abstract, [PCIM]) | | | +--gpsPolicyValue (abstract) | | | | | +--gpsPolicyDNValue | | | | | +--gpsPolicyAttributeValue | | | | | +--gpsPolicyIntegerValue | | | +-- gpsPolicyMeter | | | +-- qosPolicyQueue | | | +-- gpsPolicyTrfcProf | | | +-- qosPolicyPRTrfcProf | | | +-- qosPolicyRSVPTrfcProf | | +--CIM_ManagedSystemElement (abstract) | +--CIM_LogicalElement (abstract) | +--CIM_System (abstract) | +---CIM_AdminDomain (abstract) | +---PolicyRepository Figure 5. Class Inheritance Hierarchy for the QPIM The reader is encouraged to read section 6 and section 7 of [PCIM] in their entirety. Section 6 defines all of the object classes listed above, and section 7 defines the concepts of associations and aggregations. Snir, Ramberg, Strassner, Cohen expires May 2001 72 Draft-ietf-policy-qos-info-model-01.txt November 2000 Ten associations and aggregations are defined in the [PCIM] as follows: the Aggregation PolicyGroupInPolicyGroup the Aggregation PolicyRuleInPolicyGroup the Aggregation PolicyConditionInPolicyRule the Aggregation PolicyRuleValidityPeriod the Aggregation PolicyActionInPolicyRule the Association PolicyConditionInPolicyRepository the Association PolicyActionInPolicyRepository the Weak Aggregation PolicyGroupInSystem the Weak Aggregation PolicyRuleInSystem the Aggregation PolicyRepositoryInPolicyRepository QPIM reuses the PCIM associations and aggregations listed above and defines the following new associations and aggregations in the following hierarchy: (the diagram is in the next page) Snir, Ramberg, Strassner, Cohen expires May 2001 73 Draft-ietf-policy-qos-info-model-01.txt November 2000 [top] | +---PolicyComponent (abstract) | | | +--- PolicyGroupInPolicyRule | | | +--- PolicyRuleInPolicyRule | | | +--- PolicyConditionInPolicyRule ([PCIM]) | | | | | +--- PolicyConditionInCompoundCondition | | | +--- PolicyVariableInPolicySimpleCondition | | | +--- PolicyValueInPolicySimpleCondition | | +---Dependency (abstract) | | | +--- PolicyMeterInAction | | | +--- PolicyValueConstraintsInVariable | | | +--- PolicyTrfcProfileInMeter | | | +--- PolicyQueueInPHBAction | | | +--- PolicyConformNextAction | | | +--- PolicyExcessNextAction | | | +--- PolicyViolateNextAction | | | +--- PolicyInSystem | | | | +--- PolicyElementInPolicyRepository Figure 6. Associations and Aggregation for the QPIM Snir, Ramberg, Strassner, Cohen expires May 2001 74 Draft-ietf-policy-qos-info-model-02.txt November 2000 8. Class Definitions 8.1. The Aggregation "PolicyGroupInPolicyRule" A policy rule may aggregate one or more policy groups, via the PolicyGroupInPolicyRule aggregation. Grouping of policy groups and their subclasses into a policy rule is for administrative convenience, scalability and manageability, as it enables more complex policies to be constructed from multiple simpler policies. For example, a PolicyRule may aggregate PolicyGroups and gpsPolicyGroups via this aggregation. Policy rules do not have to contain policy groups. In addition, a policy group may also be used by itself, without belonging to a policy rule and policy rules may be individually aggregated by other policy rules by the PolicyRuleInPilicyRule aggregation (section 8.Z.). Note that it is assumed that this aggregation is used to form directed acyclic graphs and NOT ring structures. The class definition for this aggregation is as follows: NAME PolicyGroupInPolicyRule DERIVED FROM PolicyComponent (defined in [PCIM]) ABSTRACT False PROPERTIES GroupComponent[ref PolicyRule[0..n]] PartComponent[ref PolicyGroup[0..n]] 8.1.1. The Reference "GroupComponent" This property is inherited from PolicyComponent, and overridden To become an object reference to a PolicyRule that contains one or More PolicyGroups. Note that for any single instance of the aggregation class PolicyGroupInPolicyRule, this property (like all Reference properties) is single-valued. The [0..n] cardinality indicates that there may be 0, 1 or more PolicyRules that contain any given PolicyGroup. 8.1.2. The Reference "PartComponent" This property is inherited from PolicyComponent, and overridden to become an object reference to a PolicyGroup contained by one or more PolicyRules. Note that for any single instance of the aggregation class PolicyGroupInPolicyRule, this property (like all Reference properties) is single-valued. The [0..n] cardinality indicates that a given PolicyRule may contain 0, 1, or more than one PolicyGroup. Snir, Ramberg, Strassner, Cohen expires May 2001 75 Draft-ietf-policy-qos-info-model-01.txt November 2000 8.2. The Aggregation "PolicyRuleInPolicyRule" A policy rule may aggregate one or more policy rules, via the PolicyRuleInPolicyRule aggregation. Grouping of policy rules into a policy rule, as sub-rules is explained in section XXX. The ability to nest policy rules and form sub-rules is important for manageability and scalability, as it enables complex policy rules to be constructed from multiple simpler policy rules. A PolicyRule does not have to contain sub-rules. Note that it is assumed that this aggregation is used to form directed acyclic graphs and NOT ring structures. The class definition for this aggregation is as follows: NAME PolicyRuleInPolicyRule DERIVED FROM PolicyComponent (defined in [PCIM]) ABSTRACT False PROPERTIES GroupComponent[ref PolicyRule[0..n]] PartComponent[ref PolicyRule[0..n]] 8.2.1. The Reference "GroupComponent" This property is inherited from PolicyComponent, and overridden to become an object reference to a PolicyRule that contains one or more PolicyRules. Each contained PolicyRule can be conceptualized as a sub- rule of the containing PolicyRule. This nesting can be done to any desired level. However, the deeper the nesting, the more complex the results of the decisions taken by the nested rules. Note that a group of rules can be aggregated by a policy group(gpsPolicyGroups) and aggregated as a unit by a policy rule (section 8.Z). Note that for any single instance of the aggregation class PolicyRuleInPolicyRule, this property is single-valued. The [0..n] cardinality indicates that there may be 0, 1 or more PolicyRules that contain any given PolicyRule. 8.2.2. The Reference "PartComponent" This property is inherited from PolicyComponent, and overridden to become an object reference to a PolicyRule contained by a PolicyRule. Note that for any single instance of the aggregation class PolicyRuleInPolicyRule, this property is single-valued. The [0..n] cardinality indicates that a given PolicyRule may contain 0, 1, or more PolicyRules. Snir, Ramberg, Strassner, Cohen expires May 2001 76 Draft-ietf-policy-qos-info-model-01.txt November 2000 8.3. The Aggregation "PolicyConditionInCompoundCondition" A policy compound condition may aggregate one or more policy conditions, via the PolicyConditionInCompoundCondition aggregation. Grouping of policy conditions and their derivatives into a policy compound condition is for reusability of partial or full Boolean condition statements. A qosPolicyCompoundCondition may aggregate PolicyConditions and their derivatives, such as qosPolicySimpleConditions and qosPolicyCompoundConditions. The properties GroupNumber and ConditionNegated are inherited from PolicyConditionInPolicyRule and are specified per instance of this aggregation class. There is no change in their semantics, so they are not redefined here. However, the GroupComponent and PartComponent properties DO have modified semantics, and so they are described below. The class definition for this aggregation is as follows: NAME PolicyConditionInCompoundCondition DERIVED FROM PolicyConditionInPolicyRule (defined in [PCIM]) ABSTRACT False PROPERTIES GroupComponent[ref gpsPolicyCompoundCondition[0..n]] PartComponent[ref PolicyCondition[0..n]] 8.3.1. The Reference "GroupComponent" This property is inherited from PolicyComponent, and overridden to become an object reference to a gpsPolicyCompoundCondition that contains one or more PolicyConditions. Note that for any single instance of the aggregation class PolicyConditionInCompoundCondition, this property is single-valued. The [0..n] cardinality indicates that there may be 0, 1 or more gpsPolicyCompoundCondition objects that contain any given policyCondition object, or its subclasses. 8.3.2. The Reference "PartComponent" This property is inherited from PolicyComponent, and overridden to become an object reference to a PolicyCondition contained by one or more gpsPolicyCompoundConditions. Note that for any single instance of the aggregation class PolicyConditionInPolicyRule, this property is single-valued. The [0..n] cardinality indicates that a given gpsPolicyCompoundCondition may contain 0, 1 or more1 PolicyConditions (or subclasses of PolicyCondition). 8.4. The aggregation "PolicyVariableInPolicySimpleCondition" QoS policy simple conditions are represented as the ordered triplet {variable, operator, value}. The PolicyElement class is the common superclass for the PolicyVariable and PolicyValue classes and their subclasses. A gpsPolicySimpleCondition associates exactly Snir, Ramberg, Strassner, Cohen expires May 2001 77 Draft-ietf-policy-qos-info-model-01.txt November 2000 one gpsPolicyVariable via the PolicyVariableInPolicySimpleCondition aggregattion. This aggregation links a subclass of PolicyElement to the gpsPolicySimpleCondition in whose scope the PolicyElement subclass is defined. The class definition for this aggregation is as follows: NAME PolicyVariableInPolicySimpleCondition DERIVED FROM PolicyComponent (defined in [PCIM]) ABSTRACT False PROPERTIES GroupComponent[ref gpsPolicySimpleCondition[0..n]] Partcomponent[ref gpsPolicyVariable[1..1] ] 8.4.1. The Reference "GroupComponent" This property is inherited from PolicyComponent, and overridden to become an object reference to a gpsPolicySimpleCondition that contains exactly one gpsPolicyVariable. Note that for any single instance of the aggregation class policyVariableInPolicySimpleCondition, this property is single-valued. The [0..n] cardinality indicates that there may be 0, 1 or more gpsPolicySimpleCondition objects that contain any given gpsPolicyVariable object, or its subclasses. 8.4.2. The Reference "PartComponent" This property is inherited from Dependency, and overridden to become an object reference to a PolicyVariable class (or one of its subclasses) that is defined within the scope of a gpsPolicySimpleCondition. Note that for any single instance of the association class PolicyVariableInPolicySimpleCondition, this property (like all reference properties) is single-valued. The [1..1] cardinality indicates that a qpsPolicySimpleCondition must have exactly one PolicyVariable class (or one of its subclasses) defined within its scope in order to be a meaningful. 8.5. The Aggregation "PolicyValueInPolicySimpleCondition" QoS policy simple conditions are represented as the ordered triplet {variable, operator, value}. The PolicyElement class is the common superclass for the PolicyVariable and PolicyValue classes and their subclasses. A gpsPolicySimpleCondition associates exactly one gpsPolicyValue via the PolicyValueInPolicySimpleCondition aggregation. This aggregation links a subclass of PolicyElement to the gpsPolicySimpleCondition in whose scope the PolicyElement subclass is defined. Snir, Ramberg, Strassner, Cohen expires May 2001 78 Draft-ietf-policy-qos-info-model-02.txt November 2000 The class definition for this association is as follows: NAME PolicyValueInPolicySimpleCondition DERIVED FROM PolicyComponent (defined in [PCIM]) ABSTRACT False PROPERTIES GroupComponent[ref gpsPolicySimpleCondition[0..n]] PartComponent[ref gpsPolicyValue[1..1]] 8.5.1. The Reference "GroupComponent" This property is inherited from PolicyComponent, and overridden to become an object reference to a gpsPolicySimpleCondition that contains exactly one gpsPolicyValue. Note that for any single instance of the aggregation class PolicyValueInPolicySimpleCondition, this property is single-valued. The [0..n] cardinality indicates that there may be 0, 1 or more gpsPolicySimpleCondition objects that contain any given gpsPolicyValue object, or its subclasses. 8.5.2. The Reference "PartComponent" This property is inherited from Dependency, and overridden to become an object reference to a PolicyValue class (or one of its subclasses) that is defined within the scope of a gpsPolicySimpleCondition. Note that for any single instance of the association class PolicyValueInPolicySimpleCondition, this property (like all reference properties) is single-valued. The [1..1] cardinality indicates that a qpsPolicySimpleCondition must have exactly one PolicyValue class (or one of its subclasses) defined within its scope in order to be a meaningful. 8.6. The Association "PolicyElementInPolicyRepository" Policy objects (e.g., policy variables, values and other reusable policy objects) can be made reusable. Reusable policy elements are always related to a single PolicyRepository via the PolicyElementInPolicyRepository association. Policy conditions can use this association to assign reusable policy variables and/or values. Note that either policy variables and/or values do not have to be reused. In order to construct policy conditions of this form, use the PolicyVariableInPolicySimpleCondition and PolicyValueInPolicySimpleCondition weak associations as appropriate. The class definition for this association is as follows: NAME PolicyElementInPolicyRepository DERIVED FROM PolicyInSystem ABSTRACT FALSE PROPERTIES Antecedent[ref PolicyRepository[0..1]] Dependent[ref Policy[0..n]] Snir, Ramberg, Strassner, Cohen expires May 2001 79 Draft-ietf-policy-qos-info-model-01.txt November 2000 8.6.1. The Reference "Antecedent" This property is inherited from PolicyInSystem, and overridden to become an object reference to a PolicyRepository containing one or more Policy objects. A reusable Policy object is always related to exactly one PolicyRepository via the PolicyElementInPolicyRepository association. The [0..1] cardinality for this property signifies whether the Policy object is reusable or not. If it is 0, then the association is not instantiated, which means that this Policy object is specific to a single PolicyCondition. If this association is instantiated, then it means that the Policy object (subclass) is reusable, and is located in this specific PolicyRepository. 8.6.2. The Reference "Dependent" This property is inherited from PolicyInSystem, and overridden to become an object reference to a Policy object, or inheriting class included in a PolicyRepository. If this association is not instantiated (the "0" part of the cardinality), then this Policy object is embedded (or attached) directly to the containig object. However, if this association is instantiated, then the [0..n] cardinality indicates that a given PolicyRepository may contain 0, 1, or more than one Policy objects. 8.7. The Association "PolicyValueConstraintsInVariable" This association links a gpsPolicyValue object to a gpsPolicyVariable object, modeling specific value constraints. For example, the gpsPolicyVariable assignment/binding may be constrained to a specific value of IP Address. The constraints then are twofold. First, one may want to constrain the set of allowable address values. Second, one may want to ensure that the variable is of the correct data type. This latter is provided by Table 1, which defines the set of value types that each type of PolicyVariable can assume. The class definition for the association is as follows: NAME PolicyValueConstraintsInVariable DESCRIPTION A class representing the association of a constraints object to a variable object DERIVED FROM Dependency (defined in [PCIM]) ABSTRACT FALSE PROPERTIES Antecedent[ref gpsPolicyVariable[0..1]] Dependent[ref gpsPolicyValue [0..n]] Snir, Ramberg, Strassner, Cohen expires May 2001 80 Draft-ietf-policy-qos-info-model-01.txt November 2000 8.7.1. The Reference "Antecedent" This property is inherited from Dependency. Its type is and cardinality are overridden to provide the semantics of a variable optionally having value constraints. This property itself is an object reference to a policy variable (gpsPolicyVariable) that is optionally constrained by one or more policy value class instances (gpsPolicyValue). 8.7.2. The Reference "Dependent" This property is inherited from Dependency, and overridden to become an object reference to a gpsPolicyValue that is used to constrain the values that a particular gpsPolicyVariable can have. The [0..n] cardinality indicates that a given policy variable may have 0, 1 or more gpsPolicyValues defined to model the constraints on the values that the policy variable can take. 8.8. The Association "PolicyMeterInAction" This association links a gpsPolicyMeter object modeling a specific meter to a qosPolicyPRAction or a qosPolicyRSVPAction object. The class definition for the association is as follows: NAME PolicyMeterInAction DESCRIPTION A class representing the association between a gpsPolicyMeter object and a specific meter object. DERIVED FROM Dependency ABSTRACT FALSE PROPERTIES Antecedent[ref PolicyAction[0..n] Dependent[ref gpsPolicyMeter [0..n] 8.8.1. The Reference "Antecedent" This property is inherited from Dependency. It serves as an object reference to either a qosPolicyPRAction or a qosPolicyRSVPAction. The [0..n] cardinality indicates that a given meter may be referenced by 0, or 1 more policy actions. 8.8.2. The Reference "Dependent" This property is inherited from Dependency, and is overridden to become an object reference to a gpsPolicyMeter. The [0..n] cardinality indicates that a given policy action may have 0 or more gpsPolicyMeter objects to which it applies. Snir, Ramberg, Strassner, Cohen expires May 2001 81 Draft-ietf-policy-qos-info-model-02.txt November 2000 8.9. The Association "PolicyTrfcProfileInMeter" This association links a gpsPolicyTrfcProf object modeling a specific traffic profile to a gpsPolicyMeter object. The class definition for this association is as follows: NAME PolicyTrfcProfileInMeter DESCRIPTION A class representing the association between a traffic profile that is used for provisioning and a meter. DERIVED FROM Dependency ABSTRACT FALSE PROPERTIES Antecedent[ref gpsPolicyMeter [0..n]] Dependent[ref gpsPolicyTrfcProf [0..1]] 8.9.1. The Reference "Antecedent" This property is inherited from Dependency. It serves as an object reference to a meter that uses a traffic profile object to provision flows. The [0..n] cardinality indicates that a given meter may use zero or more traffic profiles. 8.9.2. The Reference "Dependent" This property is inherited from Dependency, and overridden to become an object reference to a traffic profile used by a meter. The [0..n] cardinality indicates that a given traffic profile may be used by 0 or more meters. 8.10. The Weak Association " PolicyQueueInPHBAction " This association links a qosPolicyQueue object modeling a specific queue to a QoSPolicyPHBAction object. The class definition for this association is as follows: NAME PolicyQueueInPHBAction DESCRIPTION A class representing the association between a queue and a PHB action. DERIVED FROM Dependency ABSTRACT FALSE PROPERTIES Antecedent[ref qosPolicyPHBAction[0..n]] Dependent[ref qosPolicyQueue [0..n]] 8.10.1. The Reference "Antecedent" This property is inherited from Dependency. It serves as an object reference to a qosPolicyPHBAction that references a qosPolicyQueue. The [0..n] cardinality indicates that a given queue may be referenced by 0 or more PHB actions. Snir, Ramberg, Strassner, Cohen expires May 2001 82 Draft-ietf-policy-qos-info-model-02.txt November 2000 8.10.2. The Reference "Dependent" This property is inherited from Dependency, and overridden to become an object reference to a qosPolicyQueue defined within the scope of a qosPolicyPHBAction. The [0..n] cardinality indicates that a given PHB action may be used by zero or more qosPolicyQueues. 8.11. The Association "PolicyConformNextAction" This association links an action using a meter with an object defining an action to be applied on the conforming traffic, as defined by the relevant traffic profile. The class definition for this association is as follows: NAME PolicyConformNextAction DESCRIPTION A class representing the association between two action object in order to model action to be applied on traffic conforming to an associated traffic profile. DERIVED FROM Dependency ABSTRACT FALSE PROPERTIES Antecedent[ref QoSPolicyPRAction[0..1]] Dependent[ref QoSPolicyPRAction [0..1]] 8.11.1. The Reference "Antecedent" This property is inherited from Dependency. It serves as an object reference to a qosPolicyPRAction object, which provides scoping for the next action to be applied on conforming traffic. This next action is modeled by a QoSPolicyPRAction object. The [0..1] cardinality means that a given qosPolicyPRAction may define 0 or 1 qosPolicyPRAction objects to use as its conforming action. 8.11.2. The Reference "Dependent" This property is inherited from Dependency, and overridden to become an object reference to a qosPolicyPRAction object that is defined within the scope another QoSPolicyPRAction. The [0..1] cardinality indicates that a given conforming action (modeled using a qosPolicyPRAction object) may be used by 0 or 1 qosPolicyPRAction objects. Snir, Ramberg, Strassner, Cohen expires May 2001 83 Draft-ietf-policy-qos-info-model-02.txt November 2000 8.12. The Association "PolicyExcessNextAction" This association links another action using a meter with an object defining an action to be applied on excess traffic, as defined by the relevant traffic profile. The class definition for this association is as follows: NAME PolicyExcessNextAction DESCRIPTION A class representing the association between two action objects in order to model action to be applied on traffic in excess to an associated traffic profile. DERIVED FROM Dependency ABSTRACT FALSE PROPERTIES Antecedent[ref QoSPolicyPRAction[0..1]] Dependent[ref QoSPolicyPRAction [0..1]] 8.12.1. The Reference "Antecedent" This property is inherited from Dependency. It serves as an object reference to a qosPolicyPRAction that provides a scope for the next action applied on excess traffic, modeled by a qosPolicyPRAction object. The [0..1] cardinality indicates that a given qosPolicyPRAction object may have 0 or 1 qosPolicyPRAction objects defined to process excess traffic. 8.12.2. The Reference "Dependent" This property is inherited from Dependency, and overridden to become an object reference to a qosPolicyPRAction that is handling the excess traffic defined within the scope of another qosPolicyPRAction object. The [0..1] cardinality indicates that a given excess action, modeled as a qosPolicyPRAction object, may be used by 0 or 1 qosPolicyPRAction objects. 8.13. The Association "PolicyViolateNextAction" This association links an action using a meter with an object defining an action to be applied on the violating traffic, as a defined by the relevant traffic profile. The class definition for this association is as follows: NAME PolicyExcessNextAction DESCRIPTION A class representing the association between two action objects in order to model action to be applied on traffic in violation to an associated traffic profile. DERIVED FROM Dependency ABSTRACT FALSE Snir, Ramberg, Strassner, Cohen expires May 2001 84 Draft-ietf-policy-qos-info-model-02.txt November 2000 PROPERTIES Antecedent[ref QoSPolicyPRAction[0..1]] Dependent[ref QoSPolicyPRAction [0..1]] 8.13.1. The Reference "Antecedent" This property is inherited from Dependency. It serves as an object reference to a qosPolicyPRAction that provides a scope for the next action to be applied on violating traffic, modeled by a qosPolicyPRAction object. The [0..1] cardinality indicates that a given qosPolicyPRAction object may have 0 or 1 qosPolicyPRAction objects defined to process violating traffic. 8.13.2. The Reference "Dependent" This property is inherited from Dependency, and overridden to become an object reference to a qosPolicyPRAction defined within the scope of another qosPolicyPRAction object. The [0..1] cardinality indicates that a given violating action, modeled as a qosPolicyPRAction object, may be used by 0 or 1 QoSPolicyPRAction objects. 8.14. Class qosPolicyDomain This class defines the root of a single administrative QoS policy domain, and contains the domain's policy rules and definitions. This enables the administrator to partition the set of QoS information into different domains, where each domain has a potentially different set of PHBs and policies, access rules, decision strategy or other application of the policy information organized in some fashion. The class definition is as follows: NAME qosPolicyDomain DERIVED FROM policyGroup (defined in [PCIM]) ABSTRACT False PROPERTIES qpDomainName, qpPolicyRuleMatchMethod 8.14.1. The Property qpDomainName This property provides a user-friendly name for the QoS policy domain. Its definition is as follows: NAME qpDomainName SYNTAX String Snir, Ramberg, Strassner, Cohen expires May 2001 85 Draft-ietf-policy-qos-info-model-02.txt November 2000 8.14.2. The Property qpPolicyRuleMatchMethod This property defines the decision strategy to be applied on this set of QoS policy rules by policy servers. It is an enumerated integer that defines two values, first match and match all. Please see section 5 of this document for more information on these decision strategies. Its definition is as follows: NAME qpPolicyRuleMatchMethod SYNTAX Integer (ENUM) - {"FIRST MATCH " = 0; "MATCH ALL " = 1 } 8.15. Class gpsPolicyGroup This class represents an administratively-defined policy rule container. All policies that are commonly administered are defined in a particular gpsPolicyGroup. For example, an administrator could define a set of policies that serve a certain goal, or service a certain type of application, or that handle a certain type of flow or device. Placing these policies in a gpsPolicyGroup that resides in a particular qosPolicyDomain enables the administrator to group different sets of policy rules that perform different types of operations. It also enables an organization to partition policies according to the administrator (or other entity) that manages the policies. The class definition is as follows: NAME gpsPolicyGroup DERIVED FROM policyGroup (defined in [PCIM]) ABSTRACT False PROPERTIES gpPriority, gpNamedPolicyRuleMatchMethod gpPolicyRoles 8.15.1. The Property gpPriority This property is a non-negative integer that defines the priority of a named group of rules. Conceptually, it is the priority of the gpsPolicyGroup, and is used to determine when the policy rules that the gpsPolicyGroup contains are evaluated with respect to other policyRules and gpsPolicyGroups. If two or more gpsPolicyGroup objects have the same priority, this means that the order between these objects is of no importance, but that they MUST each be evaluated before other objects that have a numerically lower priority. The attribute is defined as follows: NAME gpPriority SYNTAX Integer (must be non-negative) Snir, Ramberg, Strassner, Cohen expires May 2001 86 Draft-ietf-policy-qos-info-model-01.txt November 2000 8.15.2. The Property gpNamedPolicyRuleMatchMethod This property is an enumerated integer that defines the decision strategy to be applied on this set of QoS policy rules by policy servers. Please see section 5 of this document for more information on these decision strategies. See attribute definition of qpPolicyRuleMatchMethod. The attribute is defined as follows. NAME gpNamedPolicyRuleMatchMethod SYNTAX Integer (ENUM) - {"MATCH FIRST" = 0; "MATCH ALL" = 1 } 8.15.3 The Property gpPolicyRoles This property represents the roles and role combinations associated with all policy rules contained in this Policy Group by placement or aggregation. Each value represents one role combination.Since this is a multi-valued property, more than one role combinationcan be associated with a single policy rule. Each value is a string of the form <RoleName>[&&<RoleName>]* where the individual role names appear in alphabetical order (according to the collating sequence for UCS-2). The property definition is as follows: NAME gpPolicyRoles SYNTAX string 8.16. Class qosPolicyPRAction This class defines DiffServ actions to be applied on a flow or group of flows, including the marking of a DSCP value, dropping, policing and shaping. The association PolicyMeterInAction is used to associate a meter to qosPolicyPRAction. The associations PolicyConformNextAction, PolicyExcessNextAction, PolicyViolateNextAction can be used to link other actions to be enforced on flows that either conform, exceed or violate the associated meter and traffic profile. The class definition is as follows: NAME qosPolicyPRAction DERIVED FROM policyAction (defined in [PCIM]) ABSTRACT False PROPERTIES qpDirection, qpMarkvalue, qpMarkValueType, qpExcessAction, qpExcessMarkValue, qpViolateAction, qpViolateMarkValue 8.16.1. The Property qpDirection This property is an enumerated integer that defines whether the action should be applied to incoming or/and outgoing interfaces. Note that certain repositories MAY implement this enumeration in a different form, as long as its semantics are preserved. For example, a directory Snir, Ramberg, Strassner, Cohen expires May 2001 87 Draft-ietf-policy-qos-info-model-02.txt November 2000 MAY implement this property as a multi-valued attribute, with the attribute having the values IN and OUT. The attribute is defined as follows: NAME qpDirection SYNTAX Integer (ENUM) - {IN=0, OUT=1, BOTH=2} 8.16.2. The Property qpMarkValue This property is an integer that defines the value for the mark action. The range of values depend on the type defined in qpMarkValueType. If qpMarkValueType property is not defined, qpMarkValue is assumed to carry DSCP value in the range of 0-63 inclusive. defined as follows: NAME qpMarkValue SYNTAX Integer 8.16.3. The Property qpMarkValueType This property is an enumerated integer that defines the type of marking value used in this provisioning action. The attribute is defined as follows: NAME qpMarkValueType SYNTAX Integer (ENUM) {DSCP=0, IPP=1. TOS=2. COS=3} 8.16.4. The Property qpExcessAction This property is an enumerated integer that defines the action to be applied to out of profile, excess traffic, as defined in the qpTrfcProf referenced traffic profile instance. The attribute is defined as follows: NAME qpExcessAction SYNTAX Integer (ENUM) - {SHAPE=0,DISCARD=1,REMARK=2} 8.16.5. The Property qpExcessMarkValue This property is an integer that defines the marking value to be applied to excess out of profile packets if the qpExcessAction action is defined as REMARK. Notice that the marking type is defined by the Provisioning action qpMarkValueType property. The attribute is defined as follows: NAME qpExcessMarkValue SYNTAX Integer Snir, Ramberg, Strassner, Cohen expires May 2001 88 Draft-ietf-policy-qos-info-model-02.txt November 2000 8.16.6. The Property qpViolateAction This property is an enumerated integer that defines the action to be applied to out of profile, violating traffic, as defined in the qpTrfcProf referenced traffic profile instance. That entry contains values for each of the four types of actions that are present in this attribute: shaping, discarding or remarking. The attribute is defined as follows: NAME qpViolateAction SYNTAX Integer (ENUM) - {SHAPE=0,DISCARD=1,REMARK=2} 8.16.7. The Property qpViolateMarkValue This property is an integer that defines the marking value to be applied to violating out of profile packets if the qpViolateAction action is defined as REMARK. Notice that the marking type is defined by the provisioning action qpMarkValueType property. The attribute is defined as follows: NAME qpViolateMarkValue SYNTAX Integer 8.17. Class qosPolicyPHBAction This class defines DiffServ actions to be applied in order to provide the correct Per Hop Behavior across the QoS domain. PHB actions control the bandwidth and buffer resources and congestion control across each hop. The association PolicyQueueInPHBAction is used to associate a qosPolicyQueue object with a PHB action. The class definition is as follows: NAME qosPolicyPHBAction DERIVED FROM policyAction (defined in [PCIM]) ABSTRACT False PROPERTIES qpPHBDirection, qpDropAlgorithm, pDropTreshholdValueType, qpDropMinTreshholdValue, qpDropMaxTreshholdValue, qpRandomDropInvWeight, qpRandomDropProbMax, qpPacketSize 8.17.1. The Property qpPHBDirection This property is an enumerated integer that defines whether the action should be applied to incoming or/and outgoing interfaces. Note that certain repositories MAY implement this enumeration in a different form, as long as its semantics are preserved. For example, a directory MAY implement this property as a multi-valued attribute, with the attribute having the values IN and OUT. The attribute is defined as follows: Snir, Ramberg, Strassner, Cohen expires May 2001 89 Draft-ietf-policy-qos-info-model-02.txt November 2000 NAME qpPHBDirection SYNTAX Integer (ENUM) - {IN=0, OUT=1, BOTH=2} 8.17.2 The Property qpDropAlgorithm This property specifies the congestion control drop algorithm that should be used for this type of traffic. The attribute is defined as follows. NAME qpDropAlgorithm SYNTAX Integer {ENUM} - {alwaysDrop=0, tailDrop=1, headDrop=2, randomDrop=3} 8.17.3 The Property qpDropTreshholdValueType This property specifies the units in which qpDropMinThresholdValue and qpDropMaxThresholdValue are measured. The attribute is defined as follows. NAME qpDropThresholdValueType SYNTAX Integer {ENUM} - {numberOfPackets=0, numberOfBytes=1, percentageOfPackets=2, percentageOfBytes=3} 8.17.4 The Property qpDropMinThreshholdValue This property specifies the minimal number of queuing and buffer resources that should be reserved to this class of flows. The threshold can be specified as either relative or absolute value according to the value of qpDropThresholdValueType property. If this property specifies a value of 5 packets than enough buffer and queuing resources should be reserved to hold 5 packets before running the specified congestion control drop algorithm. If this class of traffic is one member of a PHB group and therefore shares a queue, the drop mechanism should not drop any packet from this class of traffic before the queue holds 5 packets of the entire PHB group: NAME qpDropMinThresholdValue SYNTAX Integer 8.17.5 The Property qpDropMaxTreshholdValue This property specifies the maximal number of queuing and buffer resources that should be reserved to this class of flows. The threshold can be specified as either relative or absolute value according to the value of qpDropThresholdValueType property. Congestion Control droppers should not keep more packets than the value specified in this property. Note however, that some dropper may calculate queue occupancy averages, and therefore the actual maximal queue resources should be larger. The attribute is defined as follows: Snir, Ramberg, Strassner, Cohen expires May 2001 90 Draft-ietf-policy-qos-info-model-02.txt November 2000 NAME qpDropMaxThresholdValue SYNTAX Integer 8.17.6 The Property qpRandomDropInvWeight This property specifies the random dropper's weighting of past history in affecting the calculation of the current queue average. The moving average of the queue depth uses the inverse of this value as the factor for the new queue depth, and one minus that inverse as the factor for the historical average [DIFF-MIB]. The attribute is defined as follows: NAME qpRandomDropInvWeight SYNTAX Integer 8.17.7 The Property qpRandomDropProbMax This property specifies the random dropper's worst case random drop probability, expressed in drops per thousand packets. The attribute is defined as follows. NAME qpRandomDropProbMax SYNTAX Integer 8.17.8 The Property qpPacketSize This property defines a typical packet size for this class of traffic. This property is used to translate threshold values specified in packets to bytes and vice versa. The attribute is defined as follows. NAME qpPacketSize SYNTAX Integer 8.18. Class qosPolicyRSVPAction This class defines a policy action to be applied on an RSVP signaling message that matches the rule condition. The association PolicyMeterInAction can be used to associate a meter and an RSVP traffic profile to an RSVP action object to enforce an admission decision. The class definition is as follows: NAME qosPolicyRSVPAction DERIVED FROM policyAction (defined in [PCIM]) ABSTRACT False PROPERTIES qpRSVPDirection, qpRSVPMessageType, qpRSVPService, qpRSVPStyle, Snir, Ramberg, Strassner, Cohen expires May 2001 91 Draft-ietf-policy-qos-info-model-02.txt November 2000 8.18.1. The Property qpRSVPDirection This property is an enumerated integer, and defines whether the action is to be applied to incoming or/and outgoing interfaces. Note that certain repositories MAY implement this enumeration in a different form, as long as its semantics are preserved. For example, a directory MAY implement this property as a multi-valued attribute, with the attribute having the values IN and OUT. The attribute is defined as follows: NAME qpRSVPDirection SYNTAX Integer (ENUM) - {IN=0,OUT=1,BOTH=2} 8.18.2. The Property qpRSVPMessageType This property is an enumerated integer, and defines different values that limit the scope of the action to be enforced to specific types of RSVP messages. The attribute is defined as follows: NAME qpRSVPMessageType SYNTAX Integer (ENUM) - {Path=0 Resv=1 ResvErr=2 PathErr=3} 8.18.3. The Property qpRSVPStyle This property is an enumerated integer, and defines different values that limit the scope of the action to be enforced to RSVP Requests with the specified reservation style. The attribute is defined as follows: NAME qpRSVPStyle SYNTAX Integer (ENUM) - {SE=0 FF=1 WF=2} 8.18.4. The Property qpRSVPServiceType This property is an enumerated integer, and defines different values that limit the scope of the action to be enforced to RSVP Requests asking for specified integrated service type. The attribute is defined as follows: NAME qpRSVPServiceType SYNTAX Integer (ENUM) - {ControlledLoad=0, GuaranteedService=1, NULL=2} Snir, Ramberg, Strassner, Cohen expires May 2001 92 Draft-ietf-policy-qos-info-model-01.txt November 2000 8.19. Class qosPolicyRSVPSignalCtrlAction This class extends the functionality of the qosPolicyRSVPAction class by adding detailed control on the signaling protocol behavior itself. The information carried in RSVP messages can be modified using this action, as well as the RSVP forwarding behavior. Since the purpose of this is to augment the behavior specified by the qosPolicyRSVPAction class, this class SHOULD be used with a qosPolicyRSVPAction object, and SHOULD NOT be used by itself. This class can be extended to support replacement of additional object in RSVP messages, beyond replacement of DCLASS and PREEMPTION object replacement defined below. The class definition is as follows: NAME qosPolicyRSVPSignalCtrlAction DERIVED FROM qosPolicyRSVPAction ABSTRACT False PROPERTIES qpForwardingMode, qpSendError, qpReplaceDSCP, qpReplacePreemptionPriority, qpReplaceDefendingPriority 8.19.1. The Property qpForwardingMode This property is an enumerated integer that controls the forwarding of RSVP messages. If the mode is set to proxy, RSVP Path messages are not forwarded and a Resv message is returned as if the Resv was returned by the receiver. Otherwise, RSVP Path messages are forwarded. The attribute is defined as follows: NAME qpForwardingMode SYNTAX Integer (ENUM) - {Forward=0 , Proxy=1} 8.19.2. The Property qpSendError This property is an enumerated integer and controls the generation of Resv-Err and Path-Err messages as defined in [COPSRSVP]. The attribute is defined as follows: NAME qpSendError SYNTAX Integer {No=0, Yes=1} 8.19.3. The Property qpReplaceDSCP This property is a non-negative integer that allows the replacement of a DCLASS object carrying a DSCP value in an RSVP message. The attribute specifies the DSCP value to be replaces, and is defined as follows: Snir, Ramberg, Strassner, Cohen expires May 2001 93 Draft-ietf-policy-qos-info-model-02.txt November 2000 NAME qpReplaceDSCP SYNTAX Integer (constrained to the range 0-63, inclusive) 8.19.4. The Property qpReplacePreemptionPriority This property is a non-negative integer that is used to replace or add a preemption priority object (defined in [RSVP_PREEMP]) to RSVP messages. The attribute is defined as follows: NAME qpReplacePreemptionPriority SYNTAX Integer (must be non-negative) 8.19.5. The Property qpReplaceDefendingPriority This property is a non-negative integer that is used to replace or add a preemption priority object (defined in [RSVP_PREEMP]) to RSVP messages. It specifies the defending priority within the preemption object. The attribute is defined as follows: NAME qpReplaceDefendingPriority SYNTAX Integer (must be non-negative) 8.20. Class qosPolicyRSVPInstallAction This class extends the functionality of the qosPolicyRSVPAction class by adding detailed control for COPS Install decisions (defined in [COPS]). This action allows assigning a preemption priority with an RSVP request, to provide a device with information which RSVP requests to accept in case of admission failures. This action specifies a DSCP value (which provides an associated level of QoS) to set on the flow that RSVP is requesting. Since the purpose of this is to augment the behavior specified by the qosPolicyRSVPAction class, this class SHOULD be used with a qosPolicyRSVPAction object, and SHOULD NOT be used by itself. This class can be extended to support additional install decisions that need to be controlled. The class definition is as follows: NAME qosPolicyRSVPInstallAction DERIVED FROM policyAction (defined in [PCIM]) ABSTRACT False PROPERTIES qpSetDSCPValue, qpSetPreemptionPriority, qpSetDefendingPriority Snir, Ramberg, Strassner, Cohen expires May 2001 94 Draft-ietf-policy-qos-info-model-02.txt November 2000 8.20.1. The Property qpSetDSCPValue This property is a non-negative integer that defines the setting of a DSCP value in the device. In other words, this attribute controls the remarking (by the device) of the flow signaled by the RSVP request. The attribute is defined as follows: NAME qpSetDSCPValue SYNTAX Integer (constrained to the range 0-63, inclusive) 8.20.2. The Property qpSetDefendingPriority This property is a non-negative integer, and is used to set the defending priority within the preemption object (defined in [RSVP_PREEMP]) of RSVP flows. The attribute is defined as follows: NAME qpSetDefendingPriority SYNTAX Integer (must be non-negative) 8.20.3. The Property qpSetPreemptionPriority This property is a non-negative integer, and is used to set the preemption priority [RSVP_PREEMP] of RSVP flows. The attribute is defined as follows: NAME qpSetPreemptionPriority SYNTAX Integer (must be non-negative) 8.21 Class gpsPolicyTrfcProf An abstract class that models a traffic profile. Traffic profile specifies the maximal rate parameters compared against a meter. The association PolicyTrfcProfileInMeter is used to associate between the two. NAME gpsPolicyTrfcProf DERIVED FROM policy (defined in [PCIM]) ABSTRACT True PROPERTIES 8.22. Class qosPolicyPRTrfcProf A provisioning Traffic profile is a class that 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 qosPolicyPRTrfcProf DERIVED FROM gpsPolicyTrfcProf ABSTRACT False PROPERTIES qpPRRate, qpPRNormalBurst, qpPRExcessBurst Snir, Ramberg, Strassner, Cohen expires May 2001 95 Draft-ietf-policy-qos-info-model-02.txt November 2000 8.22.1. The Property qpPRRate This is a non-negative integer that defines the token rate in kilo bits per second. A rate of zero means that all packets will be out of profile. The attribute is defined as follows: NAME qpPRRate SYNTAX Integer (must be non-negative) 8.22.2. The Property qpPRNormalBurst This attribute is an integer that defines the normal size of a burst measured in bytes. The attribute is defined as follows: NAME qpPRNormalBurst SYNTAX Integer (must be non-negative) 8.22.3. The Property qpPRExcessBurst This attribute is an integer that defines the excess size of a burst measured in bytes. The attribute is defined as follows: NAME qpPRExcessBurst SYNTAX Integer (must be non-negative) 8.23. Class qosPolicyRSVPTrfcProf This class represents an IntServ RSVP Traffic profile. Values of RSVP traffic profiles are compared against Traffic specification (TSPEC) and QoS Reservation requests (FLOWSPEC) carried in RSVP requests. Traffic profiles can be reusable objects or ad-hoc. The class definition is as follows: NAME qosPolicyRSVPTrfcProf DERIVED FROM policy (defined in [PCIM]) ABSTRACT False PROPERTIES qpRSVPTokenRate, qpRSVPPeakRate, qpRSVPBucketSize, qpRSVPResvRate, qpRSVPResvSlack, qpRSVPSessionNum, qpMinPolicedUnit, qpMaxPktSize 8.23.1. The Property qpRSVPTokenRate This property is a non-negative integer that defines the token rate parameter, measured in kilo bits per second. The attribute is defined as follows: NAME qpRSVPTokenRate SYNTAX Integer (must be non-negative) Snir, Ramberg, Strassner, Cohen expires May 2001 96 Draft-ietf-policy-qos-info-model-02.txt November 2000 8.23.2. The Property qpRSVPPeakRate This property is a non-negative integer that defines the peak rate parameter, measured in kilo bits per second. The attribute is defined as follows: NAME qpRSVPPeakRate SYNTAX Integer (must be non-negative) 8.23.3. The Property qpRSVPBucketSize This property is a non-negative integer that defines the token bucket size parameter, measured in bytes. The attribute is defined as follows: NAME qpRSVPBucketSize SYNTAX Integer (must be non-negative) 8.23.4. The Property qpRSVPResvRate This property is a non-negative integer that defines the RSVP rate (R- Spec) in the RSVP Guaranteed service reservation. It is measured in Kilo bits per second. The attribute is defined as follows: NAME qpRSVPResvRate SYNTAX Integer (must be non-negative) 8.23.5. The Property qpRSVPResvSlack This property is a non-negative integer that defines the RSVP slack term in the RSVP Guaranteed service reservation. It is measured in microseconds. The attribute is defined as follows: NAME qpRSVPResvSlack SYNTAX Integer (must be non-negative) 8.23.6. The Property qpRSVPSessionNum This property is a non-negative integer that defines the total number of allowed RSVP sessions that can be active at any given time. The attribute is defined as follows: NAME qpRSVPSessionNum SYNTAX Integer (must be non-negative) Snir, Ramberg, Strassner, Cohen expires May 2001 97 Draft-ietf-policy-qos-info-model-02.txt November 2000 8.23.7. The Property qpMinPolicedUnit This property is a non-negative integer that defines the minimum RSVP policed unit, measure in bytes. The attribute is defined as follows: NAME qpMinPolicedUnit SYNTAX Integer (must be non-negative) 8.23.8. The Property qpMaxPktSize This property is a non-negative integer that defines the maximum allowed packet size for RSVP messages, measure in bytes. The attribute is defined as follows: NAME qpMaxPktSize SYNTAX Integer (must be non-negative) 8.24. Class gpsPolicySimpleCondition A simple condition is composed of an ordered triplet: <Variable> <Operator> <Value> The operator used in all condition definitions in this draft is the 'match' operator. Such simple conditions are evaluated by answering the question: Does <variable> match <value>? The operator property can be extended to support other relations between variable and values. Simple conditions are building blocks for more complex Boolean conditions. The gpsPolicySimpleCondition class is derived from the PolicyCondition class [PCIM]. Simple conditions can be kept in repositories for reuse. A variable and a value must be associated with a simple condition to make it a meaningful condition, using the aggregations PolicyVariableInPolicySimpleCondition and PolicyValueInPolicySimpleCondition The class definition is as follows: NAME gpsPolicySimpleCondition DERIVED FROM PolicyCondition (defined in [PCIM]) ABSTRACT False PROPERTIES gpOperator Snir, Ramberg, Strassner, Cohen expires May 2001 98 Draft-ietf-policy-qos-info-model-01.txt November 2000 8.24.1. The Property gpOperator This property is an enumerated integer that defines the relation between a variable and a value. The default value is match, which has the semantics of 'belong to' or 'equal'. Applications can extend this property to represent the specific type of relation that they are using to test whether the condition is true or not. The attribute is defined as follows: NAME gpOperator SYNTAX Integer - ENUM {0=Match} DEFAULT VALUE 'match' 8.25. Class gpsPolicyCompoundCondition The gpsPolicyCompoundCondition class is used to represent a Boolean expression consisting of a set of policyConditions. As such, it can be used to define traffic filters. The gpsPolicyCompoundCondition class is linked to either a PolicyRule or a PolicyRepository using the PolicyConditionInPolicyRule and PolicyConditionInPolicyRepository associations, respectively. Compound conditions are constructed using the PolicyConditionInCompoundCondition association. The class definition is as follows: NAME gpsPolicyCompoundCondition DERIVED FROM PolicyCondition (defined in [PCIM]) ABSTRACT False PROPERTIES gpPolicyConditionListType 8.25.1. The Property qpPolicyeConditionListType The qpPolicyRuleConditionListType indicates whether the list of policy conditions associated with this policy rule is in disjunctive normal form (DNF) or conjunctive normal form (CNF). Defined values are DNF(1) and CNF(2). The attribute qpPolicyRuleConditionListType is defined to be identical as the policyRuleConditionListType property of PolicyRule PCIM. The attribute is defined as follows: NAME 'policyConditionListType' SYNTAX INTEGER (ENUM) - {1=DNF, 2=CNF} DEFAULT VALUE: 1 (DNF) Snir, Ramberg, Strassner, Cohen expires May 2001 99 Draft-ietf-policy-qos-info-model-02.txt November 2000 8.26. Class gpsPolicyVariable Variables are used for building individual conditions. The variable specifies the property of a flow that should be matched when evaluating the condition. However, not every combination of a variable and a value creates a meaningful condition. For example, a source IP address variable can not be matched against a value that specifies a port number. A given variable selects the set of matchable value types. A variable can have constraints that limit the set of values within a particular value type that can be matched against it in a condition. For example, a source-port variable limits the set of values to represent integers to the range of 0-65535. Integers outside this range can not be matched to the source-port variable, even though they are of the correct data type. Constraints for a given variable are indicated through the PolicyValueConstraintsInVariable association. The class definition is as follows: NAME gpsPolicyVariable DERIVED FROM policy (defined in [PCIM]) ABSTRACT False PROPERTIES gpVariableName, gpValueTypes, gpVariableDescription, 8.26.1. The Property gpVariableName This property is a string that provides a unique name for the variable. This is very important, because the QPIM defines a correlation between its pre-defined variable names and their logical bindings. This correlation was defined earlier in Table 2. The attribute is defined as follows: NAME gpVariableName SYNTAX String, whose values are defined in table 2 8.26.2 The Property gpValueTypes This property is a string that specifies an unordered list of possible value types that can be used in a simple condition together with this variable. The value types are specified by their class names. The list of class names enables an application to search for a specific set of class names, as well as ensure that the data type of the value is of the correct type. The list of class names was defined earlier in Table 2. The list of default qpValueTypes for each Variable is defined earlier in Table 3. The attribute is defined as follows: NAME gpValueTypes SYNTAX String Snir, Ramberg, Strassner, Cohen expires May 2001 100 Draft-ietf-policy-qos-info-model-02.txt November 2000 8.26.2. The Property gpVariableDescription This property is a string that provides a textual description of the variable. The attribute is defined as follows: NAME gpVariableDescription SYNTAX String 8.27. Class gpsPolicyValue This is an abstract class that serves as the base class for all subclasses that are used to define value objects in the QPIM. It is used for defining values and constants used in policy conditions. The class definition is as follows: NAME gpsPolicyValue DERIVED FROM policy (defined in [PCIM]) ABSTRACT True PROPERTIES 8.28. Class gpsPolicyIPv4AddrValue This class is used to provide a list of IPv4Addresses, hostnames and address range values to be matched against in a policy condition. The class definition is as follows: NAME gpsPolicyIPv4AddrValue DERIVED FROM gpsPolicyValue ABSTRACT False PROPERTIES gpIPv4AddrList 8.28.1. The Property gpIPv4AddrList This Property provides an unordered list of strings, each specifying a single IPv4 address, a hostname, or a range of IPv4 addresses, according to the ABNF definition [ABNF] of an IPv4 address as specified below: IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT IPv4prefix = IPv4address "/" 1*2DIGIT IPv4range = IPv4address"-"IPv4address IPv4maskedaddress = IPv4address","IPv4address Hostname (as defined in [NAMES]) In the above definition, each string entry is either: 1. A single Ipv4address in dot notation as defined above. Example: 121.1.1.2 Snir, Ramberg, Strassner, Cohen expires May 2001 101 Draft-ietf-policy-qos-info-model-02.txt November 2000 2. A single Hostname. Hostname format follows the guidelines and restrictions specified in [NAMES]. Example: www.bigcompany.com 3. An IPv4range address range defined above, specified by a start address in dot notation and an end address in dot notation, separated by "-". The range includes all addresses between the range's start and end addresses, including the start and end addresses. Example: 1.1.22.1-1.1.22.5 4. An IPv4maskedaddress address range defined above, specified by an address and mask. The address and mask are represented in dot notation separated by a comma ",". Example: 2.3.128.0,255.255.248.0. 5. An IPv4prefix address range defined above specified by an address and a prefix length separated by "/". Example: 2.3.128.0/15 The class definition is as follows: NAME gpIPv4AddrList SYNTAX String FORMAT IPv4address | hostname | IPv4addressrange | IPv4maskedaddress | IPv4prefix 8.29. Class gpsPolicyIPv6AddrValue This class is used to define a list of IPv6 addresses, hostnames, and address range values. The class definition is as follows: NAME gpsPolicyIPv6AddrValue DERIVED FROM gpsPolicyValue ABSTRACT False PROPERTIES gpIPv6AddrList 8.29.1. The Property gpIPv6AddrList This property provides an unordered list of strings, each specifying an IPv6 address, a hostname, or a range of IPv6 addresses. IPv6 address format definition uses the standard address format defined in [IPv6]. The ABNF definition [ABNF] as specified in [IPv6] is: IPv6address = hexpart [ ":" IPv4address ] IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT IPv6prefix = hexpart "/" 1*2DIGIT hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ] hexseq = hex4 *( ":" hex4) hex4 = 1*4HEXDIG IPv6range = IPv6address"-"IPv6address Snir, Ramberg, Strassner, Cohen expires May 2001 102 Draft-ietf-policy-qos-info-model-02.txt November 2000 IPv6maskedaddress = IPv6address","IPv6address Hostname (as defines in [NAMES]) Each string entry is either: 1. A single IPv6address as defined above. 2. A single Hostname. Hostname format follows guidelines and restrictions specified in [NAMES]. 3. An IPv6range address range, specified by a start address in dot notation and an end address in dot notation, separated by "-". The range includes all addresses between the range's start and end addresses, including the start and end addresses. 4. An IPv4maskedaddress address range defined above specified by an address and mask. The address and mask are represented in dot notation separated by a comma ",". 5. A single IPv6prefix as defined above. NAME gpIPv6AddrList SYNTAX String FORMAT IPv6address | hostname | IPv6addressrange | IPv6maskedaddress | IPv6prefix 8.30. Class gpsPolicyMACAddrValue This class is used to define a list of MAC addresses and MAC address range values. The class definition is as follows: NAME gpsPolicyMACAddrValue DERIVED FROM gpsPolicyValue ABSTRACT False PROPERTIES gpMACAddrList 8.30.1. The Property gpMACAddrList This property provides an unordered list of strings, each specifying a MAC address or a range of MAC addresses. The 802 MAC address canonical format is used. The ABNF definition [ABNF] is: MACaddress = 1*4HEXDIG ":" 1*4HEXDIG ":" 1*4HEXDIG MACmaskedaddress = MACaddress","MACaddress Each string entry is either: 1. A single MAC address. Example: 0000:00A5:0000 2. A MACmaskedaddress address range defined specified by an address and mask. The mask specifies the relevant bits in the address. Example: 0000:00A5:0000, FFFF:FFFF:0000 defines a range of MAC addresses in which the first 4 8-bit bytes are equal to 0000:00A5. Snir, Ramberg, Strassner, Cohen expires May 2001 103 Draft-ietf-policy-qos-info-model-01.txt November 2000 NAME gpMACAddrList SYNTAX String FORMAT MACaddress | MACmaskedaddress 8.31. Class gpsPolicyStringValue This class is used to represent a single or set of string values. Each can have wildcards. The class definition is as follows: NAME gpsPolicyStringValue DERIVED FROM gpsPolicyValue ABSTRACT False PROPERTIES gpStringList 8.31.1. The Property gpStringList This property provides an unordered list of strings, each representing a single string with wildcards. The asterisk character "*" is used as a wildcard, and represents an arbitrary sub-string replacement. For example, the value "abc*def" match "abcxyzdef", and the value "abc*def*" match "abcxxxdefyyyzzz". The syntax definition is identical to the substring assertion syntax defined in [LDAP_ATTR]. If the asterisk character is required as part of the string value itself, it MUST be quoted as described in section 4.3 of [LDAP_ATTR]. The attribute definition is as follows: NAME gpStringList SYNTAX String 8.32 Class gpsPolicyBitStringValue This class is used to represent a single or set of bit string values. The class definition is as follows: NAME gpsPolicyBitStringValue DERIVED FROM gpsPolicyValue ABSTRACT False PROPERTIES gpBitStringList 8.32.1. The Property gpBitStringList This property provides an unordered list of strings, each representing a single bit string or a set of bit strings. The number of bits specified SHOULD equal the number of bits of the expected variable. For example, for an 8-bit byte variable, 8 bits should be specified. If the variable does not have a fixed length, the bit string should be matched against the variable most significant bit string. The formal definition of a bit string is: Snir, Ramberg, Strassner, Cohen expires May 2001 104 Draft-ietf-policy-qos-info-model-01.txt November 2000 binary-digit = "0" / "1" bitstring = 1*binary-digit maskedBitString = bitstring","bitstring Each string entry is either: 1. A single bit string. Example: 00111010 2. A range of bit strings specifies using a bit string and a bit mask. The bit string and mask properties have the same number of bits specified. The mask bit string specifies the significant bits in the bit string value. For example, 110110, 100110 and 110111 would match the maskedBitString 100110,101110 but 100100 would not. NAME gpBitStringList SYNTAX String FORMAT bitString | maskedBitString 8.33. Class gpsPolicyDNValue This class is used to represent a single or set of Distinguished Name [DNDEF] values, including wildcards. This value type is specifically defined for an LDAP based implementation of this information model. 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 [IDENT]. The class definition is as follows: NAME gpsPolicyDNValue DERIVED FROM gpsPolicyValue ABSTRACT False PROPERTIES qpDNList 8.33.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: Snir, Ramberg, Strassner, Cohen expires May 2001 105 Draft-ietf-policy-qos-info-model-01.txt November 2000 NAME qpDNList SYNTAX List of Distinguished Names implemented as strings, each of which serves as a reference to another object. 8.34. Class gpsPolicyAttributeValue 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 [IDENT]. 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". An 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. The class definition is as follows: NAME gpsPolicyAttributeValue DERIVED FROM gpsPolicyValue ABSTRACT False PROPERTIES gpAttributeName, gpAttributeValueList 8.34.1. The Property gpAttributeName This attribute defines the name of the property that the list of values should be compared against. The attribute is defined as follows: NAME gpAttributeName SYNTAX String 8.34.2. The Property gpAttributeValueList This attribute contains a list of property values. Each value is compared to a value of the property specified by gpAttributeName. The attribute is defined as follows: NAME gpAttributeValueList SYNTAX String Snir, Ramberg, Strassner, Cohen expires May 2001 106 Draft-ietf-policy-qos-info-model-02.txt November 2000 8.35. Class gpsPolicyIntegerValue This class provides a list of integer and integer range values. Integers of arbitrary sizes can be represented. For a given variable, the set of possible ranges of integer values allowed is specified via the variable's gpValueConstraints Property. The class definition is as follows: NAME gpsPolicyIntegerValue DERIVED FROM gpsPolicyValue ABSTRACT False PROPERTIES gpIntegerList 8.35.1. The Property gpIntegerList This property provides an unordered list of integers and integer range values. The format of this property can take on of the following forms: 1. An integer value. 2. A range of integers. The range is specifies by a start integer and an end integer separated by "-". The range includes all integers between start and end integers, including the start and end integers. To represent a range of integers that is not bounded, the reserved word INFINITY can be used as the end range integer. The ABNF definition [ABNF] is: integer = 1*DIGIT | "INFINITY" integerrange = integer"-"integer Using ranges, the operators greater-than, greater-than-or-equal-to, less-than and less-than-or-equal-to can be expressed. This enables the match condition semantics of the gpOperator property of the gpsPolicySimpleCondition class to be kept simple (i.e., just the value "match"). The attribute is defined as follows. NAME gpIntegerList SYNTAX String FORMAT integer | integerrange Snir, Ramberg, Strassner, Cohen expires May 2001 107 Draft-ietf-policy-qos-info-model-01.txt November 2000 8.36 Class gpsPolicyMeter This class models a meter. Within provisioning actions, meters measure the temporal properties of the stream of packets selected by a classifier against a traffic profile. Within Signaling policies, meters measure the temporal resource allocations for flows matching a rule's condition. A traffic profile is associated to a meter using the PolicyTrfcProfileInMeter association. A meter can be shared between different policy rules. A meter shared by more than one policy rule resides in a repository and is referenced by all sharing rules. A meter is associated with an action using the PolicyMeterInAction association. The class is defined as follows: NAME gpsPolicyMeter DERIVED FROM policy (defined in [PCIM]) ABSTRACT True PROPERTIES gpMeterScope, gpMeterTimeInterval 8.36.1. The Property gpMeterScope This property is an enumerated integer that defines whether this metering action should be applied on a per-flow, per-interface, per-role within a device, per device or per role across all devices. The attribute is defined as follows: NAME gpMeterScope SYNTAX Integer (ENUM) {flow=0,interface=1 role-in-device=2, device=3, role=4} 8.36.2. The Property gpMeterTimeInterval This optional property specifies the time interval used to measure traffic in microseconds. The attribute is defined as follows: NAME gpMeterTimeInterval SYNTAX Integer Snir, Ramberg, Strassner, Cohen expires May 2001 108 Draft-ietf-policy-qos-info-model-02.txt November 2000 8.37 Class qosPolicyQueue This class models a sharable queue used by more than one policy rule. A set of actions defining PHBs may be associated to the same queue object using the PolicyQueueInPHBAction association to indicate that they belong to the same PHB group. Bandwidth and Delay attributes are than managed for the entire PHB group in a single place. The class is defined as follows: NAME qosPolicyQueue DERIVED FROM policy (defined in [PCIM]) ABSTRACT True PROPERTIES qpForwardingPriority, qpBandwidthValueType, qpMinBandwidth, qpMaxBandwidth, qpMaxDelay, qpMaxJitter, qpFairQueue 8.37.1. The Property qpForwardingPriority This property defines the forwarding priority that should be given to this set of flows. A non zero value indicate that preemptive forwarding should be provided to the class of traffic. Higher values represent higher forwarding priority. The attribute is defined as follows. NAME qpForwardingPriority SYNTAX Integer 8.37.2. The Property qpBandwidthValueType 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. The attribute is defined as follows. NAME qpBandwidthValueType SYNTAX Integer {ENUM} - {bits/sec=0, percentage=1} 8.37.3. The Property qpMinBandwidth This property defines the minimal bandwidth that should be reserved to this class of traffic. Both relative and absolute values can be specified according to the value qpBandwidthValueType property. The attribute is defined as follows. NAME qpMinBandwidth SYNTAX Integer Snir, Ramberg, Strassner, Cohen expires May 2001 109 Draft-ietf-policy-qos-info-model-02.txt November 2000 8.37.4. The Property qpMaxBandwidth This property defines the maximal bandwidth that should be allocated to this class of traffic. Both relative and absolute values can be specified according to the value qpBandwidthValueType property. The attribute is defined as follows. NAME qpMaxBandwidth SYNTAX Integer 8.37.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 maximal delay is measured in milliseconds. The attribute is defined as follows. NAME qpMaxDelay SYNTAX Integer (milliseconds) 8.37.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 maximal jitter is measured in milliseconds. The attribute is defined as follows. NAME qpMaxJitter SYNTAX Integer (milliseconds) 8.37.7 The Property qpPacketSize This property defines a typical packet size for this class of traffic. This property is used to translate threshold values specified in packets to bytes and vice versa. NAME qpPacketSize SYNTAX Integer 8.37.8 The Property qpFairQueue This property defines whether fair queuing is required for this class of traffic. The attribute is defined as follows. NAME qpFairQueue SYNTAX Integer {Boolean} - {FALSE=0, TRUE=1} Snir, Ramberg, Strassner, Cohen expires May 2001 110 Draft-ietf-policy-qos-info-model-01.txt November 2000 9. Extending the QoS Policy Schema The following subsections provide general guidance on how to create a domain-specific information model derived from the QPIM by extending the QoS policy classes. 9.1. Extending gpsPolicyValue The gpsPolicyValue class and its subclasses describe the common value types used in the QPIM. When other specific types are required, such as a floating-point numbers, the required class SHOULD be derived from the gpsPolicyValue class and properties that contain the corresponding values SHOULD be added. Notice that in many cases, using the gpsPolicyAttributeValue class allows the definition of non-standard policy atoms without extending the gpsPolicyValue class. 9.2. Extending gpsPolicySimpleCondition The gpsPolicySimpleCondition class is used to describe a single atomic Boolean condition. For Boolean conditions that are not structured as the ordered triple <variable - relation - value>, a new type of condition class SHOULD be defined. An example would be a unary condition. Subclassing could be done using either the policyCondition or gpsPolicySimpleCondition classes as the superclass. 9.3. Extending qosPolicyAction The Qos Policy actions classes defined in the QoS Policy Schema Includes the following types of actions: Provisioning actions: * Marking * Policing, shaping and remarking according to a traffic profile Signaling RSVP action: * RSVP policy admission * RSVP signal control extensions * RSVP flow control extensions Additional actions could be associated with QoS policy rules by extending the policyAction class with the appropriate properties. Snir, Ramberg, Strassner, Cohen expires May 2001 111 Draft-ietf-policy-qos-info-model-01.txt November 2000 10. Security Considerations The security considerations for this document are the same as those of the [PCIM]. 11. Editorial information <this section will be removed before publication> Changes from the previous version: 1. Some of the classes defined in QPIM are intended for usage outside the scope of QoS domain. The concept of conditions as building blocks of filters, the basic condition structure of <variable operator value>, the concept of variable binding and the concept of variable to value relationship are valuable to domains out side QoS policy. In order to allow more natural usage of these concept in other domains, the relevant classes prefix was changed from qosPolicyXXX to gpsPolicyXXX and properties prefix was changed from qpPolicyXXX to gpPolicy ,i.e., general policy XXX. 2. The notion of a class representing a filter or a Boolean expression made of policy conditions, that could also serve as a reusable filter was added. The class gpsPolicyCompoundCondition allows the definition of a flexible reusable filter, leveraging the mechanism defined in CPIM for associating policy conditions to a policy rule . 3. This draft was updated to be compatible with the latest PCIM draft. 4. PHB Actions added to allow full coverage of the QoS policy model required for definition of policies for a differential service domain. References to external PHB definitions removed. 5. Alignment between policy definition of QPIM and low level PIB / MIB Was illustrated. 6. Reuse of Policy groups and their QPIM extensions, gpsPolicyGroups and Policy rules were explained and examples were added. 7. Role usage in the context of QoS policy was explained. No new concepts were introduced. Role were also defined per gpsPolicyGroups. 8. Change gpsPolicyMeter to include a traffic profile and scope. The previous way of binding the meter the traffic profile and a scope using a provisioning action could lead to inconsistencies if not used properly (Bob). 9. Clarification of the use of gpValueTypes property of values and the meaning of table 3 (Bob). 10. Rewriting the draft in a storage independent way. The previous draft was not general enough. Added appropriate association and aggregations and removed references from objects. Changed text appropriately. 11. qpsNamedPolicyContainer class name was changes to gpsPolicyGroup to allow for usage outside the scope of QoS domain Snir, Ramberg, Strassner, Cohen expires May 2001 112 Draft-ietf-policy-qos-info-model-02.txt November 2000 12. Acknowledgments 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. 13. References [PCIM] J. Strassner, E. Ellesson, B. Moore, "Policy Framework Core Information Model", Internet Draft <draft-ietf-policy-core-info-model-05.txt> [PFSCHEMA] J. Strassner, E. Ellesson, B. Moore, "Policy Framework LDAP Core Schema", Internet Draft <draft-ietf-policy-core-schema-06.txt> [QOSSCHEMA] Y. Snir, Y Ramberg, J. Strassner, R. Cohen, "QoS Policy Schema", Internet Draft <draft-ietf-policy-qos-schema-01.txt> [DIFF-SERV-ARCH] S. Blake et al, "An Architecture for Differentiated Services", RFC2475 [EF] V. Jacobson, K. Nichols, K. Poduri, " An Expedited Forwarding PHB", RFC2598, September 1999 [AF] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured Forwarding PHB Group", RFC2597, September 1999 [DIFF-MIB] F. Baker, K. Chan, A. Smith "Management Information Base for the Differentiated Services Architecture", draft-ietf-diffserv-mib-05.txt, November 2000 [PIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, A. Smith, "Quality of Service Policy Information Base", Internet Draft <draft-mfine-cops-pib-01.txt> [RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) - Functional Specification.", IETF RFC 2205, Proposed Standard, Sep. 1997. [RSVP-IS] J. Wroclawski, "The Use of RSVP with IETF Integrated Services", RFC2210, September 1997 [GS] S. Shenker, C. Partridge, R. Guerin, "Specification of the Guaranteed Quality of Service", RFC2212, September 1997 Snir, Ramberg, Strassner, Cohen expires May 2001 113 Draft-ietf-policy-qos-info-model-01.txt November 2000 [CL] J. Wroclawski, "Specification of the Controlled-Load Network Element Service", RFC2211, September 1997 [RSVP_PREEMP] Shai Herzog, "Signaled Preemption Priority Policy Element", RFC2751 [IDNET] S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, S. Herzog, "Identity Representation for RSVP", RFC 2752, January 2000 [COPS] D. Durham, J. Boyle, R . Cohen, S. Herzog, R. Rajan, A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC2748 [COPSRSVP] S. Herzog, J. Boyle, R . Cohen, D. Durham, R. Rajan, A. Sastry, "COPS Usage for RSVP", RFC2749 [IPv6] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", RFC2373, July 1998 [NAME] P. Mockapetris, " Domain names - implementation and specification", RFC1035 [ABNF] Crocker, D., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [DNDEF] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997. [DEREF] R. Moats, J. Maziarski, J. Strassner, "Extensible Match Rules to Dereference Pointer", Internet Draft <draft-moats-ldap-dereference-match-02.txt> [LDAP_ATTR] M. Wahl, A. Coulbeck, " Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252 [TERMS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", Internet RFC 2119, March 1997. Snir, Ramberg, Strassner, Cohen expires May 2001 114 Draft-ietf-policy-qos-info-model-01.txt November 2000 14. Author's Addresses 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 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 John Strassner Cisco Systems Bldg 15 170 West Tasman Drive San Jose, CA 95134 Phone: +1-408-527-1069 Fax: +1-408-527-2477 E-mail: johns@cisco.com Ron Cohen Cisco Systems 4 Maskit Street Herzliya Pituach, Israel 46766 Phone: +972-9-970-0064 Fax: +972-9-970-0219 E-mail: ronc@cisco.com 15. Full Copyright Statement This document and translations of it be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation 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 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 PROPERTIES be followed, or as required to translate it into languages other than English. Snir, Ramberg, Strassner, Cohen expires May 2001 115 Draft-ietf-policy-qos-info-model-01.txt November 2000 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 May 2001 116
Datatracker
Report a datatracker bug
draft-ietf-policy-qos-info-model-02
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 3644.
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |