Policy Framework Y. Snir Internet Draft Y. Ramberg Expires April 2000 J. Strassner draft-ietf-policy-qos-info-model-01.txt R. Cohen 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 refines the core policy information model presented in [PCIM]. Specifically, this draft refines the concept of generic policy rules, conditions and actions to cover extensions necessary for representing 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 repository and access protocol. A companion document [QoSSCHEMA] defines the mapping of these classes to a directory that uses LDAPv3 as its access protocol. A second companion document [QOSDEV] supplies low- level definitions of QoS mechanisms that are controlled by this document. Snir, Ramberg, Strassner, Cohen expires October 2000 1 Draft-ietf-policy-qos-info-model-01.txt April 2000 Table of Contents 1. Introduction 5 1.1 Goals 5 1.2 Approach and Related Documents 5 2. Information Model Hierarchy 6 2.1 Interaction Between the PCIM and This Document 7 2.1.1 Extension of Concepts in the PCIM 7 2.1.2 Addition of New Concepts Not in the PCIM 7 2.2 High-Level Class Hierarchy 8 3. Containment Hierarchy 11 3.1. Containment Model 11 3.2. QoS Domain Containment Hierarchy 12 3.2.1. Domain Grouping and Nesting 13 3.2.2. Resource Sharing 15 3.2.3. Placement 15 3.2.4. Named Policy Containers 16 3.2.5. Policy Rules 17 3.2.6. Conditions and Actions 18 3.2.7. Data Tree Example 19 3.3. Reusable-Object Repositories 19 3.4. Relationships Between QoS Domains and Repositories 20 4. Constructing a QoS Policy Rule 21 4.1 Policy Rule Structure 21 4.2 QoS Policy Conditions 22 4.2.1 Reusable vs. Ad-Hoc Conditions 23 4.2.2. Using Simple Conditions 24 4.2.3. Composing Complex Conditions 24 4.3 Simple Condition Operator 25 4.4. QoS Policy Variables 25 4.4.1 Variable Binding 26 4.4.2. Pre-Defined Variables 26 4.5 QoS Policy Values 30 4.6. PolicyTimePeriodCondition 30 4.7. Actions 30 4.7.1 Provisioning Actions 31 4.7.1.1 Meters 32 4.7.1.2 Markers 32 4.7.1.3 Shapers 32 4.7.1.4 Droppers 33 4.7.1.5 Examples 33 4.7.2 Signaling Actions 34 4.8 Traffic Profiles 37 4.8.1 Provisioning Traffic Profiles 37 4.8.1 RSVP Traffic Profiles 38 5. Decision strategy 39 5.1. First match 39 5.2. Match All 39 Snir, Ramberg, Strassner, Cohen expires October 2000 2 Draft-ietf-policy-qos-info-model-01.txt April 2000 5.3. Decision Strategy example 40 5.3.1 Default Operation using First Match Everywhere 40 5.3.2 Operation Using Other Decision Strategies 41 6. Per Hop Behavior 42 6.1. PHBs 42 6.2. PHB Sets 42 7. QoS Policy Class Inheritance 43 8. Class Definitions 45 8.1. Class qosPolicyDomain 45 8.1.1. The Property qpDomainName 45 8.1.2. The Property qpPHBSet 45 8.1.3. The Property qpPolicyRuleMatchMethod 45 8.2. Class qosNamedPolicyContainer 46 8.2.1. The Property qpPriority 46 8.2.2. The Property qpNamedPolicyRuleMatchMethod 46 8.3. Class qosPolicyPRAction 47 8.3.1. The Property qpDirection 47 8.3.2. The Property qpSetDSCPvalue 47 8.3.3. The Property qpMeter 47 8.3.4. The Property qpMeterScope 48 8.3.5. The Property qpTrfcProf 48 8.3.6. The Property qpOutOfProfileAction 48 8.3.7. The Property qpOutofProfileRemarkValue 48 8.4. Class qosPolicyRSVPAction 48 8.4.1. The Property qpRSVPDirection 49 8.4.2. The Property qpRSVPMessageType 49 8.4.3. The Property qpRSVPStyle 49 8.4.4. The Property qpRSVPServiceType 49 8.4.5. The Property qpRSVPInstallAction 50 8.4.6. The Property qpRSVPCtrlAction 50 8.4.7. The Property qpRSVPMeter 50 8.4.8. The Property qpRSVPMeterScope 50 8.4.9. The Property qpRSVPTrfcProf 51 8.5. Class qosPolicyPRTrfcProf 51 8.5.1. The Property qpPRRate 51 8.5.2. The Property qpPRNormalBurst 51 8.5.3. The Property qpPRExcessBurst 51 8.6. Class qosPolicyRSVPTrfcProf 52 8.6.1. The Property qpRSVPTokenRate 52 8.6.2. The Property qpRSVPPeakRate 52 8.6.3. The Property qpRSVPBucketSize 52 8.6.4. The Property qpRSVPResvRate 53 8.6.5. The Property qpRSVPResvSlack 53 8.6.6. The Property qpRSVPSessionNum 53 8.6.7. The Property qpMinPolicedUnit 53 8.6.8. The Property qpMaxPktSize 53 8.7. Class qosPolicyRSVPSignalCtrlAction 54 8.7.1. The Property qpForwardingMode 54 8.7.2. The Property qpSendError 54 Snir, Ramberg, Strassner, Cohen expires October 2000 3 Draft-ietf-policy-qos-info-model-01.txt April 2000 8.7.3. The Property qpReplaceDSCP 55 8.7.4. The Property qpReplacePreemptionPriority 55 8.7.5. The Property qpReplaceDefendingPriority 55 8.8. Class qosPolicyRSVPInstallAction 55 8.8.1. The Property qpSetDSCPValue 56 8.8.2. The Property qpSetDefendingPriority 56 8.8.3. The Property qpSetPreemptionPriority 56 8.9. Class qosPolicySimpleCondition 56 8.9.1. The Property qpOperator 57 8.9.2. The Property qpVariableAtom 57 8.9.3. The Property qpValueAtom 57 8.10. Class qosPolicyVariable 57 8.10.1. The Property qpVariableName 58 8.10.2 The Property qpValueTypes 58 8.10.3. The Property qpVariableDescription 58 8.10.4. The Property qpValueConstraints 59 8.11. Class qosPolicyValue 59 8.12. Class qosPolicyIPv4AddrValue 59 8.12.1. The Property qpIPv4AddrList 59 8.13. Class qosPolicyIPv6AddrValue 60 8.13.1. The Property qpIPv6AddrList 60 8.14. Class qosPolicyMACAddrValue 61 8.14.1. The Property qpMACAddrList 61 8.15. Class qosPolicyStringValue 62 8.15.1. The Property qpStringList 62 8.16 Class qosPolicyBitStringValue 62 8.16.1. The Property qpBitStringList 62 8.17. Class qosPolicyDNValue 63 8.17.1. The Property qpDNList 63 8.18. Class qosPolicyAttributeValue 63 8.18.1. The Property qpAttributeName 64 8.18.2. The Property qpAttributeValueList 64 8.19. Class qosPolicyIntegerValue 64 8.19.1. The Property qpIntegerList 65 8.20. Class qosPolicyPHBSet 65 8.21. Class qosPolicyPHB 65 8.21.1. The Property qpDSCP 66 8.22. Class qosPolicyMeter 66 9. Extending the QoS Policy Schema 67 9.1. Extending qosPolicyValue 67 9.2. Extending qosPolicySimpleCondition 67 9.3. Extending qosPolicyAction 67 10. Security Considerations 68 11. Acknowledgments 68 12. References 68 13. Author's Addresses 69 14. Full Copyright Statement 70 Snir, Ramberg, Strassner, Cohen expires October 2000 4 Draft-ietf-policy-qos-info-model-01.txt April 2000 1. Introduction This document presents an object-oriented information model for representing network QoS policies. As such, it is independent of any specific repository type and access protocol. This document refines the core policy information model presented in [PCIM]. Specifically, this draft refines the concept of generic policy rules, conditions and actions to cover extensions necessary for representing QoS policies. This information model covers Differentiated Service QoS enforcement, and Integrated Service QoS enforcement via policy control on RSVP admission. A companion document [QoSSCHEMA] defines the mapping of these classes to a directory that uses LDAPv3 as its access protocol. A second companion document [QOSDEV] supplies low-level definitions of QoS mechanisms that are controlled by this document. 1.1 Goals This document presents high level QoS policies that can be used to enforce consistent behavior across a network, regardless of the actual vendor-specific implementation details. 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 by defining a set of common abstractions that can be used to build high-level QoS policies. 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. The companion document [QOSDEV] defines an information model for representing low-level QoS mechanisms. 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. Snir, Ramberg, Strassner, Cohen expires October 2000 5 Draft-ietf-policy-qos-info-model-01.txt April 2000 Representation of the inherent QoS mechanisms of devices is described in a companion draft [QOSDEV]. It provides a standard information model for representing low-level QoS mechanisms that exist in devices in a vendor-independent way. This document, augmented with the information provided in [QOSDEV], together provide a set of enforceable policies that control the QoS mechanisms on network devices. The concept of PHBs is central to Differentiated Services. An additional information model for representation of PHBs is defined in [PHBSET], and a corresponding LDAP representation is provided in [PHBLDAP]. This document is also intended to work with [PHBSET]. The remainder of this document presents, describes and defines the concepts of the QoS Policy Information Model (QPIM). Relationships to the Core schema and issues related to correct usage of the 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. 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 all use a common set of terminology, classes, and approaches, thus facilitating interoperability. The QPIM refines the concepts of the [PCIM] and introduces a framework of classes and relationships dedicated to model QoS Policies. This set of classes and relationships can be used to configure and manage devices that are IntServ- and DiffServ-compliant. The QPIM provides building blocks to control most of the policy aspects required by IntServ and DiffServ, but it is clear that not all functions are provided. It is also clear that other information models and their derived schemata can use some of the concepts in this document. For example, the concept of representing IP Addresses, as well as variables and constants, are not specific to QoS. However, this is the first information model that is derived from the [PCIM], and it is not clear that other working groups will be satisfied with these representations. These concepts will be socialized to other working groups and, if they agree with the representation in this document (or if a suitable compromise can be developed), then these concepts will be moved into a separate document. Snir, Ramberg, Strassner, Cohen expires October 2000 6 Draft-ietf-policy-qos-info-model-01.txt April 2000 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 repository 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 repository 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. 2.1 Interaction Between the PCIM and This Document This document both extends concepts that are part of the [PCIM] as well as adds new functions that are not part of the [PCIM]. 2.1.1 Extension of Concepts in the PCIM The concept of a policy repository, that is embedded within another repository that contains policy and non-policy information, was originally defined in an earlier version of the QPIM. It has subsequently been moved into the [PCIM], since it is a generic concept that is not limited to QoS, and can be used by other applications. This document defines specific refinements of the "embedded policy repository" to accommodate the application-specific needs of QoS provisioning. Similarly, the concepts of reusable- objects vs. rule-specific objects have been moved from an earlier version of this document to the [PCIM]. Equally similarly, this document defines specific extensions to guide the implementation of reusable- vs. rule-specific QoS objects. This document also extends the concept of a policy rule, along with 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, pre-defined variables and constants, and PHBs. Snir, Ramberg, Strassner, Cohen expires October 2000 7 Draft-ietf-policy-qos-info-model-01.txt April 2000 The [PCIM] defines the ability to group policy rules by defining the policyGroup class. This class has the following semantics: it can either be used to contain a set of policyRules, or a set of policyGroups, but not both. However, this simply gathers policy rules together in a common container. It does not nest policy rules. 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 the high-level rule itself. This high-level rule could consist of 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.). 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, such a decision strategy must be defined in this document because it does define nested rules. This strategy defines an ordering that can be applied to a set of policyRule and policyGroup objects within a larger context (e.g., a policy domain). This in turn controls the execution of different policy actions. This document also defines a set of variable and constant definitions for use with QoS policies. This concept is not present in the [PCIM] 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. Finally, this document adds a general structure for accommodating PHBs. PHBs are a concept that is specific to DiffServ, and thus are not defined in the [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 October 2000 8 Draft-ietf-policy-qos-info-model-01.txt April 2000 (continued from previous page) [unrooted] | +--Policy (abstract, defined in PCIM) | | | +---PolicyGroup (PCIM) | | | | | +---qosPolicyDomain (this document) | | | | | +---qosNamedPolicyContainer (this document) | | | +---PolicyRule (PCIM) | | | +---PolicyCondition (PCIM) | | | | | +---PolicyTimePeriodCondition (PCIM) | | | | | +---VendorPolicyCondition (PCIM) | | | | | +---qosPolicySimpleCondition (this document) | | | +---PolicyAction (PCIM) | | | | | +---VendorPolicyAction (PCIM) | | | | | +---qosPolicyPRAction (this document) | | | | | +---qosPolicyRSVPAction (this document) | | | | | +---qosPolicyRSVPSignalCtrlAction (this document) | | | | | +---qosPolicyRSVPInstallAction (this document) | | | | +---qosPolicyPRTrfcProf (this document) | | | +---qosPolicyRSVPTrfcProf (this document) | | | +---qosPolicyVariable (this document) | | | +---qosPolicyValue (this document) | | | | | +---qosPolicyIPv4AddrValue (this document) | | | | | +---qosPolicyIPv6AddrValue (this document) | | | | | +---qosPolicyMACAddrValue (this document) | | | | | +---qosPolicyStringValue (this document) | | | (continued on next page) Snir, Ramberg, Strassner, Cohen expires October 2000 9 Draft-ietf-policy-qos-info-model-01.txt April 2000 (continued from previous page) [unrooted] | +--Policy (abstract, defined in PCIM, repeated for convenience) | | | +---qosPolicyValue (this document, repeated for convenience) | | | | | +---qosPolicyBitStringValue (this document) | | | | | +---qosPolicyDNValue (this document) | | | | | +---qosPolicyAttributeValue (this document) | | | | | +---qosPolicyIntegerValue (this document) | | | +---qosPolicyMeter | | | +---qosPolicyPHBSet (this document) | | | +---qosPolicyPHB (this document) | | +--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) Snir, Ramberg, Strassner, Cohen expires October 2000 10 Draft-ietf-policy-qos-info-model-01.txt April 2000 3. Containment Hierarchy In this section, we describe the organization and structure of the QPIM hierarchy. The QPIM consists of two hierarchies: A policy definition hierarchy and a reusable objects repository hierarchy. A particular data tree may contain any number of instances of each hierarchy. Section 3.1 explains the containment and reference model used in the construction of QoS Policy data trees. Section 3.2 describes the particular containment hierarchy of the policy definition entity, which is modeled by the qosPolicyDomain class. Section 3.3 describes the structure of the reusable objects repository. Further down (section 3.4) we explain the relationships between those entities. 3.1. Containment Model The QPIM uses and extends the containment model of [PCIM]. The following paragraphs summarize this containment model. For more detail, please refer to [PCIM]. Conceptually, the QPIM takes the form of a tree hierarchy. To describe the hierarchy using actual instances of model data, we use the term 'data tree'. A data tree is simply an arrangement of objects in a tree structure. The data tree starts from a root object node. The data tree itself consists of leaf and non-leaf (i.e., container) nodes. The root node has one or more branch nodes that are either leaf or non-leaf nodes. The tree construction involves placing objects as leaves of other objects while maintaining a strict tree structure. The basic mechanism used for expressing containment 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. Certain elements of the QPIM need a mechanism for an entity to reference objects in a different tree in the containment hierarchy than the tree in which the referencing entity exists. For example, the class policyRule (defined in [PCIM]) is a container of conditions and actions (policyCondition and policyAction classes, defined in [PCIM], or their subclasses, such as those defined in this document). However, the information model should allow the formation of (complex) conditions (and actions), where some of the condition's (and/or actionÆs) components are referenced remotely. An example of such a remote reference is a reusable condition or a reusable action. Such reusable objects must be referenced remotely because they always reside in a specialized portion of the tree (in this case, in the policyRepository container) that is different from the one where the referencing rule resides. Snir, Ramberg, Strassner, Cohen expires October 2000 11 Draft-ietf-policy-qos-info-model-01.txt April 2000 To support a unified mechanism for containment of "local" and "remote" objects, [PCIM] introduces the notion of association and aggregation classes. These classes denote some type of dependency relationship that exists between the classes that they are connecting. One type of dependency that can be represented is, of course, containment. [PCIM] recommends that associations and aggregations are also implemented as classes. With respect to containment, an association class represents the act of containment itself. For example, the PolicyConditionInPolicyRule aggregation (defined in [PCIM]) defines that zero or more policy conditions are contained in a given policy rule. In general, containment may be direct or indirect. Direct containment means that when the association or aggregation is instantiated in a repository, the child object will be directly scoped by the container object. Indirect containment means that when the association or aggregation is instantiated in a repository, the child object will instead be referenced by the container object. As an example, if the target repository is a directory, then direct containment is implemented by instantiating the child object as a child node of a container. Similarly, indirect containment would be implemented using an attribute that is a DN (i.e., the DN points to another object). The association classes can (and do) carry the added semantics needed by the information model. For example, internal order of contained objects is information that can be carried on the association objects themselves. This makes the containment model more flexible, since the same object may be used by two containers in different parts of the containment tree. Containment is implemented differently in different data stores. Therefore, the containment tree that is being described is not expressed directly in the information model. Rather, the information model specifies classes and relationships that are used to model entities and relationships between entities that are represented in the containment data model. A mapping of the data specified in an information model to a form that is repository-dependent must also be specified. This is what [PFSCHEMA] and [QOSSCHEMA] do for the [PCIM] and this document, respectively. Please refer to [PCIM] for more information on the details of the association and aggregation class mechanisms. 3.2. QoS Domain Containment Hierarchy The entity that represents a single policy hierarchy is called QOS Domain and is modeled by the qosDomain class, which is a derivative of the PolicyGroup class in [PCIM]. Snir, Ramberg, Strassner, Cohen expires October 2000 12 Draft-ietf-policy-qos-info-model-01.txt April 2000 Figure 1 shows a summary view of the QoS domain containment hierarchy. The text in parenthesis denotes object containment style: either through placement in the data tree (i.e., using a class to form a container in a specific place in the data tree) or indirectly through association or aggregation classes. +---------------+ |qosPolicyDomain| (root) +---------------+ | | +-----------------------+ -->|qosNamedPolicyContainer| (placement) +-----------------------+ | | +----------+ -->|policyRule| (placement) +----------+ | | +------------------------+ |-->|qosPolicySimpleCondition| (via association) | +------------------------+ | | +---------------+ -->|qosPolicyAction| (via association) +---------------+ Figure 1: Qos Domain containment hierarchy 3.2.1. Domain Grouping and Nesting QoS policy domains may be grouped together to model multi-domain systems. Here, a domain is a contiguous set of nodes that operate under a common system of administration and provide a common set of services. Grouping may be desired to enhance various administrative tasks, or it may be required by a particular policy application. The grouping strategy (as well as all location-oriented strategies) is left for users/vendors to model based on their unique situations and requirements. This document presents guidelines and recommendations for grouping QoS domains, but specific implementations may use other techniques without violating the integrity and consistency of the QPIM. One way to group QoS policy domains is by creating a common root 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. In this case, all that is needed is to place the appropriate number of qosPolicyDomain (defined in this document) instances under the appropriate policyGroup instance. Snir, Ramberg, Strassner, Cohen expires October 2000 13 Draft-ietf-policy-qos-info-model-01.txt April 2000 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 of qosPolicyDomain classes. 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 qosNamedPolicyContainer clas. The qosNamedPolicyContainer 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 qosNamedPolicyContainer), or both. +-------------+ |policyGroup | <------------------- QoS policies for an enterprise +-------------+ | | +---------------+ -->|qosPolicyDomain| <----------- QoS policies for the Sales group +---------------+ | | +---------------+ |-->|qosPolicyDomain| <-------- QoS policies for Western Sales | +---------------+ | | | | +-----------------------+ | |-->|qosNamedPolicyContainer| <--Qos Policies for group | | +-----------------------+ A within Western Region | | | | +-----------------------+ | -->|qosNamedPolicyContainer| <--Qos Policies for group | +-----------------------+ B within Western Region | | +---------------+ -->|qosPolicyDomain| <--------QoS policies for Eastern Sales +---------------+ | | +-----------------------+ |-->|qosNamedPolicyContainer| <--Qos Policies for group | +-----------------------+ C within Eastern Region | | +-----------------------+ -->|qosNamedPolicyContainer| <--Qos Policies for group +-----------------------+ D within Eastern Region Figure 2: Top-level policy data tree example Snir, Ramberg, Strassner, Cohen expires October 2000 14 Draft-ietf-policy-qos-info-model-01.txt April 2000 The modeling approach used in the previous example is but one possible strategy among many. The information model allows for arbitrary nesting of groups, thus providing the means for modeling both wide and deep hierarchies. 3.2.2. Resource Sharing Object instances residing in different parts of the containment tree are independent to 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 means of referencing reusable objects. These are objects that are placed in a special portion of the repository dedicated to this purpose. In fact, there may be multiple such repositories, each used for collecting a set of related reusable objects. In this document, we will call such repositories reusable-objects repositories. The sharing of global or common objects enhances the interoperability of various policy agents, thus serving the primary goal of this information model. Such commonly used building blocks as important conditions (policyCondition and its subclasses ) and actions (policyAction and its subclasses) 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.2.3. Placement 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. Therefore, 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.3 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 October 2000 15 Draft-ietf-policy-qos-info-model-01.txt April 2000 The only location/organizational rule that must be followed is: Each QoS policy domain must contain complete policy information, either by containment of objects or by containment of association and/or aggregation objects, that is necessary to describe that 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. 3.2.4. Named Policy Containers A QoS policy domain is a container of (named) QoS Policy Containers, as explained above. The information model class representing named QoS policy containers is the qosNamedPolicyContainer class. This class extends the policyGroup class, which is defined in [PCIM]. A (non-empty) qosNamedPolicyContainer holds an unordered list of policyRules. There are two levels of priority that the QPIM specifies that can be used to determine the order of execution of QoS policy rules. At the highest level, we can define an unordered set of policy containers, each of which has a priority attribute (called qpPriority). This property is used to order the top level of the containment hierarchy. Within a given containment level, we can then use the Priority attribute of the policyRule class to establish an order of which policy rule in a given container executes next. Figure 3 shows a simple example of the ordering process. Section 4 describes policy rules in more detail. +---------------+ |qosPolicyDomain| +---------------+ | | +--------------+ |-->|policyRule A | | | Priority=19 | | +--------------+ | | +-----------------------+ +-------------+ |-->|qosNamedPolicyContainer|--->|policyRule C | | | qpPriority=5 | | | Priority=7 | | +-----------------------+ | +-------------+ | | | +-------------+ | +-------------+ -->|policyRule B | ->|policyRule D | | Priority=3 | | Priority=2 | +-------------+ +-------------+ Figure 3. Example Ordering for a QoS Policy Decision Here, the ordering is A, then C, then D, then B. This is because the qpPriority of the qosNamedPolicyContainer is higher than B, so each of its contained rules are executed (in order) before B. Snir, Ramberg, Strassner, Cohen expires October 2000 16 Draft-ietf-policy-qos-info-model-01.txt April 2000 As implied by the class name, each instance of the qosPolicyNamedContainer class MUST be assigned a name that is unique within its given QoS policy domain. A given policy container must belong to (i.e.: contained in) a single QoS policy domain. Sharing of policy containers among QoS policy domains is not possible because of the dependency of the decision strategy on the relative priority within each QoS policy domain. 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. While this strategy should meet most needs, taking a slightly different approach can provide additional flexibility. This approach is illustrated by looking at how PHBs are modeled (see section 6). In this approach, a different set of PHBs can be assigned to different policy containers. This has the effect of modifying the interpretation of the same PHBs by each policy container. Each policy container is assigned a "match strategy". This is defined in the qpNamedPolicyRuleMatchMethod attribute of the qosPolicyNamedContainer class. This attribute defines how to interpret the order of the QoS policy rules that it contains. For example, a FirstMatch strategy means that the rules will be "matched" according to ascending order of their Priority attribute. Decision strategies are explained in section 5. Policy container can be nested. A policy container may contain policy rules (PolicyRule [PCIM]) or named policy containers. A particular data tree, then, can be constructed as a deep hierarchy, if the designers of the policy system deem it desirable. 3.2.5. Policy Rules Each qosNamedPolicyContainer holds a set of policy rules (or possibly additional policy containers, which could be policyGroups or qosNamedPolicyContainers, that contain policy rules). QoS policy rules are modeled by the [PCIM] class policyRule. The semantics of a policy rule is, in essence, a conditional imperative statement in the form 'if then '. Applying a rule means evaluating its condition and, depending on the truth value of the condition, to execute the action or do nothing. Evaluating a condition is known as 'matching the rule', an expression we'll be using in later sections of this document. Snir, Ramberg, Strassner, Cohen expires October 2000 17 Draft-ietf-policy-qos-info-model-01.txt April 2000 A given policy rule MUST belong to one (and only one) qosNamedPolicyContainer. This restriction is necessary because the units of reusability are, in reality, the policy condition and action terms that comprise a policy rule (as opposed to the policy rule itself). This is because a policy rule is a composite object, made up of several objects, but SHOULD be viewed as a coherent statement. It is believed that allowing a policy rule to belong to more than one policy container would decrease or even destroy its coherence. For example, the rule itself is "aware" of its position inside its policy container, so if we wanted to share a rule among many containers we'd have to remove this knowledge from the rule. The notion of ordering of rules is so essential to the concept of policy that removing it from the rule also renders the rule less expressive, making policy modeling a more difficult job. Furthermore, there are other important attributes that are unique to the rule's specific placement inside a policy group and/or a policy domain. For example, the DSCP values (section 6) that define how a flow is colored (which in turn define the set of QoS policy actions that should be invoked by the rule) may be interpreted differently in different QoS policy domains (or policy containers). These examples show that the modeling of shared rules is inappropriate for the QPIM. 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 qosNamedPolicyContainer object. Note that actions taken on packets may use a different mechanism. For example, a DSCP value can be set directly using the qpSetDSCPValue attribute of the qosPolicyPRAction class. However, this class could also define a set of token bucket parameters using the qpTrfcProf attribute. This references a traffic profile (represented by the qosPolicyPRTrfcProf class) that carries the policer or shaper rate values to be enforced on a flow or a set of flows. 3.2.6. Conditions and Actions A policy rule is a composite object, as mentioned above. The most important components of a rule are the conditions and actions it contains. A condition is a Boolean expression that is evaluated to see if the rule should be applied. 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). Snir, Ramberg, Strassner, Cohen expires October 2000 18 Draft-ietf-policy-qos-info-model-01.txt April 2000 3.2.7. 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 (qosPolicyDomain) 2. WestCost (qosPolicyDomain) Each of these two QoS policy domains has its own PHB set. The EastCoast domain has 2 named policy containers. The first deals only with ERP traffic and the second handles all other traffic: 1. EastCoast (qosPolicyDomain) 1.1. ERP (qosNamedPolicyContainer) 1.2. General (qosNamedPolicyContainer) The WestCoast domain has 3 named policy container. The first deals only With ERP flows, the second deals with VoIP, and the third with all other traffic: 2. WestCoast 2.1. ERP (qosNamedPolicyContainer) 2.2. VoIP (qosNamedPolicyContainer) 2.3. General (qosNamedPolicyContainer). Each one of the qosNamedPolicyContainer entries can contain a prioritized rule set. For example, the WestCoast ERP group contains the rules relevant to ERP applications administrated 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 named containers, represented by the ERP and General qosNamedPolicyContainers, can reuse common policy conditions and actions. However, they are implemented as physically different containers to enable the administrator to administrate them according to their own domain-specific needs. 3.3. 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. Snir, Ramberg, Strassner, Cohen expires October 2000 19 Draft-ietf-policy-qos-info-model-01.txt April 2000 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. 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 containment 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]. Anywhere in the QoS Policy information model, where a reference to an object can be made (a 'reference' type attribute), this reference SHOULD point to a reusable object in a reusable-object repository. Common candidates for reusability are named instances of these classes and their derivatives: - qosPolicyVariable - qosPolicyValue - qosPolicySimpleCondition - policyAction - qosPolicyMeter, QoSPolicyPRTrfcProf and QoSPolicyRSVPTrfcProf - QoSPolicyPHBSet Throughout this document, we point out the possible use of repository and repository objects, wherever this is appropriate. 3.4. 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 object that reside in reusable objects repositories. Many references to reusable objects may be made from the rules of a given QoS policy domain. Those references need not be all pointing to the same reusable-object repository; even e single rule may contain references to reusable objects that reside in different repositories. Snir, Ramberg, Strassner, Cohen expires October 2000 20 Draft-ietf-policy-qos-info-model-01.txt April 2000 The maintenance of the policy system is made somewhat more complicated due to the flexibility of the reference model. 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. 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, and providing additional features (nesting of 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 (defined in either the PolicyConditionInPolicyRule or PolicyConditionInPolicyRepository aggregation) 3. A flag indicating whether this condition is in disjunctive or conjunctive normal form 4. An (optionally ordered) list of actions (defined in either the PolicyActionInPolicyRule or PolicyActionInPolicyRepository Aggregation) 5. A priority value, defining the priority of this rule relative to other rules 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 Snir, Ramberg, Strassner, Cohen expires October 2000 21 Draft-ietf-policy-qos-info-model-01.txt April 2000 The Boolean condition is used to evaluate if the set of actions should be performed on a network flow by matching the network flow attributes against the condition. QoS-specific conditions SHOULD be formed from using either the qosPolicySimpleCondition class 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 ConditionInPolicyRule class. Each action in the list is modeled by an action derived from the PolicyAction class. The ActionInPolicyRule class 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 schema. 4.2 QoS Policy Conditions A policy rule 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 conditions or an ANDed set of ORed conditions. 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. Many conditions in policy rules, from a networking perspective, can be modeled as Filters. Filters are not modeled directly in either the QPIM or the PCIM (i.e., no Filter class is defined). However, the filter concept is central in the QoS Policy data model, and is modeled in the Network Model of DEN and used in the companion QoS Device information model draft [QOSDEV]. The semantics of an individual condition is not specified in [PCIM]. 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 October 2000 22 Draft-ietf-policy-qos-info-model-01.txt April 2000 The qosPolicySimpleCondition class models individual conditions. This class refines the basic structure of the policyCondition class defined in [PCIM] by using the triplet , and to form a condition. The variable specifies the attribute of a flow that should be matched when evaluating the condition. A set of predefined variables that cover the basic network attribute are introduced to foster interoperability. The list cover layer 3 IP attribute such as IP network addresses, protocols and ports, as well as a set of layer 2 attributes and higher level attributes such as application and user identity. The 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. Operators should model the 'belong to' and 'equal' relations in the examples above. 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 source IP address 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. 4.2.1 Reusable vs. Ad-Hoc Conditions This schema enables the reuse of simple conditions by placing them in a common portion of the policy information tree (called the reusable- object repository). In order for a simple condition to be a member of this repository, it must carry a unique name. A qosPolicySimpleCondition can either directly contain a value and a variable, or can reference either one or both of them if they are kept in a reusable-object repository. Simple condition composition must enforce the following type conformance rule: The qpValueTypes property of the variable must be compatible with the value class name. 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 by references and containment are possible: Variable representation 1. The class qosPolicyVariable may be contained in the qosPolicySimpleCondition instance. 2. The class qosPolicyVariable may be referenced from the qosPolicySimpleCondition instance (Reusable variable) Snir, Ramberg, Strassner, Cohen expires October 2000 23 Draft-ietf-policy-qos-info-model-01.txt April 2000 Value representation 1. The qosPolicyValue class may be contained in the qosPolicySimpleCondition class. 2. The qosPolicyValue class may be referenced from the qosPolicySimpleCondition instance. This allows reusing the qosPolicyValue object, which could be named and considered a named constant. 4.2.2. Using Simple Conditions In most cases, the use of the qosPolicySimpleCondition class is sufficient for the definition of a condition for a policyRule. A simple condition can be added to a policyRule in two ways: 1. A direct attachment of an instance of the condition to the ConditionInPolicyRule instance. In this case, we call this 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 referenced by any other policy rule, and therefore is not reusable. However, since it embeds the condition directly in the ConditionInPolicyRule instance, it eliminates the extra access(es) required to fetch each of the condition elements that are refernced by pointers. 2. An indirect reference to an instance of a condition that resides in a reusable-object repository. This is called a reusable condition. This method allows the sharing of conditions by multiple policy rules. 4.2.3. Composing Complex Conditions A complex condition consists of groups of simple conditions (i.e., instances of either the policyCondition and/or the qosPolicySimpleCondition classes) that are combined in either conjunctive or disjunctive normal form (as defined in [PCIM]). A complex condition is modeled 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 to 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. Snir, Ramberg, Strassner, Cohen expires October 2000 24 Draft-ietf-policy-qos-info-model-01.txt April 2000 4.3 Simple Condition Operator The QoS policy simple condition includes the qpOperator 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 source IP address 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. 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 matched when evaluating the condition. 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). A variable may also limit, or constrain, 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 (which is 0-65535). Integers outside this range 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. The QPIM defines three important attributes that characterize each of the variables that it defines: 1. The property qpVariableName of the QosPolicyVariable class defines the well-known name used for logical binding of all variables that are defined in this document. 2. The qpValueTypes is the list of value classes that could be matched to this variable. 3. The qpValueConstraints defines a list of constraint on the variable (i.e., values that the Variable must match). Snir, Ramberg, Strassner, Cohen expires October 2000 25 Draft-ietf-policy-qos-info-model-01.txt April 2000 The combination of these three attributes provide a consistent and extensible set of meta-data that define the semantics of variables that are used to form QoS conditions. For example: - The qpVariableName can be used to identify common processing rules for a variable having a specific name. - The qpValueTypes attribute can be used to ensure that only proper classes are used as operators. For example, the source-port variable will not include the QosPolicyIPv4AddrValue class, since source ports have different semantics than IP addresses. However, it will include the QosPolicyIntegerValue class name. û The qpValueConstraints attribute ensures that variable-specific semantics are enforced (e.g., the source-port variable may include a constraint reference to a value object defining the integer range 0..63535). 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 repository must be bound to a logical entity such as a specific field in the IP header, application unique identifier or an application-specific parameter. 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 'source-port == 80', the variable 'source-port' 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 source-port 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 equals 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. Snir, Ramberg, Strassner, Cohen expires October 2000 26 Draft-ietf-policy-qos-info-model-01.txt April 2000 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. 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. 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]. | +-----------------+---------------------------------------------------+ (Table continued in next page) Snir, Ramberg, Strassner, Cohen expires October 2000 27 Draft-ietf-policy-qos-info-model-01.txt April 2000 (Table continued from the previous page) +-----------------+---------------------------------------------------+ |Variable name | Logical binding | +-----------------+---------------------------------------------------+ | 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 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. | +-----------------+---------------------------------------------------+ | 8021QID | The VLAN ID as represented in the 802.1Q field of | | | the header. | +-----------------+---------------------------------------------------+ | Snap | The snap protocol variable is bound to 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. | +-----------------+---------------------------------------------------+ | 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 2. Pre-defined Variable Names and Their Bindings The definition of each predefined variable includes a standard name and the allowed value types, i.e. the variable's qpValueTypes property. Following is a table of variable names and their allowed class types. Snir, Ramberg, Strassner, Cohen expires October 2000 28 Draft-ietf-policy-qos-info-model-01.txt April 2000 +-----------------+---------------------------------------------------+ |Variable name | Allowed class types | +-----------------+---------------------------------------------------+ | SourceIP | qosPolicyIPv4AddrValue, qosPolicyIPv6AddrValue | +-----------------+---------------------------------------------------+ | SourcePort | qosPolicyIntegerValue | +-----------------+---------------------------------------------------+ | DestinationIP | qosPolicyIPv4AddrValue, qosPolicyIPv6AddrValue | +-----------------+---------------------------------------------------+ | DestinationPort | qosPolicyIntegerValue | +-----------------+---------------------------------------------------+ | IPProtocol | qosPolicyIntegerValue | +-----------------+---------------------------------------------------+ | ToS | qosPolicyIntegerValue, qosPolicyBitStringValue | +-----------------+---------------------------------------------------+ | DSCP | qosPolicyIntegerValue, qosPolicyBitStringValue | +-----------------+---------------------------------------------------+ | DestinationMAC | qosPolicyMACAddrValue | +-----------------+---------------------------------------------------+ | SourceMAC | qosPolicyMACAddrValue | +-----------------+---------------------------------------------------+ | 8021QID | qosPolicyIntegerValue, qosPolicyBitStringValue | +-----------------+---------------------------------------------------+ | Snap | qosPolicyIntegerValue | +-----------------+---------------------------------------------------+ | Ethertype | qosPolicyIntegerValue | +-----------------+---------------------------------------------------+ | Ssap | qosPolicyIntegerValue | +-----------------+---------------------------------------------------+ | Dsap | qosPolicyIntegerValue | +-----------------+---------------------------------------------------+ | Application | qosPolicyDNValue, qosPolicyStringValue, | | | qosPolicyAttributeValue | +-----------------+---------------------------------------------------+ | User | qosPolicyDNValue, qosPolicyStringValue, | | | qosPolicyAttributeValue | +-----------------+---------------------------------------------------+ Table 3. Allowed Variable Names and Their Default Class Types Note: For Value type definition, check the QoS Policy Value section. Snir, Ramberg, Strassner, Cohen expires October 2000 29 Draft-ietf-policy-qos-info-model-01.txt April 2000 4.5 QoS Policy Value This abstract class qosPolicyValue is used for defining values and constants used in policy conditions. Different value types are derived from this class and represent the various attributes required. Extensions of the qosPolicValue 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 repository to be reused by multiple conditions. Examples of constants include well-known ports, well-known protocol, server addresses, and other similar concepts. The QoS Policy value classes define 3 types of basic values: scalars, ranges and sets. For example, a well-known port number could be defined using the qosPolicyIntegerValue, defining a single value (80 for HTTP) a range (80-88) or a set (80, 82, 8080). For details, please see the class definition for each value type. The QoS policy information model provide the following classes, all of them extending the QoSPolicyvalue: General: qosPolicyStringValue qosPolicyIntegerValue, qosPolicyBitStringValue, qosPolicyDNValue, qosPolicyAttributeValue. Layer 3 Network values: qosPolicyIPv4AddrValue, qosPolicyIPv6AddrValue. Layer 2 Network values: qosPolicyMACAddrValue. For details, please see the class definition section of each value. 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 The QoS Policy schema defines actions to control QoS enforcement in both the Integrated-Service model as well as the Differential service model. Two types of actions are provided: Signaling and Provisioning actions. Snir, Ramberg, Strassner, Cohen expires October 2000 30 Draft-ietf-policy-qos-info-model-01.txt April 2000 Signaling actions are used to provide policy control on RSVP requests. Provisioning actions are used to directly control the data traffic, regardless of any out-of-band signaling. A policy rule may aggregate zero or more policy actions. A QoS policy rule extends this definition to include 0..n provisioning actions and 0..m signaling actions, each defined by an object or objects describing the action(s) to perform. Actions are ordered (as opposed to rules, which are prioritized). The order of actions is specified in [PCIM]. The property SequencedActions in the aggregating instance of 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, the PolicyActionInPolicyRule aggregation can be used to express an order. In this case, three attributes are used: - ContainingRule, which contains a reference to a policyRule that contains one or more policyActions - ContainedAction, which contains an object reference to a policyAction contained by one or more policyRules - 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 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. 4.7.1 Provisioning Actions QoS Policy provisioning actions model traffic conditioner elements, as specified in [DIFF-SERV-ARCH]. Actions model meters, markers, shapers and droppers. Snir, Ramberg, Strassner, Cohen expires October 2000 31 Draft-ietf-policy-qos-info-model-01.txt April 2000 4.7.1.1 Meters Meters measure the temporal properties of the stream of packets selected by a classifier against a traffic profile. Meters are modeled by the QosPolicyMeter class. A meter can be shared between different policy rules. If this is desired, then the meter SHOULD reside in a reusable-object repository. This enables it to be referenced by all policy rules that want to share it. The property qpMeter is used to hold a reference to a (reusable) meter that is kept in a reusable-object repository. The qpMeterScope property specifies whether the meter should measure flows matching the rule condition per interface, per device or per flow. 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. Meters are measured against traffic profile modeled by the qosPolicyPRTrfcProf object. The property qpTrfcProf holds a reference to a traffic profile that resides in a reusable-object repository. 4.7.1.2 Markers Markers are used to set the DS field of a packet to a particular DS codepoint (DSCP), adding the marked packet to a particular DS behavior aggregate. The marker may be configured to mark all packets steered to it 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. When the marker changes the DSCP in a packet, it is said to have "re-marked" the packet. Marking is modeled by the property qpSetDSCPValue, which specifies the DSCP to set. Remarking out-of-profile packets is modeled by the qpOutofProfileRemarkValue property. The property qpOutOfProfileAction should be set to 'remark' when the remark DSCP value is used. 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. If the value of the property qpOutOfProfileAction is set to 'shape', then this specifies that packets measured by a meter should be shaped according to the traffic profile specified by a qosPolicyPRTrfcProf object. Snir, Ramberg, Strassner, Cohen expires October 2000 32 Draft-ietf-policy-qos-info-model-01.txt April 2000 4.7.1.4. Droppers Droppers are used to discard some or all of the packets in a traffic stream in order to bring the stream into compliance with a traffic profile. This process is also known as "policing" the stream. If the value of the property qpOutOfProfileAction is set to 'drop', then it specifies that packets measured by a meter should be policed according to the traffic-profile specified by a qosPolicyPRTrfcProf object. 4.7.1.5 Examples The following examples will help to show how these classes can be used to perform general provisioning actions. Example 1: Set up a rule enforcing QoS provisioning actions: LetÆs define a policy rule, P, as follows: If () THEN, on outgoing traffic, mark with AND activate a per-flow policer AND activate a per policy rule policer Rule P is represented using 3 qosPolicyPRAction objects: Object 1: qpDirection: OUT qpSetDSCPValue: Object 2: qpDirection: OUT qpMeterScope: flow qpTrfcProf: (this is a repository-specific reference to a per-flow policer object) qpOutOfProfileAction: discard Object 3: qpDirection: OUT qpMeterScope: Interface qpTrfcProf: (this is a repository-specific reference to a per-policyRule policer object) qpOutOfProfileAction: discard qpMeter: Snir, Ramberg, Strassner, Cohen expires October 2000 33 Draft-ietf-policy-qos-info-model-01.txt April 2000 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. 4.7.2 Signaling Action 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 defined by the qosPolicyRSVPSignalCtrlAction class. The qosPolicyRSVPInstallAction class controls the processing of RSVP requests and accompanying flows within the RSVP node itself. Snir, Ramberg, Strassner, Cohen expires October 2000 34 Draft-ietf-policy-qos-info-model-01.txt April 2000 QoS signaling policies does not require a policy server for decision making. A local policy module can use signaling policies for making local decisions, as well as if other outsourcing policy protocol beside COPS is used. 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. The basic decision modeled by this class is whether to admit or reject the RSVP request. The decision can be based on comparison of the request TSPEC or FLOWSPEC to a traffic profile and a meter. A meter can be used to track the temporal resources allocation of RSVP requests matching a network condition. Such 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". Use of meters and meter scope is identical to their use in provisioning policies. The following properties are used: 1. Traffic Profile - referencing a traffic profile. 2. Meter - referencing a meter. Both traffic profile and meter specifications can be directly included within the action as well. 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. The qosPolicyRSVPInstallAction adds the following actions: 1. Set the DSCP value 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 October 2000 35 Draft-ietf-policy-qos-info-model-01.txt April 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. The qosPolicyRSVPSignalCtrlAction adds 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. The following is an example for a rule enforcing QoS signaling actions: Rule S: If THEN, for all WF and SE style Resv messages, accept RSVP request requesting less than <64kb/sec> AND make sure that the total number of admitted active reservations is restricted to <5>. The actions for Rule S are represented using two qosPolicyRSVPAction objects, as follows: Object 1: qpRSVPDirection: OUT qpRSVPMessageType: Resv qpRSVPStyle: SE, WF qpRSVPTrfcProf : DN {8Kb} (repository reference) qpRSVPMeterScope: flow Snir, Ramberg, Strassner, Cohen expires October 2000 36 Draft-ietf-policy-qos-info-model-01.txt April 2000 Object 2: qpRSVPDirection: OUT qpRSVPMessageType: Resv qpRSVPStyle: SE, WF qpRSVPTrfcProf : {6 session Max} (repository reference) qpRSVPMeter: Meter (repository reference) qpRSVPMeterScope: interface The various attributes of RSVP traffic profiles are described in the next section. 4.8. Traffic Profiles The QoS Policy schema defines two categories of traffic profiles. Provisioning traffic profiles carry rate and burst parameters to be compared with flow meters. RSVP traffic profiles are compared with RSVP TSPEC and FLOWSPEC parameters, and with meters aggregating the temporal state of admitted RSVP reservations and states. Traffic profiles can be kept in a repository for reusability. Traffic profiles can also be directly attached to actions. 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 bits/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 October 2000 37 Draft-ietf-policy-qos-info-model-01.txt April 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, mAMB. 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 policy using the same rules for comparison of TSPECs (FLOWSPECs) to a traffic profile. Snir, Ramberg, Strassner, Cohen expires October 2000 38 Draft-ietf-policy-qos-info-model-01.txt April 2000 5. Decision strategy The decision strategy to be used by policy servers and other policy decision points in the network on a set of policies is defined by grouping policies into various qosNamedPolicyContainer groups, and using these groups to partition behavior in different QoS policy domains. In order to get a consistent behavior of different policy servers using the same group of policy rules, 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 per qosNamedPolicyContainer. When a policy decision point evaluates a set of rules, it implements the decision strategy defined in each container of rules. Nested containers can override the decision strategy of their containers. The order of decision making of nested rules is defined by the combination of their internal priority, the priority of the policy rule containing the nested rule and the priority of their containers. Nested rules have a higher priority than their containing rule. Priority is compared between rules and qosNamedPolicyContainers, as Defined in [PCIM]. The rule priority of PCIM is extended by introducing the qpPriority (group priority) property of qosNamedPolicyContainer. Two decision strategies are defined: 1. "FIRST MATCH" 2. "MATCH ALL" 5.1. First match 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. Match All 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 the flow meets with the rule's conditions. This matching strategy may in many cases mean that a number of rules may meet the flow's parameters 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. Snir, Ramberg, Strassner, Cohen expires October 2000 39 Draft-ietf-policy-qos-info-model-01.txt April 2000 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) | +--NamedContainer1 (priority 5) | | | +--Rule 1.1 (priority 3) | | | +--Rule 1.2 (priority 33) | +--Rule3 (priority 4) | +--Rule4 (priority 2) Figure 4: Decision Strategy example NOTE: rule nesting is not defined in PCIM, but rather is defined in this document 5.3.1 Default Operation using First Match Everywhere For simplicity we assume that a Policy Decision Point needs to enforce all rules described above. Therefore, the rules will be evaluated in the following order: 1. Rule1 (higher priority between Rule1, namedContainer1 and Rule3 2. Rule1.2 (higher priority between Rule1.1 and Rule1.2) 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 NamedContainer1, the decision process will stop once a rule's condition is matched. Note: this equates priority with order. This is very different than how this same example would work using priority as defined in [PCIM] (in fact, this could not even be represented in [PCIM]). This is because of the following two reasons: - PCIM does not provide the ability to assign an order to a named container. It therefore has no concept of ordering containers among its policy rules - PCIM has no concept of nested rules Snir, Ramberg, Strassner, Cohen expires October 2000 40 Draft-ietf-policy-qos-info-model-01.txt April 2000 5.3.2 Operation Using Other Decision Strategies However, if the decision strategy of the domain is match all and it is not overridden by NamedContainer1, 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 NamedContainer1 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 and executed if their conditions match. If one of NamedContainer1 rule 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 NamedContainer1 is first match, the decision process will evaluate Rule1 and continue to evaluate NamedContainer1 rules. 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 match-all decision strategy. Snir, Ramberg, Strassner, Cohen expires October 2000 41 Draft-ietf-policy-qos-info-model-01.txt April 2000 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 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. The QPIM provides abstract placeholders for PHBs and for a set of PHBs enforced together on a QoS domain. Further specification of PHBs and PHB sets are outside the scope of this document; please refer to [PHBSET] for more information. 6.1. PHBs The qosPolicyPHB abstract class models a single PHB. The qosPolicyPHB class includes a single property, the DSCP value, which is an integer with allowed values in the range of 0 to 63, inclusive. The qosPolicyPHB name will be defined using the cn property belonging to the Policy class [PCIM]. 6.1. PHB Sets The qosPolicyPHBSet abstract class serves as a named container for instances of qosPolicyPHB classes. It models the set of PHBs enforced together on a QoS domain. Different PHB sets can be kept in a repository. A PHB set enforced on the domain is specified by either a reference from the qosPolicyDomain class to one of the PHB sets that are located in the reusable-object repository, or by directly including the PHB set in the domain (the method for doing this is repository- specific; for example, attachment could be used if the repository is a directory). To fine tune PHB parameters and to further restrict the namespace in which a particular PHB is used, PHB sets can be referenced or augment the semantics of qosNamedPolicyContainers. However, in order to maintain an end-to-end consistent behavior, overriding the domain's PHB set should be done only to fine tune the parameters of each PHBs, and not to use a different set of PHBs altogether. Markers coloring packets of flows on domain ingress edges should pick a DSCP selecting one of the PHBs enforced on the QoS domain. Snir, Ramberg, Strassner, Cohen expires October 2000 42 Draft-ietf-policy-qos-info-model-01.txt April 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 | | | | | +--qosNamedPolicyContainer | | | +--policyRule ([PCIM]) | | | +--policyCondition ([PCIM]) | | | | | +--policyTimePeriodCondition ([PCIM]) | | | | | +--vendorPolicyCondition ([PCIM]) | | | | | +--qosPolicySimpleCondition | | | +--policyAction | | | | | +--vendorPolicyAction ([PCIM]) | | | | | +-- qosPolicyPRAction | | | | | +-- qosPolicyRSVPAction | | | | | +-- qosPolicyRSVPSignalCtrlAction | | | | | +-- qosPolicyRSVPInstallAction | | | +--qosPolicyVariable | | | +--qosPolicyValue(abstract) | | | | | +--qosPolicyIPv4AddrValue | | | | | +--qosPolicyIPv6AddrValue | | | | | +--qosPolicyMACAddrValue | | | | | +--qosPolicyStringValue | | | | | +--qosPolicyBitStringValue | | | (Diagram continued in next page) Snir, Ramberg, Strassner, Cohen expires October 2000 43 Draft-ietf-policy-qos-info-model-01.txt April 2000 (Diagram continued from previous page) top | +--policy (abstract, [PCIM]) | | | +--qosPolicyValue(abstract, continued from previous page) | | | | | +--qosPolicyDNValue | | | | | +--qosPolicyAttributeValue | | | | | +--qosPolicyIntegerValue | | | +-- qosPolicyMeter | | | +-- qosPolicyPRTrfcProf | | | +-- qosPolicyRSVPTrfcProf | | | +-- qosPolicyPHBSet (abstract) | | | +-- qosPHB (abstract) | +--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 7 of [PCIM] in its entirety, which defines the concepts of associations and aggregations. Ten associations and aggregations are defined in the [PCIM]; note that the QPIM does not define any new associations or aggregations: 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 Snir, Ramberg, Strassner, Cohen expires October 2000 44 Draft-ietf-policy-qos-info-model-01.txt April 2000 8. Class Definitions 8.1. 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, qpPHBSet, qpPolicyRuleMatchMethod 8.1.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 8.1.2. The Property qpPHBSet This property contains a reference to the PHB set defined for this domain. Its definition is as follows: NAME qpPHBSet SYNTAX Reference to a PHBSet object 8.1.3. 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 } Snir, Ramberg, Strassner, Cohen expires October 2000 45 Draft-ietf-policy-qos-info-model-01.txt April 2000 8.2. Class qosNamedPolicyContainer This class represents an administratively-defined policy rule container. All policies that are commonly administered are defined in a particular qosNamedPolicyContainer. 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 qosNamedPolicyContainer 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 qosNamedPolicyContainer DERIVED FROM policyGroup (defined in [PCIM]) ABSTRACT False PROPERTIES qpPriority, qpNamedPolicyRuleMatchMethod 8.2.1. The Property qpPriority This property is a non-negative integer that defines the priority of a named group of rules. Conceptually, it is the priority of the qosNamedPolicyContainer, and is used to determine when the policy rules that the qosNamedPolicyContainer contains are evaluated with respect to other policyRules, policyGroups, and other qosNamedPolicyContainters. If two or more qosPolicyNamedContainer objects have the same priority, this means that the order between these objects is of no importance, but that they each be evaluated before other objects that have a numerically lower priority. The attribute is defined as follows: NAME qpPriority SYNTAX Integer (must be non-negative) 8.2.2. The Property qpNamedPolicyRuleMatchMethod 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. The attribute is defined as follows: NAME qpNamedPolicyRuleMatchMethod SYNTAX Integer (ENUM) - {"FIRST MATCH " = 0; "MATCH ALL " = 1 } Snir, Ramberg, Strassner, Cohen expires October 2000 46 Draft-ietf-policy-qos-info-model-01.txt April 2000 8.3. 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 class definition is as follows: NAME qosPolicyPRAction DERIVED FROM policyAction (defined in [PCIM]) ABSTRACT False PROPERTIES qpDirection, qpSetDSCPvalue, qpMeter, qpMeterScope, qpTrfcProf, qpOutOfProfileAction, qpOutOfProfileRemarkValue 8.3.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 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.3.2. The Property qpSetDSCPvalue This property is an integer (constrained to the range 0-63, inclusive) that defines the DSCP value of the (re)mark action. The attribute is defined as follows: NAME qpSetDSCPvalue SYNTAX Integer (must be in the range 0-63, inclusive) 8.3.3. The Property qpMeter This property defines a reference to a qosPolicyMeter object used in this provisioning action. The attribute is defined as follows: NAME qpMeter SYNTAX Reference to a qosPolicyMeter object Snir, Ramberg, Strassner, Cohen expires October 2000 47 Draft-ietf-policy-qos-info-model-01.txt April 2000 8.3.4. The Property qpMeterScope This property is an enumerated integer that defines whether this metering action should be applied on a per-flow, per-interface, or per- device basis. The attribute is defined as follows: NAME qpMeterScope SYNTAX Integer (ENUM) û {flow=0,interface=1 device=2} 8.3.5. The Property qpTrfcProf This property contains a reference to an object that defines the DiffServ provisioning policing instruction value, defined as a reference to a qosPolicyPRTrfcProf instance. The attribute is defined as follows: NAME qpTrfcProf SYNTAX Reference to a qosPolicyPRTrfcProf object 8.3.6. The Property qpOutOfProfileAction This property is an enumerated integer that defines the action to be applied to out of profile packets, as defined in the DiffServTrfcProf entry. That entry contains values for each of the three types of actions that are present in this attribute: shaping, discarding, or remarking. The attribute is defined as follows: NAME qpOutOfProfileAction SYNTAX Integer (ENUM) - {SHAPE=0,DISCARD=1,REMARK=2} 8.3.7. The Property qpOutofProfileRemarkValue This property is an integer that defines the DSCP value to be applied to out of profile packets if the qpOutofProfile action is defined as REMARK. The attribute is defined as follows: NAME qpOutofProfileRemarkValue SYNTAX Integer (constrained to the range 0-63, inclusive) 8.4. Class qosPolicyRSVPAction This class defines a policy action to be applied on an RSVP signaling message that matches the rule condition. The class definition is as follows: Snir, Ramberg, Strassner, Cohen expires October 2000 48 Draft-ietf-policy-qos-info-model-01.txt April 2000 NAME qosPolicyRSVPAction DERIVED FROM policyAction (defined in [PCIM]) ABSTRACT False PROPERTIES qpRSVPDirection, qpRSVPMessageType, qpRSVPService, qpRSVPStyle, qpRSVPInstallAction, qpRSVPCtrlAction, qpRSVPMeter, qpRSVPMeterScope, qpRSVPTrfcProf 8.4.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.4.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.4.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.4.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 October 2000 49 Draft-ietf-policy-qos-info-model-01.txt April 2000 8.4.5. The Property qpRSVPInstallAction This property is a reference to a qosPolicyRSVPInstallAction object. This object is used in conjunction with the RSVP reservation, and defines detailed control for COPS install decisions (defined in [COPS]). The attribute is defined as follows: NAME qpRSVPInstallAction SYNTAX Reference to a qosPolicyRSVPInstallAction object 8.4.6. The Property qpRSVPCtrlAction This property is a reference to a qosPolicyRSVPSignalCtrlAction object. This object is used in conjunction with the RSVP reservation, and defines 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. The attribute is defined as follows: NAME qpRSVPCtrlAction SYNTAX Reference to a qosPolicyRSVPSignalCtrlAction object 8.4.7. The Property qpRSVPMeter This property is a reference to a qosPolicyMeter object. This object is used in conjunction with the RSVP reservation, and defines the detailed definition of the meter characteristics. The attribute is defined as follows: NAME qpRSVPMeter SYNTAX Reference to a qosPolicyMeter object 8.4.8. The Property qpRSVPMeterScope This property is an enumerated integer that defines the scope of the metering action to be on a per-flow, per-interface, or per-device basis. The attribute is defined as follows: NAME qpRSVPMeterScope SYNTAX Integer (ENUM) û {flow=0,interface=1 device=2} Snir, Ramberg, Strassner, Cohen expires October 2000 50 Draft-ietf-policy-qos-info-model-01.txt April 2000 8.4.9. The Property qpRSVPTrfcProf This property is a reference to a qosPolicyRSVPTrfcProf object, which defines 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. The attribute is defined as follows: NAME qpRSVPTrfcProf SYNTAX Reference to a qosPolicyRSVPTrfcProf object 8.5. 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 policy (defined in [PCIM]) ABSTRACT False PROPERTIES qpPRRate, qpPRNormalBurst, qpPRExcessBurst 8.5.1. The Property qpPRRate This is a non-negative integer that defines the token rate in 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.5.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.5.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) Snir, Ramberg, Strassner, Cohen expires October 2000 51 Draft-ietf-policy-qos-info-model-01.txt April 2000 8.6. 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.6.1. The Property qpRSVPTokenRate This property is a non-negative integer that defines the token rate parameter, measured in bits per second. The attribute is defined as follows: NAME qpRSVPTokenRate SYNTAX Integer (must be non-negative) 8.6.2. The Property qpRSVPPeakRate This property is a non-negative integer that defines the peak rate parameter, measured in bits per second. The attribute is defined as follows: NAME qpRSVPPeakRate SYNTAX Integer (must be non-negative) 8.6.3. The Property qpRSVPBucketSize This property is a non-negative integer that defines the token bucket size parameter, measured in bits per second. The attribute is defined as follows: NAME qpRSVPBucketSize SYNTAX Integer (must be non-negative) Snir, Ramberg, Strassner, Cohen expires October 2000 52 Draft-ietf-policy-qos-info-model-01.txt April 2000 8.6.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 bits per second. The attribute is defined as follows: NAME qpRSVPResvRate SYNTAX Integer (must be non-negative) 8.6.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.6.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) 8.6.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.6.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) Snir, Ramberg, Strassner, Cohen expires October 2000 53 Draft-ietf-policy-qos-info-model-01.txt April 2000 8.7. 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 policyAction (defined in [PCIM]) ABSTRACT False PROPERTIES qpForwardingMode, qpSendError, qpReplaceDSCP, qpReplacePreemptionPriority, qpReplaceDefendingPriority 8.7.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.7.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} Snir, Ramberg, Strassner, Cohen expires October 2000 54 Draft-ietf-policy-qos-info-model-01.txt April 2000 8.7.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: NAME qpReplaceDSCP SYNTAX Integer (constrained to the range 0-63, inclusive) 8.7.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.7.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.8. 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: Snir, Ramberg, Strassner, Cohen expires October 2000 55 Draft-ietf-policy-qos-info-model-01.txt April 2000 NAME qosPolicyRSVPInstallAction DERIVED FROM policyAction (defined in [PCIM]) ABSTRACT False PROPERTIES qpSetDSCPValue, qpSetPreemptionPriority, qpSetDefendingPriority 8.8.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.8.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.8.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.9. Class qosPolicySimpleCondition (Aux) A simple condition is composed of an ordered triplet: The operator used in all condition definitions in this draft is the 'match' operator. Such simple conditions are evaluated by answering the question: Does match ? 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 qosPolicySimpleCondition class is derived from the policyCondition class in [PCIM]. Simple conditions can be kept in repositories for reuse. Snir, Ramberg, Strassner, Cohen expires October 2000 56 Draft-ietf-policy-qos-info-model-01.txt April 2000 The class definition is as follows: NAME qosPolicySimpleCondition DERIVED FROM policyCondition (defined in [PCIM]) ABSTRACT False PROPERTIES qpOperator, qpVariableAtom, qpValueAtom 8.9.1. The Property qpOperator This property is a string that defines the relation between a variable and a value. The default value is ômatchö, which has the semantics of 'belong to' or 'equal'. The attribute is defined as follows: NAME qpOperator SYNTAX String DEFAULT VALUE 'match' 8.9.2. The Property qpVariableAtom This property is a reference to an object that defines the variable to be used in a QoS policy condition. The referenced object SHOULD be a subclass of the qosPolicyVariable class. The attribute is defined as follows: NAME qpVariableAtom SYNTAX Reference to an object that is a subclass of the qosPolicyVariable class 8.9.3. The Property qpValueAtom This property is a reference to an object that defines the value to be used in a QoS policy condition. The referenced object SHOULD be a subclass of the qosPolicyValue class. The attribute is defined as follows: NAME qpValueAtom SYNTAX Reference to an object that is a subclass of the qosPolicyValue class 8.10. Class qosPolicyVariable 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. 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. Snir, Ramberg, Strassner, Cohen expires October 2000 57 Draft-ietf-policy-qos-info-model-01.txt April 2000 A variable also limits 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 16 bits port entity. The class definition is as follows: NAME qosPolicyVariable DERIVED FROM policy (defined in [PCIM]) ABSTRACT False PROPERTIES qpVariableName, qpValueTypes, qpVariableDescription, QpValueConstraints 8.10.1. The Property qpVariableName This property is a string that is 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 qpVariableName SYNTAX String, defined in the following table: 8.10.2 The Property qpValueTypes 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 allows efficient retrieval of the possible set of relevant values from a repository, and was defined earlier in Table 3. The attribute is defined as follows: NAME qpValueTypes SYNTAX String 8.10.3. The Property qpVariableDescription This property is a string that provides a textual description of the variable. The attribute is defined as follows: NAME qpVariableDescription SYNTAX String Snir, Ramberg, Strassner, Cohen expires October 2000 58 Draft-ietf-policy-qos-info-model-01.txt April 2000 8.10.4. The Property qpValueConstraints This property is a set of references to objects serving as constraints for this variable. This attribute is defined as follows: NAME qpValueConstraints SYNTAX Set of references to objects that constrain this variable 8.11. Class qosPolicyValue 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 qosPolicyValue DERIVED FROM policy (defined in [PCIM]) ABSTRACT True PROPERTIES 8.12. Class qosPolicyIPv4AddrValue This class is used to provide a list of IPv4Addresses, hostnames and address range values. The class definition is as follows: NAME qosPolicyIPv4AddrValue DERIVED FROM qosPolicyValue ABSTRACT False PROPERTIES qpIPv4AddrList 8.12.1. The Property qpIPv4AddrList This Property provides an unordered list of strings, each specifying a single IPv4 address, a hostname, or a range of IPv4 addresses. The ABNF definition [ABNF] of an IPv4 address is: IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT IPv4prefix = IPv4address "/" 1*2DIGIT IPv4range = IPv4address"-"IPv4address IPv4maskedaddress = IPv4address","IPv4address Hostname (as defined in [NAMES]) Each string entry is either: 1. A single Ipv4address in dot notation as defined above. Example: 121.1.1.2 2. A single Hostname. Hostname format follows the guidelines and restrictions specified in [NAMES]. Example: www.bigcompany.com Snir, Ramberg, Strassner, Cohen expires October 2000 59 Draft-ietf-policy-qos-info-model-01.txt April 2000 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 NAME qpIPv4AddrList SYNTAX String FORMAT IPv4address | hostname | IPv4addressrange | IPv4maskedaddress | IPv4prefix 8.13. Class qosPolicyIPv6AddrValue This class is used to define a list of IPv6 addresses, hostnames, and address range values. The class definition is as follows: NAME qosPolicyIPv6AddrValue DERIVED FROM qosPolicyValue ABSTRACT False PROPERTIES qpIPv6AddrList 8.13.1. The Property qpIPv6AddrList 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 IPv6maskedaddress = IPv6address","IPv6address Hostname (as defines in [NAMES]) Snir, Ramberg, Strassner, Cohen expires October 2000 60 Draft-ietf-policy-qos-info-model-01.txt April 2000 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 qpIPv6AddrList SYNTAX String FORMAT IPv6address | hostname | IPv6addressrange | IPv6maskedaddress | IPv6prefix 8.14. Class qosPolicyMACAddrValue This class is used to define a list of MAC addresses and MAC address range values. The class definition is as follows: NAME qosPolicyMACAddrValue DERIVED FROM qosPolicyValue ABSTRACT False PROPERTIES qpMACAddrList 8.14.1. The Property qpMACAddrList 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. NAME qpMACAddrList SYNTAX String FORMAT MACaddress | MACmaskedaddress Snir, Ramberg, Strassner, Cohen expires October 2000 61 Draft-ietf-policy-qos-info-model-01.txt April 2000 8.15. Class qosPolicyStringValue This class is used to represent a single or set of string values. Each can have wildcards. The class definition is as follows: NAME qosPolicyStringValue DERIVED FROM qosPolicyValue ABSTRACT False PROPERTIES qpStringList 8.15.1. The Property qpStringList 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 qpStringList SYNTAX String 8.16 Class qosPolicyBitStringValue This class is used to represent a single or set of bit string values. The class definition is as follows: NAME qosPolicyBitStringValue DERIVED FROM qosPolicyValue ABSTRACT False PROPERTIES qpBitStringList 8.16.1. The Property qpBitStringList 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 definitions are: binary-digit = "0" / "1" bitstring = 1*binary-digit maskedBitString = bitstring","bitstring Snir, Ramberg, Strassner, Cohen expires October 2000 62 Draft-ietf-policy-qos-info-model-01.txt April 2000 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 qpBitStringList SYNTAX String FORMAT bitString | maskedBitString 8.17. Class qosPolicyDNValue This class is used to represent a single or set of Distinguished Name values, including wildcards. A Distinguished Name is a name that can be used as a key to retrieve an object. 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 qosPolicyDNValue DERIVED FROM qosPolicyValue ABSTRACT False PROPERTIES qpDNList 8.17.1. The Property qpDNList This property provides an unordered list of Distinguished Name references to objects. The attribute is defined as follows: NAME qpDNList SYNTAX List of Distinguished Names, each of which serves as a reference to another object. 8.18. Class qosPolicyAttributeValue This class is used to represent a single or set of property values in an object. This value can be used in conjunction with reference values carried in RSVP objects, as specified in [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. Snir, Ramberg, Strassner, Cohen expires October 2000 63 Draft-ietf-policy-qos-info-model-01.txt April 2000 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 qosPolicyAttributeValue with the following characteristics: qpAttributeName="member-of", qpAttributeValueList = "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 qosPolicyAttributeValue DERIVED FROM qosPolicyValue ABSTRACT False PROPERTIES qpAttributeName, qpAttributeValueList 8.18.1. The Property qpAttributeName This attribute defines the name of the property that the list of values should be compared against. The attribute is defined as follows: NAME qpAttributeName SYNTAX String 8.18.2. The Property qpAttributeValueList This attribute contains a list of property values. Each value is compared to a value of the property specified by qpAttributeName. The attribute is defined as follows: NAME qpAttributeValueList SYNTAX String 8.19. Class qosPolicyIntegerValue 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 qpValueConstraints Property. The class definition is as follows: NAME qosPolicyIntegerValue DERIVED FROM qosPolicyValue ABSTRACT False PROPERTIES qpIntegerList Snir, Ramberg, Strassner, Cohen expires October 2000 64 Draft-ietf-policy-qos-info-model-01.txt April 2000 8.19.1. The Property qpIntegerList 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. NAME qpIntegerList SYNTAX String FORMAT integer | integerrange 8.20. Class qosPolicyPHBSet The qosPolicyPHBSet is a class that serves as a named container for qosPolicyPHB objects. A single PHB set is associated with a QoS domain using the domain property defined in the qosPolicyDomain object. Instances of the qosNamedPolicyContainer class can override the domain's PHB set by referencing another PHB set via the qosPolicyPHBSet Property or by aggregation of a qosPolicyPHBSet object. The class is defined as follows: NAME qosPolicyPHBSet DERIVED FROM policy (defined in [PCIM]) ABSTRACT False PROPERTIES 8.21. Class qosPolicyPHB The qosPolicyPHB Class is an abstract class that extends the policy class (defined in the [PCIM]) with the information required to model a PHB service class. The PHB service class is an abstraction over device-specific parameters. Snir, Ramberg, Strassner, Cohen expires October 2000 65 Draft-ietf-policy-qos-info-model-01.txt April 2000 The class is defined as follows: NAME qosPolicyPHB DERIVED FROM policy (defined in [PCIM]) ABSTRACT True PROPERTIES qpDSCP 8.21.1. The Property qpDSCP This property is an integer, constrained to have a value in the range 0..63 inclusive, for representing the service classes in the QoS policy domain that are used for traffic classification. The attribute is defined as follows: NAME qpDSCP SYNTAX Integer (must be in the range 0..63, inclusive) 8.22 Class qosPolicyMeter This class models a meter, as defined in (for example) [DIFF-SERV-ARCH]. Meters measure the temporal properties of the stream of packets selected by a classifier against a traffic profile. 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. The class is defined as follows: NAME qosPolicyMeter DERIVED FROM policy (defined in [PCIM]) ABSTRACT True PROPERTIES Snir, Ramberg, Strassner, Cohen expires October 2000 66 Draft-ietf-policy-qos-info-model-01.txt April 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 qosPolicyValue The qosPolicyValue 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 qosPolicyValue class and properties that contain the corresponding values SHOULD be added. Notice that in many cases, using the qosPolicyAttributeValue class allows the definition of non-standard policy atoms without extending the qosPolicyValue class. 9.2. Extending qosPolicySimpleCondition The qosPolicySimpleCondition class is used to describe a single atomic Boolean condition. For Boolean conditions that are not structured as the ordered triple , 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 qosPolicySimpleCondition 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 October 2000 67 Draft-ietf-policy-qos-info-model-01.txt April 2000 10. Security Considerations The security considerations for this document are the same as those of the [PCIM]. 11. 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. 12. References [ABNF] Crocker, D., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [CL] J. Wroclawski, "Specification of the Controlled-Load Network Element Service", RFC2211, September 1997 [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 [DEREF] R. Moats, J. Maziarski, J. Strassner, "Extensible Match Rules to Dereference Pointer", Internet Draft [DIFF-SERV-ARCH] S. Blake D. Blake, "An Architecture for Differentiated Services", RFC2475 [DNDEF] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997. [GS] S. Shenker, C. Partridge, R. Guerin, "Specification of the Guaranteed Quality of Service", RFC2212, September 1997 [IDNET] S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, S. Herzog, "Identity Representation for RSVP", RFC 2752, January 2000 [IPv6] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", RFC2373, July 1998 Snir, Ramberg, Strassner, Cohen expires October 2000 68 Draft-ietf-policy-qos-info-model-01.txt April 2000 [LDAP_ATTR] M. Wahl, A. Coulbeck, " Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252 [NAME] P. Mockapetris, " Domain names - implementation and specification", RFC1035 [PCIM] J. Strassner, E. Ellesson, B. Moore, "Policy Framework Core Information Model", Internet Draft [PHBLDAP] R. Cohen, Y. Snir, J. Strassner, ôLDAP schema for Domain Per Hop Behavior Setö, Internet Draft [PHBSET] R. Cohen, A. Zavalkovsky, N. Elfassy, ôDomain Per Hop Behavior Set Specificationö, Internet Draft [PFSCHEMA] J. Strassner, E. Ellesson, B. Moore, "Policy Framework LDAP Core Schema", Internet Draft [PIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, A. Smith, "Quality of Service Policy Information Base", Internet Draft [QOSDEV] J. Strassner, W. Weiss, D. Durham, A. Westerinen, ôInformation Model for Describing Network Device QoS Mechanismsö, Internet Draft [QOSSCHEMA] Y. Snir, Y Ramberg, J. Strassner, R. Cohen, ôQoS Policy Schemaö, Internet Draft [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 [RSVP_PREEMP] Shai Herzog, "Signaled Preemption Priority Policy Element", RFC2751 [TERMS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", Internet RFC 2119, March 1997. Snir, Ramberg, Strassner, Cohen expires October 2000 69 Draft-ietf-policy-qos-info-model-01.txt April 2000 13. Author's Addresses Yoram Snir Cisco Systems 4 Maskit Street Herzliya Pituach, Israel 46766 Phone: +972-9-970-0085 Fax: +972-9-970-0219 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 14. 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 October 2000 70 Draft-ietf-policy-qos-info-model-01.txt April 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 October 2000 71