draft-ietf-policy-qos-info-model-00.txt   draft-ietf-policy-qos-info-model-01.txt 
Policy Framework Y. Snir Policy Framework Y. Snir
Internet Draft Y. Ramberg Internet Draft Y. Ramberg
Expires April 2000 J. Strassner Expires April 2000 J. Strassner
R. Cohen draft-ietf-policy-qos-info-model-01.txt R. Cohen
draft-ietf-policy-qos-info-model-00.txt Cisco Systems Cisco Systems
January, 2000
Policy Framework QoS Information Model Policy Framework QoS Information Model
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet Drafts.
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
skipping to change at line 38 skipping to change at line 36
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract Abstract
This document presents an object-oriented information model for This document presents an object-oriented information model for
representing network QoS policies. The QoS policy information model representing network QoS policies. This document refines the core
refines the core policy information model presented in [PFCORE]. policy information model presented in [PCIM]. Specifically, this draft
Specifically, this draft refines the concept of generic policy rules, refines the concept of generic policy rules, conditions and actions to
conditions and actions to cover extensions necessary for representing cover extensions necessary for representing QoS policies. It also
QoS policies. This information model covers Differential Service QoS provides refinement of additional concepts that are important for
enforcement, and Integrated Service QoS enforcement via policy building rule-specific as well as reusable QoS policy rules. This
control on RSVP admission. A companion document [QoSSCHEMA] defines information model covers Differentiated Services QoS enforcement, and
the mapping of these classes to a directory that uses LDAPv3 as its Integrated Service QoS enforcement via policy control on RSVP
access protocol. admission. It is important to note that this document defines an
information model, which by definition is independent of any particular
repository and access protocol. A companion document [QoSSCHEMA]
defines the mapping of these classes to a directory that uses LDAPv3 as
its access protocol. A second companion document [QOSDEV] supplies low-
level definitions of QoS mechanisms that are controlled by this
document.
Snir, Ramberg, Strassner, Cohen expires September 2000 1 Snir, Ramberg, Strassner, Cohen expires October 2000 1
Table of Contents Table of Contents
1. Introduction ...............................................5 1. Introduction 5
1.1 Goals 5
1.2 Approach and Related Documents 5
2. Information model Hierarchy ................................5 2. Information Model Hierarchy 6
2.1 Interaction Between the PCIM and This Document 7
2.1.1 Extension of Concepts in the PCIM 7
2.1.2 Addition of New Concepts Not in the PCIM 7
2.2 High-Level Class Hierarchy 8
3. Containment Hierarchy.......................................5 3. Containment Hierarchy 11
3.1. Containment Model ........................................6 3.1. Containment Model 11
3.2. QoS Domain Containment Hierarchy .........................7 3.2. QoS Domain Containment Hierarchy 12
3.2.1. Domain grouping and nesting ............................8 3.2.1. Domain Grouping and Nesting 13
3.2.2. Resource sharing .......................................9 3.2.2. Resource Sharing 15
3.2.3. Placement ..............................................9 3.2.3. Placement 15
3.2.4. Named Policy Containers ...............................10 3.2.4. Named Policy Containers 16
3.2.5. Policy rules ..........................................10 3.2.5. Policy Rules 17
3.2.6. Conditions and Actions ................................11 3.2.6. Conditions and Actions 18
3.2.7. Data tree example .....................................11 3.2.7. Data Tree Example 19
3.3. Reusable Objects Repositories ...........................12 3.3. Reusable-Object Repositories 19
3.4. Relationships between QoS Domains and repositories ......13 3.4. Relationships Between QoS Domains and Repositories 20
4. Constructing a QoS Policy Rule ............................13 4. Constructing a QoS Policy Rule 21
4.1 Policy Rule Structure ....................................14 4.1 Policy Rule Structure 21
4.2 QoS Policy Condition .....................................14 4.2 QoS Policy Conditions 22
4.2.1 Reusable vs. ad-hoc conditions .........................15 4.2.1 Reusable vs. Ad-Hoc Conditions 23
4.2.2. Using simple conditions ...............................16 4.2.2. Using Simple Conditions 24
4.2.3. Composing complex conditions ..........................16 4.2.3. Composing Complex Conditions 24
4.3 Simple Condition operator ................................17 4.3 Simple Condition Operator 25
4.4. Variable ................................................17 4.4. QoS Policy Variables 25
4.4.1 Variable Binding .......................................18 4.4.1 Variable Binding 26
4.4.2. Pre-defined Variables .................................18 4.4.2. Pre-Defined Variables 26
4.5 QoS Policy Values ........................................21 4.5 QoS Policy Values 30
4.6. PolicyTimePeriodCondition ...............................22 4.6. PolicyTimePeriodCondition 30
4.7. Actions .................................................22 4.7. Actions 30
4.7.1 Provisioning Actions ...................................22 4.7.1 Provisioning Actions 31
4.7.2 Signaling Actions ......................................24 4.7.1.1 Meters 32
4.7.1.2 Markers 32
4.7.1.3 Shapers 32
4.7.1.4 Droppers 33
4.7.1.5 Examples 33
4.7.2 Signaling Actions 34
4.8 Traffic Profiles 37
4.8.1 Provisioning Traffic Profiles 37
4.8.1 RSVP Traffic Profiles 38
5. Decision strategy .........................................28 5. Decision strategy 39
5.1. First match .............................................29 5.1. First match 39
5.2. Match All ...............................................29 5.2. Match All 39
5.3. Decision Strategy example ...............................29 Snir, Ramberg, Strassner, Cohen expires October 2000 2
6. Per Hop Behavior ..........................................30 5.3. Decision Strategy example 40
6.1. PHB .....................................................30 5.3.1 Default Operation using First Match Everywhere 40
6.2. PHB Set .................................................31 5.3.2 Operation Using Other Decision Strategies 41
7. QoS Policy Class Inheritance ..............................31 6. Per Hop Behavior 42
6.1. PHBs 42
6.2. PHB Sets 42
Snir, Ramberg, Strassner, Cohen expires September 2000 2 7. QoS Policy Class Inheritance 43
8. Class definition ..........................................33 8. Class Definitions 45
8.1. Class qosPolicyDomain ...................................33 8.1. Class qosPolicyDomain 45
8.1.1. The Property qpDomainName .............................33 8.1.1. The Property qpDomainName 45
8.1.2. The Property qpPHBSet .................................33 8.1.2. The Property qpPHBSet 45
8.1.3. The Property qpPolicyRuleMatchMethod ..................33 8.1.3. The Property qpPolicyRuleMatchMethod 45
8.2. Class qosNamedPolicyContainer ...........................33 8.2. Class qosNamedPolicyContainer 46
8.2.1. The Property qpPriority ...............................34 8.2.1. The Property qpPriority 46
8.2.2. The Property qpPolicyRuleMatchMethod ..................34 8.2.2. The Property qpNamedPolicyRuleMatchMethod 46
8.3. Class qosPolicyPRAction .................................34 8.3. Class qosPolicyPRAction 47
8.3.1. The Property qpDirection ..............................35 8.3.1. The Property qpDirection 47
8.3.2. The Property qpSetDSCPvalue ...........................35 8.3.2. The Property qpSetDSCPvalue 47
8.3.3. The Property qpMeter ..................................35 8.3.3. The Property qpMeter 47
8.3.4. The Property qpMeterScope .............................35 8.3.4. The Property qpMeterScope 48
8.3.5. The Property qpPRTrfcProf .............................35 8.3.5. The Property qpTrfcProf 48
8.3.6. The Property qpOutOfProfileAction .....................35 8.3.6. The Property qpOutOfProfileAction 48
8.3.7. The Property qpOutofProfileRemarkValue ................36 8.3.7. The Property qpOutofProfileRemarkValue 48
8.4. Class qosPolicyRSVPAction ...............................36 8.4. Class qosPolicyRSVPAction 48
8.4.1. The Property qpDirection ..............................36 8.4.1. The Property qpRSVPDirection 49
8.4.2. The Property qpRSVPMessageType ........................36 8.4.2. The Property qpRSVPMessageType 49
8.4.3. The Property qpRSVPStyle ..............................36 8.4.3. The Property qpRSVPStyle 49
8.4.4. The Property qpRSVPServiceType ........................37 8.4.4. The Property qpRSVPServiceType 49
8.4.5. The Property qpRSVPInstallAction ......................37 8.4.5. The Property qpRSVPInstallAction 50
8.4.6. The Property qpRSVPCtrlAction .........................37 8.4.6. The Property qpRSVPCtrlAction 50
8.4.7. The Property qpMeter ..................................37 8.4.7. The Property qpRSVPMeter 50
8.4.8. The Property qpMeterScope .............................37 8.4.8. The Property qpRSVPMeterScope 50
8.4.9. The Property qpRSVPTrfcProf ...........................37 8.4.9. The Property qpRSVPTrfcProf 51
8.5. Class qosPolicyPRTrfcProf ...............................38 8.5. Class qosPolicyPRTrfcProf 51
8.5.1. The Property qpPRRate .................................38 8.5.1. The Property qpPRRate 51
8.5.2. The Property qpPRNormalBurst ..........................38 8.5.2. The Property qpPRNormalBurst 51
8.5.3. The Property qpPRExcessBurst ..........................38 8.5.3. The Property qpPRExcessBurst 51
8.6. Class qosPolicyRSVPTrfcProf ............................38 8.6. Class qosPolicyRSVPTrfcProf 52
8.6.1. The Property qpRSVPTokenRate ..........................39 8.6.1. The Property qpRSVPTokenRate 52
8.6.2. The Property qpRSVPPeakRate ...........................39 8.6.2. The Property qpRSVPPeakRate 52
8.6.3. The Property qpRSVPBucketSize .........................39 8.6.3. The Property qpRSVPBucketSize 52
8.6.4. The Property qpRSVPResvRate ...........................39 8.6.4. The Property qpRSVPResvRate 53
8.6.5. The Property qpRSVPResvSlack ..........................39 8.6.5. The Property qpRSVPResvSlack 53
8.6.6. The Property qpRSVPSessionNum .........................39 8.6.6. The Property qpRSVPSessionNum 53
8.6.7. The Property qpMinPolicedUnit .........................40 8.6.7. The Property qpMinPolicedUnit 53
8.6.8. The Property qpMaxPktSize .............................40 8.6.8. The Property qpMaxPktSize 53
8.7. Class qosPolicyRSVPSignalCtrlAction .....................40 8.7. Class qosPolicyRSVPSignalCtrlAction 54
8.7.1. The Property qpForwardingMode .........................40 8.7.1. The Property qpForwardingMode 54
8.7.2. The Property qpSendError...............................41 8.7.2. The Property qpSendError 54
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 Snir, Ramberg, Strassner, Cohen expires October 2000 3
8.9. Class qosPolicySimpleCondition ..........................43 8.7.3. The Property qpReplaceDSCP 55
8.9.1. The Property qpOperator ...............................43 8.7.4. The Property qpReplacePreemptionPriority 55
8.9.2. The Property qpVariableAtom ...........................43 8.7.5. The Property qpReplaceDefendingPriority 55
8.9.3. The Property qpValueAtom ..............................43 8.8. Class qosPolicyRSVPInstallAction 55
8.10. Class qosPolicyVariable ................................44 8.8.1. The Property qpSetDSCPValue 56
8.10.1. The Property qpVariableName ..........................44 8.8.2. The Property qpSetDefendingPriority 56
8.10.2 The Property qpValueTypes ...........................46 8.8.3. The Property qpSetPreemptionPriority 56
8.10.3. The Property qpVariableDescription ..................47 8.9. Class qosPolicySimpleCondition 56
8.10.4. The Property qpValueConstraints ......................47 8.9.1. The Property qpOperator 57
8.11. Class qosPolicyValue ...................................47 8.9.2. The Property qpVariableAtom 57
8.12. Class qosPolicyIPv4AddrValue ...........................48 8.9.3. The Property qpValueAtom 57
8.12.1. The Property qpIPv4AddrList ..........................48 8.10. Class qosPolicyVariable 57
8.13. Class qosPolicyIPv6AddrValue ...........................49 8.10.1. The Property qpVariableName 58
8.13.1. The Property qpIPv6AddrList ..........................49 8.10.2 The Property qpValueTypes 58
8.14. Class qosPolicyMACAddrValue ............................50 8.10.3. The Property qpVariableDescription 58
8.14.1. The Property qpMACAddrList ...........................50 8.10.4. The Property qpValueConstraints 59
8.15. Class qosPolicyStringValue .............................50 8.11. Class qosPolicyValue 59
8.15.1. The Property qpStringList ............................51 8.12. Class qosPolicyIPv4AddrValue 59
8.16 Class qosPolicyBitStringValue ...........................51 8.12.1. The Property qpIPv4AddrList 59
8.16.1. The Property qpBitStringList .........................51 8.13. Class qosPolicyIPv6AddrValue 60
8.17. Class qosPolicyDNValue .................................52 8.13.1. The Property qpIPv6AddrList 60
8.17.1. The Property qpDNList ................................52 8.14. Class qosPolicyMACAddrValue 61
8.18. Class qosPolicyPropertyValue ...........................53 8.14.1. The Property qpMACAddrList 61
8.18.1. The Property qpPropertyName ..........................53 8.15. Class qosPolicyStringValue 62
8.18.2. The Property qpPropertyValueList .....................53 8.15.1. The Property qpStringList 62
8.19. Class qosPolicyIntegerValue ............................53 8.16 Class qosPolicyBitStringValue 62
8.19.1. The Property qpIntegerList ...........................54 8.16.1. The Property qpBitStringList 62
8.20. Class qosPolicyPHBSet ..................................54 8.17. Class qosPolicyDNValue 63
8.21. Class qosPolicyPHB .....................................55 8.17.1. The Property qpDNList 63
8.21.1. The Property qpDSCP ..................................55 8.18. Class qosPolicyAttributeValue 63
8.22. Class qosPolicyElementAuxClass .........................55 8.18.1. The Property qpAttributeName 64
8.18.2. The Property qpAttributeValueList 64
8.19. Class qosPolicyIntegerValue 64
8.19.1. The Property qpIntegerList 65
8.20. Class qosPolicyPHBSet 65
8.21. Class qosPolicyPHB 65
8.21.1. The Property qpDSCP 66
8.22. Class qosPolicyMeter 66
9. Extending the QoS Policy Schema ...........................55 9. Extending the QoS Policy Schema 67
9.1. Extending qosPolicyValue ................................55 9.1. Extending qosPolicyValue 67
9.2. Extending qosPolicySimpleCondition ......................55 9.2. Extending qosPolicySimpleCondition 67
9.3. Extending qosPolicyAction ...............................55 9.3. Extending qosPolicyAction 67
10. Security Considerations ..................................56 10. Security Considerations 68
11. Acknowledgments ..........................................56 11. Acknowledgments 68
12. References ...............................................56 12. References 68
13. Author's Addresses .......................................58 13. Author's Addresses 69
14. Full Copyright Statement .................................59 14. Full Copyright Statement 70
Snir, Ramberg, Strassner, Cohen expires September 2000 4 Snir, Ramberg, Strassner, Cohen expires October 2000 4
1. Introduction 1. Introduction
This document presents an object-oriented information model for This document presents an object-oriented information model for
representing network QoS policies. The QoS policy information model representing network QoS policies. As such, it is independent of any
refines the core policy information model presented in [PFCORE]. specific repository type and access protocol. This document refines the
Specifically, this draft refines the concept of generic policy rules, core policy information model presented in [PCIM]. Specifically, this
conditions and actions to cover extensions necessary for representing draft refines the concept of generic policy rules, conditions and
QoS policies. This information model covers Differential Service QoS actions to cover extensions necessary for representing QoS policies.
enforcement, and Integrated Service QoS enforcement via policy control This information model covers Differentiated Service QoS enforcement,
on RSVP admission. A companion document [QoSSCHEMA] defines the mapping 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 of these classes to a directory that uses LDAPv3 as its access
protocol. protocol. A second companion document [QOSDEV] supplies low-level
definitions of QoS mechanisms that are controlled by this document.
The document presents high level QoS policies that can be used to 1.1 Goals
This document presents high level QoS policies that can be used to
enforce consistent behavior across a network, regardless of the actual enforce consistent behavior across a network, regardless of the actual
vendor specific implementation details. The purpose of introducing a vendor-specific implementation details. The purpose of introducing a
standard information model and schema is to allow interoperability standard information model is to allow interoperability between Policy
between Policy Servers, Policy Management Applications, and Network Servers, Policy Management Applications, and Network devices.
devices. A standard schema allows each of these components to be built
by different vendors, yet the final outcome of the QoS policies This document solves two problems. First, different devices have
enforced on the network will be identical. different capabilities, and may respond differently to the same high-
level policy rule. This document solves this by defining a set of
common abstractions that can be used to build high-level QoS policies.
This enables different devices to use the same low-level abstractions
of mechanisms to implement QoS services, which are controlled by the
QoS policy rules defined in this document. The companion document
[QOSDEV] defines an information model for representing low-level QoS
mechanisms.
Second, different policy servers and applications may provision parts
of the network differently if no common high-level policy description
exists. This document defines a standard information model that
provides common definitions and semantics to be assigned to build,
interpret and enforce high-level policy rules.
1.2 Approach and Related Documents
The information model presented in this document contains information The information model presented in this document contains information
that can be shared by other network policy managers, e.g. Security that can be shared by other network policy managers (e.g., Security
managers, IP address managers, etc. Examples include sharing of the managers, IP address managers, and others). Examples include sharing of
same definition of well-known application port numbers, IP addresses of the same definition of well-known application port numbers, IP
servers and other network attributes. It allows checking of consistent addresses of servers and other network attributes. It allows checking
behaviors of the interaction between the different managers by of consistent behaviors of the interaction between the different
comparing for example the set of QoS and security actions enforced on managers by comparing, for example, the set of QoS and security actions
the same set of flows. 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 Snir, Ramberg, Strassner, Cohen expires October 2000 5
enforceable policies on each network device. Information model for
representation of PHBs is further elaborated in [PHBSET]. Representation of the inherent QoS mechanisms of devices is described
in a companion draft [QOSDEV]. It provides a standard information model
for representing low-level QoS mechanisms that exist in devices in a
vendor-independent way. This document, augmented with the information
provided in [QOSDEV], together provide a set of enforceable policies
that control the QoS mechanisms on network devices.
The concept of PHBs is central to Differentiated Services. An
additional information model for representation of PHBs is defined in
[PHBSET], and a corresponding LDAP representation is provided in
[PHBLDAP]. This document is also intended to work with [PHBSET].
The remainder of this document presents, describes and defines the The remainder of this document presents, describes and defines the
concepts of the QoS Policy schema, its structure and organization, its concepts of the QoS Policy Information Model (QPIM). Relationships to
relationships to the Core schema and issues related to correct usage of the Core schema and issues related to correct usage of the schema are
the schema. defined in [QOSSCHEMA].
2. Information model Hierarchy 2. Information Model Hierarchy
This section discusses the hierarchy between the Core This section discusses the relationships between the Policy Core
information model, the QoS information model and future Information Model ([PCIM]), the QoS Policy Information Model (QPIM,
extension of the QoS information model. which is this document) and future extensions of the QPIM.
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 The [PCIM] models high-level policy concepts and introduces structural
conventions and nomenclature common to all types of policies. The
fundamental purpose of the [PCIM] is to provide a generic
representation of the structure of a policy rule, along with a set of
classes and relationships that can serve as a common representation of
policy groups, rules, conditions, and actions. This enables derived
information models and schemata to all use a common set of terminology,
classes, and approaches, thus facilitating interoperability.
devices and services. The QoS information model provides The QPIM refines the concepts of the [PCIM] and introduces a framework
building blocks to control most of policy aspects, but it is of classes and relationships dedicated to model QoS Policies. This set
clear that not all knobs are provided. The core and QoS of classes and relationships can be used to configure and manage
information model are extensible. An implementation-specific devices that are IntServ- and DiffServ-compliant. The QPIM provides
schema that is derived from this schema should further building blocks to control most of the policy aspects required by
concretize the QoS concepts of the QoS Policy schema. IntServ and DiffServ, but it is clear that not all functions are
provided.
It is also clear that other information models and their derived
schemata can use some of the concepts in this document. For example,
the concept of representing IP Addresses, as well as variables and
constants, are not specific to QoS. However, this is the first
information model that is derived from the [PCIM], and it is not clear
that other working groups will be satisfied with these representations.
These concepts will be socialized to other working groups and, if they
agree with the representation in this document (or if a suitable
compromise can be developed), then these concepts will be moved into a
separate document.
Snir, Ramberg, Strassner, Cohen expires October 2000 6
The PCIM and QPIM are both inherently extensible. Furthermore, they are
designed to fit together to produce one virtual information model. As
such, both are independent of any particular repository and access
protocol. However, mappings can be defined to translate the data from
this single "virtual information model" to a form that can be
implemented in a specific type of repository that uses one or more
specific access protocols. Examples of mapping the concepts of the
[PCIM] and this document to a form that can be implemented in a
directory that uses LDAP as its access protocol are provided in
[PFSCHEMA] and [QOSSCHEMA], respectively.
This document specifies an extensible information model. While this
document defines facilities for building policy rules, conditions and
actions to build QoS policies, it is recognized that not all required
functionality can or should be defined in this document. Therefore, any
implementation-specific schema that is derived from this information
model should further concretize the QoS concepts of the QoS Policy
schema to suit its own application-specific needs.
2.1 Interaction Between the PCIM and This Document
This document both extends concepts that are part of the [PCIM] as well
as adds new functions that are not part of the [PCIM].
2.1.1 Extension of Concepts in the PCIM
The concept of a policy repository, that is embedded within another
repository that contains policy and non-policy information, was
originally defined in an earlier version of the QPIM. It has
subsequently been moved into the [PCIM], since it is a generic concept
that is not limited to QoS, and can be used by other applications. This
document defines specific refinements of the "embedded policy
repository" to accommodate the application-specific needs of QoS
provisioning.
Similarly, the concepts of reusable- objects vs. rule-specific objects
have been moved from an earlier version of this document to the [PCIM].
Equally similarly, this document defines specific extensions to
guide the implementation of reusable- vs. rule-specific QoS objects.
This document also extends the concept of a policy rule, along with
conditions and actions that are specific to QoS. It further defines
different types of actions that target DiffServ and IntServ actions.
2.1.2 Addition of New Concepts Not in the PCIM
There are several notable new concepts that are not part of the [PCIM].
These include rule nesting, rule decision strategy, pre-defined
variables and constants, and PHBs.
Snir, Ramberg, Strassner, Cohen expires October 2000 7
The [PCIM] defines the ability to group policy rules by defining the
policyGroup class. This class has the following semantics: it can
either be used to contain a set of policyRules, or a set of
policyGroups, but not both. However, this simply gathers policy rules
together in a common container. It does not nest policy rules.
This document adds the concept of nesting one or more policy rules
within a policy rule. For example, one could think of a policy rule
that controls how a user logs onto the network as consisting of the
high-level rule itself. This high-level rule could consist of a set of
lower-level rules that are invoked at various stages of processing
(e.g., how the user is authenticated, how the IP Address is assigned,
etc.).
Since there is no concept of nested rules in the [PCIM], there is no
need for a decision strategy to be used to define the order of
processing of these rules. However, such a decision strategy must be
defined in this document because it does define nested rules. This
strategy defines an ordering that can be applied to a set of policyRule
and policyGroup objects within a larger context (e.g., a policy
domain). This in turn controls the execution of different policy
actions.
This document also defines a set of variable and constant definitions
for use with QoS policies. This concept is not present in the [PCIM]
because the purpose of the [PCIM] is to provide a general structure for
representing policy rules, conditions and actions. Variable and
constant definitions represent specific concepts that have pre-defined
semantics.
Finally, this document adds a general structure for accommodating PHBs.
PHBs are a concept that is specific to DiffServ, and thus are not
defined in the [PCIM].
2.2 High-Level Class Hierarchy
The following diagram shows how the classes in this document relate to
the classes defined in the PCIM.
Snir, Ramberg, Strassner, Cohen expires October 2000 8
(continued from previous page)
[unrooted]
|
+--Policy (abstract, defined in PCIM)
| |
| +---PolicyGroup (PCIM)
| | |
| | +---qosPolicyDomain (this document)
| | |
| | +---qosNamedPolicyContainer (this document)
| |
| +---PolicyRule (PCIM)
| |
| +---PolicyCondition (PCIM)
| | |
| | +---PolicyTimePeriodCondition (PCIM)
| | |
| | +---VendorPolicyCondition (PCIM)
| | |
| | +---qosPolicySimpleCondition (this document)
| |
| +---PolicyAction (PCIM)
| | |
| | +---VendorPolicyAction (PCIM)
| | |
| | +---qosPolicyPRAction (this document)
| | |
| | +---qosPolicyRSVPAction (this document)
| | |
| | +---qosPolicyRSVPSignalCtrlAction (this document)
| | |
| | +---qosPolicyRSVPInstallAction (this document)
| | |
| +---qosPolicyPRTrfcProf (this document)
| |
| +---qosPolicyRSVPTrfcProf (this document)
| |
| +---qosPolicyVariable (this document)
| |
| +---qosPolicyValue (this document)
| | |
| | +---qosPolicyIPv4AddrValue (this document)
| | |
| | +---qosPolicyIPv6AddrValue (this document)
| | |
| | +---qosPolicyMACAddrValue (this document)
| | |
| | +---qosPolicyStringValue (this document)
| | |
(continued on next page)
Snir, Ramberg, Strassner, Cohen expires October 2000 9
(continued from previous page)
[unrooted]
|
+--Policy (abstract, defined in PCIM, repeated for convenience)
| |
| +---qosPolicyValue (this document, repeated for convenience)
| | |
| | +---qosPolicyBitStringValue (this document)
| | |
| | +---qosPolicyDNValue (this document)
| | |
| | +---qosPolicyAttributeValue (this document)
| | |
| | +---qosPolicyIntegerValue (this document)
| |
| +---qosPolicyMeter
| |
| +---qosPolicyPHBSet (this document)
| |
| +---qosPolicyPHB (this document)
| |
+--CIM_ManagedSystemElement (abstract, defined in PCIM)
|
+--CIM_LogicalElement (abstract, defined in PCIM)
|
+--CIM_System (abstract, defined in PCIM)
|
+---CIM_AdminDomain (abstract, defined in PCIM)
|
+---PolicyRepository (PCIM)
Snir, Ramberg, Strassner, Cohen expires October 2000 10
3. Containment Hierarchy 3. Containment Hierarchy
In this section we describe the organization and structure of the In this section, we describe the organization and structure of the QPIM
information model hierarchy. hierarchy.
The QoS Policy information model consists of two hierarchies: A policy The QPIM consists of two hierarchies: A policy
definition hierarchy and a reusable objects repository hierarchy. A definition hierarchy and a reusable objects repository hierarchy. A
particular data tree may contain any number of instances of each particular data tree may contain any number of instances of each
hierarchy. Section 3.1 explains the containment and reference model hierarchy. Section 3.1 explains the containment and reference model
used in the construction of QoS Policy data trees. Section 3.2 used in the construction of QoS Policy data trees. Section 3.2
describes the particular containment hierarchy of the policy definition describes the particular containment hierarchy of the policy definition
entity, which is modeled by the QoSDomain class. Section 3.3 describes entity, which is modeled by the qosPolicyDomain class. Section 3.3
the structure of the reusable objects repository. Further down (section describes the structure of the reusable objects repository. Further
3.4) we explain the relationships between those entities. down (section 3.4) we explain the relationships between those entities.
3.1. Containment model 3.1. Containment Model
The QoS Policy Information Model employs containment model of [PFCORE]. The QPIM uses and extends the containment model of [PCIM]. The
The following paragraphs are a reminder and do not replace the detailed following paragraphs summarize this containment model. For more detail,
definitions of [PFCORE]. please refer to [PCIM].
The fundamental data model of the QoS Policy definition information Conceptually, the QPIM takes the form of a tree hierarchy. To describe
model is tree hierarchy. To describe the hierarchy of data in an actual the hierarchy using actual instances of model data, we use the term
instance of model data we use the term 'data tree'. A data tree is 'data tree'. A data tree is simply an arrangement of objects in a tree
simply an arrangement of objects in a tree structure. The data tree structure. The data tree starts from a root object node. The data tree
starts from a root object node. The root node may have several branch itself consists of leaf and non-leaf (i.e., container) nodes. The root
nodes ű these are just several objects placed "right below" the root. node has one or more branch nodes that are either leaf or non-leaf
The tree construction involves placing objects as leaves of other nodes. The tree construction involves placing objects as leaves of
objects while maintaining a strict tree structure. other objects while maintaining a strict tree structure.
The basic mechanism used for expressing containment is data tree The basic mechanism used for expressing containment is placement of the
placement. To express the relationship of "container ű contained" objects in the data tree. To express the relationship of "container -
between a container object and the objects it contains, the contained contained" between a container object and the objects it contains, the
objects are placed below the container object. contained objects are placed below the container object.
Certain elements of the QoS Information Model need a mechanism for an Certain elements of the QPIM need a mechanism for an entity to
entity to reference objects not on the same hierarchy as the reference objects in a different tree in the containment hierarchy than
referencing entity. For example, QoS Policy rules (PolicyRule [PFCORE]) the tree in which the referencing entity exists. For example, the class
is a container of actions and conditions (PolicyCondition, PolicyAction policyRule (defined in [PCIM]) is a container of conditions and actions
[PFCORE]). However, the information model should allow formation of (policyCondition and policyAction classes, defined in [PCIM], or their
(complex) conditions (and actions) where some of the condition's subclasses, such as those defined in this document). However, the
components are referenced remotely (e.g., a reusable simple condition) information model should allow the formation of (complex) conditions
must be referenced because it always resides on a hierarchy different (and actions), where some of the condition's (and/or actionĂs)
from the one where the referencing rule resides). components are referenced remotely. An example of such a remote
reference is a reusable condition or a reusable action. Such reusable
objects must be referenced remotely because they always reside in a
specialized portion of the tree (in this case, in the policyRepository
container) that is different from the one where the referencing rule
resides.
Snir, Ramberg, Strassner, Cohen expires September 2000 6 Snir, Ramberg, Strassner, Cohen expires October 2000 11
To support a unified mechanism for containment of "local" and "remote" To support a unified mechanism for containment of "local" and "remote"
objects, [PFCORE] introduces the notion of association classes. An objects, [PCIM] introduces the notion of association and aggregation
association class is an intermediate placeholder for a contained object classes. These classes denote some type of dependency relationship that
that may be a direct child of its container or a referenced remote exists between the classes that they are connecting. One type of
object. The relationships between the container object and its dependency that can be represented is, of course, containment.
contained element is then:
Container [PCIM] recommends that associations and aggregations are also
| implemented as classes. With respect to containment, an association
|-- Association classes (containment by placement) class represents the act of containment itself. For example, the
| PolicyConditionInPolicyRule aggregation (defined in [PCIM]) defines
|-- local contained objects (packed inside the assoc. that zero or more policy conditions are contained in a given policy
| instances) rule.
|
|-- remote contained objects (referenced by the assoc. In general, containment may be direct or indirect. Direct containment
instances) means that when the association or aggregation is instantiated in a
repository, the child object will be directly scoped by the container
object. Indirect containment means that when the association or
aggregation is instantiated in a repository, the child object will
instead be referenced by the container object. As an example, if the
target repository is a directory, then direct containment is
implemented by instantiating the child object as a child node of a
container. Similarly, indirect containment would be implemented using
an attribute that is a DN (i.e., the DN points to another object).
The association classes can (and do) carry the added semantics needed The association classes can (and do) carry the added semantics needed
by the information model. For example, internal order of contained by the information model. For example, internal order of contained
objects is information that can be carried on the association objects objects is information that can be carried on the association objects
themselves, making the containment model more flexible (same object may themselves. This makes the containment model more flexible, since the
be used by two containers but in a different position). same object may be used by two containers in different parts of the
Refer to [PFCORE] for details of the association class mechanism. containment tree.
Containment is implemented differently in different data stores.
Therefore, the containment tree that is being described is not
expressed directly in the information model. Rather, the information
model specifies classes and relationships that are used to model
entities and relationships between entities that are represented in the
containment data model. A mapping of the data specified in an
information model to a form that is repository-dependent must also be
specified. This is what [PFSCHEMA] and [QOSSCHEMA] do for the [PCIM]
and this document, respectively. Please refer to [PCIM] for more
information on the details of the association and aggregation class
mechanisms.
3.2. QoS Domain Containment Hierarchy 3.2. QoS Domain Containment Hierarchy
The entity that represents a single policy hierarchy is called QOS The entity that represents a single policy hierarchy is called QOS
Domain and is modeled by the qosDomain class, which is a derivative of Domain and is modeled by the qosDomain class, which is a derivative of
the PolicyGroup class in [PFCORE]. the PolicyGroup class in [PCIM].
Figure 1 shows a summary view of the QoS Domain containment hierarchy. Snir, Ramberg, Strassner, Cohen expires October 2000 12
Figure 1 shows a summary view of the QoS domain containment hierarchy.
The text in parenthesis denotes object containment style: either The text in parenthesis denotes object containment style: either
through data tree placement or through association classes. through placement in the data tree (i.e., using a class to form a
container in a specific place in the data tree) or indirectly through
association or aggregation classes.
+---------------+ +---------------+
|qosPolicyDomain| (root) |qosPolicyDomain| (root)
+-|-------------+ +---------------+
|
| +-----------------------+ | +-----------------------+
-->|qosNamedPolicyContainer| (placement) -->|qosNamedPolicyContainer| (placement)
+-|---------------------+ +-----------------------+
| +-------------+ |
-->|policyRule| | (placement) | +----------+
+-|-----------+ -->|policyRule| (placement)
+----------+
| |
| +------------------------+ | +------------------------+
|-->|qosPolicySimpleCondition| (via association) |-->|qosPolicySimpleCondition| (via association)
| +------------------------+ | +------------------------+
| |
| +---------------+ | +---------------+
|-->|qosPolicyAction| (via association) -->|qosPolicyAction| (via association)
+---------------+ +---------------+
Figure 1: Qos Domain containment hierarchy Figure 1: Qos Domain containment hierarchy
Snir, Ramberg, Strassner, Cohen expires September 2000 7 3.2.1. Domain Grouping and Nesting
3.2.1. Domain grouping and nesting QoS policy domains may be grouped together to model multi-domain
systems. Here, a domain is a contiguous set of nodes that operate under
a common system of administration and provide a common set of services.
Grouping may be desired to enhance various administrative tasks, or it
may be required by a particular policy application. The grouping
strategy (as well as all location-oriented strategies) is left for
users/vendors to model based on their unique situations and
requirements. This document presents guidelines and recommendations for
grouping QoS domains, but specific implementations may use other
techniques without violating the integrity and consistency of the QPIM.
QOS Domains may be grouped together to model multi-domain systems. One way to group QoS policy domains is by creating a common root for
Grouping may be desired to enhance various administrative tasks and may several QoS policy domain data tree instances. This can be done by
be required by a particular policy application. The grouping strategy using the PolicyGroup (defined in [PCIM]) class as a root for the
(as well as all location-oriented strategies) is left for users/vendors multi-domain tree. In this case, all that is needed is to place the
to model based on their unique situation and requirement. This document appropriate number of qosPolicyDomain (defined in this document)
presents guidelines and recommendations for grouping QoS Domains but instances under the appropriate policyGroup instance.
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 Snir, Ramberg, Strassner, Cohen expires October 2000 13
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 Figure 2 is an example that depicts the ability to provide different
classes of service to different organizations within a single classes of service to different organizations within a single
enterprise. The different organizations are each represented by a enterprise. In this example, the enterprise is represented by an
separate QoS policy domain (which is an instance of the qosPolicyDomain instance of the policyGroup class. The different organizations are each
class). Each qosPolicyDomain class is used as a container to hold all represented by a separate QoS policy domain (which is an instance of
of the policies of a given portion of the organization. In Figure 2 the qosPolicyDomain class). Each qosPolicyDomain class is used as a
this level is represented by the nesting of qosPolicyDomain classes. container to hold all of the policies for a given portion of the
organization. In Figure 2, this level is represented by the nesting of
qosPolicyDomain classes.
Each qosPolicyDomain instance serves as a container that contains an Each qosPolicyDomain instance serves as a container that contains an
ordered list of related QoS policy rule groups that apply to a ordered list of related QoS policy rules that apply to a different part
different parts or functions of the domain (e.g., Eastern Sales vs. or function of the domain (e.g., Eastern Sales vs. Western Sales). This
Western Sales). Each qosPolicyDomain contains a set of containers grouping is done using instances of the qosNamedPolicyContainer clas.
(implemented as instances of the qosNamedPolicyContainer class) that The qosNamedPolicyContainer class would in turn contain either a set of
groups together QoS rules. policyRule instances, a set of policyGroup instances (to provide
further grouping of policy rules that are scoped by a given
qosNamedPolicyContainer), or both.
+----------------+ +-------------+
|qosPolicyGroup | <-------------------QoS policies for an enterprise |policyGroup | <------------------- QoS policies for an enterprise
+--|-------------+ +-------------+
|
| +---------------+ | +---------------+
-->|qosPolicyDomain| <--------------QoS policies for sales -->|qosPolicyDomain| <----------- QoS policies for the Sales group
+-|-------------+ +---------------+
|
| +---------------+ | +---------------+
|-->|qosPolicyDomain| <--------QoS policies for Western Sales |-->|qosPolicyDomain| <--------QoS policies for Western Sales
| +-|-------------+ | +---------------+
| |
| | +-----------------------+ | | +-----------------------+
| |-->|qosNamedPolicyContainer| <--Qos Policies for group | |-->|qosNamedPolicyContainer| <--Qos Policies for group
| | +-----------------------+ A within Western Region | | +-----------------------+ A within Western Region
| |
| | +-----------------------+ | | +-----------------------+
| -->|qosNamedPolicyContainer| <--Qos Policies for group | -->|qosNamedPolicyContainer| <--Qos Policies for group
| +-----------------------+ B within Western Region | +-----------------------+ B within Western Region
| |
| +---------------+ | +---------------+
-->|qosPolicyDomain| <--------QoS policies for Eastern Sales -->|qosPolicyDomain| <--------QoS policies for Eastern Sales
+-|-------------+ +---------------+
|
(Figure continued in next page)
Snir, Ramberg, Strassner, Cohen expires September 2000 8
(Figure continued from previous page)
| +-----------------------+ | +-----------------------+
|-->|qosNamedPolicyContainer| <--Qos Policies for group |-->|qosNamedPolicyContainer| <--Qos Policies for group
| +-----------------------+ C within Eastern Region | +-----------------------+ C within Eastern Region
|
| +-----------------------+ | +-----------------------+
-->|qosNamedPolicyContainer| <--Qos Policies for group -->|qosNamedPolicyContainer| <--Qos Policies for group
+-----------------------+ d within Eastern Region +-----------------------+ D within Eastern Region
Figure 2: Top-level policy data tree example Figure 2: Top-level policy data tree example
Snir, Ramberg, Strassner, Cohen expires October 2000 14
The modeling approach used in the previous example is but one possible The modeling approach used in the previous example is but one possible
strategy among many. The information model allows for arbitrary nesting strategy among many. The information model allows for arbitrary nesting
of groups, thus providing the means for modeling both wide and deep of groups, thus providing the means for modeling both wide and deep
hierarchies. hierarchies.
3.2.2. Resource sharing 3.2.2. Resource Sharing
While different hierarchy instances are indifferent to each other (no Object instances residing in different parts of the containment tree
cross-referencing among QoS Domains), multiple QoS Domains may still are independent to each other. That is, there is no cross-referencing
share data by means of references to reusable objects (residing in a among objects located in different QoS policy domains. However,
reusable objects repositories). The sharing of global or common multiple QoS policy domains may still share data by means of
definition enhances the interoperability of various policy agents thus referencing reusable objects. These are objects that are placed in a
serving the primary goal of this information model. Such commonly used special portion of the repository dedicated to this purpose. In fact,
building blocks as important conditions (PolicyCondition) and actions there may be multiple such repositories, each used for collecting a set
(PolicyAction) can be placed in the repository and used by policy of related reusable objects. In this document, we will call such
rules. The information model does not restrict the number of repositories reusable-objects repositories.
repositories that can be referenced from a single QoS Domain. Even a
single instance of a policy rule (PolicyRule) may contain references to The sharing of global or common objects enhances the interoperability
objects residing in more than one repository. The information model of various policy agents, thus serving the primary goal of this
does not dictate a QoS Domain wide scope for reusable objects (there's information model. Such commonly used building blocks as important
a many-to-many relationship between QoS Domains and reusable objects conditions (policyCondition and its subclasses ) and actions
repositories). (policyAction and its subclasses) can be placed in the reusable-object
repository and used by multiple policy rules from multiple domains.
Both the [PCIM] and the QPIM do not restrict the number of reusable-
object repositories that can be referenced from a single domain. Even a
single instance of a policy rule may contain references to objects
residing in more than one repository. It is important to note that the
QPIM does not dictate a QoS domain-wide scope for reusable objects, so
as to keep this concept as general as possible.
3.2.3. Placement 3.2.3. Placement
Intending to allow a flexible structure that does not pre-impose harsh The purpose of the QPIM is to define a flexible structure of
restriction on data tree constructors, the information model must not information that does not pre-impose harsh restrictions on building the
contain a hidden assumption about placement of particular QoS Domains data tree. Therefore, the QPIM must not contain any hidden assumptions
hierarchies (including, for that matter, placement of repositories as about the placement of particular QoS policy domain hierarchies
explained in section 3.3). Consequently, the information model does not (including, for that matter, placement of reusable-object repositories
require a certain pre-defined location for the portion of the data tree as explained in section 3.3 below). Consequently, the QPIM does not
dedicated to policy. An instance of the global data tree (a corporate require any pre-defined locations for the portion of the data tree that
directory, for example) may contain several QoS Domains hooked to the is dedicated to policy. An instance of the global data tree (a
tree in various places. Zero or more reusable objects repository may corporate directory, for example) may in fact contain several QoS
also be present in the global data tree. The information model does not policy domains that exist within the global date tree in various
dictate any standard organization of objects to be controlled via places. Zero or more reusable object-repositories may also be present
policy. The only location/organizational rule that must be followed is: in the global data tree.
Snir, Ramberg, Strassner, Cohen expires September 2000 9 In addition, the QPIM does not dictate any standard organization of
objects to be controlled via policy, either for QoS policy classes and
relationships or for reusable-object repositories that are used by QoS
applications.
"Each QoS Domain must contain complete policy information either by Snir, Ramberg, Strassner, Cohen expires October 2000 15
containment of objects or by containment of association objects. In
other words: Simple tree navigation and occasional reference chasing, The only location/organizational rule that must be followed is:
starting at the tree root (QoS Domain) must lead to all policy
definition objects needed to enforce the domain's policy." Each QoS policy domain must contain complete policy information,
either by containment of objects or by containment of association
and/or aggregation objects, that is necessary to describe that
policy domain. Reusable objects SHOULD be placed in one or more
reusable-object repositories and referenced by one or more objects
that exist in the QoS policy domain, as appropriate.
3.2.4. Named Policy Containers 3.2.4. Named Policy Containers
A QoS Domain is a container of (named) QoS Policy Containers, as A QoS policy domain is a container of (named) QoS Policy Containers, as
explained above. The information model class representing policy explained above. The information model class representing named QoS
containers is QoSNamedPolicyContainer, which extends the PolicyGroup policy containers is the qosNamedPolicyContainer class. This class
class of [PFCORE]. A (non-empty) policy container is an ordered list of extends the policyGroup class, which is defined in [PCIM].
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 A (non-empty) qosNamedPolicyContainer holds an unordered list of
be assigned a name that must be unique within its QoS Domain. A given policyRules. There are two levels of priority that the QPIM specifies
policy container must belong to (i.e.: contained in) a single QoS that can be used to determine the order of execution of QoS policy
Domain. Sharing of policy containers among QoS Domains is not rules. At the highest level, we can define an unordered set of policy
recommended because of the dependency of the decision strategy on the containers, each of which has a priority attribute (called qpPriority).
relative priority within each domain. This property is used to order the top level of the containment
hierarchy. Within a given containment level, we can then use the
Priority attribute of the policyRule class to establish an order of
which policy rule in a given container executes next. Figure 3 shows a
simple example of the ordering process. Section 4 describes policy
rules in more detail.
The purpose of "dividing" a QoS Domain's policy rules among the +---------------+
domains' policy containers provides a flexible framework for fine grain |qosPolicyDomain|
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 |-->|policyRule A |
in place for the Western region. Another policy system may take a | | Priority=19 |
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. |-->|qosNamedPolicyContainer|--->|policyRule C |
| | qpPriority=5 | | | Priority=7 |
| +-----------------------+ | +-------------+
| |
| +-------------+ | +-------------+
-->|policyRule B | ->|policyRule D |
| Priority=3 | | Priority=2 |
+-------------+ +-------------+
Each policy container is assigned a "match strategy", which is a name Figure 3. Example Ordering for a QoS Policy Decision
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 Here, the ordering is A, then C, then D, then B. This is because the
"matched" according to ascending order of their Priority attribute. qpPriority of the qosNamedPolicyContainer is higher than B, so each of
Decision strategy is explained in section 5. its contained rules are executed (in order) before B.
Snir, Ramberg, Strassner, Cohen expires October 2000 16
As implied by the class name, each instance of the
qosPolicyNamedContainer class MUST be assigned a name that is unique
within its given QoS policy domain. A given policy container must
belong to (i.e.: contained in) a single QoS policy domain. Sharing of
policy containers among QoS policy domains is not possible because of
the dependency of the decision strategy on the relative priority within
each QoS policy domain.
The ability to "divide" a given QoS policy domain's policy rules among
a set of policy containers provides a flexible framework to realize a
fine-grained administrative (or functional) structure. As the example
in figure 2 illustrates, it makes sense to divide policies for the
sales organization into two regional containers: Western and Eastern.
This enables a change in policies for one region to not affect the
policies currently in place for the other region.
While this strategy should meet most needs, taking a slightly different
approach can provide additional flexibility. This approach is
illustrated by looking at how PHBs are modeled (see section 6). In this
approach, a different set of PHBs can be assigned to different policy
containers. This has the effect of modifying the interpretation of the
same PHBs by each policy container.
Each policy container is assigned a "match strategy". This is defined
in the qpNamedPolicyRuleMatchMethod attribute of the
qosPolicyNamedContainer class. This attribute defines how to interpret
the order of the QoS policy rules that it contains. For example, a
FirstMatch strategy means that the rules will be "matched" according to
ascending order of their Priority attribute. Decision strategies are
explained in section 5.
Policy container can be nested. A policy container may contain policy Policy container can be nested. A policy container may contain policy
rules (PolicyRule [PFCORE]) or named policy containers. A particular rules (PolicyRule [PCIM]) or named policy containers. A particular
data tree, then, can be constructed as a deep hierarchy, if the data tree, then, can be constructed as a deep hierarchy, if the
designers of the policy system deem it desirable. designers of the policy system deem it desirable.
3.2.5. Policy rules 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 Each qosNamedPolicyContainer holds a set of policy rules (or possibly
additional policy containers, which could be policyGroups or
qosNamedPolicyContainers, that contain policy rules). QoS policy rules
are modeled by the [PCIM] class policyRule.
The semantics of a policy rule is, in essence, a conditional imperative The semantics of a policy rule is, in essence, a conditional imperative
statement in the form 'if <condition> then <action>'. Applying a rule statement in the form 'if <condition> then <action>'. Applying a rule
means to evaluate its condition and, depending on the truth value of means evaluating its condition and, depending on the truth value of
the condition, wither execute the action or move along (do nothing). the condition, to execute the action or do nothing. Evaluating a
Evaluating a condition is known as 'matching the rule', an expression condition is known as 'matching the rule', an expression we'll be using
we'll be using further down. in later sections of this document.
A given policy rule must belong to one (and only one) named Snir, Ramberg, Strassner, Cohen expires October 2000 17
container.
This model is chosen because the units of reusability are the policy A given policy rule MUST belong to one (and only one)
condition and action terms that comprise a policy rule, as opposed to qosNamedPolicyContainer. This restriction is necessary because the
the policy rule itself. A policy rule is a composite object, made up units of reusability are, in reality, the policy condition and action
from several objects (some reusable) and is viewed as a coherent terms that comprise a policy rule (as opposed to the policy rule
statement. It is believed that allowing a policy rule to belong to more itself). This is because a policy rule is a composite object, made up
than one policy container would decrease its coherence. For example, of several objects, but SHOULD be viewed as a coherent statement. It is
believed that allowing a policy rule to belong to more than one policy
container would decrease or even destroy its coherence. For example,
the rule itself is "aware" of its position inside its policy container, 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 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 remove this knowledge from the rule. The notion of ordering of rules is
essential to the concept of policy that removing it from the rule also so essential to the concept of policy that removing it from the rule
renders the rule less expressive, making policy modeling a more also renders the rule less expressive, making policy modeling a more
difficult job. Furthermore, there are other important attributes that difficult job. Furthermore, there are other important attributes that
are unique to the rule's specific placement inside the policy group are unique to the rule's specific placement inside a policy group
and/or the policy domain. For example, the DSCP values (section 6.) and/or a policy domain. For example, the DSCP values (section 6) that
that define how a flow is colored (which in turn define the set of QoS 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 policy actions that should be invoked by the rule) may be interpreted
differently in different QoS domains (or policy containers). These differently in different QoS policy domains (or policy containers).
examples show that the modeling of shared rules is inappropriate for These examples show that the modeling of shared rules is inappropriate
the QoS Policy information model. for the QPIM.
The order of the rules inside a group is based on the value of the rule The order of the policy rules inside a container is based on the
priority attribute [PFCORE]. The enforcement of policy rules also relative values of the Priority attribute of each of the policyRules
depends on particular settings belonging to the group. The match (please see [PCIM] for more information). The enforcement of policy
strategy to be applied to the rules contained in this container is rules also depends on particular settings belonging to the group. The
defined in the policyRuleMatchMethod attribute of the match strategy to be applied to the policy rules contained in a given
qosNamedPolicyContainer object. container is defined in the policyRuleMatchMethod attribute of the
qosNamedPolicyContainer object. Note that actions taken on packets may
use a different mechanism. For example, a DSCP value can be set
directly using the qpSetDSCPValue attribute of the qosPolicyPRAction
class. However, this class could also define a set of token bucket
parameters using the qpTrfcProf attribute. This references a traffic
profile (represented by the qosPolicyPRTrfcProf class) that carries the
policer or shaper rate values to be enforced on a flow or a set of
flows.
3.2.6. Conditions and Actions 3.2.6. Conditions and Actions
A policy rule is a composite object, as mentioned above. The most A policy rule is a composite object, as mentioned above. The most
important components of a rule are the conditions and actions it important components of a rule are the conditions and actions it
contains. A condition is a Boolean expression that is evaluated to see 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 if the rule should be applied. An action is a specification of one or
device configuration instruction that must be done if the rule is to be more QoS operations enforced on the designated set of flows that MUST
applied. be done if the given policy rule is to be applied. Actions are applied
if the condition is TRUE (see [PCIM] for more details).
Conditions and actions are discussed in detail [PFIM]. Snir, Ramberg, Strassner, Cohen expires October 2000 18
3.2.7. Data tree example 3.2.7. Data Tree Example
The following example illustrates the hierarchical nature of the QoS The following example illustrates the hierarchical nature of the QoS
Policy data tree. Each organizational entity is related to a specific Policy data tree. Each organizational entity is related to a specific
type of class, which is shown in parentheses. type of class, which is shown in parentheses.
Snir, Ramberg, Strassner, Cohen expires September 2000 11 There are two QoS policy domains in this example, grouped together
under the same root (domain grouping). The QoS policy domains are:
There are two domains in this example, grouped together under the same
root (domain grouping). The QoS Domains are:
1. EastCoast (qosPolicyDomain) 1. EastCoast (qosPolicyDomain)
2. WestCost (qosPolicyDomain) 2. WestCost (qosPolicyDomain)
Each of these two QoS policy domains has its PHB set. The EastCoast Each of these two QoS policy domains has its own PHB set. The EastCoast
domain has 2 named policy containers. The first deals only with ERP domain has 2 named policy containers. The first deals only with ERP
traffic and the second handles all other traffic: traffic and the second handles all other traffic:
1. EastCoast (qosPolicyDomain) 1. EastCoast (qosPolicyDomain)
1.1. ERP (qosNamedPolicyContainer) 1.1. ERP (qosNamedPolicyContainer)
1.2. General (qosNamedPolicyContainer). 1.2. General (qosNamedPolicyContainer)
The WestCoast domain has 3 policy rule groups. The first deals only with The WestCoast domain has 3 named policy container. The first deals only
ERP flows, the second deals with VOIP, and the third with all other With ERP flows, the second deals with VoIP, and the third with all
traffic: other traffic:
2. WestCoast 2. WestCoast
2.1. ERP (qosNamedPolicyContainer) 2.1. ERP (qosNamedPolicyContainer)
2.2. VOIP (qosNamedPolicyContainer) 2.2. VoIP (qosNamedPolicyContainer)
2.3. General (qosNamedPolicyContainer). 2.3. General (qosNamedPolicyContainer).
Each one of the qosNamedPolicyContainer entries can contain a Each one of the qosNamedPolicyContainer entries can contain a
prioritized rule set. For example, the WestCoast ERP group contains the prioritized rule set. For example, the WestCoast ERP group contains the
rules relevant to ERP applications administrated by the west coast rules relevant to ERP applications administrated by the west coast
domain administrator. domain administrator.
We see from the above structure that this structure provides the We see from the above structure that this structure provides the
administrator with a great deal of flexibility. For example, similarly administrator with a great deal of flexibility. For example, similarly
named containers, represented by the ERP and General named containers, represented by the ERP and General
qosNamedPolicyContainers, can reuse common policy conditions and qosNamedPolicyContainers, can reuse common policy conditions and
actions. However, they are implemented as physically different actions. However, they are implemented as physically different
containers to enable the administrator to administrate them containers to enable the administrator to administrate them
according to their own domain-specific needs. according to their own domain-specific needs.
3.3. Reusable Objects Repositories 3.3. Reusable-Object 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 Reusable objects are objects that can be referred by (hence "used by")
purpose of allowing data tree constructors to share data among many other objects. For example, the reference could be accomplished by
users as explained in section 1.2.1.2. allocating an attribute on the referencing object that contains the
location of the referenced object.
The following sections are merely a reminder of the mechanism for Snir, Ramberg, Strassner, Cohen expires October 2000 19
modeling reusable objects repositories introduced in [PFCORE].
Snir, Ramberg, Strassner, Cohen expires September 2000 12 The concept of reusable-object repositories is introduced by [PCIM] for
the purpose of allowing data tree constructors to share data among many
users. This document enhances this concept to model the needs of QoS
policy rules.
A reusable objects repository hierarchy is rooted in an instance of the A reusable-object repository hierarchy is rooted in an instance of the
PolicyRepository class [PFCORE]. Individual repositories are named policyRepository class (defined in [PCIM]). Individual reusable-object
containers for reusable objects. Note that [PFCORE] allows arbitrary repositories are named containers for reusable objects. Note that
nesting of repositories, thus a repository of repositories is a natural [PCIM] allows arbitrary nesting of reusable-object repositories. This
modeling technique. can be conceptually thought of as a repository of repositories.
Each named repository is a container of "reusable objects". A reusable Each named reusable-object repository is a container of "reusable
object must have a unique name within the repository that container. objects" that can be used for a common purpose, and/or are administered
in a common way. A reusable object MUST have a unique name within the
the container that it resides in.
The complete containment model for the reusable objects repositories, as The complete containment model for the reusable-object repositories,
well as detailed description of the various mechanisms for constructing as well as detailed description of the various mechanisms for
and maintaining such repositories are described in great detail in constructing and maintaining such repositories, is described in detail
[PFCORE]. in [PCIM].
Anywhere in the QoS Policy information model, where a reference to an Anywhere in the QoS Policy information model, where a reference to an
object can be made (a 'reference' type attribute), this reference may object can be made (a 'reference' type attribute), this reference
point to a reusable object in a reusable objects repository. SHOULD point to a reusable object in a reusable-object repository.
Common candidates for reusability are named instances of these classes: Common candidates for reusability are named instances of these classes
QoSPolicyVariable, QoSPolicyValue and its derivatives, and their derivatives:
QoSPolicySimpleCondition, PolicyAction and its derivatives,
QoSPolicyPRTrfcProf, QoSPolicyRSVPTrfcProf and QoSPolicyPHBSet.
Throughout this document we point out the possible use of repository and - qosPolicyVariable
repository objects, wherever this is appropriate. - qosPolicyValue
- qosPolicySimpleCondition
- policyAction
- qosPolicyMeter, QoSPolicyPRTrfcProf and QoSPolicyRSVPTrfcProf
- QoSPolicyPHBSet
3.4. Relationships between QoS Domains and repositories Throughout this document, we point out the possible use of repository
and repository objects, wherever this is appropriate.
As explained above, a QoS Domain contains within it groups of policy 3.4. Relationships Between QoS Domains and Repositories
rules. A policy rule can contain ordered lists of conditions and
As explained above, a QoS policy domain contains within it groups of
policy rules. A policy rule can contain ordered lists of conditions and
actions. The conditions and actions may be reusable object that reside actions. The conditions and actions may be reusable object that reside
in reusable objects repositories. in reusable objects repositories.
Many references to reusable objects may be made from the rules of a 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 given QoS policy domain. Those references need not be all pointing to
repository; even e single rule may contain references to reusable the same reusable-object repository; even e single rule may contain
objects that reside in different repositories. references to reusable objects that reside in different repositories.
Snir, Ramberg, Strassner, Cohen expires October 2000 20
The maintenance of the policy system is made somewhat more complicated The maintenance of the policy system is made somewhat more complicated
due to the flexibility of the reference model. It is more difficult to due to the flexibility of the reference model. For example, it is more
prevent "dangling" references to repositories that are no longer difficult to prevent "dangling" references to repositories that are no
present, for instance. Schema designers are encouraged to pay extra longer present. Schema designers are encouraged to pay extra attention
attention to this problem and exercise any technique available from to this problem and exercise any technique available from their
their implementation platform to maintain integrity of their data trees. implementation platform to maintain integrity of their data trees.
[PFCORE] discusses this issue as well. [PCIM] discusses this issue as well.
4. Constructing a QoS Policy Rule 4. Constructing a QoS Policy Rule
A policy rule modeled in [PFCORE] represents the "If Condition then A policy rule modeled in [PCIM] represents the "If Condition then
Action" semantics associated with a policy. The policyRule class uses Action" semantics associated with a policy. The QPIM extends these
the rule container class PolicyRuleInPolicyGroup to establish semantics by refining the type of policy conditions and actions that
can be represented, extending the use of containers, and providing
Snir, Ramberg, Strassner, Cohen expires September 2000 13 additional features (nesting of rules, defining extensible rule
decision strategies, linking to PHBs, and providing pre-defined
variables and constants that can be used to express the required
semantics of QoS policy rules in more detail.
containment relationships between a policy rule and possible sub-rules, The following sections describe these characteristics in more detail.
modeled by the same PolicyRule class.
4.1 Policy Rule Structure 4.1 Policy Rule Structure
A policy rule has the following attributes [PFCORE]: A policy rule has the following attributes (defined in [PCIM]) that can
be used to provide important semantics for QoS policy applications;
these are in addition to the attributes which serve as a key and
provide its name:
1. Enable flag. 1. An Enable flag that indicates whether a policy rule is
2. A Boolean condition. administratively enabled, administratively disabled, or enabled
3. Ordered list of Actions. for debug mode.
4. Informational attributes. 2. A set of conditions (defined in either the
PolicyConditionInPolicyRule or PolicyConditionInPolicyRepository
aggregation)
3. A flag indicating whether this condition is in disjunctive or
conjunctive normal form
4. An (optionally ordered) list of actions (defined in either the
PolicyActionInPolicyRule or PolicyActionInPolicyRepository
Aggregation)
5. A priority value, defining the priority of this rule relative to
other rules in the same container
6. The attribute named ˘mandatory÷, which is used to define whether
the evaluation of conditions (and the subsequent execution of
actions if the conditions evaluate to TRUE) is mandatory or not
7. A SequencedActions attribute that defines how to execute the
actions if the condition is TRUE
8. An array of PolicyRoles attributes, that define the roles or
role-combinations that are used in this rule
9. A RuleUsage attribute, that contains a description of how this
rule should be used
The enable flag indicates whether a policy rule is administratively Snir, Ramberg, Strassner, Cohen expires October 2000 21
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 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 be performed on a network flow by matching the network flow attributes
against the condition. A condition is composed from against the condition. QoS-specific conditions SHOULD be formed from
qosPolicySimpleCondition conditions defined in this document and using either the qosPolicySimpleCondition class defined in this
PolicyTimePeriodCondition conditions [PFCORE]. The combination of document and/or the policyTimePeriodCondition class defined in [PCIM]
individual conditions in a policy rule is defined in [PFCORE] using (or their subclasses, of course). Note that QoS-specific conditions MAY
ConditionInPolicyRule class. be mixed with more generic conditions that are not derived from either
of these classes. However, these non-QoS-specific conditions SHOULD be
Each action in the list is modeled by an action derived from derived from the policyCondition class (defined in [PCIM]). The
PolicyAction. The ActionInPolicyRule class defines the order of which combination of individual conditions in a policy rule is defined in
policy actions are performed. [PCIM] using the ConditionInPolicyRule class.
Informational attributes correspond to various meta-data used for Each action in the list is modeled by an action derived from the
managing policy rules. PolicyAction class. The ActionInPolicyRule class defines the order in
which policy actions are performed.
The interpretation of a policy rule in regard to a given network flow The interpretation of a policy rule in regard to a given network flow
may be expressed as follows: 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 If the rule is enabled and the Boolean expression is evaluated to
this flow." 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 The rest of this section describes the components of the policyRule
class and their relationships to the other classes defined in this class and their relationships to the other classes defined in this
schema. schema.
4.2 QoS Policy Conditions 4.2 QoS Policy Conditions
A policy rule modeled in [PFCORE] represents the "If Condition then A policy rule modeled in [PCIM] represents the "If Condition then
Action" semantics associated with a policy. A condition is represented Action" semantics associated with a policy. A condition is represented
as either an ORed set of ANDed conditions or an ANDed set of ORed as either an ORed set of ANDed conditions or an ANDed set of ORed
conditions. Individual conditions may either be negated (NOT C) or conditions. Individual conditions may either be negated (NOT C) or
unnegated (C). The actions specified by a policy rule are to be not negated (C). The actions specified by a policy rule are to be
performed if and only if the policy rule condition evaluates to TRUE. 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 Many conditions in policy rules, from a networking perspective, can be
modeled as Filters. Filters are not modeled directly in either the QPIM
or the PCIM (i.e., no Filter class is defined). However, the filter
concept is central in the QoS Policy data model, and is modeled in the
Network Model of DEN and used in the companion QoS Device information
model draft [QOSDEV].
not modeled directly in either the QoS Policy schema or the core schema The semantics of an individual condition is not specified in [PCIM].
(i.e., no Filter class is defined). However, the filter concept is This document provides semantics for common QoS policy conditions. For
central in the QoS Policy data model, and is modeled in the Network example, conditions such as: "If the source IP address of the flow
Model of DEN and used in the companion QoS capabilities draft [QoSCap]. belongs to 10.1.x.x subnet" as well as "If the IP protocol number of
the flow equals the TCP protocol number" are modeled in this document.
The semantics of an individual condition is not specified in [PFCORE]. Snir, Ramberg, Strassner, Cohen expires October 2000 22
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 <variable>, <operator> and <value>. 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 The qosPolicySimpleCondition class models individual conditions. This
class refines the basic structure of the policyCondition class defined
in [PCIM] by using the triplet <variable>, <operator> and <value> to
form a condition.
The variable specifies the attribute of a flow that should be matched
when evaluating the condition. A set of predefined variables that cover
the basic network attribute are introduced to foster interoperability.
The list cover layer 3 IP attribute such as IP network addresses,
protocols and ports, as well as a set of layer 2 attributes and higher
level attributes such as application and user identity.
The variable is matched against a value to produce the Boolean result.
In the first example above, a source IP address variable is matched
against a 10.1.x.x subnet value. The operator specifies the type of
relation between the variable and the value evaluated in the condition.
Operators should model the 'belong to' and 'equal' relations in the
examples above. In many cases, a generic 'match' operator can be used,
and the interpretation of the relation between the variable and value
is implied by the value itself. For example, the variable source IP
address can be matched to an IP address, where the 'equal' relation is
implied, to a hostname in which the 'resolve to' relation is implied,
or to a subnet address in which 'belongs to' relation is implied.
4.2.1 Reusable vs. Ad-Hoc Conditions
This schema enables the reuse of simple conditions by placing them in a This schema enables the reuse of simple conditions by placing them in a
common portion of the policy information tree (called the reusable- common portion of the policy information tree (called the reusable-
objects repository). In order for a simple condition to be a member of object repository). In order for a simple condition to be a member of
this repository, it must carry a name, as any reusable object this repository, it must carry a unique name.
[PFCORE]).
A qosPolicySimpleCondition can either directly contain a value and a A qosPolicySimpleCondition can either directly contain a value and a
variable, or can reference either one of them if they are kept in a variable, or can reference either one or both of them if they are kept
repository. in a reusable-object repository.
Simple condition composition must enforce the following type Simple condition composition must enforce the following type
conformance rules: The qpValueTypes property of the variable must be conformance rule: The qpValueTypes property of the variable must be
compatible with the value class name. compatible with the value class name.
The QoS information model defines four different ways to compose a The QPIM defines four different ways to compose a simple condition
simple condition through the combination of representations of through the combination of representations of variables and values. The
variables and values. The following combinations of representing a following combinations of representing a simple condition by references
simple condition by references and containment are possible: and containment are possible:
Snir, Ramberg, Strassner, Cohen expires September 2000 15
Variable representation Variable representation
1. The class qosPolicyVariable may be contained in the 1. The class qosPolicyVariable may be contained in the
qosPolicySimpleCondition instance. qosPolicySimpleCondition instance.
2. The class qosPolicyVariable may be referenced from the 2. The class qosPolicyVariable may be referenced from the
qosPolicySimpleCondition instance (Reusable variable) qosPolicySimpleCondition instance (Reusable variable)
Snir, Ramberg, Strassner, Cohen expires October 2000 23
Value representation Value representation
1. The qosPolicyValue class may be contained in the 1. The qosPolicyValue class may be contained in the
qosPolicySimpleCondition class. qosPolicySimpleCondition class.
2. The qosPolicyValue class may be referenced from 2. The qosPolicyValue class may be referenced from the
the qosPolicySimpleCondition instance. This allows reusing the qosPolicySimpleCondition instance. This allows reusing the
qosPolicyValue object, which could be named and considered a named qosPolicyValue object, which could be named and considered a named
constant. constant.
4.2.2. Using simple conditions 4.2.2. Using Simple Conditions
In most cases, the use of the qosPolicySimpleCondition class is In most cases, the use of the qosPolicySimpleCondition class is
sufficient for the definition of a condition for a policyRule. A simple sufficient for the definition of a condition for a policyRule. A simple
condition can be added to a policyRule in two ways: condition can be added to a policyRule in two ways:
1. A direct attachment of an instance of the simple condition to the 1. A direct attachment of an instance of the condition to the
ConditionInPolicyRule instance. In this case we call this an "ad-hoc" ConditionInPolicyRule instance. In this case, we call this an
simple condition. This method allows the creation of a "private" simple "ad-hoc" simple condition. This method allows the creation of a
condition. This instance of the condition can't be referenced by any "private" simple condition, meaning that this instance of the
other policy rule, and therefore is not reusable. However, since it condition can't be referenced by any other policy rule, and
embeds the condition directly in the therefore is not reusable. However, since it embeds the condition
ConditionInPolicyRule instance, it eliminates the extra access(es) directly in the ConditionInPolicyRule instance, it eliminates the
required to fetch each of the condition elements that are refernced by extra access(es) required to fetch each of the condition elements
pointers. that are refernced by pointers.
2. Use the simple condition list attribute, ContainedCondition 2. An indirect reference to an instance of a condition that resides in
(defined in the ConditionInPolicyRule class) to point to a repository- a reusable-object repository. This is called a reusable condition.
resident simple condition. This is called a reusable simple condition. This method allows the sharing of conditions by multiple policy
This method allows the sharing of simple conditions by multiple policy
rules. rules.
4.2.3. Composing complex conditions 4.2.3. Composing Complex Conditions
A complex condition consists of groups of simple conditions (i.e., A complex condition consists of groups of simple conditions (i.e.,
instances of either the policySimpleCondition and/or the instances of either the policyCondition and/or the
qosPolicySimpleCondition classes) that are combined in either qosPolicySimpleCondition classes) that are combined in either
conjunctive or disjunctive normal form (as defined in [PFCORE]). conjunctive or disjunctive normal form (as defined in [PCIM]).
A complex condition is modeled by the mechanism supplied in PFCORE A complex condition is modeled by the mechanisms supplied in the
attributes: following PCIM attributes:
Snir, Ramberg, Strassner, Cohen expires September 2000 16
1. The ConditionListType attribute of the policyRule, which 1. The ConditionListType attribute of the policyRule, which
is a boolean expression type (from the Core schema) that is a boolean expression type that defines whether the simple
defines whether the simple condition is in conjunctive or condition is in conjunctive or disjunctive normal form.
disjunctive normal form. 2. The PolicyConditionInPolicyRule aggregation class that does three
2. The ConditionInPolicyRule class that defines whether the condition things: associates conditions to a particular policy rule, defines
is negated or not and what is the associated group of the boolean whether the condition is negated or not, and partitions the
expression this condition belongs to. For details see [PFCORE] referenced conditions into one or more groups. For more details,
section 6.3. please see [PCIM], section 6.3.
4.3 Simple Condition operator Snir, Ramberg, Strassner, Cohen expires October 2000 24
4.3 Simple Condition Operator
The QoS policy simple condition includes the qpOperator property, The QoS policy simple condition includes the qpOperator property,
specifiing the type of relation between the variable and the value Which specifies the type of relation between the variable and the value
evaluated in the condition. evaluated in the condition. In many cases, a generic 'match' operator
In many cases, a generic 'match' operator can be used, and the can be used, and the interpretation of the relation between the
interpretation of the relation between the variable and value is variable and value is implied by the value itself. For example, the
implied by the value itself. For example, the variable source IP variable source IP address can be matched to an IP address, where the
address can be matched to an IP address, where the 'equal' relation is 'equal' relation is implied, to a hostname in which the 'resolve to'
implied, to a hostname in which the 'resolve to' relation is implied, relation is implied, or to a subnet address in which 'belongs to'
or to a subnet address in which 'belongs to' relation is implied. 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 The QPIM defines a single operator, "match", that models the most
generic relation: that of being equal or belonging to.
4.4 QoS Policy Variables
QoS Policy Variables are used for building individual conditions, as QoS Policy Variables are used for building individual conditions, as
defined in section 4.2. The variable specifies the attribute of a flow defined in section 4.2. The variable specifies the attribute of a flow
that should be matched when evaluating the condition. that should be matched when evaluating the condition.
Not every combination of a variable and a value creates a meaningful Not every combination of a variable and a value creates a meaningful
condition. A source IP address variable can not be matched against a condition. For example, a source IP address variable can not be matched
value that specifies a port number. A given variable selects the set of against a value that specifies a port number. The QPIM defines a set of
matchable value types, i.e. a value that could be compared and variables that can be used to model common QoS policy conditions, and
evaluated to a Boolean expression. assigns appropriate semantics for each. Each type of variable
inherently selects the set of value types that it can be matched
against (i.e. a value that could be compared and evaluated to a Boolean
expression).
A variable may also limit the set of values within a particular value A variable may also limit, or constrain, the set of values within a
type that can be matched against it in a condition. For example, a particular value type that can be matched against it in a condition.
source-port variable limits the set of values to represent integers in This may be viewed as a second level of integrity checking. For
the range of 0-65535. Integers outside this range can not be matched to example, a variable representing the source-port must limit the set of
the 16 bits port entity. values that it can assume to the valid range of integers that
The property qpVariableName of the QosPolicyVariable class defines the correspond to legal source-port values (which is 0-65535). Integers
well-known name used for ligical binding of this variable. outside this range can not be matched to this variable. Thus, it is not
The qpValueTypes is the list of value classes that could be matched to enough to say that the data type of the source-port variable is an
this variable, for example the source port variable qpValueTypes integer ű we also need to ensure that the value to be tested is within
property will not include the QosPolicyIPv4AddrValue class for obvious a valid range of integers.
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 The QPIM defines three important attributes that characterize each of
the variables that it defines:
1. The property qpVariableName of the QosPolicyVariable class defines
the well-known name used for logical binding of all variables that
are defined in this document.
2. The qpValueTypes is the list of value classes that could be
matched to this variable.
3. The qpValueConstraints defines a list of constraint on the
variable (i.e., values that the Variable must match).
Snir, Ramberg, Strassner, Cohen expires October 2000 25
The combination of these three attributes provide a consistent and
extensible set of meta-data that define the semantics of variables that
are used to form QoS conditions. For example:
- The qpVariableName can be used to identify common processing rules
for a variable having a specific name.
- The qpValueTypes attribute can be used to ensure that only proper
classes are used as operators. For example, the source-port
variable will not include the QosPolicyIPv4AddrValue class, since
source ports have different semantics than IP addresses. However,
it will include the QosPolicyIntegerValue class name.
ű The qpValueConstraints attribute ensures that variable-specific
semantics are enforced (e.g., the source-port variable may include
a constraint reference to a value object defining the integer range
0..63535).
4.4.1. Variable Binding 4.4.1. Variable Binding
For the QoS Policy schema to be interoperable, different policy For the QoS Policy schema to be interoperable, different policy
management systems and policy servers must instantiate the same management systems and policy servers must instantiate the same
variables with identical values (in the same evaluation operation). variables with identical values (in the same evaluation operation).
While different policy servers may use a different binding mechanism, While different policy servers may use a different binding mechanism,
the binding logic must result in an identical instantiation. the binding logic must result in an identical instantiation.
Each variable defined in the QoS policy repository must be bound to a 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 logical entity such as a specific field in the IP header, application
unique identifier or an application-specific parameter. unique identifier or an application-specific parameter.
When a policy server attempts to evaluate an expression containing When a policy server attempts to evaluate an expression containing
variables, it must instantiate the variables. To instantiate a variables, it must instantiate the variables. To instantiate a
variable, that variable must be bound to a specific value (or values, variable, that variable must be bound to a specific value (or values,
depending on its type category) and associated with a logical entity. depending on its type category) and associated with a logical entity.
For example, in the expression 'sourceport == 80', the variable For example, in the expression 'source-port == 80', the variable
'sourceport' must be instantiated to a value and logically associated 'source-port' must be instantiated to a value and logically associated
with the packet header field containing the source port number, for the with the packet header field containing the source port number, for the
expression to be evaluated. expression to be evaluated.
If, in this example, the variable sourceport is bound to a value of If, in this example, the variable source-port is bound to a value of
'80', then the expression is evaluated to TRUE for each packet that the '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 source port number in the IP header field equals 80. Otherwise it is
evaluated to FALSE. evaluated to FALSE.
4.4.2. Pre-defined Variables 4.4.2. Pre-Defined Variables
The purpose of this section is to explain the need and define the The purpose of this section is to explain the need and define the
relationship of standard, frequently used variables with their logical relationship of standard, frequently used variables with their logical
entities. Pre-defined variables are necessary for ensuring entities. Pre-defined variables are necessary for ensuring
interoperability among policy servers and policy management tools from interoperability among policy servers and policy management tools from
different vendors. different vendors.
Snir, Ramberg, Strassner, Cohen expires October 2000 26
For example, different policy servers may have to evaluate the same For example, different policy servers may have to evaluate the same
policy rule. Variables enable the condition term to be abstracted such policy rule. If each policy server uses a common set of variables, this
that its evaluation can be performed in the same helps to abstract the condition term such that its evaluation can be
way. performed in the same way.
The QoS Policy information model specifies a set of pre-defined The QoS Policy information model specifies a set of pre-defined
variables to support a set of fundamental QoS variables such as IP variables to support a set of fundamental QoS terms that are commonly
header fields, user information, applications, etc. A pre-defined used to form conditions. Examples of these include IP header field
variable must always have the same name and binding semantics, i.e.: a values, user information, applications, and others. A pre-defined
given pre-defined variable should be bound to the same logical entity variable MUST always have the same name and binding semantics. For
by all client systems (typically policy servers). Similarly, the pre- example, a given pre-defined variable should be bound to the same
defined variable should be stored in the reusable-objects repository to logical entity by all client systems (typically policy devices).
enable reuse and sharing of the pre-defined variable. Similarly, the pre-defined variable should be stored in the reusable-
object repository to enable reuse and sharing of the pre-defined
variable.
All standard variable names are case insensitive and do not include All standard variable names are case insensitive and do not include
spaces or other non-standard characters. spaces or other non-standard characters to promote ease of use.
Snir, Ramberg, Strassner, Cohen expires September 2000 18
The implementers of client systems that use the QoS Policy schema must The implementers of client systems that map the QPIM to a specific
provide binding methods to bind pre-defined variables according to the repository-based implementation MUST provide binding methods to bind
semantics specified in this section. pre-defined variables according to the semantics specified in this
section.
Following is a table that defines the predefined Variable names and Following is a table that defines the predefined variable names and
their binding. The table indicates which fields are checked in actual their binding. The table indicates which fields are checked in actual
filters used in provisioning policies as well as in RSVP signaling filters used in provisioning policies as well as in RSVP signaling
messages. messages.
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
|Variable name | Logical binding | |Variable name | Logical binding |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| SourceIP | The source IP address of the flow. Compared to the| | SourceIP | The source IP address of the flow. Compared to the|
| | source IP header field, or the sender address in | | | source IP header field, or the sender address in |
| | the RSVP Filter spec object [RSVP]. | | | the RSVP Filter spec object [RSVP]. |
skipping to change at line 976 skipping to change at line 1393
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| DestinationIP | The destination IP address of the flow. Compared | | DestinationIP | The destination IP address of the flow. Compared |
| | to the destination IP header field, or the session| | | to the destination IP header field, or the session|
| | address in the RSVP SESSION object [RSVP]. | | | address in the RSVP SESSION object [RSVP]. |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| DestinationPort | The destination Port of a UDP/TCP flow. Compared | | DestinationPort | The destination Port of a UDP/TCP flow. Compared |
| | to the destination port field in the TCP/UDP | | | to the destination port field in the TCP/UDP |
| | header, or the session port in the RSVP SESSION | | | header, or the session port in the RSVP SESSION |
| | object [RSVP]. | | | object [RSVP]. |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
(Table continued in next page)
Snir, Ramberg, Strassner, Cohen expires October 2000 27
(Table continued from the previous page)
+-----------------+---------------------------------------------------+
|Variable name | Logical binding |
+-----------------+---------------------------------------------------+
| IPProtocol | The IP protocol number. Compared to the protocol | | IPProtocol | The IP protocol number. Compared to the protocol |
| | number in the IP header field or to the IP | | | number in the IP header field or to the IP |
| | protocol in the RSVP SESSION object [RSVP]. | | | protocol in the RSVP SESSION object [RSVP]. |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| ToS | The ToS variable is bound to the IP header ToS | | ToS | The ToS variable is bound to the IP header ToS |
| | byte. | | | byte. |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| DSCP | The DSCP variable is bound to the IP header DSCP | | DSCP | The DSCP variable is bound to the IP header DSCP |
| | byte or to DCLASS RSVP object. | | | byte or to DCLASS RSVP object. |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| DestinationMAC | The destination MAC address variable is bound the | | DestinationMAC | The destination MAC address variable is bound the |
| | frame destination MAC address. | | | frame destination MAC address. |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| SourceMAC | The source MAC address variable is bound the frame| | SourceMAC | The source MAC address variable is bound the frame|
| | source MAC address. | | | source MAC address. |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| 8021QID | The VLAN ID as represented in the 802.1Q field of | | 8021QID | The VLAN ID as represented in the 802.1Q field of |
| | the header. | | | the header. |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
(Table continued in next page)
Snir, Ramberg, Strassner, Cohen expires September 2000 19
(Table continued from the previous page)
+-----------------+---------------------------------------------------+
|Variable name | Logical binding |
+-----------------+---------------------------------------------------+
| Snap | The snap protocol variable is bound to protocol | | Snap | The snap protocol variable is bound to protocol |
| | type carried over SNAP encapsulation. | | | type carried over SNAP encapsulation. |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| Ethertype | The ethertype variable is bound to the frame | | Ethertype | The ethertype variable is bound to the frame |
| | header ethertype value. | | | header ethertype value. |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| Ssap | The source sap variable is bound the frame header | | Ssap | The source sap variable is bound the frame header |
| | field containing the source SAP. | | | field containing the source SAP. |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| Dsap | The destination sap variable is bound the frame | | Dsap | The destination sap variable is bound the frame |
skipping to change at line 1026 skipping to change at line 1443
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| Application | The ID of the application that generated the flow.| | Application | The ID of the application that generated the flow.|
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| User | The ID of the user that initiated the flow, or is | | User | The ID of the user that initiated the flow, or is |
| | designated as the flow owner. | | | designated as the flow owner. |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
Table 2. Pre-defined Variable Names and Their Bindings Table 2. Pre-defined Variable Names and Their Bindings
The definition of each predefined variable includes a standard name and The definition of each predefined variable includes a standard name and
the allowed value types, i.e. the variableĂs qpValueTypes property. the allowed value types, i.e. the variable's qpValueTypes property.
Following is a table of variable names and their default allowed class Following is a table of variable names and their allowed class types.
types.
Snir, Ramberg, Strassner, Cohen expires October 2000 28
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
|Variable name | Allowed class types | |Variable name | Allowed class types |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| SourceIP | qosPolicyIPv4AddrValue, qosPolicyIPv6AddrValue | | SourceIP | qosPolicyIPv4AddrValue, qosPolicyIPv6AddrValue |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| SourcePort | qosPolicyIntegerValue | | SourcePort | qosPolicyIntegerValue |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| DestinationIP | qosPolicyIPv4AddrValue, qosPolicyIPv6AddrValue | | DestinationIP | qosPolicyIPv4AddrValue, qosPolicyIPv6AddrValue |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| DestinationPort | qosPolicyIntegerValue | | DestinationPort | qosPolicyIntegerValue |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| IPProtocol | qosPolicyIntegerValue | | IPProtocol | qosPolicyIntegerValue |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| ToS | qosPolicyIntegerValue, qosPolicyBitStringValue | | ToS | qosPolicyIntegerValue, qosPolicyBitStringValue |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| DSCP | qosPolicyIntegerValue, qosPolicyBitStringValue | | DSCP | qosPolicyIntegerValue, qosPolicyBitStringValue |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
(Table continued in next page)
Snir, Ramberg, Strassner, Cohen expires September 2000 20
(Table continued from previous page)
+-----------------+---------------------------------------------------+
| DestinationMAC | qosPolicyMACAddrValue | | DestinationMAC | qosPolicyMACAddrValue |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| SourceMAC | qosPolicyMACAddrValue | | SourceMAC | qosPolicyMACAddrValue |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| 8021QID | qosPolicyIntegerValue, qosPolicyBitStringValue | | 8021QID | qosPolicyIntegerValue, qosPolicyBitStringValue |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| Snap | qosPolicyIntegerValue | | Snap | qosPolicyIntegerValue |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| Ethertype | qosPolicyIntegerValue | | Ethertype | qosPolicyIntegerValue |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
skipping to change at line 1079 skipping to change at line 1489
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| Application | qosPolicyDNValue, qosPolicyStringValue, | | Application | qosPolicyDNValue, qosPolicyStringValue, |
| | qosPolicyAttributeValue | | | qosPolicyAttributeValue |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| User | qosPolicyDNValue, qosPolicyStringValue, | | User | qosPolicyDNValue, qosPolicyStringValue, |
| | qosPolicyAttributeValue | | | qosPolicyAttributeValue |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
Table 3. Allowed Variable Names and Their Default Class Types Table 3. Allowed Variable Names and Their Default Class Types
For Value type definition check the QoS Policy Value section. Note: For Value type definition, check the QoS Policy Value section.
Snir, Ramberg, Strassner, Cohen expires October 2000 29
4.5 QoS Policy Value 4.5 QoS Policy Value
This abstract class QoSPolicyValue is used for defining values and This abstract class qosPolicyValue is used for defining values and
constants used in policy conditions. Different value types are derived constants used in policy conditions. Different value types are derived
from this class and represent the various attributes required. from this class and represent the various attributes required.
Extensions off the QoS Polictvalue class, defined in this document Extensions of the qosPolicValue class, defined in this document
provide a list of values for representing the basic network attribute. provide a list of values for representing the basic network attribute.
Values can be used to represent constants as named values. Named values Values can be used to represent constants as named values. Named values
could be kept in a repository to be reused by multiple conditions. could be kept in a repository to be reused by multiple conditions.
Examples of constants include well-known ports, well-known protocol, Examples of constants include well-known ports, well-known protocol,
server addresses, etc. server addresses, and other similar concepts.
The QoS Policy value classes define 3 types of basic values, scalars,
ranges and sets. For example a well-known port number could be defined 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) 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 a range (80-88) or a set (80, 82, 8080). For details, please see the
definition for each value type. class definition for each value type.
The QoS policy information model provide the following classes, all of The QoS policy information model provide the following classes, all of
them extending the QoSPolicyvalue: them extending the QoSPolicyvalue:
General:
QosPolicyStringValue
QosPolicyIntegerValue,
Snir, Ramberg, Strassner, Cohen expires September 2000 21
QosPolicyBitStringValue, General:
QosPolicyDNValue, qosPolicyStringValue
QosPolicyAttributeValue. qosPolicyIntegerValue,
qosPolicyBitStringValue,
qosPolicyDNValue,
qosPolicyAttributeValue.
Layer 3 Network values: Layer 3 Network values:
qosPolicyIPv4AddrValue, qosPolicyIPv4AddrValue,
qosPolicyIPv6AddrValue. qosPolicyIPv6AddrValue.
Layer 2 Network values: Layer 2 Network values:
QosPolicyMACAddrValue. qosPolicyMACAddrValue.
For details see class definition section of each value. For details, please see the class definition section of each value.
4.6. PolicyTimePeriodCondition 4.6. PolicyTimePeriodCondition
The QoS Policy Information model uses the PolicyTimePeriodCondition The QoS Policy Information model uses the policyTimePeriodCondition
class [PFCORE] to define time based QoS Policy rules. For details see class (defined in [PCIM]) to define time based QoS policy rules. For
[PFCORE] section 6.5. details, please see [PCIM], section 6.5.
4.7. Actions 4.7. Actions
The QoS Policy schema defines actions to control QoS enforcement in The QoS Policy schema defines actions to control QoS enforcement in
both the Integrated-Service model as well as the Differential service both the Integrated-Service model as well as the Differential service
model. Two types of actions are provided: Signaling and Provisioning model. Two types of actions are provided: Signaling and Provisioning
actions. Signaling actions are used to provide policy control on RSVP actions.
Snir, Ramberg, Strassner, Cohen expires October 2000 30
Signaling actions are used to provide policy control on RSVP
requests. Provisioning actions are used to directly control the data requests. Provisioning actions are used to directly control the data
traffic, regardless of any out-of-band signaling. traffic, regardless of any out-of-band signaling.
A Policy rule may include 0..n provisioning actions and 0..m signaling A policy rule may aggregate zero or more policy actions. A QoS policy
actions objects, each defining an action to perform. rule extends this definition to include 0..n provisioning actions and
Actions are ordered (prioritized). The order of actions is specified in 0..m signaling actions, each defined by an object or objects describing
[PFCORE]; Order of actions for a rule is determined by the integer the action(s) to perform. Actions are ordered (as opposed to rules,
value assigned to the policyActionOrder property of the which are prioritized). The order of actions is specified in [PCIM].
policyRuleActionAssociation class. Provisioning and signaling actions
are intermixed in the rule. Policy consumers (such as PDPs) may The property SequencedActions in the aggregating instance of defines
separate the actions to two lists but must respect the internal order whether a specified action order is required, recommended, or of no
of the specified actions. significance.
QoS Policy action classes extend the [PFCORE] PolicyAction class.
Additional type of actions may be added as extensions to this schema by Ordering semantics depend on how actions are represented. If actions
extending the PolicyAction and using the current mechanisms. are represented as separate objects, the PolicyActionInPolicyRule
aggregation can be used to express an order. In this case, three
attributes are used:
- ContainingRule, which contains a reference to a policyRule that
contains one or more policyActions
- ContainedAction, which contains an object reference to a
policyAction contained by one or more policyRules
- ActionOrder, which is an unsigned integer 'n' that indicates the
relative position of an action in the sequence of actions that are
associated with a given policy rule. When 'n' is a positive
integer, it indicates a place in the sequence of actions to be
performed, with smaller integers indicating earlier positions in
the sequence. The special value '0' indicates "don't care". If
two or more actions have the same non-zero sequence number, they
may be performed in any order, but they must all be performed at
the appropriate place in the overall action sequence.
For actions defined explicitly in a subclass of policyRule, the
ordering mechanism must be specified in the subclass definition. Note
that QPIM does not define any policyRule subclasses. Instead, the QPIM
defines subclasses of policyCondition and policyAction to extend the
semantics of these classes.
Provisioning and signaling actions can be intermixed in a QoS policy
rule. Policy consumers (such as PDPs) MAY separate the actions into
separate lists, but MUST respect the internal order of the specified
actions.
4.7.1 Provisioning Actions 4.7.1 Provisioning Actions
QoS Policy provisioning actions model traffic conditioner [DIFF-SERV- QoS Policy provisioning actions model traffic conditioner elements, as
ARCH] elements. Actions model meters, markers, shapers and droppers. specified in [DIFF-SERV-ARCH]. Actions model meters, markers, shapers
and droppers.
1. Meters measure the temporal properties of the stream of packets Snir, Ramberg, Strassner, Cohen expires October 2000 31
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 4.7.1.1 Meters
property specifies whether the meter should measure flows matching Meters measure the temporal properties of the stream of packets
the rule condition per interface, per device or per flow. A selected by a classifier against a traffic profile. Meters are modeled
per flow meter conceptually creates a new meter for each flow, by the QosPolicyMeter class. A meter can be shared between different
measuring each flow against the profile. A per interface meter measures policy rules. If this is desired, then the meter SHOULD reside in a
the aggregate set of flows matching the rule condition forwarded via a reusable-object repository. This enables it to be referenced by all
single interface. Meters are measured against traffic profile modeled policy rules that want to share it.
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, The property qpMeter is used to hold a reference to a (reusable) meter
adding the marked packet to a particular DS behavior aggregate. The that is kept in a reusable-object repository. The qpMeterScope property
marker may be configured to mark all packets steered to it to a single specifies whether the meter should measure flows matching the rule
codepoint, or may be configured to mark a packet to one of a set of condition per interface, per device or per flow. A per flow meter
codepoints used to select a PHB in a PHB group, according to the state conceptually creates a new meter for each flow, measuring each flow
of a meter. When the marker changes the codepoint in a packet it is against the profile. A per interface meter measures the aggregate set
said to have "re-marked" the packet. Marking is modeled by the property of flows matching the rule condition forwarded via a single interface.
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 Meters are measured against traffic profile modeled by the
order to bring the stream into compliance with a traffic profile. A qosPolicyPRTrfcProf object. The property qpTrfcProf holds a reference
shaper usually has a finite-size buffer, and packets may be discarded to a traffic profile that resides in a reusable-object repository.
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 4.7.1.2 Markers
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: Markers are used to set the DS field of a packet to a particular DS
codepoint (DSCP), adding the marked packet to a particular DS behavior
aggregate. The marker may be configured to mark all packets steered to
it to a single DSCP, or may be configured to mark a packet to one of a
set of DSCPs used to select a PHB in a PHB group, according to the
state of a meter. When the marker changes the DSCP in a packet, it is
said to have "re-marked" the packet.
Rule P = If (<condition>) than mark = <DS Value> AND activate a per- Marking is modeled by the property qpSetDSCPValue, which specifies the
flow policer <FLOWP> AND activate a per policy rule policer <CLASSP>. DSCP to set. Remarking out-of-profile packets is modeled by the
Activate rule on outgoing traffic. qpOutofProfileRemarkValue property. The property qpOutOfProfileAction
should be set to 'remark' when the remark DSCP value is used.
4.7.1.3 Shapers
Shapers are used to delay some or all of the packets in a traffic
stream in order to bring the stream into compliance with a traffic
profile. A shaper usually has a finite-sized buffer, and packets may
be discarded if there is not sufficient buffer space to hold the
delayed packets.
If the value of the property qpOutOfProfileAction is set to 'shape',
then this specifies that packets measured by a meter should be shaped
according to the traffic profile specified by a qosPolicyPRTrfcProf
object.
Snir, Ramberg, Strassner, Cohen expires October 2000 32
4.7.1.4. Droppers
Droppers are used to discard some or all of the packets in a traffic
stream in order to bring the stream into compliance with a traffic
profile. This process is also known as "policing" the stream.
If the value of the property qpOutOfProfileAction is set to 'drop',
then it specifies that packets measured by a meter should be policed
according to the traffic-profile specified by a qosPolicyPRTrfcProf
object.
4.7.1.5 Examples
The following examples will help to show how these classes can be used
to perform general provisioning actions.
Example 1: Set up a rule enforcing QoS provisioning actions:
LetĂs define a policy rule, P, as follows:
If (<condition>) THEN, on outgoing traffic,
mark with <DS Value> AND
activate a per-flow policer <FLOWP> AND
activate a per policy rule policer <CLASSP>
Rule P is represented using 3 qosPolicyPRAction objects: Rule P is represented using 3 qosPolicyPRAction objects:
Object 1: Object 1:
qpDirection: OUT qpDirection: OUT
qpSetDSCPValue: <DS Value> qpSetDSCPValue: <DS Value>
Object 2: Object 2:
qpDirection: OUT qpDirection: OUT
qpMeterScope: flow qpMeterScope: flow
qpTrfcProf: <FLOWP> DN (repository reference) qpTrfcProf: <FLOWP> (this is a repository-specific reference to a
per-flow policer object)
qpOutOfProfileAction: discard qpOutOfProfileAction: discard
Snir, Ramberg, Strassner, Cohen expires September 2000 23
Object 3: Object 3:
qpDirection: OUT qpDirection: OUT
qpMeterScope: Interface qpMeterScope: Interface
qpTrfcProf: <CLASSP> DN (repository reference) qpTrfcProf: <CLASSP> (this is a repository-specific reference to a
per-policyRule policer object)
qpOutOfProfileAction: discard qpOutOfProfileAction: discard
qpMeter: <Meter> qpMeter: <Meter>
Some PHBs require the successive application of a number of traffic Snir, Ramberg, Strassner, Cohen expires October 2000 33
conditioners. An example of a policy with two levels of traffic
conditioners is the following: "Mark packets to DSCP=24 if rate is Example 2: Conditioning traffic
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 Some PHBs require the successive application of a set of traffic
policy rule is modeled by using two actions. The first action measures conditioners to properly process the traffic. An example of a policy
the traffic against the first profile specifying DSCP=24 to set for with two levels of traffic conditioning is the following:
within profile packets. Out-of-profile packets are marked to DSCP=23.
The subsequent action measured traffic against the second higher Mark packets to DSCP=24 if the rate is within profile x=<64Kb/s>,
profile, and drops out-of-profile packets. Arbitrary cascading of else mark packets with DSCP=25 if rate is within profile y=<128kb/s>,
traffic conditioners can be constructed, where each action measures else drop out-of-profile packets.
traffic against a higher traffic profile and change only the out-of-
profile action as required. This policy rule can be modeled by using two actions. The first action
measures the traffic against the first profile. If the traffic is
within this profile, then the traffic is (re)marked with a DSCP of 24.
If the traffic is out of profile, then the subsequent action measures
the traffic against the second higher profile. If the traffic is within
this profile, then the traffic is (re)marked with a DSCP of 25.
Otherwise, the traffic is out of profile, and it will be dropped.
In this way, an arbitrary cascading of traffic conditioners can be
constructed, where each action measures traffic against a higher
traffic profile and change only the out-of-profile action as required.
4.7.2 Signaling Action 4.7.2 Signaling Action
RSVP is the standard protocol used for requesting QoS resources from RSVP is the standard protocol used for requesting QoS resources from
the network. The QoS Policy signaling actions control the decision the network. The QoS policy signaling actions defined in this document
whether to admit or reject an RSVP request based on the request's can be used to control whether to admit or reject an RSVP request based
attributes and the specified policy. The QoS policy signaling actions on the request's attributes and the specified policy. The QoS policy
allow modifying the content and forwarding behavior of RSVP requests. signaling actions allow modifying the content and forwarding behavior
of RSVP requests.
The signaling policies control the admission priority of resources and The signaling policies control the admission priority of resources and
provide preemption support. Mapping of integrated services signaled by provide preemption support. Mapping of integrated services signaled by
RSVP to differential services in a core network is controlled by RSVP to differential services in a core network is controlled by
signaling policies as well, by assigning DSCP to flows on the boundary signaling policies as well, by assigning appropriate DSCPs to flows on
of the differential service core. the boundary of the differential service core.
The set of policies specified allow a policy server (policy decision The set of policies specified allow a policy server (policy decision
point) to instruct an RSVP node (policy enforcement point) to enforce point) to instruct an RSVP node (policy enforcement point) to enforce
all set of controls defined in the COPS protocol specification. The all set of controls defined in the COPS protocol specification. The
actions defined here follow the different decision types of the COPS actions defined here follow the different decision types of the COPS
protocol [COPS] and the guidelines for it's use in RSVP environment protocol [COPS] and the guidelines for its use in an RSVP environment
[COPS-RSVP]. The basic decision to accept or deny a reservation is [COPS-RSVP]. The basic decision to accept or deny a reservation is
modeled by qosPolicyRSVPAction. Two supplements can be added to this modeled by the qosPolicyRSVPAction class. Additional control is
decision. qosPolicyRSVPSignalCtrlAction controls the content and provided through the use of two classes. The content and forwarding
forwarding behavior of RSVP flows. qosPolicyRSVPInstallAction controls behavior of RSVP flows is defined by the qosPolicyRSVPSignalCtrlAction
the processing of RSVP requests and accompanying flows within the RSVP class. The qosPolicyRSVPInstallAction class controls the processing of
node itself. QoS signaling policies does not require a policy server RSVP requests and accompanying flows within the RSVP node itself.
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 Snir, Ramberg, Strassner, Cohen expires October 2000 34
QoS signaling policies does not require a policy server for decision
making. A local policy module can use signaling policies for making
local decisions, as well as if other outsourcing policy protocol beside
COPS is used.
The qosPolicyRSVPAction action includes a specification of the subset The qosPolicyRSVPAction action includes a specification of the subset
of RSVP flows on which the action should be taken. The following of RSVP flows on which the action should be taken. The following
parameters can be specified: parameters can be specified:
1. Direction - in/out 1. Direction - in/out
2. Message type - Path/Resv/PathErr/ResvErr 2. Message type - Path/Resv/PathErr/ResvErr
3. Service type - Gaurenteed Service / Controlled Load / Null 3. Service type - Guaranteed Service / Controlled Load / Null
4. Service style - SE, WF, FF 4. Service style - SE, WF, FF
The direction refers to the direction of the flow, hence the direction The direction refers to the direction of the flow, hence the direction
of the RSVP Path messages. Therefore out-direction policies control of the RSVP Path messages. Therefore, out-direction policies control
outgoing Path messages as well as incoming Resv messages. outgoing Path messages as well as incoming Resv messages.
The basic decision modeled by this class is whether to admit or reject 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 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 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 be used to track the temporal resources allocation of RSVP requests
matching a network condition. Such meters allow enforcement of policies matching a network condition. Such meters allow enforcement of policies
of the form: "Allow allocation of resource via RSVP for flows coming 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 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 meters and meter scope is identical to their use in provisioning
policies. The following properties are used: policies. The following properties are used:
skipping to change at line 1293 skipping to change at line 1778
be used to track the temporal resources allocation of RSVP requests be used to track the temporal resources allocation of RSVP requests
matching a network condition. Such meters allow enforcement of policies matching a network condition. Such meters allow enforcement of policies
of the form: "Allow allocation of resource via RSVP for flows coming 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 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 meters and meter scope is identical to their use in provisioning
policies. The following properties are used: policies. The following properties are used:
1. Traffic Profile - referencing a traffic profile. 1. Traffic Profile - referencing a traffic profile.
2. Meter - referencing a meter. 2. Meter - referencing a meter.
Both traffic profile and meter can be directly included within the Both traffic profile and meter specifications can be directly included
action as well. 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: Note that if a traffic profile is not provided, it is implicitly
assumed that the RSVP request should be accepted. Rejecting all RSVP
requests matching the condition is specified by a zero valued traffic
profile.
1. Set DSCP value The qosPolicyRSVPInstallAction adds the following actions:
2. Set the Preemption priority of the RSVP request.
Setting DSCP on the flow on the edge of a differential service core 1. Set the DSCP value
allow provisioning of QoS end to end over a mixed integrated and 2. Set the preemption priority of the RSVP request.
Setting the DSCP of the flow on the edge of a differential service core
allow provisioning of QoS, end-to-end, over mixed integrated and
differential service clouds. differential service clouds.
RSVP node is responsible for admission decision based on its available
resources. Setting preemption priority [RSVP_PREEMP] allows the RSVP Snir, Ramberg, Strassner, Cohen expires October 2000 35
node to decide which of its reservations should be admitted, and when
to make room for a newer reservation by preempting an already installed An RSVP node is responsible for deciding whether to admit flows or not,
one. based on its available resources. Setting the preemption priority
[RSVP_PREEMP] allows the RSVP node to decide which of its reservations
should be admitted, and when to make room for a newer reservation by
preempting an already installed one.
This class should be extended to cover other COPS install decisions if This class should be extended to cover other COPS install decisions if
required. required.
The qosPolicyRSVPSignalCtrlAction adds the following controls: The qosPolicyRSVPSignalCtrlAction adds the following controls:
1. Replace/add DCLASS object in RSVP message. 1. Replace/add DCLASS object in RSVP message.
2. Replace/add Preemption priority object in RSVP message. 2. Replace/add Preemption priority object in RSVP message.
3. Trigger an error/warning RSVP message. 3. Trigger an error/warning RSVP message.
Snir, Ramberg, Strassner, Cohen expires September 2000 25
4. Instruct the RSVP node to proxy RSVP message as if sent by 4. Instruct the RSVP node to proxy RSVP message as if sent by
the RSVP end nodes. the RSVP end nodes.
Modifying the content of messages can be enforced using COPS replace Modifying the content of messages can be enforced using a COPS
decision. This class should be extended to cover other object replacement decision. This class should be extended to cover other
replacements and in particular replacement of policy objects. 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 Triggering errors and warnings is important in scenarios when there is
and various other information. 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 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 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 may map the RSVP request to specific PHB by setting the DSCP on the
flow packets, without forwarding the Path message downstream. Still, flow packets, without forwarding the Path message downstream. Still,
this RSVP node may send back an RSVP Resv message as if the receiver this RSVP node may send back an RSVP Resv message as if the receiver
has sent it, to complete the RSVP cycle. has sent it, to complete the RSVP cycle.
Example for a rule enforcing QoS signaling actions: The following is an example for a rule enforcing QoS signaling actions:
Rule S = If (<condition>) than accept RSVP request requesting less ore Rule S:
all traffic exceeds the rate limit. Traffic that falls between the If <condition> THEN, for all WF and SE style Resv messages,
normal burst size and the Excess Burst size exceeds the traffic profile accept RSVP request requesting less than <64kb/sec> AND
with a probability that increases as the burst size increases. This make sure that the total number of admitted active reservations
provides a Random Discard mechanism for policer, markers and shapers. is restricted to <5>.
Excess burst size should be larger than normal burst size. If excess The actions for Rule S are represented using two qosPolicyRSVPAction
burst is not specified, it is assumed that excess burst size is equal objects, as follows:
to normal burst size. In this case, burst larger than the normal burst
size will always be counted as out-of-profile packets. Object 1:
qpRSVPDirection: OUT
qpRSVPMessageType: Resv
qpRSVPStyle: SE, WF
qpRSVPTrfcProf : DN {8Kb} (repository reference)
qpRSVPMeterScope: flow
Snir, Ramberg, Strassner, Cohen expires October 2000 36
Object 2:
qpRSVPDirection: OUT
qpRSVPMessageType: Resv
qpRSVPStyle: SE, WF
qpRSVPTrfcProf : {6 session Max} (repository reference)
qpRSVPMeter: Meter (repository reference)
qpRSVPMeterScope: interface
The various attributes of RSVP traffic profiles are described in the
next section.
4.8. Traffic Profiles
The QoS Policy schema defines two categories of traffic profiles.
Provisioning traffic profiles carry rate and burst parameters to be
compared with flow meters. RSVP traffic profiles are compared with RSVP
TSPEC and FLOWSPEC parameters, and with meters aggregating the temporal
state of admitted RSVP reservations and states.
Traffic profiles can be kept in a repository for reusability. Traffic
profiles can also be directly attached to actions.
4.8.1. Provisioning traffic profiles
Shaping, policing and remarking provisioning actions compare a
provisioning traffic profile against a meter. The provisioning traffic
profile is a template containing rate and burst values, modeled by the
qosPolicyPRTrfcProf class.
The qosPolicyPRTrfcProf class includes the following properties:
1. Rate measured in bits/sec.
2. Normal burst measured in bytes.
3. Excess burst measured in bytes.
Rate determines the long-term average transmission rate. Traffic that
falls under this rate will always conform. The normal burst size
determines how large traffic bursts can be before some traffic exceeds
the traffic profile. The Excess Burst size determines how large traffic
bursts can be before all traffic exceeds the rate limit. Traffic that
falls between the normal burst size and the Excess Burst size exceeds
the traffic profile with a probability that increases as the burst size
increases. This provides a Random Discard mechanism for policers,
markers and shapers.
Excess burst size SHOULD be greater than or equal to the normal burst
size. If the excess burst size is not specified, it is assumed that
excess burst size is equal to the normal burst size. In this case,
burst larger than the normal burst size will always be counted as out-
of-profile packets.
Snir, Ramberg, Strassner, Cohen expires October 2000 37
4.8.2. RSVP traffic profiles
RSVP signaling QoS policy can condition the decision whether to accept RSVP signaling QoS policy can condition the decision whether to accept
or deny an RSVP request based on the traffic specification of the flow or deny an RSVP request based on the traffic specification of the flow
(TSPEC) or the amount of QoS resources requested (FLOWSPEC). The TSPEC (TSPEC) or the amount of QoS resources requested (FLOWSPEC). The TSPEC
and FLOWSPEC objects are either compared directly with a traffic and FLOWSPEC objects are either compared directly with a traffic
profile, or aggregated to a meter that measures the temporal admitted profile, or aggregated to a meter that measures the temporal admitted
RSVP states and than compared to the traffic specification. RSVP states and than compared to the traffic specification. The
QosPolicyRSVPTrfcProf class models such a traffic profile. The qosPolicyRSVPTrfcProf class models such a traffic profile. The
qosPolicyRSVPTrfcProf class has the following properties: qosPolicyRSVPTrfcProf class has the following properties:
1. Token Rate (r) measured in bits/sec. 1. Token Rate (r) measured in bits/sec.
2. Peak Rate (p) measured in bits/sec. 2. Peak Rate (p) measured in bits/sec.
3. Bucket Size (b) measured in bytes. 3. Bucket Size (b) measured in bytes.
4. Min Policed unit (m) measured in bytes. 4. Min Policed unit (m) measured in bytes.
5. Max packet size (M) measured in bytes. 5. Max packet size (M) measured in bytes.
6. Resv Rate (R) measured in bits/sec. 6. Resv Rate (R) measured in bits/sec.
7. Slack term (s) measured in microseconds. 7. Slack term (s) measured in microseconds.
8. Number of sessions. 8. Number of sessions.
The first 5 parameters are the traffic specification parameters used in The first 5 parameters are the traffic specification parameters used in
integrated service. For a definition and full explanation of their the integrated service architecture. These parameters are used to
meaning refer to [RSVP-IS]. These parameters are used to define a define a sender TSPEC as well as FLOWSPEC for the Controlled Load
service [CL]. For a definition and full explanation of their meaning,
Snir, Ramberg, Strassner, Cohen expires September 2000 27 please refer to [RSVP-IS]. Parameters 6 and 7 are the additional
parameters used for specification of the Guaranteed Service FLOWSPEC
sender TSPEC as well as FLOWSPEC for the Controlled Load service [CL]. [GS]. The last parameter is used to specify the maximum number of
Parameters 6 and 7 are the additional parameters used for specification allowed RSVP sessions. This provides an easy way to limit the number of
of the Guaranteed Service FLOWSPEC [GS]. admitted RSVP requests without requiring pre-knowledge of the
aggregated rates requested.
A partial order is defined between TSPECs (and FLOWSPECs). A TSPEC A is A partial order is defined between TSPECs (and FLOWSPECs). A TSPEC A is
larger than TSPEC B if and only if rA>rB, pA>pB, bA>bB, mA<mB and larger than TSPEC B if and only if rA>rB, pA>pB, bA>bB, mA<mB and
MA>MB. A TSPEC RSVP measured against a traffic profile use the same MA>MB. A TSPEC measured against a traffic profile uses the same
ordering rule. An RSVP message is accepted only if its TSPEC (FLOWSPEC) ordering rule. An RSVP message is accepted only if its TSPEC (FLOWSPEC)
is either smaller or equal to the traffic profile. Only parameters is either smaller or equal to the traffic profile. Only parameters
specified in the traffic profile are compared. GS FLOWSPEC is compared specified in the traffic profile are 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 The GS FLOWSPEC is also compared against the rate R and the slack term
should not be smaller than that specified in 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 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 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 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 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 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 that measures the temporal state of admitted RSVP states. The meter is
than compared with the traffic profile specified in the signaling than compared with the traffic profile specified in the signaling
policy using the same rules for comparison of TSPECs (FLOWSPECs) to a policy using the same rules for comparison of TSPECs (FLOWSPECs) to a
traffic profile. traffic profile.
RSVP traffic profile may specify also the maximal number of allowed Snir, Ramberg, Strassner, Cohen expires October 2000 38
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 5. Decision strategy
The decision strategy to be used by policy servers and other policy The decision strategy to be used by policy servers and other policy
decision points in the network on the set of defined policies is decision points in the network on a set of policies is defined by
defined per qosNamedPolicyContainer group. grouping policies into various qosNamedPolicyContainer groups, and
In order to get a consistent behavior of different policy servers using using these groups to partition behavior in different QoS policy
the same group of policy rules, the priority of the policy rules must domains. In order to get a consistent behavior of different policy
be pre-defined and the decision strategy implemented by each different servers using the same group of policy rules, the priority of the
policy server must be defined explicitly. 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 The decision strategy is defined per domain and can be overridden per
qosNamedPolicyContainer. When a policy decision point evaluates a set qosNamedPolicyContainer. When a policy decision point evaluates a set
of rules, it implements the decision strategy defined in each container of rules, it implements the decision strategy defined in each container
of rules. Nested containers can override the decision strategy of their of rules. Nested containers can override the decision strategy of their
containers. 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 The order of decision making of nested rules is defined by the
combination of their internal priority, the priority of the policy rule
containing the nested rule and the priority of their containers.
Nested rules have a higher priority than their containing rule.
Priority is compared between rules and qosNamedPolicyContainers, as
Defined in [PCIM]. The rule priority of PCIM is extended by introducing
the qpPriority (group priority) property of qosNamedPolicyContainer.
Two decision strategies are defined: Two decision strategies are defined:
1. "FIRST MATCH" 1. "FIRST MATCH"
2. "MATCH ALL" 2. "MATCH ALL"
5.1. First match 5.1. First match
The first match decision strategy is defined as a process that The first match decision strategy is defined as a process that
evaluates the policy rules in the defined order, evaluating the rules' evaluates the policy rules in the defined order, evaluating the
conditions, until a condition is evaluated to TRUE. The rule's actions conditions of each rule, until a condition is evaluated to TRUE. The
are applied and the process of decision-making is complete. rule's actions are then applied and the process of decision-making is
terminated.
5.2. Match All 5.2. Match All
The match all decision strategy is a process of going over the complete The match all decision strategy is defined as first scanning the
set of rules according to their defined order of priority and applying complete set of rules according to their defined order of priority and
the actions of each rule that the flow meets with the rule's then applying the actions of each rule that the flow meets with the
conditions. This matching strategy may in many cases mean that a number rule's conditions. This matching strategy may in many cases mean that a
of rules may meet the flow's parameters and all of their actions will number of rules may meet the flow's parameters and all of their actions
be applied. will be applied.
A Match All strategy may result in applying conflicting rules. Handling A Match All strategy may result in applying conflicting rules. Handling
conflicts is outside the scope of this draft. The implementers of QoS conflicts is outside the scope of this draft. The implementers of QoS
systems must provide proprietary conflict detection and avoidance or systems must provide proprietary conflict detection and avoidance or
resolution mechanisms. resolution mechanisms.
Snir, Ramberg, Strassner, Cohen expires October 2000 39
5.3. Decision Strategy example 5.3. Decision Strategy example
This section demonstrates both decision strategies and rule This section demonstrates both decision strategies and rule
prioritization. prioritization. The rules to be evaluated are shown in Figure 4 below.
Domain Domain
| |
+--Rule1 (priority 19) +--Rule1 (priority 19)
| |
+--NamedContainer1 (priority 5) +--NamedContainer1 (priority 5)
| | | |
| +--Rule 1.1 (priority 303) | +--Rule 1.1 (priority 3)
| | | |
| +--Rule 1.2 (priority 3) | +--Rule 1.2 (priority 33)
| |
+--Rule3 (priority 4) +--Rule3 (priority 4)
| |
+--Rule4 +--Rule4 (priority 2)
Figure 3: Decision Strategy example Figure 4: Decision Strategy example
For simplicity we assume that a Policy Decision Point needs to enforce NOTE: rule nesting is not defined in PCIM, but rather is defined in
all rules described above. this document
Snir, Ramberg, Strassner, Cohen expires September 2000 29 5.3.1 Default Operation using First Match Everywhere
The rules will be evaluated in the following order: For simplicity we assume that a Policy Decision Point needs to enforce
all rules described above. Therefore, the rules will be evaluated in
the following order:
1. Rule1 (higher priority between Rule1, namedContainer1 and Rule3 1. Rule1 (higher priority between Rule1, namedContainer1 and Rule3
2. Rule1.2 (higher priority between Rule1.1 and Rule1.2) 2. Rule1.2 (higher priority between Rule1.1 and Rule1.2)
3. Rule1.1 3. Rule1.1 (because its container has a higher priority than Rule3
4. Rule4 (nested in Rule 3) 4. Rule4 (because it is nested in Rule 3)
5. Rule3 5. Rule3
If the decision strategy of the domain is first match and it is If the decision strategy of the domain is first match and it is not
not overridden by NamedContainer1, the decision process stops once overridden by NamedContainer1, the decision process will stop once a
a rule's condition is matched. 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 Note: this equates priority with order. This is very different than how
over all rules according to the order above. this same example would work using priority as defined in [PCIM] (in
fact, this could not even be represented in [PCIM]). This is because of
the following two reasons:
- PCIM does not provide the ability to assign an order to a named
container. It therefore has no concept of ordering containers among
its policy rules
- PCIM has no concept of nested rules
Snir, Ramberg, Strassner, Cohen expires October 2000 40
5.3.2 Operation Using Other Decision Strategies
However, if the decision strategy of the domain is match all and it is
not overridden by NamedContainer1, the match all decision process will
run over all rules according to the order above.
If the decision strategy of the domain is first match and the decision If the decision strategy of the domain is first match and the decision
process of NamedContainer1 is match all, Rule1 will be evaluated process of NamedContainer1 is match all, Rule1 will be evaluated
first. If its condition matches, the decision process stops. Else, first. If its condition matches, the decision process stops. Else,
both Rules 1.1 and 1.2 will be evaluated and executed if their both Rules 1.1 and 1.2 will be evaluated and executed if their
condition match. If one of NamedContainer1 rule match, the decision conditions match. If one of NamedContainer1 rule match, the decision
process stops. Else Rules 3 and 4 will be evaluated using first match process stops. Else Rules 3 and 4 will be evaluated using first match
decision strategy. decision strategy.
If the decision strategy of the domain is match all and the decision If the decision strategy of the domain is match all and the decision
process of NamedContainer1 is first match, the decision process will process of NamedContainer1 is first match, the decision process will
evaluate Rule1 and continue to evaluate NamedContainer1 rules. Rules evaluate Rule1 and continue to evaluate NamedContainer1 rules. Rules
1.1 and 1.2 will be evaluated using first match strategy. The decision 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 process continues to evaluate rules 3 and 4 according to match-all
decision strategy. decision strategy.
Snir, Ramberg, Strassner, Cohen expires October 2000 41
6. Per Hop Behavior 6. Per Hop Behavior
A per-hop behavior (PHB) is a description of the externally observable A per-hop behavior (PHB) is a description of the externally observable
forwarding behavior of a DS node applied to a particular DS behavior 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 aggregate. A PHB is selected at a node by the DSCP in a received
received packet. A set of PHBs is enforced on a QoS domain. The set of packet. A set of PHBs is enforced on a QoS domain. The set of PHBs
PHBs share buffer and scheduler resources among them. The QoS share buffer and scheduler resources among them. The QPIM provides
informational model provides abstract placeholders for PHBs and for a abstract placeholders for PHBs and for a set of PHBs enforced together
set of PHBs enforced together on a QoS domain. Further specification of on a QoS domain. Further specification of PHBs and PHB sets are outside
PHBs and PHP sets are outside the scope of this document. the scope of this document; please refer to [PHBSET] for more
information.
6.1. PHB 6.1. PHBs
The qosPolicyPHB abstract class models a single PHB. The qosPolicyPHB The qosPolicyPHB abstract class models a single PHB. The qosPolicyPHB
class includes a single property, the DSCP value, an integer with class includes a single property, the DSCP value, which is an integer
allowed value of 0 to 63. with allowed values in the range of 0 to 63, inclusive. The
The qosPolicyPHB name will be defined using the cn property belonging qosPolicyPHB name will be defined using the cn property belonging
to the Policy class [PFCORE]. to the Policy class [PCIM].
Snir, Ramberg, Strassner, Cohen expires September 2000 30
6.1. PHB Set 6.1. PHB Sets
The qosPolicyPHBSet abstract class serves as a named container for The qosPolicyPHBSet abstract class serves as a named container for
instances of qosPolicyPHB classes. It models the set of PHBs enforced instances of qosPolicyPHB classes. It models the set of PHBs enforced
together on a QoS domain. Different PHB sets can be kept in a 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 repository. A PHB set enforced on the domain is specified by either a
reference from the qosPolicyDOmain class to one of the repository PHB reference from the qosPolicyDomain class to one of the PHB sets that
sets, or by directly attaching a PHB set to the domain class. are located in the reusable-object repository, or by directly including
the PHB set in the domain (the method for doing this is repository-
specific; for example, attachment could be used if the repository is a
directory).
To fine tune PHB parameters and to further restrict the namespace in 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 which a particular PHB is used, PHB sets can be referenced or augment
to qosNamedPolicyContainers. In order to maintain an end to end the semantics of qosNamedPolicyContainers. However, in order to
consistent behavior, overriding the domain's PHB set should be done maintain an end-to-end consistent behavior, overriding the domain's PHB
only to fine tune the parameters of each PHBs, and not to use different set should be done only to fine tune the parameters of each PHBs, and
set of PHBs altogether. not to use a different set of PHBs altogether.
Markers coloring packets of flows on domain ingress edges should pick a Markers coloring packets of flows on domain ingress edges should pick a
DS codepoint selecting one of the PHB enforced on the QoS domain. DSCP selecting one of the PHBs enforced on the QoS domain.
Snir, Ramberg, Strassner, Cohen expires October 2000 42
7. QoS Policy Class Inheritance 7. QoS Policy Class Inheritance
The following diagram illustrates the class hierarchy for the The following diagram illustrates the class hierarchy for the QPIM.
Policy schema classes (relevant Core classes are included): Relevant classes from the PCIM are also included for completeness:
top top
| |
+--policy (abstract) +--policy (abstract, [PCIM])
| | | |
| +--policyGroup | +--policyGroup ([PCIM])
| | | | | |
| | +--qosPolicyDomain | | +--qosPolicyDomain
| | | | | |
| | +--qosNamedPolicyContainer | | +--qosNamedPolicyContainer
| | | |
| +--policyRule ([PCIM])
| | | |
| +--policyRule | +--policyCondition ([PCIM])
| | | | |
| +--policyRuleConditionAssociation | | +--policyTimePeriodCondition ([PCIM])
| | | | |
| +--policyRuleActionAssociation | | +--vendorPolicyCondition ([PCIM])
| |
| +--policyConditionInstance
| |
| +--policyActionInstance
| |
| +--policyInstance
| |
| |
(Diagram continued in next page)
Snir, Ramberg, Strassner, Cohen expires September 2000 31
(Diagram continued from previous page)
| +--policyCondition
| | | | | |
| | +--qosPolicySimpleCondition | | +--qosPolicySimpleCondition
| | | |
| +--policyAction
| | |
| | +--vendorPolicyAction ([PCIM])
| | |
| | +-- qosPolicyPRAction
| | |
| | +-- qosPolicyRSVPAction
| | |
| | +-- qosPolicyRSVPSignalCtrlAction
| | |
| | +-- qosPolicyRSVPInstallAction
| | | |
| +--qosPolicyVariable | +--qosPolicyVariable
| | | |
| |
| +--qosPolicyValue(abstract) | +--qosPolicyValue(abstract)
| | | | | |
| | +--qosPolicyIPv4AddrValue | | +--qosPolicyIPv4AddrValue
| | | | | |
| | +--qosPolicyIPv6AddrValue | | +--qosPolicyIPv6AddrValue
| | | | | |
| | +--qosPolicyMACAddrValue | | +--qosPolicyMACAddrValue
| | | | | |
| | +--qosPolicyStringValue | | +--qosPolicyStringValue
| | | | | |
| | +--qosPolicyBitStringValue | | +--qosPolicyBitStringValue
| | | | | |
(Diagram continued in next page)
Snir, Ramberg, Strassner, Cohen expires October 2000 43
(Diagram continued from previous page)
top
|
+--policy (abstract, [PCIM])
| |
| +--qosPolicyValue(abstract, continued from previous page)
| | |
| | +--qosPolicyDNValue | | +--qosPolicyDNValue
| | | | | |
| | +--qosPolicyAttributeValue | | +--qosPolicyAttributeValue
| | | | | |
| | +--qosPolicyIntegerValue | | +--qosPolicyIntegerValue
| | | |
| +-- qosPolicyMeter | +-- qosPolicyMeter
| | | |
| +-- qosPolicyPRTrfcProf | +-- qosPolicyPRTrfcProf
| | | |
| +-- qosPolicyRSVPTrfcProf | +-- qosPolicyRSVPTrfcProf
| | | |
| +-- qosPolicyPHBSet (abstract) | +-- qosPolicyPHBSet (abstract)
| | | |
| +-- qosPHB (abstract) | +-- qosPHB (abstract)
| |
+--policyActionAuxClass +--CIM_ManagedSystemElement (abstract)
| |
| +-- qosPolicyPRAction
| |
| +-- qosPolicyRSVPAction
| |
| +-- qosPolicyRSVPSignalCtrlAction
| |
| +-- qosPolicyRSVPInstallAction
| |
+--policyRepository +--CIM_LogicalElement (abstract)
|
+--CIM_System (abstract)
|
+---CIM_AdminDomain (abstract)
|
+---PolicyRepository
Note: classes with a "qos" prefix are QoS Policy Schema classes. Figure 5. Class Inheritance Hierarchy for the QPIM
Snir, Ramberg, Strassner, Cohen expires September 2000 32 The reader is encouraged to read section 7 of [PCIM] in its entirety,
which defines the concepts of associations and aggregations. Ten
associations and aggregations are defined in the [PCIM]; note that the
QPIM does not define any new associations or aggregations:
8. Class definition: the Aggregation PolicyGroupInPolicyGroup
the Aggregation PolicyRuleInPolicyGroup
the Aggregation PolicyConditionInPolicyRule
the Aggregation PolicyRuleValidityPeriod
the Aggregation PolicyActionInPolicyRule
the Association PolicyConditionInPolicyRepository
the Association PolicyActionInPolicyRepository
the Weak Aggregation PolicyGroupInSystem
the Weak Aggregation PolicyRuleInSystem
the Aggregation PolicyRepositoryInPolicyRepository
Snir, Ramberg, Strassner, Cohen expires October 2000 44
8. Class Definitions
8.1. Class qosPolicyDomain 8.1. Class qosPolicyDomain
This class defines a single administrative QoS policy domain, and This class defines the root of a single administrative QoS policy
contains the domain's policy rules and definitions. This enables the domain, and contains the domain's policy rules and definitions. This
administrator to partition the set of QoS information into different enables the administrator to partition the set of QoS information into
domains, where each domain has a potentially different set of PHBs and different domains, where each domain has a potentially different set of
policies, access rules, decision strategy or other application of the PHBs and policies, access rules, decision strategy or other application
policy information organized in some fashion. The class definition is of the policy information organized in some fashion. The class
as follows: definition is as follows:
NAME qosPolicyDomain NAME qosPolicyDomain
DESCRIPTION A class that is the root of an administrative DERIVED FROM policyGroup (defined in [PCIM])
QoS policy domain, which resides in the ABSTRACT False
PolicyGroup container. It contains a group of
named policy containers.
DERIVED FROM PolicyGroup (Core)
PROPERTIES qpDomainName, qpPHBSet, qpPolicyRuleMatchMethod PROPERTIES qpDomainName, qpPHBSet, qpPolicyRuleMatchMethod
8.1.1. The Property qpDomainName 8.1.1. The Property qpDomainName
This property provides a user-friendly name for the QoS policy domain.
Its definition is as follows:
NAME qpDomainName NAME qpDomainName
DESCRIPTION A user-friendly name of the QoS policy domain.
SYNTAX String SYNTAX String
8.1.2. The Property qpPHBSet 8.1.2. The Property qpPHBSet
This property contains a reference to the PHB set defined for this
domain. Its definition is as follows:
NAME qpPHBSet NAME qpPHBSet
DESCRIPTION Reference to the PHB set defined for the domain. SYNTAX Reference to a PHBSet object
SYNTAX Reference
8.1.3. The Property qpPolicyRuleMatchMethod 8.1.3. The Property qpPolicyRuleMatchMethod
This property defines the decision strategy to be applied on this set
of QoS policy rules by policy servers. It is an enumerated integer that
defines two values, first match and match all. Please see section 5 of
this document for more information on these decision strategies. Its
definition is as follows:
NAME qpPolicyRuleMatchMethod NAME qpPolicyRuleMatchMethod
DESCRIPTION The decision strategy to be applied on this set SYNTAX Integer (ENUM) - {"FIRST MATCH " = 0; "MATCH ALL " = 1 }
of qos policy rules by policy servers.
SYNTAX Integer ENUM[] -
{"FIRST MATCH " = 1; "MATCH ALL " = 2 }
8.2. Class qosNamedPolicyContainer Snir, Ramberg, Strassner, Cohen expires October 2000 45
This class represents an administrative policy rule container. All 8.2. Class qosNamedPolicyContainer
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 This class represents an administratively-defined policy rule
container. All policies that are commonly administered are defined in a
particular qosNamedPolicyContainer. For example, an administrator could
define a set of policies that serve a certain goal, or service a
certain type of application, or that handle a certain type of flow or
device. Placing these policies in a qosNamedPolicyContainer that
resides in a particular qosPolicyDomain enables the administrator to
group different sets of policy rules that perform different types of
operations. It also enables an organization to partition policies
according to the administrator (or other entity) that manages the
policies. The class definition is as follows:
NAME qosNamedPolicyContainer NAME qosNamedPolicyContainer
DESCRIPTION A class that is a logical and physical DERIVED FROM policyGroup (defined in [PCIM])
container of policies. ABSTRACT False
DERIVED FROM PolicyGroup (Core) PROPERTIES qpPriority, qpNamedPolicyRuleMatchMethod
PROPERTIES qpPriority, qpPolicyRuleMatchMethod
8.2.1. The Property qpPriority 8.2.1. The Property qpPriority
This property is a non-negative integer that defines the priority of a
named group of rules. Conceptually, it is the priority of the
qosNamedPolicyContainer, and is used to determine when the policy rules
that the qosNamedPolicyContainer contains are evaluated with respect to
other policyRules, policyGroups, and other qosNamedPolicyContainters.
If two or more qosPolicyNamedContainer objects have the same priority,
this means that the order between these objects is of no importance,
but that they each be evaluated before other objects that have a
numerically lower priority. The attribute is defined as follows:
NAME qpPriority NAME qpPriority
DESCRIPTION The priority of a named group of rules compared SYNTAX Integer (must be non-negative)
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 8.2.2. The Property qpNamedPolicyRuleMatchMethod
NAME qpPolicyRuleMatchMethod This property is an enumerated integer that defines the decision
DESCRIPTION The decision strategy to be applied on this set strategy to be applied on this set of QoS policy rules by policy
of qos policy rules by policy servers. servers. Please see section 5 of this document for more information on
SYNTAX Integer ENUM[] - these decision strategies. The attribute is defined as follows:
{"FIRST MATCH " = 1; "MATCH ALL " = 2 }
NAME qpNamedPolicyRuleMatchMethod
SYNTAX Integer (ENUM) - {"FIRST MATCH " = 0; "MATCH ALL " = 1 }
Snir, Ramberg, Strassner, Cohen expires October 2000 46
8.3. Class qosPolicyPRAction 8.3. Class qosPolicyPRAction
This class defines Diff-Serv actions to be applied on a flow, including This class defines DiffServ actions to be applied on a flow or group of
marking of DSCP value, policing and shaping. flows, including the marking of a DSCP value, dropping, policing and
The class definition is as follows: shaping. The class definition is as follows:
NAME qosPolicyPRAction NAME qosPolicyPRAction
DESCRIPTION A class that defines Provisioning Diff-Serv DERIVED FROM policyAction (defined in [PCIM])
Traffic action to be applied on a specific flow
or group of flows.
DERIVED FROM PolicyAction (Core)
ABSTRACT False ABSTRACT False
PROPERTIES qpDirection, qpSetDSCPvalue, qpMeter, qpMeterScope, PROPERTIES qpDirection, qpSetDSCPvalue, qpMeter, qpMeterScope,
qpTrfcProf, qpOutOfProfileAction, qpTrfcProf, qpOutOfProfileAction,
qpOutOfProfileRemarkValue qpOutOfProfileRemarkValue
Snir, Ramberg, Strassner, Cohen expires September 2000 34
8.3.1. The Property qpDirection 8.3.1. The Property qpDirection
This property is an enumerated integer that defines whether the action
should be applied to incoming or/and outgoing interfaces. Note that
certain repositories MAY implement this enumeration in a different
form, as long as its semantics are preserved. For example, a directory
MAY implement this property as a multi-valued attribute, with the
attribute having the values IN and OUT. The attribute is defined as
follows:
NAME qpDirection NAME qpDirection
DESCRIPTION this Property defines the direction of the action, SYNTAX Integer (ENUM) - {IN=0, OUT=1, BOTH=2}
incoming or/and outgoing interfaces.
SYNTAX Integer [ENUM] {IN=0,OUT=1}
8.3.2. The Property qpSetDSCPvalue 8.3.2. The Property qpSetDSCPvalue
This property is an integer (constrained to the range 0-63, inclusive)
that defines the DSCP value of the (re)mark action. The attribute is
defined as follows:
NAME qpSetDSCPvalue NAME qpSetDSCPvalue
DESCRIPTION this Property defines DSCP value of the mark action. SYNTAX Integer (must be in the range 0-63, inclusive)
SYNTAX Integer
8.3.3. The Property qpMeter 8.3.3. The Property qpMeter
This property defines a reference to a qosPolicyMeter object used in
this provisioning action. The attribute is defined as follows:
NAME qpMeter NAME qpMeter
DESCRIPTION A reference to a qosPolicyMeter object used in this SYNTAX Reference to a qosPolicyMeter object
provisioning action.
SYNTAX Reference Snir, Ramberg, Strassner, Cohen expires October 2000 47
8.3.4. The Property qpMeterScope 8.3.4. The Property qpMeterScope
This property is an enumerated integer that defines whether this
metering action should be applied on a per-flow, per-interface, or per-
device basis. The attribute is defined as follows:
NAME qpMeterScope NAME qpMeterScope
DESCRIPTION An integer, enum, that defines the scope of the SYNTAX Integer (ENUM) ű {flow=0,interface=1 device=2}
metering action.
SYNTAX Integer enum [flow=0,interface=1 device=2]
8.3.5. The Property qpPRTrfcProf 8.3.5. The Property qpTrfcProf
NAME qpPRTrfcProf This property contains a reference to an object that defines the
DESCRIPTION This Property contains the DiffServ / provisioning DiffServ provisioning policing instruction value, defined as a
Policing instruction value, defined as a reference to a reference to a qosPolicyPRTrfcProf instance. The attribute is defined
qosPolicyPRTrfcProf entry. as follows:
SYNTAX Reference
NAME qpTrfcProf
SYNTAX Reference to a qosPolicyPRTrfcProf object
8.3.6. The Property qpOutOfProfileAction 8.3.6. The Property qpOutOfProfileAction
NAME qpOutOfProfileAction This property is an enumerated integer that defines the action to be
DESCRIPTION The action to be applied to out of profile applied to out of profile packets, as defined in the DiffServTrfcProf
packets, as defined in the DiffServTrfcProf entry. That entry contains values for each of the three types of
entry. actions that are present in this attribute: shaping, discarding, or
SYNTAX Integer [ENUM] {SHAPE=0,DISCARD=1,REMARK=2} remarking. The attribute is defined as follows:
Snir, Ramberg, Strassner, Cohen expires September 2000 35 NAME qpOutOfProfileAction
SYNTAX Integer (ENUM) - {SHAPE=0,DISCARD=1,REMARK=2}
8.3.7. The Property qpOutofProfileRemarkValue 8.3.7. The Property qpOutofProfileRemarkValue
This property is an integer that defines the DSCP value to be applied
to out of profile packets if the qpOutofProfile action is defined as
REMARK. The attribute is defined as follows:
NAME qpOutofProfileRemarkValue NAME qpOutofProfileRemarkValue
DESCRIPTION The DSCP value to be applied to out of profile SYNTAX Integer (constrained to the range 0-63, inclusive)
packets if the qpOutofProfile action is defined
as REMARK.
SYNTAX Integer
8.4. Class qosPolicyRSVPAction 8.4. Class qosPolicyRSVPAction
This class defines a policy action to be applied on an RSVP signaling This class defines a policy action to be applied on an RSVP signaling
messages that match the rule condition. message that matches the rule condition. The class definition is as
The class definition is as follows: follows:
Snir, Ramberg, Strassner, Cohen expires October 2000 48
NAME qosPolicyRSVPAction NAME qosPolicyRSVPAction
DESCRIPTION A class that defines an RSVP action to be DERIVED FROM policyAction (defined in [PCIM])
performed if a certain rule's condition is met.
DERIVED FROM PolicyAction (Core)
ABSTRACT False ABSTRACT False
PROPERTIES qpRSVPDirection, qpRSVPMessageType, qpRSVPService,
qpRSVPStyle, qpRSVPInstallAction, qpRSVPCtrlAction,
qpRSVPMeter, qpRSVPMeterScope, qpRSVPTrfcProf
PROPERTIES qpDirection, qpRSVPMessageType[], qpRSVPService[], 8.4.1. The Property qpRSVPDirection
qpRSVPStyle[], qpRSVPInstallAction, qpRSVPCtrlAction,
qpMeter, qpMeterScope, qpRSVPTrfcProf,
8.4.1. The Property qpDirection This property is an enumerated integer, and defines whether the action
is to be applied to incoming or/and outgoing interfaces. Note that
certain repositories MAY implement this enumeration in a different
form, as long as its semantics are preserved. For example, a directory
MAY implement this property as a multi-valued attribute, with the
attribute having the values IN and OUT. The attribute is defined as
follows:
NAME qpDirection NAME qpRSVPDirection
DESCRIPTION this Property defines the direction of the action, SYNTAX Integer (ENUM) - {IN=0,OUT=1,BOTH=2}
incoming or/and outgoing interfaces.
SYNTAX Integer [ENUM] {IN=0,OUT=1}
8.4.2. The Property qpRSVPMessageType 8.4.2. The Property qpRSVPMessageType
This property is an enumerated integer, and defines different values
that limit the scope of the action to be enforced to specific types of
RSVP messages. The attribute is defined as follows:
NAME qpRSVPMessageType NAME qpRSVPMessageType
DESCRIPTION this Property limits the scope of the action to be SYNTAX Integer (ENUM) - {Path=0 Resv=1 ResvErr=2 PathErr=3}
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 8.4.3. The Property qpRSVPStyle
NAME qpRSVPStyle This property is an enumerated integer, and defines different values
DESCRIPTION this Property limits the scope of the action to be that limit the scope of the action to be enforced to RSVP Requests with
enforced only on RSVP Requests with the specified the specified reservation style. The attribute is defined as follows:
reservation style.
SYNTAX Integer [ENUM] {SE=0 FF=1 WF=2}
Snir, Ramberg, Strassner, Cohen expires September 2000 36 NAME qpRSVPStyle
SYNTAX Integer (ENUM) - {SE=0 FF=1 WF=2}
8.4.4. The Property qpRSVPServiceType 8.4.4. The Property qpRSVPServiceType
This property is an enumerated integer, and defines different values
that limit the scope of the action to be enforced to RSVP Requests
asking for specified integrated service type. The attribute is defined
as follows:
NAME qpRSVPServiceType NAME qpRSVPServiceType
DESCRIPTION this Property limits the scope of the action to be SYNTAX Integer (ENUM) -
enforced only on RSVP Requests asking for specified {ControlledLoad=0, GuaranteedService=1, NULL=2}
integrated service type.
SYNTAX Integer [ENUM] Snir, Ramberg, Strassner, Cohen expires October 2000 49
{ControlledLoad =1 , GuaranteedService =2, NULL=3}
8.4.5. The Property qpRSVPInstallAction 8.4.5. The Property qpRSVPInstallAction
This property is a reference to a qosPolicyRSVPInstallAction object.
This object is used in conjunction with the RSVP reservation, and
defines detailed control for COPS install decisions (defined in
[COPS]). The attribute is defined as follows:
NAME qpRSVPInstallAction NAME qpRSVPInstallAction
DESCRIPTION A reference to a qpRSVPInstallAction object used in SYNTAX Reference to a qosPolicyRSVPInstallAction object
conjunction with the RSVP reservation.
SYNTAX Reference
8.4.6. The Property qpRSVPCtrlAction 8.4.6. The Property qpRSVPCtrlAction
This property is a reference to a qosPolicyRSVPSignalCtrlAction object.
This object is used in conjunction with the RSVP reservation, and
defines detailed control on the signaling protocol behavior itself.
The information carried in RSVP messages can be modified using this
action, as well as the RSVP forwarding behavior. The attribute is
defined as follows:
NAME qpRSVPCtrlAction NAME qpRSVPCtrlAction
DESCRIPTION A reference to a qpRSVPCtrlAction object used in SYNTAX Reference to a qosPolicyRSVPSignalCtrlAction object
conjunction with the RSVP reservation.
SYNTAX Reference
8.4.7. The Property qpMeter 8.4.7. The Property qpRSVPMeter
NAME qpMeter
DESCRIPTION A reference to a qosPolicyMeter object used in this
RSVP action.
SYNTAX Reference
8.4.8. The Property qpMeterScope This property is a reference to a qosPolicyMeter object. This object is
NAME qpMeterScope used in conjunction with the RSVP reservation, and defines the detailed
DESCRIPTION An integer, enum, that defines the scope of the definition of the meter characteristics. The attribute is defined as
metering action. follows:
SYNTAX Integer enum [flow=0,interface=1 device=2]
NAME qpRSVPMeter
SYNTAX Reference to a qosPolicyMeter object
8.4.8. The Property qpRSVPMeterScope
This property is an enumerated integer that defines the scope of the
metering action to be on a per-flow, per-interface, or per-device
basis. The attribute is defined as follows:
NAME qpRSVPMeterScope
SYNTAX Integer (ENUM) ű {flow=0,interface=1 device=2}
Snir, Ramberg, Strassner, Cohen expires October 2000 50
8.4.9. The Property qpRSVPTrfcProf 8.4.9. The Property qpRSVPTrfcProf
NAME qpRSVPTrfcProf This property is a reference to a qosPolicyRSVPTrfcProf object, which
DESCRIPTION A reference to RSVPTrfcProf object that define the defines an IntServ RSVP Traffic profile. Values of RSVP traffic
traffic profile compared with TSPEC or FLOWSPEC profiles are compared against Traffic specification (TSPEC) and QoS
objects, or with value kept in meter. Reservation requests (FLOWSPEC) carried in RSVP requests. The attribute
SYNTAX Reference is defined as follows:
Snir, Ramberg, Strassner, Cohen expires September 2000 37 NAME qpRSVPTrfcProf
SYNTAX Reference to a qosPolicyRSVPTrfcProf object
8.5. Class qosPolicyPRTrfcProf 8.5. Class qosPolicyPRTrfcProf
A provisioning Traffic profile is a class that carries the policer or 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. shaper rate values to be enforced on a flow or a set of flows. The
class definition is as follows:
The class definition is as follows:
NAME qosPolicyPRTrfcProf NAME qosPolicyPRTrfcProf
DESCRIPTION A class that carries the policer or shaper rate DERIVED FROM policy (defined in [PCIM])
values to be enforced on a flow or a set of flows.
DERIVED FROM Policy (Core)
ABSTRACT False ABSTRACT False
PROPERTIES qpPRRate, qpPRNormalBurst, qpPRExcessBurst
PROPERTIES qpPRRate, qpPRNormalBurst,
qpPRExcessBurst
8.5.1. The Property qpPRRate 8.5.1. The Property qpPRRate
This is a non-negative integer that defines the token rate in bits per
second. A rate of zero means that all packets will be out of profile.
The attribute is defined as follows:
NAME qpPRRate NAME qpPRRate
DESCRIPTION The token rate. It is specified in units of SYNTAX Integer (must be non-negative)
bits/second. A rate of zero means that all packets
will be out of profile.
SYNTAX Integer
8.5.2. The Property qpPRNormalBurst 8.5.2. The Property qpPRNormalBurst
This attribute is an integer that defines the normal size of a burst
measured in bytes. The attribute is defined as follows:
NAME qpPRNormalBurst NAME qpPRNormalBurst
DESCRIPTION The normal size of a burst measured in bytes SYNTAX Integer (must be non-negative)
SYNTAX Integer
8.5.3. The Property qpPRExcessBurst 8.5.3. The Property qpPRExcessBurst
This attribute is an integer that defines the excess size of a burst
measured in bytes. The attribute is defined as follows:
NAME qpPRExcessBurst NAME qpPRExcessBurst
DESCRIPTION The excess size of a burst measured in bytes SYNTAX Integer (must be non-negative)
SYNTAX Integer
Snir, Ramberg, Strassner, Cohen expires October 2000 51
8.6. Class qosPolicyRSVPTrfcProf 8.6. Class qosPolicyRSVPTrfcProf
This class represents an IntServ RSVP Traffic profile. Values of RSVP This class represents an IntServ RSVP Traffic profile. Values of RSVP
traffic profiles are compared against Traffic specification (TSPEC) and traffic profiles are compared against Traffic specification (TSPEC) and
QoS Reservation requests (FLOWSPEC) carried in RSVP requests. Traffic QoS Reservation requests (FLOWSPEC) carried in RSVP requests. Traffic
profiles can be reusable objects or ad-hoc. profiles can be reusable objects or ad-hoc. The class definition is as
follows:
The class definition is as follows:
NAME qosPolicyRSVPTrfcProf NAME qosPolicyRSVPTrfcProf
DESCRIPTION A class that defines rate limiting values for QoS DERIVED FROM policy (defined in [PCIM])
requests for a flow or a set of flow via RSVP
Snir, Ramberg, Strassner, Cohen expires September 2000 38
DERIVED FROM Policy (Core)
ABSTRACT False ABSTRACT False
PROPERTIES qpRSVPTokenRate, qpRSVPPeakRate, PROPERTIES qpRSVPTokenRate, qpRSVPPeakRate,
qpRSVPBucketSize, qpRSVPResvRate, qpRSVPResvSlack, qpRSVPBucketSize, qpRSVPResvRate, qpRSVPResvSlack,
qpRSVPSessionNum, qpMinPolicedUnit, qpMaxPktSize qpRSVPSessionNum, qpMinPolicedUnit, qpMaxPktSize
8.6.1. The Property qpRSVPTokenRate 8.6.1. The Property qpRSVPTokenRate
This property is a non-negative integer that defines the token rate
parameter, measured in bits per second. The attribute is defined as
follows:
NAME qpRSVPTokenRate NAME qpRSVPTokenRate
DESCRIPTION Token Rate parameter, measured in bits/sec SYNTAX Integer (must be non-negative)
SYNTAX Integer
8.6.2. The Property qpRSVPPeakRate 8.6.2. The Property qpRSVPPeakRate
This property is a non-negative integer that defines the peak rate
parameter, measured in bits per second. The attribute is defined as
follows:
NAME qpRSVPPeakRate NAME qpRSVPPeakRate
DESCRIPTION Peak rate parameter, measured is bits/sec SYNTAX Integer (must be non-negative)
SYNTAX Integer
8.6.3. The Property qpRSVPBucketSize 8.6.3. The Property qpRSVPBucketSize
This property is a non-negative integer that defines the token bucket
size parameter, measured in bits per second. The attribute is defined
as follows:
NAME qpRSVPBucketSize NAME qpRSVPBucketSize
DESCRIPTION Bucket Size, measured in bytes SYNTAX Integer (must be non-negative)
SYNTAX Integer
Snir, Ramberg, Strassner, Cohen expires October 2000 52
8.6.4. The Property qpRSVPResvRate 8.6.4. The Property qpRSVPResvRate
This property is a non-negative integer that defines the RSVP rate (R-
Spec) in the RSVP Guaranteed service reservation. It is measured in
bits per second. The attribute is defined as follows:
NAME qpRSVPResvRate NAME qpRSVPResvRate
DESCRIPTION Defines RSVP Rate - R-Spec parameter in the RSVP SYNTAX Integer (must be non-negative)
Guaranteed service reservation. Measured in bits/sec.
SYNTAX Integer
8.6.5. The Property qpRSVPResvSlack 8.6.5. The Property qpRSVPResvSlack
This property is a non-negative integer that defines the RSVP slack
term in the RSVP Guaranteed service reservation. It is measured in
microseconds. The attribute is defined as follows:
NAME qpRSVPResvSlack NAME qpRSVPResvSlack
DESCRIPTION Defines RSVP Slack Term - [RSVP] Flowspec::xspec_S SYNTAX Integer (must be non-negative)
parameter in the RSVP Guaranteed service reservation
(microseconds).
SYNTAX Integer
8.6.6. The Property qpRSVPSessionNum 8.6.6. The Property qpRSVPSessionNum
NAME qpRSVPSessionNum This property is a non-negative integer that defines the total number
DESCRIPTION The total number of allowed active RSVP sessions. of allowed RSVP sessions that can be active at any given time. The
SYNTAX Integer attribute is defined as follows:
Snir, Ramberg, Strassner, Cohen expires September 2000 39 NAME qpRSVPSessionNum
SYNTAX Integer (must be non-negative)
8.6.7. The Property qpMinPolicedUnit 8.6.7. The Property qpMinPolicedUnit
This property is a non-negative integer that defines the minimum RSVP
policed unit, measure in bytes. The attribute is defined as follows:
NAME qpMinPolicedUnit NAME qpMinPolicedUnit
DESCRIPTION Defines the RSVP minimum policed unit, measured SYNTAX Integer (must be non-negative)
in bytes.
SYNTAX Integer
8.6.8. The Property qpMaxPktSize 8.6.8. The Property qpMaxPktSize
This property is a non-negative integer that defines the maximum
allowed packet size for RSVP messages, measure in bytes. The attribute
is defined as follows:
NAME qpMaxPktSize NAME qpMaxPktSize
DESCRIPTION Defines RSVP maximum allowed packet size, measured SYNTAX Integer (must be non-negative)
in bytes.
SYNTAX Integer Snir, Ramberg, Strassner, Cohen expires October 2000 53
8.7. Class qosPolicyRSVPSignalCtrlAction 8.7. Class qosPolicyRSVPSignalCtrlAction
This class extends the functionality of the qosPolicyRSVPAction class This class extends the functionality of the qosPolicyRSVPAction class
by adding detailed control on the signaling protocol behavior itself. by adding detailed control on the signaling protocol behavior itself.
The information carried in RSVP messages can be modified using this The information carried in RSVP messages can be modified using this
action, as well as the RSVP forwarding behavior. This class can be action, as well as the RSVP forwarding behavior.
extended to support replacement of additional object in RSVP messages,
beyond replacement of DCLASS and PREEMPTION object replacement defined Since the purpose of this is to augment the behavior specified by the
below. qosPolicyRSVPAction class, this class SHOULD be used with a
This class SHOULD be aggregated to a qosPolicyRSVPAction object. qosPolicyRSVPAction object, and SHOULD NOT be used by itself.
This class can be extended to support replacement of additional object
in RSVP messages, beyond replacement of DCLASS and PREEMPTION object
replacement defined below.
The class definition is as follows:
NAME qosPolicyRSVPSignalCtrlAction NAME qosPolicyRSVPSignalCtrlAction
DESCRIPTION Actions modifying the behavior and content of RSVP DERIVED FROM policyAction (defined in [PCIM])
Signaling flows.
DERIVED FROM policyAction
ABSTRACT False ABSTRACT False
PROPERTIES qpForwardingMode, qpSendError, qpReplaceDSCP,
PROPERTIES qpForwardingMode, qpSendError, qpReplacePreemptionPriority, qpReplaceDefendingPriority
qpReplaceDSCP,qpReplacePreemptionPriority,
qpReplaceDefendingPriority
8.7.1. The Property qpForwardingMode 8.7.1. The Property qpForwardingMode
This Property controls forwarding of RSVP messages. If the mode is set This property is an enumerated integer that controls the forwarding of
to proxy, an RSVP Path messages is not forwarded and a Resv message is RSVP messages. If the mode is set to proxy, RSVP Path messages are not
returned as if the Resv was returned by the receiver. forwarded and a Resv message is returned as if the Resv was returned by
the receiver. Otherwise, RSVP Path messages are forwarded. The
attribute is defined as follows:
NAME qpForwardingMode NAME qpForwardingMode
DESCRIPTION Defines whether to forward or return RSVP signaling. SYNTAX Integer (ENUM) - {Forward=0 , Proxy=1}
SYNTAX Integer [ENUM] {Forward =1 , Proxy =2}
Snir, Ramberg, Strassner, Cohen expires September 2000 40
8.7.2. The Property qpSendError 8.7.2. The Property qpSendError
This Property controls generation of Resv-Err and Path-Err messages as This property is an enumerated integer and controls the generation of
defined in [COPSRSVP]. Resv-Err and Path-Err messages as defined in [COPSRSVP]. The attribute
is defined as follows:
NAME qpSendError NAME qpSendError
DESCRIPTION Defines whether to send RSVP error and warning
message.
SYNTAX Integer {No=0, Yes=1} SYNTAX Integer {No=0, Yes=1}
Snir, Ramberg, Strassner, Cohen expires October 2000 54
8.7.3. The Property qpReplaceDSCP 8.7.3. The Property qpReplaceDSCP
This property is a non-negative integer that allows the replacement of
a DCLASS object carrying a DSCP value in an RSVP message. The attribute
specifies the DSCP value to be replaces, and is defined as follows:
NAME qpReplaceDSCP NAME qpReplaceDSCP
DESCRIPTION allows the replacement of a DCLASS object carrying SYNTAX Integer (constrained to the range 0-63, inclusive)
DSCP value in RSVP message.
SYNTAX Integer
8.7.4. The Property qpReplacePreemptionPriority 8.7.4. The Property qpReplacePreemptionPriority
This Property allows replacing or adding of preemption priority This property is a non-negative integer that is used to replace or add
[RSVP_PREEMP] object to RSVP messages. a preemption priority object (defined in [RSVP_PREEMP]) to RSVP
messages. The attribute is defined as follows:
NAME qpReplacePreemptionPriority NAME qpReplacePreemptionPriority
DESCRIPTION A positive integer value specifying the preemption SYNTAX Integer (must be non-negative)
Priority that should be carried by RSVP messages.
SYNTAX Integer
8.7.5. The Property qpReplaceDefendingPriority 8.7.5. The Property qpReplaceDefendingPriority
This Property allows replacing or adding of preemption priority This property is a non-negative integer that is used to replace or add
[RSVP_PREEMP] object to RSVP messages. a preemption priority object (defined in [RSVP_PREEMP]) to RSVP
messages. It specifies the defending priority within the preemption
object. The attribute is defined as follows:
NAME qpReplaceDefendingPriority NAME qpReplaceDefendingPriority
DESCRIPTION This Property allows replacing or adding of SYNTAX Integer (must be non-negative)
preemption priority [RSVP_PREEMP] object to RSVP
messages. It specifies the defending priority within
the preemption object.
SYNTAX Integer
8.8. Class qosPolicyRSVPInstallAction 8.8. Class qosPolicyRSVPInstallAction
This class extends the functionality of the qosPolicyRSVPAction class This class extends the functionality of the qosPolicyRSVPAction class
by adding detailed control on COPS Install decisions [COPS]. This by adding detailed control for COPS Install decisions (defined in
action allows assigning a preemption priority with an RSVP request, to [COPS]). This action allows assigning a preemption priority with an
provide a device with information which RSVP requests to accept in case RSVP request, to provide a device with information which RSVP requests
of admission failures. This actions specifies a DSCP value to set on to accept in case of admission failures. This action specifies a DSCP
the flow RSVP is requesting QoS for. This class should be extended when value (which provides an associated level of QoS) to set on the flow
additional install decisions need to be controlled. that RSVP is requesting.
Snir, Ramberg, Strassner, Cohen expires September 2000 41 Since the purpose of this is to augment the behavior specified by the
qosPolicyRSVPAction class, this class SHOULD be used with a
qosPolicyRSVPAction object, and SHOULD NOT be used by itself.
This class SHOULD be attached to an object together with This class can be extended to support additional install decisions that
qosPolicyRSVPAction. need to be controlled.
class definition is as follows: The class definition is as follows:
Snir, Ramberg, Strassner, Cohen expires October 2000 55
NAME qosPolicyRSVPInstallAction NAME qosPolicyRSVPInstallAction
DESCRIPTION A class that defines a actions to be DERIVED FROM policyAction (defined in [PCIM])
administrated on a the PEP.
DERIVED FROM policyAction
ABSTRACT False ABSTRACT False
PROPERTIES qpSetDSCPValue, qpSetPreemptionPriority, PROPERTIES qpSetDSCPValue, qpSetPreemptionPriority,
qpSetDefendingPriority qpSetDefendingPriority
8.8.1. The Property qpSetDSCPValue 8.8.1. The Property qpSetDSCPValue
This property is a non-negative integer that defines the setting of a
DSCP value in the device. In other words, this attribute controls the
remarking (by the device) of the flow signaled by the RSVP request. The
attribute is defined as follows:
NAME qpSetDSCPValue NAME qpSetDSCPValue
DESCRIPTION Defines the value the PEP PROPERTIES use to remark SYNTAX Integer (constrained to the range 0-63, inclusive)
the flow signaled by the RSVP requests.
SYNTAX Integer
8.8.2. The Property qpSetDefendingPriority 8.8.2. The Property qpSetDefendingPriority
This Property allows setting the preemption priority [RSVP_PREEMP] of This property is a non-negative integer, and is used to set the
RSVP flows. defending priority within the preemption object (defined in
[RSVP_PREEMP]) of RSVP flows. The attribute is defined as follows:
NAME qpSetDefendingPriority NAME qpSetDefendingPriority
DESCRIPTION This Property allows setting the SYNTAX Integer (must be non-negative)
preemption priority [RSVP_PREEMP] of RSVP flows.
It specifies the defending priority within
the preemption object.
SYNTAX Integer
8.8.3. The Property qpSetPreemptionPriority 8.8.3. The Property qpSetPreemptionPriority
This Property allows setting the preemption priority [RSVP_PREEMP] of This property is a non-negative integer, and is used to set the
RSVP flows. preemption priority [RSVP_PREEMP] of RSVP flows. The attribute is
defined as follows:
NAME qpSetPreemptionPriority NAME qpSetPreemptionPriority
DESCRIPTION This Property allows setting the SYNTAX Integer (must be non-negative)
preemption priority [RSVP_PREEMP] of RSVP flows.
SYNTAX Integer
Snir, Ramberg, Strassner, Cohen expires September 2000 42
8.9. Class qosPolicySimpleCondition (Aux) 8.9. Class qosPolicySimpleCondition (Aux)
A simple condition is composed of a <Variable> an <Operator> and A simple condition is composed of an ordered triplet:
<Value> triplet. The operator used in all definition in this draft is <Variable> <Operator> <Value>
The operator used in all condition definitions in this draft is
the 'match' operator. Such simple conditions are evaluated by answering the 'match' operator. Such simple conditions are evaluated by answering
the question: Does <variable> match <value>? The operator Property can the question: Does <variable> match <value>? The operator property can
be extended to support other relations between variable and values. be extended to support other relations between variable and values.
Simple conditions are building blocks for more complex Boolean Simple conditions are building blocks for more complex Boolean
conditions. conditions. The qosPolicySimpleCondition class is derived from the
The qosPolicySimpleCondition is derived from the policyCondition class policyCondition class in [PCIM]. Simple conditions can be kept in
of the Core schema [PFSCHEMA]. Simple conditions can be kept in repositories for reuse.
repositories for reuse. For a complete explanation of the use of simple
conditions see the relevant section. Snir, Ramberg, Strassner, Cohen expires October 2000 56
The class definition is as follows: The class definition is as follows:
NAME qosPolicySimpleCondition NAME qosPolicySimpleCondition
DESCRIPTION A class that represents a single Boolean condition. A DERIVED FROM policyCondition (defined in [PCIM])
group of conditions make up a Boolean expression.
A single condition is made of the triple <Variable -
relation - Value>
DERIVED FROM PolicyCondition (Core)
ABSTRACT False ABSTRACT False
All classes derived from qosPolicyVariable and qosPolicyValue defined
below can be attached as well.
PROPERTIES qpOperator, qpVariableAtom, qpValueAtom PROPERTIES qpOperator, qpVariableAtom, qpValueAtom
8.9.1. The Property qpOperator 8.9.1. The Property qpOperator
This property is a string that defines the relation between a variable
and a value. The default value is ˘match÷, which has the semantics of
'belong to' or 'equal'. The attribute is defined as follows:
NAME qpOperator NAME qpOperator
DESCRIPTION The relation between a variable and a value.
SYNTAX String SYNTAX String
DEFAULT VALUE 'match'
8.9.2. The Property qpVariableAtom 8.9.2. The Property qpVariableAtom
This property is a reference to an object that defines the variable to
be used in a QoS policy condition. The referenced object SHOULD be a
subclass of the qosPolicyVariable class. The attribute is defined as
follows:
NAME qpVariableAtom NAME qpVariableAtom
DESCRIPTION A reference to a variable SYNTAX Reference to an object that is a subclass of the
SYNTAX Reference qosPolicyVariable class
8.9.3. The Property qpValueAtom 8.9.3. The Property qpValueAtom
NAME qpValueAtom This property is a reference to an object that defines the value to be
DESCRIPTION A reference to a value. used in a QoS policy condition. The referenced object SHOULD be a
SYNTAX Reference subclass of the qosPolicyValue class. The attribute is defined as
follows:
Snir, Ramberg, Strassner, Cohen expires September 2000 43 NAME qpValueAtom
SYNTAX Reference to an object that is a subclass of the
qosPolicyValue class
8.10. Class qosPolicyVariable 8.10. Class qosPolicyVariable
Variables are used for building individual conditions. The variable Variables are used for building individual conditions. The variable
specifies the Property of a flow that should be matched when evaluating specifies the property of a flow that should be matched when evaluating
the condition. the condition. However, not every combination of a variable and a value
creates a meaningful condition. A source IP address variable can not be
matched against a value that specifies a port number. A given variable
selects the set of matchable value types.
Not every combination of a variable and a value creates a meaningful Snir, Ramberg, Strassner, Cohen expires October 2000 57
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 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- 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 port variable limits the set of values to represent integers to the
range of 0-65535. Integers outside this range can not be matched to the range of 0-65535. Integers outside this range can not be matched to the
16 bits port entity. 16 bits port entity.
The qosPolicyVariable class is an auxiliary class to allow attachment The class definition is as follows:
of variables to policy conditions for efficient LDAP
retrieval. The class definition is as follows:
NAME qosPolicyVariable NAME qosPolicyVariable
DESCRIPTION A class that represents a single variable in a DERIVED FROM policy (defined in [PCIM])
Boolean condition
DERIVED FROM Policy (Core)
ABSTRACT False ABSTRACT False
PROPERTIES qpVariableName, qpValueTypes, qpVariableDescription,
PROPERTIES qpVariableName, qpValueTypes[] QpValueConstraints
qpVariableDescription,
qpValueConstraints[ref qosPolicyValue [0..n]]
8.10.1. The Property qpVariableName 8.10.1. The Property qpVariableName
NAME qpVariableName This property is a string that is a unique name for the variable. This
DESCRIPTION A unique name for the variable. is very important, because the QPIM defines a correlation between its
SYNTAX String pre-defined variable names and their logical bindings. This correlation
was defined earlier in Table 2. The attribute is defined as follows:
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
+-----------------+---------------------------------------------------+
|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
+-----------------+---------------------------------------------------+
| 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 NAME qpVariableName
SYNTAX String, defined in the following table:
8.10.2 The Property qpValueTypes 8.10.2 The Property qpValueTypes
This Property specifies an unordered list of possible value types that This property is a string that specifies an unordered list of possible
can be used in a simple condition together with this variable. The value types that can be used in a simple condition together with this
value types are specified by their class names. The list of class names variable. The value types are specified by their class names. The list
allow efficient retrieval of the possible set of relevant values from a of class names allows efficient retrieval of the possible set of
repository. relevant values from a repository, and was defined earlier in Table 3.
The attribute is defined as follows:
NAME qpValueTypes NAME qpValueTypes
DESCRIPTION A list of class names of possible value types that
can be associated with this variable in a condition
SYNTAX String 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
+-----------------+---------------------------------------------------+
| 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 8.10.3. The Property qpVariableDescription
This property is a string that provides a textual description of the
variable. The attribute is defined as follows:
NAME qpVariableDescription NAME qpVariableDescription
DESCRIPTION A textual description of the variable
SYNTAX String SYNTAX String
Snir, Ramberg, Strassner, Cohen expires October 2000 58
8.10.4. The Property qpValueConstraints 8.10.4. The Property qpValueConstraints
This property is a set of references to objects serving as constraints
for this variable. This attribute is defined as follows:
NAME qpValueConstraints NAME qpValueConstraints
DESCRIPTION A list of references of the value objects SYNTAX Set of references to objects that constrain this variable
serving as constraints for this variable.
SYNTAX Reference
8.11. Class qosPolicyValue 8.11. Class qosPolicyValue
This abstract class used for This is an abstract class that serves as the base class for all
defining values and constants used in policy conditions. The class subclasses that are used to define value objects in the QPIM. It is
definition is as follows: used for defining values and constants used in policy conditions. The
class definition is as follows:
NAME qosPolicyValue NAME qosPolicyValue
DESCRIPTION This class is used as an abstract class for defining DERIVED FROM policy (defined in [PCIM])
values and constants used in policy conditions
DERIVED FROM Policy
ABSTRACT True ABSTRACT True
PROPERTIES PROPERTIES
Snir, Ramberg, Strassner, Cohen expires September 2000 47
8.12. Class qosPolicyIPv4AddrValue 8.12. Class qosPolicyIPv4AddrValue
This class is used to provide a List of Ipv4Addresses and address range This class is used to provide a list of IPv4Addresses, hostnames and
values. The class definition is as follows: address range values. The class definition is as follows:
NAME qosPolicyIPv4AddrValue NAME qosPolicyIPv4AddrValue
DESCRIPTION This class is used to define a list of Ipv4 addresses
and address range values
DERIVED FROM qosPolicyValue DERIVED FROM qosPolicyValue
ABSTRACT False ABSTRACT False
PROPERTIES qpIPv4AddrList[] PROPERTIES qpIPv4AddrList
8.12.1. The Property qpIPv4AddrList 8.12.1. The Property qpIPv4AddrList
This Property provides an unordered list of strings each specifying a This Property provides an unordered list of strings, each specifying a
single Ipv4 address or a range of Ipv4 addresses. single IPv4 address, a hostname, or a range of IPv4 addresses. The ABNF
The ABNF definition [ABNF] of Ipv4 address is: definition [ABNF] of an IPv4 address is:
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
IPv4prefix = IPv4address "/" 1*2DIGIT
Ipv4prefix = Ipv4address "/" 1*2DIGIT IPv4range = IPv4address"-"IPv4address
IPv4maskedaddress = IPv4address","IPv4address
Ipv4range = Ipv4address".."Ipv4address Hostname (as defined in [NAMES])
Ipv4maskedaddress = Ipv4address","Ipv4address
Each string entry is either: Each string entry is either:
1. A single Ipv4address in dot notation as defined above.
Example: 121.1.1.2
2. A single Hostname. Hostname format follows the guidelines and
restrictions specified in [NAMES].
Example: www.bigcompany.com
1. A single Ipv4address in dot notation as defined above. Example: Snir, Ramberg, Strassner, Cohen expires October 2000 59
121.1.1.2 3. An IPv4range address range defined above, specified by a start
2. A single Hostname. Hostname format PROPERTIES follow guidelines and address in dot notation and an end address in dot notation,
restrictions specified in [NAMES]. Example: www.bigcompany.com separated by "-". The range includes all addresses between the
3. An Ipv4range address range defined above, specified by a start range's start and end addresses, including the start and end
address in dot notation and an end address in dot notation, separated addresses.
by "..". The range includes all addresses between the range's start and Example: 1.1.22.1-1.1.22.5
end addresses, including the start and end addresses. Example: 4. An IPv4maskedaddress address range defined above, specified by an
1.1.22.1..1.1.22.5 address and mask. The address and mask are represented in dot
4. An Ipv4maskedaddress address range defined above, specified by an notation separated by a comma ",".
address and mask. The address and mask are represented in dot notation Example: 2.3.128.0,255.255.248.0.
separated by a comma ",". Example: 2.3.128.0,255.255.248.0. 5. An IPv4prefix address range defined above specified by an address
5. An Ipv4prefix address range defined above specified by an address and a prefix length separated by "/".
and a prefix length separated by "/". Example: 2.3.128.0/15 Example: 2.3.128.0/15
NAME qpIPv4AddrList NAME qpIPv4AddrList
DESCRIPTION A list of IP addresses and IP address ranges.
SYNTAX String SYNTAX String
FORMAT IPv4address | hostname | IPv4addressrange |
FORMAT Ipv4address | hostname | Ipv4addressrange | IPv4maskedaddress | IPv4prefix
Ipv4maskedaddress | Ipv4prefix
Snir, Ramberg, Strassner, Cohen expires September 2000 48
8.13. Class qosPolicyIPv6AddrValue 8.13. Class qosPolicyIPv6AddrValue
This class is used to define a List of Ipv6 addresses and address range This class is used to define a list of IPv6 addresses, hostnames, and
values. The class definition is as follows: address range values. The class definition is as follows:
NAME qosPolicyIPv6AddrValue NAME qosPolicyIPv6AddrValue
DESCRIPTION This class is used to define a list of Ipv6
addresses and Ipv6 address range values.
DERIVED FROM qosPolicyValue DERIVED FROM qosPolicyValue
ABSTRACT False ABSTRACT False
PROPERTIES qpIPv6AddrList
PROPERTIES qpIPv6AddrList[]
8.13.1. The Property qpIPv6AddrList 8.13.1. The Property qpIPv6AddrList
This Property provides an unordered list of strings each specifying an This property provides an unordered list of strings, each specifying an
Ipv6 address or a range of Ipv6 addresses. Ipv6 address format IPv6 address, a hostname, or a range of IPv6 addresses. IPv6 address
definition uses the standard address format defined in [Ipv6]. format definition uses the standard address format defined in [IPv6].
The ABNF definition [ABNF] as specified in [Ipv6] is: The ABNF definition [ABNF] as specified in [IPv6] is:
IPv6address = hexpart [ ":" IPv4address ] IPv6address = hexpart [ ":" IPv4address ]
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
IPv6prefix = hexpart "/" 1*2DIGIT IPv6prefix = hexpart "/" 1*2DIGIT
hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ] hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
hexseq = hex4 *( ":" hex4) hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG hex4 = 1*4HEXDIG
IPv6range = IPv6address"-"IPv6address
IPv6maskedaddress = IPv6address","IPv6address
Hostname (as defines in [NAMES])
Ipv6range = Ipv6address".."Ipv6address Snir, Ramberg, Strassner, Cohen expires October 2000 60
Ipv6maskedaddress = Ipv6address","Ipv6address
Each string entry is either: Each string entry is either:
1. A single Ipv6address as defined above. 1. A single IPv6address as defined above.
2. A single Hostname. Hostname format PROPERTIES follow guidelines and 2. A single Hostname. Hostname format follows guidelines and
restrictions specified in [NAMES]. Example: www.bigcompany.com restrictions specified in [NAMES].
3. An Ipv6range address range, specified by a start address in dot 3. An IPv6range address range, specified by a start address in dot
notation and an end address in dot notation, separated by "..". The notation and an end address in dot notation, separated by "-".
range includes all addresses between the range's start and end The range includes all addresses between the range's start and end
addresses, including the start and end addresses. addresses, including the start and end addresses.
4. An Ipv4maskedaddress address range defined above specified by an 4. An IPv4maskedaddress address range defined above specified by an
address and mask. The address and mask are represented in dot notation address and mask. The address and mask are represented in dot
separated by a comma ",". notation separated by a comma ",".
5. A single Ipv6prefix as defined above. 5. A single IPv6prefix as defined above.
NAME qpIPv6AddrList NAME qpIPv6AddrList
DESCRIPTION A list of Ipv6 addresses and Ipv6 address
ranges.
SYNTAX String SYNTAX String
FORMAT IPv6address | hostname | IPv6addressrange |
Snir, Ramberg, Strassner, Cohen expires September 2000 49 IPv6maskedaddress | IPv6prefix
FORMAT IPv6address | hostname | Ipv6addressrange |
Ipv6maskedaddress | Ipv6prefix
8.14. Class qosPolicyMACAddrValue 8.14. Class qosPolicyMACAddrValue
This class is used to define a List of MAC addresses and MAC address This class is used to define a list of MAC addresses and MAC address
range values. The class definition is as follows: range values. The class definition is as follows:
NAME qosPolicyMACAddrValue NAME qosPolicyMACAddrValue
DESCRIPTION This class is used to define a list of MAC
addresses and MAC address range values.
DERIVED FROM qosPolicyValue DERIVED FROM qosPolicyValue
ABSTRACT False ABSTRACT False
PROPERTIES qpMACAddrList
PROPERTIES qpMACAddrList[]
8.14.1. The Property qpMACAddrList 8.14.1. The Property qpMACAddrList
This Property provides an unordered list of strings each specifying a This property provides an unordered list of strings, each specifying a
MAC address or a range of MAC addresses. 802 MAC address canonical MAC address or a range of MAC addresses. The 802 MAC address canonical
format is used: format is used. The ABNF definition [ABNF] is:
The ABNF definition [ABNF] is:
MACaddress = 1*4HEXDIG ":" 1*4HEXDIG ":" 1*4HEXDIG MACaddress = 1*4HEXDIG ":" 1*4HEXDIG ":" 1*4HEXDIG
MACmaskedaddress = MACaddress","MACaddress MACmaskedaddress = MACaddress","MACaddress
Each string entry is either: Each string entry is either:
1. A single MAC address. Example: 0000:00A5:0000 1. A single MAC address. Example: 0000:00A5:0000
2. A MACmaskedaddress address range defined specified by an address and 2. A MACmaskedaddress address range defined specified by an address
mask. The mask specifies the relevant bits in the address. Example: and mask. The mask specifies the relevant bits in the address.
0000:00A5:0000, FFFF:FFFF:0000 defines a range of MAC addresses in Example: 0000:00A5:0000, FFFF:FFFF:0000 defines a range of MAC
which the first 4 8-bit bytes are equal to 0000:00A5. addresses in which the first 4 8-bit bytes are equal to 0000:00A5.
NAME qpIPv6AddrList NAME qpMACAddrList
DESCRIPTION A list of MAC addresses and MAC address ranges.
SYNTAX String SYNTAX String
FORMAT MACaddress | MACmaskedaddress FORMAT MACaddress | MACmaskedaddress
8.15. Class qosPolicyStringValue Snir, Ramberg, Strassner, Cohen expires October 2000 61
This class is used to represent a single or set of string values. 8.15. Class qosPolicyStringValue
The class definition is as follows:
Snir, Ramberg, Strassner, Cohen expires September 2000 50 This class is used to represent a single or set of string values. Each
can have wildcards. The class definition is as follows:
NAME qosPolicyStringValue NAME qosPolicyStringValue
DESCRIPTION This class is used to define a list of string DERIVED FROM qosPolicyValue
values with wildcards DERIVED FROM qosPolicyValue
ABSTRACT False ABSTRACT False
PROPERTIES qpStringList
PROPERTIES qpStringList[]
8.15.1. The Property qpStringList 8.15.1. The Property qpStringList
This Property provides an unordered list of strings each representing a This property provides an unordered list of strings, each representing
single string with wildcards. The asterix character "*" is used as a single string with wildcards. The asterisk character "*" is used as a
wildcard and represents an arbitrary sub-string replacement. For wildcard, and represents an arbitrary sub-string replacement. For
example, the value "abc*def" match "abcxyzdef", and the value example, the value "abc*def" match "abcxyzdef", and the value
"abc*def*" match "abcxxxdefyyyzzz". The syntax definition is identical "abc*def*" match "abcxxxdefyyyzzz". The syntax definition is identical
to substrig assertion syntax defined in [LDAP_ATTR]. If the asterix to the substring assertion syntax defined in [LDAP_ATTR]. If the
character is required as part of the string value itself, It is quoted asterisk character is required as part of the string value itself, it
as described in section 4.3 of [LDAP_ATTR]. MUST be quoted as described in section 4.3 of [LDAP_ATTR].
The attribute definition is as follows:
NAME qpStringList NAME qpStringList
DESCRIPTION A list of string values with wildcards
SYNTAX String SYNTAX String
8.16 Class qosPolicyBitStringValue 8.16 Class qosPolicyBitStringValue
This class is used to represent a single or set of bit string values. This class is used to represent a single or set of bit string values.
The class definition is as follows: The class definition is as follows:
NAME qosPolicyBitStringValue NAME qosPolicyBitStringValue
DESCRIPTION This class is used to define a list of bit string
Values.
DERIVED FROM qosPolicyValue DERIVED FROM qosPolicyValue
ABSTRACT False ABSTRACT False
PROPERTIES qpBitStringList[] PROPERTIES qpBitStringList
8.16.1. The Property qpBitStringList 8.16.1. The Property qpBitStringList
This Property provides an unordered list of strings each representing a This property provides an unordered list of strings, each representing
single bit string or a set of bit strings. The number of bits specified a single bit string or a set of bit strings. The number of bits
should equal the number of bits of the expected variable. For example, specified SHOULD equal the number of bits of the expected variable. For
for an 8-bit byte variable, 8 bits should be specified. If the variable example, for an 8-bit byte variable, 8 bits should be specified. If the
does not have a fixed length, the bit string should be matched against variable does not have a fixed length, the bit string should be matched
the variable most significant bit string. against the variable most significant bit string. The formal
The formal definitions are: definitions are:
binary-digit = "0" / "1" binary-digit = "0" / "1"
bitstring = 1*binary-digit bitstring = 1*binary-digit
maskedBitString = bitstring","bitstring maskedBitString = bitstring","bitstring
Snir, Ramberg, Strassner, Cohen expires September 2000 51 Snir, Ramberg, Strassner, Cohen expires October 2000 62
Each string entry is either: Each string entry is either:
1. A single bit string. Example: 00111010 1. A single bit string. Example: 00111010
2. A range of bit strings specifies using a bit string and a bit mask. 2. A range of bit strings specifies using a bit string and a bit
The bit string and mask PROPERTIES have the same number of bits mask. The bit string and mask properties have the same number of
specified. The mask bit string specifies the significant bits in the bits specified. The mask bit string specifies the significant bits
bit string value. For example, 110110, 100110 and 110111 would match in the bit string value. For example, 110110, 100110 and 110111
the maskedBitString 100110,101110 but 100100 would not. would match the maskedBitString 100110,101110 but 100100 would
not.
NAME qpBitStringList NAME qpBitStringList
DESCRIPTION A list of bit string values
SYNTAX String SYNTAX String
FORMAT bitString | maskedBitString
FORMAT BitString | maskedBitString
8.17. Class qosPolicyDNValue 8.17. Class qosPolicyDNValue
This class is used to represent a single or set of Directory Name This class is used to represent a single or set of Distinguished Name
values including wildcards. This value can be used in comparison to values, including wildcards. A Distinguished Name is a name that can be
reference values carried in RSVP policy objects [IDENT]. used as a key to retrieve an object. This value can be used in
comparison to reference values carried in RSVP policy objects, as
specified in [IDENT].
The class definition is as follows: The class definition is as follows:
NAME qosPolicyDNValue NAME qosPolicyDNValue
DESCRIPTION This class is used to define a list of reference
values with wildcards.
DERIVED FROM qosPolicyValue DERIVED FROM qosPolicyValue
ABSTRACT False ABSTRACT False
PROPERTIES qpDNList
PROPERTIES qpDNList[]
8.17.1. The Property qpDNList 8.17.1. The Property qpDNList
This Property provides an unordered list of references each This property provides an unordered list of Distinguished Name
representing a single object referenced. references to objects. The attribute is defined as follows:
An example of such reference is the directory server implementation of
the information model is the Distinguished Name (DN).
NAME qpDNList NAME qpDNList
DESCRIPTION A list of values with wildcards. SYNTAX List of Distinguished Names, each of which serves as a
SYNTAX Reference reference to another object.
Snir, Ramberg, Strassner, Cohen expires September 2000 52 8.18. Class qosPolicyAttributeValue
8.18. Class qosPolicyPropertyValue This class is used to represent a single or set of property values in
an object. This value can be used in conjunction with reference values
carried in RSVP objects, as specified in [IDENT]. The property name is
used to specify which of the properties in the object is being used as
the condition. The value of this property will then be retrieved, and a
match (which is dependent on the property name) will be used to see if
the condition is satisfied or not.
This class is used to represent a single or set of Property values. The Snir, Ramberg, Strassner, Cohen expires October 2000 63
match operation used is dependent on the Property name. This value can
be used in conjunction with reference values carried in RSVP objects For example, suppose a User class has a multi-valued Property called
[IDENT]. The Property name is used to specify which of the Properties 'member-of' that lists the names of groups that this user belongs to.
the pointer points to, should be compared to the list of values. For Suppose this property uses caseIgnoreMatch matching. A simple condition
example, suppose a User class has a multi-valued Property called can be constructed to match the reference carried in an RSVP Identity
'member-of' that lists the names of groups this user belongs to. policy object to a qosPolicyAttributeValue with the following
Suppose this Property uses caseIgnoreMatch matching. A simple condition characteristics:
can be constructed to match the reference carried in RSVP Identity qpAttributeName="member-of",
policy object to a qosPolicyPropertyValue with qpPropertyName="member- qpAttributeValueList = "group-A".
of" and qpPropertyList = "group-A". An Identity policy object carrying
a reference "OU=Sales, CN=J. Smith, O=Widget Inc." will match this An Identity policy object carrying the following reference:
simple condition only if J. Smith belongs to group-a. "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: The class definition is as follows:
NAME qosPolicyPropertyValue NAME qosPolicyAttributeValue
DESCRIPTION This class is used to define an Property and a
list of its values.
DERIVED FROM qosPolicyValue DERIVED FROM qosPolicyValue
ABSTRACT False ABSTRACT False
PROPERTIES qpAttributeName, qpAttributeValueList
PROPERTIES qpPropertyName, qpPropertyValueList[] 8.18.1. The Property qpAttributeName
8.18.1. The Property qpPropertyName This attribute defines the name of the property that the list of values
should be compared against. The attribute is defined as follows:
NAME qpPropertyName NAME qpAttributeName
DESCRIPTION A name of a property the list of values should
be compared with
SYNTAX String SYNTAX String
8.18.2. The Property qpPropertyValueList 8.18.2. The Property qpAttributeValueList
NAME qpPropertyValueList This attribute contains a list of property values. Each value is
DESCRIPTION A list of property values. Each value is compared compared to a value of the property specified by qpAttributeName. The
to a value of the property specified by attribute is defined as follows:
qpPropertyName.
NAME qpAttributeValueList
SYNTAX String SYNTAX String
8.19. Class qosPolicyIntegerValue 8.19. Class qosPolicyIntegerValue
This class provides a list of Integer and integer range values. Integer This class provides a list of integer and integer range values.
of arbitrary size can be represented. For a given variable, the set of Integers of arbitrary sizes can be represented. For a given variable,
the set of possible ranges of integer values allowed is specified via
Snir, Ramberg, Strassner, Cohen expires September 2000 53 the variable's qpValueConstraints Property. The class definition is as
follows:
possible range of integer values allowed is specified via the
variable's qpValueConstraints Property.
The class definition is as follows:
NAME qosPolicyIntegerValue NAME qosPolicyIntegerValue
DESCRIPTION This class is used to define Integer values
DERIVED FROM qosPolicyValue DERIVED FROM qosPolicyValue
ABSTRACT False ABSTRACT False
PROPERTIES qpIntegerList
PROPERTIES qpIntegerList[] Snir, Ramberg, Strassner, Cohen expires October 2000 64
8.19.1. The Property qpIntegerList 8.19.1. The Property qpIntegerList
This Property provides an unordered list of integers and integer range This property provides an unordered list of integers and integer range
values. The format of the Property can take on of the following forms: values. The format of this property can take on of the following forms:
1. An integer value. 1. An integer value.
2. A range of integers. The range is specifies by a start integer and 2. A range of integers. The range is specifies by a start integer and
an end integer separated by "..". The range includes all integers an end integer separated by "-". The range includes all integers
between start and end integers, including the start and end 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 To represent a range of integers that is not bounded, the reserved word
INFINITY can be used as the end range integer. INFINITY can be used as the end range integer.
The ABNF definition [ABNF] is: The ABNF definition [ABNF] is:
integer = 1*DIGIT | "INFINITY" integer = 1*DIGIT | "INFINITY"
integerrange = integer".."integer integerrange = integer"-"integer
Using ranges the operators greater-than, greater-than-or-equal-to, Using ranges the operators greater-than, greater-than-or-equal-to,
less-than and less-than-or-equal-to can be expressed. less-than and less-than-or-equal-to can be expressed.
NAME qpIntegerList NAME qpIntegerList
DESCRIPTION
SYNTAX String SYNTAX String
FORMAT integer | integerrange FORMAT integer | integerrange
8.20. Class qosPolicyPHBSet 8.20. Class qosPolicyPHBSet
The qosPolicyPHBSet is an class that serves as a named container for The qosPolicyPHBSet is a class that serves as a named container for
qosPolicyPHB objects. A single PHB set is associated with a QoS domain qosPolicyPHB objects. A single PHB set is associated with a QoS domain
using the domain property defined in the qosPolicyDomain object. using the domain property defined in the qosPolicyDomain object.
Instances of the qosNamedPolicyContainer class can override the Instances of the qosNamedPolicyContainer class can override the
domain's PHB set by referencing another PHB set via the qosPolicyPHBSet domain's PHB set by referencing another PHB set via the qosPolicyPHBSet
Property or by aggregation of a qosPolicyPHBSet object. Property or by aggregation of a qosPolicyPHBSet object.
The class is defined as follows:
NAME qosPolicyPHBSet NAME qosPolicyPHBSet
DESCRIPTION This class defines a set of PHB definitions DERIVED FROM policy (defined in [PCIM])
DERIVED FROM policy
ABSTRACT False ABSTRACT False
PROPERTIES PROPERTIES
Snir, Ramberg, Strassner, Cohen expires September 2000 54
8.21. Class qosPolicyPHB 8.21. Class qosPolicyPHB
The qosPolicyPHB Class is an abstract class extending the Policy class, The qosPolicyPHB Class is an abstract class that extends the policy
which is intended to be extended with the information required to model class (defined in the [PCIM]) with the information required to model
a PHB service class. The PHB service class is an abstraction over a PHB service class. The PHB service class is an abstraction over
device-specific parameters. device-specific parameters.
Snir, Ramberg, Strassner, Cohen expires October 2000 65
The class is defined as follows:
NAME qosPolicyPHB NAME qosPolicyPHB
DESCRIPTION This class defines a single service class in a PHB DERIVED FROM policy (defined in [PCIM])
set.
DERIVED FROM Policy (Core)
ABSTRACT True ABSTRACT True
PROPERTIES qpDSCP PROPERTIES qpDSCP
8.21.1. The Property qpDSCP 8.21.1. The Property qpDSCP
This property is an integer, constrained to have a value in the range
0..63 inclusive, for representing the service classes in the QoS policy
domain that are used for traffic classification. The attribute is
defined as follows:
NAME qpDSCP NAME qpDSCP
DESCRIPTION An integer in the range 0..63, representing the SYNTAX Integer (must be in the range 0..63, inclusive)
service classes in the domain that are used for
classification. 8.22 Class qosPolicyMeter
SYNTAX Integer
This class models a meter, as defined in (for example)
[DIFF-SERV-ARCH]. Meters measure the temporal properties of the stream
of packets selected by a classifier against a traffic profile.
A meter can be shared between different policy rules. A meter shared by
more than one policy rule resides in a repository and is referenced by
all sharing rules.
The class is defined as follows:
NAME qosPolicyMeter
DERIVED FROM policy (defined in [PCIM])
ABSTRACT True
PROPERTIES
Snir, Ramberg, Strassner, Cohen expires October 2000 66
9. Extending the QoS Policy Schema 9. Extending the QoS Policy Schema
The following subsections provide general guidance on how to create a The following subsections provide general guidance on how to create a
domain-specific schema derived from the QoS Policy Schema by extending domain-specific information model derived from the QPIM by extending
the QoS policy classes. the QoS policy classes.
9.1. Extending qosPolicyValue 9.1. Extending qosPolicyValue
The qosPolicyValue class and its subclasses describe the common The qosPolicyValue class and its subclasses describe the common
value types used in QoS policy information model. value types used in the QPIM. When other specific types are required,
When other specific types are required, such as a floating-point such as a floating-point numbers, the required class SHOULD be derived
numbers, the required class should be derived from the from the qosPolicyValue class and properties that contain the
qosPolicyValue class and properties that contain the corresponding corresponding values SHOULD be added.
values should be added.
Notice, that in many cases using the qosPolicyPropertyValue class Notice that in many cases, using the qosPolicyAttributeValue class
allows the definition of non-standard policy atoms with out extending allows the definition of non-standard policy atoms with out extending
the qosPolicyValue class. the qosPolicyValue class.
9.2. Extending qosPolicySimpleCondition 9.2. Extending qosPolicySimpleCondition
Policy condition describes a single atomic Boolean condition. For The qosPolicySimpleCondition class is used to describe a single atomic
Boolean Boolean condition. For Boolean conditions that are not structured as
conditions that are not structured as the ordered triple <variable - the ordered triple <variable - relation - value>, a new type of
relation - value>, a new type of condition class should be defined. An condition class SHOULD be defined. An example would be a unary
example would be an unary condition. condition.
Subclassing could be done using either PolicyCondition or
qosPolicySimpleCondition as the superclass.
Snir, Ramberg, Strassner, Cohen expires September 2000 55 Subclassing could be done using either the policyCondition or
qosPolicySimpleCondition classes as the superclass.
9.3. Extending qosPolicyAction 9.3. Extending qosPolicyAction
The Qos Policy actions classes defined in the QoS Policy Schema The Qos Policy actions classes defined in the QoS Policy Schema
includes Includes the following types of actions:
Provisioning actions: Provisioning actions:
* Marking * Marking
* Policing, shaping and remarking according to a traffic profile. * Policing, shaping and remarking according to a traffic profile
Signaling RSVP action: Signaling RSVP action:
* RSVP policy admission * RSVP policy admission
* RSVP signal control extensions. * RSVP signal control extensions
* RSVP flow control extensions. * RSVP flow control extensions
Additional actions could be associated with QoS policy rules by Additional actions could be associated with QoS policy rules by
extending the PolicyAction class with the appropriate properties. extending the policyAction class with the appropriate properties.
Snir, Ramberg, Strassner, Cohen expires October 2000 67
10. Security Considerations 10. Security Considerations
See [PFSCHEMA]. The security considerations for this document are the same as those of
the [PCIM].
11. Acknowledgments 11. Acknowledgments
12. References The authors wish to thank the input of the participants of the Policy
Framework working group, and especially Bob Moore and Alex Wang for
their helpful contributions.
[TERMS] S. Bradner, "Key words for use in RFCs to Indicate 12. References
Requirement Levels", Internet RFC 2119, March 1997.
[PFCORE] J. Strassner, E. Ellesson, B. Moore, "Policy Framework Core [ABNF] Crocker, D., and P. Overell, "Augmented BNF for
Information Model", Syntax Specifications: ABNF", RFC 2234, November
draft-ietf-policy-core-info-model-00.txt 1997.
[PFSCHEMA] J. Strassner, E. Ellesson, B. Moore, "Policy Framework LDAP [CL] J. Wroclawski, "Specification of the Controlled-Load
Core Schema", draft-ietf-policy-core-schema-04.txt Network Element Service", RFC2211, September 1997
[COPS] D. Durham, J. Boyle, R . Cohen, S. Herzog, R. Rajan, A. [COPS] D. Durham, J. Boyle, R . Cohen, S. Herzog, R. Rajan, A.
Sastry, "The COPS (Common Open Policy Service) Protocol", Sastry, "The COPS (Common Open Policy Service) Protocol",
RFC2748 RFC2748
[COPSRSVP] S. Herzog, J. Boyle, R . Cohen, D. Durham, R. Rajan, A. [COPSRSVP] S. Herzog, J. Boyle, R . Cohen, D. Durham, R. Rajan, A.
Sastry, "COPS Usage for RSVP", RFC2749 Sastry, "COPS Usage for RSVP", RFC2749
[LDAP_ATTR] M. Wahl, A. Coulbeck, " Lightweight Directory Access [DEREF] R. Moats, J. Maziarski, J. Strassner, "Extensible Match
Protocol (v3): Attribute Syntax Definitions", RFC 2252 Rules to Dereference Pointer", Internet Draft
<draft-moats-ldap-dereference-match-02.txt>
[RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) - [DIFF-SERV-ARCH] S. Blake D. Blake, "An Architecture for
Functional Specification.", IETF RFC 2205, Differentiated Services", RFC2475
Proposed Standard, Sep. 1997.
[RSVP_PREEMP] Shai Herzog, "Signaled Preemption Priority Policy [DNDEF] Wahl, M., Kille, S., and T. Howes, "Lightweight
Element", RFC2751 Directory Access Protocol (v3): UTF-8 String
Representation of Distinguished Names", RFC 2253,
December 1997.
Snir, Ramberg, Strassner, Cohen expires September 2000 56 [GS] S. Shenker, C. Partridge, R. Guerin, "Specification
of the Guaranteed Quality of Service", RFC2212,
September 1997
[DIFF-SERV-ARCH] S. Blake D. Blake, "An Architecture for [IDNET] S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T.
Differentiated Services", RFC2475 Moore, S. Herzog, "Identity Representation for
RSVP", RFC 2752, January 2000
[PIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, A. [IPv6] R. Hinden, S. Deering, "IP Version 6 Addressing
Smith, "Quality of Service Policy Information Base",
Internet Draft <draft-mfine-cops-pib-01.txt>
[DEREF] R. Moats, J. Maziarski, J. Strassner, "Extensible Match Snir, Ramberg, Strassner, Cohen expires October 2000 68
Rules to Dereference Pointer", Internet Draft
<draft-moats-ldap-dereference-match-02.txt>
[QOSCAP] J. Strassner, W. Weiss, D. Durham, A. Westerinen, [LDAP_ATTR] M. Wahl, A. Coulbeck, " Lightweight Directory Access
Information Model for defining the QoS Protocol (v3): Attribute Syntax Definitions", RFC 2252
Capabilities of Network Devices and Services,
draft-ietf-policy-qos-capabilities-schema-00.txt
[NAME] P. Mockapetris, " Domain names - implementation and [NAME] P. Mockapetris, " Domain names - implementation and
specification", RFC1035 specification", RFC1035
[Ipv6] R. Hinden, S. Deering, "IP Version 6 Addressing [PCIM] J. Strassner, E. Ellesson, B. Moore, "Policy Framework Core
Information Model", Internet Draft
<draft-ietf-policy-core-info-model-05.txt>
[ABNF] Crocker, D., and P. Overell, "Augmented BNF for [PHBLDAP] R. Cohen, Y. Snir, J. Strassner, ˘LDAP schema for Domain
Syntax Specifications: ABNF", RFC 2234, November Per Hop Behavior Set÷, Internet Draft
1997. <draft-ronc-domain-phb-set-ldap-rep-00.txt>
[DNDEF] Wahl, M., Kille, S., and T. Howes, "Lightweight [PHBSET] R. Cohen, A. Zavalkovsky, N. Elfassy, ˘Domain Per Hop
Directory Access Protocol (v3): UTF-8 String Behavior Set Specification÷, Internet Draft
Representation of Distinguished Names", RFC 2253, <draft-ronc-domain-phb-set-specification-00.txt>
December 1997.
[IDNET] S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. [PFSCHEMA] J. Strassner, E. Ellesson, B. Moore, "Policy Framework LDAP
Moore, S. Herzog, "Identity Representation for Core Schema", Internet Draft
RSVP", RFC 2752, January 2000 <draft-ietf-policy-core-schema-06.txt>
[QOSSCHEMA] Y. Snir, Y Ramberg, J. Strassner, R. Cohen QoS [PIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, A.
Policy Schema , qos-ietf-policy-info-model-00.txt Smith, "Quality of Service Policy Information Base",
Internet Draft <draft-mfine-cops-pib-01.txt>
[QOSDEV] J. Strassner, W. Weiss, D. Durham, A. Westerinen,
˘Information Model for Describing Network Device QoS
Mechanisms÷, Internet Draft
<draft-ietf-policy-qos-device-info-model-00.txt>
[QOSSCHEMA] Y. Snir, Y Ramberg, J. Strassner, R. Cohen, ˘QoS
Policy Schema÷, Internet Draft
<draft-ietf-policy-qos-schema-01.txt>
[RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) -
Functional Specification.", IETF RFC 2205,
Proposed Standard, Sep. 1997.
[RSVP-IS] J. Wroclawski, "The Use of RSVP with IETF Integrated [RSVP-IS] J. Wroclawski, "The Use of RSVP with IETF Integrated
Services", RFC2210, September 1997 Services", RFC2210, September 1997
[CL] J. Wroclawski, "Specification of the Controlled-Load [RSVP_PREEMP] Shai Herzog, "Signaled Preemption Priority Policy
Network Element Service", RFC2211, September 1997 Element", RFC2751
[GS] S. Shenker, C. Partridge, R. Guerin, "Specification [TERMS] S. Bradner, "Key words for use in RFCs to Indicate
of the Guaranteed Quality of Service", RFC2212, Requirement Levels", Internet RFC 2119, March 1997.
September 1997
Snir, Ramberg, Strassner, Cohen expires September 2000 57 Snir, Ramberg, Strassner, Cohen expires October 2000 69
13. Author's Addresses 13. Author's Addresses
Yoram Snir Yoram Snir
Cisco Systems Cisco Systems
4 Maskit Street 4 Maskit Street
Herzliya Pituach, Israel 46766 Herzliya Pituach, Israel 46766
Phone: +972-9-970-0085 Phone: +972-9-970-0085
Fax: +972-9-970-0219 Fax: +972-9-970-0219
E-mail: ysnir@cisco.com E-mail: ysnir@cisco.com
skipping to change at line 2904 skipping to change at line 3487
in whole or in part, without restriction of any kind, provided that the in whole or in part, without restriction of any kind, provided that the
above copyright notice and this paragraph are included on all such above copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself not be copies and derivative works. However, this document itself not be
modified in any way, such as by removing the copyright notice or modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet organizations, references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet which case the procedures for copyrights defined in the Internet
Standards process PROPERTIES be followed, or as required to translate Standards process PROPERTIES be followed, or as required to translate
it into languages other than English. it into languages other than English.
Snir, Ramberg, Strassner, Cohen expires September 2000 58 Snir, Ramberg, Strassner, Cohen expires October 2000 70
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE FITNESS FOR A PARTICULAR PURPOSE
Snir, Ramberg, Strassner, Cohen expires September 2000 59 Snir, Ramberg, Strassner, Cohen expires October 2000 71
 End of changes. 493 change blocks. 
1578 lines changed or deleted 2161 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/