Policy Framework Y. Snir Internet Draft Y. Ramberg Expires April 2000 J. Strassner R. Cohen draft-ietf-policy-qos-info-model-00.txt Cisco Systems January, 2000 Policy Framework QoS Information Model Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This document presents an object-oriented information model for representing network QoS policies. The QoS policy information model refines the core policy information model presented in [PFCORE]. Specifically, this draft refines the concept of generic policy rules, conditions and actions to cover extensions necessary for representing QoS policies. This information model covers Differential Service QoS enforcement, and Integrated Service QoS enforcement via policy control on RSVP admission. A companion document [QoSSCHEMA] defines the mapping of these classes to a directory that uses LDAPv3 as its access protocol. Snir, Ramberg, Strassner, Cohen expires September 2000 1 Draft-ietf-policy-qos-info-model-00.txt March 2000 Table of Contents 1. Introduction ...............................................5 2. Information model Hierarchy ................................5 3. Containment Hierarchy.......................................5 3.1. Containment Model ........................................6 3.2. QoS Domain Containment Hierarchy .........................7 3.2.1. Domain grouping and nesting ............................8 3.2.2. Resource sharing .......................................9 3.2.3. Placement ..............................................9 3.2.4. Named Policy Containers ...............................10 3.2.5. Policy rules ..........................................10 3.2.6. Conditions and Actions ................................11 3.2.7. Data tree example .....................................11 3.3. Reusable Objects Repositories ...........................12 3.4. Relationships between QoS Domains and repositories ......13 4. Constructing a QoS Policy Rule ............................13 4.1 Policy Rule Structure ....................................14 4.2 QoS Policy Condition .....................................14 4.2.1 Reusable vs. ad-hoc conditions .........................15 4.2.2. Using simple conditions ...............................16 4.2.3. Composing complex conditions ..........................16 4.3 Simple Condition operator ................................17 4.4. Variable ................................................17 4.4.1 Variable Binding .......................................18 4.4.2. Pre-defined Variables .................................18 4.5 QoS Policy Values ........................................21 4.6. PolicyTimePeriodCondition ...............................22 4.7. Actions .................................................22 4.7.1 Provisioning Actions ...................................22 4.7.2 Signaling Actions ......................................24 5. Decision strategy .........................................28 5.1. First match .............................................29 5.2. Match All ...............................................29 5.3. Decision Strategy example ...............................29 6. Per Hop Behavior ..........................................30 6.1. PHB .....................................................30 6.2. PHB Set .................................................31 7. QoS Policy Class Inheritance ..............................31 Snir, Ramberg, Strassner, Cohen expires September 2000 2 Draft-ietf-policy-qos-info-model-00.txt March 2000 8. Class definition ..........................................33 8.1. Class qosPolicyDomain ...................................33 8.1.1. The Property qpDomainName .............................33 8.1.2. The Property qpPHBSet .................................33 8.1.3. The Property qpPolicyRuleMatchMethod ..................33 8.2. Class qosNamedPolicyContainer ...........................33 8.2.1. The Property qpPriority ...............................34 8.2.2. The Property qpPolicyRuleMatchMethod ..................34 8.3. Class qosPolicyPRAction .................................34 8.3.1. The Property qpDirection ..............................35 8.3.2. The Property qpSetDSCPvalue ...........................35 8.3.3. The Property qpMeter ..................................35 8.3.4. The Property qpMeterScope .............................35 8.3.5. The Property qpPRTrfcProf .............................35 8.3.6. The Property qpOutOfProfileAction .....................35 8.3.7. The Property qpOutofProfileRemarkValue ................36 8.4. Class qosPolicyRSVPAction ...............................36 8.4.1. The Property qpDirection ..............................36 8.4.2. The Property qpRSVPMessageType ........................36 8.4.3. The Property qpRSVPStyle ..............................36 8.4.4. The Property qpRSVPServiceType ........................37 8.4.5. The Property qpRSVPInstallAction ......................37 8.4.6. The Property qpRSVPCtrlAction .........................37 8.4.7. The Property qpMeter ..................................37 8.4.8. The Property qpMeterScope .............................37 8.4.9. The Property qpRSVPTrfcProf ...........................37 8.5. Class qosPolicyPRTrfcProf ...............................38 8.5.1. The Property qpPRRate .................................38 8.5.2. The Property qpPRNormalBurst ..........................38 8.5.3. The Property qpPRExcessBurst ..........................38 8.6. Class qosPolicyRSVPTrfcProf ............................38 8.6.1. The Property qpRSVPTokenRate ..........................39 8.6.2. The Property qpRSVPPeakRate ...........................39 8.6.3. The Property qpRSVPBucketSize .........................39 8.6.4. The Property qpRSVPResvRate ...........................39 8.6.5. The Property qpRSVPResvSlack ..........................39 8.6.6. The Property qpRSVPSessionNum .........................39 8.6.7. The Property qpMinPolicedUnit .........................40 8.6.8. The Property qpMaxPktSize .............................40 8.7. Class qosPolicyRSVPSignalCtrlAction .....................40 8.7.1. The Property qpForwardingMode .........................40 8.7.2. The Property qpSendError...............................41 8.7.3. The Property qpReplaceDSCP ............................41 8.7.4. The Property qpPreemptionPriority .....................41 8.7.5. The Property qpDefendingPriority ......................41 8.8. Class qosPolicyRSVPInstallAction ........................41 8.8.1. The Property qpSetDSCPValue ...........................42 8.8.2. The Property qpSetDefendingPriority ...................42 8.8.3. The Property qpSetPreemptionPriority ..................42 Snir, Ramberg, Strassner, Cohen expires September 2000 3 Draft-ietf-policy-qos-info-model-00.txt March 2000 8.9. Class qosPolicySimpleCondition ..........................43 8.9.1. The Property qpOperator ...............................43 8.9.2. The Property qpVariableAtom ...........................43 8.9.3. The Property qpValueAtom ..............................43 8.10. Class qosPolicyVariable ................................44 8.10.1. The Property qpVariableName ..........................44 8.10.2 The Property qpValueTypes ...........................46 8.10.3. The Property qpVariableDescription ..................47 8.10.4. The Property qpValueConstraints ......................47 8.11. Class qosPolicyValue ...................................47 8.12. Class qosPolicyIPv4AddrValue ...........................48 8.12.1. The Property qpIPv4AddrList ..........................48 8.13. Class qosPolicyIPv6AddrValue ...........................49 8.13.1. The Property qpIPv6AddrList ..........................49 8.14. Class qosPolicyMACAddrValue ............................50 8.14.1. The Property qpMACAddrList ...........................50 8.15. Class qosPolicyStringValue .............................50 8.15.1. The Property qpStringList ............................51 8.16 Class qosPolicyBitStringValue ...........................51 8.16.1. The Property qpBitStringList .........................51 8.17. Class qosPolicyDNValue .................................52 8.17.1. The Property qpDNList ................................52 8.18. Class qosPolicyPropertyValue ...........................53 8.18.1. The Property qpPropertyName ..........................53 8.18.2. The Property qpPropertyValueList .....................53 8.19. Class qosPolicyIntegerValue ............................53 8.19.1. The Property qpIntegerList ...........................54 8.20. Class qosPolicyPHBSet ..................................54 8.21. Class qosPolicyPHB .....................................55 8.21.1. The Property qpDSCP ..................................55 8.22. Class qosPolicyElementAuxClass .........................55 9. Extending the QoS Policy Schema ...........................55 9.1. Extending qosPolicyValue ................................55 9.2. Extending qosPolicySimpleCondition ......................55 9.3. Extending qosPolicyAction ...............................55 10. Security Considerations ..................................56 11. Acknowledgments ..........................................56 12. References ...............................................56 13. Author's Addresses .......................................58 14. Full Copyright Statement .................................59 Snir, Ramberg, Strassner, Cohen expires September 2000 4 Draft-ietf-policy-qos-info-model-00.txt March 2000 1. Introduction This document presents an object-oriented information model for representing network QoS policies. The QoS policy information model refines the core policy information model presented in [PFCORE]. Specifically, this draft refines the concept of generic policy rules, conditions and actions to cover extensions necessary for representing QoS policies. This information model covers Differential Service QoS enforcement, and Integrated Service QoS enforcement via policy control on RSVP admission. A companion document [QoSSCHEMA] defines the mapping of these classes to a directory that uses LDAPv3 as its access protocol. The document presents high level QoS policies that can be used to enforce consistent behavior across a network, regardless of the actual vendor specific implementation details. The purpose of introducing a standard information model and schema is to allow interoperability between Policy Servers, Policy Management Applications, and Network devices. A standard schema allows each of these components to be built by different vendors, yet the final outcome of the QoS policies enforced on the network will be identical. The information model presented in this document contains information that can be shared by other network policy managers, e.g. Security managers, IP address managers, etc. Examples include sharing of the same definition of well-known application port numbers, IP addresses of servers and other network attributes. It allows checking of consistent behaviors of the interaction between the different managers by comparing for example the set of QoS and security actions enforced on the same set of flows. Representation of QoS capabilities of devices is described in a companion draft [QoSCAPABLE]. It allows deduction of the set of enforceable policies on each network device. Information model for representation of PHBs is further elaborated in [PHBSET]. The remainder of this document 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. 2. Information model Hierarchy This section discusses the hierarchy between the Core information model, the QoS information model and future extension of the QoS information model. The Core Policy information model models high-level policy concepts and introduces structural conventions and nomenclature common to all types of policies. The QoS Policy schema refines the concepts of the Core Schema and introduces a framework of classes dedicated to model QoS Policies that can be used to configure and manage RSVP and Differential service capable Snir, Ramberg, Strassner, Cohen expires September 2000 5 Draft-ietf-policy-qos-info-model-00.txt March 2000 devices and services. The QoS information model provides building blocks to control most of policy aspects, but it is clear that not all knobs are provided. The core and QoS information model are extensible. An implementation-specific schema that is derived from this schema should further concretize the QoS concepts of the QoS Policy schema. 3. Containment Hierarchy In this section we describe the organization and structure of the information model hierarchy. The QoS Policy information model consists of two hierarchies: A policy definition hierarchy and a reusable objects repository hierarchy. A particular data tree may contain any number of instances of each hierarchy. Section 3.1 explains the containment and reference model used in the construction of QoS Policy data trees. Section 3.2 describes the particular containment hierarchy of the policy definition entity, which is modeled by the QoSDomain class. Section 3.3 describes the structure of the reusable objects repository. Further down (section 3.4) we explain the relationships between those entities. 3.1. Containment model The QoS Policy Information Model employs containment model of [PFCORE]. The following paragraphs are a reminder and do not replace the detailed definitions of [PFCORE]. The fundamental data model of the QoS Policy definition information model is tree hierarchy. To describe the hierarchy of data in an actual instance of model data we use the term 'data tree'. A data tree is simply an arrangement of objects in a tree structure. The data tree starts from a root object node. The root node may have several branch nodes û these are just several objects placed "right below" the root. The tree construction involves placing objects as leaves of other objects while maintaining a strict tree structure. The basic mechanism used for expressing containment is data tree placement. To express the relationship of "container û contained" between a container object and the objects it contains, the contained objects are placed below the container object. Certain elements of the QoS Information Model need a mechanism for an entity to reference objects not on the same hierarchy as the referencing entity. For example, QoS Policy rules (PolicyRule [PFCORE]) is a container of actions and conditions (PolicyCondition, PolicyAction [PFCORE]). However, the information model should allow formation of (complex) conditions (and actions) where some of the condition's components are referenced remotely (e.g., a reusable simple condition) must be referenced because it always resides on a hierarchy different from the one where the referencing rule resides). Snir, Ramberg, Strassner, Cohen expires September 2000 6 Draft-ietf-policy-qos-info-model-00.txt March 2000 To support a unified mechanism for containment of "local" and "remote" objects, [PFCORE] introduces the notion of association classes. An association class is an intermediate placeholder for a contained object that may be a direct child of its container or a referenced remote object. The relationships between the container object and its contained element is then: Container | |-- Association classes (containment by placement) | |-- local contained objects (packed inside the assoc. | instances) | |-- remote contained objects (referenced by the assoc. instances) The association classes can (and do) carry the added semantics needed by the information model. For example, internal order of contained objects is information that can be carried on the association objects themselves, making the containment model more flexible (same object may be used by two containers but in a different position). Refer to [PFCORE] for details of the association class mechanism. 3.2. QoS Domain Containment Hierarchy The entity that represents a single policy hierarchy is called QOS Domain and is modeled by the qosDomain class, which is a derivative of the PolicyGroup class in [PFCORE]. Figure 1 shows a summary view of the QoS Domain containment hierarchy. The text in parenthesis denotes object containment style: either through data tree placement or through association classes. +---------------+ |qosPolicyDomain| (root) +-|-------------+ | +-----------------------+ -->|qosNamedPolicyContainer| (placement) +-|---------------------+ | +-------------+ -->|policyRule| | (placement) +-|-----------+ | | +------------------------+ |-->|qosPolicySimpleCondition| (via association) | +------------------------+ | | +---------------+ |-->|qosPolicyAction| (via association) +---------------+ Figure 1: Qos Domain containment hierarchy Snir, Ramberg, Strassner, Cohen expires September 2000 7 Draft-ietf-policy-qos-info-model-00.txt March 2000 3.2.1. Domain grouping and nesting QOS Domains may be grouped together to model multi-domain systems. Grouping may be desired to enhance various administrative tasks and may be required by a particular policy application. The grouping strategy (as well as all location-oriented strategies) is left for users/vendors to model based on their unique situation and requirement. This document presents guidelines and recommendations for grouping QoS Domains but specific implementations may use other techniques without violating the integrity and consistency of the information model. Grouping of QoS Domains can be done by creating a common root for several QoS Domain data tree instances. One way for doing this is by using the PolicyGroup [PFCORE] class as a root for the multi-domain tree. In this case we just place several QoS Domain instances under the root PolicyGroup instance. Figure 2 is an example that depicts the ability to provide different classes of service to different organizations within a single enterprise. The different organizations are each represented by a separate QoS policy domain (which is an instance of the qosPolicyDomain class). Each qosPolicyDomain class is used as a container to hold all of the policies of a given portion of the organization. In Figure 2 this level is represented by the nesting of qosPolicyDomain classes. Each qosPolicyDomain instance serves as a container that contains an ordered list of related QoS policy rule groups that apply to a different parts or functions of the domain (e.g., Eastern Sales vs. Western Sales). Each qosPolicyDomain contains a set of containers (implemented as instances of the qosNamedPolicyContainer class) that groups together QoS rules. +----------------+ |qosPolicyGroup | <-------------------QoS policies for an enterprise +--|-------------+ | +---------------+ -->|qosPolicyDomain| <--------------QoS policies for sales +-|-------------+ | +---------------+ |-->|qosPolicyDomain| <--------QoS policies for Western Sales | +-|-------------+ | | +-----------------------+ | |-->|qosNamedPolicyContainer| <--Qos Policies for group | | +-----------------------+ A within Western Region | | +-----------------------+ | -->|qosNamedPolicyContainer| <--Qos Policies for group | +-----------------------+ B within Western Region | | +---------------+ -->|qosPolicyDomain| <--------QoS policies for Eastern Sales +-|-------------+ (Figure continued in next page) Snir, Ramberg, Strassner, Cohen expires September 2000 8 Draft-ietf-policy-qos-info-model-00.txt March 2000 (Figure continued from previous page) | +-----------------------+ |-->|qosNamedPolicyContainer| <--Qos Policies for group | +-----------------------+ C within Eastern Region | +-----------------------+ -->|qosNamedPolicyContainer| <--Qos Policies for group +-----------------------+ d within Eastern Region Figure 2: Top-level policy data tree example The modeling approach used in the previous example is but one possible strategy among many. The information model allows for arbitrary nesting of groups, thus providing the means for modeling both wide and deep hierarchies. 3.2.2. Resource sharing While different hierarchy instances are indifferent to each other (no cross-referencing among QoS Domains), multiple QoS Domains may still share data by means of references to reusable objects (residing in a reusable objects repositories). The sharing of global or common definition enhances the interoperability of various policy agents thus serving the primary goal of this information model. Such commonly used building blocks as important conditions (PolicyCondition) and actions (PolicyAction) can be placed in the repository and used by policy rules. The information model does not restrict the number of repositories that can be referenced from a single QoS Domain. Even a single instance of a policy rule (PolicyRule) may contain references to objects residing in more than one repository. The information model does not dictate a QoS Domain wide scope for reusable objects (there's a many-to-many relationship between QoS Domains and reusable objects repositories). 3.2.3. Placement Intending to allow a flexible structure that does not pre-impose harsh restriction on data tree constructors, the information model must not contain a hidden assumption about placement of particular QoS Domains hierarchies (including, for that matter, placement of repositories as explained in section 3.3). Consequently, the information model does not require a certain pre-defined location for the portion of the data tree dedicated to policy. An instance of the global data tree (a corporate directory, for example) may contain several QoS Domains hooked to the tree in various places. Zero or more reusable objects repository may also be present in the global data tree. The information model does not dictate any standard organization of objects to be controlled via policy. The only location/organizational rule that must be followed is: Snir, Ramberg, Strassner, Cohen expires September 2000 9 Draft-ietf-policy-qos-info-model-00.txt March 2000 "Each QoS Domain must contain complete policy information either by containment of objects or by containment of association objects. In other words: Simple tree navigation and occasional reference chasing, starting at the tree root (QoS Domain) must lead to all policy definition objects needed to enforce the domain's policy." 3.2.4. Named Policy Containers A QoS Domain is a container of (named) QoS Policy Containers, as explained above. The information model class representing policy containers is QoSNamedPolicyContainer, which extends the PolicyGroup class of [PFCORE]. A (non-empty) policy container is an ordered list of policy rules (PolicyRule [PFCORE]). The order of the rules inside their container is interpreted as priority, where the top of the order is the highest prioritized element. Section 4 describes PolicyRules. As implied by the class name, each instance of a policy container must be assigned a name that must be unique within its QoS Domain. A given policy container must belong to (i.e.: contained in) a single QoS Domain. Sharing of policy containers among QoS Domains is not recommended because of the dependency of the decision strategy on the relative priority within each domain. The purpose of "dividing" a QoS Domain's policy rules among the domains' policy containers provides a flexible framework for fine grain administrative (or functional) structure. As the example shown in figure 2, it makes sense to divide policies for the sales organization into two regional containers: Western and Eastern. A change in policies for the Eastern region does not have to effect the policies currently in place for the Western region. Another policy system may take a slightly different approach in modeling its policy structure by assigning a different set of PHB's (see section 6) to different policy container, thus modifying the interpretation of policies of each policy container according to different specifications. Each policy container is assigned a "match strategy", which is a name of a method to interpret the order of its rules (see section 1.2.1.5). For example, a FirstMatch strategy means that the rules will be "matched" according to ascending order of their Priority attribute. Decision strategy is explained in section 5. Policy container can be nested. A policy container may contain policy rules (PolicyRule [PFCORE]) or named policy containers. A particular data tree, then, can be constructed as a deep hierarchy, if the designers of the policy system deem it desirable. 3.2.5. Policy rules Each named policy container holds a set of policy rules (or possibly policy containers that contain policy rules). QoS policy rules are modeled by the [PFCORE] class PolicyRule. Snir, Ramberg, Strassner, Cohen expires September 2000 10 Draft-ietf-policy-qos-info-model-00.txt March 2000 The semantics of a policy rule is, in essence, a conditional imperative statement in the form 'if then '. Applying a rule means to evaluate its condition and, depending on the truth value of the condition, wither execute the action or move along (do nothing). Evaluating a condition is known as 'matching the rule', an expression we'll be using further down. A given policy rule must belong to one (and only one) named container. 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. A policy rule is a composite object, made up from several objects (some reusable) and is viewed as a coherent statement. It is believed that allowing a policy rule to belong to more than one policy container would decrease its coherence. For example, the rule itself is "aware" of its position inside its policy container, so if we wanted to share a rule among many containers we'd have to remove this knowledge from the rule. The notion of order of rules is so essential to the concept of policy that removing it from the rule also renders the rule less expressive, making policy modeling a more difficult job. Furthermore, there are other important attributes that are unique to the rule's specific placement inside the policy group and/or the policy domain. For example, the DSCP values (section 6.) that define how a flow is colored (which in turn define the set of QoS actions that should be invoked by the rule) may be interpreted differently in different QoS domains (or policy containers). These examples show that the modeling of shared rules is inappropriate for the QoS Policy information model. 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 the policyRuleMatchMethod attribute of the qosNamedPolicyContainer object. 3.2.6. Conditions and Actions A policy rule is a composite object, as mentioned above. The most important components of a rule are the conditions and actions it contains. A condition is a Boolean expression that is evaluated to see if the rule should be applied. An action is a specification of QoS device configuration instruction that must be done if the rule is to be applied. Conditions and actions are discussed in detail [PFIM]. 3.2.7. Data tree example The following example illustrates the hierarchical nature of the QoS Policy data tree. Each organizational entity is related to a specific type of class, which is shown in parentheses. Snir, Ramberg, Strassner, Cohen expires September 2000 11 Draft-ietf-policy-qos-info-model-00.txt March 2000 There are two domains in this example, grouped together under the same root (domain grouping). The QoS Domains are: 1. EastCoast (qosPolicyDomain) 2. WestCost (qosPolicyDomain) Each of these two QoS policy domains has its PHB set. The EastCoast domain has 2 named policy containers. The first deals only with ERP traffic and the second handles all other traffic: 1. EastCoast (qosPolicyDomain) 1.1. ERP (qosNamedPolicyContainer) 1.2. General (qosNamedPolicyContainer). The WestCoast domain has 3 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 contains the rules relevant to ERP applications administrated by the west coast domain administrator. We see from the above structure that this structure provides the administrator with a great deal of flexibility. For example, similarly named containers, represented by the ERP and General qosNamedPolicyContainers, can reuse common policy conditions and actions. However, they are implemented as physically different containers to enable the administrator to administrate them according to their own domain-specific needs. 3.3. Reusable Objects Repositories Reusable objects are objects that can be referred to (hence "used by") from other objects. The reference is accomplished by allocating an attribute on the referencing object that contain the location of the referenced object. The concept of object repositories is introduced by [PFCORE] for the purpose of allowing data tree constructors to share data among many users as explained in section 1.2.1.2. The following sections are merely a reminder of the mechanism for modeling reusable objects repositories introduced in [PFCORE]. Snir, Ramberg, Strassner, Cohen expires September 2000 12 Draft-ietf-policy-qos-info-model-00.txt March 2000 A reusable objects repository hierarchy is rooted in an instance of the PolicyRepository class [PFCORE]. Individual repositories are named containers for reusable objects. Note that [PFCORE] allows arbitrary nesting of repositories, thus a repository of repositories is a natural modeling technique. Each named repository is a container of "reusable objects". A reusable object must have a unique name within the repository that container. The complete containment model for the reusable objects repositories, as well as detailed description of the various mechanisms for constructing and maintaining such repositories are described in great detail in [PFCORE]. Anywhere in the QoS Policy information model, where a reference to an object can be made (a 'reference' type attribute), this reference may point to a reusable object in a reusable objects repository. Common candidates for reusability are named instances of these classes: QoSPolicyVariable, QoSPolicyValue and its derivatives, QoSPolicySimpleCondition, PolicyAction and its derivatives, QoSPolicyPRTrfcProf, QoSPolicyRSVPTrfcProf and QoSPolicyPHBSet. Throughout this document we point out the possible use of repository and repository objects, wherever this is appropriate. 3.4. Relationships between QoS Domains and repositories As explained above, a QoS Domain contains within it groups of policy rules. A policy rule can contain ordered lists of conditions and actions. The conditions and actions may be reusable object that reside in reusable objects repositories. Many references to reusable objects may be made from the rules of a given QoS Domain. Those references need not be all poining to the same repository; even e single rule may contain references to reusable objects that reside in different repositories. The maintenance of the policy system is made somewhat more complicated due to the flexibility of the reference model. It is more difficult to prevent "dangling" references to repositories that are no longer present, for instance. Schema designers are encouraged to pay extra attention to this problem and exercise any technique available from their implementation platform to maintain integrity of their data trees. [PFCORE] discusses this issue as well. 4. Constructing a QoS Policy Rule A policy rule modeled in [PFCORE] represents the "If Condition then Action" semantics associated with a policy. The policyRule class uses the rule container class PolicyRuleInPolicyGroup to establish Snir, Ramberg, Strassner, Cohen expires September 2000 13 Draft-ietf-policy-qos-info-model-00.txt March 2000 containment relationships between a policy rule and possible sub-rules, modeled by the same PolicyRule class. 4.1 Policy Rule Structure A policy rule has the following attributes [PFCORE]: 1. Enable flag. 2. A Boolean condition. 3. Ordered list of Actions. 4. Informational attributes. The enable flag indicates whether a policy rule is administratively enabled, administratively disabled, or enabled for debug mode. Only enabled policy rules are enforced on the domain network. The Boolean condition is used to evaluate if the set of actions should be performed on a network flow by matching the network flow attributes against the condition. A condition is composed from qosPolicySimpleCondition conditions defined in this document and PolicyTimePeriodCondition conditions [PFCORE]. The combination of individual conditions in a policy rule is defined in [PFCORE] using ConditionInPolicyRule class. Each action in the list is modeled by an action derived from PolicyAction. The ActionInPolicyRule class defines the order of which policy actions are performed. Informational attributes correspond to various meta-data used for managing policy rules. The interpretation of a policy rule in regard to a given network flow may be expressed as follows: "If the rule is enabled and the Boolean expression is evaluated to TRUE, then use the Action list to extract the prescribed treatment for this flow." The rest of this section describes the components of the policyRule class and their relationships to the other classes defined in this schema. 4.2 QoS Policy Conditions A policy rule modeled in [PFCORE] represents the "If Condition then Action" semantics associated with a policy. A condition is represented as either an ORed set of ANDed conditions or an ANDed set of ORed conditions. Individual conditions may either be negated (NOT C) or unnegated (C). The actions specified by a policy rule are to be performed if and only if the policy rule condition evaluates to TRUE. Many conditions in policy rules, from a networking perspective, can be modeled as Filters. Filters are Snir, Ramberg, Strassner, Cohen expires September 2000 14 Draft-ietf-policy-qos-info-model-00.txt March 2000 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 central in the QoS Policy data model, and is modeled in the Network Model of DEN and used in the companion QoS capabilities draft [QoSCap]. The semantics of an individual condition is not specified in [PFCORE]. Conditions such as: "If the source IP address of the flow belongs to 10.1.x.x subnet" as well as "If the IP protocol number of the flow equals TCP protocol number" are modeled in this document. Individual conditions are modeled by the qosPolicySimpleCondition class using the triplet , and . The variable specifies the attribute of a flow that should be matched when evaluating the condition. A set of predefined variables that cover the basic network attribute are introduced to foster interoperability. The list cover layer 3 IP attribute such as IP network addresses, protocols and ports, as well as a set of layer 2 attributes and higher level attributes such as application and user identity. The variable is matched against a value to produce the Boolean result. In the first example above, a source IP address variable is matched against a 10.1.x.x subnet value. The operator specifies the type of relation between the variable and the value evaluated in the condition. Operators should model the 'belong to' and 'equal' relations in the examples above. In many cases, a generic 'match' operator can be used, and the interpretation of the relation between the variable and value is implied by the value itself. For example, the variable source IP address can be matched to an IP address, where the 'equal' relation is implied, to a hostname in which the 'resolve to' relation is implied, or to a subnet address in which 'belongs to' relation is implied. 4.2.1 Reusable vs. ad-hoc conditions This schema enables the reuse of simple conditions by placing them in a common portion of the policy information tree (called the reusable- objects repository). In order for a simple condition to be a member of this repository, it must carry a name, as any reusable object [PFCORE]). A qosPolicySimpleCondition can either directly contain a value and a variable, or can reference either one of them if they are kept in a repository. Simple condition composition must enforce the following type conformance rules: The qpValueTypes property of the variable must be compatible with the value class name. The QoS information model defines four different ways to compose a simple condition through the combination of representations of variables and values. The following combinations of representing a simple condition by references and containment are possible: Snir, Ramberg, Strassner, Cohen expires September 2000 15 Draft-ietf-policy-qos-info-model-00.txt March 2000 Variable representation 1. The class qosPolicyVariable may be contained in the qosPolicySimpleCondition instance. 2. The class qosPolicyVariable may be referenced from the qosPolicySimpleCondition instance (Reusable variable) Value representation 1. The qosPolicyValue class may be contained in the qosPolicySimpleCondition class. 2. The qosPolicyValue class may be referenced from the qosPolicySimpleCondition instance. This allows reusing the qosPolicyValue object, which could be named and considered a named constant. 4.2.2. Using simple conditions In most cases, the use of the qosPolicySimpleCondition class is sufficient for the definition of a condition for a policyRule. A simple condition can be added to a policyRule in two ways: 1. A direct attachment of an instance of the simple condition to the ConditionInPolicyRule instance. In this case we call this an "ad-hoc" simple condition. This method allows the creation of a "private" simple condition. This instance of the condition can't be referenced by any other policy rule, and therefore is not reusable. However, since it embeds the condition directly in the ConditionInPolicyRule instance, it eliminates the extra access(es) required to fetch each of the condition elements that are refernced by pointers. 2. Use the simple condition list attribute, ContainedCondition (defined in the ConditionInPolicyRule 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. 4.2.3. Composing 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 [PFCORE]). A complex condition is modeled by the mechanism supplied in PFCORE attributes: Snir, Ramberg, Strassner, Cohen expires September 2000 16 Draft-ietf-policy-qos-info-model-00.txt March 2000 1. The ConditionListType attribute of the policyRule, which is a boolean expression type (from the Core schema) that defines whether the simple condition is in conjunctive or disjunctive normal form. 2. The ConditionInPolicyRule class that defines whether the condition is negated or not and what is the associated group of the boolean expression this condition belongs to. For details see [PFCORE] section 6.3. 4.3 Simple Condition operator The QoS policy simple condition includes the qpOperator property, specifiing the type of relation between the variable and the value evaluated in the condition. In many cases, a generic 'match' operator can be used, and the interpretation of the relation between the variable and value is implied by the value itself. For example, the variable source IP address can be matched to an IP address, where the 'equal' relation is implied, to a hostname in which the 'resolve to' relation is implied, or to a subnet address in which 'belongs to' relation is implied. The QoS Policy information model defines a single operator: ômatchö that models the equal / belong to relationship. 4.4 QoS Policy Variable QoS Policy Variables are used for building individual conditions, as defined in section 4.2. The variable specifies the attribute of a flow that should be matched when evaluating the condition. Not every combination of a variable and a value creates a meaningful condition. A source IP address variable can not be matched against a value that specifies a port number. A given variable selects the set of matchable value types, i.e. a value that could be compared and evaluated to a Boolean expression. A variable may also limit the set of values within a particular value type that can be matched against it in a condition. For example, a source-port variable limits the set of values to represent integers in the range of 0-65535. Integers outside this range can not be matched to the 16 bits port entity. The property qpVariableName of the QosPolicyVariable class defines the well-known name used for ligical binding of this variable. The qpValueTypes is the list of value classes that could be matched to this variable, for example the source port variable qpValueTypes property will not include the QosPolicyIPv4AddrValue class for obvious reasons, but will include the QosPolicyIntegerValue class name. The qpValueConstraints will include a list of constraint on the variable; I.e. values that the Variable must match. In the above example the source port variable may include a constraint reference to a value object defining the integer range 0..63535. Snir, Ramberg, Strassner, Cohen expires September 2000 17 Draft-ietf-policy-qos-info-model-00.txt March 2000 4.4.1. Variable Binding For the QoS Policy schema to be interoperable, different policy management systems and policy servers must instantiate the same variables with identical values (in the same evaluation operation). While different policy servers may use a different binding mechanism, the binding logic must result in an identical instantiation. Each variable defined in the QoS policy repository must be bound to a logical entity such as a specific field in the IP header, application unique identifier or an application-specific parameter. When a policy server attempts to evaluate an expression containing variables, it must instantiate the variables. To instantiate a variable, that variable must be bound to a specific value (or values, depending on its type category) and associated with a logical entity. For example, in the expression '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. 4.4.2. Pre-defined Variables The purpose of this section is to explain the need and define the relationship of standard, frequently used variables with their logical entities. Pre-defined variables are necessary for ensuring interoperability among policy servers and policy management tools from different vendors. For example, different policy servers may have to evaluate the same policy rule. Variables enable the condition term to be abstracted such that its evaluation can be performed in the same way. The QoS Policy information model specifies a set of pre-defined variables to support a set of fundamental QoS variables such as IP header fields, user information, applications, 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. All standard variable names are case insensitive and do not include spaces or other non-standard characters. Snir, Ramberg, Strassner, Cohen expires September 2000 18 Draft-ietf-policy-qos-info-model-00.txt March 2000 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. Following is a table that defines the predefined Variable names and their binding. The table indicates which fields are checked in actual filters used in provisioning policies as well as in RSVP signaling messages. +-----------------+---------------------------------------------------+ |Variable name | Logical binding | +-----------------+---------------------------------------------------+ | SourceIP | The source IP address of the flow. Compared to the| | | source IP header field, or the sender address in | | | the RSVP Filter spec object [RSVP]. | +-----------------+---------------------------------------------------+ | SourcePort | The source Port of a UDP/TCP flow. Compared to the| | | source port field in the TCP/UDP header, or the | | | sender port in the RSVP Filter spec object [RSVP].| +-----------------+---------------------------------------------------+ | DestinationIP | The destination IP address of the flow. Compared | | | to the destination IP header field, or the session| | | address in the RSVP SESSION object [RSVP]. | +-----------------+---------------------------------------------------+ | DestinationPort | The destination Port of a UDP/TCP flow. Compared | | | to the destination port field in the TCP/UDP | | | header, or the session port in the RSVP SESSION | | | object [RSVP]. | +-----------------+---------------------------------------------------+ | IPProtocol | The IP protocol number. Compared to the protocol | | | number in the IP header field or to the IP | | | protocol in the RSVP SESSION object [RSVP]. | +-----------------+---------------------------------------------------+ | ToS | The ToS variable is bound to the IP header ToS | | | byte. | +-----------------+---------------------------------------------------+ | DSCP | The DSCP variable is bound to the IP header DSCP | | | byte or to DCLASS RSVP object. | +-----------------+---------------------------------------------------+ | DestinationMAC | The destination MAC address variable is bound the | | | frame destination MAC address. | +-----------------+---------------------------------------------------+ | SourceMAC | The source MAC address variable is bound the frame| | | source MAC address. | +-----------------+---------------------------------------------------+ | 8021QID | The VLAN ID as represented in the 802.1Q field of | | | the header. | +-----------------+---------------------------------------------------+ (Table continued in next page) Snir, Ramberg, Strassner, Cohen expires September 2000 19 Draft-ietf-policy-qos-info-model-00.txt March 2000 (Table continued from the previous page) +-----------------+---------------------------------------------------+ |Variable name | Logical binding | +-----------------+---------------------------------------------------+ | Snap | The snap protocol variable is bound to protocol | | | type carried over SNAP encapsulation. | +-----------------+---------------------------------------------------+ | Ethertype | The ethertype variable is bound to the frame | | | header ethertype value. | +-----------------+---------------------------------------------------+ | Ssap | The source sap variable is bound the frame header | | | field containing the source SAP. | +-----------------+---------------------------------------------------+ | Dsap | The destination sap variable is bound the frame | | | header field containing the destination SAP. | +-----------------+---------------------------------------------------+ | Application | The ID of the application that generated the flow.| +-----------------+---------------------------------------------------+ | User | The ID of the user that initiated the flow, or is | | | designated as the flow owner. | +-----------------+---------------------------------------------------+ Table 2. Pre-defined Variable Names and Their Bindings The definition of each predefined variable includes a standard name and the allowed value types, i.e. the variableÆs qpValueTypes property. Following is a table of variable names and their default allowed class types. +-----------------+---------------------------------------------------+ |Variable name | Allowed class types | +-----------------+---------------------------------------------------+ | SourceIP | qosPolicyIPv4AddrValue, qosPolicyIPv6AddrValue | +-----------------+---------------------------------------------------+ | SourcePort | qosPolicyIntegerValue | +-----------------+---------------------------------------------------+ | DestinationIP | qosPolicyIPv4AddrValue, qosPolicyIPv6AddrValue | +-----------------+---------------------------------------------------+ | DestinationPort | qosPolicyIntegerValue | +-----------------+---------------------------------------------------+ | IPProtocol | qosPolicyIntegerValue | +-----------------+---------------------------------------------------+ | ToS | qosPolicyIntegerValue, qosPolicyBitStringValue | +-----------------+---------------------------------------------------+ | DSCP | qosPolicyIntegerValue, qosPolicyBitStringValue | +-----------------+---------------------------------------------------+ (Table continued in next page) Snir, Ramberg, Strassner, Cohen expires September 2000 20 Draft-ietf-policy-qos-info-model-00.txt March 2000 (Table continued from previous page) +-----------------+---------------------------------------------------+ | DestinationMAC | qosPolicyMACAddrValue | +-----------------+---------------------------------------------------+ | SourceMAC | qosPolicyMACAddrValue | +-----------------+---------------------------------------------------+ | 8021QID | qosPolicyIntegerValue, qosPolicyBitStringValue | +-----------------+---------------------------------------------------+ | Snap | qosPolicyIntegerValue | +-----------------+---------------------------------------------------+ | Ethertype | qosPolicyIntegerValue | +-----------------+---------------------------------------------------+ | Ssap | qosPolicyIntegerValue | +-----------------+---------------------------------------------------+ | Dsap | qosPolicyIntegerValue | +-----------------+---------------------------------------------------+ | Application | qosPolicyDNValue, qosPolicyStringValue, | | | qosPolicyAttributeValue | +-----------------+---------------------------------------------------+ | User | qosPolicyDNValue, qosPolicyStringValue, | | | qosPolicyAttributeValue | +-----------------+---------------------------------------------------+ Table 3. Allowed Variable Names and Their Default Class Types For Value type definition check the QoS Policy Value section. 4.5 QoS Policy Value This abstract class QoSPolicyValue is used for defining values and constants used in policy conditions. Different value types are derived from this class and represent the various attributes required. Extensions off the QoS Polictvalue class, defined in this document provide a list of values for representing the basic network attribute. Values can be used to represent constants as named values. Named values could be kept in a repository to be reused by multiple conditions. Examples of constants include well-known ports, well-known protocol, server addresses, etc. The QoS Policy value classes define 3 types of basic values, scalars, ranges and sets. For example a well-known port number could be defined using the qosPolicyIntegerValue, defining a single value (80 for HTTP) a range (80-88) or a set (80, 82, 8080). For details see the class definition for each value type. The QoS policy information model provide the following classes, all of them extending the QoSPolicyvalue: General: QosPolicyStringValue QosPolicyIntegerValue, Snir, Ramberg, Strassner, Cohen expires September 2000 21 Draft-ietf-policy-qos-info-model-00.txt March 2000 QosPolicyBitStringValue, QosPolicyDNValue, QosPolicyAttributeValue. Layer 3 Network values: qosPolicyIPv4AddrValue, qosPolicyIPv6AddrValue. Layer 2 Network values: QosPolicyMACAddrValue. For details see class definition section of each value. 4.6. PolicyTimePeriodCondition The QoS Policy Information model uses the PolicyTimePeriodCondition class [PFCORE] to define time based QoS Policy rules. For details see [PFCORE] section 6.5. 4.7. Actions The QoS Policy schema defines actions to control QoS enforcement in both the Integrated-Service model as well as the Differential service model. Two types of actions are provided: Signaling and Provisioning actions. Signaling actions are used to provide policy control on RSVP requests. Provisioning actions are used to directly control the data traffic, regardless of any out-of-band signaling. A Policy rule may include 0..n provisioning actions and 0..m signaling actions objects, each defining an action to perform. Actions are ordered (prioritized). The order of actions is specified in [PFCORE]; Order of actions for a rule is determined by the integer value assigned to the policyActionOrder property of the policyRuleActionAssociation class. Provisioning and signaling actions are intermixed in the rule. Policy consumers (such as PDPs) may separate the actions to two lists but must respect the internal order of the specified actions. QoS Policy action classes extend the [PFCORE] PolicyAction class. Additional type of actions may be added as extensions to this schema by extending the PolicyAction and using the current mechanisms. 4.7.1 Provisioning Actions QoS Policy provisioning actions model traffic conditioner [DIFF-SERV- ARCH] elements. Actions model meters, markers, shapers and droppers. 1. Meters measure the temporal properties of the stream of packets selected by a classifier against a traffic profile. QosPolicyMeter object models a meter. A meter can be shared between different policy rules. A meter shared by more than one policy rule resides in a repository and is referenced by all sharing rules. The property QpMeter holds a reference to a meter kept in repository. The qpMeterScope Snir, Ramberg, Strassner, Cohen expires September 2000 22 Draft-ietf-policy-qos-info-model-00.txt March 2000 property specifies whether the meter should measure flows matching the rule condition per interface, per device or per flow. A per flow meter conceptually creates a new meter for each flow, measuring each flow against the profile. A per interface meter measures the aggregate set of flows matching the rule condition forwarded via a single interface. Meters are measured against traffic profile modeled by the qosPolicyPRTrfcProf object. The property qpTrfcProf holds a reference to a traffic profile that resides in a repository. 2. Markers set the DS field of a packet to a particular DS codepoint, adding the marked packet to a particular DS behavior aggregate. The marker may be configured to mark all packets steered to it to a single codepoint, or may be configured to mark a packet to one of a set of codepoints used to select a PHB in a PHB group, according to the state of a meter. When the marker changes the codepoint in a packet it is said to have "re-marked" the packet. Marking is modeled by the property qpSetDSCPValue specifying the DS code-point to set. Remarking out-of- profile packets is modeled by the qpOutofProfileRemarkValue property. The property qpOutOfProfileAction should be set to 'remark' when the remark DSCP value is used. 3. Shapers delay some or all of the packets in a traffic stream in order to bring the stream into compliance with a traffic profile. A shaper usually has a finite-size buffer, and packets may be discarded if there is not sufficient buffer space to hold the delayed packets. The property qpOutOfProfileAction 'shape' specify that packets measured by a meter should be shaped according to the traffic profile specified by a qosPoilicyPRTrfcProf. 4. Droppers discard some or all of the packets in a traffic stream in order to bring the stream into compliance with a traffic profile. This process is known as "policing" the stream. The property qpOutOfProfileAction 'drop' specify that packets measured by a meter should be policed according to the traffic-profile specified by a qosPoilicyPRTrfcProf. Example for a rule enforcing QoS provisioning actions: Rule P = If () than mark = AND activate a per- flow policer AND activate a per policy rule policer . Activate rule on outgoing traffic. Rule P is represented using 3 qosPolicyPRAction objects: Object 1: qpDirection: OUT qpSetDSCPValue: Object 2: qpDirection: OUT qpMeterScope: flow qpTrfcProf: DN (repository reference) qpOutOfProfileAction: discard Snir, Ramberg, Strassner, Cohen expires September 2000 23 Draft-ietf-policy-qos-info-model-00.txt March 2000 Object 3: qpDirection: OUT qpMeterScope: Interface qpTrfcProf: DN (repository reference) qpOutOfProfileAction: discard qpMeter: Some PHBs require the successive application of a number of traffic conditioners. An example of a policy with two levels of traffic conditioners is the following: "Mark packets to DSCP=24 if rate is within profile x=<64Kb/s>, else mark packets with DSCP=25 if rate is within profile y=<128kb/s>, else drop out-of-profile packets". This policy rule is modeled by using two actions. The first action measures the traffic against the first profile specifying DSCP=24 to set for within profile packets. Out-of-profile packets are marked to DSCP=23. The subsequent action measured traffic against the second higher profile, and drops out-of-profile packets. Arbitrary cascading of traffic conditioners can be constructed, where each action measures traffic against a higher traffic profile and change only the out-of- profile action as required. 4.7.2 Signaling Action RSVP is the standard protocol used for requesting QoS resources from the network. The QoS Policy signaling actions control the decision whether to admit or reject an RSVP request based on the request's attributes and the specified policy. The QoS policy signaling actions allow modifying the content and forwarding behavior of RSVP requests. The signaling policies control the admission priority of resources and provide preemption support. Mapping of integrated services signaled by RSVP to differential services in a core network is controlled by signaling policies as well, by assigning DSCP to flows on the boundary of the differential service core. The set of policies specified allow a policy server (policy decision point) to instruct an RSVP node (policy enforcement point) to enforce all set of controls defined in the COPS protocol specification. The actions defined here follow the different decision types of the COPS protocol [COPS] and the guidelines for it's use in RSVP environment [COPS-RSVP]. The basic decision to accept or deny a reservation is modeled by qosPolicyRSVPAction. Two supplements can be added to this decision. qosPolicyRSVPSignalCtrlAction controls the content and forwarding behavior of RSVP flows. qosPolicyRSVPInstallAction controls the processing of RSVP requests and accompanying flows within the RSVP node itself. QoS signaling policies does not require a policy server for decision making. A local policy module can use signaling policies for making local decisions, as well as if other outsourcing policy protocol beside COPS is used. Snir, Ramberg, Strassner, Cohen expires September 2000 24 Draft-ietf-policy-qos-info-model-00.txt March 2000 The qosPolicyRSVPAction action includes a specification of the subset of RSVP flows on which the action should be taken. The following parameters can be specified: 1. Direction - in/out 2. Message type - Path/Resv/PathErr/ResvErr 3. Service type - Gaurenteed Service / Controlled Load / Null 4. Service style - SE, WF, FF The direction refers to the direction of the flow, hence the direction of the RSVP Path messages. Therefore out-direction policies control outgoing Path messages as well as incoming Resv messages. The basic decision modeled by this class is whether to admit or reject the RSVP request. The decision can be based on comparison of the request TSPEC or FLOWSPEC to a traffic profile and a meter. A meter can be used to track the temporal resources allocation of RSVP requests matching a network condition. Such meters allow enforcement of policies of the form: "Allow allocation of resource via RSVP for flows coming from subnet x up to a total aggregated rate of 256kb/sec". Use of meters and meter scope is identical to their use in provisioning policies. The following properties are used: 1. Traffic Profile - referencing a traffic profile. 2. Meter - referencing a meter. Both traffic profile and meter can be directly included within the action as well. Note that if traffic profile is not provided, it is implicitly assumed that the RSVP request should be accepted. Rejecting all RSVP request matching the condition is specified by a zero valued traffic profile. The qosPolicyRSVPInstallAction adds the following controls: 1. Set DSCP value 2. Set the Preemption priority of the RSVP request. Setting DSCP on the flow on the edge of a differential service core allow provisioning of QoS end to end over a mixed integrated and differential service clouds. RSVP node is responsible for admission decision based on its available resources. Setting preemption priority [RSVP_PREEMP] allows the RSVP node to decide which of its reservations should be admitted, and when to make room for a newer reservation by preempting an already installed one. This class should be extended to cover other COPS install decisions if required. The qosPolicyRSVPSignalCtrlAction adds the following controls: 1. Replace/add DCLASS object in RSVP message. 2. Replace/add Preemption priority object in RSVP message. 3. Trigger an error/warning RSVP message. Snir, Ramberg, Strassner, Cohen expires September 2000 25 Draft-ietf-policy-qos-info-model-00.txt March 2000 4. Instruct the RSVP node to proxy RSVP message as if sent by the RSVP end nodes. Modifying the content of messages can be enforced using COPS replace decision. This class should be extended to cover other object replacements and in particular replacement of policy objects. Triggering error and warnings is important in scenarios when there is a need to notify the end nodes that their reservation is about to expire and various other information. There are scenarios in which it makes sense not to carry RSVP requests end to end. An RSVP node on the boundary of a differential service core may map the RSVP request to specific PHB by setting the DSCP on the flow packets, without forwarding the Path message downstream. Still, this RSVP node may send back an RSVP Resv message as if the receiver has sent it, to complete the RSVP cycle. Example for a rule enforcing QoS signaling actions: Rule S = If () than accept RSVP request requesting less ore all traffic exceeds the rate limit. Traffic that falls between the normal burst size and the Excess Burst size exceeds the traffic profile with a probability that increases as the burst size increases. This provides a Random Discard mechanism for policer, markers and shapers. Excess burst size should be larger than normal burst size. If excess burst is not specified, it is assumed that excess burst size is equal to normal burst size. In this case, burst larger than the normal burst size will always be counted as out-of-profile packets. RSVP signaling QoS policy can condition the decision whether to accept or deny an RSVP request based on the traffic specification of the flow (TSPEC) or the amount of QoS resources requested (FLOWSPEC). The TSPEC and FLOWSPEC objects are either compared directly with a traffic profile, or aggregated to a meter that measures the temporal admitted RSVP states and than compared to the traffic specification. QosPolicyRSVPTrfcProf class models such a traffic profile. The qosPolicyRSVPTrfcProf class has the following properties: 1. Token Rate (r) measured in bits/sec. 2. Peak Rate (p) measured in bits/sec. 3. Bucket Size (b) measured in bytes. 4. Min Policed unit (m) measured in bytes. 5. Max packet size (M) measured in bytes. 6. Resv Rate (R) measured in bits/sec. 7. Slack term (s) measured in microseconds. 8. Number of sessions. The first 5 parameters are the traffic specification parameters used in integrated service. For a definition and full explanation of their meaning refer to [RSVP-IS]. These parameters are used to define a Snir, Ramberg, Strassner, Cohen expires September 2000 27 Draft-ietf-policy-qos-info-model-00.txt March 2000 sender TSPEC as well as FLOWSPEC for the Controlled Load service [CL]. Parameters 6 and 7 are the additional parameters used for specification of the Guaranteed Service FLOWSPEC [GS]. A partial order is defined between TSPECs (and FLOWSPECs). A TSPEC A is larger than TSPEC B if and only if rA>rB, pA>pB, bA>bB, mAMB. A TSPEC RSVP measured against a traffic profile use the same ordering rule. An RSVP message is accepted only if its TSPEC (FLOWSPEC) is either smaller or equal to the traffic profile. Only parameters specified in the traffic profile are compared. GS FLOWSPEC is compared also against the rate R and the slack term S. R should not be larger than the traffic profile R parameter, while the FLOWSPEC slack term should not be smaller than that specified in the slack term. TSPECs as well as FLOWSPECs can be added. The sum of two TSPECs is computed by summing the rate r, the peak rate p, the bucket size b, and by taking the minimum of min policed unit m and the maximum of the max packet size M. GS FLOWSPECs are summed by adding the Resv rate and minimizing the slack term s. These rules are used to compute a meter that measures the temporal state of admitted RSVP states. The meter is than compared with the traffic profile specified in the signaling policy using the same rules for comparison of TSPECs (FLOWSPECs) to a traffic profile. RSVP traffic profile may specify also the maximal number of allowed RSVP sessions. This provides an easy way to limit the number of admitted RSVP requests without pre knowledge of the aggregated rates requested. 5. Decision strategy The decision strategy to be used by policy servers and other policy decision points in the network 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 is defined per domain and can be overridden per qosNamedPolicyContainer. When a policy decision point evaluates a set of rules, it implements the decision strategy defined in each container of rules. Nested containers can override the decision strategy of their containers. The order of decision making of nested rules is defined by their internal priority, the priority of the policy rule containing the nested rule and the priority of their containers. Nested rules have a higher priority then their containing rule. Priority is compared between rules and qosNameddContainers, as defined in [PCIM]. Snir, Ramberg, Strassner, Cohen expires September 2000 28 Draft-ietf-policy-qos-info-model-00.txt March 2000 Two decision strategies are defined: 1. "FIRST MATCH" 2. "MATCH ALL" 5.1. First match The first match decision strategy is defined as a process that evaluates the policy rules in the defined order, evaluating the rules' conditions, until a condition is evaluated to TRUE. The rule's actions are applied and the process of decision-making is complete. 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. 5.3. Decision Strategy example This section demonstrates both decision strategies and rule prioritization. Domain | +--Rule1 (priority 19) | +--NamedContainer1 (priority 5) | | | +--Rule 1.1 (priority 303) | | | +--Rule 1.2 (priority 3) | +--Rule3 (priority 4) | +--Rule4 Figure 3: Decision Strategy example For simplicity we assume that a Policy Decision Point needs to enforce all rules described above. Snir, Ramberg, Strassner, Cohen expires September 2000 29 Draft-ietf-policy-qos-info-model-00.txt March 2000 The rules will be evaluated in the following order: 1. Rule1 (higher priority between Rule1, namedContainer1 and Rule3 2. Rule1.2 (higher priority between Rule1.1 and Rule1.2) 3. Rule1.1 4. Rule4 (nested in Rule 3) 5. Rule3 If the decision strategy of the domain is first match and it is not overridden by NamedContainer1, the decision process stops once a rule's condition is matched. If the decision strategy of the domain is match all and it is not overridden by NamedContainer1, the match-all decision process runs over all rules according to the order above. If the decision strategy of the domain is first match and the decision process of NamedContainer1 is match all, Rule1 will be evaluated first. If its condition matches, the decision process stops. Else, both Rules 1.1 and 1.2 will be evaluated and executed if their condition match. If one of NamedContainer1 rule match, the decision process stops. Else Rules 3 and 4 will be evaluated using first match decision strategy. If the decision strategy of the domain is match all and the decision process of NamedContainer1 is first match, the decision process will evaluate Rule1 and continue to evaluate NamedContainer1 rules. Rules 1.1 and 1.2 will be evaluated using first match strategy. The decision process continues to evaluate rules 3 and 4 according to match-all decision strategy. 6. Per Hop Behavior A per-hop behavior (PHB) is a description of the externally observable forwarding behavior of a DS node applied to a particular DS behavior aggregate. A PHB is selected at a node by the DS codepoint in a received packet. A set of PHBs is enforced on a QoS domain. The set of PHBs share buffer and scheduler resources among them. The QoS informational model provides abstract placeholders for PHBs and for a set of PHBs enforced together on a QoS domain. Further specification of PHBs and PHP sets are outside the scope of this document. 6.1. PHB The qosPolicyPHB abstract class models a single PHB. The qosPolicyPHB class includes a single property, the DSCP value, an integer with allowed value of 0 to 63. The qosPolicyPHB name will be defined using the cn property belonging to the Policy class [PFCORE]. Snir, Ramberg, Strassner, Cohen expires September 2000 30 Draft-ietf-policy-qos-info-model-00.txt March 2000 6.1. PHB Set The qosPolicyPHBSet abstract class serves as a named container for instances of qosPolicyPHB classes. It models the set of PHBs enforced together on a QoS domain. Different PHB sets can be kept in a repository. A PHB set enforced on the domain is specified by either a reference from the qosPolicyDOmain class to one of the repository PHB sets, or by directly attaching a PHB set to the domain class. To fine tune PHB parameters and to further restrict the namespace in which a particular PHB is used, PHB sets can be referenced or attached to qosNamedPolicyContainers. In order to maintain an end to end consistent behavior, overriding the domain's PHB set should be done only to fine tune the parameters of each PHBs, and not to use different set of PHBs altogether. Markers coloring packets of flows on domain ingress edges should pick a DS codepoint selecting one of the PHB enforced on the QoS domain. 7. QoS Policy Class Inheritance The following diagram illustrates the class hierarchy for the Policy schema classes (relevant Core classes are included): top | +--policy (abstract) | | | +--policyGroup | | | | | +--qosPolicyDomain | | | | | +--qosNamedPolicyContainer | | | | | +--policyRule | | | +--policyRuleConditionAssociation | | | +--policyRuleActionAssociation | | | +--policyConditionInstance | | | +--policyActionInstance | | | +--policyInstance | | | | (Diagram continued in next page) Snir, Ramberg, Strassner, Cohen expires September 2000 31 Draft-ietf-policy-qos-info-model-00.txt March 2000 (Diagram continued from previous page) | +--policyCondition | | | | | +--qosPolicySimpleCondition | | | | | +--qosPolicyVariable | | | | | +--qosPolicyValue(abstract) | | | | | +--qosPolicyIPv4AddrValue | | | | | +--qosPolicyIPv6AddrValue | | | | | +--qosPolicyMACAddrValue | | | | | +--qosPolicyStringValue | | | | | +--qosPolicyBitStringValue | | | | | +--qosPolicyDNValue | | | | | +--qosPolicyAttributeValue | | | | | +--qosPolicyIntegerValue | | | +-- qosPolicyMeter | | | +-- qosPolicyPRTrfcProf | | | +-- qosPolicyRSVPTrfcProf | | | +-- qosPolicyPHBSet (abstract) | | | +-- qosPHB (abstract) | +--policyActionAuxClass | | | +-- qosPolicyPRAction | | | +-- qosPolicyRSVPAction | | | +-- qosPolicyRSVPSignalCtrlAction | | | +-- qosPolicyRSVPInstallAction | +--policyRepository Note: classes with a "qos" prefix are QoS Policy Schema classes. Snir, Ramberg, Strassner, Cohen expires September 2000 32 Draft-ietf-policy-qos-info-model-00.txt March 2000 8. Class definition: 8.1. 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 has a potentially different set of PHBs and policies, access rules, decision strategy or other application of the policy information organized in some fashion. The class definition is as follows: NAME qosPolicyDomain DESCRIPTION A class that is the root of an administrative QoS policy domain, which resides in the PolicyGroup container. It contains a group of named policy containers. DERIVED FROM PolicyGroup (Core) PROPERTIES qpDomainName, qpPHBSet, qpPolicyRuleMatchMethod 8.1.1. The Property qpDomainName NAME qpDomainName DESCRIPTION A user-friendly name of the QoS policy domain. SYNTAX String 8.1.2. The Property qpPHBSet NAME qpPHBSet DESCRIPTION Reference to the PHB set defined for the domain. SYNTAX Reference 8.1.3. The Property qpPolicyRuleMatchMethod NAME qpPolicyRuleMatchMethod DESCRIPTION The decision strategy to be applied on this set of qos policy rules by policy servers. SYNTAX Integer ENUM[] - {"FIRST MATCH " = 1; "MATCH ALL " = 2 } 8.2. 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: Snir, Ramberg, Strassner, Cohen expires September 2000 33 Draft-ietf-policy-qos-info-model-00.txt March 2000 NAME qosNamedPolicyContainer DESCRIPTION A class that is a logical and physical container of policies. DERIVED FROM PolicyGroup (Core) PROPERTIES qpPriority, qpPolicyRuleMatchMethod 8.2.1. The Property 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 each be evaluated before other objects that have a numerically lower priority. SYNTAX Integer 8.2.2. The Property qpPolicyRuleMatchMethod NAME qpPolicyRuleMatchMethod DESCRIPTION The decision strategy to be applied on this set of qos policy rules by policy servers. SYNTAX Integer ENUM[] - {"FIRST MATCH " = 1; "MATCH ALL " = 2 } 8.3. Class qosPolicyPRAction This class defines Diff-Serv actions to be applied on a flow, including marking of DSCP value, policing and shaping. The class definition is as follows: NAME qosPolicyPRAction DESCRIPTION A class that defines Provisioning Diff-Serv Traffic action to be applied on a specific flow or group of flows. DERIVED FROM PolicyAction (Core) ABSTRACT False PROPERTIES qpDirection, qpSetDSCPvalue, qpMeter, qpMeterScope, qpTrfcProf, qpOutOfProfileAction, qpOutOfProfileRemarkValue Snir, Ramberg, Strassner, Cohen expires September 2000 34 Draft-ietf-policy-qos-info-model-00.txt March 2000 8.3.1. The Property qpDirection NAME qpDirection DESCRIPTION this Property defines the direction of the action, incoming or/and outgoing interfaces. SYNTAX Integer [ENUM] {IN=0,OUT=1} 8.3.2. The Property qpSetDSCPvalue NAME qpSetDSCPvalue DESCRIPTION this Property defines DSCP value of the mark action. SYNTAX Integer 8.3.3. The Property qpMeter NAME qpMeter DESCRIPTION A reference to a qosPolicyMeter object used in this provisioning action. SYNTAX Reference 8.3.4. The Property qpMeterScope NAME qpMeterScope DESCRIPTION An integer, enum, that defines the scope of the metering action. SYNTAX Integer enum [flow=0,interface=1 device=2] 8.3.5. The Property qpPRTrfcProf NAME qpPRTrfcProf DESCRIPTION This Property contains the DiffServ / provisioning Policing instruction value, defined as a reference to a qosPolicyPRTrfcProf entry. SYNTAX Reference 8.3.6. The Property qpOutOfProfileAction NAME qpOutOfProfileAction DESCRIPTION The action to be applied to out of profile packets, as defined in the DiffServTrfcProf entry. SYNTAX Integer [ENUM] {SHAPE=0,DISCARD=1,REMARK=2} Snir, Ramberg, Strassner, Cohen expires September 2000 35 Draft-ietf-policy-qos-info-model-00.txt March 2000 8.3.7. The Property qpOutofProfileRemarkValue NAME qpOutofProfileRemarkValue DESCRIPTION The DSCP value to be applied to out of profile packets if the qpOutofProfile action is defined as REMARK. SYNTAX Integer 8.4. Class qosPolicyRSVPAction This class defines a policy action to be applied on an RSVP signaling messages that match the rule condition. The class definition is as follows: NAME qosPolicyRSVPAction DESCRIPTION A class that defines an RSVP action to be performed if a certain rule's condition is met. DERIVED FROM PolicyAction (Core) ABSTRACT False PROPERTIES qpDirection, qpRSVPMessageType[], qpRSVPService[], qpRSVPStyle[], qpRSVPInstallAction, qpRSVPCtrlAction, qpMeter, qpMeterScope, qpRSVPTrfcProf, 8.4.1. The Property qpDirection NAME qpDirection DESCRIPTION this Property defines the direction of the action, incoming or/and outgoing interfaces. SYNTAX Integer [ENUM] {IN=0,OUT=1} 8.4.2. The Property qpRSVPMessageType NAME qpRSVPMessageType DESCRIPTION this Property limits the scope of the action to be enforced only on specific type of RSVP messages. SYNTAX Integer [ENUM] { Path=0 Resv=1 ResvErr=2 PathErr=3} 8.4.3. The Property qpRSVPStyle NAME qpRSVPStyle DESCRIPTION this Property limits the scope of the action to be enforced only on RSVP Requests with the specified reservation style. SYNTAX Integer [ENUM] {SE=0 FF=1 WF=2} Snir, Ramberg, Strassner, Cohen expires September 2000 36 Draft-ietf-policy-qos-info-model-00.txt March 2000 8.4.4. The Property qpRSVPServiceType NAME qpRSVPServiceType DESCRIPTION this Property limits the scope of the action to be enforced only on RSVP Requests asking for specified integrated service type. SYNTAX Integer [ENUM] {ControlledLoad =1 , GuaranteedService =2, NULL=3} 8.4.5. The Property qpRSVPInstallAction NAME qpRSVPInstallAction DESCRIPTION A reference to a qpRSVPInstallAction object used in conjunction with the RSVP reservation. SYNTAX Reference 8.4.6. The Property qpRSVPCtrlAction NAME qpRSVPCtrlAction DESCRIPTION A reference to a qpRSVPCtrlAction object used in conjunction with the RSVP reservation. SYNTAX Reference 8.4.7. The Property qpMeter NAME qpMeter DESCRIPTION A reference to a qosPolicyMeter object used in this RSVP action. SYNTAX Reference 8.4.8. The Property qpMeterScope NAME qpMeterScope DESCRIPTION An integer, enum, that defines the scope of the metering action. SYNTAX Integer enum [flow=0,interface=1 device=2] 8.4.9. The Property qpRSVPTrfcProf NAME qpRSVPTrfcProf DESCRIPTION A reference to RSVPTrfcProf object that define the traffic profile compared with TSPEC or FLOWSPEC objects, or with value kept in meter. SYNTAX Reference Snir, Ramberg, Strassner, Cohen expires September 2000 37 Draft-ietf-policy-qos-info-model-00.txt March 2000 8.5. Class qosPolicyPRTrfcProf A provisioning Traffic profile is a class that carries the policer or shaper rate values to be enforced on a flow or a set of flows. The class definition is as follows: NAME qosPolicyPRTrfcProf DESCRIPTION A class that carries the policer or shaper rate values to be enforced on a flow or a set of flows. DERIVED FROM Policy (Core) ABSTRACT False PROPERTIES qpPRRate, qpPRNormalBurst, qpPRExcessBurst 8.5.1. The Property qpPRRate NAME qpPRRate 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 8.5.2. The Property qpPRNormalBurst NAME qpPRNormalBurst DESCRIPTION The normal size of a burst measured in bytes SYNTAX Integer 8.5.3. The Property qpPRExcessBurst NAME qpPRExcessBurst DESCRIPTION The excess size of a burst measured in bytes SYNTAX Integer 8.6. Class qosPolicyRSVPTrfcProf This class represents an IntServ RSVP Traffic profile. Values of RSVP traffic profiles are compared against Traffic specification (TSPEC) and QoS Reservation requests (FLOWSPEC) carried in RSVP requests. Traffic profiles can be reusable objects or ad-hoc. The class definition is as follows: NAME qosPolicyRSVPTrfcProf DESCRIPTION A class that defines rate limiting values for QoS requests for a flow or a set of flow via RSVP Snir, Ramberg, Strassner, Cohen expires September 2000 38 Draft-ietf-policy-qos-info-model-00.txt March 2000 DERIVED FROM Policy (Core) ABSTRACT False PROPERTIES qpRSVPTokenRate, qpRSVPPeakRate, qpRSVPBucketSize, qpRSVPResvRate, qpRSVPResvSlack, qpRSVPSessionNum, qpMinPolicedUnit, qpMaxPktSize 8.6.1. The Property qpRSVPTokenRate NAME qpRSVPTokenRate DESCRIPTION Token Rate parameter, measured in bits/sec SYNTAX Integer 8.6.2. The Property qpRSVPPeakRate NAME qpRSVPPeakRate DESCRIPTION Peak rate parameter, measured is bits/sec SYNTAX Integer 8.6.3. The Property qpRSVPBucketSize NAME qpRSVPBucketSize DESCRIPTION Bucket Size, measured in bytes SYNTAX Integer 8.6.4. The Property qpRSVPResvRate NAME qpRSVPResvRate DESCRIPTION Defines RSVP Rate - R-Spec parameter in the RSVP Guaranteed service reservation. Measured in bits/sec. SYNTAX Integer 8.6.5. The Property qpRSVPResvSlack NAME qpRSVPResvSlack DESCRIPTION Defines RSVP Slack Term - [RSVP] Flowspec::xspec_S parameter in the RSVP Guaranteed service reservation (microseconds). SYNTAX Integer 8.6.6. The Property qpRSVPSessionNum NAME qpRSVPSessionNum DESCRIPTION The total number of allowed active RSVP sessions. SYNTAX Integer Snir, Ramberg, Strassner, Cohen expires September 2000 39 Draft-ietf-policy-qos-info-model-00.txt March 2000 8.6.7. The Property qpMinPolicedUnit NAME qpMinPolicedUnit DESCRIPTION Defines the RSVP minimum policed unit, measured in bytes. SYNTAX Integer 8.6.8. The Property qpMaxPktSize NAME qpMaxPktSize DESCRIPTION Defines RSVP maximum allowed packet size, measured in bytes. SYNTAX Integer 8.7. Class qosPolicyRSVPSignalCtrlAction This class extends the functionality of the qosPolicyRSVPAction class by adding detailed control on the signaling protocol behavior itself. The information carried in RSVP messages can be modified using this action, as well as the RSVP forwarding behavior. This class can be extended to support replacement of additional object in RSVP messages, beyond replacement of DCLASS and PREEMPTION object replacement defined below. This class SHOULD be aggregated to a qosPolicyRSVPAction object. NAME qosPolicyRSVPSignalCtrlAction DESCRIPTION Actions modifying the behavior and content of RSVP Signaling flows. DERIVED FROM policyAction ABSTRACT False PROPERTIES qpForwardingMode, qpSendError, qpReplaceDSCP,qpReplacePreemptionPriority, qpReplaceDefendingPriority 8.7.1. The Property qpForwardingMode This Property controls forwarding of RSVP messages. If the mode is set to proxy, an RSVP Path messages is not forwarded and a Resv message is returned as if the Resv was returned by the receiver. NAME qpForwardingMode DESCRIPTION Defines whether to forward or return RSVP signaling. SYNTAX Integer [ENUM] {Forward =1 , Proxy =2} Snir, Ramberg, Strassner, Cohen expires September 2000 40 Draft-ietf-policy-qos-info-model-00.txt March 2000 8.7.2. The Property qpSendError This Property controls generation of Resv-Err and Path-Err messages as defined in [COPSRSVP]. NAME qpSendError DESCRIPTION Defines whether to send RSVP error and warning message. SYNTAX Integer {No=0, Yes=1} 8.7.3. The Property qpReplaceDSCP NAME qpReplaceDSCP DESCRIPTION allows the replacement of a DCLASS object carrying DSCP value in RSVP message. SYNTAX Integer 8.7.4. The Property qpReplacePreemptionPriority This Property allows replacing or adding of preemption priority [RSVP_PREEMP] object to RSVP messages. NAME qpReplacePreemptionPriority DESCRIPTION A positive integer value specifying the preemption Priority that should be carried by RSVP messages. SYNTAX Integer 8.7.5. The Property qpReplaceDefendingPriority This Property allows replacing or adding of preemption priority [RSVP_PREEMP] object to RSVP messages. NAME qpReplaceDefendingPriority DESCRIPTION This Property allows replacing or adding of preemption priority [RSVP_PREEMP] object to RSVP messages. It specifies the defending priority within the preemption object. SYNTAX Integer 8.8. Class qosPolicyRSVPInstallAction This class extends the functionality of the qosPolicyRSVPAction class by adding detailed control on COPS Install decisions [COPS]. This action allows assigning a preemption priority with an RSVP request, to provide a device with information which RSVP requests to accept in case of admission failures. This actions specifies a DSCP value to set on the flow RSVP is requesting QoS for. This class should be extended when additional install decisions need to be controlled. Snir, Ramberg, Strassner, Cohen expires September 2000 41 Draft-ietf-policy-qos-info-model-00.txt March 2000 This class SHOULD be attached to an object together with qosPolicyRSVPAction. class definition is as follows: NAME qosPolicyRSVPInstallAction DESCRIPTION A class that defines a actions to be administrated on a the PEP. DERIVED FROM policyAction ABSTRACT False PROPERTIES qpSetDSCPValue, qpSetPreemptionPriority, qpSetDefendingPriority 8.8.1. The Property qpSetDSCPValue NAME qpSetDSCPValue DESCRIPTION Defines the value the PEP PROPERTIES use to remark the flow signaled by the RSVP requests. SYNTAX Integer 8.8.2. The Property qpSetDefendingPriority This Property allows setting the preemption priority [RSVP_PREEMP] of RSVP flows. NAME qpSetDefendingPriority DESCRIPTION This Property allows setting the preemption priority [RSVP_PREEMP] of RSVP flows. It specifies the defending priority within the preemption object. SYNTAX Integer 8.8.3. The Property qpSetPreemptionPriority This Property allows setting the preemption priority [RSVP_PREEMP] of RSVP flows. NAME qpSetPreemptionPriority DESCRIPTION This Property allows setting the preemption priority [RSVP_PREEMP] of RSVP flows. SYNTAX Integer Snir, Ramberg, Strassner, Cohen expires September 2000 42 Draft-ietf-policy-qos-info-model-00.txt March 2000 8.9. Class qosPolicySimpleCondition (Aux) A simple condition is composed of a an and triplet. The operator used in all definition in this draft is the 'match' operator. Such simple conditions are evaluated by answering the question: Does match ? The operator Property can be extended to support other relations between variable and values. Simple conditions are building blocks for more complex Boolean conditions. The qosPolicySimpleCondition is derived from the policyCondition class of the Core schema [PFSCHEMA]. Simple conditions can be kept in repositories for reuse. For a complete explanation of the use of simple conditions see the relevant section. 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) ABSTRACT False All classes derived from qosPolicyVariable and qosPolicyValue defined below can be attached as well. PROPERTIES qpOperator, qpVariableAtom, qpValueAtom 8.9.1. The Property qpOperator NAME qpOperator DESCRIPTION The relation between a variable and a value. SYNTAX String 8.9.2. The Property qpVariableAtom NAME qpVariableAtom DESCRIPTION A reference to a variable SYNTAX Reference 8.9.3. The Property qpValueAtom NAME qpValueAtom DESCRIPTION A reference to a value. SYNTAX Reference Snir, Ramberg, Strassner, Cohen expires September 2000 43 Draft-ietf-policy-qos-info-model-00.txt March 2000 8.10. Class qosPolicyVariable Variables are used for building individual conditions. The variable specifies the Property of a flow that should be matched when evaluating the condition. Not every combination of a variable and a value creates a meaningful condition. A source IP address variable can not be matched against a value that specifies a port number. A given variable selects the set of matchable value types. A variable also limits the set of values within a particular value type that can be matched against it in a condition. For example, a source- port variable limits the set of values to represent integers in the range of 0-65535. Integers outside this range can not be matched to the 16 bits port entity. The qosPolicyVariable class is an auxiliary class to allow attachment of variables to policy conditions for efficient LDAP retrieval. The class definition is as follows: NAME qosPolicyVariable DESCRIPTION A class that represents a single variable in a Boolean condition DERIVED FROM Policy (Core) ABSTRACT False PROPERTIES qpVariableName, qpValueTypes[] qpVariableDescription, qpValueConstraints[ref qosPolicyValue [0..n]] 8.10.1. The Property qpVariableName NAME qpVariableName DESCRIPTION A unique name for the variable. SYNTAX String Following is a table that defines the predefined Variable names and their logical binding. The table indicates which fields are checked in actual filters used in provisioning policies as well as in RSVP signaling messages. Snir, Ramberg, Strassner, Cohen expires September 2000 44 Draft-ietf-policy-qos-info-model-00.txt March 2000 +-----------------+---------------------------------------------------+ |Variable name | Logical binding | +-----------------+---------------------------------------------------+ | SourceIP | The source IP address of the flow. Compared to the| | | source IP header field, or the sender address in | | | the RSVP Filter spec object [RSVP]. | +-----------------+---------------------------------------------------+ | SourcePort | The source Port of a UDP/TCP flow. Compared to the| | | source port field in the TCP/UDP header, or the | | | sender port in the RSVP Filter spec object [RSVP].| +-----------------+---------------------------------------------------+ | DestinationIP | The destination IP address of the flow. Compared | | | to the destination IP header field, or the session| | | address in the RSVP SESSION object [RSVP]. | +-----------------+---------------------------------------------------+ | DestinationPort | The destination Port of a UDP/TCP flow. Compared | | | to the destination port field in the TCP/UDP | | | header, or the session port in the RSVP SESSION | | | object [RSVP]. | +-----------------+---------------------------------------------------+ | IPProtocol | The IP protocol number. Compared to the protocol | | | number in the IP header field or to the IP | | | protocol in the RSVP SESSION object [RSVP]. | +-----------------+---------------------------------------------------+ | ToS | The ToS variable is bound to the IP header ToS | | | byte. | +-----------------+---------------------------------------------------+ | DSCP | The DSCP variable is bound to the IP header DSCP | | | byte or to DCLASS RSVP object. | +-----------------+---------------------------------------------------+ | DestinationMAC | The destination MAC address variable is bound the | | | frame destination MAC address. | +-----------------+---------------------------------------------------+ | SourceMAC | The source MAC address variable is bound the frame| | | source MAC address. | +-----------------+---------------------------------------------------+ | 8021QID | The VLAN ID as represented in the 802.1Q field of | | | the header. | +-----------------+---------------------------------------------------+ |Variable name | Logical binding | +-----------------+---------------------------------------------------+ | Snap | The snap protocol variable is bound to protocol | | | type carried over SNAP encapsulation. | +-----------------+---------------------------------------------------+ | Ethertype | The ethertype variable is bound to the frame | | | header ethertype value. | +-----------------+---------------------------------------------------+ | Ssap | The source sap variable is bound the frame header | | | field containing the source SAP. | +-----------------+---------------------------------------------------+ Snir, Ramberg, Strassner, Cohen expires September 2000 45 Draft-ietf-policy-qos-info-model-00.txt March 2000 +-----------------+---------------------------------------------------+ | Dsap | The destination sap variable is bound the frame | | | header field containing the destination SAP. | +-----------------+---------------------------------------------------+ | Application | The ID of the application that generated the flow.| +-----------------+---------------------------------------------------+ | User | The ID of the user that initiated the flow, or is | | | designated as the flow owner. | +-----------------+---------------------------------------------------+ Table 2. Pre-defined Variable Names and Their Bindings 8.10.2 The Property qpValueTypes This Property specifies an unordered list of possible value types that can be used in a simple condition together with this variable. The value types are specified by their class names. The list of class names allow efficient retrieval of the possible set of relevant values from a repository. NAME qpValueTypes DESCRIPTION A list of class names of possible value types that can be associated with this variable in a condition SYNTAX String Following is a table of variable names and their default allowed class types. +-----------------+---------------------------------------------------+ |Variable name | Allowed class types | +-----------------+---------------------------------------------------+ | SourceIP | qosPolicyIPv4AddrValue, qosPolicyIPv6AddrValue | +-----------------+---------------------------------------------------+ | SourcePort | qosPolicyIntegerValue | +-----------------+---------------------------------------------------+ | DestinationIP | qosPolicyIPv4AddrValue, qosPolicyIPv6AddrValue | +-----------------+---------------------------------------------------+ | DestinationPort | qosPolicyIntegerValue | +-----------------+---------------------------------------------------+ | IPProtocol | qosPolicyIntegerValue | +-----------------+---------------------------------------------------+ | ToS | qosPolicyIntegerValue, qosPolicyBitStringValue | +-----------------+---------------------------------------------------+ | DSCP | qosPolicyIntegerValue, qosPolicyBitStringValue | +-----------------+---------------------------------------------------+ | DestinationMAC | qosPolicyMACAddrValue | +-----------------+---------------------------------------------------+ | SourceMAC | qosPolicyMACAddrValue | +-----------------+---------------------------------------------------+ Snir, Ramberg, Strassner, Cohen expires September 2000 46 Draft-ietf-policy-qos-info-model-00.txt March 2000 +-----------------+---------------------------------------------------+ | 8021QID | qosPolicyIntegerValue, qosPolicyBitStringValue | +-----------------+---------------------------------------------------+ | Snap | qosPolicyIntegerValue | +-----------------+---------------------------------------------------+ | Ethertype | qosPolicyIntegerValue | +-----------------+---------------------------------------------------+ | Ssap | qosPolicyIntegerValue | +-----------------+---------------------------------------------------+ | Dsap | qosPolicyIntegerValue | +-----------------+---------------------------------------------------+ | Application | qosPolicyDNValue, qosPolicyStringValue, | | | qosPolicyPropertyValue | +-----------------+---------------------------------------------------+ | User | qosPolicyDNValue, qosPolicyStringValue, | | | qosPolicyPropertyValue | +-----------------+---------------------------------------------------+ Table 3. Allowed Variable Names and Their Default Class Types 8.10.3. The Property qpVariableDescription NAME qpVariableDescription DESCRIPTION A textual description of the variable SYNTAX String 8.10.4. The Property qpValueConstraints NAME qpValueConstraints DESCRIPTION A list of references of the value objects serving as constraints for this variable. SYNTAX Reference 8.11. Class qosPolicyValue This abstract class used for defining values and constants used in policy conditions. The class definition is as follows: NAME qosPolicyValue DESCRIPTION This class is used as an abstract class for defining values and constants used in policy conditions DERIVED FROM Policy ABSTRACT True PROPERTIES Snir, Ramberg, Strassner, Cohen expires September 2000 47 Draft-ietf-policy-qos-info-model-00.txt March 2000 8.12. Class qosPolicyIPv4AddrValue This class is used to provide a List of Ipv4Addresses and address range values. The class definition is as follows: NAME qosPolicyIPv4AddrValue DESCRIPTION This class is used to define a list of Ipv4 addresses and address range values DERIVED FROM qosPolicyValue ABSTRACT False PROPERTIES qpIPv4AddrList[] 8.12.1. The Property qpIPv4AddrList This Property provides an unordered list of strings each specifying a single Ipv4 address or a range of Ipv4 addresses. The ABNF definition [ABNF] of Ipv4 address is: IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT Ipv4prefix = Ipv4address "/" 1*2DIGIT Ipv4range = Ipv4address".."Ipv4address Ipv4maskedaddress = Ipv4address","Ipv4address Each string entry is either: 1. A single Ipv4address in dot notation as defined above. Example: 121.1.1.2 2. A single Hostname. Hostname format PROPERTIES follow guidelines and restrictions specified in [NAMES]. Example: www.bigcompany.com 3. An Ipv4range address range defined above, specified by a start address in dot notation and an end address in dot notation, separated by "..". The range includes all addresses between the range's start and end addresses, including the start and end addresses. Example: 1.1.22.1..1.1.22.5 4. An Ipv4maskedaddress address range defined above, specified by an address and mask. The address and mask are represented in dot notation separated by a comma ",". Example: 2.3.128.0,255.255.248.0. 5. An Ipv4prefix address range defined above specified by an address and a prefix length separated by "/". Example: 2.3.128.0/15 NAME qpIPv4AddrList DESCRIPTION A list of IP addresses and IP address ranges. SYNTAX String FORMAT Ipv4address | hostname | Ipv4addressrange | Ipv4maskedaddress | Ipv4prefix Snir, Ramberg, Strassner, Cohen expires September 2000 48 Draft-ietf-policy-qos-info-model-00.txt March 2000 8.13. Class qosPolicyIPv6AddrValue This class is used to define a List of Ipv6 addresses and address range values. The class definition is as follows: NAME qosPolicyIPv6AddrValue DESCRIPTION This class is used to define a list of Ipv6 addresses and Ipv6 address range values. DERIVED FROM qosPolicyValue ABSTRACT False PROPERTIES qpIPv6AddrList[] 8.13.1. The Property qpIPv6AddrList This Property provides an unordered list of strings each specifying an Ipv6 address or a range of Ipv6 addresses. Ipv6 address format definition uses the standard address format defined in [Ipv6]. The ABNF definition [ABNF] as specified in [Ipv6] is: IPv6address = hexpart [ ":" IPv4address ] IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT IPv6prefix = hexpart "/" 1*2DIGIT hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ] hexseq = hex4 *( ":" hex4) hex4 = 1*4HEXDIG Ipv6range = Ipv6address".."Ipv6address Ipv6maskedaddress = Ipv6address","Ipv6address Each string entry is either: 1. A single Ipv6address as defined above. 2. A single Hostname. Hostname format PROPERTIES follow guidelines and restrictions specified in [NAMES]. Example: www.bigcompany.com 3. An Ipv6range address range, specified by a start address in dot notation and an end address in dot notation, separated by "..". The range includes all addresses between the range's start and end addresses, including the start and end addresses. 4. An Ipv4maskedaddress address range defined above specified by an address and mask. The address and mask are represented in dot notation separated by a comma ",". 5. A single Ipv6prefix as defined above. NAME qpIPv6AddrList DESCRIPTION A list of Ipv6 addresses and Ipv6 address ranges. SYNTAX String Snir, Ramberg, Strassner, Cohen expires September 2000 49 Draft-ietf-policy-qos-info-model-00.txt March 2000 FORMAT IPv6address | hostname | Ipv6addressrange | Ipv6maskedaddress | Ipv6prefix 8.14. Class qosPolicyMACAddrValue This class is used to define a List of MAC addresses and MAC address range values. The class definition is as follows: NAME qosPolicyMACAddrValue DESCRIPTION This class is used to define a list of MAC addresses and MAC address range values. DERIVED FROM qosPolicyValue ABSTRACT False PROPERTIES qpMACAddrList[] 8.14.1. The Property qpMACAddrList This Property provides an unordered list of strings each specifying a MAC address or a range of MAC addresses. 802 MAC address canonical format is used: The ABNF definition [ABNF] is: MACaddress = 1*4HEXDIG ":" 1*4HEXDIG ":" 1*4HEXDIG MACmaskedaddress = MACaddress","MACaddress Each string entry is either: 1. A single MAC address. Example: 0000:00A5:0000 2. A MACmaskedaddress address range defined specified by an address and mask. The mask specifies the relevant bits in the address. Example: 0000:00A5:0000, FFFF:FFFF:0000 defines a range of MAC addresses in which the first 4 8-bit bytes are equal to 0000:00A5. NAME qpIPv6AddrList DESCRIPTION A list of MAC addresses and MAC address ranges. SYNTAX String FORMAT MACaddress | MACmaskedaddress 8.15. Class qosPolicyStringValue This class is used to represent a single or set of string values. The class definition is as follows: Snir, Ramberg, Strassner, Cohen expires September 2000 50 Draft-ietf-policy-qos-info-model-00.txt March 2000 NAME qosPolicyStringValue DESCRIPTION This class is used to define a list of string values with wildcards DERIVED FROM qosPolicyValue ABSTRACT False PROPERTIES qpStringList[] 8.15.1. The Property qpStringList This Property provides an unordered list of strings each representing a single string with wildcards. The asterix character "*" is used as wildcard and represents an arbitrary sub-string replacement. For example, the value "abc*def" match "abcxyzdef", and the value "abc*def*" match "abcxxxdefyyyzzz". The syntax definition is identical to substrig assertion syntax defined in [LDAP_ATTR]. If the asterix character is required as part of the string value itself, It is quoted as described in section 4.3 of [LDAP_ATTR]. NAME qpStringList DESCRIPTION A list of string values with wildcards SYNTAX String 8.16 Class qosPolicyBitStringValue This class is used to represent a single or set of bit string values. The class definition is as follows: NAME qosPolicyBitStringValue DESCRIPTION This class is used to define a list of bit string Values. DERIVED FROM qosPolicyValue ABSTRACT False PROPERTIES qpBitStringList[] 8.16.1. The Property qpBitStringList This Property provides an unordered list of strings each representing a single bit string or a set of bit strings. The number of bits specified should equal the number of bits of the expected variable. For example, for an 8-bit byte variable, 8 bits should be specified. If the variable does not have a fixed length, the bit string should be matched against the variable most significant bit string. The formal definitions are: binary-digit = "0" / "1" bitstring = 1*binary-digit maskedBitString = bitstring","bitstring Snir, Ramberg, Strassner, Cohen expires September 2000 51 Draft-ietf-policy-qos-info-model-00.txt March 2000 Each string entry is either: 1. A single bit string. Example: 00111010 2. A range of bit strings specifies using a bit string and a bit mask. The bit string and mask PROPERTIES have the same number of bits specified. The mask bit string specifies the significant bits in the bit string value. For example, 110110, 100110 and 110111 would match the maskedBitString 100110,101110 but 100100 would not. NAME qpBitStringList DESCRIPTION A list of bit string values SYNTAX String FORMAT BitString | maskedBitString 8.17. Class qosPolicyDNValue This class is used to represent a single or set of Directory Name values including wildcards. This value can be used in comparison to reference values carried in RSVP policy objects [IDENT]. The class definition is as follows: NAME qosPolicyDNValue DESCRIPTION This class is used to define a list of reference values with wildcards. DERIVED FROM qosPolicyValue ABSTRACT False PROPERTIES qpDNList[] 8.17.1. The Property qpDNList This Property provides an unordered list of references each representing a single object referenced. An example of such reference is the directory server implementation of the information model is the Distinguished Name (DN). NAME qpDNList DESCRIPTION A list of values with wildcards. SYNTAX Reference Snir, Ramberg, Strassner, Cohen expires September 2000 52 Draft-ietf-policy-qos-info-model-00.txt March 2000 8.18. Class qosPolicyPropertyValue This class is used to represent a single or set of Property values. The match operation used is dependent on the Property name. This value can be used in conjunction with reference values carried in RSVP objects [IDENT]. The Property name is used to specify which of the Properties the pointer points to, should be compared to the list of values. For example, suppose a User class has a multi-valued Property called 'member-of' that lists the names of groups this user belongs to. Suppose this Property uses caseIgnoreMatch matching. A simple condition can be constructed to match the reference carried in RSVP Identity policy object to a qosPolicyPropertyValue with qpPropertyName="member- of" and qpPropertyList = "group-A". An Identity policy object carrying a reference "OU=Sales, CN=J. Smith, O=Widget Inc." will match this simple condition only if J. Smith belongs to group-a. The class definition is as follows: NAME qosPolicyPropertyValue DESCRIPTION This class is used to define an Property and a list of its values. DERIVED FROM qosPolicyValue ABSTRACT False PROPERTIES qpPropertyName, qpPropertyValueList[] 8.18.1. The Property qpPropertyName NAME qpPropertyName DESCRIPTION A name of a property the list of values should be compared with SYNTAX String 8.18.2. The Property qpPropertyValueList NAME qpPropertyValueList DESCRIPTION A list of property values. Each value is compared to a value of the property specified by qpPropertyName. SYNTAX String 8.19. Class qosPolicyIntegerValue This class provides a list of Integer and integer range values. Integer of arbitrary size can be represented. For a given variable, the set of Snir, Ramberg, Strassner, Cohen expires September 2000 53 Draft-ietf-policy-qos-info-model-00.txt March 2000 possible range of integer values allowed is specified via the variable's qpValueConstraints Property. The class definition is as follows: NAME qosPolicyIntegerValue DESCRIPTION This class is used to define Integer values DERIVED FROM qosPolicyValue ABSTRACT False PROPERTIES qpIntegerList[] 8.19.1. The Property qpIntegerList This Property provides an unordered list of integers and integer range values. The format of the Property can take on of the following forms: 1. An integer value. 2. A range of integers. The range is specifies by a start integer and an end integer separated by "..". The range includes all integers between start and end integers, including the start and end integers. To represent a range of integers that is not bounded, the reserved word INFINITY can be used as the end range integer. The ABNF definition [ABNF] is: integer = 1*DIGIT | "INFINITY" integerrange = integer".."integer Using ranges the operators greater-than, greater-than-or-equal-to, less-than and less-than-or-equal-to can be expressed. NAME qpIntegerList DESCRIPTION SYNTAX String FORMAT integer | integerrange 8.20. Class qosPolicyPHBSet The qosPolicyPHBSet is an class that serves as a named container for qosPolicyPHB objects. A single PHB set is associated with a QoS domain using the domain property defined in the qosPolicyDomain object. Instances of the qosNamedPolicyContainer class can override the domain's PHB set by referencing another PHB set via the qosPolicyPHBSet Property or by aggregation of a qosPolicyPHBSet object. NAME qosPolicyPHBSet DESCRIPTION This class defines a set of PHB definitions DERIVED FROM policy ABSTRACT False PROPERTIES Snir, Ramberg, Strassner, Cohen expires September 2000 54 Draft-ietf-policy-qos-info-model-00.txt March 2000 8.21. Class qosPolicyPHB The qosPolicyPHB Class is an abstract class extending the Policy class, which is intended to be extended with the information required to model a PHB service class. The PHB service class is an abstraction over device-specific parameters. NAME qosPolicyPHB DESCRIPTION This class defines a single service class in a PHB set. DERIVED FROM Policy (Core) ABSTRACT True PROPERTIES qpDSCP 8.21.1. The Property qpDSCP NAME qpDSCP DESCRIPTION An integer in the range 0..63, representing the service classes in the domain that are used for classification. SYNTAX Integer 9. 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 extending the QoS policy classes. 9.1. Extending qosPolicyValue The qosPolicyValue class and its subclasses describe the common value types used in QoS policy information model. When other specific types are required, such as a floating-point numbers, the required class should be derived from the qosPolicyValue class and properties that contain the corresponding values should be added. Notice, that in many cases using the qosPolicyPropertyValue class allows the definition of non-standard policy atoms with out extending the qosPolicyValue class. 9.2. Extending 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. Snir, Ramberg, Strassner, Cohen expires September 2000 55 Draft-ietf-policy-qos-info-model-00.txt March 2000 9.3. Extending qosPolicyAction The Qos Policy actions classes defined in the QoS Policy Schema includes Provisioning actions: * Marking * Policing, shaping and remarking according to a traffic profile. Signaling RSVP action: * RSVP policy admission * RSVP signal control extensions. * RSVP flow control extensions. Additional actions could be associated with QoS policy rules by extending the PolicyAction class with the appropriate properties. 10. Security Considerations See [PFSCHEMA]. 11. Acknowledgments 12. 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 [COPS] D. Durham, J. Boyle, R . Cohen, S. Herzog, R. Rajan, A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC2748 [COPSRSVP] S. Herzog, J. Boyle, R . Cohen, D. Durham, R. Rajan, A. Sastry, "COPS Usage for RSVP", RFC2749 [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", RFC2751 Snir, Ramberg, Strassner, Cohen expires September 2000 56 Draft-ietf-policy-qos-info-model-00.txt March 2000 [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 [DEREF] R. Moats, J. Maziarski, J. Strassner, "Extensible Match Rules to Dereference Pointer", Internet Draft [QOSCAP] J. Strassner, W. Weiss, D. Durham, A. Westerinen, Information Model for defining the QoS Capabilities of Network Devices and Services, draft-ietf-policy-qos-capabilities-schema-00.txt [NAME] P. Mockapetris, " Domain names - implementation and specification", RFC1035 [Ipv6] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", RFC2373, July 1998 [ABNF] Crocker, D., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [DNDEF] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997. [IDNET] S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, S. Herzog, "Identity Representation for RSVP", RFC 2752, January 2000 [QOSSCHEMA] Y. Snir, Y Ramberg, J. Strassner, R. Cohen QoS Policy Schema , qos-ietf-policy-info-model-00.txt [RSVP-IS] J. Wroclawski, "The Use of RSVP with IETF Integrated Services", RFC2210, September 1997 [CL] J. Wroclawski, "Specification of the Controlled-Load Network Element Service", RFC2211, September 1997 [GS] S. Shenker, C. Partridge, R. Guerin, "Specification of the Guaranteed Quality of Service", RFC2212, September 1997 Snir, Ramberg, Strassner, Cohen expires September 2000 57 Draft-ietf-policy-qos-info-model-00.txt March 2000 13. Author's Addresses Yoram Snir Cisco Systems 4 Maskit Street Herzliya Pituach, Israel 46766 Phone: +972-9-970-0085 Fax: +972-9-970-0219 E-mail: ysnir@cisco.com Yoram Ramberg Cisco Systems 4 Maskit Street Herzliya Pituach, Israel 46766 Phone: +972-9-970-0081 Fax: +972-9-970-0219 E-mail: yramberg@cisco.com John Strassner Cisco Systems Bldg 15 170 West Tasman Drive San Jose, CA 95134 Phone: +1-408-527-1069 Fax: +1-408-527-2477 E-mail: johns@cisco.com Ron Cohen Cisco Systems 4 Maskit Street Herzliya Pituach, Israel 46766 Phone: +972-9-970-0064 Fax: +972-9-970-0219 E-mail: ronc@cisco.com 14. Full Copyright Statement This document and translations of it be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process PROPERTIES be followed, or as required to translate it into languages other than English. Snir, Ramberg, Strassner, Cohen expires September 2000 58 Draft-ietf-policy-qos-info-model-00.txt March 2000 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE Snir, Ramberg, Strassner, Cohen expires September 2000 59