Policy Framework Y. Snir Internet Draft Y. Ramberg Expires April 2000 J. Strassner draft-snir-qos-policy-schema-01.txt Cisco Systems October, 1999 QoS Policy Framework 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 The QoS Policy schema refines the concepts in the Policy Framework Core Information Model and Schema documents ([PFCORE] and [PFSCHEMA], respectively) in order to extend this generalized policy model to represent network Quality of Service (QoS) policy information. This information is typically used by QoS Policy Servers to configure network devices according to prescribed QoS Policies. The schema presented here is based on, and derived from, the Policy Framework LDAP Core Schema, version 4. This document will be updated shortly to reflect the latest changes of the Policy framework LDAP Core Schema draft. Snir, Ramberg, Strassner expires April 2000 1 Draft-snir-qos-policy-schema-01.txt October 1999 Table of Contents 1. Introduction 7 1.1. Schemata Hierarchy 7 1.2. Containment Hierarchy 8 1.2.1. Reusable-objects repositories 10 1.2.1.1. Repository structure 11 1.2.1.1.1. Atom Folders 13 1.2.1.1.1.1. Using Atoms 13 1.2.1.1.1.2. Atom Folders Organization 13 1.2.1.1.1.3. Variable 14 1.2.1.1.1.4 Constant 15 1.2.1.1.1.5. Operators and Relations 15 1.2.1.1.1.5.1. Integer 16 1.2.1.1.1.6. String 16 1.2.1.1.1.7. IP address (IPv4 and IPv6) 16 1.2.1.1.2. Value 16 1.2.1.2. Variable binding 17 1.2.1.2.1. Pre-defined Variables 18 1.2.1.2.1.1. IP Header Variables 18 1.2.1.2.1.1.1. Source IP address IPv4 18 1.2.1.2.1.1.2. Source IP address IPv6 19 1.2.1.2.1.1.3. Source Port 19 1.2.1.2.1.1.4. Destination IPv4 address 19 1.2.1.2.1.1.5. Destination IPv6 address 19 1.2.1.2.1.1.6. Destination Port 19 1.2.1.2.1.1.7. Protocol Number 19 1.2.1.2.1.1.8. ToS Value 19 1.2.1.2.1.2. Layer 2 Variables 20 1.2.1.2.1.2.1. Destination MAC address 20 1.2.1.2.1.2.2. Source MAC address 20 1.2.1.2.1.2.3. 802.1Q ID 20 1.2.1.2.1.2.4. SNAP Protocol 20 1.2.1.2.1.2.5. Ethertype 20 1.2.1.2.1.2.6. Source SAP 20 1.2.1.2.1.2.7. Destination SAP 20 1.2.1.2.1.3. Application Variables 21 1.2.1.2.1.3.1. Application name 21 1.2.1.2.1.3.2. Application unique id 21 1.2.1.2.1.4. Host Variables 21 1.2.1.2.1.4.1. Host name 21 1.2.1.2.1.4.2. Host group - domain 21 1.2.1.3. Simple Conditions 21 1.2.1.4. Policers 22 1.2.1.4.1. DS policers 22 1.2.1.4.2. RSVP policers 23 1.2.2. Per Hop Behavior 23 1.2.2.1. PHB Set 23 1.2.2.2. Service class 24 Snir, Ramberg, Strassner expires April 2000 2 Draft-snir-qos-policy-schema-01.txt October 1999 1.3. Policy tree 24 1.3.1.1. Overview 25 1.3.1.2. Discussion of the Containment Hierarchy 26 1.3.1.3. Example of the Use of the Policy Containment Hierarchy 27 1.3.2. Policy Rule Implementation 28 1.3.3. Simple and complex conditions 29 1.3.3.1. Simple condition composition 29 1.3.3.2. Using simple conditions 31 1.3.3.3. Composing and using complex conditions 31 1.3.4. Action 32 1.3.5. Decision strategy 33 1.3.5.1. First match 33 1.3.5.2. Match All 33 1.3.6. Inheritance Hierarchy for the LDAP QoS Policy Schema 34 2. Implementation in an LDAP Server 36 2.1. Use of Distinguished Name in the Schema 36 2.2. QoS Policy Auxiliary classes 36 2.2.1. Using attachment of auxiliary classes vs. DNs 36 2.2.2. Multiple attachment 36 2.2.3. Auxiliary Classes - when and how they should be used 36 2.2.3.1. Attach to PolicyInstance class 37 2.2.3.2. Attach specific containers to root objects 37 2.2.3.3. Attach to an object for efficient LDAP retrieval operation 37 2.2.3.3.1. Attaching qosPolicySimpleCondition to qosPolicyRule 37 2.2.3.3.2. Attaching qosPolicyAction to qosPolicyRule 37 2.2.3.3.3. Attaching qosPolicyVariable, qosPolicyConstant and qosPolicyValue objects to qosPolicySimpleCondition 37 2.3. LDAP Search efficiency 38 2.3.1. Reusable objects 38 2.3.2. NamedGroupContainer Location 38 2.3.3. QoS Policy Rules Location 38 2.3.4. Qos Policy SubRule Location 38 2.3.5. Condition, Action, and TriggerEvent location 38 2.3.6. Search 38 3. Data integrity 39 3.1. Order of insertion of objects into the Directory Service 39 3.2. Distinguishing between objects in the repository and private instantiations 40 3.3. Versioning of objects 40 3.4. Transaction Support 40 3.5. Data integrity in replicated directories 40 3.6. Referred objects' DN 40 4. Class Definitions 41 4.1. Class qosPolicyRoot 41 4.1.1. The Attribute qpRepositoryRoot 41 4.1.2. The Attribute qpDomainsRoot 41 4.2. Class qosPolicyRepository 41 4.2.1. The Attribute qpRepositoriesPresent 42 Snir, Ramberg, Strassner expires April 2000 3 Draft-snir-qos-policy-schema-01.txt October 1999 4.3. Class qosRepositoryContainmentAuxClass 42 4.3.1. The Attribute qpRepositoryContainmentAuxSet 43 4.4. Class qosPolicyDomains 43 4.4.1. The Attribute qpDomainsPresent 44 4.5. Class qosPolicyDomain 44 4.5.1. The Attribute qpDomainName 44 4.5.2. The Attribute qpGlobalNamedContainer 45 4.5.3. The Attribute qpPHBSet 45 4.6. Class qosNamedPolicyContainer 45 4.6.1. The Attribute qpPriority 46 4.6.2. The Attribute qpPolicyRuleMatchMethod 46 4.7. Class qosPolicyRule 46 4.7.1. The Attribute qpDirection 47 4.8. Class qosPolicyColorAction 47 4.8.1. The Attribute qpDSCPValue 47 4.9. Class qosPolicyDSPolicerAction 48 4.9.1. The Attribute qpDiffServPolicer 48 4.9.2. The Attribute qpOutOfProfileAction 48 4.9.3. The Attribute qpOutofProfilePolicer 48 4.9.4. The Attribute qpOutofProfileRemarkValues 49 4.10. Class qosPolicyRSVPPolicerAction 49 4.10.1. The Attribute qpRSVPPolicer 49 4.10.2. The Attribute qpRSVPAction 49 4.11. Class qosPolicyDSPolicer 50 4.11.1. The Attribute qpPolicerName 50 4.11.2. The Attribute qpDSPolicerDescription 50 4.11.3. The Attribute qpDSNormalRate 51 4.11.4. The Attribute qpDSNormalBurst 51 4.11.5. The Attribute qpDSExcessBurst 51 4.11.6. The Attribute qpIsShared 51 4.12. Class qosPolicyRSVPPolicer 51 4.12.1. The Attribute qpPolicerName 52 4.12.2. The Attribute qpRSVPPolicerDescription 52 4.12.3. The Attribute qpRSVPTokenRate 52 4.12.4. The Attribute qpRSVPPeakRate 53 4.12.5. The Attribute qpRSVPBucketSize 53 4.12.6. The Attribute qpIsShared 53 4.12.7. The Attribute qpPreemptionPriority 53 4.12.8. The Attribute qpDefendingPriority 54 4.13. Class qosPolicyDetailedRSVPPolicer 54 4.13.1. The Attribute qpRSVPMsgType 54 4.13.2. The Attribute qpRSVPServiceType 55 4.13.3. The Attribute qpMinPolicedUnit 55 4.13.4. The Attribute qpMaxPktSize 55 4.13.5. The Attribute qpRSVPResvRate 55 4.13.6. The Attribute qpRSVPResvSlack 55 4.14. Class qosPolicySimpleCondition (Aux) 56 4.14.1. The Attribute qpOperator 56 4.14.2. The Attribute qpVariableAtom 57 4.14.3. The Attribute qpValueAtom 57 Snir, Ramberg, Strassner expires April 2000 4 Draft-snir-qos-policy-schema-01.txt October 1999 4.15. Class qosPolicyVariable 57 4.15.1. The Attribute qpVariableName 57 4.15.2. The Attribute qpVariableType 58 4.15.3. The Attribute qpVariableID 58 4.15.4. The Attribute qpVariableDescription 58 4.15.5. The Attribute qpValueConstraints 58 4.16. Class qosPolicyConstant 59 4.16.1. The Attribute qpConstantName 59 4.16.2. The Attribute qpConstantID 59 4.16.3. The Attribute qpConstantDescription 59 4.16.4. The Attribute qpValueRef 60 4.17. Class qosPolicyValue 60 4.17.1. The Attribute qpValueType 60 4.17.2. The Attribute qpValueDescription 60 4.18. Class qosPolicyIPAddrValue 61 4.18.1. The Attribute qpIPAddress 61 4.18.2. The Attribute qpIPMask 61 4.19. Class qosPolicyStringValue 61 4.19.1. The Attribute qpStringValue 62 4.20. Class qosPolicyNumberValue 62 4.20.1. The Attribute qpNumberValue 62 4.21. Class qosPolicyNumberRangeValue 62 4.21.1. The Attribute qpNumberFromValue 63 4.21.2. The Attribute qpNumberToValue 63 4.22. Class qosPolicyAtomFolders 63 4.22.1. The Attribute qpFolderList 63 4.23. Class qosPolicyAtomFolder 64 4.23.1. The Attribute qpVariableDNs 64 4.23.2. The Attribute qpConstantDNs 64 4.24. Class qosPolicyConditionFolder 65 4.24.1. The Attribute qpConditionList 65 4.25. Class qosPolicyDSPolicerFolder 65 4.25.1. The Attribute qpDSPolicerList 65 4.26. Class qosPolicyRSVPPolicerFolder 66 4.26.1. The Attribute qpRSVPPolicerList 66 4.27. Class qosPolicyPHBFolder 66 4.27.1. The attribute qpPHBSetList 66 4.28. Class qosPolicyPHBSet 67 4.28.1. The attribute qpSCList 67 4.28.2. The attribute qpPHBName 67 4.29. Class qosPolicyServiceClass 67 4.29.1. The attribute qpServicePolicer 68 4.29.2. The attribute qpServiceDSCP 68 4.29.3. The attribute qpServiceTransmitFactor 68 4.29.4. The attribute qpServiceBufferFactor 68 4.30. Class qosPolicyTriggerEvent 69 4.30.1. The Attribute qpTriggerType 69 Snir, Ramberg, Strassner expires April 2000 5 Draft-snir-qos-policy-schema-01.txt October 1999 5. Extending the QoS Policy Schema 69 5.1. Subclassing qosPolicyValue 69 5.2. Subclassing qosPolicySimpleCondition 70 5.3. Subclassing qosPolicyAction 70 6. Security Considerations 70 7. Acknowledgments 70 8. References 71 9. Author's Addresses 71 10. Full Copyright Statement 72 Snir, Ramberg, Strassner expires April 2000 6 Draft-snir-qos-policy-schema-01.txt October 1999 1. Introduction The purpose of introducing a standard QoS Policy schema is to provide a means for different Policy Servers and management tools from different vendors to interoperate with each other when configuring various types of QoS mechanisms in network devices from multiple vendors. Two different forms of interoperability are envisioned: - multiple QoS Policy Servers can interoperate with each other - multiple Policy Servers, each belonging to one or more different disciplines (e.g., Security, IP Address Management, or QoS) can interoperate with each other, including the ability to share information defined in the directory server between them In each case, the purpose of interoperability is to be able to exchange policy information and coordinate the application of policies to network elements between different Policy Servers. In general, the network will consist of many different heterogeneous devices, most of which have to be controlled by a given set of policies. The problem is that both the number of devices as well as their inherent differences in their capabilities makes it impossible for a single Policy Server to control the configuration of network resources for heterogeneous network devices. The interoperability provided in this schema enables the network to be partitioned into smaller groups of devices that are under a single administrative policy domain. Furthermore, it acknowledges that, due to the wide differences in functional capabilities that devices have, it is unreasonable to expect a single Policy Server to be able to control all types of devices. This schema enables multiple Policy Servers to communicate and exchange information, so that they can coordinate the application of policies to devices in the policy domains that they control. This section presents, describes and defines the concepts of the QoS Policy schema, its structure and organization, its relationships to the Core schema and issues related to correct usage of the schema. 1.1. Schemata Hierarchy The QoS Policy schema by itself may be insufficient to model a particular set of QoS services and systems. In general, one may have to derive implementation-specific classes from this schema in order to model a specific QoS system in sufficient detail. In fact, the QoS Policy schema is a middle layer in a three-level hierarchy of schemata: Core Policy Schema is extended by QoS Policy Schema is extended by Implementation-specific schemata Snir, Ramberg, Strassner expires April 2000 7 Draft-snir-qos-policy-schema-01.txt October 1999 The Core Policy schema models high-level policy concepts and introduces structural conventions and nomenclature common to all types of policies. The QoS schema refines the concepts of the Core Schema and introduces a framework of classes dedicated to model QoS Policy. The QoS Policy schema preserves the conventions and general spirit of the Core schema design. An implementation-specific schema should further concretize the QoS concepts of the QoS Policy schema into particular objects. Such a schema would add its own classes (both structural and auxiliary) to model a particular system. Such additional classes would, for example, be specific QoS actions that are undefined in the QoS schema. 1.2. Containment Hierarchy The fundamental data model of the QoS Policy schema is a strict tree hierarchy. Figure 1 shows a summary view of the class containment hierarchy. ------------- ------------- |qosPolicyRoot| -.-.-.->|qosRepository| ------------- ------------- | | --------------+---------- ----+------------------- | Scope for | | | | ---------- | | Policy | | | |-->|Conditions| | | Admin V | | | ---------- | | --------------- | | | -------- | | |qosPolicyDomain| | | |-->|Policers| | | ----------------- | | | -------- | | |qosPolicyDomain| | | | -------- | | ----------------- | | |-->| PHBs | | | |qosPolicyDomain| | | | -------- | | --------------- | | | -------- | | | | -->| Atoms | | | | | -------- | ------------------------ ------------------------ ------> Containment. -¸¸-¸¸> DN Reference -¸-¸-¸> Implied containment. That is, the qosPolicyRoot class would not contain an instance of the Repository class, but would rather contain instances of the subclasses of the Repository class. Figure 1: QoS Policy class containment - major classes The hierarchy is structured as containment relationships: Container objects that include sets of DNs of contained objects model the branch- to-leaf relationships. For example: A named policy container includes a list of DNs of the contained rules. Section 2.1 describes the use of DNs in the schema. Snir, Ramberg, Strassner expires April 2000 8 Draft-snir-qos-policy-schema-01.txt October 1999 With respect to the Policy Framework core information model and schema specifications, containers are usually based on auxiliary classes (section 2.2). A container, then, may be attached to a branch level class so that leaves may be added. In addition, an entity may refer (by means of DN) to a reusable object. Reusable objects reside in repositories (i.e., a special area within the DIT) and can be referenced by multiple users. Reusable object references cross the containment hierarchy and are not considered part of the policy tree structure. Section 1.2.1 describes the reusable object repositories. Policy applications do not own the DIT; rather, they must work within an existing DIT. Consequently, this means that there is no standard organization of objects to be controlled via policy. This makes it hard to associate policy objects with other objects in the DIT efficiently. One solution to this problem is to extend the DIT structure and build a special portion reserved for policy objects. This avoids needless replication of policy objects, and promotes reusability of policy objects. The root of the policy portion of the DIT is a single-instance object qosPolicyRoot, derived from the PolicyGroup class in the Policy Core Schema. The qosPolicyRoot object provides scoping for two main branches of the policy schema: reusable-objects repositories and a policy tree that contains policy rules and their building blocks. These main branches divide the tree into two major sections: a policy definition section and a section containing reusable-object repositories. Figure 1 shows that the qoSPolicyDomain container provides scoping for the application of one or more policy groups of PolicyRules. Each qoSPolicyDomain can contain its own set of PolicyRules and groups of rules. Multiple PolicyRules can be contained in a single qoSPolicyDomain. The second branch is the reusable-objects repository section. This is information that all qoSPolicyDomains can use, and is divided into different categories of information (conditions, actions, etc.). This lets multiple policy servers in different policy domains share and reuse common information. The following sub-sections describe the QoS Policy schema major classes and the relationships among them. The description follows the division into the two major sub-trees depicted in Figure 1: policy definitions (which are rooted in qoSPolicyDomains) and policy repositories. Snir, Ramberg, Strassner expires April 2000 9 Draft-snir-qos-policy-schema-01.txt October 1999 1.2.1. Reusable-objects repositories Reusable objects are entities that can be referenced (through DN type attributes) by one or more other entities in the QoS policy schema tree. For example, different policy rules (which are all instances of the qosPolicyRule class) may contain references to the same condition object (qosPolicySimpleCondition) that resides in the repository. This enables these different policy rules to use (in this case) the same policy condition to represent, for example, a common event that is occurring. A reference to a reusable object is not part of the hierarchy; these references cross the tree structure as depicted in Figure 1. The data model requires that every reusable object have a unique name attribute within its defined scope. The purpose of this requirement is to establish a clear and unambiguous identity for objects. To accomplish name uniqueness, an implementation-specific schema should enforce RDN semantics for the identified naming attributes for the reusable objects as specified in this draft. The benefits of using reusable objects over use of "ad-hoc" instances are as follows: * Minimal objects required for loading - DIT constructors may define an object once and "use it" multiple times by referring to it from multiple entities. * Encapsulation - concepts that can be used as part of multiple conditions and/or multiple actions, such as constants, can be encapsulated in an object. This improves reuse by separating the definition of the concept from the definition of the policy. For example, defining a constant with a well known name, such as "source port for web traffic" allows DIT constructors to define policies using that constant without knowing the real port number of web traffic in this domain. * Data integrity - LDAP has no referential integrity mechanisms. Consequently, the problem of maintaining changes to an object in the DIT is especially difficult when different policy rules are using copies of the same policy objects. Each change the user makes to one of these objects must be made to ALL of the copies of this object in the DIT (preferably as an atomic transaction), in order to ensure consistent behavior of the network. Two solutions to this latter problem exist. The first is to either extend LDAP, or to write custom code that attempts to enforce referential and transactional integrity. The second is a much simpler solution. It advocates maintaining a single object in a special section of the DIT (e.g., the "reusable-objects repository") which all applications know about. Then, each application can simply reuse this object where required through a DN reference. Now, every change to this object need only be performed once, and will immediately effect all policies that contain a DN reference to it. It therefore eliminates completely the need to add transactional and referential integrity in the directory server, and greatly reduces the need for multi-step transaction support for applications using this feature. Snir, Ramberg, Strassner expires April 2000 10 Draft-snir-qos-policy-schema-01.txt October 1999 Reusable objects provide flexibility, but are inherently in conflict with applications that need to retrieve policy objects quickly and efficiently. In fact, some object classes may be used both to create reusable objects as well as non-reusable, "ad-hoc", objects. Such is the case with the qosPolicySimpleCondition class, for example. This requires a compromise in the naming attributes used for such classes. The solution is to use auxiliary classes and two different structural classes that they will be attached to - a PolicyRule (for rules that are not shared) and a PolicyRepository (for rules that are shared). This will be explained in more detail in subsequent sections of this document. However, the important point is that reusability is NOT the policy rule, but rather the policy conditions and actions that can be used in a policy rule. A reusable object may be more "expensive" to use than an ad-hoc object when using LDAP. This is because of the extra LDAP reference(s) involved in accessing a repository-resident object. Reusable objects are constructed as follows: 1. A unique name, used as an RDN, must be assigned to the reusable object instance. 2. Many reusable objects defined in this document are built as auxiliary classes (this is discussed later). If the reusable object is an auxiliary class, then that reusable object must be attached to a structural class before it can be referenced, usually the PolicyInstance class [PFCORE]. 3. The DN of the (structural) class (that is either the reusable object (if the reusable object is a structural object) or a structural class that the reusable object is attached to) is added to the particular repository. The qosPolicyRoot object contains a DN reference to a repository container, of type PolicyGroup, containing up to 5 repositories (some nested) of reusable-objects. Specific extensions of the QoS policy schema may add other type of repositories, as needed. The following subsections describe the reusable objects and their organization in repositories. 1.2.1.1. Repository structure Figure 2 shows a summary view of the reusable objects repositories structure. All repository classes are derived from the Core class Policy, which adds the commonName, caption, description and policyKeywords attributes. The commonName attribute contains the specific Folder name (please see [PFCORE] for generalized definitions and [PFSCHEMA] for LDAP definitions of the other attributes). Beyond this, each repository has a specific internal structure that is described in the following sub-sections. Snir, Ramberg, Strassner expires April 2000 11 Draft-snir-qos-policy-schema-01.txt October 1999 The presence of repositories in the DIT is optional. The root of the QoS policy portion of the DIT (qosPolicyRoot) MAY contain a DN attribute (qoSPolicyRepositoryRoot) that points to an instance of the qosPolicyRepository class. This class is used as a common "repository- in-the-repository", providing the ability to place reusable entities (e.g., conditions and actions) in a common place. This enables common administration of the reusable terms, and helps mitigate the lack of referential integrity in LDAP. The qosPolicyRepository class is a single instance "holder" class. Adding QoS policy repositories to the holder class is done by attaching a container class (QosRepositoryContainmentAuxClass) to the qosPolicyRepository class instance and populating one of its attributes (QoSRepositoryContainmentAuxSet). This attribute contains a list of DNs of the repositories that are in the QoS policy subtree. +--------------+ | Repositories | +-----------------+ +--|-----------+ ->|qosPolicyVariable| | | +-----------------+ | +--------------------+ | |---->|qosPolicyAtomFolders| | +-----------------+ | +--|-----------------+ |->|qosPolicyConstant| | | +-------------------+ | +-----------------+ | ->|qosPolicyAtomFolder|- | +-------------------+ | | +------------------+ +------------+ |---->|qosPolicyPHBFolder|--->|qosPolicyPHB| | +------------------+ +------------+ | | | | +---------------------+ | -->|qosPolicyServiceClass| | +---------------------+ | | +------------------------+ +------------------+ |---->|qosPolicyConditionFolder|---->|qosPolicyCondition| | +------------------------+ +------------------+ | +------------------------+ +------------------+ |---->|qosPolicyDSPolicerFolder|---->|qosPolicyDSPolicer| | +------------------------+ +------------------+ | +--------------------------+ +--------------------+ ---->|qosPolicyRSVPPolicerFolder|----->|qosPolicyRSVPPolicer| +--------------------------+ +--------------------+ Figure 2: Reusable objects repositories Snir, Ramberg, Strassner expires April 2000 12 Draft-snir-qos-policy-schema-01.txt October 1999 1.2.1.1.1. Atom Folders The QoS Policy schema provides a means for creating named variables and values (constants). Variables and constants are called atoms and are modeled by the qosPolicyConstant and qosPolicyVariable classes. A variable consists of a name and a type. A constant consists of a name and a value. In the QoS Policy schema, values are tagged with a data type. The following section contains a detailed description of the structure of the atom folders repository and details of the structure and usage of atoms. 1.2.1.1.1.1. Using Atoms A typical use of atoms is in the formation of simple conditions (qosPolicySimpleCondition, section 1.2.1.3). For example: to form the Boolean expression 'SourceIPAddress == MyServerAddress', a variable of type IPAddress named 'SourceIPAddress', an operator '==' that denotes an equality logical relation, and a constant of named 'MyServerAddress' that holds the IP address of a machine called MyServer are used. Section 1.2.1.3 explains how to construct Boolean expressions (conditions) and how to use them in policy rules. Specific-implementation schemata may also use atoms for holding various named entities used as "system entities". For example: an implementation-specific schema may wish to introduce meaningful constants such as PhoneBookURL, HelpDeskSourcePort, CEOHostIP, etc. into the schema, so that these constants could be used in multiple policies. An obvious advantage of using atoms is the ability to refer to a value by quoting its name instead of copying the actual value every time it is used. This reduces the chance of errors and omissions in copying the value. The indirection also enhances central maintenance of widely used values. For example: If the IP address of the machine used by the CEO has changed, all that needs to be done is to change the value of the CEOHostIP constant. All expressions referring to CEOHostIP constants will reflect the change "automatically". 1.2.1.1.1.2. Atom Folders Organization Atoms are organized in named folders, thus providing multiple namespaces for constants and variables. Each atom folder contains two repositories, one for variables and one for constants. An implementation-specific schema can create as many folders as it needs. Snir, Ramberg, Strassner expires April 2000 13 Draft-snir-qos-policy-schema-01.txt October 1999 For example: It would make sense for an implementation-specific schema to create folders for application parameters, one per application: OracleFinancialsParameters, CorporateIntranetSettings, SystemProperties, etc. The OracleFinancialsParameters folder may holds atoms such as TransactionType variable, OracleFinancialsURL constant etc. that are logically different than the constants and variables defined in the other folders. Each folder establishes a well-defined namespace and scope for its contained atoms. An individual named folder (qosPolicyAtomFolder) must contain a name (i.e., the commonName attribute) and may contain (up to) two lists of DNs: one for the variables (qosPolicyVariables) and one for the constants (qosPolicyConstants). Because both qosPolicyVariable and qosPolicyConstants are auxiliary classes, they can't be referenced directly. To instantiate a variable (or a constant) and place it in the repository, the qosPolicyVariable class (or the qosPolicyConstant class) must first be attached to an instance of the PolicyInstance class (derived from the core schema). This is a structural class used as a holder for the actual variable (or constant). The DN of the instance of the PolicyInstance class holding the attached object is then added to the DN list of the appropriate folder (qosPolicyVariables or qosPolicyInstance). 1.2.1.1.1.3. Variable The variable class (qosPolicyVariable) models the concept of variable used in the simple conditions. The class qosPolicyVariable has two required attributes: name (qosPolicyVariableName) and type (qosPolicyVariableType). The type attribute is of type OID and its allowed values are specified in [LDAP_ATTR]. Variables are bound to values in specific contexts. For example: When evaluating a simple condition, the policy server and/or network device) must check the type/value conformance rules for incompatibility. Conformance rule violations are considered errors that prevent the evaluation of the condition. For example: the simple condition 'MyNTStationAddress == '144.254.93.72' uses a variable named MyNTStationAddress of type IP_ADDRESS (see section 1.2.1.1.1.7), which declares the appropriate data type for this variable. The variable must be bound to a value before the condition's Boolean expression can be evaluated. Section 1.2.1.2 discusses variable binding. Variables may contain value constraints. A variable may contain a list of DNs pointing to constants (qosPolicyConstant) representing the allowed values it can be assigned (policyValueConstraints). For example: The TransactionType variable in the OracleFinancialsParameters folder may contain the following value constraint constants: UrgentQueryTX, GeneralLedgerTX, DBReplicationActivityTX, and others. Snir, Ramberg, Strassner expires April 2000 14 Draft-snir-qos-policy-schema-01.txt October 1999 Each of these variables has a specific meaning to the OracleFinancials application. The implementation-specific system can implement a logical value acceptance test of the data entered by using the variable value constraint. 1.2.1.1.1.4 Constant Constants are named values. The class qosPolicyConstant models a constant. A constant MUST have a name (qosPolicyConstantName). The constant's value MAY be referenced by a DN (attribute qosPolicyValueRef) or contain an actual value by attachment of an instance of the qosPolicyValue class. Note that qosPolicyValue is an abstract class. To create a value, one should use the appropriate derived auxiliary class that represents a specific value type (e.g., qosPolicyNumberValue). In the text , the term qosPolicyValue is used to represent the derived auxiliary classes from the abstract class. Using constants, one may name and reuse values. For example: the number '80' is used for the port number of WEB servers. One may create a constant named WEBPort and attach to it the value '80' of type integer. This constant can now be placed in a repository and can be referenced from simple conditions in many policy rules. An example of such a condition is 'SourcePort == WEBPort', where 'SourcePort is a variable and WEBPort is a constant. 1.2.1.1.1.5. Operators and Relations Operators and relations are defined in association with a specific type, i.e., the "equal" operator associated with an Integer is not the "equal" operator associated with a String. Policy servers and policy management tools must conform to the standard operators that manipulate the types of operands appropriate for a given type of policy condition in order to share policy information and to have a consistent interpretation of the policy rules. An operator consists of an operation ('EQUAL', 'IN_RANGE', etc.) and a Data Type. Again, the operation defined by a particular operator may have different semantics; these semantics are determined by the semantics of the data type to which the operator applies. The following sub-section enumerates the allowed operators for the most common data types. Snir, Ramberg, Strassner expires April 2000 15 Draft-snir-qos-policy-schema-01.txt October 1999 1.2.1.1.1.5.1. Integer The following operators are defined for INTEGER, as defined in [LDAP_ATTR]: ¸ EQUAL - 'integerMatch' defined in [LDAP_ATTR]. The operator EQUAL would be interpreted as IN for set or range of integers. ¸ NOT_EQUAL - Inverse of EQUAL operator. The operator NOT_EQUAL would be interpreted as NOT_IN for set or range of integers. ¸ GREATER_THAN (>) - First operand is numerically larger then the second operand of this relation. ¸ GREATER THAN OR EQUAL_TO (>=) - First operand Integer size is numerically larger or equal to the second operand of this relation. ¸ LESSS_THAN (<) - First operand Integer size is numerically smaller then the second operand of this relation. ¸ LESS THAN OR EQUAL TO (<=) - First operand Integer size is numerically smaller or equal to the second operand of this relation. 1.2.1.1.1.6. String The following operators are defined for STRING, as defined in [LDAP_ATTR]: ¸ CIS_EQUAL - "caseIgnoreSubstringsMatch" ¸ Case Ignore Equal ¸ CSS_EQUAL - Case sensitive Equal ¸ CIS_STR_MATCH - Supports matching rules such as wildcards (*) single character all match 1.2.1.1.1.7. IP address (IPv4 and IPv6) The following operators are defined for IP_ADDRESS: ¸ EQUAL - See CIS_EQUAL for String ¸ NOT_EQUAL -See CIS_EQUAL for String 1.2.1.1.2. Value Values are modeled by the qosPolicyValue abstract class. Object instances of classes that are derived from qosPolicyValue contain the actual bits of the data and a data type tag. Specific value types (e.g. integer, IP address) are modeled by auxiliary classes that are derivatives of qosPolicyValue. Note that an appropriate subclass of the qosPolicyValue class (representing the specific type of value that is being tested) should be used, not qosPolicyValue itself. The appropriate subclass must be attached to a PolicyInstance structural "holder" class (or any other structural class) before it can be used. For example: The class qosPolicyNumberValue models a numeric value. Snir, Ramberg, Strassner expires April 2000 16 Draft-snir-qos-policy-schema-01.txt October 1999 Values are not reusable and are not named. To reuse named values one should employ constants (section 1.2.1.1.1.4). Values may be instantiated in 3 different ways: a single value, a set of values, or a range of values. An example to a single Number value would be 1, a set would be {1, 5 and 15} (but none of the intermediate value 2-4 and 6-14) and a Range would be [2 to 18] (meaning all values from 2 up through and including 18). To use a value, one must create an instance of the specific type value class and set the actual data1. Values are important, because they can be used to separate the definition of a condition (which uses a constant) from the actual value of the constant. Continuing the above example, the constant "WEBPort" can be defined by attaching an instance of the qosPolicyNumberValue class (which is an auxiliary subclass of the abstract qosPolicyValue class) to an instance of the PolicyInstance class. The PolicyInstance class would then be responsible for associating the value of the qosPolicyNumberValue instance with the value of the above qosPolicyConstant class. This indirection is necessary because certain directories require auxiliary classes to be derived only from the Top class. Finally, note that the qosPolicyValueType attributes is of type OID. Types are defined in [LDAP_ATTR]. 1.2.1.2. 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 'sourceport == 80', the variable 'sourceport' must be instantiated to a value and logically associated with the packet header field containing the source port number, for the expression to be evaluated. If, in this example, the variable sourceport is bound to a value of '80', then the expression is evaluated to TRUE for each packet that the source port number in the IP header field equals 80. Otherwise it is evaluated to FALSE. Snir, Ramberg, Strassner expires April 2000 17 Draft-snir-qos-policy-schema-01.txt October 1999 1.2.1.2.1. Pre-defined Variables The purpose of this section is to explain the need and define the relationship of standard, frequently used variables with their logical entities. Pre-defined variables are necessary for ensuring interoperability among policy servers and policy management tools from different vendors. For example, different policy servers may have to evaluate the same policy rule. Variables enable the condition term to be abstracted such that its evaluation can be performed in the same way. In addition, if these variables are stored in the reusable-objects repository (portion of the DIT), then multiple management applications can access this same variable and reuse and share information among themselves. The QoS Policy information model specifies a set of pre-defined variables to support the fundamental QoS variables such as IP header fields, user information, application unique ID, etc. A pre-defined variable must always have the same name and binding semantics, i.e.: a given pre-defined variable should be bound to the same logical entity by all client systems (typically policy servers). Similarly, the pre- defined variable should be stored in the reusable-objects repository to enable reuse and sharing of the pre-defined variable. The definition of each predefined variable includes a standard name and the type of this variable. All standard variable names are case insensitive and do not include spaces or other non-standard characters. While all variables are tagged with a data type, the values might be of different categories (e.g., scalar, set or range), depending on the expression and the logical relation used. Note that an implementation- specific schema needs not define binding methods for all pre-defined variables. Only variables that are used in expressions in DITs must be provided binding methods to fulfill the requirements of the QoS Policy schema. The implementers of client systems that use the QoS Policy schema must provide binding methods to bind pre-defined variables according to the semantics specified in this section. 1.2.1.2.1.1. IP Header Variables IP header elements are frequently used for QoS policy definitions, and are expected to appear in most schemata representing QoS Policies. Pre- defined variables are provided for both IPv4 and IPv6 header elements. 1.2.1.2.1.1.1. Source IP address IPv4 The source IP address is bound to the IPv4 header source IP field. Variable Name: "sourceipv4" Type: String Snir, Ramberg, Strassner expires April 2000 18 Draft-snir-qos-policy-schema-01.txt October 1999 1.2.1.2.1.1.2. Source IP address IPv6 The source IP address is bound to the IPv6 header source IP field. Variable Name: "sourceipv6" Type: String 1.2.1.2.1.1.3. Source Port The source IP port number is bound to the IP header source port field. Variable Name: "sourceport " Type: Integer 1.2.1.2.1.1.4. Destination IPv4 address The destination IPv4 address is bound to the IPv4 header destination IP field. Variable Name: "destinationipv4" Type: String 1.2.1.2.1.1.5. Destination IPv6 address The destination IPv6 address is bound to the IPv4 header destination IP field. Variable Name: "destinationipv6" Type: String 1.2.1.2.1.1.6. Destination Port The destination IP port number is bound to the IP header destination port field. Variable Name: "destinationport " Type: Integer 1.2.1.2.1.1.7. Protocol Number The protocol number is bound to the IP header protocol field. Variable Name: "ipprotocol" Type: Integer 1.2.1.2.1.1.8. ToS Value The ToS variable is bound to the IP header ToS byte. Variable Name: "tos" Type: String The following string would model the ToS Byte: XXXXXXXX - X is either 0 or 1. Snir, Ramberg, Strassner expires April 2000 19 Draft-snir-qos-policy-schema-01.txt October 1999 1.2.1.2.1.2. Layer 2 Variables 1.2.1.2.1.2.1. Destination MAC address The destination MAC address Variable is bound the frame destination MAC address. Variable Name: "destinationmac " Type: String, representing the IEEE canonical representation of the destination MAC address. 1.2.1.2.1.2.2. Source MAC address The sourec MAC address Variable is bound the frame source MAC address. Variable Name: "sourcemac" Type: String, representing the IEEE canonical representation of the source MAC address. 1.2.1.2.1.2.3. 802.1Q ID The VLAN ID as represented in the 802.1Q field of the header Variable Name: "8021qid" Type: Integer 1.2.1.2.1.2.4. SNAP Protocol The snap protocol variable is bound the frame field that contains the SNAP value. Variable Name: "snap" Type: Integer 1.2.1.2.1.2.5. Ethertype The ethertype variable is bound to the frame header ethertype value. Variable Name: "ethertype" Type: Integer 1.2.1.2.1.2.6. Source SAP The ssap variable is bound the frame header field containing the source SAP. Variable Name: "ssap" Type: Integer 1.2.1.2.1.2.7. Destination SAP The dsap variable is bound the frame header field containing the destination SAP. Variable Name: "dsap" Type: Integer Snir, Ramberg, Strassner expires April 2000 20 Draft-snir-qos-policy-schema-01.txt October 1999 1.2.1.2.1.3. Application Variables 1.2.1.2.1.3.1. Application name A case insensitive string representing the application name variable. Variable Name: "applicationname" Type: String - cis 1.2.1.2.1.3.2. Application unique id A case insensitive string representing an application unique ID variable, such as a WIN32 GUID. Variable Name: "applicationuniqueid" Type: String - cis 1.2.1.2.1.4. Host Variables 1.2.1.2.1.4.1. Host name A case insensitive string representing the host / server name variable. Variable Name: "hostname" Type: String - cis 1.2.1.2.1.4.2. Host group - domain A case insensitive string representing the host domain or group variable. Variable Name: "hostdomain" Type: String - cis 1.2.1.3. Simple Conditions Simple conditions are Boolean expressions of the following form: ' '. Simple conditions are used as building blocks for complex conditions, involving combinations of disjunctive simple condition lists, conjunctive simple condition lists and negations of individual simple conditions. Simple conditions are also used to provide optimized access for policies that do not contain references to one or more additional objects. In other words, a simple condition is a special type (i.e., a subclass) of PolicyCondition that contains the condition embedded in the PolicyRule (as opposed to referencing one or more additional objects that contains the condition). Section 2.3.2 contains a detailed discussion of condition construction and usage. Snir, Ramberg, Strassner expires April 2000 21 Draft-snir-qos-policy-schema-01.txt October 1999 To place an instance of the qosPolicySimpleCondition in the repository, it must be attached to an instance of the PolicyInstance class. This is because the qosPolicySimpleCondition class is an auxiliary class, and must be attached to a structural class in order to be instantiated. An instance of this PolicyInstance object is added to the resuable-objects repository. PolicyRules that want to reference this condition do so by placing a DN pointing to this PolicyInstance object in their appropriate attribute. This enables a single PolicyInstance object to be reused by multiple PolicyRules, no matter where the PolicyRules are located in the DIT. 1.2.1.4. Policers The QoS Policy schema defines two categories of policers repositories: DS policers and RSVP policers. A policer object that is in the reusable-objects repository may be referenced by any instance of the qosPolicyRule, or any of its subclasses. A reusable policer may either be shared or private. A private policer is one that affects a single PolicyRule. A shared policer is one that affects multiple PolicyRules which reference it. To designate a policer as shared, the value of the isShared attribute of that policer is set to TRUE. By default, policers are not shared. To modify a policer from being shared to being private, the value of the isShared attribute of that policer is set to FALSE. For example, a DS policer DSP1 is a private reusable policer. It is used by the PolicyRules R1, R2 and R3. This means that an instance of the DSP1 object is referenced by the DiffServPolicer attribute of the qosPolicyDSPolicerAction objects associated with those rules. The excess burst limit set by this policer is 100 kbps. Because this is a private policer, the rules are interpreted to have excess burst limit of 100 kbps for each. Now, if we make DSP1 a shared policer, the PoliyRules R1, R2 and R3 will share an excess burst limit of 100 kbps together. Using a private reusable policer has the same effect as attaching three identical policers to each of the rules. Using a shared policer has the effect of policing three rules with one aggregate policer. 1.2.1.4.1. DS policers The qosPolicyDSPolicerFolder object is a repository of Differentiated Services (DS) policers, providing a grouping of objects that control aggregate service-level limit settings. A DS policer can be referenced by instances of the qosPolicyAction class. Snir, Ramberg, Strassner expires April 2000 22 Draft-snir-qos-policy-schema-01.txt October 1999 1.2.1.4.2. RSVP policers The qosPolicyRSVPPolicerFolder object is a repository of RSVP policers, providing a grouping of objects that represent individual flow limits based on RSVP concepts. An RSVP policer can be referenced by instances of the qosPolicyAction class. 1.2.2. Per Hop Behavior Per Hop Behaviors (PHBs) are objects that represent traffic conditioning of service classes as defined by the Differentiated Services Working Group of the IETF. These objects are stored in the PHBFolder, which is a container in the reusable-objects repository contained in the DIT. PHBs are used to specify domain wide parameters and service classes. PHBs are fundamental concepts in the Differentiated Services QoS paradigm and model as defined in [DIFF-SERV-ARCH]. Each PHB is a set of service classes. Each service class specifies a group of QoS parameters associated with a single Differentiated Services Code Point (DSCP) as defined in the [DIFF-SERV-ARCH]. 1.2.2.1. PHB Set PHB set is a named container for qosPolicyServiceClass objects. A single PHB set is associated (i.e., referenced) with a QoS domain using the domain attribute defined in the qosPolicyDomain object. DIT constructors establish this association. A system administrator may select the appropriate PHB from the repository and associate it with a specific QoS domain by referencing it using a DN. To refine definition of PHBs, and/or to further restrict the namespace in which a particular PHB is used, the domain PHB can contain additional containers, which are qosNamedPolicyContainers. The qosNamedPolicyContainers can override the domain's PHB set by referencing another PHB set via the qosPolicyPHBSet attribute. This will enforce a specific PHB set on the qosNamedPolicyContainers' set of rules. Policy Servers use the domain's PHB to derive configuration parameters for all devices in a QoS Domain. If a policy container is associated with a PHB, this PHB set overrides the domain PHB set. This combination provides a two-level configuration mechanism: domain-wide and specific to a policy container in a particular domain. While the approach defined in the Differentiated Services RFCs defines 64 service classes, a PHB set does not have to contain a member for each possible service class. Snir, Ramberg, Strassner expires April 2000 23 Draft-snir-qos-policy-schema-01.txt October 1999 In order to ensure consistent behavior, each policy rule may be associated with a single PHB service class. The service class, denoted by the value of the DSCP, is selected from the PHB set specified for the policy container (i.e., an instance of the qosPolicyNamedContainer object). If the container has no PHB set associated with it, then the service class is defined in the PHB set associated with the domain (i.e., an instance of the qosPolicyDomain object). 1.2.2.2. Service class The qosPolicyServiceClass object models a single service class. Flows colored with the relevant DSCP value are viewed as members of the service class for this DSCP value. (Note that the value of a DSCP is also known as its color.) The qosPolicyServiceClass is an abstract class, which is intended to be extended by vendor-specific implementations with the information required to model a PHB service class. The PHB service class is an abstraction over device-specific parameters. No actual device-specific or interface specific configuration is to be specified. Rather, the service class should contain generic parameters that specify the service in abstract terms. Instead of designating, for example, a specific queue or threshold for the class, the service class defines a parameter that is interpreted and translated into specific device queue and threshold parameters. This way, different devices can be made to provide a certain service even when the device capabilities are different. A certain transmit factor may be interpreted differently by different devices to use different technologies to the same abstract end. Service classes within the same PHB set are interrelated. Each service class is specified in relation to other service classes in the same set. This means that from the user's point of view, only the complete set specifies the general PHB; individual service class merely define the relation of this service to other services, as in: "Packets in this class are twice as likely to be forwarded as the packets in that class". 1.3. Policy tree The body of the DIT that contains the policy definition is called the policy tree, this is where all domains of a given policy system are located in the directory. It is important to note that there is no fixed location in the DIT where the policy objects are rooted, i.e., the qosPolicyDomains entry may be located anywhere in the DIT. The schema merely express containment relationships among objects by means of containers as described in the Core schema [CORE]. Figure 3 shows a summary view of the policy tree. Snir, Ramberg, Strassner expires April 2000 24 Draft-snir-qos-policy-schema-01.txt October 1999 +----------------+ |qosPolicyDomains| +--|-------------+ | +---------------+ -->|qosPolicyDomain| +-|-------------+ | +-----------------------+ -->|qosNamedPolicyContainer| +-|---------------------+ | +-------------+ -->|qosPolicyRule| +-|-----------+ | | +------------------------+ |-->|qosPolicySimpleCondition| | +------------------------+ | | +---------------+ |-->|qosPolicyAction| +---------------+ Figure 3: Policy tree containment 1.3.1.1. Overview The policy tree hierarchy is constructed by subclassing the PolicyGroup class of the Policy Core schema [PFCORE] and its associated auxiliary container classes. The root of the policy tree (qosPolicyDomains) is a subclass of the PolicyGroup class. This has the semantics of grouping a set of groups of policy rules using the PolicyGroupContainmentAuxClass. Its members are instances of the qosPolicyDomain class. The general strategy assumes that a given QoS policy domain (using the qosPolicyDomains class) represents all of the policies of a given entity (e.g., enterprise or Service Provider). It further assumes that this domain will need to be partitioned; hence, the use of qosPolicyDomain instances to represent the partitions of the overall system. The qosPolicyDomain class also extends the PolicyGroup class as a group of groups (of policy rules) using the same method as the qosPolicyDomains class. The members of each qosPolicyDomain container are instances of the qosPolicyNamedContainer class. The qosPolicyNamedContainer represents a named policy group that is scoped by the qosPolicyDomain container. It is derived from the PolicyGroup class as well. However, this extension models the ability of a PolicyGroup class to group a set of PolicyRules, using the PolicyRuleContainmentAuxClass, as opposed to grouping a set of PolicyGroups. The members of the policy group container are instances of the qosPolicyRule class. Snir, Ramberg, Strassner expires April 2000 25 Draft-snir-qos-policy-schema-01.txt October 1999 A given qosNamedPolicyContainer can only belong to a single domain. We model this by using specific containers to hold the policies for each domain. The containers provide a finer level of scoping, enabling policy rules to be defined that make use of a specific well-defined PHB set. Each domain can reuse various shared objects which are located in the (common) reusable-objects repository, but the policy rules themselves can not be shared between policy domains. A given policy rule (qosPolicyRule) must belong to one (and only one) policy group. Similarly, a policy group may belong to one (and only one) policy domain. This model is chosen because the units of reusability are the policy condition and action terms that comprise a policy rule, as opposed to the policy rule itself. This is because policy rules are complex objects that are made up of more basic, primitive objects, such as simple conditions (qosPolicySimpleCondition) and actions (qosPolicyAction). The policy rule itself has some important attributes that are unique to its specific placement inside the policy group and/or the policy domain. For example: the DSCP values a flow is colored (QoS action) may be interpreted differently in different domains as defined in the Per Hop Behavior (PHB) classes associated with this domain. This is why policy conditions and actions can be reused, but policy rules can not. The order of the rules inside a group is based on the value of the rule priority attribute [PFCORE]; the enforcement of policy rules also depends on particular settings belonging to the group. The match strategy to be applied to the rules contained in this container is defined in PolicyRuleMatchMethod attribute of the qoSNamedPolicyContainer object. 1.3.1.2. Discussion of the Containment Hierarchy The root of the policy tree is the (single) instance of the qosPolicyDomains class. The qosPolicyDomains extends the PolicyGroup class (which is defined in [PFCORE]), and is used as a container for the entries representing the various QoS domains in a given system. These are conceptualized as different subtrees of a system, enabling different administrative (or other) scoping of policy rules to be applied to different portions of a policy system. Each subtree is called a policy domain [see PLYTERM], and is modeled by the qosPolicyDomain class. The qosPolicyDomain class is intended to be used as the main QOS policy administration unit. Each qosPolicyDomain container contains an ordered list of QoS policy rule groups, which are implemented as instances of the qosPolicyNamedContainer class. The auxiliary class PolicyGroupContainmentAuxClass, which is defined in [PFCORE], is used to associate these qosNamedPolicyContainer objects to a specific qosPolicyDomain. Snir, Ramberg, Strassner expires April 2000 26 Draft-snir-qos-policy-schema-01.txt October 1999 The qosPolicyNamedContainers are used to contain ordered lists of policy rules, with additional attributes relevant to the specific QoS policy that is implemented in the (restricted) scope defined by the qosPolicyNamedContainer. Each qosNamedPolicyContainer object holds one or more PolicyGroup and/or qoSPolicyRule objects. The PolicyGroup object, which is defined in [PFCORE], can either hold additional PolicyGroup objects, or it can hold one or more PolicyRule or qosPolicyRule objects. The qosNamedPolicyContainer class has a defined priority to allow for a consistent decision process. That is, each policy rule has a priority internal to its group, and its group has a priority between groups. The decision strategy can also be defined per qosNamedPolicyContainer. Each qosNamedPolicyContainer may override the PHB set defined for its domain and use a different PHB set by referring the desired PHB. A given QoS policy domain can only belong to a single domain container. This is because reusable objects must be located in a specific portion of the DIT. Since policies that use a given PHB set are NOT reusable, we enforce this by using containers to hold the policies for each domain. The containers provide a finer level of scoping, enabling policy rules to be defined that make use of a specific PHB set. Thus, each domain can reuse various shared objects which are located in the (common) reusable-objects repository, but the policy rules themselves can not be shared between policy domains. This hierarchical structure is intended to provide flexibility and extensibility, so that applications that need to use sets of policies that are administratively scoped can use this approach as a standard structure. 1.3.1.3. Example of the Use of the Policy Containment Hierarchy The following example illustrates the hierarchical nature of the QoS Policy DIT. The root (qosPolicyDomains) has 2 direct children: 1. EastCoast (qosPolicyDomain) 2. WestCost (qosPolicyDomain). Each of the two policy domains have their own PHB set. The EastCoast domain has 2 policy rule groups, the first deals only with ERP flows and the second with all other traffic: 1. EastCoast (qosPolicyDomain) 1.1. ERP (qosNamedPolicyContainer) 1.2. General (qosNamedPolicyContainer). Snir, Ramberg, Strassner expires April 2000 27 Draft-snir-qos-policy-schema-01.txt October 1999 The WestCoast domain has 3 policy rule groups, 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 contain the rules relevant to ERP applications administrated by the west coast domain administrator. We see from the above structure that the administrator has 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 differently. 1.3.2. Policy Rule Implementation Policy rules that are QoS-specific are modeled by the qosPolicyRule class. The qosPolicyRule class is derived from the core class PolicyRule, and uses the rule container class PolicyRuleContainmentAuxClass, by attachment, to establish containment relationships between a policy and its components. The semantics of the qosPolicyRule are as follows: EnableFlag + Direction + Boolean expression + Action + other informational attributes. These semantics are defined as follows: * The EnableFlag is inherited from the policyRule class defined in [PFCORE]. This is an enumeration indicating whether a policy rule is administratively enabled, administratively disabled, or enabled for debug mode. Thus, it determines whether this qosPolicyRule is currently active and available for use in controlling entities in the managed environment or not. * Direction is defined in the qosPolicyRule class, and corresponds to the attribute PolicyDirection. It is an enumerated value that defines whether this policy applies to the input, output, or both interfaces. * Boolean expression is the condition (simple or complex) that is contained in the qosPolicyRule. * Action is the (set of) action(s) contained in the qosPolicyRule. * "Other informational attributes" correspond to various metadata that provide additional semantics for this policy. Snir, Ramberg, Strassner expires April 2000 28 Draft-snir-qos-policy-schema-01.txt October 1999 The interpretation of a policy rule in regard to a given network flow may be expressed as follows: "If the rule is enabled (EnableFlag == TRUE), and the flow direction is as specified in Direction and the Boolean expression is evaluated to TRUE, then use the Action to extract the prescribed treatment for this flow. The rest of this section describes the components of the qosPolicyRule class and their relationships to the other classes defined in this schema. 1.3.3. Simple and complex conditions Conditions (simple and complex) are used for determining if a certain PolicyRule applies to a given network flow. If the condition's expression evaluates to TRUE, then the PolicyRule applies and the action(s) specified is (are) taken. Many conditions in PolicyRules, from a networking perspective, are also known as Filters. Filters are not modeled directly in either the QoS Policy schema or the core schema (i.e., no Filter class is defined). However, the filter concept is quite central in the QoS Policy data model. Filters are modeled directly in the Network model being built in the DMTF, and are manifested in this schema as relationships between a policy rule and a structured list of groups of simple conditions. Filters are also modeled in the draft [DEVQMDL], which will be integrated with this draft in the near future. This section explains how the QoS Policy schema models simple and complex conditions to represent policy rule Filters. 1.3.3.1. Simple condition composition Simple conditions are used as building blocks to construct complex conditions, and may also be used directly by qosPolicyRules. The class qosPolicySimpleCondition models a simple Boolean expression of the form {variable; logical relation; value}. For example, the Boolean expression 'SourcePort == WEBServerPort') is modeled as a simple condition that contains the variable SourcePort of type Integer, the '==' logical relation (equality) and the constant named WEBServerPort of type Integer and a value (hidden inside the constant through representation as an auxiliary class that has been attached to the constant class). Variables are modeled by the qosPolicyVariable class. Similarly, named values are modeled by the qosPolicyConstant class, and "ad-hoc" values are modeled by the qosPolicyValue class. Snir, Ramberg, Strassner expires April 2000 29 Draft-snir-qos-policy-schema-01.txt October 1999 Simple condition composition must enforce the following type conformance rules: * The data type of the variable must be compatible with the data type of the constant * The logical relation must be compatible with the data type of the variable and the constant. * The schema itself can't model conformance rules, but these rules are an integral part of the information model and must be enforced by appropriate means (e.g., DIT content rules). For example: If the conformance rules are not enforced by the data entry agent, then it makes sense for a policy server to verify conformance when reading the values of an entry from the DIT. The schema defines six different ways to compose a simple condition through the combination of representations of variables, constants and values. To facilitate this, the classes qosPolicyVariable, qosPolicyConstant and qosPolicyValue are all auxiliary classes. The following combinations of representing a simple condition by DN references and attachment are possible: Variable representation 1. The class qosPolicyVariable may be directly attached to the qosPolicySimpleCondition instance. 2. The class qosPolicyVariable may be attached to an instance of the PolicyInstance class, which may then be referenced by a DN from the qosPolicySimpleCondition instance. (See section 2.2.1). Value representation (Note: qosPolicyValue is an abstract class. To create a value, the appropriate derived auxiliary class that represents the desired value type (e.g., qosPolicyNumberValue to represent an integer) should be used. In the following text, the term qosPolicyValue is used to represent the appropriate auxiliary class. 1. The qosPolicyValue class may be directly attached to the qosPolicySimpleCondition class. 2. The qosPolicyValue class may be attached to the qosPolicyConstant class. Note that the qosPolicyConstant class is an auxiliary class and must be attached to a structural class before becoming an entry. 3. The qosPolicyValue class may be attached to an instance of the PolicyInstance class, which may then be referenced by a DN from the qosPolicySimpleCondition instance. 4. The class qosPolicyConstant may be attached to an instance of the PolicyInstance class, which may then be referenced by a DN from the qosPolicySimpleCondition instance (see section 2.2.1.). Reusable vs. ad-hoc conditions Simple conditions are modeled by an auxiliary class and can not be directly instantiated. There are two ways to instantiate a simple condition: Snir, Ramberg, Strassner expires April 2000 30 Draft-snir-qos-policy-schema-01.txt October 1999 1. Attachment: A qosPolicySimpleCondition class may be attached to an instance of the qosPolicyRule (structural) class. 2. Indirect DN: A qosPolicySimpleCondition class may be attached to an instance of the PolicyInstance structural class, and then referenced through the policyRuleConditionList attribute of the PolicyRule or qosPolicyRule classes. This schema enables the reuse of simple conditions by placing them in a common portion of the DIT (called the reusable-objects repository). In order for a simple condition to be a member of this repository, it must be of the second kind (indirect DN) and must also carry a name (RDN type). 1.3.3.2. Using simple conditions In most cases, a simple condition is sufficient for the definition of a condition for a qosPolicyRule. A simple condition can be added to a qosPolicyRule in two ways: 1. A direct attachment of an instance of the simple condition to the qosPolicyRule instance. In this case we call this an "ad-hoc" simple condition. This method allows the creation of a "private" simple condition. This instance of the condition can't be referenced by any other policy rule, and so is not reusable. However, since it embeds the condition directly in the qosPolicyRule instance, it eliminates the extra access(es) required to fetch each of the condition elements that are pointed to by DNs. 2. Use the simple condition list attribute, policyRuleConditionList (defined in the PolicyRule class) to point to a repository- resident simple condition. This is called a reusable simple condition. This method allows the sharing of simple conditions by multiple policy rules. Ad-hoc simple filters are very efficient: They can be accessed with a single LDAP operation. Reusable simple filters are very flexible, but require an LDAP operation for each DN that is contained in the policyRuleConditionList attribute. Note that various optimizations are possible, for example fetching the condition repository prior to searching for rules. 1.3.3.3. Composing and using complex conditions A complex condition consists of groups of simple conditions (i.e., instances of either the policySimpleCondition and/or the qosPolicySimpleCondition classes) that are combined in either conjunctive or disjunctive normal form (as defined in [PFSCHEMA] and [PFCORE]), and special markings negating given simple condition elements in the complex condition, (e.g.: 'NOT (SourceIP == 1.1.1.0)'). Snir, Ramberg, Strassner expires April 2000 31 Draft-snir-qos-policy-schema-01.txt October 1999 A complex condition is modeled by 2 attributes: 1. PolicyRuleConditionListType - Boolean expression type (from the Core schema) that defines whether the simple condition is in conjunctive or disjunctive normal form. 2. Structured DN syntax - points to a list of simple conditions that are used to define the Boolean expression; the conditions are combined using syntax elements contained in the DN itself. (see [PFCORE]). The structured DN (SDN) syntax facilitates arbitrary logical relationships among simple conditions. SDN syntax and semantics are discussed in [PFCORE]. The SDNs may point to repository-resident simple conditions and/or ad- hoc simple conditions. Note that, as section 2.2.3.1 explains, simple conditions that are referenced by a DN must be attached to an instance of the PolicyInstance class, as the qosPolicySimpleCondition is an auxiliary class and can't be directly instantiated. Complex conditions must be composed from simple conditions that are indirectly instantiated (through DN pointers to the objects). However, simple conditions comprising complex conditions need not all be reusable. 1.3.4. Action The three different PolicyAction classes define the action to be applied to the flow that meets the PolicyRule's conditions. These objects may be used together as described in [PFCORE]. This version of the QoS Policy Schema models 3 types of actions, which are viewed as the most common and general actions for QoS applications. Additional actions may be added in future versions of this draft. 1. Coloring - setting and changing DSCP values. 2. DiffServ Policers - the process of discarding and shaping packets in a DiffServ-capable network element within a traffic stream in accordance with the state of a corresponding meter enforcing a traffic profile. 3. IntServ - Policers (RSVP). - the process of per session RSVP reservation creation in an IntServ-capable network in accordance with the state of a corresponding meter enforcing a traffic profile. RSVP actions include 2 types of policers to allow for admission control per direction. Snir, Ramberg, Strassner expires April 2000 32 Draft-snir-qos-policy-schema-01.txt October 1999 1.3.5. Decision strategy The decision strategy to be used by policy servers on the set of defined policies is defined per qosNamedPolicyContainer group. 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 defined per qosNamedPolicyContainer is valid for all policy rules, simple and nested, that are contained in the qosNamedPolicyContainer. The order of decision making of nested rules is defined by their priority and the general policy rule containing the nested rules. Example: General Rule 1 - priority 1 |- nested Rule 1 - priority 1 | |- nested Rule 2 - priority 2 Simple Rule 2 - priority 2 The resulting order of evaluation of policy rules is: nested Rule 1 nested Rule 2 General Rule 1 Simple Rule 2 Two decision strategies are defined: 1. "FIRST MATCH" 2. "MATCH ALL" 1.3.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 rules' conditions, until a condition is evaluated to TRUE. The rule's action is applied and the process of decision-making is complete. 1.3.5.2. Match All The match all decision strategy is a process of going over the complete set of rules according to their defined order of priority and 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 expires April 2000 33 Draft-snir-qos-policy-schema-01.txt October 1999 1.3.6. Inheritance Hierarchy for the LDAP QoS Policy Schema The following diagram illustrates the class hierarchy for the LDAP QoS Policy schema classes (Core classes are included): Top | +--policy (abstract) | | | +--qosPolicyRoot (structural) | | | +--policyGroup (structural) | | | | | +--qosPolicyDomains (structural) | | | | | +--qosPolicyDomain (structural) | | | | | +--qosNamedPolicyContainer(structural) | | | +--policyRule (structural) | | | | | +--qosPolicyRule (structural) | | | +--policyCondition (auxiliary) | | | | | +--policyTimePeriodCondition (auxiliary) | | | | | +--vendorPolicyCondition (auxiliary) | | | | | +--qosPolicySimpleCondition (auxiliary) | | | +--policyAction (auxiliary) | | | | | | | +--vendorPolicyAction (auxiliary) | | | | | | | +--qosPolicyColorAction (auxiliary) | | | | | | | +--qosPolicyDSPolicerAction (auxiliary) | | | | | | | +--qosPolicyRSVPPolicerAction (auxiliary) | | | +--qosPolicyDSPolicer(auxiliary) | | | +--qosPolicyRSVPPolicer(auxiliary) | | | | | +--qosPolicyDetailedRSVPPolicer (auxiliary) | | | +--qosPolicyVariable(auxiliary) | | | +--qosPolicyConstant(auxiliary) | | Snir, Ramberg, Strassner expires April 2000 34 Draft-snir-qos-policy-schema-01.txt October 1999 Figure 5 (continued) | +--qosPolicyValue(abstract) | | | | +--qosPolicyNumberValue(auxiliary) | | | +--qosPolicyNumberRangeValue(auxiliary) | | | | +--qosPolicyStringValue(auxiliary) | | | | +--qosPolicyIPAddrValue((auxiliary)| | | | | +--policyInstance (structural) | | | +--policyElement (auxiliary) | | | +--qosPolicyAtomFolders(structural) | | | +--qosPolicyAtomFolder(structural) | | | +--qosPolicyConditionFolder(structural) | | | +--qosPolicyDSPolicerFolder(structural) | | | +--qosPolicyRSVPPolicerFolder(structural) | | | +--qosPolicyPHBFolder (structural) | | | +--qosPolicyPHBSet | | | +--qosPolicyServiceClass (structural) | | | +--qosPolicyTriggerEvent (abstract) | +--policySubtreesPtrAuxClass (auxiliary) | +--policyGroupContainmentAuxClass (auxiliary) | +--policyRuleContainmentAuxClass (auxiliary) Notice: classes with a "qos" prefix are QoS Policy Schema classes. Figure 5. Class Hierarchy for the LDAP QoS Policy Schema Snir, Ramberg, Strassner expires April 2000 35 Draft-snir-qos-policy-schema-01.txt October 1999 2. Implementation in an LDAP Server 2.1. Use of Distinguished Name in the Schema Distinguished names are object primary keys in LDAP. The QoS Policy schema makes ample use of DNs in various places according to the concepts defined in the Core Schema. Here are the major uses of DNs: * Object containers - throughout the schema, the relationships of a container to the set of objects that it contains are prevalent. Containers are lists of DNs of contained objects. A container may be attached to a node on the tree, thus adding another level to the hierarchy. * Static branches - leaves of the tree are sometimes pointed to by DNs * Cross hierarchy reference - references from a given entity to another entity (e.g., a repository object - section 1.2.1) can be referenced by means of a DN The Core schema introduces the concept of Structured Distinguished Name (SDN) that is based on an RDN format that allows a relationship among DNs. Section 1.3.1.3 describes how SDNs are used to compose complex Boolean expressions used in modeling and composing filtering instruction. 2.2. QoS Policy Auxiliary classes 2.2.1. Using attachment of auxiliary classes vs. DNs For a general discussion of attachment of auxiliary classes and the pros and cons of doing so, see [PFCORE]. QoS policy reusable objects should be stored in the appropriate repository. These objects will be referred to by DNs. Objects that are not reusable should, if possible, be attached to other classes for efficiency. Attachment allows a more efficient LDAP data retrieval operation. See [PFCORE]. 2.2.2. Multiple attachment Attaching more then one auxiliary class to a single structural object is allowed. This type of usage is recommended when defining simple policy rules that include the condition and action in the policy rule entry. By attaching the condition, its variable, and a value, the action and its policers allows retrieval of the entire policy rule in a single LDAP operation. For example see 2.2.3.3.3. 2.2.3. Auxiliary Classes - when and how they should be used Auxiliary objects must be attached to a structural class to be instantiated. There are 3 ways of using these objects. Snir, Ramberg, Strassner expires April 2000 36 Draft-snir-qos-policy-schema-01.txt October 1999 2.2.3.1. Attach to PolicyInstance class Whenever an auxiliary class should be instantiated so that it can be reused, it will be attached to a PolicyInstance object. An example would be a reusable qosPolicySimpleCondition to be placed in the Repository. The actual object placed there would be an instance of the PolicyInstance class with an instance of the qosPolicySimpleCondition class attached to it. 2.2.3.2. Attach specific containers to root objects Some auxiliary classes are attached to the appropriate structural classes defined in the Core Policy Information Model and Schema. Among such classes are the PolicyGroupContainmentAuxClass, which is used to attach qosPolicyDomain objects to, for example, other qosPolicyDomain , qosPolicyRule, or qosNamedPolicyContainer objects. Each of these classes can contain any of the other classes by using the PolicyRuleContainmentAuxClass to contain the DN of the appropriate class. 2.2.3.3. Attach to an object for efficient LDAP retrieval operation 2.2.3.3.1. Attaching qosPolicySimpleCondition to qosPolicyRule A simple QoS policy rule that includes just a single condition and action should be built by attaching the qosPolicySimpleCondition to the qosPolicyRule object. In this case, the qosPolicyRule.policyRuleConditionList attribute will be NULL. 2.2.3.3.2. Attaching qosPolicyAction to qosPolicyRule A simple policy rule that includes just a single action should be built by attaching the qosPolicyAction to the qosPolicyRule object. In this case the qosPolicyRule.policyRuleActionList attribute will be NULL. The same mechanism will be used for attaching policyTrigger objects. 2.2.3.3.3. Attaching qosPolicyVariable, qosPolicyConstant and qosPolicyValue objects to qosPolicySimpleCondition For a complex policy rule, it is recommended that a qosPolicySimpleCondition object be constructed through the attachment of qosPolicyVariable, qosPolicyConstant and qosPolicyValue auxiliary classes. The only exception to this rule is when one of these objects is a reusable (e.g., resident in a repository). In this case, it should not be attached, but a DN reference should be used instead. Snir, Ramberg, Strassner expires April 2000 37 Draft-snir-qos-policy-schema-01.txt October 1999 2.3. LDAP Search efficiency The ability to efficiently search for policy rules is important. Writers of policy elements should follow a few basic rules in order to allow readers of policy to do this efficiently, with a minimum of LDAP queries. 2.3.1. Reusable objects Reusable objects are located in the repository sub-tree as defined in section 1.2.1. Each reusable object is a child of the parent folder it belongs to. The parent folder defines a namespace that the objects that it contains are bound to. 2.3.2. NamedGroupContainer Location NamedGroupContainers are defined as direct children of their domain entry. 2.3.3. QoS Policy Rules Location QoS policy rules are defined as children of a particular NamedGroupContainer entry. 2.3.4. Qos Policy SubRule Location A QoS policy SubRule is a rule that is contained in another rule. This concept is not defined in the core schema, and is specific (for now) to this QoS schema. SubRule entries are defined as children of a particular policy rule that is more general in usage and/or scope. 2.3.5. Condition, Action, and TriggerEvent location Condition, action and TriggerEvent objects are either located in the relevant repository (if they are reusable objects) or are defined as children of the policy rule that uses them. 2.3.6. Search Readers of policies will assume that the above rules of entry location are implemented by applications that write these results. Readers will most likely perform LDAP sub-tree searches. The readers are responsible for validating the completeness and consistency of the policy retrieved by checking that every entry exists, as specified by the relevant container values. For example, for each rule, using the SDN values, the reader must check that the required conditions are available. Snir, Ramberg, Strassner expires April 2000 38 Draft-snir-qos-policy-schema-01.txt October 1999 3. Data integrity LDAP provides little if any support for data integrity protection. The only guarantee provided by LDAP-based systems is that a single object instance access is "atomic". This means that complex schemata such as the qosPolicy schema can't guarantee atomicity of multi-step operations. Note that even reading is not safe: no read consistency is guaranteed whatsoever. While there are various tactical solutions, a general schema may not rely on the guarantees of any particular directory product that are beyond the LDAP protocol standard specification, as such guarantees are proprietary and not supported by all products. This section discuss the problems associated with data integrity, consistency, concurrency control and transaction handling involved in using the qosPolicySchema, and suggests several approaches to tactical solutions. However, no attempt is made to provide a general strategy to the inherent weaknesses in LDAP. 3.1. Order of insertion of objects into the Directory Service Objects should be placed in the directory server in a particular order to minimize risks of lost updates due to client or server abnormal termination. In general, referred objects should be placed in the DIT prior to the placement of its DN in the referring object. For example, an action object (e.g., qosPolicyAction) should be fully initialized and placed in the DIT before its DN is added to the policyRuleActionList attribute of the policy rule (PolicyRule). Doing it in the opposite order (i.e., inserting a DN of the qosPolicyAction instance in the policyRuleActionList attribute before placing the action object in the DIT) may result in a "dangling" DN (i.e., a DN that points to nothing). A failure in the modify process may happen if the client machine fails to complete its modify operations because it crashes before the second operation completes successfully. The result of this is that the DN doesn't point at a real instance. The insertion ordering tactics comes at a price. Say, for example, that the referring and referred objects are to be placed in the directory so the referring object is the parent of the referred object. Obviously, no child DN exists before the parent is placed in the DIT. In such a case, one is tempted to write the parent, thus creating the node in the DIT and then write the child. However, an abnormal termination of either the client or the LDAP server before the operation of placing the child in the DIT results in a dangling child DN reference in the parent. To prevent this, one must pay the price of an extra write operation: First, write the parent with no reference to the child. Next, write the child to the correct DIT placement. Finally, modify the parent to point to the child. It is the responsibility of the writing client to eliminate cases of dangling references. Snir, Ramberg, Strassner expires April 2000 39 Draft-snir-qos-policy-schema-01.txt October 1999 3.2. Distinguishing between objects in the repository and private instantiations Reusable objects will ONLY be instantiated in the repository part of the DIT. Data integrity of the DIT relies on the location of the objects. When a change is made to a reusable object, located in the repository, no other action is required to insure that the modification is reflected in all referring objects (policies). If a reusable object is not placed in the repository, each change made to that object requires a complete scan of the DIT to make the change to each copy. 3.3. Versioning of objects Adding meta information to objects, such as creation / modification time, version and other application-specific information will allow implementation of application-specific validation, data integrity checking and enforcement. Discussion of these techniques is beyond the scope of this document. 3.4. Transaction Support No transaction support is defined in LDAPv3. Implementation of the QoS Policy Schema must assume that none is available and define their use of the DIT by relying solely on the single entry atomic operation LDAP supplies. 3.5. Data integrity in replicated directories Replication of information brings up data integrity, referential integrity, and concurrency control issues. These issues are not related specifically to the QoS Policy Schema (e.g., the QoS Policy Schema does not make things worse) and are beyond the scope of this document. 3.6. Referred objects' DN When updating a DN to a referred object, that object version should be checked to make sure that it exists and the object is of the right version. It is also recommend that schema checking be turned on in the server. Snir, Ramberg, Strassner expires April 2000 40 Draft-snir-qos-policy-schema-01.txt October 1999 4. Class Definitions 4.1. Class qosPolicyRoot This class represents the root of the subtree that contains QoS policy information. The qosPolicyRoot object contains the references to the repositories that it uses and to the policy definition information that it needs to represent policies. The class definition is as follows: NAME qosPolicyRoot DESCRIPTION The root of the QoS policy information tree DERIVED FROM Policy (Core) TYPE Structural AUXILIARY CLASSES OID MUST MAY qpRepositoryRoot qpDomainsRoot 4.1.1. The Attribute qpRepositoryRoot NAME qpRepositoryRoot DESCRIPTION A DN reference to the repository container entry, which identifies the subtree containing reusable objects SYNTAX DistinguishedName OID EQUALITY DistinguishedNameMatch MULTI-VALUED No DEFAULT VALUE NULL 4.1.2. The Attribute qpDomainsRoot NAME qpDomainsRoot DESCRIPTION A DN reference to qosPolicyDomains entry, which identifies the subtree containing policy information SYNTAX DistinguishedName OID EQUALITY DistinguishedNameMatch MULTI-VALUED No DEFAULT VALUE NULL 4.2. Class qosPolicyRepository This class represents the root (i.e., the top of the subtree) of the QoS policy repository. The qosPolicyRepository object contains the DNs of the specific repositories that contain reusable policy information. Snir, Ramberg, Strassner expires April 2000 41 Draft-snir-qos-policy-schema-01.txt October 1999 Note that this defines the root of different shareable repositories that can be used for policy-based applications. This is useful when differences exist in the nature of the administration of different objects that are under policy control, but it is desirable to group the objects under a common portion of the DIT (e.g., as a replication partition). For example, if there are policies that directly affect different users, it is not advisable to lump all users into a single common repository. This is because that effectively destroys the different nature that exists between users of different groups. However, it is desirable to treat all users alike for certain purposes (e.g., updating common information that they share, like being members of the same organization). To meet the needs of this example, we use the qosPolicyRoot to define the top of the DIT for policy information, and place each set of different users in their own qosPolicyRepository container. NAME qosPolicyRepository DESCRIPTION The root of the various repositories that contain shareable objects. DERIVED FROM AdminDomain TYPE Structural AUXILIARY CLASSES qosRepositoryContainmentAuxClass OID MUST MAY qpRepositoriesPresent 4.2.1. The Attribute qpRepositoriesPresent NAME qpRepositoriesPresent DESCRIPTION This is a boolean that, if TRUE, indicates that there are one or more repositories contained in this container. SYNTAX Boolean OID EQUALITY BooleanMatch MULTI-VALUED No 4.3. Class qosRepositoryContainmentAuxClass This auxiliary class provides a single, multi-valued attribute that points to a set of QoS policy repositories. By attaching this attribute to instances of various other classes, a policy administrator has a flexible way of providing an entry point into the directory that allows a client to locate and retrieve the policy repositories relevant to it. This provides the ability to have different repositories in two different roots of the same DIT. Snir, Ramberg, Strassner expires April 2000 42 Draft-snir-qos-policy-schema-01.txt October 1999 NAME qosRepositoryContainmentAuxClass DESCRIPTION An auxiliary class that enables policy repositories to be added in a flexible manner to the DIT DERIVED FROM Top TYPE Auxiliary AUXILIARY CLASSES OID MUST qpRepositoryContainmentAuxSet MAY 4.3.1. The Attribute qpRepositoryContainmentAuxSet This attribute provides an unordered set of DN pointers to one or more QoS policy repositories associated with the instance of a structural class to which this attribute has been attached. The attribute definition is as follows: NAME qpRepositoryContainmentAuxSet DESCRIPTION Distinguished names of policy repositories associated in some way with the instance to which this attribute has been appended. No order is implied. SYNTAX DistinguishedName OID EQUALITY DistinguishedNameMatch MULTI-VALUED Yes DEFAULT VALUE NULL 4.4. Class qosPolicyDomains This class represents the root of the QoS policy definition tree. The qosPolicyDomains object contains the policy definition information that it needs to represent policies. The class definition is as follows: NAME qosPolicyDomains DESCRIPTION The root of all QoS policy domains, under which all QoS information is stored. DERIVED FROM PolicyGroup (Core) TYPE Structural AUXILIARY CLASSES PolicyGroupContainmentAuxClass, PolicyRuleContainmentAuxClass OID MUST MAY qpDomainsPresent Snir, Ramberg, Strassner expires April 2000 43 Draft-snir-qos-policy-schema-01.txt October 1999 4.4.1. The Attribute qpDomainsPresent NAME qpDomainsPresent DESCRIPTION This is a boolean that, if TRUE, indicates that there are one or more qosPolicyDomain objects contained in this container. SYNTAX Boolean OID EQUALITY BooleanMatch MULTI-VALUED No 4.5. Class qosPolicyDomain This class defines 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 may have a potentially different set of policies, access rules, decision strategy or other application of the policy information organized in some fashion (which is represented by the domain) that reflects distinct administrative control (compared to the rest of the DIT). The qosPolicyDomains object points to a subtree in the DIT that contains policy information, and each qosPolicyDomain object points to a specific subsection of that subtree that contains specialized policy information. The class definition is as follows: NAME qosPolicyDomain DESCRIPTION A class that is the root of an administrative QoS policy domain, which resides in the qosPolicyDomains container. It contains a group of named policy containers. DERIVED FROM PolicyGroup (Core) TYPE Structural AUXILIARY CLASSES PolicyGroupContainmentAuxClass, PolicyRuleContainmentAuxClass OID MUST MAY qpDomainName, qpGlobalNamedContainer, qpPHBSet 4.5.1. The Attribute qpDomainName NAME qpDomainName DESCRIPTION A user-friendly name of the QoS policy domain. SYNTAX IA5String OID EQUALITY CaseExactIA5Match MULTI-VALUED No DEFAULT VALUE NULL Snir, Ramberg, Strassner expires April 2000 44 Draft-snir-qos-policy-schema-01.txt October 1999 4.5.2. The Attribute qpGlobalNamedContainer NAME qpGlobalNamedContainer DESCRIPTION A reference to the "global" rules contained in a qosNamedPolicyGroup entry. SYNTAX DistinguishedName OID EQUALITY DistinguishedNameMatch MULTI-VALUED No DEFAULT VALUE NULL 4.5.3. The Attribute qpPHBSet NAME qpPHBSet DESCRIPTION DN reference to the PHB set defined for the domain. SYNTAX DistinguishedName OID EQUALITY DistinguishedNameMatch MULTI-VALUED YES DEFAULT VALUE NULL 4.6. Class qosNamedPolicyContainer This class represents an administrative policy rule container. All policies serving a certain goal, servicing a certain type of application, handling a certain type of flow or devices are administrated in a particular qosNamedPolicyContainer. The class definition is as follows: NAME qosNamedPolicyContainer DESCRIPTION A class that is a logical and physical container of policies. DERIVED FROM PolicyGroup (Core) TYPE Structural AUXILIARY CLASSES PolicyRuleContainmentAuxClass, PolicyRuleContainmentAuxClass OID MUST qpPriority, qpPolicyRuleMatchMethod MAY Snir, Ramberg, Strassner expires April 2000 45 Draft-snir-qos-policy-schema-01.txt October 1999 4.6.1. The Attribute qpPriority NAME qpPriority DESCRIPTION The priority of a named group of rules compared to the other qosPolicyNamedContainer objects. If two or more qosPolicyNamedContainer objects have the same priority, this means that the order between these containers is of no importance, but that they must each be evaluated before other objects that have a numerically lower priority. SYNTAX Integer OID EQUALITY IntegerMatch MULTI-VALUED No DEFAULT VALUE NULL 4.6.2. The Attribute qpPolicyRuleMatchMethod NAME qpPolicyRuleMatchMethod DESCRIPTION The decision strategy top be applied on this set of qos policy rules by policy servers. See 1.4.4 SYNTAX Integer ENUM[] - {"FIRST MATCH " = 1; "MATCH ALL " = 2 } OID EQUALITY IntegerMatch MULTI-VALUED No DEFAULT VALUE 1 4.7. Class qosPolicyRule The qosPolicyRule is a class capable of defining a simple or complex QoS policy rule, and is an extension of the PolicyRule class. Simple QoS policy rules can be constructed by attaching auxiliary classes and using a single LDAP query for their retrieval. Complex QoS policy rules can include a list of sub-rules and/or references to objects representing conditions and actions. Sub-rules are implemented by attachingan instance of the PolicyRuleContainmentAuxClass, which is used to contains a list of DNs pointing to other qosPolicyRule objects. The reason of extending the PolicyRule class was to include a new attribute: the direction (e.g., input, output, or both) of the traffic that this policy rule applies to. The class definition is as follows: Snir, Ramberg, Strassner expires April 2000 46 Draft-snir-qos-policy-schema-01.txt October 1999 NAME qosPolicyRule DESCRIPTION A simple or complex policy rule that is used to represent QoS policies. DERIVED FROM PolicyRule (Core) TYPE Structural AUXILIARY CLASSES qosPolicyTriggerEvent, PolicyAction, qosPolicySimpleCondition, PolicyRuleContainmentAuxClass OID MUST MAY qpDirection 4.7.1. The Attribute qpDirection NAME qpDirection DESCRIPTION An enumerated value of the apply direction of the policy rule. SYNTAX Integer [ENUM] {IN: 1, OUT: 2, BOTH: 3} OID EQUALITY IntegerMatch MULTI-VALUED No 4.8. Class qosPolicyColorAction This class defines a specific DSCP coloring action to be applied on a flow. The class definition is as follows: NAME qosPolicyColorAction DESCRIPTION A class that defines the coloring action to be performed if the condition of the policy rule that contains this action is met. DERIVED FROM PolicyAction (Core) TYPE Auxiliary AUXILIARY CLASSES OID MUST MAY qpDSCPValue 4.8.1. The Attribute qpDSCPValue NAME qpDSCPValue DESCRIPTION An integer in the range of 0..63, that is the DSCP value to color the packet. SYNTAX Integer OID EQUALITY IntegerMatch MULTI-VALUED No Snir, Ramberg, Strassner expires April 2000 47 Draft-snir-qos-policy-schema-01.txt October 1999 4.9. Class qosPolicyDSPolicerAction This class defines a specific DiffServ shaper to be applied on a flow. The class definition is as follows: NAME qosPolicyDSPolicerAction DESCRIPTION A class that defines the DiffServ Traffic shaping action to be applied on a specific flow or group of flows, if a certain rule's condition is met. DERIVED FROM PolicyAction (Core) TYPE Auxiliary AUXILIARY CLASSES qosPolicyDSPolicer OID MUST MAY qpDiffServPolicer, qpOutOfProfileAction, qpOutOfProfilePolicer, qpOutOfProfileRemarkValues 4.9.1. The Attribute qpDiffServPolicer NAME qpDiffServPolicer DESCRIPTION This attribute contains the DiffServ Policing instruction value, defined as a DN reference to a DiffServPolicer entry. SYNTAX DistinguishedName OID EQUALITY DistinguishedNameMatch MULTI-VALUED No 4.9.2. The Attribute qpOutOfProfileAction NAME qpOutOfProfileAction DESCRIPTION The action to be applied to out of profile packets, as defined in the DiffServPolicer entry. SYNTAX Integer [ENUM] {SHAPE=0,DISCARD=1,remark=2} OID EQUALITY IntegerMatch MULTI-VALUED No 4.9.3. The Attribute qpOutofProfilePolicer NAME qpOutofProfilePolicer DESCRIPTION A DN reference of a policer to be applied on out of band packets if the OutofProfile action is defined as SHAPE. SYNTAX DistinguishedName OID EQUALITY DistinguishedNameMatch MULTI-VALUED No Snir, Ramberg, Strassner expires April 2000 48 Draft-snir-qos-policy-schema-01.txt October 1999 4.9.4. The Attribute qpOutofProfileRemarkValues NAME qpOutofProfileRemarkValues DESCRIPTION The DSCP value to be applied to out of profile packets if the OutofProfile action is defined as REMARK. SYNTAX Integer OID EQUALITY IntegerMatch MULTI-VALUED Yes 4.10. Class qosPolicyRSVPPolicerAction This class defines a specific IntServ RSVP action to be applied on a flow. The class definition is as follows: NAME qosPolicyRSVPPolicerAction DESCRIPTION A class that defines an RSVP action to be performed if a certain rule's condition is met. DERIVED FROM PolicyAction (Core) TYPE Auxiliary AUXILIARY CLASSES qosPolicyRSVPPolicer, qosPolicyDetailedRSVPPolicer OID MUST MAY qpRSVPPolicer, qpRSVPAction 4.10.1. The Attribute qpRSVPPolicer NAME qpRSVPPolicer DESCRIPTION A DN list of references to RSVPPolicer objects that define the desired RSVP action SYNTAX DistinguishedName OID EQUALITY DistinguishedNameMatch MULTI-VALUED No 4.10.2. The Attribute qpRSVPAction NAME qpRSVPAction DESCRIPTION An enumerated integer representing a specific RSVP decision. SYNTAX Integer [ENUM] {0 û Accept, 1 - Deny} OID EQUALITY IntegerMatch MULTI-VALUED No Snir, Ramberg, Strassner expires April 2000 49 Draft-snir-qos-policy-schema-01.txt October 1999 4.11. Class qosPolicyDSPolicer The DiffServ Policer is a class that represents the process of discarding or shaping packets within a traffic stream in accordance with the state of a corresponding meter enforcing a traffic profile as part of the QoS action. Policers may be reusable objects or local ones. If a policer is in a reusable object repository, then it may be aggregated in two different ways. If the policer is private, i.e., its isShared attribute is set to FALSE (or it doesn't exist), then it polices all flows filtered by any rule referencing this policer. If the policer is shared, i.e., its isShared attribute is set to TRUE, then it polices all flows filtered by the conditions of all rules referencing this policer.Only reusable policers may be designated as shared policers. The class definition is as follows: NAME qosPolicyDSPolicer DESCRIPTION A class that defines a specific DiffServ Policer to be administered on a specific flow or flow aggregate. DERIVED FROM Policy (Core) TYPE Auxiliary AUXILIARY CLASSES OID MUST MAY qpPolicerName, qpDSPolicerDescription, qpDSNormalRate, qpDSNormalBurst, qpDSExcessBurst, qpIsShared 4.11.1. The Attribute qpPolicerName NAME qpPolicerName DESCRIPTION The DiffServ Policer name. SYNTAX IA5String OID EQUALITY CaseExactIA5Match MULTI-VALUED No 4.11.2. The Attribute qpDSPolicerDescription NAME qpDSPolicerDescription DESCRIPTION A description of the type of policing that is being performed. SYNTAX DirectoryString OID EQUALITY CaseIgnoreMatch MULTI-VALUED No Snir, Ramberg, Strassner expires April 2000 50 Draft-snir-qos-policy-schema-01.txt October 1999 4.11.3. The Attribute qpDSNormalRate NAME qpDSNormalBurst DESCRIPTION The token rate. It is specified in units of bits/second. A rate of zero means that all packets will be out of profile. SYNTAX Integer OID EQUALITY IntegerMatch MULTI-VALUED No 4.11.4. The Attribute qpDSNormalBurst NAME qpDSNormalBurst DESCRIPTION The normal size of a burst in terms of bits SYNTAX Integer OID EQUALITY IntegerMatch MULTI-VALUED No 4.11.5. The Attribute qpDSExcessBurst NAME qpDSExcessBurst DESCRIPTION The excess size of a burst in terms of bits SYNTAX Integer OID EQUALITY IntegerMatch MULTI-VALUED No 4.11.6. The Attribute qpIsShared NAME qpIsShared DESCRIPTION Boolean attributes designating a policer to be a multiple rule aggregator. SYNTAX Integer ENUM {0 = Not shared, 1=Shared} OID EQUALITY IntegerMatch MULTI-VALUED No DEFAULT VALUE 0 - False 4.12. Class qosPolicyRSVPPolicer This class represents an IntServ RSVP Policer. Policers may be reusable objects or ad-hoc. If a policer is in a reusable object repository, then it may be aggregated in two different ways. If the policer is private, i.e., its isShared attribute is set to FALSE (or it doesn't exist), then it polices all flows filtered by any rule referencing this policer. If the policer is shared, i.e., its isShared attribute is set to TRUE, then it polices all flows filtered by the conditions of all rules referencing this policer. Snir, Ramberg, Strassner expires April 2000 51 Draft-snir-qos-policy-schema-01.txt October 1999 Only reusable policers may be designated as shared policers. The PreemptionPriority value defines the priority of preemption decisions to be executed by (for example) policy servers. If the PreemptionPriority is undefined or set to 0, the priority is undefined. The higher the PreemptionPriority value, the higher the priority of the RSVP state compared to other RSVP states using the same resources. The class definition is as follows: NAME qosPolicyRSVPPolicer DESCRIPTION A class that defines a specific IntServ Policer to be administered on a specific flow or flow group. DERIVED FROM Policy (Core) TYPE Auxiliary AUXILIARY CLASSES OID MUST MAY qpPolicerName, qpRSVPPolicerDescription, qpRSVPTokenRate, qpRSVPPeakRate, qpRSVPBucketSize, qpIsShared, qpPreemptionPriority, qpDefendingPriority 4.12.1. The Attribute qpPolicerName NAME qpPolicerName DESCRIPTION The IntServ Policer name. SYNTAX DirectoryString OID EQUALITY CaseIgnoreMatch MULTI-VALUED No 4.12.2. The Attribute qpRSVPPolicerDescription NAME qpRSVPPolicerDescription DESCRIPTION Policers represent RSVP parameters for the group of flows identified by a specific set of conditions. SYNTAX DirectoryString OID EQUALITY CaseIgnoreMatch MULTI-VALUED No 4.12.3. The Attribute qpRSVPTokenRate NAME qpRSVPTokenRate DESCRIPTION RSVP parameter. SYNTAX Integer OID EQUALITY IntegerMatch MULTI-VALUED No Snir, Ramberg, Strassner expires April 2000 52 Draft-snir-qos-policy-schema-01.txt October 1999 4.12.4. The Attribute qpRSVPPeakRate NAME qpRSVPPeakRate DESCRIPTION RSVP parameter. SYNTAX Integer OID EQUALITY IntegerMatch MULTI-VALUED No 4.12.5. The Attribute qpRSVPBucketSize NAME qpRSVPBucketSize DESCRIPTION RSVP parameter. SYNTAX Integer OID EQUALITY IntegerMatch MULTI-VALUED No 4.12.6. The Attribute qpIsShared NAME qpIsShared DESCRIPTION Boolean attributes designating a policer to be a multiple rule aggregator. SYNTAX Integer ENUM {0 = Not shared, 1=Shared} OID EQUALITY IntegerMatch MULTI-VALUED No DEFAULT VALUE 0 - False 4.12.7. The Attribute qpPreemptionPriority NAME qpPreemptionPriority DESCRIPTION A positive integer value to be used with preemption algorithms. The lower the priority value, the lower the preemption priority. If the priority value is set to 0, the priority is undefined. See [RSVP_PREEMP] for details. SYNTAX Integer OID EQUALITY IntegerMatch MULTI-VALUED No DEFAULT VALUE 0 Snir, Ramberg, Strassner expires April 2000 53 Draft-snir-qos-policy-schema-01.txt October 1999 4.12.8. The Attribute qpDefendingPriority NAME qpDefendingPriority DESCRIPTION A positive integer value to be used with preemption algorithms. The lower the qosDefendingPriority value, the lower the preemption priority. If priority value is set to 0, the priority is undefined. See [RSVP_PREEMP] for details. SYNTAX Integer OID EQUALITY IntegerMatch MULTI-VALUED No DEFAULT VALUE 0 4.13. Class qosPolicyDetailedRSVPPolicer This class extends the qosPolicyRSVPPolicer class by adding detailed parameters required for detailed RSVP policy information. It allows the definition of RSVP admission policy per direction of the RSVP signaling, i.e., per PATH message and per RESV message of the same RSVP session. This class allows for two different RSVP service class decisions: Controlled Load or Guaranteed Service. For detailed explanation of these services, as well as the class parameters, see [RSVP]. Notice that the RSVP action may refer to two qosPolicyDetailedRSVPPolicers, one for Path admission policy and one for RESV policy. The class definition is as follows: NAME qosPolicyDetailedRSVPPolicer DESCRIPTION A class that defines a detailed IntServ Policer to be administrated on a specific flow or flow group. DERIVED FROM qosPolicyRSVPPOlicer TYPE Auxiliary AUXILIARY CLASSES OID MUST MAY qpRSVPRSVPMsgType, qpRSVPServiceType, qpMinPolicedUnit, qpMaxPktSize, qpRSVP_STYLE, qpRSVPResvRate, qpRSVPResvSlack 4.13.1. The Attribute qpRSVPMsgType NAME qpRSVPMsgType DESCRIPTION Defines the message type this detailed Policer refers to, either PATH or RESV SYNTAX Integer [ENUM] {Path =1 , RESV =2} OID EQUALITY IntegerMatch MULTI-VALUED No Snir, Ramberg, Strassner expires April 2000 54 Draft-snir-qos-policy-schema-01.txt October 1999 4.13.2. The Attribute qpRSVPServiceType NAME qpRSVPServiceType DESCRIPTION Defines the RSVP service type , Controlled Load and/or guaranteed service. SYNTAX Integer [ENUM] {ControlledLoad =1 , GuaranteedService =2} OID EQUALITY IntegerMatch MULTI-VALUED YES 4.13.3. The Attribute qpMinPolicedUnit NAME qpMinPolicedUnit DESCRIPTION Defines the RSVP minimum policed unit SYNTAX Integer OID EQUALITY IntegerMatch MULTI-VALUED NO 4.13.4. The Attribute qpMaxPktSize NAME qpMaxPktSize DESCRIPTION Defines RSVP maximum allowed packet size. SYNTAX Integer OID EQUALITY IntegerMatch MULTI-VALUED NO 4.13.5. The Attribute qpRSVPResvRate NAME qpRSVPResvRate DESCRIPTION Defines RSVP Rate - R-Spec parameter in the RSVP Guaranteed service reservation (Bps). SYNTAX Integer OID EQUALITY IntegerMatch MULTI-VALUED NO 4.13.6. The Attribute qpRSVPResvSlack NAME qpRSVPResvSlack DESCRIPTION Defines RSVP Slack Term - [RSVP] Flowspec::xspec_S parameter in the RSVP Guaranteed service reservation (microseconds). SYNTAX Integer OID EQUALITY IntegerMatch MULTI-VALUED NO Snir, Ramberg, Strassner expires April 2000 55 Draft-snir-qos-policy-schema-01.txt October 1999 4.14. Class qosPolicySimpleCondition (Aux) The qosPolicySimpleCondition is a class that is used when building Boolean expressions. It is derived from the policyCondition class of the Core schema (see [PFCORE]). QosPolicySimpleCondition is an auxiliary class to allow attachment to QoS Policy objects for simple rules. A simple condition is made of the triple . The qosPolicySimpleCondition class and its derived classes can always be mapped to True or False by evaluating the variable according to the relation that it specifies. This can be used in one of two ways. First, if the policy rule is a simple policy rule, then the action(s) that it specifies will be taken if the qosPolicySimpleCondition (or one of its subclasses) is defined to be TRUE. Otherwise, the action(s) that are specified in the simple condition will not be executed. Alternatively, an instance of this class (or one of its subclasses) can be used to form a complex condition. The evaluation of this class will then be combined with the evaluation of other condition classes in either conjunctive or disjunctive normal form (see [PFCORE]) to determine if the attached action(s) are executed or not. The class definition is as follows: NAME qosPolicySimpleCondition DESCRIPTION A class that represents a single Boolean condition. A group of conditions make up a Boolean expression. A single condition is made of the triple DERIVED FROM PolicyCondition (Core) TYPE Auxiliary AUXILIARY CLASSES qosPolicyVariable, qosPolicyConstant, qosPolicyIPAddrValue, qosPolicyStringValue, qosPolicyNumberValue, qosPolicyNumberRangeValue OID MUST MAY qpOperator, qpVariableAtom, qpValueAtom 4.14.1. The Attribute qpOperator NAME qpOperator DESCRIPTION The relation between a variable and a value. SYNTAX DirectoryString OID EQUALITY CaseIgnoreString MULTI-VALUED No Snir, Ramberg, Strassner expires April 2000 56 Draft-snir-qos-policy-schema-01.txt October 1999 4.14.2. The Attribute qpVariableAtom NAME qpVariableAtom DESCRIPTION A reference to a variable SYNTAX DistinguishedName OID EQUALITY DistinguishedNameMatch MULTI-VALUED No 4.14.3. The Attribute qpValueAtom NAME qpValueAtom DESCRIPTION A reference to a value. SYNTAX DistinguishedName OID EQUALITY DistinguishedNameMatch MULTI-VALUED No 4.15. Class qosPolicyVariable The qosPolicyVariable class is used as a building block for constructing policy conditions. We call such building blocks "atoms". The qosPolicyVariable class is an auxiliary class to allow the attachment of variables to policy conditions for more efficient LDAP access. The class definition is as follows: NAME qosPolicyVariable DESCRIPTION A class that represents a single variable in a Boolean condition DERIVED FROM Policy (Core) TYPE Auxiliary AUXILIARY CLASSES OID MUST MAY qpVariableName, qpVariableType, qpVariableID, qpVariableDescription, qpValuConstraints 4.15.1. The Attribute qpVariableName NAME qpVariableName DESCRIPTION A unique name for the variable. SYNTAX IA5String OID EQUALITY CaseExactIA5Match MULTI-VALUED No Snir, Ramberg, Strassner expires April 2000 57 Draft-snir-qos-policy-schema-01.txt October 1999 4.15.2. The Attribute qpVariableType NAME qpVariableType DESCRIPTION A well known type, as defined [LDAP_ATTR]. Required allowing the right operation to be performed on this Variable. For example, an equal operation is performed differently for variable of type strings to variables of type integer. SYNTAX IA5String OID EQUALITY CaseExactIA5Match MULTI-VALUED No 4.15.3. The Attribute qpVariableID NAME qpVariableID DESCRIPTION Unique ID, necessary for the naming of reusable objects. SYNTAX OID OID EQUALITY ObjectIdentifierMatch MULTI-VALUED No 4.15.4. The Attribute qpVariableDescription NAME qpVariableDescription DESCRIPTION A textual description of the variable SYNTAX DirectoryString OID EQUALITY CaseIgnoreMatch MULTI-VALUED No 4.15.5. The Attribute qpValueConstraints NAME qpValueConstraints DESCRIPTION A list of DNs of the constant objects serving as constraints for this variable. The constants could be of different types such as ranges and bags. SYNTAX DistinguishedName OID EQUALITY DistinguishedNameMatch MULTI-VALUED Yes Snir, Ramberg, Strassner expires April 2000 58 Draft-snir-qos-policy-schema-01.txt October 1999 4.16. Class qosPolicyConstant The qosPolicyConstant is a class that is used as a building atom of a policy condition. It is an auxiliary class, which allows its attachment to policy conditions for more efficient LDAP access. The class definition is as follows: NAME qosPolicyConstant DESCRIPTION A class that represents a single atom (a constant value) in a Boolean condition DERIVED FROM Policy (Core) TYPE Auxiliary AUXILIARY CLASSES OID MUST MAY qpConstantName, qpValueRef, qpConstantID, QpConstantDescription 4.16.1. The Attribute qpConstantName NAME qpConstantName DESCRIPTION A unique name for a constant to be used when it is used as a reusable object. SYNTAX IA5String OID EQUALITY CaseExactIA5Match MULTI-VALUED No 4.16.2. The Attribute qpConstantID NAME qpConstantID DESCRIPTION Unique ID, required for use as a reusable object SYNTAX OID OID EQUALITY ObjectIdentifierMatch MULTI-VALUED No 4.16.3. The Attribute qpConstantDescription NAME qpConstantDescription DESCRIPTION A textual description of the purpose of this object SYNTAX DirectoryString OID EQUALITY CaseIgnoreMatch MULTI-VALUED No Snir, Ramberg, Strassner expires April 2000 59 Draft-snir-qos-policy-schema-01.txt October 1999 4.16.4. The Attribute qpValueRef NAME qpValueRef DESCRIPTION A DN reference to a qosPolicyValue object SYNTAX DistinguishedName OID EQUALITY DistinguishedNameMatch MULTI-VALUED No 4.17. Class qosPolicyValue The qosPolicyValue is a class that is used as an abstract class for defining values of constants and policy conditions. The class definition is as follows: NAME qosPolicyValue DESCRIPTION This class is used as an abstract class for defining values of constants and policy conditions DERIVED FROM Policy TYPE Abstract AUXILIARY CLASSES OID MUST MAY qpValueType, qpValueDescription 4.17.1. The Attribute qpValueType NAME qpValueType DESCRIPTION A well known type as defined [LDAP_ATTR] SYNTAX OID OID EQUALITY ObjectIdentifierMatch MULTI-VALUED No 4.17.2. The Attribute qpValueDescription NAME qpValueDescription DESCRIPTION Textual description of the purpose of this class SYNTAX DirectoryString OID EQUALITY CaseIgnoreMatch MULTI-VALUED No Snir, Ramberg, Strassner expires April 2000 60 Draft-snir-qos-policy-schema-01.txt October 1999 4.18. Class qosPolicyIPAddrValue The qosPolicyIPAddrValue is a class that is used to define an IP address value. The class definition is as follows: NAME qosPolicyIPAddrValue DESCRIPTION This class is used to define an IP address value DERIVED FROM qosPolicyValue TYPE Auxiliary AUXILIARY CLASSES OID MUST MAY qpIPAddress, qpIPMask 4.18.1. The Attribute qpIPAddress NAME qpIPAddress DESCRIPTION IP address represented as a string in dotted decimal notation SYNTAX IA5String OID EQUALITY CaseExactIA5Match MULTI-VALUED No 4.18.2. The Attribute qpIPMask NAME qpIPMask DESCRIPTION IP mask represented as a string in dotted decimal notation SYNTAX IA5String OID EQUALITY CaseEactIA5Match MULTI-VALUED No 4.19. Class qosPolicyStringValue The qosPolicyStringValue is a class that is used to define a String value. The class definition is as follows: NAME qosPolicyStringValue DESCRIPTION This class is used to define a String value DERIVED FROM qosPolicyValue TYPE Auxiliary AUXILIARY CLASSES OID MUST MAY qpStringValue Snir, Ramberg, Strassner expires April 2000 61 Draft-snir-qos-policy-schema-01.txt October 1999 4.19.1. The Attribute qpStringValue NAME qpStringValue DESCRIPTION The value of the string SYNTAX DirectoryString OID EQUALITY CaseIgnoreMatch MULTI-VALUED Yes (to enable the representation of a set of numbers; otherwise, you would have to define another class) 4.20. Class qosPolicyNumberValue The qosPolicyNumberValue is a class that is used to define Integer values. The class definition is as follows: NAME qosPolicyNumberValue DESCRIPTION This class is used to define Integer values DERIVED FROM qosPolicyValue TYPE Auxiliary AUXILIARY CLASSES OID MUST MAY qpNumberValue 4.20.1. The Attribute qpNumberValue NAME qpNumberValue DESCRIPTION Description of the purpose of this class SYNTAX Integer OID EQUALITY IntegerMatch MULTI-VALUED YES (to enable the representation of a set of numbers; otherwise, you would have to define another class) 4.21. Class qosPolicyNumberRangeValue The qosPolicyNumberRangeValue is a class that is used to define a contiguous range of integer values. The class definition is as follows: NAME qosPolicyNumberRangeValue DESCRIPTION This class is used to define a contiguous range of integer values. DERIVED FROM qosPolicyValue TYPE Auxiliary AUXILIARY CLASSES OID MUST MAY qpNumberFromValue, qpNumberToValue Snir, Ramberg, Strassner expires April 2000 62 Draft-snir-qos-policy-schema-01.txt October 1999 4.21.1. The Attribute qpNumberFromValue NAME qpNumberFromValue DESCRIPTION Lower boundary of the range. SYNTAX Integer OID EQUALITY IntegerMatch MULTI-VALUED No 4.21.2. The Attribute qpNumberToValue NAME qpNumberToValue DESCRIPTION Upper boundary of the range SYNTAX Integer OID EQUALITY IntegerMatch MULTI-VALUED No 4.22. Class qosPolicyAtomFolders The qosPolicyAtomFolders class is the root of a list of containers, each holding a list of reusable variables and constants. The hierarchy of folders is necessary for expressing flexible administration policies, such as Atom folder per namedPolicyContainer or per type of policy. The class definition is as follows: NAME qosPolicyAtomFolders DESCRIPTION This class defines the root of a list of containers, each holding a list of reusable variables and constants DERIVED FROM Policy (Core) TYPE Structural AUXILIARY CLASSES OID MUST MAY qpFolderList 4.22.1. The Attribute qpFolderList NAME qpFolderList DESCRIPTION List of DNs that point to a set of qosPolicyAtomFolders, each holding a list of reusable variables and constants. SYNTAX DistinguishedName OID EQUALITY DistinguishedNameMatch MULTI-VALUED Yes Snir, Ramberg, Strassner expires April 2000 63 Draft-snir-qos-policy-schema-01.txt October 1999 4.23. Class qosPolicyAtomFolder The qosPolicyAtomFolder is a container class for a list of reusable variable and constants. It provides an additional level of scoping, fitting below the qosPolicyAtomFolders class. This allows the administrator to define different reusable classes and group them in separate qosPolicyAtomFolder containers to achieve commonality of administration (among other things), while aggregating the qosPolicyAtomFolder containers under an instance of the qosPolicyAtomFolders container to provide a higher-level, common level of administration to each of the qosPolicyAtomFolder containers. The class definition is as follows: NAME qosPolicyAtomFolder DESCRIPTION This class is a container class for a list of reusable variable and constants. It is intended to be scoped by an instance of the qosPolicyAtomFolders class. DERIVED FROM Policy (Core) TYPE Structural AUXILIARY CLASSES OID MUST MAY qpVariableDNs, qpConstantDNs 4.23.1. The Attribute qpVariableDNs NAME qpVariableDNs DESCRIPTION List of references to reusable qosPolicyVariables SYNTAX DistinguishedName OID EQUALITY DistinguishedNameMatch MULTI-VALUED Yes 4.23.2. The Attribute qpConstantDNs NAME qpConstantDNs DESCRIPTION List of references to reusable qosPolicyConstants SYNTAX DistinguishedName OID EQUALITY DistinguishedNameMatch MULTI-VALUED Yes Snir, Ramberg, Strassner expires April 2000 64 Draft-snir-qos-policy-schema-01.txt October 1999 4.24. Class qosPolicyConditionFolder The qosPolicyConditionFolder is a container class for a list of reusable qosPolicySimpleCondition objects. The class definition is as follows: NAME qosPolicyConditionFolder DESCRIPTION This class is a container class for a list of reusable qosPolicySimpleCondition objects DERIVED FROM Policy (Core) TYPE Structural AUXILIARY CLASSES OID MUST MAY qpConditionList 4.24.1. The Attribute qpConditionList NAME qpConditionList DESCRIPTION List of references to reusable qosPolicySimpleCondition objects. SYNTAX DistinguishedName OID EQUALITY DistinguishedNameMatch MULTI-VALUED Yes 4.25. Class qosPolicyDSPolicerFolder The qosPolicyDSPolicerFolder is a container class for a list of reusable qosPolicyDSPolicer objects. The class definition is as follows: NAME qosPolicyDSPolicerFolder DESCRIPTION This class is a container class for a list of reusable qosPolicyDSPolicer objects DERIVED FROM Policy (Core) TYPE Structural AUXILIARY CLASSES OID MUST MAY qpDSPolicerList 4.25.1. The Attribute qpDSPolicerList NAME qpDSPolicerList DESCRIPTION List of references to reusable qosPolicyDSPolicer objects. SYNTAX DistinguishedName OID EQUALITY DistinguishedNameMatch MULTI-VALUED Yes Snir, Ramberg, Strassner expires April 2000 65 Draft-snir-qos-policy-schema-01.txt October 1999 4.26. Class qosPolicyRSVPPolicerFolder The qosPolicyRSVPPolicerFolder is a container class for a list of reusable qosPolicyRSVPPolicer objects. The class definition is as follows: NAME qosPolicyRSVPPolicerFolder DESCRIPTION This class is a container class for a list of reusable qosPolicyRSVPPolicer objects DERIVED FROM Policy (Core) TYPE Structural AUXILIARY CLASSES OID MUST MAY qpRSVPPolicerList 4.26.1. The Attribute qpRSVPPolicerList NAME qpRSVPPolicerList DESCRIPTION List of references to reusable qosPolicyRSVPPolicer objects. SYNTAX DistinguishedName OID EQUALITY DistinguishedNameMatch MULTI-VALUED Yes 4.27. Class qosPolicyPHBFolder NAME qosPolicyPHBFolder DESCRIPTION This class is a container of PHB definitions DERIVED FROM Policy (Core) TYPE Structural AUXILIARY CLASSES OID MUST qpPHBSetList MAY 4.27.1. The attribute qpPHBSetList NAME qpPHBSetList DESCRIPTION List of references to reusable PHB set objects. SYNTAX DistinguishedName OID EQUALITY DistinguishedNameMatch MULTI-VALUED Yes Snir, Ramberg, Strassner expires April 2000 66 Draft-snir-qos-policy-schema-01.txt October 1999 4.28. Class qosPolicyPHBSet This class defines a set of PHB definitions. The class definition is as follows: NAME qosPolicyPHBSet DESCRIPTION This class defines a set of PHB definitions DERIVED FROM Policy (Core) TYPE Structural AUXILIARY CLASSES OID MUST MAY qpPHBName, qpSCList 4.28.1. The attribute qpSCList NAME qpSCList DESCRIPTION List of references to reusable service class objects. SYNTAX DistinguishedName OID EQUALITY DistinguishedNameMatch MULTI-VALUED Yes 4.28.2. The attribute qpPHBName NAME qpPHBName DESCRIPTION A name of the service class such as "Gold" or "VOIP". This must be unique within the PHB set (modeled by the CN attribute inherited from Policy [CORE]). SYNTAX IA5String OID EQUALITY CaseExactIA5Match MULTI-VALUED No 4.29. Class qosPolicyServiceClass This class defines a single service class in a PHB set. The class definition is as follows: NAME qosPolicyPHBSet DESCRIPTION This class defines a single service class in a PHB set. DERIVED FROM Policy (Core) TYPE Structural AUXILIARY CLASSES OID MUST MAY qpServicePolicer, qpServiceDSCP, qpServiceTransmitFactor, QpServiceBufferFactor Snir, Ramberg, Strassner expires April 2000 67 Draft-snir-qos-policy-schema-01.txt October 1999 4.29.1. The attribute qpServicePolicer NAME qpServicePolicer DESCRIPTION DN defining out of band behavior. The policer may instead be attached to the PHB for non-reusable policers. The Policer is an aggregate policer for flows mapped to this service class. SYNTAX DistinguishedName OID EQUALITY DistinguishedNameMatch MULTI-VALUED No 4.29.2. The attribute qpServiceDSCP NAME qpServiceDSCP DESCRIPTION An integer in the range 0..63, representing the service classes in the domain that are used for classification. SYNTAX Integer OID EQUALITY IntegerMatch MULTI-VALUED No 4.29.3. The attribute qpServiceTransmitFactor NAME qpServiceTransmitFactor DESCRIPTION Minimal percentage of bandwidth allocated to this service SYNTAX Integer OID EQUALITY IntegerMatch MULTI-VALUED No 4.29.4. The attribute qpServiceBufferFactor NAME qpServiceBufferFactor DESCRIPTION Percentage of buffer space allocated to each service class. SYNTAX Integer OID EQUALITY IntegerMatch MULTI-VALUED No Snir, Ramberg, Strassner expires April 2000 68 Draft-snir-qos-policy-schema-01.txt October 1999 4.30. Class qosPolicyTriggerEvent This class is an abstract class used for inheritance of specific trigger events such as time, network load or error events. The definition of this class is as follows: NAME qosPolicyTriggerEvent DESCRIPTION This class is an abstract class used for inheritance of specific trigger events such as time, network load or error events DERIVED FROM Policy (Core) TYPE Auxiliary AUXILIARY CLASSES OID MUST MAY qpTriggerType 4.30.1. The Attribute qpTriggerType NAME qpTriggerType DESCRIPTION An enumerated unsigned 16-bit integer that defines the type of trigger that this instance represents. SYNTAX Integer OID EQUALITY IntegerMatch MULTI-VALUED No 5. Extending the QoS Policy Schema The following subsections provide general guidance on how to create a domain-specific schema derived from the QoS Policy Schema by deriving specific classes. 5.1. Subclassing qosPolicyValue The qosPolicyValue class and its subclasses describe three common value types: * Integer * String * IP address When other specific types are required, such as a floating-point number or a MAC address, the required class should be derived from the qosPolicyValue class and an attribute that contains the corresponding value should be added. If possible, the attribute name should be Value. Notice that the Type of the value must be well defined and standard for interoperability. Snir, Ramberg, Strassner expires April 2000 69 Draft-snir-qos-policy-schema-01.txt October 1999 5.2. Subclassing qosPolicySimpleCondition Policy condition describes 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 an unary condition. Subclassing could be done using either PolicyCondition or qosPolicySimpleCondition as the superclass. Notice that the qosPolicySimpleCondition is an auxiliary class. This enables it to be attached to the qosPolicyRule class instance. Any classes derived from this class should also be auxiliary classes. 5.3. Subclassing qosPolicyAction QosPolicyAction as defined in the QoS Policy Schema includes at most three QoS actions. * Coloring. * Policing / Traffic Shaping. * RSVP reservations. In order to add other actions to a certain qosPolicyAction instance, additional actions should be added to the qosPolicyAction by deriving a new class and adding the appropriate attributes. Notice that the qosPolicyAction is an auxiliary class in order to allow attachment to the qosPolicyRule class instance. Any classes derived from this class should also be auxiliary classes. 6. Security Considerations 7. Acknowledgments We would like to acknowledge John Schnizlein and Steve Schleimer for their helpful comments. Snir, Ramberg, Strassner expires April 2000 70 Draft-snir-qos-policy-schema-01.txt October 1999 8. References [TERMS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", Internet RFC 2119, March 1997. [PFCORE] J. Strassner, E. Ellesson, B. Moore, "Policy Framework Core Information Model", draft-ietf-policy-core-info-model-00.txt [PFSCHEMA] J. Strassner, E. Ellesson, B. Moore, "Policy Framework LDAP Core Schema", draft-ietf-policy-core-schema-04.txt [PLYTERMS] J. Strassner, E. Ellesson, "Terminology for describing network policy and services", draft-ietf-policy-terminology-02.txt [COPS] J. Boyle, R . Cohen et al , "The COPS (Common Open Policy Service) Protocol",draft-ietf-rap-cops-06.txt [LDAP_ATTR] M. Wahl, A. Coulbeck, " Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252 [RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) - Functional Specification.", IETF RFC 2205, Proposed Standard, Sep. 1997. [RSVP_PREEMP] Shai Herzog, "Signaled Preemption Priority Policy Element", - IETF DRAFT [DIFF-SERV-ARCH] S. Blake D. Blake, "An Architecture for Differentiated Services", RFC2475 [PIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, A. Smith, "Quality of Service Policy Information Base", Internet Draft [DEVQMDL] W. Weiss, J. Strassner, A. Westerinen, D.Durham, "Information Model for describing network policy and services", Internet Draft, 9. Author's Addresses Yoram Snir Cisco Systems 4 Maskit Street Herzliya Pituach, Israel 46766 Phone: +972-9-970-0085 Fax: +972-9-970-0302 E-mail: ysnir@cisco.com Snir, Ramberg, Strassner expires April 2000 71 Draft-snir-qos-policy-schema-01.txt October 1999 Yoram Ramberg Cisco Systems 4 Maskit Street Herzliya Pituach, Israel 46766 Phone: +972-9-970-0081 Fax: +972-9-746-2021 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 10. Full Copyright Statement This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. The derived value classes should be auxiliary so they can be attached to the qosPolicyConstant class. This means that independent instances of value classes can not be created. Snir, Ramberg, Strassner expires April 2000 72