Internet Engineering Task Force Yoram Snir INTERNET DRAFT Yoram Ramberg 23 June 1999 John Strassner Cisco QoS Policy Framework Information Model and Schema draft-snir-policy-qos-infomodel-00.txt Status of Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (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 model 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 Core Schema. Definition of Key Word Usage The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119 [TERMS]. These words will be capitalized to ensure that their intent in this context is easily discernible. Snir, et. al. Expires 25 December 1999 [Page 1] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 Table of Contents Status of this memo 1 Copyright Notice 1 Abstract 1 Definition of Key Word Usage 1 Table of Contents 2 1. Introduction 5 1.1 Schema Hierarchy 5 1.2 Containment Hierarchy 6 1.2.1 Reusable-objects repositories 7 1.2.1.1 Repository structure 8 1.2.1.1.1 Atom folders 9 1.2.1.1.1.1 Using atoms 10 1.2.1.1.1.2 Atom folders organization 10 1.2.1.1.1.3 Value 11 1.2.1.1.1.4 Constant 11 1.2.1.1.1.5 Variable 11 1.2.1.1.2 DS policers 12 1.2.1.1.3 RSVP policers 12 1.2.1.1.4 Simple Conditions 12 1.2.2 Policy tree 13 1.3 Policy rule 14 1.3.1 The Semantics of Complex Policies 15 1.3.2 Simple and complex conditions 15 1.3.2.1 Simple condition composition 16 1.3.2.2 Using simple conditions 17 1.3.2.3 Composing and using complex conditions 17 1.3.3 Action 18 1.4 Inheritance Hierarchy for the LDAP QoS Policy Schema 18 2. Implementation in an LDAP Server 20 2.1 Use of Distinguished Name in the Schema 20 2.2 QoS Policy Auxiliary Classes 20 2.2.1 Using Attachment of Auxiliary Classes vs. DNs 20 2.2.2 Multiple attachment 20 2.2.3 Auxiliary Classes - When and How They Should be Used 21 2.2.3.1 Attach to the PolicyInstance Class 21 2.2.3.2 Attach Specific Containers to Root Objects 21 2.2.3.3 Attach to an Object for Efficient LDAP Retrieval Operation 21 2.2.3.3.1 Attaching qosPolicySimpleCondition to qosPolicy 21 2.2.3.3.2 Attaching qosPolicyAction to qosPolicy 21 2.2.3.3.3 Attaching qosPolicyVariable, qosPolicyConstant and 21 qosPolicyValue Objects to qosPolicySimpleCondition 3. Data integrity 22 3.1 Order of Insertion of Objects into the Directory Service 22 3.2 Distinguishing between Objects in the Repository to Private 23 Instantiations 3.3 Versioning of Objects 23 3.4 Transaction Support 23 Snir, et. al. Expires 25 December 1999 [Page 2] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 3.5 Data Integrity in Replicated Directories 23 3.6 Referred Objects' DN 23 4. Class Definitions 24 4.1 Class qosPolicyRoot 24 4.1.1 The Attribute QosPolicyRepositories 24 4.1.2 The Attribute QosPolicyDomains 24 4.2 Class qosPolicyRepository 25 4.3 Class qosPolicyDomains 25 4.4 Class qosPolicyDomain 25 4.4.1 The Attribute QosDomainName 26 4.5 Class qosNamedPolicyContainer 26 4.5.1 The Attribute AdminDomainName 27 4.6 Class qosPolicyRule 27 4.6.1 The Attribute QosPolicydirection 27 4.7 Class qosPolicyColorAction 27 4.7.1 The Attribute DSCPValue 28 4.8 Class qosPolicyDSPolicerAction 28 4.8.1 The Attribute DiffServPolicer 28 4.8.2 The Attribute OutOfProfileAction 29 4.8.3 The Attribute OutOfProfileRemarkValues 29 4.8.4 The Attribute OutOfProfilePolicer 29 4.9 Class qosPolicyRSVPPolicerAction 29 4.9.1 The Attribute RSVPPolicer 30 4.9.2 The Attribute RSVPAction 30 4.10 Class qosPolicyDSPolicer 30 4.10.1 The Attribute PolicerName 30 4.10.2 The Attribute Description 31 4.10.3 The Attribute QosPolicyNormalBurst 31 4.10.4 The Attribute QosPolicyExcessBurst 31 4.10.5 The Attribute QosPolicyPeakBurst 31 4.11 Class qosPolicyRSVPPolicer 31 4.11.1 The Attribute PolicerName 32 4.11.2 The Attribute Description 32 4.11.3 The Attribute QosPolicyTokenRate 32 4.11.4 The Attribute QosPolicyPeakRate 32 4.11.5 The Attribute QosPolicyBucketSize 33 4.12 Class qosPolicySimpleCondition 33 4.12.1 The Attribute Operator 33 4.12.2 The Attribute PolicyVariableAtom 33 4.12.3 The Attribute PolicyValueAtom 34 4.13 Class qosPolicyVariable 34 4.13.1 The Attribute QosPolicyVariableName 34 4.13.2 The Attribute QosPolicyVariableType 34 4.13.3 The Attribute PolicyVariableID 35 4.13.4 The Attribute PolicyVariableDescription 35 4.13.5 The Attribute PolicyValueConstraints 35 4.14 Class qosPolicyConstant 35 4.14.1 The Attribute QosPolicyConstantName 36 4.14.2 The Attribute QosPolicyConstantID 36 4.14.3 The Attribute QosPolicyConstantDescription 36 4.14.4 The Attribute QosPolicyValueRef 36 Snir, et. al. Expires 25 December 1999 [Page 3] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 4.15 Class qosPolicyValue 36 4.15.1 The Attribute QosPolicyValueType 37 4.15.2 The Attribute QosPolicyValueDescription 37 4.16 Class qosPolicyIPAddrValue 37 4.16.1 The Attribute QosPolicyIPAddrValue 37 4.16.2 The Attribute QosPolicyIPMaskValue 37 4.17 Class qosPolicyStringValue 38 4.17.1 The Attribute QosPolicyStringValue 38 4.18 Class qosPolicyNumberValue 38 4.18.1 The Attribute QosPolicyNumberValue 38 4.19 Class qosPolicyNumberRangeValue 39 4.19.1 The Attribute QosPolicyFromValue 39 4.19.2 The Attribute QosPolicyToValue 39 4.20 Class qosPolicyAtomFolders 39 4.20.1 The Attribute QosPolicyFolderList 40 4.21 Class qosPolicyAtomFolder 40 4.21.1 The Attribute FolderName 40 4.21.2 The Attribute QosPolicyVariables 40 4.21.3 The Attribute QosPolicyConstants 40 4.22 Class qosPolicyConditionFolder 41 4.22.1 The Attribute QosPolicyConditionList 41 4.23 Class qosPolicyAggDSPolicerFolder 41 4.23.1 The Attribute QosAggDSPolicerList 41 4.24 Class qosPolicyRSVPPolicerFolder 42 4.24.1 The Attribute QosRSVPPolicerList 42 5. Extending the QoS Policy Schema 42 5.1 Subclassing qosPolicyValue 42 5.2 Subclassing qosPolicySimpleCondition 42 5.3 Subclassing qosPolicyAction 43 6. Security Considerations 43 7. References 43 8. Author's Addresses 44 9. Full Copyright Statement 44 Snir, et. al. Expires 25 December 1999 [Page 4] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 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. 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. In each case, the purpose of interoperability is to be able to exchange policy information and coordinate the application of policies 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. However, this is a difficult task without some form of common administration, due to the large number of devices as well as the inherent differences in their capabilities. 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 Schema 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 best thought of as 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 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 Policy suitable for controlling network QoS. Snir, et. al. Expires 25 December 1999 [Page 5] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 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 the application-specific needs of 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 inheritance hierarchy. Figure 1 shows a summary view of the class containment hierarchy. QosPolicyRoot%%%%%%%%%%%%%%%%%%%%%%%%> Repository +-----------|-------------------------+ +----|------------------+ | V Scope for | | | +----------+ | | +-----------------+ Policy | | +->|Conditions|<## | | | qosPolicyDomain |-+ Admin | | | +----------+ # | | +-----------------+ | | | | # | | | qosPolicyDomain | | | | +----------+ # | | +-----------------+ | | |->| Actions |<## | | | | | | +----------+ # | +-----------|-------------------------+ | | # | | | | +----------+ # | +-----------|-------------------------+ | ->| Policers |<## | | | Policy | | +----------+ # | | +-------|--------+ Definitions | | Repositories # | | | PolicyRule |-+ | +---------------------#-| | +----------------+ | | # | | PolicyRule |######################################## | +----------------+ | +-------------------------------------+ ---> Containment ###> Associations in Information Model; DN References in LDAP %%%> 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 Example - 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. With respect to the Policy Framework core information model and schema specifications, containers are usually based on auxiliary classes (see section 2.2). A container, then, may be attached to a branch level class so that leaves may be added. Snir, et. al. Expires 25 December 1999 [Page 6] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 In addition, an entity may refer (by means of DN) to a reusable object. Reusable objects reside in repositories and can be referenced by multiple users. Reusable object references cross the hierarchy and are not considered part of the policy tree structure. Section 1.2.1 describes the reusable object repositories. The root of the tree 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 schema: reusable- objects repositories and a policy tree. These main branches divide the tree into two major sections: a policy definition section and repositories for reusable-objects. Figure 1 shows a summary view of the QoS Policy schema tree. Two main branches comprise the entire tree: One branch, the policy definition section, is rooted in the QoS Domains container. Note 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. A given PolicyRule can be a member of multiple QoSPolicyDomains, and 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.). 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 (which are subclassed from the repository class). 1.2.1 Reusable-objects repositories Reusable objects are entities that can be referenced (through DN type attributes) by other entities on the QoS policy schema tree. For example, multiple policy rules (instances of qosPolicyRule classes) may contain references to the same condition (qosPolicySimpleCondition) that resides in the repository. 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. The purpose of this requirement is to establish a clear and unambiguous identity for objects contained in the directory. To accomplish name uniqueness, an implementation-specific schema should use the identified naming attributes as RDNs for the reusable objects as specified in this draft. Snir, et. al. Expires 25 December 1999 [Page 7] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 The benefits of using reusable objects over use of "ad-hoc" instances include: - 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 - encapsulated concepts decouple changes to values of those concepts from changes to the policies that use them. For example, without encapsulation as defined above, changing one object value in one PolicyRule affects all PolicyRules that it is contained in at once. Instead, if an object is used to encapsulate this value, then only the part of the PolicyRule that this object affects is changed. - Some object classes may be used to create reusable objects as well as non-reusable, "ad-hoc", instances. Such is the case with the qosPolicySimpleCondition class, for example. The class definition for such objects can't require a MUST status for the name attribute (because ad-hoc objects don't require it) and the data model requirement for name uniqueness can only be enforced by DIT constructors, not LDAP Server schema checking. A reusable object may be more "expensive" than the use of an ad-hoc object when using directories because of the extra LDAP reference(s) involved in accessing a repository resident object. Reusable objects are constructed as follows: - A unique name, used as an RDN, must be assigned to the reusable object instance. - The DN of the structural class representing the reusable object 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 name, description and keywords attributes. Beyond this, each repository has a specific internal structure that is described in the following sub-sections. Snir, et. al. Expires 25 December 1999 [Page 8] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 The presence of repositories in the DIT is optional. The root of the DIT (qosPolicyRoot) MAY contain a DN attribute (Repositories) that points to an instance of the qosPolicyRepositoies class. The qosPolicyRepositories class is derived from the core class PolicyGroup. It is a single instance "holder" class. Adding repositories to the holder class is done by attaching a container class (PolicyGroupContainmentAuxClass) to the qosPolicyRepositories class instance and populating its DN list with DNs of the particular repositories. +--------------+ | Repositories | +-----------------+ +--|-----------+ ->|qosPolicyVariable| | | +-----------------+ | +--------------------+ | |---->|qosPolicyAtomFolders| | +-----------------+ | +--|-----------------+ |->|qosPolicyConstant| | | +-------------------+ | +-----------------+ | ->|qosPolicyAtomFolder|- | +-------------------+ | +------------------+ +------------+ |---->|qosPolicyPHBFolder|----->|qosPolicyPHB| | +------------------+ +------------+ | +------------------------+ +------------------+ |---->|qosPolicyConditionFolder|---->|qosPolicyCondition| | +------------------------+ +------------------+ | +---------------------------+ +------------------+ |---->|qosPolicyAggDSPolicerFolder|------>|qosPolicyDSPolicer| | +---------------------------+ +------------------+ | +--------------------------+ +--------------------+ ---->|qosPolicyRSVPPolicerFolder|----->|qosPolicyRSVPPolicer| +--------------------------+ +--------------------+ Figure 2: Reusable objects repositories 1.2.1.1.1 Atom folders The QoS Policy schema provides a means for creating named variables and 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. Snir, et. al. Expires 25 December 1999 [Page 9] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 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.1.4). For example: to form the boolean expression 'SourceIPAddress == MyServerAddress', we can use a variable of type IPAddress named 'SourceIPAddress', an operator '==' that denotes an equality logical relation and a constant named 'MyServerAddress' that holds the IP address of a machine called MyServer. Section 1.3.2 explains how to compose 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. An obvious advantage of using atoms is the ability to refer to a value by a meaningful name instead of copying the actual value every time it is used. Copying the value introduces a high probability for copying errors and omissions. In addition, the use of indirection (e.g., the name of the constant that refers to a value) also enhances the 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 policy 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 atoms. An implementation- specific schema can create as many folders as it needs. For example: it would make sense for an implementation-specific schema to create folders for application parameters, one per application, as in the following example: OracleFinancialsParameters, CorporateIntranetSettings, and SystemProperties. The OracleFinancialsParameters folder may hold atoms such as TransactionType variable, OracleFinancialsURL constant, and so forth. An individual named folder (qosPolicyAtomFolder) must contain a name (FolderName 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 qosPolicyConstant are auxiliary classes, they can't be pointed to directly. To instantiate a variable (or a constant) of these auxiliary classes and place it in the repository, the appropriate auxiliary class (qosPolicyVariable or qosPolicyConstant) must first be attached to an instance of the PolicyInstance core class. This is a structural class used as a holder for reusable objects (in this case, 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 folder (qosPolicyVariables or qosPolicyInstance). Snir, et. al. Expires 25 December 1999 [Page 10] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 1.2.1.1.1.3 Value Values are modeled by the qosPolicyValue abstract class. An instance of qosPolicyValue contains the actual bits of the data and a data type tag. Specific value types (e.g. integer and IP address) are modeled by structural classes that are derived from qosPolicyValue. For example: the class qosPolicyNumberValue models a numeric value. Values are not reusable and are not named. To reuse named values, one should employ constants (see section 1.2.1.1.1.4). To use a value, one must create an instance of the specific type value class and set the actual data. (Note that the derived value classes are auxiliary classes, so that they can be attahed to the qosPolicyConstant class. This means that independent instances of value classes can not be created). For example: to represent the IP address of a workstation, one would create an instance of the qosPolicyIPAddressValue (presumably of type IP_ADDRESS_DOT_NOTATION) and "put" in it the appropriate string (e.g., '144.254.93.72') that represents the address of the workstation. The qosPolicyValueType attributes is of type OID. Types are defined according to [LDAP_ATTR]. 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 either by a DN (attribute qosPolicyValueRef), or MAY 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 derived auxiliary classes that represent specific value types (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 Variable The variable class (qosPolicyVariable) models the concept of a variable used in a simple condition. For example: the simple condition 'MyNTStationAddress == '144.254.93.72' uses a variable named 'MyNTStationAddress' of type IP_ADDRESS, which is compatible with the type of the value '144.254.93.72'. Snir, et. al. Expires 25 December 1999 [Page 11] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 The class qosPolicyVaribale 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 PDP (or PEP) must check the type/value conformance rules for incompatibility. Detection of conformance rules violations are considered errors and prevent the evaluation of the condition. 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. For example: the TransactionType variable in the OracleFinancialsParameters folder may contain value constraint constants: UrgentQueryTX, GeneralLedgerTX, DBReplicationActivityTX, and so forth. The implementation-specific system can implement a logical value acceptation test of data entry by using the variable value constraint. 1.2.1.1.2 DS policers The qosPolicyAggDSPolicerFolder object is a repository of Differentiated Services (DS) policers, providing a grouping of aggregate service-level limit settings. A DS policer can be referenced by instances of the qosPolicyAction class. 1.2.1.1.3 RSVP policers The qosPolicyRSVPPolicerFolder object is a repository of RSVP policers, providing a grouping of individual flow limits based on RSVP concepts. An RSVP policer can be referenced by instances of the qosPolicyAction class. 1.2.1.1.4 Simple Conditions Simple conditions are Boolean expressions of the following form: {Variable; Operator; Value}. 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 are stored in a directory that contain a simple condition (e.g., one not composed of a set of objects). In other words, a simple condition is a special type of PolicyRule that contains the condition embedded in the PolicyRule itself (as opposed to referencing another object that contains the condition). Section 2.3.2 contains a detailed discussion of condition combination and usage. Simple conditions in the repository may be referenced by instances of qosPolicy (and qosSubPolicy). Snir, et. al. Expires 25 December 1999 [Page 12] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 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. A DN of this PolicyInstance object is then added to the condition repository, thus making this simple condition reusable by multiple policy rules. 1.2.2 Policy tree The Policy tree is contained in the set of qosPolicyDomain containers that have been instantiated. It is important to note that there is no fixed location in the DIT where the policy objects are rooted. This is because, in general, the customer owns the DIT, and we have no control over the DIT composition. This is why the use of auxiliary classes is so important, because they enable classes that contain policy information to be easily identified. The Policy definitions include the Policy-Rules, partitioned into distinct named containers (qosPolicyDomain), under a higher-level container (qosPolicyDomains). Figure 3 shows a summary view of the policy tree structure. +----------------+ |qosPolicyDomains| +--|-------------+ | +---------------+ -->|qosPolicyDomain| +-|-------------+ | +-----------------------+ -->|qosNamedPolicyContainer| +-|---------------------+ | +---------+ -->|qosPolicy| +-|-------+ | +------------+ -->|qosSubPolicy| +-|----------+ | +------------------------+ |-->|qosPolicySimpleCondition| | +------------------------+ | +---------------+ |-->|qosPolicyAction| +---------------+ Figure 3: Policy tree containment Each qosPolicyRule, whether complex or simple, may contain a simple condition (or a list of simple conditions) and an action (or a list of actions). The qosPolicyRule concept is further discussed in section 1.3. The building blocks used in the composition of policy rules (e.g., simple conditions and actions) can either be reusable objects that are stored in a repository, or "ad-hoc" instances of objects. Snir, et. al. Expires 25 December 1999 [Page 13] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 Each subtree is called a policy domain [see PLYTERM], and is modeled by the qosPolicyDomain class. The auxiliary class PolicyGroupContainmentAuxClass (from the core model and schema) is used to attach the qosPolicyDomain class to other qosPolicyDomain and/or PolicyGroup classes. A given domain can only belong to a single domain container. Each domain may contain (by attachment) a container of qosPolicyNamedPolicyGroup objects. This class models the notion of Roles as defined in [COPS] and [PLYTERMS], and serves as a container of Policies (qosPolicy). The qosPolicyNamedPolicyGroup class is also derived from the PolicyGroup core class. A given named policy group can only belong to a single domain object. The next branch level is the policy contained in the qosPolicyNamedPolicyGroup, which is a group of qosPolicyRules. The auxiliary class PolicyRuleContainmentAuxClass may be used to attach the qosPolicyNamedPolicyGroup object to an instance of the qosPolicyRule object. A given qosPolicyRule can only belong to a single qosPolicyNamedPolicyGroup object. The match strategy to be applied to the rules contained in this container is defined in PolicyRuleMatchMethod attribute. This strategy is also valid for rules added to the match process from the domain "global" rules. A Policy rule (qosPolicyRule) models an "atomic" policy unit and may be the final node (leaf) in the QoS Policy hierarchy. However, some policies may contain an added level of hierarchy, sub-policies. Sub-policies are also modeled by the qosPolicyRule objects. Containment of sub-policies is accomplished via attachment of rule container class (PolicyRuleContainmentAuxClass) to the qosPolicyRule. See section 1.3 for a detailed explanation of the semantics of the policy - sub-policy relationships. 1.3 Policy rule Policy rules are modeled by the qosPolicyRule class. The qosPolicyRule class is derived from the core class qosPolicyRule, and uses the rule containers class (PolicyRuleContainmentAuxClass), by attachment, to establish containment relationships between policy and sub-policies. PolicyRules that contain sub-policies (which can be identified by examining their SubPolicies attribute, which will not be NULL in such a case) are called complex policies. PolicyRules that have no sub-policies are called simple policies. Put another way, a complex policy is a policy that is composed of other policies. In the information model sense, a complex policy is an aggregation of simple policies, where a simple policy is an atomic object. Snir, et. al. Expires 25 December 1999 [Page 14] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 A given sub-policy can only be contained in a single policy. For example, consider the following qosPolicyRule: EnableFlag + Direction + Boolean expression + Action + other informational attributes The interpretation of a policy rule in regard to a given network flow as expressed in this statement is: "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 its relationships to the other entities of the schema. 1.3.1 The Semantics of Complex Policies The interpretation of a policy that contains sub-policies is as follows: If the value of the policyRuleEnabled attribute (inherited from the Core class PolicyRule) of the "parent" policy is FALSE, then all sub-policies of this rule are disabled (ignored). Otherwise, each sub-policy is designated enabled/disabled by the value of its own policyRuleEnabled attribute. Such a policy is suspended until all of its sub-policies are evaluated. This cumulative set of results is then fed into the higher-level policy. 1.3.2 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 is evaluated to TRUE, then the PolicyRule applies and the action(s) specified is (are) taken. 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 and it is manifested in the schema as relationships between a policy rule and a structured list of groups of simple conditions. Note also that filters are modeled in the Network Common Model of CIM. This section explains how the QoS Policy schema models simple and complex conditions to represent policy filters. Snir, et. al. Expires 25 December 1999 [Page 15] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 1.3.2.1 Simple condition composition Simple conditions are the building blocks of 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 string and a value (hidden inside the constant). Variables are modeled by the qosPolicyVariable class, named values are modeled by the qosPolicyConstant class, and "ad-hoc" values are modeled by the qosPolicyValue class. Simple condition composition must enforce 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 directly, but these rules are an integral part of the underlying information model and must be enforced by DIT constructors and/or clients of the schema. For example: if the conformance rules are not enforced by the data entry agent, then it makes sense for a PDP to verify conformance when reading the DIT. The schema defines several different ways to compose a simple condition through the combination of representations of variables, constants and values. Since the classes qosPolicyVariable, qosPolicyConstant and qosPolicyValue are all auxiliary classes, combinations of representation by DN references and attachments are possible as follows: Variable representation - The class qosPolicyVariable may be directly attached to an instance of the qosPolicySimpleCondition class. - 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 - The qosPolicyValue class may be directly attached to the qosPolicySimpleCondition class. - 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. - The qosPolicyConstant class may be directly attached to the qosPolicySimpleCondition class. Snir, et. al. Expires 25 December 1999 [Page 16] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 - 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: - Attachment: A qosPolicySimpleCondition class can be attached to the qosPolicyRule (structural) class. - 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 class. The schema provides reusing simple conditions by placing them in a common repository. In order for a simple condition to be a member of a repository, it must be of the second kind (indirect DN) and must also carry a name (RDN type). 1.3.2.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 policy rule (qosPolicy) in two ways: - A direct attachment of an instance of the simple condition to the qosPolicy 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. - Use the simple condition list attribute, policyRuleConditionList (derived from PolicyRule) 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 more than a single LDAP operation. 1.3.2.3 Composing and using complex conditions A complex condition consists of groups of either logically ANDed or ORed simple conditions (qosPolicySimpleCondition)[JCS19], and special markings negating given simple conditions in the complex condition, (e.g.: 'NOT (SourceIP == 1.1.1.0)'). A complex condition is modeled by 2 attributes: Snir, et. al. Expires 25 December 1999 [Page 17] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 - PolicyRuleConditionListType - a boolean expression type (from the Core schema) - 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. (from the Core schema). 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.3 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. The 3 actions modeled in this draft are: - Coloring - DSCP values. - Diff-Serv Policers - Int-Serv - Policers (RSVP). 1.4 Inheritance Hierarchy for the LDAP QoS Policy Schema Figure 4 illustrates the class hierarchy for the LDAP QoS Policy schema classes (Core classes are included, and are easily identified as any class whose name does not start with the prefix "qos"): Snir, et. al. Expires 25 December 1999 [Page 18] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 top | +--policy (abstract) | | | +---policyGroup (structural) | | +--------qosPolicyDomains (structural) | | +--------qosPolicyDomain (structural) | | +--------qosNamedPolicyContainer(structural) | +---policyRule (structural) | | +--------QosPolicyRule (structural) | | | +---policyCondition (auxiliary) | | +---policyTimePeriodCondition (auxiliary) | | +---vendorPolicyCondition (auxiliary) | | +---qosPolicySimpleCondition (auxiliary) | | | +---policyAction (auxiliary) | | +---vendorPolicyAction (auxiliary) | | +---qosColorPolicyAction (auxiliary) | | +---qosPolicyDSPolicerAction (auxiliary) | | +---qosCPolicyRSVPPolicerAction (auxiliary) | | | +--policyInstance (structural) | | | +--policyElement (auxiliary) | | | +--qosPolicyAtomFolders(structural) | | | +--qosPolicyAtomFolder(structural) | | | +--qosPolicyConditionFolder(structural) | | | +--qosPolicyAggDSPolicerFolder(structural) | | | +--qosPolicyRSVPPolicerFolder(structural) | +--policySubtreesPtrAuxClass (auxiliary) +--policyGroupContainmentAuxClass (auxiliary) +--policyRuleContainmentAuxClass (auxiliary) +--qosPolicyVariable(auxiliary) +--qosPolicyConstant(auxiliary) +--qosPolicyValue(abstract) | +--qosPolicyNumberValue(auxiliary) | +--qosPolicyNumberRangeValue(auxiliary) | +--qosPolicyStringValue(auxiliary) | +--qosPolicyIPAddrValue((auxiliary) | +--qosPolicyDSPolicer(auxiliary) +--qosPolicyRSVPPolicer(auxiliary) +--qosPolicyTrigger (auxiliary) Figure 4. Inheritance Hierarchy Snir, et. al. Expires 25 December 1999 [Page 19] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 2. Implementation in an LDAP Server This section will discuss considerations for implementing this schema in a directory that uses LDAP as its access protocol. 2.1 Use of Distinguished Name in the Schema Distinguished names are the primary keys of objects in a directory. 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. Tree leaves are sometimes pointed to by DNs - Cross hierarchy reference - references from a given entity to another (e.g.: repository object - section 1.2.1) 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.2.3 describes how SDNs are used to compose complex boolean expressions that can be used for modeling and composing filtering instructions. 2.2 QoS Policy Auxiliary Classes This section will discuss some implementation considerations that are specific to using auxiliary classes. 2.2.1 Using Attachment of Auxiliary Classes vs. DNs For 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 defined in this schema. 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 than 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. Snir, et. al. Expires 25 December 1999 [Page 20] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 2.2.3 Auxiliary Classes - When and How They Should be Used Auxiliary classes must be attached to a structural class to be instantiated. There are 3 ways of using these objects. 2.2.3.1 Attach to the 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 a PolicyInstance with a qosPolicySimpleCondition 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 as 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 This section elaborates on different ways to attach an object for efficient retrieval when using LDAP. 2.2.3.3.1 Attaching qosPolicySimpleCondition to qosPolicy A simple QoS policy rule that includes just a single condition should be built by attaching the qosPolicySimpleCondition to the qosPolicyRule object. In this case, the attribute qosPolicyRule.policyRuleConditionList will be NULL. 2.2.3.3.2 Attaching qosPolicyAction to qosPolicy A simple policy rule that includes just a single action should be built by attaching the qosPolicyAction to the qosPolicy object. In this case, the attribute qosPolicy.policyRuleActionList will not appear. 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 by 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) object. In this case, it should not be attached, but a DN reference should be used instead. Snir, et. al. Expires 25 December 1999 [Page 21] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 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 any particular directory product guarantees that are beyond the LDAP protocol standard specification. 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 LDAP inherent weaknesses in this area. 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 (qosPolicyAction) should be fully initialized and placed in the DIT before its DN is added to the ActionList attribute of the policy rule (PolicyRule). Doing it in the opposite order, i.e., inserting a DN of qosPolicyAction instance in the ActionList before placing the action object in the DIT, may result in a "dangling" DN. This may happen if the client machine crashes before the second operation completes successfully. 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. Howeve, an abnormal termination of either client or LDAP server before the operation of placing the child 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, the parent is modified to point to the child. It is the responsibility of the writing client to eliminate cases of dangling refernces. Snir, et. al. Expires 25 December 1999 [Page 22] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 3.2 Distinguishing between Objects in the Repository to 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 or modification time, version and other application-specific information will allow implementation of application-specific 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 information tree modification relying 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, et. al. Expires 25 December 1999 [Page 23] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 4. Class Definitions The following sections describe the classes comprising the QoS Policy Schema and their attributes. 4.1 Class qosPolicyRoot This class represents the root of the QoS policy information. The qosPolicyRootobject 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: none OID: POSSIBLE SUPERIORS: container, organization, organizationalUnit MUST: MAY: QosPolicyRepositories QosPolicyDomains 4.1.1 The Attribute QosPolicyRepositories NAME: QosPolicyRepositories DESCRIPTION: A DN reference to the repository container entry SYNTAX: distinguishedName OID: EQUALITY: distinguishedNameMatch MULTI-VALUED: No DEFAULT VALUE: NULL 4.1.2 The Attribute QosPolicyDomains NAME: QosPolicyDomains DESCRIPTION: A DN reference to qosPolicyDomains entry SYNTAX: distinguishedName OID: EQUALITY: distinguishedNameMatch MULTI-VALUED: No DEFAULT VALUE: NULL Snir, et. al. Expires 25 December 1999 [Page 24] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 4.2 Class qosPolicyRepository This class represents the root of the QoS policy repository of reusable objects tree. The qosPolicyRepository object contains the specific repositories' DNs. NAME: QosPolicyRepository DESCRIPTION: The root of the shareable objects repositories. This is an aggregator for shareable objects repositories. DERIVED FROM: PolicyGroup (Core) TYPE: Structural AUXILIARY CLASSES: PolicyGroupContainmentAuxClass OID: POSSIBLE SUPERIORS: container, organization, organizationalUnit, PolicyGroup MUST: MAY: 4.3 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 the QoS policy domains, and the aggregator for repository information. DERIVED FROM: PolicyGroup (Core) TYPE: Structural AUXILIARY CLASSES: PolicyGroupContainmentAuxClass, PolicyRuleContainmentAuxClass OID: POSSIBLE SUPERIORS: container, organization, organizationalUnit, PolicyGroup MUST: MAY: 4.4 Class qosPolicyDomain This class defines a single administrative QoS policy domain, and contains the domain's policy rules and definitions. The class definition is as follows: Snir, et. al. Expires 25 December 1999 [Page 25] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 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: POSSIBLE SUPERIORS: container, organization, organizationalUnit, PolicyGroup MUST: MAY: QosDomainName 4.4.1 The Attribute QosDomainName NAME: QosDomainName DESCRIPTION: A user-friendly name of the qos policy domain. SYNTAX: DirectoryString OID: EQUALITY: CaseIgnoreMatch MULTI-VALUED: No DEFAULT VALUE: NULL 4.5 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 administered in a particular namedQoSPolicyContainer. The namedQoSPolicyContainer fills the role of a diff-serv "Role" object (see [PLYTERMS]). The class definition is as follows: NAME: qosNamedPolicyContainer DESCRIPTION: A class that is a logical and physical container of policies, parallel to the concept of a Role. DERIVED FROM: PolicyGroup (Core) TYPE: Structural AUXILIARY CLASSES: PolicyRuleContainmentAuxClass, PolicyRuleContainmentAuxClass OID: POSSIBLE SUPERIORS: container, organization, organizationalUnit, PolicyGroup MUST: MAY: AdminDomainName Snir, et. al. Expires 25 December 1999 [Page 26] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 4.5.1 The Attribute AdminDomainName NAME: AdminDomainName DESCRIPTION: A user-friendly name of the administrative domain. SYNTAX: IA5String OID: EQUALITY: caseExactIA5Match MULTI-VALUED: No DEFAULT VALUE: NULL 4.6 Class qosPolicyRule The qosPolicyRule is a class capable of defining a simple or complex QoS policy rule. The qosPolicyRule class is an extension of the PolicyRule class. Simple qosPolicyRules could be constructed by attachment of auxiliary classes and allow a single LDAP query for retrieval. Complex rule could include a list of sub-rules by attachment of PolicyRuleContainmentAuxClass containing a list of qosPolicyRule objects' DNs (used as Sub-Policies). The class definition is as follows: NAME: qosPolicyRule DESCRIPTION: A simple or complex policy rule, i.e., a policy rule that may contain other policy rules. DERIVED FROM: policyRule TYPE: Structural AUXILIARY CLASSES: policyAction , qosPolicyGenericCondition, PolicyRuleContainmentAuxClass OID: MUST: MAY: QosPolicydirection 4.6.1 The Attribute QosPolicydirection NAME: QosPolicydirection DESCRIPTION: An enumerated value of the apply direction of the policy rule. Values are: IN (1) and OUT (2) SYNTAX: Integer OID: EQUALITY: IntegerMatch MULTI-VALUED: Yes, IN & OUT is a valid combination. 4.7 Class qosPolicyColorAction This class defines a specific DSCP coloring action to be applied on a flow. The class definition is as follows: Snir, et. al. Expires 25 December 1999 [Page 27] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 NAME: qosPolicyColorAction DESCRIPTION: A class that defines the coloring action to be performed if a certain rule's condition is met. DERIVED FROM: PolicyAction TYPE: Auxiliary AUXILIARY CLASSES: none OID: MUST: DSCPValue MAY: 4.7.1 The Attribute DSCPValue NAME: DSCPValue DESCRIPTION: An integer in the range of 0..63 that is the DSCP value to color the packet with. SYNTAX: Integer OID: EQUALITY: IntegerMatch MULTI-VALUED: No DEFAULT VALUE: 0 4.8 Class qosPolicyDSPolicerAction This class defines a specific diff-serv shaper to be applied on a flow. The class definition is as follows: NAME: qosPolicyDSPolicerAction DESCRIPTION: A class that defines the DiffServ policing action (e.g., dropping) to be applied on a specific flow or group of flows, if a certain rule's condition is met. DERIVED FROM: PolicyAction TYPE: Auxiliary AUXILIARY CLASSES: QosPolicyDSPolicer OID: MUST: DiffServPolicer MAY: OutOfProfileAction, OutOfProfileRemarkValues, OutOfProfilePolicer 4.8.1 The Attribute DiffServPolicer NAME: DiffServPolicer DESCRIPTION: The DiffServ Policing instruction value, defined as a DN reference to Diff-ServPolicer entry. SYNTAX: distinguishedName OID: EQUALITY: distinguishedNameMatch MULTI-VALUED: No Snir, et. al. Expires 25 December 1999 [Page 28] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 4.8.2 The Attribute OtOfProfileAction NAME: OutOfProfileAction DESCRIPTION: The action to be applied to out of profile packets, as defined in the DiffServ Policer entry. SYNTAX: Integer [ENUM] {SHAPE=0,DISCARD=1,remark=2} OID: EQUALITY: IntegerMatch MULTI-VALUED: No 4.8.3 The Attribute OutOfProfileRemarkValues NAME: OutOfProfileRemarkValues DESCRIPTION: The DiffServ value to be applied to out of profile packets if the outOfProfile action is defined as remark. SYNTAX: Integer [ENUM] {SHAPE=0,DISCARD=1,REMARK=2} OID: EQUALITY: IntegerMatch MULTI-VALUED: Yes 4.8.4 The Attribute OutOfProfilePolicer NAME: OutOfProfilePolicer 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 4.9 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 RSVP action to be performed if a certain rule's condition is met. DERIVED FROM: PolicyAction (Core) TYPE: Auxiliary AUXILIARY CLASSES: qosPolicyRSVPPolicer OID: MUST: RSVPPolicer MAY: RSVPAction Snir, et. al. Expires 25 December 1999 [Page 29] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 4.9.1 The Attribute RSVPPolicer NAME: RSVPPolicer DESCRIPTION: A DN list of references to RSVPPolicer representing the RSVP action SYNTAX: distinguishedName OID: EQUALITY: distinguishedNameMatch MULTI-VALUED: No 4.9.2 The Attribute RSVPAction NAME: RSVPAction DESCRIPTION: An enumerated integer representing RSVP decision. SYNTAX: Integer (Enum) 0 - Accept, 1 - Deny OID: EQUALITY: IntegerMatch MULTI-VALUED: No 4.10 Class qosPolicyDSPolicer The DiffServ Policer is a class that represents the process of discarding 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. The class definition is as follows: NAME: qosPolicyDSPolicer DESCRIPTION: A class that defines a specific DiffServ Policer to be administrated on a specific flow or flow aggregate. DERIVED FROM: Policy (Core) TYPE: Auxiliary AUXILIARY CLASSES: none OID: POSSIBLE SUPERIORS: PolicyRule, qosPolicy, qosSubPolicy MUST: MAY: PolicerName, Description, QosPolicyNormalBurst, QosPolicyExcessBurst, QosPolicyPeakBurst 4.10.1 The Attribute PolicerName NAME: PolicerName DESCRIPTION: The DiffServ Policer name. SYNTAX: IA5String OID: EQUALITY caseExactIA5Match MULTI-VALUED: No Snir, et. al. Expires 25 December 1999 [Page 30] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 4.10.2 The Attribute Description NAME: Description DESCRIPTION: A description of the type of policing that is being performed. SYNTAX: directoryString OID: EQUALITY: caseIgnoreMatch MULTI-VALUED: No 4.10.3 The Attribute QosPolicyNormalBurst NAME: QosPolicyNormalBurst DESCRIPTION: The average rate of the sender's data stream. SYNTAX: Integer OID: EQUALITY: IntegerMatch MULTI-VALUED: No 4.10.4 The Attribute QosPolicyExcessBurst NAME: QosPolicyExcessBurst DESCRIPTION: The amount in excess of the average rate, but not more than the peak rate, of the sender's data stream that will be accommodated. SYNTAX: Integer OID: EQUALITY: IntegerMatch MULTI-VALUED: No 4.10.5 The Attribute QosPolicyPeakBurst NAME: QosPolicyPeakBurst DESCRIPTION: The peak rate of the sender's data stream. SYNTAX: Integer OID: EQUALITY: IntegerMatch MULTI-VALUED: No 4.11 Class qosPolicyRSVPPolicer This class defines the IntServ RSVP action as part of the QoS action. Policers may be reusable objects or local ones. The class definition is as follows: Snir, et. al. Expires 25 December 1999 [Page 31] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 NAME: QosPolicyRSVPPolicer DESCRIPTION: A class that defines a specific IntServ Policer to be administrated on a specific flow or flow group. DERIVED FROM: Policy (Core) TYPE: Auxiliary AUXILIARY CLASSES: none OID: MUST: MAY: PolicerName, Description, QosPolicyTokenRate, QosPolicyPeakRate, QosPolicyBucketSize 4.11.1 The Attribute PolicerName NAME: PolicerName DESCRIPTION: The IntServ Policer name. SYNTAX: IA5String OID: EQUALITY: caseExactIA5Match MULTI-VALUED: No 4.11.2 The Attribute Description NAME: Description DESCRIPTION: Policers represent RSVP parameters for the group of flows identified by the conditions. SYNTAX: IA5String OID: EQUALITY: caseExactIA5Match MULTI-VALUED: No 4.11.3 The Attribute QosPolicyTokenRate NAME: QosPolicyTokenRate DESCRIPTION: RSVP parameter. SYNTAX: Integer OID: EQUALITY: IntegerMatch MULTI-VALUED: No 4.11.4 The Attribute QosPolicyPeakRate NAME: QosPolicyPeakRate DESCRIPTION: RSVP parameter. SYNTAX: Integer OID: EQUALITY: IntegerMatch MULTI-VALUED: No Snir, et. al. Expires 25 December 1999 [Page 32] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 4.11.5 The Attribute QosPolicyBucketSize NAME: QosPolicyBucketSize DESCRIPTION: RSVP parameter. SYNTAX: Integer OID: EQUALITY: IntegerMatch MULTI-VALUED: No 4.12 Class qosPolicySimpleCondition The qosPolicySimpleCondition class is used when building boolean expressions. It is the basic, atomic condition. A single condition is made of the triple . QosPolicySimpleCondition and its derived classes should be mapped to True or False at any time. QosPolicySimpleCondition is an auxiliary class to allow attachment to QoS Policy objects for simple rules. 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, qosPolicyValue OID: MUST: Operator MAY: PolicyVariableAtom, PolicyValueAtom 4.12.1 The Attribute Operator NAME: Operator DESCRIPTION: Relation between variable and value. SYNTAX: IA55String OID: EQUALITY: caseExactIA5Match MULTI-VALUED: No 4.12.2 The Attribute PolicyVariableAtom NAME: PolicyVariableAtom DESCRIPTION: Reference to variable, usually reusable SYNTAX: distinguishedName OID: EQUALITY: distinguishedNameMatch MULTI-VALUED: No Snir, et. al. Expires 25 December 1999 [Page 33] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 4.12.3 The Attribute PolicyValueAtom NAME: PolicyValueAtom DESCRIPTION: Reference to value, usually a reusable constant. SYNTAX: distinguishedName OID: EQUALITY: distinguishedNameMatch MULTI-VALUED: No 4.13 Class qosPolicyVariable The qosPolicyVariable is a class that is used as a building atom of a policy condition. QosPolicyVariable is an auxiliary class to allow attachment to policy conditions for quick LDAP access. The class definition is as follows: NAME: qosPolicyVariable DESCRIPTION: A class that represents a single atom in a boolean condition DERIVED FROM: top TYPE: Auxiliary AUXILIARY CLASSES: none OID: MUST: QosPolicyVariableName, QosPolicyVariableType MAY: PolicyVariableID, PolicyVariableDescription, PolicyValueConstraints 4.13.1 The Attribute QosPolicyVariableName NAME: QosPolicyVariableName DESCRIPTION: A unique name for a variable to be used when a reusable object. SYNTAX: IA5String OID: EQUALITY: caseExactIA5Match MULTI-VALUED: No 4.13.2 The Attribute QosPolicyVariableType NAME: QosPolicyVariableType 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: OID EQUALITY: OIDMatch MULTI-VALUED: No Snir, et. al. Expires 25 December 1999 [Page 34] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 4.13.3 The Attribute PolicyVariableID NAME: PolicyVariableID DESCRIPTION: Unique ID, relevant to reusable objects. SYNTAX: IA5String OID: EQUALITY: caseExactIA5Match MULTI-VALUED: No 4.13.4 The Attribute PolicyVariableDescription NAME: PolicyVariableDescription DESCRIPTION: Self explanatory. SYNTAX: IA5String OID: EQUALITY: caseExactIA5Match MULTI-VALUED: No 4.13.5 The Attribute PolicyValueConstraints NAME: PolicyValueConstraints 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: IA5String OID: EQUALITY: caseExactIA5Match MULTI-VALUED: Yes 4.14 Class qosPolicyConstant The qosPolicyConstant class is used as a building block for defining a policy condition. The qosPolicyConstant class is an auxiliary class to allow attachment to policy conditions for quick LDAP access. The class definition is as follows: NAME: QosPolicyConstant DESCRIPTION: A class that represents a single atom in a boolean condition DERIVED FROM: top TYPE: Auxiliary AUXILIARY CLASSES: none OID: MUST: QosPolicyConstantName, QosPolicyValueRef MAY: QosPolicyConstantID, QosPolicyConstantDescription Snir, et. al. Expires 25 December 1999 [Page 35] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 4.14.1 The Attribute QosPolicyConstantName NAME: QosPolicyConstantName DESCRIPTION: A unique name for a constant to be used when a reusable object. SYNTAX IA5String OID: EQUALITY: caseExactIA5Match MULTI-VALUED: No 4.14.2 The Attribute QosPolicyConstantID NAME: QosPolicyConstantID DESCRIPTION: Unique ID, relevant to reusable objects. SYNTAX IA5String OID: EQUALITY: caseExactIA5Match MULTI-VALUED: No 4.14.3 The Attribute QosPolicyConstantDescription NAME: QosPolicyConstantDescription DESCRIPTION: Self explanatory. SYNTAX IA5String OID: EQUALITY: caseExactIA5Match MULTI-VALUED: No 4.14.4 The Attribute QosPolicyValueRef NAME: QosPolicyValueRef DESCRIPTION: A DN reference to a qosPolicyValue object. SYNTAX distinguishedName OID: EQUALITY: distinguishedNameMatch MULTI-VALUED: No 4.15 Class qosPolicyValue The class qosPolicyValue is used as an abstract class for defining values of constants and policy conditions. The class definition is as follows: NAME: qosPolicyValue DESCRIPTION: Superclass for representing values of constants DERIVED FROM: top TYPE: Abstract AUXILIARY CLASSES: none OID: MUST: QosPolicyValueType MAY: QosPolicyValueDescription Snir, et. al. Expires 25 December 1999 [Page 36] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 4.15.1 The Attribute QosPolicyValueType NAME: QosPolicyValueType DESCRIPTION: A well known type as defined [LDAP_ATTR]. SYNTAX: OID OID: EQUALITY: OIDMatch MULTI-VALUED: No 4.15.2 The Attribute QosPolicyValueDescription NAME: QosPolicyValueDescription DESCRIPTION: Self explanatory SYNTAX IA5String OID: EQUALITY: caseExactIA5Match MULTI-VALUED: No 4.16 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: Used to define an IP address DERIVED FROM: qosPolicyValue TYPE: Auxiliary AUXILIARY CLASSES: none OID: MUST: QosPolicyIPAddrValue, QosPolicyIPMaskValue MAY: 4.16.1 The Attribute QosPolicyIPAddrValue NAME: QosPolicyIPAddrValue DESCRIPTION: IP address represented as a string in A.B.C.D notation. SYNTAX IA5String OID: EQUALITY: caseExactIA5Match MULTI-VALUED: No 4.16.2 The Attribute QosPolicyIPMaskValue NAME: QosPolicyIPMaskValue DESCRIPTION: IP mask represented as a string in A.B.C.D notation SYNTAX IA5String OID: EQUALITY: caseExactIA5Match MULTI-VALUED: No Snir, et. al. Expires 25 December 1999 [Page 37] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 4.17 Class qosPolicyStringValue The qosPolicyStringValue is a class that is used to define a String value. The class definition is as follows: NAME: qosPolicyStringValue DESCRIPTION: Used to define the value of a string DERIVED FROM: qosPolicyValue TYPE: Auxiliary AUXILIARY CLASSES: none OID: MUST: QosPolicyStringValue MAY: 4.17.1 The Attribute QosPolicyStringValue NAME: QosPolicyValue DESCRIPTION: Used to define the value of a String. SYNTAX IA5String OID: EQUALITY: caseExactIA5Match MULTI-VALUED: No 4.18 Class qosPolicyNumberValue The qosPolicyNumberValue is a class that is used to define Integer values. The class definition is as follows: NAME: qosPolicyNumberValue DESCRIPTION: Used to define the value of a Number. DERIVED FROM: qosPolicyValue TYPE: Auxiliary AUXILIARY CLASSES: none OID: MUST: QosPolicyNumberValue MAY: 4.18.1 The Attribute QosPolicyNumberValue NAME: QosPolicyNumberValue DESCRIPTION: Used to define the value of a Number. SYNTAX IA5String OID: EQUALITY: caseExactIA5Match MULTI-VALUED: No Snir, et. al. Expires 25 December 1999 [Page 38] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 4.19 Class qosPolicyNumberRangeValue The qosPolicyNumberRangeValue is a class that is used to define Integer range values. The class definition is as follows: NAME: qosPolicyNumberRangeValue DESCRIPTION: Used to define integer ranges DERIVED FROM: qosPolicyValue TYPE: Auxiliary AUXILIARY CLASSES: none OID: MUST: QosPolicyFromValue, QosPolicyToValue MAY: 4.19.1 The Attribute QosPolicyFromValue NAME: QosPolicyFromValue DESCRIPTION: Lower boundary of the range. SYNTAX: Integer OID: EQUALITY: IntegerMatch MULTI-VALUED: No 4.19.2 The Attribute QosPolicyToValue NAME: QosPolicyToValue DESCRIPTION: Upper boundary of the range. SYNTAX: Integer OID: EQUALITY: IntegerMatch MULTI-VALUED: No 4.20 Class qosPolicyAtomFolders The qosPolicyAtomFolders is a class that is the root of a list of folders, each holding a list of reusable variables and constants. The hierarchy of folders is necessary for easy administration, such as Atom folder per namedPolicyContainer, or per type of policy. The class definition is as follows: NAME: qosPolicyAtomFolders DESCRIPTION: Root of folders that hold reusable variables and constants DERIVED FROM: Policy (Core) TYPE: Structural AUXILIARY CLASSES: none OID: MUST: QosPolicyFolderList MAY: Snir, et. al. Expires 25 December 1999 [Page 39] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 4.20.1 The Attribute QosPolicyFolderList NAME: QosPolicyFolderList DESCRIPTION: List of referred qosPolicyAtomfolder, each holding a list of reusable variables and constants. SYNTAX distinguishedName OID: EQUALITY: distinguishedNameMatch MULTI-VALUED: Yes 4.21 Class qosPolicyAtomFolder The qosPolicyAtomFolder is a container class for a list of reusable variable and constants. The class definition is as follows: NAME: qosPolicyAtomFolder DESCRIPTION: Container class for a list of reusable variable and constants. DERIVED FROM: Policy (Core) TYPE: Structural AUXILIARY CLASSES: none OID: MUST: FolderName MAY: QosPolicyVariables, QosPolicyConstants 4.21.1 The Attribute FolderName NAME: FolderName DESCRIPTION: Unique name for the folder in the Atoms repository. SYNTAX IA5String OID: EQUALITY: caseExactIA5Match MULTI-VALUED: No 4.21.2 The Attribute QosPolicyVariables NAME: QosPolicyVariables DESCRIPTION: List of reusable qosPolicyVariables. SYNTAX distinguishedName OID: EQUALITY: distinguishedNameMatch MULTI-VALUED: Yes 4.21.3 The Attribute QosPolicyConstants NAME: QosPolicyConstants DESCRIPTION: List of reusable qosPolicyConstants. SYNTAX distinguishedName OID: EQUALITY: distinguishedNameMatch MULTI-VALUED: Yes Snir, et. al. Expires 25 December 1999 [Page 40] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 4.22 Class qosPolicyConditionFolder The qosPolicyConditionFolder is a container class for a list of reusable qosPolicySimpleCondition objects. The class definition is as follows: NAME: qosPolicyConditionFolder DESCRIPTION: List of reusable qosPolicySimpleCondition objects DERIVED FROM: Policy (Core) TYPE: Structural AUXILIARY CLASSES: none OID: MUST: MAY: QosPolicyConditionList 4.22.1 The Attribute QosPolicyConditionList NAME: QosPolicyConditionList DESCRIPTION: List of reusable qosPolicySimpleConditions objects. SYNTAX distinguishedName OID: EQUALITY: distinguishedNameMatch MULTI-VALUED: Yes 4.23 Class qosPolicyAggDSPolicerFolder The qosAggDSPolicerListis a container class for a list of reusable qosPolicyDSPolicer objects. The class definition is as follows: NAME: qosPolicyAggDSPolicerFolder DESCRIPTION: List of reusable qosPolicyDSPolicer objects DERIVED FROM: Policy (Core) TYPE: Structural AUXILIARY CLASSES: none OID: MUST: MAY: QosAggDSPolicerList 4.23.1 The Attribute QosAggDSPolicerList NAME: QosAggDSPolicerList DESCRIPTION: List of reusable qosPolicyDSPolicer objects. SYNTAX distinguishedName OID: EQUALITY: distinguishedNameMatch MULTI-VALUED: Yes Snir, et. al. Expires 25 December 1999 [Page 41] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 4.24 Class qosPolicyRSVPPolicerFolder The qosPolicyRSVPPolicerFolder a container class for a list of reusable qosPolicyRSVPPolicer objects. The class definition is as follows: NAME: qosPolicyRSVPPolicerFolder DESCRIPTION: List of reusable qosPolicyRSVPPolicer objects DERIVED FROM: Policy (Core) TYPE: Structural AUXILIARY CLASSES: none OID: MUST: MAY: QosRSVPPolicerList 4.24.1 The Attribute QosRSVPPolicerList NAME: QosRSVPPolicerList DESCRIPTION: List of reusable qosPolicyRSVPPolicer objects. SYNTAX distinguishedName OID: EQUALITY: distinguishedNameMatch MULTI-VALUED: Yes 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 and the classes derived from it describe common value types: - Integer - String - IP address When other specific types are required, such as float or MAC address, the required class should be derived from qosPolicyValue and an attribute that is the required value should be added. If possible, the attribute name should be qosPolicyValue. Notice that the Type of the value must be well defined and standard for interoperability. 5.2 Subclassing qosPolicySimpleCondition Policy condition describes a single atomic boolean condition. For boolean conditions that are not structured as , a new type of condition calss should be added. An example would be an unary condition. Snir, et. al. Expires 25 December 1999 [Page 42] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 Subclassing could either be from the PolicyCondition class (Core) or the qosPolicySimpleCondition. Notice that the qosPolicySimpleCondition is an auxiliary class in order to allow attachment to the qosPolicy and derived class should remain so. 5.3 Subclassing qosPolicyAction QosPolicyAction as defined in the QoS Policy Schema includes at most three qos actions: - Coloring. - Traffic Shaping. - RSVP reservations. In order to add other actions to a certain qosPolicy or qosSubPolicy, additional actions should be added to the qosPolicyAction by deriving this class and adding the required attributes. Notice that the qosPolicyAction is an auxiliary class in order to allow attachment to the qosPolicy and derived class should remain so. 6. Security Considerations Security and denial of service considerations are not explicitly considered in this memo, as they are appropriate for the underlying policy architecture implementing the distribution and communication of the information described in this draft. However, the information in this draft explicitly makes use of the security measures recommended in the policy architecture defined by the Policy Framework working group. Specifically, any mechanisms used to distribute and communicate the information described in this draft must minimize theft and denial of service threats. Second, it must be ensured that the entities (such as PEPs and PDPs) involved in policy control can verify each other's identity and establish necessary trust before communicating. The communication tunnel between policy clients and policy servers SHOULD be secured by the use of an IPSEC [IPSEC] channel. It is advisable that this tunnel makes use of both the AH (Authentication Header) and ESP (Encapsulating Security Payload) protocols, in order to provide confidentiality, data origin authentication, integrity and replay prevention. 7. 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 Snir, et. al. Expires 25 December 1999 [Page 43] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 [PLYTERMS] J. Strassner, E. Ellesson, "Terminology for describing network policy and services", draft-ietf-policy-terminology-02.txt [LDAP_ATTR] M. Wahl, A. Coulbeck, " Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252 8. 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 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 E 190 West Tasman Drive San Jose, CA 95134 Phone: +1-408-527-1069 Fax: +1-408-527-2477 E-mail: johns@cisco.com 9. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. Snir, et. al. Expires 25 December 1999 [Page 44] INTERNET DRAFT draft-snir-policy-qos-infomodel-00.txt 25 June 1999 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Snir, et. al. Expires 25 December 1999 [Page 45]