draft-ietf-policy-qos-info-model-02.txt   draft-ietf-policy-qos-info-model-03.txt 
Policy Framework Y. Snir Policy Framework Working Group Y. Snir
Internet Draft Y. Ramberg INTERNET-DRAFT Y. Ramberg
Expires May 2001 J. Strassner Category: Standards Track J. Strassner
draft-ietf-policy-qos-info-model-02.txt R. Cohen Cisco Systems
November 2000 Cisco Systems R. Cohen
Ntear LLC
Policy Framework QoS Information Model Policy QoS Information Model
<draft-ietf-policy-qos-info-model-03.txt>
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
all provisions of Section 10 of RFC2026. 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
Task Force (IETF), its areas, and its working groups. Note that Force (IETF), its areas, and its working groups. Note that other groups
other groups may also distribute working documents as Internet Drafts. may also distribute working documents as Internet-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
and may be updated, replaced, or obsoleted by other documents at any may be updated, replaced, or obsoleted by other documents at any time.
time. It is inappropriate to use Internet-Drafts as reference It is inappropriate to use Internet-Drafts as reference material or to
material or to cite them other than as "work in progress." 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
Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (2001). 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. This document is based on the IETF representing network QoS policies. This document is based on the IETF
Policy Core Information Model as specified by [PCIM]. This draft Policy Core Information Model and its extensions as specified by [PCIM]
refines the concept of generic policy rules, conditions and actions and [PCIMe]. This draft builds upon these two documents to define an
defined in [PCIM] in order to define extensions necessary for information model for QoS enforcement for differentiated and integrated
representing IntServ and DiffServ QoS policies. It also provides services using policy. It is important to note that this document defines
refinement of additional concepts that are important for building rule- an information model, which by definition is independent of any
specific as well as reusable QoS policy rules. particular data storage mechanism and access protocol.
This information model covers Differentiated Services QoS enforcement, Definition of Key Word Usage
and Integrated Service QoS enforcement via policy control on RSVP
admission. It is important to note that this document defines an
information model, which by definition is independent of any particular
data storage mechanism and access protocol. Companion documents (e.g.,
[QoSSCHEMA]) define the mapping of these classes to specific data
models (schemata).
Snir, Ramberg, Strassner, Cohen expires May 2001 1 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [KEYWORDS].
For example, [QoSSCHEMA] defines how to map the data in this Snir, Ramberg, Strassner, Cohen expires November 2001 1
information model to a form that can be stored in a directory that uses
LDAPv3 as its access protocol.
Table of Contents Table of Contents
1. Introduction 6 1. Introduction 5
1.1 Goals 7 1.1. Goals 5
1.2 Approach and Related Documents 7 1.1.1. Modeling Abstract QoS Policies 5
1.1.2. Enhancing Interoperability 6
2. Information Model Hierarchy 8 1.1.3. Intended Audiences 7
2.1 Interaction Between the PCIM and This Document 8 1.2. QPIM Characteristics 8
2.1.1. Extension of Concepts in the PCIM 8 1.3. QPIM and Other Published Standards 10
2.1.1.1 Hierarchical Policy Repositories 9
2.1.1.2 Extensions to Reusable Objects 9
2.1.1.3 Extensions to the Structure of a Policy Rule 9
2.1.2 Addition of New Concepts Not in the PCIM 9
2.1.2.1 Rule Nesting 9
2.1.2.2 Rule Decision Strategy 10
2.1.2.3 Compound Conditions 10
2.1.2.4 Pre-Defined Variables and Constants 10
2.1.2.5 Per-Hop Behaviors 11
2.1.3 Mapping to a Directory 11
2.2 High-Level Class Hierarchy 11
3. QPIM Hierarchies 13
3.1. Class and Relationship Hierarchies Defined in the QPIM 14
3.2. Implementation Guidelines 15
3.2.1 Modeling Containment 16
3.2.2. Implementing Relationships 17
3.2.2.1. Relationship modeling 17
3.2.2.2. Representing Containment in a Consistent Manner 18
3.2.3. Mapping Differences and Examples 18
3.3. QoS Domain Data Tree 19
3.4. Types of Grouping Classes 22
3.5. QoS Policy Domain Grouping and Nesting 23
3.6. Resource Sharing 25
3.7. Instance Location 26
3.8. Policy Containers 27
3.8.1 Semantics of a gpsPolicyGroup 27
3.8.2 Priority and Decision Strategy Applied to Containers 29
3.8.3 Sharing Policy Containers 30
3.9 Policy Roles associated with gpsPolicyGroup 31
3.10 Policy Rules 32
3.11 Conditions and Actions 33
3.12 Data Tree Example 33
3.13 Reusable-Object Repositories 34
3.14 Relationships Between QoS Domains and Repositories 35
Snir, Ramberg, Strassner, Cohen expires May 2001 2
4. Constructing a QoS Policy Rule 36 2. Class Hierarchies 11
4.1 Policy Rule Structure 36 2.1. Inheritance Hierarchy 11
4.2 QoS Policy Conditions 37 2.2. Relationship Hierarchy 13
4.2.1. Simple Conditions 38
4.2.2. Compound Conditions 38
4.2.3. Using Simple Conditions 39
4.2.4. Using Compound Conditions 41
4.2.5. Reusable vs. Rule-Specific Conditions 42
4.3 Simple Condition Operator 43
4.4 QoS Policy Variables 43
4.4.1 Variable Binding 45
4.4.2 Pre-Defined Variables 46
4.5 QoS Policy Value 49
4.6. PolicyTimePeriodCondition 50
4.7. Actions 50
4.7.1 Provisioning Actions 52
4.7.1.1 Meters 52
4.7.1.2 Markers 53
4.7.1.3 Shapers 54
4.7.1.4 Droppers 54
4.7.1.5 Examples 55
4.7.2 PHB actions 57
4.7.2.1 Bandwidth and Delay management 57
4.7.2.2 Congestion Control and Buffer management 58
4.7.2.3 Queues and PHB groups 58
4.7.2.4 Using hierarchical policies 59
4.7.2.5 Examples 59
4.7.3 Signaling Actions 61
4.7.3.1 Admission Control 62
4.7.3.2 Forwarding Behavior 62
4.7.3.3 Signaling Control 63
4.7.3.4 Examples 63
4.8 Meters and Traffic Profiles 64 3. QoS Actions 14
4.8.1 Provisioning Traffic Profiles 65 3.1. Overview 14
4.8.2 RSVP Traffic Profiles 66 3.2. RSVP Policy Actions 15
3.3. Provisioning Policy Actions 16
3.3.1. Admission Actions: Controlling Policers and Shapers 17
3.3.2. Controlling Markers 18
3.3.3. Controlling Edge Policies Examples 18
3.4. Per-Hop Behavior Actions 20
3.4.1. Controlling Bandwidth and Delay 21
3.4.2. Congestion Control Actions 21
3.4.3. Using Hierarchical Policies Examples for PHB Actions 22
5. Decision strategy 67 4. Traffic Profiles 23
5.1 Organizing the Application of Decision Strategies 67 4.1. Provisioning Traffic Profiles 24
5.2 Decision Strategies 68 4.2. RSVP Traffic Profiles 24
5.2.1. First Match Decision Strategy 68
5.2.2. Match All Decision Strategy 68
5.3. Decision Strategy example 69
6. Per Hop Behavior 70 5. Pre-Defined QoS-Related Variables 25
7. QoS Policy Class Inheritance 71 6. QoS Related Values 27
8. Class Definitions 75 7. Class Definitions: Association Hierarchy 28
8.1 The Aggregation "PolicyGroupInPolicyRule" 75 7.1. The Association "QoSPolicyTrfcProfInAdmissionAction" 28
8.1.1. The Reference "GroupComponent" 75 7.1.1. The Reference "Antecedent" 28
7.1.2. The Reference "Dependent" 28
7.2. The Association "PolicyConformAction" 28
7.2.1. The Reference "Antecedent" 29
7.2.2. The Reference "Dependent" 29
7.3. The Association "PolicyExcessAction" 29
7.3.1. The Reference "Antecedent" 29
7.3.2. The Reference "Dependent" 29
7.4. The Association "PolicyViolateAction" 30
7.4.1. The Reference "Antecedent" 30
7.4.2. The Reference "Dependent" 30
Snir, Ramberg, Strassner, Cohen expires May 2001 3 Snir, Ramberg, Strassner, Cohen expires November 2001 2
8.1.2. The Reference "PartComponent" 75 Table of Contents (continued)
8.2 The Aggregation "PolicyRuleInPolicyRule" 76 8. Class Definitions: Inheritance Hierarchy 31
8.2.1. The Reference "GroupComponent" 76 8.1. The Class QoSPolicyDiscardAction 31
8.2.2. The Reference "PartComponent" 76 8.2. The Class QoSPolicyAdmissionAction 31
8.3 The Aggregation "PolicyConditionInCompoundCondition " 77 8.2.1. The Property qpAdmissionScope 31
8.3.1. The Reference "GroupComponent" 77 8.3. The Class QoSPolicyPoliceAction 32
8.3.2. The Reference "PartComponent" 77 8.4. The Class QoSPolicyShapeAction 32
8.4 The Aggregation " PolicyVariableInPolicySimpleCondition " 77 8.5. The Class QoSPolicyRSVPAdmissionAction 33
8.4.1. The Reference "GroupComponent" 78 8.5.1. The Property qpRSVPWarnOnly 33
8.4.2. The Reference "PartComponent" 78 8.5.2. The Property qpRSVPMaxSessions 33
8.5 The Aggregation " PolicyValueInPolicySimpleCondition " 78 8.6. The Class QoSPolicyPHBAction 34
8.5.1. The Reference "GroupComponent" 79 8.6.1. The Property qpPacketSize 34
8.5.2. The Reference "PartComponent" 79 8.7. The Class QoSPolicyBandwidthAction 34
8.6. The Association "PolicyElementInPolicyRepository" 79 8.7.1. The Property qpForwardingPriority 35
8.6.1. The Reference "Antecedent" 80 8.7.2. The Property qpBandwidthUnits 35
8.6.2. The Reference "Dependent" 80 8.7.3. The Property qpMinBandwidth 35
8.7. The Association "PolicyValueConstraintsInVariable" 80 8.7.4. The Property qpMaxBandwidth 35
8.7.1. The Reference "Antecedent" 81 8.7.5. The Property qpMaxDelay 36
8.7.2. The Reference "Dependent" 81 8.7.6. The Property qpMaxJitter 36
8.8. The Association "PolicyMeterInAction" 81 8.7.7. The Property qpFairness 36
8.8.1. The Reference "Antecedent" 81 8.8. The Class QoSPolicyCongestionControlAction 36
8.8.2. The Reference "Dependent" 81 8.8.1. The Property qpSizeUnits 37
8.9. The Association "PolicyTrfcProfileInMeter" 82 8.8.2. The Property qpQueueSize 37
8.9.1. The Reference "Antecedent" 82 8.8.3. The Property qpDropAlgorithm 37
8.9.2. The Reference "Dependent" 82 8.8.4. The Property qpDropThresholdUnits 37
8.10. The Association "PolicyQueueInPHBAction" 82 8.8.5. The Property qpDropMinThresholdValue 38
8.10.1. The Reference "Antecedent" 82 8.8.6. The Property qpDropMaxThresholdValue 38
8.10.2. The Reference "Dependent" 83 8.9. The Class QoSPolicyTrfcProf 38
8.11. The Association "PolicyConformNextAction" 83 8.10. The Class QoSPolicyTokenBucketTrfcProf 39
8.11.1. The Reference "Antecedent" 83 8.10.1. The Property qpTBRate 39
8.11.2. The Reference "Dependent" 83 8.10.2. The Property qpTBNormalBurst 39
8.12. The Association "PolicyExcessNextAction" 84 8.10.3. The Property qpTBExcessBurst 39
8.12.1. The Reference "Antecedent" 84 8.11. The Class QoSPolicyIntServTrfcProf 40
8.12.2. The Reference "Dependent" 84 8.11.1. The Property qpISTokenRate 40
8.13. The Association "PolicyViolateNextAction" 84 8.11.2. The Property qpISPeakRate 40
8.13.1. The Reference "Antecedent" 85 8.11.3. The Property qpISBucketSize 40
8.13.2. The Reference "Dependent" 85 8.11.4. The Property qpISResvRate 41
8.14. Class qosPolicyDomain 85 8.11.5. The Property qpISResvSlack 41
8.14.1. The Property qpDomainName 85 8.11.6. The Property qpISMinPolicedUnit 41
8.14.2. The Property qpPolicyRuleMatchMethod 86 8.11.7. The Property qpISMaxPktSize 41
8.15. Class gpsPolicyGroup 86 8.12. The Class QoSPolicyAttributeValue 42
8.15.1. The Property gpPriority 86 8.12.1. The Property qpAttributeName 42
8.15.2. The Property gpNamedPolicyRuleMatchMethod 87 8.12.2. The Property qpAttributeValueList 42
8.15.3. The Property gpPolicyRoles 87 8.13. The Class QoSPolicyRSVPVariable 42
8.16. Class qosPolicyPRAction 87 8.14. The Class QoSPolicyRSVPSourceIPv4Variable 43
8.16.1. The Property qpDirection 87 8.15. The Class QoSPolicyRSVPDestinationIPv4Variable 43
8.16.2. The Property qpMarkvalue 88 8.16. The Class QoSPolicyRSVPSourceIPv6Variable 43
8.16.3. The Property qpMarkValueType 88 8.17. The Class QoSPolicyRSVPDestinationIPv6Variable 44
8.16.4. The Property qpExcessAction 88 8.18. The Class QoSPolicyRSVPSourcePortVariable 44
8.16.5. The Property qpExcessMarkValue 88 8.19. The Class QoSPolicyRSVPDestinationPortVariable 44
8.16.6. The Property qpViolateAction 89
8.16.7. The Property qpViolateMarkValue 89
Snir, Ramberg, Strassner, Cohen expires May 2001 4 Snir, Ramberg, Strassner, Cohen expires November 2001 3
8.17. Class qosPolicyPHBAction 89 Table of Contents (continued)
8.17.1. The Property qpPHBDirection 89
8.17.2. The Property qpDropAlgorithm 90
8.17.3. The Property qpDropTreshholdValueType 90
8.17.4. The Property qpDropMinTreshholdValue 90
8.17.5. The Property qpDropMaxTreshholdValue 90
8.17.6. The Property qpRandomDropInvWeight 91
8.17.7. The Property qpRandomDropProbMax 91
8.17.8 The Property qpPacketSize 91
8.18. Class qosPolicyRSVPAction 91
8.18.1. The Property qpRSVPDirection 92
8.18.2. The Property qpRSVPMessageType 92
8.18.3. The Property qpRSVPStyle 92
8.18.4. The Property qpRSVPServiceType 92
8.19. Class qosPolicyRSVPSignalCtrlAction 93
8.19.1. The Property qpForwardingMode 93
8.19.2. The Property qpSendError 93
8.19.3. The Property qpReplaceDSCP 93
8.19.4. The Property qpReplacePreemptionPriority 94
8.19.5. The Property qpReplaceDefendingPriority 94
8.20. Class qosPolicyRSVPInstallAction 94
8.20.1. The Property qpSetDSCPValue 95
8.20.2. The Property qpSetDefendingPriority 95
8.20.3. The Property qpSetPreemptionPriority 95
8.21. Class gpsPolicyTrfcProf 95
8.22. Class qosPolicyPRTrfcProf 96
8.22.1. The Property qpPRRate 96
8.22.2. The Property qpPRNormalBurst 96
8.22.3. The Property qpPRExcessBurst 96
8.23. Class qosPolicyRSVPTrfcProf 96
8.23.1. The Property qpRSVPTokenRate 96
8.23.2. The Property qpRSVPPeakRate 97
8.23.3. The Property qpRSVPBucketSize 97
8.23.4. The Property qpRSVPResvRate 97
8.23.5. The Property qpRSVPResvSlack 97
8.23.6. The Property qpRSVPSessionNum 97
8.23.7. The Property qpMinPolicedUnit 98
8.23.8. The Property qpMaxPktSize 98
8.24. Class gpsPolicySimpleCondition 98
8.24.1. The Property gpOperator 99
8.25. Class gpsPolicyCompoundCondition 99
8.25.1 The Property gpPolicyConditionListType 99
8.26. Class gpsPolicyVariable 100
8.26.1. The Property gpVariableName 100
8.26.2. The Property gpVariableDescription 101
8.27. Class gpsPolicyValue 101
8.28. Class gpsPolicyIPv4AddrValue 101
8.28.1. The Property gpIPv4AddrList 102
8.29. Class gpsPolicyIPv6AddrValue 102
8.29.1. The Property gpIPv6AddrList 102
Snir, Ramberg, Strassner, Cohen expires May 2001 5 8.20. The Class QoSPolicyRSVPIPProtocolVariable 45
8.21. The Class QoSPolicyRSVPIPVersionVariable 45
8.22. The Class QoSPolicyRSVPDCLASSVariable 45
8.23. The Class QoSPolicyRSVPStyleVariable 46
8.24. The Class QoSPolicyRSVPIntServVariable 46
8.25. The Class QoSPolicyRSVPMessageTypeVariable 46
8.26. The Class QoSPolicyRSVPPreemptionPriorityVariable 47
8.27. The Class QoSPolicyRSVPPreemptionDefPriorityVariable 47
8.28. The Class QoSPolicyRSVPUserVariable 48
8.29. The Class QoSPolicyRSVPApplicationVariable 48
8.30. The Class QoSPolicyRSVPAuthMethodVariable 49
8.31. The Class QosPolicyDNValue 49
8.31.1. The Property qpDNList 49
8.32. The Class QoSPolicyRSVPSimpleAction 50
8.32.1. The Property qpRSVPActionType 50
8.30. Class gpsPolicyMACAddrValue 103 9. Acknowledgements 50
8.30.1. The Property gpMACAddrList 103
8.31. Class gpsPolicyStringValue 104
8.31.1. The Property gpStringList 104
8.32 Class gpsPolicyBitStringValue 104
8.32.1. The Property gpBitStringList 104
8.33. Class gpsPolicyDNValue 105
8.33.1. The Property gpDNList 105
8.34. Class gpsPolicyAttributeValue 106
8.34.1. The Property gpAttributeName 106
8.34.2. The Property gpAttributeValueList 106
8.35. Class gpsPolicyIntegerValue 107
8.35.1. The Property gpIntegerList 107
8.36. Class gpsPolicyMeter 108
8.36.1. The Property gpMeterScope 108
8.36.2. The Property gpMeterTimeInterval 108
8.37. Class qosPolicyQueue 109
8.37.1. The Property qpForwardingPriority 109
8.37.2. The Property qpBandwidthValueType 109
8.37.3. The Property qpMinBandwidth 109
8.37.4. The Property qpMaxBandwidth 110
8.37.5 The Property qpMaxDelay 110
8.37.6 The Property qpMaxJitter 110
8.37.7 The Property qpPacketSize 110
8.37.8 The Property qpFairQueue 110
9. Extending the QoS Policy Schema 111 10. Security Considerations 50
9.1. Extending gpsPolicyValue 111
9.2. Extending gpsPolicySimpleCondition 111
9.3. Extending qosPolicyAction 111
10. Security Considerations 112 11. References 51
11. Editorial Changes 112 12. Authors' Addresses 52
12. Acknowledgments 113
13. References 113
14. Author's Addresses 115 13. Full Copyright Statement 53
15. Full Copyright Statement 115 Snir, Ramberg, Strassner, Cohen expires November 2001 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. As such, it is independent of any representing network QoS policies. This document is based on the IETF
specific data storage mechanism and access protocol. This document is Policy Core Information Model and its extensions as specified by [PCIM]
based on the IETF Policy Core Information Model as specified by [PCIM]. and [PCIMe]. This draft builds upon these two documents to define an
Specifically, this draft refines the concept of generic policy rules, information model for QoS enforcement for differentiated and integrated
conditions and actions to cover extensions necessary for representing services using policy. It is important to note that this document defines
IntServ and DiffServ QoS policies. an information model, which by definition is independent of any
particular data storage mechanism and access protocol.
Snir, Ramberg, Strassner, Cohen expires May 2001 6
This information model covers Differentiated Service QoS enforcement, The following subsections describe the goals and purposes of the QoS
and Integrated Service QoS enforcement via policy control on RSVP Policy Information Model (QPIM), its intended audience, and its
admission. Companion documents (e.g., [QoSSCHEMA]) define the mapping relationships to other published standards.
of these classes to specific data models (schemata). For example,
[QoSSCHEMA] defines how to map the data in this information model to a
form that can be stored in a directory that uses LDAPv3 as its access
protocol.
1.1 Goals 1.1 Goals
This document defines a set of classes that can be used to build high This section explains the goals for creating QPIM.
level policies that can be used to configure and enforce consistent QoS
behavior across a network. Specifically, the policies defined in this
document can be used to control and manage different vendor-specific
device mechanisms that are used to build different IntServ and DiffServ
QoS behaviors. The purpose of introducing a standard information model
is to allow interoperability between policy servers, policy management
applications, and network devices.
This document solves two problems. First, different devices have
different capabilities, and may respond differently to the same high-
level policy rule. This document solves this problem by defining a set
of common abstractions that can be used to build high-level QoS
policies. These high-level QoS policies control and manage low-level
QoS device mechanisms independent of the specific type of device that
is being managed. 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.
Second, different policy servers and applications may provision parts 1.1.1. Modeling Abstract QoS Policies
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 main goal of the QPIM is to create an information model that can be
used to help bridge part of the conceptual gap between a human policy
maker and a network element that is configured to enforce the policy.
Clearly this wide gap implies several translation levels, from the
abstract to the concrete. At the abstract end are the business QoS policy
rules. QPIM facilitates a formal representation of network QoS business
rules, thus providing the first concretization level: formally
representing humanly expressed QoS policy.
The information model presented in this document contains information When a human business executive defines network policy, it is usually
that can be shared by other network policy managers (e.g., Security done using informal business terms and language. For example, a human may
managers, IP address managers, and others). Examples include sharing of utter a policy statement that reads: "traffic generated by our human-
the same definition of well-known application port numbers, IP resources application should have higher priority for making it through
addresses of servers and other network attributes. It allows checking to its destination compared to traffic generated by people browsing the
of consistent behaviors of the interaction between the different WEB during their lunch breaks". While this statement clearly defines QoS
managers by comparing, for example, the set of QoS and security actions policy for the network, the network itself cannot enforce it. Translation
enforced on the same set of flows. to "network terms and language" is required.
The remainder of this document presents, describes and defines the On the other end of the scale, a network element functioning as a Policy
QoS Policy Information Model (QPIM). QPIM is a set of entities and Enforcement Point (PEP, see [TERMS] for its definition), such as a
relationships (both modeled by classes) that define managed objects and router, can be configured with specific commands that determine the
operational parameters of its inner working QoS mechanisms. For example,
the (imaginary) command "output-queue-depth = 100" may be an instruction
to a network interface card of a router to allow up to 100 packets to be
stored before subsequent packets are discarded (not forwarded). On a
different device within the same network, the same instruction may take
another form, because a different vendor built that device or it has a
different set of functions, and hence implementation, even though it is
from the same vendor. In addition, a particular PEP may not have the
ability to create queues that are longer than, say, 50 packets, which may
result in a different instruction implementing the same business policy.
Snir, Ramberg, Strassner, Cohen expires May 2001 7 Snir, Ramberg, Strassner, Cohen expires November 2001 5
interactions between managed objects that can be used to define, The first example illustrates 'abstract policy', while the second
manage, and control IntServ and DiffServ QoS mechanisms using policies. illustrates 'concrete configuration'. Furthermore, the first example
It uses basic concepts defined in [PCIM] but extends those to control illustrates end-to-end policy, which covers the conditioning of
IntServ and DiffServ QoS mechanisms. Since QPIM is an information model application traffic throughout the network. The second example
(and is therefore independent of any specific data storage mechanism illustrates configuration for a particular PEP or a set thereof. While an
and access protocol limitations), this document is limited to end-to-end policy statement can only be enforced by configuration of PEPs
discussing the different managed objects that are used to define and in various parts of the network, the information model of policy and that
provision IntServ and DiffServ QoS policies. Relationships to the Core of the mechanisms that a PEP uses to implement that policy is vastly
schema [PCLS] and issues related to mapping this information to a form different.
suitable for implementation in a directory, along with correct usage of
the mapped schema, are defined in [QOSSCHEMA].
2. Information Model Hierarchy The translation process from abstract business policy to concrete PEP
configuration is roughly expressed as follows:
This section discusses the relationships between the Policy Core 1. Informal business QoS policy is expressed by a human policy maker
Information Model [PCIM], the QoS Policy Information Model (QPIM, (e.g. "All executives' WEB requests should be prioritized")
which is this document) and future extensions of the QPIM. 2. A network administrator models the informal policy by using QPIM
constructs, thus creating a formal representation of the abstract
policy. (e.g. "If packet's protocol is HTTP and its destination is in
the 'EXECUTIVES' user group, then assign IPP 7 to the packet header").
Note that the administrator is very likely to use a particular data
model (e.g., LDAP schema) that is mapped to QPIM.
3. The network administrator maps the abstract, formal policy to PEPs
(most likely by using roles, as specified in [PCIMe, sections 2.2.4
and 4.6]).
4. A configuration/distribution agent (or a PDP see [TERMS] for its
definition) consults a device capability model to determine how to
translate the policy into device configuration. An example for a
standards-based capability model is [QDDIM]. Note that one or more
such translations are possible, depending on the particular
capabilities of a given PEP and the implementation of the system.
5. For each PEP in the network, the configuration/distribution agent
configures the appropriate instructions to enforce the policy.
2.1 Relationship Between the PCIM and This Document QPIM is intended to be the bridging mechanism between step #1 and step #2
in the methodology just described.
This document both extends concepts that are part of the [PCIM] and 1.1.2. Enhancing Interoperability
adds new functions that are not part of the [PCIM].
The [PCIM] models high-level policy concepts and introduces structural Another goal of QPIM is to facilitate interoperability among policy
conventions and nomenclature common to all types of policies. The systems, PDPs in particular. QPIM accomplishes its interoperability goal
fundamental purpose of the [PCIM] is to provide a generic by standardizing a representation of policy. Producers and consumers of
representation of the structure of a policy rule, along with a set of QoS policy need only rely on QPIM-based schemata (or data models) to
classes and relationships that can serve as a common representation of ensure mutual understanding and agreement on the semantics of QoS policy.
policy groups, rules, conditions, and actions. This enables derived For example, suppose that a QoS policy management application, built by
information models and schemata to use a common set of terminology, vendor A, writes its policies based on an LDAP schema that maps from QPIM
classes, and approaches, thus facilitating interoperability. to a directory implementation.A separately built PDP from vendor B may
then read this policy and "understand" it as both the management
application and the PDP were architected to comply with the QPIM
standard.
The QPIM refines and extends the concepts of the [PCIM] by introducing Snir, Ramberg, Strassner, Cohen expires November 2001 6
a framework of classes and relationships dedicated to model IntServ and
DiffServ QoS Policies. This set of classes and relationships can be
used to configure and manage devices that are compliant with either the
integrated services [Intserv] and/or with the differentiated service
approach [Diffserv].
2.1.1 Extension of Concepts in the PCIM Interoperability of QPIM producers/consumers is by definition at a high
level, and does not guarantee that the same policy will result in the
same PEP configuration. First, different PEPs will have different
capabilities and functions, which necessitate different individual
configurations even if the different PEPs are controlled by the same
policy. Second, different PDPs will also have different capabilities and
functions, and may choose to translate the high-level QPIM policy
differently depending on the functionality of the PDP as well as the
capabilities of the PEPs that are being controlled by the PDP. Finally,
the same policy may be interpreted slightly differently depending on
various factors. For example, a QPIM policy rule that reads "If packet's
protocol is HTTP then assign 7 to IPP", may result in different
configurations depending on how that rule is implemented. For example, an
application recognition mechanism can be used to enforce the policy. If
the device does not supports this particular mechanism, then an alternate
mechanism must be used. For example, the packets could be classified
based on their destination TCP port.
The QPIM extends three fundamental concepts defined in [PCIM] in order Therefore, we define interoperability of QoS policies as the ability to
to be able to define policies that can control, manage and provision specify a policy rule in a standard format. The advantage is that such a
the QoS mechanisms of devices. These are hierarchical policy policy can be understood by PDPs and PEPs manufactured from different
repositories, extensions to reusable objects, and extensions to the vendors having different capabilities and functionality, as well as
structure of a policy rule. policy-based applications. We specifically do not require a policy to be
translated into exactly the same configuration in different PEPs. This is
why we view the above two systems that differ in the interpretation of
recognizing WEB traffic as interoperable with regard to policy. The
advantage of using QPIM policies is that incompatible device capabilities
may still be employed and controlled using the QPIM policy.
Snir, Ramberg, Strassner, Cohen expires May 2001 8 1.1.3. Intended Audiences
2.1.1.1 Hierarchical Policy Repositories QPIM is intended for several audiences. The following lists some of the
intended audiences and their respective uses:
The concept of a "nested" policy repository (i.e., a repository that 1. Application vendors who build QoS policy management applications can
is embedded within another repository) that contains policy use this model as an extensible framework for defining policies to
information, was originally defined in an earlier version of the QPIM. control PEPs and PDPs in an interoperable manner
It has subsequently been moved into the [PCIM], since it is a general 2. Developers of Policy Decision Point (PDP) systems can use this
concept that is not limited to QoS, and can be used by other framework to develop interoperable policies
applications. This document reuses this concept, but defines specific 3. QoS policy makers who seek a standardized model for expressing a
refinements for using "embedded policy repositories" to accommodate the formal representation of QoS policy can use this model to control PEPs
application-specific needs of QoS provisioning. These reflect the need of varying capabilities and functionality
to provide nested levels of administration and scoping to policies and 4. Builders of large organization data and knowledge bases who decide to
policy information. combine QoS policy information with other networking policy
information, assuming all modeling is based on [PCIM] and [PCIMe]
5. Authors of various standards may use constructs introduced in this
document to enhance their work. Authors of data models wishing to map
a storage specific technology to QPIM must use this document as well.
2.1.1.2 Extensions to Reusable Objects Snir, Ramberg, Strassner, Cohen expires November 2001 7
Similarly, the concepts of reusable objects vs. rule-specific objects 1.2. QPIM Characteristics
have been moved from an earlier version of this document to the [PCIM].
In addition, this document defines specific extensions to guide the
implementation of reusable- vs. rule-specific QoS objects.
2.1.1.3 Extensions to the Structure of a Policy Rule First, a general statement that characterizes QPIM:
This document also extends the concept of a policy rule. It is "The QoS Policy Information Model (QPIM) establishes a standard framework
important to note that this is done without having to redefine or and constructs for specifying and representing business QoS policies.
subclass of PolicyRule (as defined in [PCIM]), because if that was This framework consists of a set of classes and relationships, organized
done, then interoperability would be adversely affected. This document in an object-oriented information model. It is agnostic of any specific
also defines additional conditions and actions that are specific to PDP or PEP implementation and independent of any particular QoS
QoS. It further defines different types of actions that target DiffServ technology mechanism. It is intended to be used to control the
and IntServ actions. provisioning of end-to-end network services."
2.1.2 Addition of New Concepts Not in the PCIM In the rest of this section, we itemize and expand the general statement
presented above.
There are several notable new concepts that are not part of the [PCIM]. 1. QPIM, as the name implies, is a QoS Policy Information Model. This
These include rule nesting, rule decision strategy, compound means that it only models QoS concepts. These concepts are either
conditions, pre-defined variables and constants, and Per Hop Behavior derived in this document, or adapted for use in modelingQoS from other
definition, as part of the QoS actions. documents.
2.1.2.1 Rule Nesting 2. QPIM is an information model. As such, it is independent of any
specific data storage mechanism and access protocol. QPIM's constructs
may be mapped to various storage and data organization technologies. A
data model mapped to QPIM can be created in a relational database, an
object oriented database, an LDAP directory and more. Because QPIM is
not a schema, the reader is encouraged to focus on the conceptual
level and not on the data organization methodology. Clearly a mapped
schema would include enhancements and optimizations not appropriate in
the information-modeling realm. For example, a given association
between two classes is always modeled as an association class in QPIM.
A given schema may find it useful and efficient to model such a
relationship using a reference object attribute in a directory or a
keyforeign key relationship in a relational database.
The [PCIM] defines the ability to group policy rules by defining the 3. QPIM is standard. The model standardizes the process of specifying
policyGroup class. This class can be used to contain a set of business QoS policies. It is an interpretation and extension of the
policyRules and/or a set of policyGroups. This grouping mechanism core policy information model as defined in [PCIM] and [PCIMe]. It
allows for constructing a flexible and extensible information model. references other IETF standards (e.g. [TERMS], [DIFFSERV] and others)
However, it treats PolicyRules as atomic objects that can contain only and is meant to enhance interoperability of QoS systems from different
conditions and actions. In practice, this is not flexible enough for vendors.
some of the needs of IntServ and DiffServ.
Snir, Ramberg, Strassner, Cohen expires May 2001 9 QPIM establishes a conceptual framework by fully and closely following
the core policy framework as specified in [PCIM] and [PCIMe]. QPIM
inherits all of its constructs from the core model, providing QoS
interpretation and extensions where necessary.
Therefore, this document adds the concept of nesting one or more policy 4. QPIM is object oriented. The modeling methodology is based on UML
rules within a policy rule. For example, one could think of a policy (Unified Modeling Language [UML]. This is a ubiquitous modeling method
rule that controls how a user logs onto the network as consisting of that is easy to understand and read. In addition, UML-based models
two parts. A high-level rule is used to group together a set of lower- lend themselves to further extensions and natural progression toward
level rules that are invoked at various stages of processing (e.g., how detailed data models.
the user is authenticated, how the IP Address is assigned, etc.). The
high-level rule would also contain information to properly control the
execution sequence of the lower-level rules, as well as to provide a
consistent and conceptually simpler interface to other objects in the
system. This is implemented by allowing a PolicyRule to contain a
PolicyRule or a PolicyGroup as one of its components.
2.1.2.2 Rule Decision Strategy Snir, Ramberg, Strassner, Cohen expires November 2001 8
Since there is no concept of nested rules in the [PCIM], there is no 5. QPIM is a formal model. It expresses its concepts by describing and
need for a decision strategy to be used to define the order of defining classes and inter-class associations. Classes are formal
processing of these rules. However, since QPIM allows for nested rules, definitions of major concepts. For example, the concept of a traffic
different examples of decision strategies must be defined in this profile is represented by the QosPolicyTrfcProf (abstract) class. A
document and shown that they can work in this new environment. This derivative of this class provides several attributes to describe the
document defines two such decision strategies: match-first and match- traffic in terms of average rate and other characteristics.
all. Both define an ordering that can be applied to a set of Associations represent relationships among instances of different
policyRules and policyGroup objects within a larger context (e.g., a classes or the same class. For example, the association
policy domain). This in turn controls the execution of different policy QoSPolicyViolateAction links a certain restriction on traffic
actions. Note that choosing a different decision strategy is one way to (represented by an instance of the QoSPolicyPoliceAction class) to an
change the result of executing a set of policy rules without changing action to be taken when the restriction is violated.
the policy rules themselves.
2.1.2.3 Compound Conditions 6. QPIM is abstract. The model is aimed at the formalization of humanly
expressed business QoS policies. For example, QPIM provides the means
of expressing formally a business policy that states: "In our network,
IP telephony should receive the same service quality as that of our
legacy phone systems". QPIM provides the topmost link from the
abstract business policy to the concrete device implementation by
expressing the abstract business policy in high-level networking
terms. QPIM compliant tools can be built to further concretize the
high-level QoS policies defined in QPIM terms so that actual network
elements (PEPs) can be configured to enforce the abstract business
policy.
[PCIM] defines conditions that consist of a single term. [PCIM] allows 7. QPIM is QoS technology-agnostic, as it assumes no particular mechanism
such conditions to be logically combined using 'AND' and 'OR' terms. (e.g., class-based weighted fair queuing) for policy enforcement. For
This makes sense, because all conditions can be constructed from such example, a certain policy may require that traffic adhere to a given
primitives. However, a richer means of representing common conditions traffic profile. The traffic profile itself can be represented by an
is called for. instance of the QosPolicyTrfcProf class. The properties of the profile
class may include an attribute representing the average rate of
traffic in units of bits per second. However, QPIM neither describes
nor mandates a mechanism to perform the measuring mechanism itself.
Specifying such mechanisms is in the realm of network modeling, not
policy modeling.
This document extends the concept of a simple (i.e., one-term) Though a particular QoS mechanism (e.g., class-based weighted fair
condition to define compound conditions. This is conceptually queuing) is generic to many types of devices, individual devices may
equivalent to using a set of simple conditions. However, supporting implement this generic mechanism differently. This necessitates a
compound conditions enables a better matching of the information model device-independent view of controlling QoS mechanisms, which is
to the environment that it is modeling, and also simplifies the mapping precisely what QPIM is intended for. A single QPIM policy can be
of the information model to different types of data models. In translated into different configurations of different devices. For
addition, it enhances the manageability and reusability of complex example, a network interface card that can be configured to implement
conditions. Therefore, the classes and relationships needed to build several output queues and assign size and bandwidth allocation
this in as efficient a manner as possible are defined in this document. parameters to each of them is a concrete element whose configuration
can be controlled with QPIM policies.
2.1.2.4 Pre-Defined Variables and Constants Snir, Ramberg, Strassner, Cohen expires November 2001 9
This document also defines a set of variable and constant definitions 8. QPIM adheres to and interprets the two predominant QoS paradigms:
for use with QoS policies. This concept is not present in the [PCIM] Differentiated (DiffServ) Services and Integrated Services (IntServ).
While both DiffServ and IntServ inherently model technology, the
mechanisms implementing those technologies are not specified and are
left to the implementer's interpretation. DiffServ and IntServ are
described in [DIFFSERV] and [INTSERV], respectively. The term RSVP
refers to a protocol developed to implement IntServ [RSVP]. The terms
IntServ and RSVP are sometime used interchangeably.
Snir, Ramberg, Strassner, Cohen expires May 2001 10 9. QPIM is a network-end-to-end model. This means that QPIM policies can
describe the QoS allocated to traffic throughout the network. QPIM
does not represent explicitly network topological concepts. Section
4.6 of [PCIMe] explains a role based mechanism that can be used for
mapping policies to PEPs. Neither [PCIM], [PCIMe] nor [QPIM] require a
particular topological view of the network in order to express
abstract policy.
because the purpose of the [PCIM] is to provide a general structure for 1.3. QPIM and Other Published Standards
representing policy rules, conditions and actions. Variable and
constant definitions represent specific concepts that have pre-defined
semantics.
This version of this draft has these elements residing in this draft. QPIM makes extensive use of the concepts and constructs that are
However, they have been generalized so that other applications besides introduced by [PCIM] and [PCIMe]. The entire QPIM class hierarchy is
QoS can use them. derived from [PCIM] and [PCIMe] classes. The concepts of policy, policy
groups, policy conditions, reusable objects values and variables are used
in QPIM directly. QPIM only introduces extensions where QoS actions,
values and variables are necessary to add QoS specific semantics to the
framework defined by [PCIM] and [PCIMe].
2.1.2.5 Per-Hop Behaviors By modeling the information of both predominant QoS paradigms, DiffServ
and IntServ, QPIM unifies the two methodologies using a single class
inheritance tree, thus allowing a single context for thinking about QoS
policy.
Finally, QoS Policy definition may require the notion of a Per-Hop Companion documents (e.g., [QoSSCHEMA]) define the mapping of QPIM's
Behavior (specified by the differentiated services paradigm). This classes to specific data models (schemata). For example, [QoSSCHEMA]
document provides interpretation for this notion by providing a way to defines how to map the data in this information model to a form that can
represent Per-Hop Behaviors using policy rules. be stored in a directory that uses LDAPv3 as its access protocol.
2.1.3 Mapping to a Directory QPIM adheres to terminology as defined in [TERMS].
The PCIM and QPIM are both inherently extensible. Furthermore, they are QPIM intentionally avoids references to documents that present network
designed to fit together to produce one "virtual" information model. As models. A network model is the OBJECT of policy. QPIM models the SUBJECT
such, both are independent of any particular data storage mechanism and of policy. The latter distinction makes it inappropriate for QPIM to
access protocol. However, mappings can be defined to translate the data model the actual network. An example for network modeling is available in
from this single virtual information model to a form that can be [QDDIM], a document that models QoS device data path and capabilities.
implemented in a specific type of data storage mechanism 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 Snir, Ramberg, Strassner, Cohen expires November 2001 10
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. This is best done by
extending the set of classes and relationships defined in this
document, as opposed to redefining new concepts that are not compatible
with either this document or PCIM.
2.2 High-Level Class Hierarchy 2. Class Hierarchies
The following diagram shows how the classes in this document relate to 2.1. Inheritance Hierarchy
the classes defined in the PCIM.
Snir, Ramberg, Strassner, Cohen expires May 2001 11 QPIM's inheritance hierarchy is rooted in [PCIM] and [PCIMe]. Figures 1
and 2 depict the QPIM inheritance hierarchy while noting its
relationships to [PCIM] and [PCIMe] classes. Figure 1 shows the QPIM
inheritance hierarchy,.
[unrooted] [ManagedElement] (abstract, PCIM)
| |
+--Policy (abstract, defined in PCIM) +--Policy (abstract, PCIM)
| | | |
| +---PolicyGroup (PCIM) | +---PolicyAction (abstract, PCIM)
| | | | | |
| | +---qosPolicyDomain (this document) | | +---SimplePolicyAction (PCIMe)
| | | |
| | | +---QoSPolicyRSVPSimpleAction (QPIM)
| | | | | |
| | +---gpsPolicyGroup (this document) | | +---QoSPolicyDiscardAction (QPIM)
| |
| +---PolicyRule (PCIM)
| |
| +---PolicyCondition (abstract, defined in PCIM)
| | | | | |
| | +---PolicyTimePeriodCondition (PCIM) | | +---QoSPolicyAdmissionAction (abstract, QPIM)
| | | |
| | | +---QoSPolicyPoliceAction (QPIM)
| | | |
| | | +---QoSPolicyShapeActionAction (QPIM)
| | | |
| | | +---QoSPolicyRSVPAdmissionAction (QPIM)
| | | | | |
| | +---VendorPolicyCondition (PCIM) | | +---QosPolicyPHBAction (abstract, QPIM)
| | | | | |
| | +---gpsPolicySimpleCondition (this document) | | +---QoSPolicyBandwidthAction (QPIM)
| | | | | |
| | +---gpsPolicyCompoundCondition (this document) | | +---QoSPolicyCongestionControlAction (QPIM)
| | | |
| +---PolicyAction (abstract, defined in PCIM) | +---QosPolicyTrfcProf (abstract, QPIM)
| | | | | |
| | +---VendorPolicyAction (PCIM) | | +---QosPolicyTokenBucketTrfcProf (QPIM)
| | | | | |
| | +---qosPolicyPRAction (this document) | | +---QosPolicyIntServTrfcProf (QPIM)
| |
(continued on the next page)
Snir, Ramberg, Strassner, Cohen expires November 2001 11
(continued from the previous page)
[ManagedElement] (abstract, PCIM, repeated for convenience)
|
+--Policy (abstract, PCIM, repeated for convenience)
| |
| +---PolicyVariable (abstract, PCIMe)
| | | | | |
| | +---qosPolicyPHBAction (this document) | | +---PolicyImplicitVariable (abstract, PCIMe)
| | | | | |
| | +---qosPolicyRSVPAction (this document) | | +---QoSPolicyRSVPVariable (abstract, QPIM)
| | | | | |
| | +---qosPolicyRSVPSignalCtrlAction (this document) | | +---QoSPolicyRSVPSourceIPv4Variable (QPIM)
| | | | | |
| | +---qosPolicyRSVPInstallAction (this document) | | +---QoSPolicyRSVPDestinationIPv4Variable (QPIM)
| |
| +---gpsPolicyTrfcProf (this document)
| | | | | |
| | +---qosPolicyPRTrfcProf (this document) | | +---QoSPolicyRSVPSourceIPv6Variable (QPIM)
| | | | | |
| | +---qosPolicyRSVPTrfcProf (this document) | | +---QoSPolicyRSVPDestinationIPv6Variable (QPIM)
| |
| +---gpsPolicyVariable (abstract, this document)
| |
| +---gpsPolicyValue (abstract, this document)
| | | | | |
| | +---gpsPolicyIPv4AddrValue (this document) | | +---QoSPolicyRSVPSourcePortVariable (QPIM)
| | | | | |
| | +---gpsPolicyIPv6AddrValue (this document) | | +---QoSPolicyRSVPDestinationPortVariable (QPIM)
(continued on next page)
Snir, Ramberg, Strassner, Cohen expires May 2001 12
(continued from previous page)
[unrooted]
|
+--Policy (abstract, defined in PCIM, repeated for convenience)
| |
| +---gpsPolicyValue (this document, repeated for convenience)
| | | | | |
| | +---gpsPolicyMACAddrValue (this document) | | +---QoSPolicyRSVPIPProtocolVariable (QPIM)
| | | | | |
| | +---gpsPolicyStringValue (this document) | | +---QoSPolicyRSVPIPVersionVariable (QPIM)
| | | | | |
| | +---gpsPolicyBitStringValue (this document) | | +---QoSPolicyRSVPDCLASSVariable (QPIM)
| | | | | |
| | +---gpsPolicyDNValue (this document) | | +---QoSPolicyRSVPStyleVariable (QPIM)
| | | | | |
| | +---gpsPolicyAttributeValue (this document) | | +---QoSPolicyRSVPDIntServVariable (QPIM)
| | | | | |
| | +---gpsPolicyIntegerValue (this document) | | +---QoSPolicyRSVPMessageTypeVariable (QPIM)
| | | | |
| +---gpsPolicyMeter | | +---QoSPolicyRSVPPreemptionPriorityVariable (QPIM)
| | | | |
| +---qosPolicyQueue | | +---QoSPolicyRSVPPreemptionDefPriorityVariable (QPIM)
| | |
| | +---QoSPolicyRSVPUserVariable (QPIM)
| | |
| | +---QoSPolicyRSVPApplicationVariable (QPIM)
| | |
| | +---QoSPolicyRSVPAuthMethodVariable (QPIM)
| | | |
+--CIM_ManagedSystemElement (abstract, defined in PCIM) | +---PolicyValue (abstract, PCIMe)
| | | |
+--CIM_LogicalElement (abstract, defined in PCIM) | | +---QoSPolicyDNValue (QPIM)
| | | |
+--CIM_System (abstract, defined in PCIM) | | +---QoSPolicyAttributeValue (QPIM)
|
+---CIM_AdminDomain (abstract, defined in PCIM)
|
+---PolicyRepository (PCIM)
3. QPIM Hierarchies
QPIM, following the information organizational paradigm of [PCIM], is
an object-oriented information model. As in [PCIM], this model defines
two hierarchies of object classes: structural classes representing
policy information and control of policies, and relationship classes
that indicate how instances of the structural classes are related to
each other.
In the rest of this section, we describe the organization and structure
of the QPIM hierarchies. Section 3.1 expands the previous paragraph and
describes the inheritance and relationship hierarchies that are used in
the construction of the QoS information hierarchies. Section 3.2
describes how the different information hierarchies can be used to
build the desired information hierarchies of the policy application.
Snir, Ramberg, Strassner, Cohen expires May 2001 13
Section 3.3 describes the structure of the reusable objects repository.
Finally, section 3.4 explains the relationships between the domain data
tree and the reusable-object repositories.
3.1 Class and Relationship Hierarchies Defined in the QPIM
The QPIM consists of two hierarchies: an inheritance hierarchy that is
used to define a set of classes that represent entities in the managed
policy environment, and a relationship hierarchy that is used to define
a hierarchy of relationships that describe how different objects
interact with each other. These hierarchies work together to describe
entities in the managed environment and how they relate to and interact
with each other.
Two relationship constructs are used in the formal presentation of
QPIM. The first is an association, which models different types of
dependency relationships between two (or theoretically more) objects.
The second is an aggregation, which is a strong form of association
that typically represents a "whole-part" or a "containment"
relationship.
Both associations and aggregations are modeled as classes that contain
references to the objects that are participating in the relationship.
In addition, both associations and aggregations can be defined between
classes without affecting any of the related classes. That is, the
addition of either an association or an aggregation does not affect the
function or structure of the related classes.
Note that containment is a directional relationship - the containing
entity is known as the aggregate (the "whole" side of the
relationship), and the contained entities are known as the components
(the "part of" side of the relationship). For example, the relationship
between a policy container (e.g., gpsPolicyGroup, which is defined in
this document as a subclass of PolicyGroup, which is defined in [PCIM])
and the rules it contains (e.g., PolicyRule, which is defined in
[PCIM]) is modeled by an aggregation (PolicyRuleInPolicyGroup, which is
defined in [PCIM]). However, the association between a reusable object
and the repository in which it resides models a "resides-in"
relationship rather than "part-of" relationship. This is because a
given reusable object can reside in any repository according to the
discretion of the administrator - there is no whole-part relationship
connoted by placing a reusable object in a repository. Rather, there is
only a dependency relationship that states that in order to find the
given reusable object, you must look in this particular repository. On
the other hand, there is a whole-part relationship established when a
policy container, such as a PolicyGroup or a gpsPolicyGroup, is used to
contain a particular PolicyRule. Now, we are adding specific semantics
that say that a particular PolicyRule is-a-part-of a given policy
container.
Snir, Ramberg, Strassner, Cohen expires May 2001 14
Relationship classes may be used to extend the semantics of the
relationship beyond the basic containment or reference concepts. For
example, a relationship class may contain added attributes that add
particular semantics. For example, the PolicyConditionInPolicyRule
aggregation defines the relationship between a PolicyRule and a set of
policy conditions (PolicyCondition, defined in [PCIM]). In this case,
the PolicyRule acts as a container, and can hold zero or more
PolicyConditions (which are the contained objects). Since this is
expressing a whole-part relationship, it is modeled as an aggregation.
However, this aggregation class carries two additional properties:
GroupNumber and ConditionNegated. These properties are used to add to
the relationship itself the semantics of sub-grouping of conditions and
whether to prepend a Boolean 'NOT' operator to the condition.
Implementers of a particular QoS Policy system may further sub-class
relationships to incorporate additional application-specific semantics
as required.
Comprehensive presentation of relationships and their modeling is
available in [PCIM].
Two important examples of using aggregation are composition and
scoping. An example of composition is the PolicyRule. It has its own
attributes, but it is only complete when it is used in conjunction with
a set of conditions and actions. Conceptually, a PolicyRule serves as a
container that aggregates a set of PolicyCondition objects and a set of
PolicyAction objects. An example of scoping is grouping objects under a
single container (e.g., qosPolicyDomain) so that common administrative
rules can be applied to all of the objects in a container.
3.2 Implementation Guidelines
The QPIM defines two information hierarchies. Objects that are to be
managed are represented by the classes in the inheritance hierarchy.
Behavior that is to be represented and managed is represented by the
classes in the relationship hierarchies. An implementation is not
complete if just the class inheritance hierarchy is implemented - both
hierarchies MUST be implemented.
Many data storage technologies are incapable of directly representing
relationships. However, all data storage mechanisms of interest can
either emulate relationships or have specific constructs that can
implement some, but not all, relationships. For example, an LDAP based
directory does not have the concept of a general dependency
relationship (although one can be implemented in a variety of ways),
but it does have the concept of a containment relationship.
In general, an implementation will define two types of information. The
first type of information is policy definition data. This information
consists of policy rules and groups, and the components of policy
Snir, Ramberg, Strassner, Cohen expires May 2001 15
rules, that are used to govern the application of policies to manage
entities. The second type of information is a set of nested containers
that form a hierarchy for storing and managing reusable objects.
For applications that want to manage and control QoS, containers
provide significant convenience benefits. Containers can be used to
group similar policies and policy information together in order to make
the policy data easier to manage. They also enable an organization to
impose its own views of organizing policies and policy information in
the data store. This is done in QPIM by enabling a single monolithic
repository to be conceptually divided into a set of repositories that
reflect the administrative use of the policies. To this end, the QPIM
not only supports the use of containers for grouping information, but
also for determining execution semantics of policy rules.
3.2.1 Modeling Containment
Containment is a general concept that is expressed in an information
model using either an association or (more usually) an aggregation.
Different data stores have different characteristics (e.g., data
structures, organization of data, and access protocols). Therefore,
there will be many mappings from a single information model, one for
each type of data store. This means that containment may be expressed
differently in each mapping. However, this document makes no explicit
or implicit assumptions about the storage mechanism, access protocol,
or other characteristics of different data stores. The information
model presented here can be mapped to most storage mechanisms and
models, such as LDAP directories, relational DBMS, SMI, and others.
For example, the basic mechanism used for expressing containment when
mapping to a directory is placement of the objects in the data tree. To
express the relationship of "container - contained" between a container
object and the objects it contains, the contained objects are placed
below the container object. In a relational database system, on the
other hand, this relationship may be implemented by means of various
key/foreign-key join mechanisms.
In QPIM (as well as in [PCIM]) an object may be related to its
container in one of two ways. We refer to these methods as "ad-hoc"
containment and "indirect" containment, as follows:
1. To establish ad-hoc containment the object is created and is
associated to its container by means of an instance of the
appropriate aggregation class.
2. To establish indirect containment the object is created and placed
in a reusable-object repository The contained object must be given a
unique name that is scoped by the containing repository. The
instance of the aggregation class must now contain a reference to
the reusable object.
Snir, Ramberg, Strassner, Cohen expires May 2001 16
The difference between ad-hoc objects and reusable objects is that ad-
hoc objects need not be named - they are implicitly scoped by their
containing object. However, reusable objects must be uniquely named so
that the object that is referencing them can differentiate between
reusable objects of the same type.
Reusable-object repositories facilitate the central management of
commonly referenced objects like named conditions and actions, or
commonly occurring variables and values that are used in conditions.
3.2.2 Implementing Relationships
[PCIM] recommends that relationships be implemented as classes. In
[PCIM] (as well as in QPIM), aggregation and association classes serve
these two purposes:
1. Model a relationship between two objects. One of the most important
types of relationships for QoS is containment. Relationships are
used in QPIM to model the relation between a container entity and
its contained entities.
2. Unify the containment model so that both ad-hoc and indirectly
contained objects (which are accessed in a reusable-object
repository) are treated identically
The following paragraphs explain how the three purposes are
accomplished.
3.2.2.1 Relationship modeling
A relationship class models containment (as well as other types of
dependencies) as a set of (usually bi-directional) references. For a
binary relationship (which is the overwhelming majority of
relationships used), one reference property points to an object on one
side of the relationship while another property points an object in the
other side of the relationship.
Sometimes it is important for a relationship to express added
semantics. Since a relationship is modeled as a class, the relationship
itself may use all the power of class design. This means that in [PCIM]
and QPIM, relationships can contain properties and methods, and may
take advantage of inheritance. For example, the relationship may be
assigned properties that are used to represent specific semantics of
the relationship itself. For example, if the information order requires
some sub-grouping of the contained object, as is the case for
conditions in a policy rule (e.g., PolicyCondition, which is defined in
[PCIM]), then the corresponding relationship class (e.g.,
PolicyConditionInPolicyRule, which is defined in [PCIM]) will have a
corresponding property (i.e., GroupNumber) that represents the group
membership number. This is a technique that enhances the independence
of the two objects on both ends of a relationship, because such
Snir, Ramberg, Strassner, Cohen expires May 2001 17
properties connote that their values reflect the relationship itself
and not an inherent property of either object participating in the
relationship. In other words, the container doesn't carry constituent
specific information, and the contained object is independent from
other contained objects and its container.
3.2.2.2 Representing Containment in a Consistent Manner
Recall that a container may contain reusable objects as well as "ad-
hoc" objects. The contained objects themselves are not "aware" of their
reusability status; there's no property in the contained object class
that denotes reusability. The aggregation relationship is also unaware
of whether the contained object happens to be reusable or not. It
merely carries a reference to this object in one of its properties
(e.g., the PartComponent property of the PolicyConditionInPolicyRule
class, defined in [PCIM]). The membership of an object in a reusable-
object repository is represented by an association between the
particular repository and the member object. It is fully expressed by
this association so that the repository, the container and the
contained objects can be independent. This approach also contributes to
data integrity and scalable data storage mapping implementation.
3.2.3 Mapping Differences and Examples
Mapping the information model to different data storage mechanisms may
result in various interpretations and implementations. To end this
section we'll discuss two comprehensive examples to illustrate some of
the issues concerning implementation and to highlight the flexible
design this model provides. Note that even for an LDAP directory, there
could be many different interpretations that result in different data
models. Two companion documents to QPIM, [PFSCHEMA] and [QOSSCHEMA],
specify a standard mapping of QPIM to an LDAP directory.
Example 1: Aggregation in LDAP directories
An LDAP aggregation class is specified to implement each aggregation
class in the information model. When adding a contained object to a
container, an instance of the aggregation class is created and the
aggregation property that points toward the contained object is
assigned a DN for that object. No distinction is possible (nor is it
desired!) between an aggregation instance for an ad-hoc object and that
of a reusable object.
All instances of the aggregation as well as all ad-hoc objects are
placed directly under the container instance in the DIT. When
collecting the contained object, a single LDAP search may be used to
fetch all objects residing directly under the container. A simple
procedure can determine if reusable objects exist and require added
fetch operations. The procedure scans the aggregation instances and
fetches those that have not already been fetched because they did not
reside in the node directly under the container. Fetching a reusable
Snir, Ramberg, Strassner, Cohen expires May 2001 18
object is done by using the DN in the aggregation property that
contains a reference to the contained object.
Example 2: Aggregation in a relational DBMS
No standards-based mapping has yet been defined for any RDBMS at this
time. This example merely studies a possible implementation.
We'll assume that the aggregation is "simple" and does not define any
additional properties to carry added semantics beyond the container-
contained relationship.
Two tables are of interest:
1. Container object class: A row exists for each container object of
this class.
2. Contained object class: A row exists for each contained object of
this class.
Because this is a "simple" relationship as described above, no special
relationship class is necessary. Instead, the contained object table
has a column that is a foreign key to the container object.
For example, suppose a container class C is implemented in a table CT
with a primary key column pkc. A contained object class CO is
implemented in a table COT with a foreign key column fkc (referencing
CT). When collecting contained objects in table COT for the container
object (which is table CT), the following SQL statement can do the job
through a simple join:
Select <properties list> from COT, C where COT.fkc == C.pkc;
Note, however, that this is a very restrictive implementation. It might
be advisable to implement a third table for the aggregation itself so
that adding columns to carry added semantics can be done without having
to redefine the schema.
3.3. QoS Domain Data Tree
The entity that represents a single policy hierarchy is called a QOS
Domain, and is modeled by the qosPolicyDomain class. This class is a
derivative of the PolicyGroup class in [PCIM].
Figure 1 shows a summary view of the QoS domain data tree hierarchy.
The text in parentheses refers to the explanations below the figure,
which provide specific semantics for each object in the hierarchy.
Snir, Ramberg, Strassner, Cohen expires May 2001 19
+---------------+
|qosPolicyDomain| (root of the data hierarchy)
+---------------+
| +----------+
|-->|policyRule| (a)
| +----------+
| | +------------------------+
| |-->|gpsPolicySimpleCondition| (b)
| | +------------------------+
| | +--------------------------+
| |-->|gpsPolicyCompoundCondition| (b)
| | +--------------------------+
| | | +------------------------+
| | |-->|gpsPolicySimpleCondition| (c)
| | | +------------------------+
| | | +--------------------------+
| | |-->|gpsPolicyCompoundCondition| (d)
| | +--------------------------+
| | +---------------+
| |-->|qosPolicyAction| (e)
| | +---------------+
| | +----------+
| |-->|policyRule| (f)
| | +----------+
| | +--------------+
| |-->|gpsPolicyGroup| (g)
| +--------------+
| +--------------+
|-->|gpsPolicyGroup| (h)
| +--------------+
| | +----------+
| |-->|PolicyRule| (i)
| | +----------+
| | +--------------+
| |-->|gpsPolicyGroup| (j)
| +--------------+
| +---------------+
|-->|qosPolicyDomain| (k)
+---------------+
Figure 1: Qos Domain Data Tree Hierarchy
Explanation to the relationships defined in figure 1:
a - Any number of PolicyRule instances may be contained by a given
qosPolicyDomain instance in the hierarchy by using the
PolicyRuleInPolicyGroup aggregation. This has the effect of making such
policyRules global for that container. Finer granularity can be
obtained by either nesting qosPolicyDomain instances (shown in
relationship (k)), or by embedding other types of containers (e.g.,
Snir, Ramberg, Strassner, Cohen expires May 2001 20
gpsPolicyGroup, which is shown in relationship h) within a given
qosPolicyDomain container. Note that gpsPolicyGroup objects can also be
nested, as shown in relationship (j).
b - Any number of qpsPolicySimpleCondition and
gpsPolicyCompoundCondition instances may be contained by a PolicyRule
instance via the PolicyConditionInPolicyRule aggregation.
c - Any number of gpsPolicySimpleCondition instances may be contained
by an instance of a gpsPolicyCompoundCondition via the
PolicyConditionInPolicyCompoundCondition aggregation.
d - Any number of gpsPolicyCompoundCondition instances may be contained
by an instance of a gpsPolicyCompoundCondition via the
PolicyConditionInPolicyCompoundCondition aggregation. The nested
containment combined with (c) above facilitates formation of arbitrary
Boolean expression and reuse of existing conditions as components of
such expressions.
e - Any number of qosPolicyAction instances may be contained by a
PolicyRule instance via the PolicyActionInPolicyRule aggregation.
f - Any number of PolicyRule instances may be contained by another
PolicyRule instance by using the PolicyRuleInPolicyRule aggregation.
This allows for recursively nesting policy rules within a given
policyRule instance, thus forming rule/sub-rule semantics.
g - Any number of gpsPolicyGroup instances may be contained by an
instance of PolicyRule via the PolicyGroupInPolicyRule aggregation.
This aggregation also implements a rule/sub-rule relationship similar
to the one defined in (f). However, it is somewhat richer, in that it
allows a complete policy container (i.e., a group of rules) to be
nested within a rule as a reusable unit.
h - Any number of gpsPolicyGroup instances may be contained by an
instance of a qosPolicyDomain via the PolicyGroupInPolicyGroup
aggregation.
i - Any number of PolicyRule instances may be contained by an instance
of a gpsPolicyGroup via the PolicyRuleInPolicyGroup aggregation.
j - Any number of gpsPolicyGroup instances may be contained within
another gpsPolicyGroup instance by using the PolicyGroupInPolicyGroup
aggregation. This allows for recursive nesting of groups of rules
within a given gpsPolicyGroup instance. This enables one policy
container to scope other contained policy containers. Note also that
all subclasses of PolicyGroup (e.g., both the gpsPolicyGroup as well as
the qosPolicyDomain class) inherit this relationship.
Snir, Ramberg, Strassner, Cohen expires May 2001 21
k - Any number of qosPolicyDomain instances may be contained by an
instance of a qosPolicyDomain class via the PolicyGroupInPolicyGroup
aggregation. This effectively enables the administrator to define a
hierarchical set of administrative roots within a single, larger
administrative scope.
3.4 Types of Grouping Classes
There are three fundamental types of grouping mechanisms defined in
this document, represented by three different classes. These are the
PolicyGroup, QoSPolicyDomain, and gpsPolicyGroup classes.
The PolicyGroup class is defined in PCIM. This class is a generalized
aggregation container. It enables either PolicyRules or PolicyGroups
to be aggregated in a single container. It has no properties and no
additional semantics.
The qosPolicyDomain class is defined in section 8.14 of this document.
This class is a subclass of PolicyGroup, and is used to define the root
of a single administrative QoS policy domain. As such, it contains the
domain's policy rules and other associated data. Note that additional
containers that are aggregated by this object can define additional
policy rules and other policy data that are specific to that level of
scoping. This class defines the following additional semantics compared
to a PolicyGroup:
- the root of a single administrative policy domain
- the decision match strategy to be employed by default for all
objects that are aggregated by this object (note that individual
containers may override this default behavior by defining their
own match strategies at their scoping level)
The gpsPolicyGroup class is defined in section 8.15 of this document.
This class is also a subclass of PolicyGroup, and represents an
administratively-defined policy rule container. All policies that are
commonly administered are defined in a particular gpsPolicyGroup. This
class defines the following additional semantics compared to a
PolicyGroup:
- the container is allowed to have its own priority; this enables it
to be treated the same as a policy rule when the order of execution
is determined
- the container is allowed to have its own decision match strategy
(note that this may be used to override the default match strategy
defined in a qosPolicyDomain)
- the container has a property that collects the roles and role-
combinations that are associated with all of the policy rules that
are aggregated by this container.
Snir, Ramberg, Strassner, Cohen expires May 2001 22
The difference between the qosPolicyDomain and the gpsPolicyGroup
classes are:
- the qosPolicyDomain class serves as the root of a policy domain;
the gpsPolicyGroup is not to be used for this purpose
- conceptually, gpsPolicyGroups are aggregated by a
qosPolicyDomain; the gpsPolicyGroups serve to provide a
finer level of granularity in defining and applying policies
- gpsPolicyGroups have roles and role-combinations, while
qosPolicyDomains do not
- gpsPolicyGroups have priorities, which qosPolicyDomains
do not
One final note: each of these classes can serve as a container in
various data store implementations. Thus, the more general term
"container" will be used in this document to refer to a class that can
aggregate objects. If special semantics are required, then either a
qosPolicyDomain or a gpsPolicyGroup will be specifically called out,
according to the desired semantics.
3.5. QoS Policy Domain Grouping and Nesting
The qosPolicyDomain class is used to establish a QoS policy domain
within a particular data store. Different objects can be placed in this
policy domain so that they can then be grouped together and managed
according to a common set of policies. However, sometimes a more
sophisticated organization of policy information is required. In this
case, multiple QoS policy domains may be grouped together to provide
more granular management of policy data.
Each domain may be viewed as a contiguous set of nodes that operate
under a common system of administration and provide a common set of
services. Each node can contain policy rules and/or policy information.
Grouping may be desired to enhance various administrative tasks (e.g.,
ensure that a set of objects are all updated), or it may be required by
a particular policy application. For example, a particular policy
application may need a combination of policy rules and other data.
Storing these different data in a common container in a domain that
belongs to that application considerably simplifies this process.
The grouping strategy (as well as all location-oriented strategies) is
left for users and vendors to model, based on their unique situations
and requirements. This document presents guidelines and recommendations
for constructing QoS domains and grouping objects within a QoS domain.
Specific implementations may use other techniques to construct QoS
domains and to group objects within a QoS domain without violating the
integrity and consistency of the QPIM as long as two constraints are
met. First, the implementation MUST NOT define a class that performs
the same function as a QPIM class. If a QPIM class is deemed
Snir, Ramberg, Strassner, Cohen expires May 2001 23
insufficient for a specific application, then that application SHOULD
derive a subclass from the QPIM class (as opposed to build a parallel
class that conflicts with the QPIM class). Second, the implementation
MUST NOT redefine QPIM classes in any way. This includes, but is not
limited to, canceling (also called deleting) attributes, renaming
attributes, or changing the purpose that a class or attribute was
designed for.
One way to group QoS policy domains is by creating a common root (which Figure 1. The QPIM Inheritance Hierarchy
is not necessarily modeled in this document) for several QoS policy
domain data tree instances. This can be done by using the PolicyGroup
(defined in [PCIM]) class as a root for the multi-domain tree (but
other objects may be used as well). In this case, all that is needed is
to implement a containment of a the appropriate number of
qosPolicyDomain (defined in this document) instances within the
appropriate PolicyGroup instance.
Figure 2 is an example that depicts the ability to provide different Snir, Ramberg, Strassner, Cohen expires November 2001 12
classes of service to different organizations within a single
enterprise. In this example, the enterprise is represented by an
instance of the PolicyGroup class. The different organizations are each
represented by a separate QoS policy domain (which is an instance of
the qosPolicyDomain class). Each qosPolicyDomain class is used as a
container to hold all of the policies for a given portion of the
organization. In Figure 2, this level is represented by the nesting
level of qosPolicyDomain classes that constitute the hierarchy of
container classes shown in Figure 2.
Each qosPolicyDomain instance serves as a container that contains an 2.2. Relationship Hierarchy
ordered list of related QoS policy rules that apply to a different part
or function of the domain (e.g., Eastern Sales vs. Western Sales). This
grouping is done using instances of the gpsPolicyGroup class.
The gpsPolicyGroup class would in turn contain either a set of
PolicyRule instances, a set of PolicyGroup instances (to provide
further grouping of policy rules that are scoped by a given
gpsPolicyGroup), or both.
Snir, Ramberg, Strassner, Cohen expires May 2001 24 Figure 2 shows the QPIM association hierarchy.
+-------------+ [unrooted] (abstract, PCIM)
|policyGroup | <------------------- QoS policies for an enterprise
+-------------+
|
| +---------------+
-->|qosPolicyDomain| <----------- QoS policies for the Sales group
+---------------+
| |
| +---------------+ +---Dependency (abstract)
|-->|qosPolicyDomain| <-------- QoS policies for Western Sales
| +---------------+
| | | |
| | +--------------+ | +--- QosPolicyTrfcProfInAdmissionAction (QPIM)
| |-->|gpsPolicyGroup| <--Qos Policies for group
| | +--------------+ A within Western Region
| | | |
| | +--------------+ | +--- QoSPolicyConformAction (QPIM)
| -->|gpsPolicyGroup| <--Qos Policies for group
| +--------------+ B within Western Region
|
| +---------------+
-->|qosPolicyDomain| <--------QoS policies for Eastern Sales
+---------------+
|
| +--------------+
|-->|gpsPolicyGroup| <--Qos Policies for group
| +--------------+ C within Eastern Region
|
| +--------------+
-->|gpsPolicyGroup| <--Qos Policies for group
+--------------+ D within Eastern Region
Figure 2: Top-level Policy Data Tree Example
The modeling approach used in the previous example is but one possible
strategy among many. This information model allows for arbitrary
nesting of containers, groups and rules, thus providing the means for
modeling both wide and deep policy hierarchies.
3.6. Resource Sharing
Object instances residing in different branches of the data tree
are independent of each other. That is, there is no cross-referencing
among objects located in different QoS policy domains. However,
multiple QoS policy domains may still share data by using a special
mechanism. This mechanism is called referencing reusable objects. A
reusable object is an object that is placed in a special portion of the
data store dedicated to sharing information among multiple clients that
Snir, Ramberg, Strassner, Cohen expires May 2001 25
wish to access the same information. In fact, there may be multiple
such repositories, each used for collecting a different set of related
reusable objects. In this document, we will call such repositories
reusable-object repositories. (Note that [PCIM] refers to this object
as a PolicyRepository; we are using the term "reusable-object
repository" to emphasize the fact that this is a special "repository-
in-a-repository" for containing reusable objects).
The sharing of global or common objects enhances the interoperability
of various policy applications, thus serving the primary goal of this
information model. Such commonly used building blocks as PolicyGroup
and its subclasses (e.g., gpsPolicyGroup and qosPolicyDomain),
subclasses of PolicyCondition (e.g., qpsPolicySimpleCondition and
gpsPolicyCompoundCondition)and PolicyAction (e.g., qosPolicyPRAction
and qosPolicyRSVPAction), as well as lower-level objects (e.g.,
instances of qpsPolicyVariable and qpsPolicyValue) 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.7. Instance Location
The purpose of the QPIM is to define a flexible structure of
information that does not pre-impose harsh restrictions on building the
data tree. When a data tree is derived from the QPIM, it is important
to ensure that this derivation is as free of restrictions as possible.
Although each data store has its own special considerations to be taken
into account, one of the most important considerations in mapping for
directories concerns placement of entries. The QPIM MUST NOT contain
any hidden assumptions about the placement of particular QoS policy
domain hierarchies (including, for that matter, placement of reusable-
object repositories as explained in section 3.13 below). Consequently,
the QPIM does not require any pre-defined locations for the portion of
the data tree that is dedicated to policy. An instance of the global
data tree (a corporate directory, for example) may in fact contain
several QoS policy domains that exist within the global date tree in
various places. Zero or more reusable-object repositories may also be
present in the global data tree.
In addition, the QPIM does not dictate any standard organization of
objects to be controlled via policy, either for QoS policy classes and
relationships or for reusable-object repositories that are used by QoS
applications.
Snir, Ramberg, Strassner, Cohen expires May 2001 26
The only location/organizational rule that must be followed is:
Each QoS policy domain must contain complete policy information that
is necessary to describe that particular 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. Note specifically that there is no
requirement for reusable objects to be placed in the policy domain
itself. Furthermore, reusable objects MUST be referenced using the
properties defined in the appropriate [PCIM] and QPIM classes.
3.8. Policy Containers
A QoS policy domain is a container that provides scoping for QoS policy
containers, policy rules, and other policy information, as mentioned
previously. There are two information model class that are used to
represent QoS policy containers: the qosPolicyDomain and the
gpsPolicyGroup classes. Both classes extend the PolicyGroup class,
which is defined in [PCIM].
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.
Both the gpsPolicyGroup as well as the qosPolicyDomain policy
containers can be nested (e.g., a container may contain multiple
containers). A particular data tree, then, may be constructed with as
deep a hierarchy as needed.
3.8.1 Semantics of a gpsPolicyGroup
A (non-empty) gpsPolicyGroup holds an ordered list (i.e., a set) of
PolicyRule and/or gpsPolicyGroup instances. Both the gpsPolicyGroup
class and the PolicyRule class carry a priority property (called
gpPriority and Priority, respectively). Note that the PolicyGroup class
does NOT have a priority property - this is one of the reasons that the
PolicyGroup class has been subclassed in this document to provide these
semantics (through the gpsPolicyGroup class). These properties are used
to specify the order in which objects within a gpsPolicyGroup are
processed. The gpPriority property added to the gpsPolicyGroup enables
it to be treated the same way as a PolicyRule. That is, both the
gpsPolicyGroup as well as the PolicyRule will appear as atomic objects
that each has their own distinct priority.
Snir, Ramberg, Strassner, Cohen expires May 2001 27
The semantics of the gpPriority property in the gpsPolicyGroup class
are identical to the semantics of the Priority property in the
PolicyRule class. Larger values mean higher priority (i.e., objects
having a higher priority will be processed before objects that have a
lower priority). If two or more objects have equal values, then those
objects may be evaluated in any order with respect to each other. For
example, if there are four objects A, B, C, and D having priorities 3,
5, 5, and 8, respectively, acceptable processing orders are {D, C, B,
A} and {D, B, C, A}. Note that the gpPriority and Priority properties
of the gpsPolicyGroup and PolicyRule classes respectively may be
unassigned, in which case they are treated as having the numerical
value of 0.
The reason to define a priority for the gpsPolicyGroup is to be able to
assign a "match strategy" (this is the gpNamedPolicyRuleMatchMethod
property of the gpsPolicyGroup class) to the gpsPolicyGroup. Remember
that a gpsPolicyGroup contains its own set of PolicyRules (and possibly
additional gpsPolicyGroups). Therefore, we need a way to evaluate the
PolicyRules that are contained in a gpsPolicyGroup relative to
PolicyRules that exist at the same level as the gpsPolicyGroup. This
property dictates the execution order of the contained QoS policy
rules, based on the values of the priority properties of the contained
instances. For example, a 'First Match' strategy means that the groups
and/or rules will be "matched" according to ascending order of their
Priority attribute. Decision strategies are explained in section 5.
Note also that the specific semantics of "execution order" depend on
the match decision strategy that is being used. For example, if a
"match-first" strategy is being used, then the first rule whose
conditions match (i.e., evaluated to Boolean 'TRUE') will have its
actions executed. However, if a "match-all" strategy is being used,
then all rules will be scanned for conditions that match. Then, the
actions for each rule that has matched will be executed in priority
order for all rules whose conditions were matched.
Figure 3 shows a simple example of the above execution process. Section
4 describes policy rules in more detail.
Snir, Ramberg, Strassner, Cohen expires May 2001 28
+---------------+
|qosPolicyDomain|
+---------------+
|
| +--------------+
|-->|PolicyRule A |
| | Priority=19 |
| +--------------+
|
| +-----------------------+ +-------------+
|-->|gpsPolicyGroup |--->|PolicyRule C |
| | gpPriority=5 | | | Priority=7 |
| +-----------------------+ | +-------------+
| | | |
| +-------------+ | +-------------+ | +--- QoSPolicyExceedAction (QPIM)
-->|PolicyRule B | ->|PolicyRule D | | |
| Priority=3 | | Priority=2 | | +--- QoSPolicyViolateAction (QPIM)
+-------------+ +-------------+
Figure 3. Example Ordering for a QoS Policy Decision
In this example, the ordering is A, then C, then D, then B. This is
because the gpPriority property of the gpsPolicyGroup is higher than
the Priority property of PolicyRule B, so each of the PolicyRules
contained in the gpsPolicyGroup (i.e., PolicyRule C and PolicyRule D)
are executed (in priority order) before PolicyRule B. If the
gpsPolicyGroup's priority was not defined, then the order between the
policy rules would have been A, then C, then B, and finally D (note in
this last example that the Priority property of a PolicyRule is treated
identically to the gpPriority property of a gpsPolicyGroup).
3.8.2 Priority and Decision Strategy Applied to Containers
Each policy rule as well as each policy container may have an order
attribute (Priority for PolicyRule and gpPriority for gpsPolicyGroup,
respectively). The ordering is interpreted as a function of the
priority value AND the particular level of aggregation that the
PolicyRule or gpsPolicyGroup resides in. For example, in Figure 3
above, PolicyRule A and PolicyRule B, as well as the gpsPolicyGroup,
are all at the same level of containment. The priority of each of these
objects must be compared with each other. Note that it would be
incorrect to ignore the priority of the gpsPolicyGroup and try and
compare the priorities of the policy rules that it contains (C and D)
to the priorities of policy rules A and B.
Snir, Ramberg, Strassner, Cohen expires May 2001 29
3.8.3 Sharing Policy Containers
For shared (reusable) containers, the priority assigned to the shared
container must be correct for all containing objects. This restriction
makes it impractical to share a particular policy container directly
(i.e., for two applications belonging to two different QoS policy
domains to share the same policy container). This is because a policy
container can contain not just policy rules, but also additional policy
containers. However, sharing (i.e, reusing) a policy container can be
made possible by "enclosing" a shared container within an exclusive
container (i.e., a container that is used to contain just a single
instance of a gpsPolicyGroup object). This in effect makes the
gpsPolicyGroup act as a single-level container. Depending on the
sharing context, the following techniques can be used for sharing an
instance of the gpsPolicyGroup class:
1. Reusing a gpsPolicyGroup inside a gpsPolicyGroup
To reference a container C1 with priority P1 from a container C, an
enclosing container D is created and is assigned the desired priority
P1 within the context of the C container. The D container is placed
under the C container in the data tree implementation. The D container
contains a single object, C1, by means of the PolicyGroupInPolicyGroup
aggregation. The D container complies with the naming and ordering
restrictions -- it is only created in the context of the C container
and can not be reused by any other container. This means that the
container C1 can not contain additional containers, even though it is
normally able to.
2. Reusing a gpsPolicyGroup inside a policyRule
To reference a container C1 with priority P1 from a policy rule R
(making it a "sub-rule" object, as opposed to a (more general)
container that is shareable by multiple policy rules), an enclosing
container D is created and is assigned the desired priority P1 within
the context of the sub-rule. The D container is contained in the rule
by using the PolicyRuleInPolicyRule aggregation. This aggregation
effectively places a given rule under an existing rule (in our example,
PolicyRule R contains a set of conditions and actions as well as the
container D; container D contains a single object, which is another
policy rule, but this policy rule acts as a sub-rule of R) using the
PolicyGroupInPolicyGroup aggregation.
This structure enables either another rule, R', or a policy container,
C', or both, to now share the C1 container by similar means.
Note that a shared container (C1 in the descriptions under #1 and #2
above) MUST be named so that it can be placed in a reusable-object
repository (see section 3.13).
Snir, Ramberg, Strassner, Cohen expires May 2001 30
Figure 4 illustrates the above example of sharing a policy container
between a policy container and a policy rule. The numbers in
parentheses denote in-context ordering.
(rest of the hierarchy)
|
| +-------+
|-->| C (1) |
| +-------+
| | +--------+
(cont.) |-->| R1 (1) |
| +--------+
| +-------+
|-->| D (2) |
| +-------+
| | +--------+
| |--PolicyGroupInPolicyGroup-->| C1 (*) |<----+
| +--------+ ^
| +--------+ |
|-->| R2 (3) | |
| +--------+ |
| +--------+ |
|-->| R3 (4) | |
| +--------+ |
| | +--------+ |
(cont.) |-->| R5 (1) | |
| +--------+ |
| +--------+ |
|-->| D' (2) | |
| +--------+ |
(cont.) | |
|--PolicyGroupInPolicyGroup---------->+
(*) denotes a priority which is always ignored for reusable (shared)
policy containers.
Figure 4. Sharing policy containers
3.9 Policy Roles associated with gpsPolicyGroup
The property gpPolicyRoles in the gpsPolicyGroup class
represents the roles and role-combinations associated with the set of
policy rules and gpsPolicyGroups aggregated by a gpsPolicyGroup. Roles
and role-combinations are defined in [POLTERM] and further elaborated
on in [PCIM].
Each value represents one role-combination. Since this is a multi-
valued property, more than one role-combination can be associated with
a single gpsPolicyGroup.
Snir, Ramberg, Strassner, Cohen expires May 2001 31
After identifying the relevant set of rules to be used, rules should be
prioritized according to the procedures and rules defined in Section 5.
The PolicyRoles values defined per gpsPolicyGroup include implicitly
the roles defined for the contained policy containers.Overriding a role
or role-combination that is defined for a containing policy container
is not allowed.
The following example illustrates this situation:
gpsPolicyGroup 1 : PolicyRoles: Role A, Role B
|
+--PolicyRule 1.1 : PolicyRoles: <Not defined>
|
+--PolicyRule 1.2 : PolicyRoles: Role A, Role D
|
+--PolicyRule 1.3 : PolicyRoles: <Not defined>
|
+--PolicyRule 1.3.1 : PolicyRoles: Role E
PolicyRule 1.1 will be associated with roles A & B, because it
inherits both of these roles from gpsPolicyGroup 1
PolicyRule 1.2 will be associated with roles A, B, & D, because it
inherits roles A and B from gpsPolicyGroup 1 and adds D
PolicyRule 1.3 will be associated with roles A & B, because it
inherits both of these roles from gpsPolicyGroup 1
PolicyRule 1.3.1 will be associated with Roles A, B, & E, because it
inherits roles A & B from PolicyRule 1.3 and adds E
For a definition of the gpsPolicyGroup's PolicyRole property,
refer to section 8.2.3. Extended explanation on the definition and
usage of Roles is provided in [PCIM], section 5.2.
Note: A role or role-combination defined in contained and containing
policy objects does not imply any special behavior. The example above
illustrates this situation in PolicyRule 1.2, regarding role A.
3.10. Policy Rules
QoS policy rules are modeled by the [PCIM] class PolicyRule. All new
behavior in [PCIM] is obtained not by altering the definition of a
PolicyRule, but rather by adding new types of PolicyConditions and
PolicyActions (along with other associated objects) that are used by
the PolicyRule.
The semantics of a policy rule is, in essence, a conditional imperative
statement in the form 'if <condition> then <action>'. Applying a rule
means evaluating its condition and, depending on the truth value of
the condition, to either execute the action or to do nothing.
Evaluating a condition is known as 'matching the rule', an expression
we'll be using in later sections of this document. [PCIM] requires that
Snir, Ramberg, Strassner, Cohen expires May 2001 32
a given policy rule SHOULD belong to one (and only one) gpsPolicyGroup.
These semantics are enforced by a special association,
PolicyRuleInPolicyContainer (defined in [PCIM]), with the appropriate
cardinality (1 policy container can contain zero-or-more PolicyRules).
However, a policy designer may, in some cases, wish to reuse a
particular rule in more than one policy container. The designer MAY do
so by encapsulating the would-be reusable rule within a single,
reusable policy container and sharing that container, using the
technique described in section 3.8.3.
The order of the policy rules inside a container is based on the
relative values of the Priority attribute of each of the PolicyRules
(please see [PCIM] for more information). The enforcement of policy
rules also depends on particular settings belonging to the group. The
match strategy to be applied to the policy rules contained in a given
container is defined in the policyRuleMatchMethod attribute of the
gpsPolicyGroup object.
Policy rules may be nested. Placing a rule under another rule in the
data tree creates a nested rule. This is done by using the
PolicyRuleInPilicyRule aggregation.
3.11. Conditions and Actions
A policy rule is a composite object. The most
important components of a rule are the conditions and actions it
contains. A condition is a Boolean expression that is evaluated to find
out if the rule should be applied. An application of a rule means that
the actions that it contains will be executed. An action is a
specification of one or more QoS operations enforced on the designated
set of flows that MUST be done if the given policy rule is to be
applied. Actions are applied if the condition is TRUE (see [PCIM] for
more details).
3.12. Data Tree Example
The following example illustrates the hierarchical nature of the QoS
Policy data tree. Each organizational entity is related to a specific
type of class, which is shown in parentheses.
There are two QoS policy domains in this example, grouped together
under the same root (domain grouping). The QoS policy domains are:
1. EastCoast
2. WestCost
Snir, Ramberg, Strassner, Cohen expires May 2001 33
Assume that each of these two qosPolicyDomains has its own PHB set
modeled by a gpsPolicyGroup with a set of policy rules defining the per
hop behavior for different DSCP values.
The EastCoast domain has 2 named policy containers. The first deals
only with ERP traffic and the second handles all other traffic:
1. EastCoast (implemented as a qosPolicyDomain)
1.1. ERP (implemented as a gpsPolicyGroup)
1.2. General (implemented as a gpsPolicyGroup)
The WestCoast domain has three named policy containers. The first deals
only with ERP traffic, the second deals with VoIP traffic, and the
third with all other traffic:
2. WestCoast
2.1. ERP (implemented as a gpsPolicyGroup)
2.2. VoIP (implemented as a gpsPolicyGroup)
2.3. General (implemented as a gpsPolicyGroup).
Each one of the gpsPolicyGroup entries can contain a
prioritized rule set. For example, the WestCoast ERP group contains the
rules relevant to ERP applications administered by the west coast
domain administrator.
We see from the above structure that this structure provides the
administrator with a great deal of flexibility. For example, similarly
containers, represented by the ERP and General
gpsPolicyGroups, can reuse common policy conditions and
actions. However, they are implemented as physically different
containers to enable the administrator to administer them
according to their own domain-specific needs.
3.13. Reusable-Object Repositories
Reusable objects are objects that can be referred by (hence "used by")
other objects. For example, the reference could be accomplished by
allocating an attribute on the referencing object that contains the
location of the referenced object. In this information model,
association classes (and naming rules) are used to establish
reusability of an object by creating a "resides-in" relationship
between the reusable object and the repository in which it resides. For
example, the PolicyConditionInPolicyRepository association is used to
enable an instance of a PolicyCondition class, or its subclasses, to
reside in an instance of a PolicyRepository class, or its subclasses.
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.
Snir, Ramberg, Strassner, Cohen expires May 2001 34
A reusable-object repository hierarchy is rooted in an instance of the
policyRepository class (defined in [PCIM]). Individual reusable-object
repositories are named containers for reusable objects. Note that
[PCIM] allows arbitrary nesting of reusable-object repositories. This
can be conceptually thought of as a repository of repositories.
Each named reusable-object repository is a container of "reusable
objects" that can be used for a common purpose, and/or are administered
in a common way. A reusable object MUST have a unique name within the
the container that it resides in.
The complete aggregation model for the reusable-object repositories,
as well as detailed description of the various mechanisms for
constructing and maintaining such repositories, is described in detail
in [PCIM].
Common candidates for reusability are named instances of these classes
and their derivatives:
- gpsPolicyVariable
- gpsPolicyValue
- gpsPolicySimpleCondition
- gpsPolicyCompoundCondition
- policyAction
- gpsPolicyMeter, QoSPolicyTrfcProf, QoSPolicyQueue
- gpsPolicyGroup for policy rule reusability
3.14. Relationships Between QoS Domains and Repositories
As explained above, a QoS policy domain contains within it groups of
policy rules. A policy rule can contain ordered lists of conditions and
actions. The conditions and actions may be reusable objects that reside
in reusable-object repositories, or they may be rule-specific
conditions and actions that are embedded within the rule, or a
combination of both.
The advantage of reusable objects is that many different policy rules
may reference the same reusable object . References to reusable objects
need not all point to the same reusable-object repository; any policy
rule may contain references to reusable objects that reside in
different repositories.
The maintenance of the policy system is made somewhat more complicated
due to the flexibility provided by the ability to use multiple
repositories. For example, it is more difficult to prevent "dangling"
references to repositories that are no longer present. Schema designers
are encouraged to pay extra attention to this problem and exercise any
technique available from their implementation platform to maintain
integrity of their data trees. [PCIM] discusses this issue as well.
Snir, Ramberg, Strassner, Cohen expires May 2001 35
4. Constructing a QoS Policy Rule
A policy rule modeled in [PCIM] represents the "If Condition then
Action" semantics associated with a policy. The QPIM extends these
semantics by refining the type of policy conditions and actions that
can be represented, extending the use of containers that hold policy
information, and providing additional features (nesting of rules,
aggregation of groups inside rules, defining extensible rule decision
strategies, linking to PHBs, and providing pre-defined
variables and constants that can be used to express the required
semantics of QoS policy rules in more detail).
The following sections describe these characteristics in more detail.
4.1 Policy Rule Structure
A policy rule has the following attributes (defined in [PCIM]) that can
be used to provide important semantics for QoS policy applications;
these are in addition to the attributes which serve as a key and
provide its name:
1. An Enable flag that indicates whether a policy rule is
administratively enabled, administratively disabled, or enabled
for debug mode.
2. A set of conditions,contained in the rules by means of the
PolicyConditionInPolicyRule aggregation. Note that the new
subclasses of PolicyCondition that the QPIM defines automatically
inherits this relationships
3. A flag indicating whether the rule's condition is in disjunctive
or conjunctive normal form
4. An (optionally ordered) list of actions, contained in the rule by
means of the PolicyActionInPolicyRule aggregation.
5. A priority value, defining the ordinal position of this rule
relative to other rules (or any other contained objects) 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 Boolean condition is evaluated in order to determine if the set of
actions should be performed on a network flow by matching the network
flow attributes against the condition. The PCIM defines a generic
simple policy condition class, called PolicyCondition, which can be
Snir, Ramberg, Strassner, Cohen expires May 2001 36
used to contain a single condition term to be tested. This document
defines two new policy condition classes. The first,
gpsPolicySimpleCondition, extends the semantics of a policy condition
to contain an ordered triplet ({variable, operator, value}). The
second, gpsPolicyCompoundCondition, uses the gpsPolicySimpleCondition
class to build a more generic compound condition class. QoS-specific
conditions SHOULD be formed by using the gpsPolicySimpleCondition class
and/or the gpsPolicyCompoundCondition class (both of these classes are
defined in this document) and/or the policyTimePeriodCondition class
defined in [PCIM] (or their subclasses, of course). Note that QoS-
specific conditions MAY be mixed with more generic conditions that are
not derived from either of these classes. However, these non-QoS-
specific conditions SHOULD be derived from the PolicyCondition class
(defined in [PCIM]). The combination of individual conditions in a
policy rule is defined in [PCIM] using the PolicyConditionInPolicyRule
aggregation.
Each action in the list is modeled by an class derived from the
PolicyAction class. The collection of individual actions in a policy
rule is defined in [PCIM] using the PolicyActionInPolicyRule
aggregation. This class also contains a property, ActionOrder, that
defines the order in which policy actions are performed. .
The interpretation of a policy rule in regard to a given network flow
may be expressed as follows:
If the rule is enabled and the Boolean expression is evaluated to
TRUE, then use the Action list to extract the prescribed treatment
for this flow.
The rest of this section describes the components of the policyRule
class and their relationships to the other classes defined in this
information model.
4.2 QoS Policy Conditions
A policy rule, as modeled in [PCIM], represents the "If Condition then
Action" semantics associated with a policy. A condition is represented
as either an ORed set of ANDed terms (disjunctive normal form) or an
ANDed set of Ored terms (conjunctive normal form). Individual
conditions may either be negated (NOT C) or not negated (C). The
actions specified by a policy rule are to be performed if and only if
the policy rule condition evaluates to TRUE.
The semantics of an individual condition are not specified in [PCIM].
Rather, the PCIM limits itself to specifying the structure of a
condition and its naming attributes. This document provides semantics
for common QoS policy conditions. For example, conditions such as: "If
the source IP address of the flow belongs to 10.1.x.x subnet" as well
as "If the IP protocol number of the flow equals the TCP protocol
number" are modeled in this document.
Snir, Ramberg, Strassner, Cohen expires May 2001 37
4.2.1 Simple Conditions
The gpsPolicySimpleCondition class models individual conditions. This
class refines the basic structure of the PolicyCondition class defined
in [PCIM] by specifying the contents of the condition using the triplet
<variable>, <operator> and <value> to form the condition.
The variable specifies the attribute of a flow that should be matched
when evaluating the condition. A set of predefined variables that cover
network attributes that are commonly used for filtering are introduced
to encourage interoperability. This list covers layer 3 IP attributes
such as IP network addresses, protocols and ports, as well as a set of
layer 2 attributes (e.g., MAC addresses) and higher level attributes
such as application and user identity.
The QPIM defines a single operator, "match", as explained in the
'Simple Condition Operator' section.
The bound 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. The match operator that is defined in QPIM is not just a
simple equal operator - it carries additional semantics (which are
defined in the PolicyValueConstraintsInVariable association) that
ensure that it contains an allowed value that belongs to a pre-defined
acceptable range of values. For example, an IPv4SourceAddress variable
is defined as a string. But the literal value of the string must
conform to the defined semantics of an IPv4 address, and must represent
a legal IPv4 address in either dotted decimal or CIDR format.
Similarly, a port is defined to be an integer. But negative values, or
positive values greater than 65535, are not allowed.
4.2.2 Compound Conditions
Sometimes it is convenient to model a general Boolean expression as an
atomic condition. For example, many packet-related conditions in policy
rules, from a networking perspective, can be modeled as Filters.
Filters are not modeled directly in the PCIM (i.e., no Filter class is
defined). However, the filter concept is central in the QoS Policy data
model.
Note that a filter may consist of multiple terms. The problem, then, is
that if all we have are the PolicyCondition, PolicyTimePeriodCondition,
and gpsPolicySimpleCondition classes, we can't refer to a filter as an
atomic condition, because we will need to combine multiple instances of
one or more of these classes to construct the filter. This is why the
QPIM has defined the gpsPolicyCompoundCondition class.
Snir, Ramberg, Strassner, Cohen expires May 2001 38
The gpsPolicyCompoundCondition class enables multiple instances of the
PolicyCondition, the PolicyTimePeriodCondition, the
gpsPolicySimpleCondition, and/or the gpsPolicyCompoundCondition classes
to be combined and treated as a single atomic entity. This enables the
gpsPolicyCompoundCondition class to be used to model any general
Boolean expression, including common traffic filters. A filter is
constructed by the mechanisms supplied in the following PCIM
attributes:
1. The ConditionListType attribute of the policyRule, which
is a Boolean expression type that defines whether the simple
condition is in conjunctive or disjunctive normal form.
2. The PolicyConditionInPolicyRule aggregation class that does three
things: associates conditions with a particular policy rule,
defines whether the condition is negated or not, and partitions
the referenced conditions into one or more groups. For more
details, please see [PCIM], section 6.3.
4.2.3. Using Simple Conditions
Simple conditions can be used in policy rules directly or as building
blocks for creating compound conditions.
Simple condition composition MUST enforce the following data type
conformance rule: The gpValueTypes property of the variable must be
compatible with the value class name. This ensures that the binding of
the variable to an acceptable value can be done.
The QPIM defines four different ways to compose a simple condition
through the combination of representations of variables and values. The
following combinations of representing a simple condition are possible:
Variable representation
1. An "ad-hoc" instance of the class gpsPolicyVariable may be contained
by the gpsPolicySimpleCondition instance using the
PolicyVariableInPolicySimpleCondition.
2. A reusable, named instance of the class gpsPolicyVariable, which
resides in a reusable-object repository may be indirectly linked
with the gpsPolicySimpleCondition instance (using the same
aggregation as above)
Value representation
1. An "ad-hoc" instance of the class gpsPolicyValue may be contained
by the gpsPolicySimpleCondition class using the
PolicyValueInPolicySimpleCondition aggregation.
Snir, Ramberg, Strassner, Cohen expires May 2001 39
2. A reusable, named instance of the class gpsPolicyValue may be
indirectly linked with the gpsPolicySimpleCondition instance using
the same aggregation as above).
The first method for representing variables and values enables either
to be embedded directly in a policy condition. This is important for
allowing simple and efficient access to the policy condition and its
embedded variables and/or values. It also enables the condition along
with its embedded variables and values to be treated as an atomic
object. The second method for representing variables and values enables
the condition to reuse the variable and/or value. In this case, both
would be stored in a PolicyRepository. Note that the method described
here for composing conditions out of variables and values allows for
uniform handling for both "ad-hoc" reusable objects, as the
relationships between the aggregator and aggregated objects are unaware
of the reusability vs. ad-hoc status of the aggregated objects.
A simple condition can be added to a PolicyRule or to a
gpsPolicyCompoundCondition in two ways:
1. Building a rule-specific ("ad-hoc") condition. In this case, the
goal is to embed the condition directly in either the PolicyRule or the
gpsPolicyCompoundCondition instance. In many data storage mechanism
implementations, this will be realized by treating the PolicyRule or
the gpsPolicyCompoundCondition instance as a container, and placing an
instance of the condition in the container. For example, in a
directory implementation, the condition will be added as a leaf object
in the container. In the information model, we describe this case using
either the PolicyConditionInPolicyRule aggregation (in the case of a
embedding a condition directly in a PolicyRule) or the
PolicyConditionInCompoundCondition aggregation (for embedding either
gpsPolicySimpleConditions or gpsPolicyCompoundConditions in a
gpsPolicyCompoundCondition).
This case is called an "ad-hoc" simple condition. This method allows
the creation of a "private" simple condition, meaning that this
instance of the condition can't be used by any other policy rule or
compound condition, hence it is not reusable. However, this case
enables the condition and its container to be treated and managed
atomically.
2. Building a reusable condition. In this case, the goal is to treat
the condition as a reusable building block. Therefore, it will be
placed in a PolicyRepository and referenced by its containing object
(either a PolicyRule or a qpsCompoundPolicyCondition). In many data
storage mechanism implementations, this will be realized by treating
the PolicyRule or the gpsPolicyCompoundCondition instance as a
container, treating the PolicyRepository as a separate container, and
using an attribute in the PolicyRule or gpsPolicyCompoundCondition to
reference the condition in the PolicyRepository. For example, in a
Snir, Ramberg, Strassner, Cohen expires May 2001 40
directory implementation, a DN pointer will be used to refer to the
condition. In the information model, we describe this case using two
relationship classes. One class, the PolicyConditionInPolicyRepository
association, establishes the "resides-in" relationship between the
reusable object and the reusable-object repository in which it resides.
Another class, the PolicyConditionInPolicyRule aggregation class,
establishes the "contained-in" relationship between the condition and
the rule that contains it.
The advantage of this approach is that by using an indirect reference
to refer to an instance of a condition that resides in a reusable-
object repository, this method allows the sharing of reusable
conditions by multiple policy rules or compound conditions.
Schema designers should keep in mind that in some cases, an
implementation platform introduces an added cost to access reusable
objects that are located in different areas of the data store than the
referencing object is located in. For example, in LDAP based storage,
fetching a sub-tree (i.e., a container object and its "leaves") is a
single operation while accessing a referenced object is an additional
operation.
4.2.4. Using Compound Conditions
Compound conditions should be used when the definition of a set of
terms that should be treated atomically (e.g., as a single condition)
is required. One such example is the common case of filtering on a
five- or six-tuple (e.g., the source and destination address and ports,
protocol, and DSCP). This type of filter can be modeled as a container
that holds one or more simple conditions.
If filter reusability is not required, then an ad-hoc set of simple
conditions that implement a rule-specific condition is sufficient (it
carries the same semantics except for reusability).
All instances of the gpsPolicyCompoundCondition MUST carry unique
names. A name is a MUST property for reusable objects (this is required
by [PCIM]).
The gpPolicyConditionListType of the gpsPolicyCompoundCondition is set
to DNF or CNF (disjunctive or conjunctive normal form, respectively),
as required. Each of the conditions that are to be used in this
compound condition are defined using the
PolicyConditionInCompoundCondition aggregation. This aggregation
enables the condition to be treated as a container so that it can
aggregate other conditions, and is defined in QPIM.
Each condition that is contained in the compound condition can be
either directly contained the compound condition (in which case it is
a rule-specific, ad-hoc condition) or be a reusable condition that
resides in a PolicyRepository.
Snir, Ramberg, Strassner, Cohen expires May 2001 41
An implementation may realize these three relationships in any way
desired to implement their semantics. Sometimes, this means that these
relationships will be implemented as their own classes, and sometimes
it means that they will be implemented in some other way that is
particular to that type of data store. For example, the [PFSCHEMA] uses
a combination of a class and a mechanism (DIT containment) to implement
these three relationships. The class is used to specify an optional NOT
operation to be applied to a condition (e.g., the condition is matched
if the term is NOT true), and to define the interpretation of the term
(i.e., which terms are grouped together, and whether they are ORED or
ANDed together).
The following example illustrates the construction of a reusable
compound condition, named "My-Server", that expresses the following
logic: SourceIPAddress=1.1.1.1 AND SourcePort=7777:
A compound condition is created and is assigned a unique name, in this
case, "My-Server". The gpsPolicyCompoundCondition property
policyConditionListType is set to DNF.
The compound condition is built by ANDing two gpsPolicySimpleCondition
instances. The first simple condition is implemented using a
gpsPolicySimpleCondition object. It includes a SourceIPAddress variable
and an IP address value of "1.1.1.1". The second simple condition is
also implemented using a gpsPolicySimpleCondition object. It includes a
SourcePort variable and an integer value of 7777.
Each of the simple conditions is linked to the compound condition
container using the PolicyConditionInCompoundCondition aggregation.
The qpsPolicyCompoundCondition is then made reusable by placing it in a
reusable-object repository using the PolicyConditionInPolicyRepository
association. To use this compound condition in a policy rule, the
PolicyConditionInPolicyRule aggregation is used.
4.2.5 Reusable vs. Rule-Specific Conditions
This information model facilitates reuse of simple conditions (using
the qpsPolicySimpleCondition class) as well as more complex expressions
(using the qosPolicyCompoundCondition class) by placing them in a
common portion of the policy information tree (called the reusable-
object repository). In order for a condition to be placed in this
repository, it must carry a unique name.
A reusable gpsPolicySimpleCondition contains a value and a variable.
There are two different ways to build simple (or compound) conditions.
One way is for the values and variables to be embedded within the
condition directly. Conceptually, this can be thought of as specifying
that when the condition is instantiated, its variables and values will
also be instantiated as part of the same object that is used to build
Snir, Ramberg, Strassner, Cohen expires May 2001 42
the condition itself. In this case, embedding the values and variables
within the policy condition is specified by the
PolicyValueInPolicyCondition and PolicyVariableInPolicyCondition
aggregations, respectively. This is called a rule-specific condition,
because its components can not be shared with other rules.
Alternatively, a policy variable and/or a policy value can be
instantiated in a reusable-object repository and then referenced by the
(simple or compound) condition. The values (or variables) are linked to
the PolicyRepository using the PolicyElementInPolicyRepository
association; the condition is linked to the PolicyRepository using the
PolicyConditionInPolicyRepository association. Note that the reusable-
object repository may be part of the same data store as that which
contains the aggregating condition, or it may be a physically different
data store..
4.3 Simple Condition Operator
The QoS policy simple condition includes the gpOperator property,
which specifies the type of relation between the variable and the value
evaluated in the condition. In many cases, a generic 'match' operator
can be used, and the interpretation of the relation between the
variable and value is implied by the value itself. For example, the
variable SourceIPAddress 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. Similarly, this same variable (which is a string)
has semantics that determine the acceptable values that the string can
take. For example, an improperly formed address in either CIDR or
dotted decimal notation can be detected and rejected.
The QPIM defines a single operator, "match", that models the most
generic relation: that of being equal or belonging to.
4.4 QoS Policy Variables
QoS policy variables are used for building individual conditions, as
defined in section 4.2. The variable specifies the attribute of a flow
that should be bound and evaluated according to a set of pre-defined
semantics in a condition. Its purpose is to act as a binding point,
associating a condition with an object whose data is evaluated
according to the specified operator/value. The QPIM has defined
semantics for some of the most common of these variables based upon
these sources to guide the binding of common data. However, such
binding could also be determined from a variety of other standard and
proprietary sources such as public or private MIBs or application-
specific data.
Snir, Ramberg, Strassner, Cohen expires May 2001 43
Not every combination of a variable and a value creates a meaningful
condition. For example, a source IP address variable can not be matched
against a value that specifies a port number. The QPIM defines a set of
variables that can be used to model common QoS policy conditions, and
assigns appropriate semantics for each. Each type of variable
inherently selects the set of value types that it can be matched
against (i.e. a value that could be compared and evaluated to a Boolean
expression).
Variables have data types. Many of the variables defined in this draft
have associated semantics that limit the set of values within a
particular value type that can be matched against it in a condition.
This may be viewed as a second level of integrity checking. For
example, a variable representing the source-port must limit the set of
values that it can assume to the valid range of integers that
correspond to legal source-port values; values such as -3 or 2000000
are not legal values and can not be matched to this variable. Thus, it
is not enough to say that the data type of the source-port variable is
an integer; we also need to ensure that the value to be tested is
within a valid range of integers. This is achieved by associating the
source port variable with an integer value object that contains the
appropriate value range for that variable.
In this first implementation, simple semantics such as those described
above are realized by defining a separate class whose properties
contain the constraints. This constraint class is then linked to the
PolicyValue class through the PolicyValueConstraintsInVariable. In the
future, a more robust mechanism, such as an object constraint language,
may be integrated with the information model to provide even more
metadata to describe legal behavior, values and operations on the
variable. Currently, such a language is not integrated with either this
information model or PCIM. The mechanism defined in this draft enables
implementation experience to be gained to help guide the integration of
a constraint language in the future.
The QPIM defines one attribute, one association, and one general
purpose mechanism that together characterize each of the variables that
it defines:
1. The property gpVariableName of the qpsPolicyVariable class defines
the well-known name used for logically binding all variables that
are defined in this document to a set of allowed value data types.
2. The PolicyValueConstraintsInVariable association defines the set
of value classes that could be matched to this variable.
3. The list of constraints on the values that the PolicyVariable can
hold (i.e., values that the variable must match) are defined by
the appropriate properties of an associated PolicyValue class.
Snir, Ramberg, Strassner, Cohen expires May 2001 44
For example, if a PolicyVariable represents the SourcePort of incoming
traffic, then a PolicyValueConstraintsInVariable association can be
used to link the PolicyVariable instance to an qosPolicyIntegerValue
instance. This association by itself constrains the data type of the
SourcePort PolicyVariable to be an integer. However, we can further
constrain the particular values that the SourcePort PolicyVariable can
hold by entering valid ranges in the qpIntegerList property of the
qosPolicyIntegerValue instance.
Note that implementations are free to realize the semantics defined by
these two associations in a number of different ways. The information
model defines these semantics based around an association, because that
is the most general form describing how this information is related. An
implementation could conceivably realize this using zero or more actual
relationships.
The combination of the qpVariableName and the
PolicyValueConstraintsInVariable assocation provide a consistent and
extensible set of metadata that define the semantics of variables that
are used to form QoS conditions. Since the
PolicyValueConstraintsInVariable association points to another class,
any of the properties in the PolicyValue class can be used to constrain
values that the PolicyVariable can hold. For example:
- The gpVariableName can be used to identify common processing rules
for a variable having a specific name.
- The PolicyValueConstraintsInVariable association can be used to
ensure that only proper classes are used in the expression. For
example, the SourcePort variable will not be allowed to associate
to the qpsPolicyIPv4AddrValue class, since source ports have
different semantics than IP addresses and may not be matched.
However, it will associate to a gpsPolicyIntegerValue class.
- The PolicyValueConstraintsInVariable association also ensures that
variable-specific semantics are enforced (e.g., the SourcePort
variable may include a constraint association to a value object
defining a specific integer range that should be matched).
4.4.1. Variable Binding
For the QoS Policy schema to be interoperable, different policy
management systems and policy servers must instantiate the same
variables with identical values (in the same evaluation operation).
While different policy servers may use a different binding mechanism,
the binding logic must result in an identical instantiation.
Each variable defined in the QoS policy data store must be bound to a
logical entity such as a specific field in the IP header, a specific
class or property in the QPIM or in a related Information or Data
Model, an application unique identifier or an application-specific
parameter.
Snir, Ramberg, Strassner, Cohen expires May 2001 45
When a policy server attempts to evaluate an expression containing
variables, it must instantiate the variables. To instantiate a
variable, that variable must be bound to a specific value (or values,
depending on its type category) and associated with a logical entity.
For example, in the expression 'SourcePort == 80', the variable
'SourcePort' must be instantiated to a value and logically associated
with the packet header field containing the source port number, for the
expression to be evaluated.
If, in this example, the variable SourcePort is bound to a value of
'80', then the expression is evaluated to TRUE for each packet that the
source port number in the IP header field equal to 80. Otherwise it is
evaluated to FALSE.
4.4.2. Pre-Defined Variables
The purpose of this section is to explain the need and define the
relationship of standard, frequently used variables with their logical
entities. Pre-defined variables are necessary for ensuring
interoperability among policy servers and policy management tools from
different vendors.
For example, different policy servers may have to evaluate the same
policy rule. If each policy server uses a common set of variables, this
helps to abstract the condition term such that its evaluation can be
performed in the same way by all of those policy servers. If no such
set of common variables exist, then each policy server is free to
define its own set of variables. Variations in each variable that each
policy server defines will impede interoperability, and prevent the
same semantics and interpretation to be achieved when each policy
server implements the same policy rule.
The QoS Policy information model specifies a set of pre-defined
variables to support a set of fundamental QoS terms that are commonly
used to form conditions. Examples of these include IP header field
values, user information, applications, and others. A pre-defined
variable MUST always have the same name and binding semantics. For
example, a given pre-defined variable should be bound to the same
logical entity by all client systems (typically policy devices).
Similarly, the pre-defined variable should be stored in the reusable-
object repository to enable reuse and sharing of the pre-defined
variable.
Snir, Ramberg, Strassner, Cohen expires May 2001 46
All standard variable names are case insensitive and do not include
spaces or other non-standard characters to promote ease of use.
The implementers of client systems that map the QPIM to a specific
repository-based implementation MUST provide binding methods to bind
pre-defined variables according to the semantics specified in this
section.
Following is a table that defines the predefined variable names and
their binding. The table indicates which fields are checked in actual
filters used in provisioning policies as well as in RSVP signaling
messages.
+-----------------+---------------------------------------------------+
|Variable name | Logical binding |
+-----------------+---------------------------------------------------+
| SourceIP | The source IP address of the flow. Compared to the|
| | source IP header field, or the sender address in |
| | the RSVP Filter spec object [RSVP]. |
+-----------------+---------------------------------------------------+
| SourcePort | The source Port of a UDP/TCP flow. Compared to the|
| | source port field in the TCP/UDP header, or the |
| | sender port in the RSVP Filter spec object [RSVP].|
+-----------------+---------------------------------------------------+
| DestinationIP | The destination IP address of the flow. Compared |
| | to the destination IP header field, or the session|
| | address in the RSVP SESSION object [RSVP]. |
+-----------------+---------------------------------------------------+
| DestinationPort | The destination Port of a UDP/TCP flow. Compared |
| | to the destination port field in the TCP/UDP |
| | header, or the session port in the RSVP SESSION |
| | object [RSVP]. |
+-----------------+---------------------------------------------------+
| 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 the 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. |
+-----------------+---------------------------------------------------+
(Table continued in next page)
Snir, Ramberg, Strassner, Cohen expires May 2001 47
(Table continued from the previous page)
+-----------------+---------------------------------------------------+
| 8021QID | The VLAN ID is bound to the 802.1Q field of |
| | the header. |
+-----------------+---------------------------------------------------+
| Snap | The snap protocol variable is bound to the |
| | 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. |
+-----------------+---------------------------------------------------+
|Variable name | Logical binding |
+-----------------+---------------------------------------------------+
| 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 1. Pre-defined Variables and Their Bindings
The definition of each predefined variable includes a standard name and
the allowed value types. The VariableHasDataValues association is used
to associate a variable object with a value object.
Following is a table of variable names and the value types defined
within this document that can be used together in a simple condition.
In reality, these are individual specializations of the general
association, PolicyValueConstraintsInVariable, that exists between the
PolicyVariable and PolicyValue classes and their subclasses. A given
variable can further restrict the values that can be combined with it
in a given condition. This is done by restricting the values that can
be held by the appropriate attributes of the PolicyValue class that is
used to represent the constraining object in the
PolicyValueConstraintsInVariable association. For example, by default,
a condition including a variable with the name "SourceIP" should also
include either a gpsPolicyIPv4AddrValue or a gpsPolicyIPv6AddrValue
value object. But, if there is a need to restrict values within a
condition to only IPv6 addresses of a certain range, then the
PolicyValueConstraintsInVariable association can be used to indicate
that only gpsPolicyIPv6Values of that range should be used. This is
done by placing this information into the qpIPv6AddrList attribute of
the gpsPolicyIPv6AddrValue class. The table below does not restrict new
Snir, Ramberg, Strassner, Cohen expires May 2001 48
value classes defined elsewhere to be combined with variables defined
in this document.
+-----------------+---------------------------------------------------+
|Variable name | Allowed value types |
+-----------------+---------------------------------------------------+
| SourceIP | gpsPolicyIPv4AddrValue, gpsPolicyIPv6AddrValue |
+-----------------+---------------------------------------------------+
| SourcePort | gpsPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| DestinationIP | gpsPolicyIPv4AddrValue, gpsPolicyIPv6AddrValue |
+-----------------+---------------------------------------------------+
| DestinationPort | gpsPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| IPProtocol | gpsPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| ToS | gpsPolicyIntegerValue, gpsPolicyBitStringValue |
+-----------------+---------------------------------------------------+
| DSCP | gpsPolicyIntegerValue, gpsPolicyBitStringValue |
+-----------------+---------------------------------------------------+
| DestinationMAC | gpsPolicyMACAddrValue |
+-----------------+---------------------------------------------------+
| SourceMAC | gpsPolicyMACAddrValue |
+-----------------+---------------------------------------------------+
| 8021QID | gpsPolicyIntegerValue, gpsPolicyBitStringValue |
+-----------------+---------------------------------------------------+
| Snap | gpsPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| Ethertype | gpsPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| Ssap | gpsPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| Dsap | gpsPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| Application | gpsPolicyDNValue, gpsPolicyStringValue, |
| | gpsPolicyAttributeValue |
+-----------------+---------------------------------------------------+
| User | gpsPolicyDNValue, gpsPolicyStringValue, |
| | gpsPolicyAttributeValue |
+-----------------+---------------------------------------------------+
Table 2. Variable Names and Their Default Class Mappings
Note: Values are defined in section 4.5.
4.5 QoS Policy Value
The abstract class gpsPolicyValue is used for defining values and
constants used in policy conditions. Different value types are derived
Snir, Ramberg, Strassner, Cohen expires May 2001 49
from this class and represent the various attributes required.
Extensions of the qpsPolicyValue class, defined in this document
provide a list of values for representing the basic network attribute.
Values can be used to represent constants as named values. Named values
could be kept in a reusable-object repository to be reused by multiple
conditions.
Examples of constants include well-known ports, well-known protocols,
server addresses, and other similar concepts.
The qpsPolicyValue classes define 3 basic types of values: scalars,
ranges and sets. For example, a well-known port number could be defined
using the gpsPolicyIntegerValue class, defining a single value (80 for
HTTP), a range (80-88), or a set (80, 82, 8080) of ports, respectively.
For details, please see the class definition for each value type in
section 8 of this document.
The QoS policy information model provide the following classes, all of
them extending the qpsPolicyValue class:
Classes for general use:
GpsPolicyStringValue,
gpsPolicyIntegerValue,
gpsPolicyBitStringValue,
gpsPolicyDNValue,
gpsPolicyAttributeValue.
Classes for layer 3 Network values:
gpsPolicyIPv4AddrValue,
gpsPolicyIPv6AddrValue.
Classes for layer 2 Network values:
gpsPolicyMACAddrValue.
For details, please see the class definition section of each value in
section 8 of this document.
4.6. PolicyTimePeriodCondition
The QoS Policy Information model uses the policyTimePeriodCondition
class (defined in [PCIM]) to define time based QoS policy rules. For
details, please see [PCIM], section 6.5.4.7. Actions
4.7 Actions
The QoS Policy information model defines actions to control QoS
enforcement in both the Integrated Service model as well as the
Differentiated Service model. Three types of actions are provided:
Signaling, Provisioning and Per-Hop-Behvior (PHB) actions.
Snir, Ramberg, Strassner, Cohen expires May 2001 50
Signaling actions are used to provide policy control on RSVP Figure 2. The QPIM Association Hierarchy
requests. Provisioning actions are used to enforce differentiated
service edge policies including marking, policing and shaping
operations. PHB actions are used to enforce per-hop behaviors across
the differentiated services domain.
A policy rule may aggregate zero or more policy actions. A QoS policy Snir, Ramberg, Strassner, Cohen expires November 2001 13
rule extends this definition to include 0..n provisioning actions,
o..k PHB actions and 0..m signaling actions, each defined by an object
or objects describing the action(s) to perform. This extension is done
seamlessly by requiring all QoS action classes to be subclasses of the
PolicyAction class defined in [PCIM]. As such, all QoS action
subclasses automatically inherit the two relationships
(PolicyActionInPolicyRule and PolicyActionInPolicyRepository) that are
used by a policy rule to aggregate actions. Actions are ordered
(as opposed to rules, which are prioritized). The order of actions is
specified in [PCIM] using the ActionOrder property.
The property SequencedActions in the aggregating instance of a 3. QoS Actions
PolicyRule (see section 6.3.6 of [PCIM]) defines whether a specified
action order is required, recommended, or of no significance.
Ordering semantics depend on how actions are represented. If actions This section describes the QoS actions that are modeled by QPIM. QoS
are represented as separate objects that are aggregated by PolicyRule, actions are policy enforced network behaviors that are specified for
the PolicyActionInPolicyRule aggregation can be used to express an traffic selected by QoS conditions. QoS actions are modeled using the
order. In this case, three attributes are used: classes PolicyAction (defined in [PCIM]), SimplePolicyAction (defined in
[PCIMe]) and several QoS actions defined in this document (described
below).
- GroupComponent, which defines zero or more PolicyRules that can 3.1 Overview
contain the same PolicyAction
- PartComponent, which defines zero or more PolicyActions that are
contained by a given policyRule
- 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 QoS policy based systems allow the network administrator to specify a set
ordering mechanism must be specified in the subclass definition. Note of rules that control both the selection of the flows that need to be
that QPIM does not define any policyRule subclasses. Instead, the QPIM provided with a preferred forwarding treatment, as well as specifying the
defines subclasses of policyCondition and policyAction to extend the specific set of preferred forwarding behaviors. QPIM provides an
semantics of these classes. information model for specifying such a set of rules.
Provisioning, PHB and signaling actions can be intermixed in a QoS QoS policy rules allow controlling environments in which RSVP signaling
policy rule. Policy consumers (such as PDPs) MAY separate the actions is used to request different forwarding treatment for different traffic
into separate lists, but MUST respect the internal order of the types from the network as well as environments where no signaling is
specified actions. used, but preferred treatment is desired for some (not all) traffic. QoS
policy rules allow controlling environments where strict QoS guarantees
are provided to individual flows as well as environments where QoS is
provided to flow aggregates. QoS actions allow a PDP or a PEP to
determine which RSVP requests should be admitted because they satisfy a
given policy, before network resources are allocated. They allow control
of the RSVP signaling content itself, as well as differentiation between
priorities of requests. QoS actions also allow specification of the
Differential Service edge enforcement including policing, shaping and
marking, as well as the per-hop behaviors used in the network core.
Finally, QoS actions can be used to control mapping of RSVP request at
the edge of a differential service cloud into per hop behaviors.
Snir, Ramberg, Strassner, Cohen expires May 2001 51 Four groups of actions are derived from action classes defined in [PCIM]
and [PCIMe]. The first QoS action group contains a single action,
QoSPolicyRSVPSimpleAction. This action is used for both signal control
and install actions depending on a type attribute. The second QoS action
group determines whether a flow or class of flows should be admitted.
This is done by specifying an appropriate traffic profile. These set of
actions are called QoS admission actions. The third group of actions
control bandwidth allocation and congestion control differentiations,
which together specify the per-hop behavior forwarding treatment. The
forth QoS action is unconditional packet discard action. This action is
used either by itself or as a building block of the
QoSPolicyPoliceAction.
4.7.1 Provisioning Actions Note that some QoS actions are not directly modeled. Instead, they are
modeled by using the class SimplePolicyAction with the appropriate
associations. For example, the three marking actions (DSCP, IPP and CoS)
are modeled by using the SimplePolicyAction class, associating it with
variables and values of the appropriate type.
QoS policy provisioning actions configure traffic conditioner Snir, Ramberg, Strassner, Cohen expires November 2001 14
elements, as specified in [DIFF-SERV-ARCH]. Actions configure meters,
markers, shapers and droppers.
The qosPolicyPRAction class is a generic class that defines a 3.2 RSVP Policy Actions
set of DiffServ actions that can be applied to an individual flow or
to a group of flows.
4.7.1.1 Meters There are three types of decisions a PDP (either remote or within a PEP)
can make when it evaluates an RSVP request:
Meters measure the temporal properties of a stream of packets 1. Admit or reject the request
selected by a classifier against a traffic profile. 2. Use admission parameters to decide whether to admit the request or
not
3. Use signaling parameters to decide how to modify the RSVP signaling
messages
A meter is associated with a provisioning action using the The COPS for RSVP [RFC2749] specification uses different Decision object
PolicyMeterInAction association. A meter can be shared among types to model each of these decisions. QPIM follows the COPS
(i.e., used by) policy actions of different rules. If this is desired, specification and models each decision using a different action class.
then the meter SHOULD reside in a reusable-object repository. The QoSPolicyRSVPAdmissionAction with its associated
QosPolicyIntServTrfcProf determine whether to accept or reject a given
RSVP request by comparing the RSVP request's TSPEC or RSPEC parameters
against the traffic profile. For a full description of the comparison
method, see section 4, which describes traffic profiles in more detail.
Meters measure flows matching the rule condition per flow, per Using the QoSPolicyRSVPAdmissionAction, a limit on the number of admitted
interface, per role within a device, per device or per role across all reservations can be enforced as well. The QoSPolicyRSVPAdmissionAction
devices. A per flow meter conceptually creates a new meter for each can specify that a set of RSVP requests will be accepted yet a warning
flow, measuring each flow against the profile. A per interface meter message would be sent to the RSVP end points. The
measures the aggregate set of flows matching the rule condition QoSPolicyRSVPAdmissionAction controls the Decision Command and Decision
forwarded via a single interface. Other options measure traffic across Flags objects used within COPS for RSVP.
a set of interfaces assigned with the same role or across a whole
device. The gpMeterScope property of the gpsPolicyMeter class is used
to determine which of the options above is selected.Meters are measured
against traffic profile modeled by the qosPolicyPRTrfcProf object. The
association PolicyTrfcProfileInMeter is used to associate between a
meter and its traffic profile. The traffic profile used for
provisioning actions is a template containing rate and burst values,
modeled by the qosPolicyPRTrfcProf class. Traffic measured by a meter
can be classified as conforming traffic when the metered rate is below
the rate defined by the traffic profile, as excess traffic, when the
metered traffic is above the normal burst and below the Excess burst
size and violating traffic when rate is above the maximum excess burst.
The [DIFF-MIB] definition of a meter combines the traffic profile and a The class QoSPolicyRSVPSimpleAction, which is derived from the
meter as one unit. Separation of the concepts provides more flexibility PolicySimpleAction class [PCIMe], can be used to specify RSVP decisions.
in reuse of traffic profiles across different rules. The [DIFF-MIB]
defines a two level meter, and provides means to combine two level
meters into more complex meters. In this document a three level traffic
profile is defined. This allows construction of both two level meters
as well as providing an easier definition for three level meters needed
for creating AF [AF] provisioning actions.
Snir, Ramberg, Strassner, Cohen expires May 2001 52 The property qpRSVPActionType designates the instance of the class to be
either of type 'REPLACE', 'STATELESS', or both. For instances carrying a
qpRSVPActionType property value of 'REPLACE', the action is interpreted
as a COPS Replace Decision, controlling the contents of the RSVP message.
For instances carrying a qpRSVPActionType property value of 'STATELESS',
the action is interpreted as a COPS Stateless Decision, controlling the
admission parameters. If both of these actions are required, this can be
done by assigning both of the two qpRSVPActionType values, since it is a
multi-valued property.
A metered provisioning action using three level traffic profile This class is modeled to represent the COPS for RSVP Replace and
specifies the actions that should be enforced on excess and Stateless decisions. This similarity allows future use of these COPS
violating traffic using the qpExcessAction and qpViolateAction decisions to be directly controlled by a QoSPolicySimpleAction. The only
properties. A three level metered action that does not specify required extension might be the definition of a new RSVP variable.
an excess action implies that the excess traffic should be
treated as either violating or conforming traffic according to
an algorithm suitable for the enforcement of the rule. For
example, the final enforcement of such a rule may be the use of
a RED like behavior to determine whether traffic is conforming
or violating. A metered action with three level traffic profile
that specifies an exceed action but does not specify a violate
action implies that violate action is identical to the specified
exceed action.
A metered provisioning action allows additional flexibility by Snir, Ramberg, Strassner, Cohen expires November 2001 15
linking actions that should be enforced only on traffic that either
conforms, exceeds or violates a meter. The associations
PolicyConformNextAction, PolicyExcessNextAction and
PolicyViolateNextAction define actions that are not associated with the
set of actions aggregated via the PolicyActionInPolicyRule aggregation
relationship (defined in [PCIM]), and are enforced only according to
the state of the meter.
Once an a action is enforced, all actions associated to it using
one of the next action association should be enforced prior to
other actions associated to the rule using the policyActionInPolicyRule
aggregation. For example, a rule may contain two actions A and B via
the aggregation policyActionInPolicyRule. The aggregation property
ActionOrder specifies that action A should be performed prior to action
B. Action A is a metered provisioning action that specifies that
exceeding traffic should be marked with DSCP 5 and associates a
third action, action C to be enforced only on exceeding traffic.
The order of enforcement of the three actions A, B and C is as follows:
First, action A is performed.
If traffic exceeds the traffic profile, C is performed. Action B
is always performed following A or C.
4.7.1.2 Markers Example: Controlling COPS Stateless Decision
Markers are used to set the DS field of a packet to a particular DS
Code Point (DSCP), adding the marked packet to a particular DS
behavior aggregate. The marker may be configured to mark all packets
that it receives 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. The marker may also be configured to
allow or not allow remarking of packets. When the marker changes the
DSCP in a packet, it is said to have "re-marked" the packet.
Provisioning actions can include both DSCP (re)marking as well as
802.1Q, Precedence and CoS marking. Precedence marking is required for
legacy devices, i.e., devices that do not support the full DSCP field
(6 bits) in the ToS byte of the IP packet header for IPv4. CoS marking
is required when crossing a link layer that supports QoS via CoS.
Snir, Ramberg, Strassner, Cohen expires May 2001 53 The QoSPolicyRSVPSimpleAction allows the specification of admission
parameters. It allows specification of the preemption priority [RFC2751]
of a given RSVP Reservation request. Using the preemption priority value,
the PEP can determine the importance of a Reservation compared with
already admitted reservations, and if necessary can preempt lower
priority reservations to make room for the higher priority one. This
class can also be used to control mapping of RSVP requests to a
differentiated services domain by setting the QoSPolicyRSVPDSCPVariable
to the required value. This instructs the PEP to mark traffic matching
the Session and Sender specifications carried in an RSVP request to a
given DSCP value.
The qosPolicyPRAction class contains a number of properties that can be Example: Controlling the COPS Replace Decision
used to control the behavior of a marker. For example, the values of
the property qpExcessAction or qpViolateAction should be set
to 'remark' in order to model a marker that marks packets according to
a state of a meter. The properties qpExcessRemarkValue and A Policy system should be able to control the information carried in the
qpViolateMarkValue carries the marking values. The value type is RSVP messages. The QoSPolicyRSVPSimpleAction allows control of the
determined by the property qpMarkValueType. Both excess and violate content of RSVP signaling messages. An RSVP message can carry a
actions may be specified when measuring a meter against a three level preemption policy object [RFC2751] specifying the priority of the
traffic profile. Please see section 8.3 for more detail. reservation request in comparison to other requests. An RSVP message can
also carry a policy object for authentication purposes. An RSVP message
can carry a DCLASS [DCLASS] object that specifies to the receiver or
sender the particular DSCP value that should be set on the data traffic.
A COPS for RSVP Replacement Data Decision controls the content of the
RSVP message by specifying a set of RSVP objects replacing or removing
the existing ones.
4.7.1.3 Shapers 3.3 Provisioning Policy Actions
Shapers are used to delay some or all of the packets in a traffic The differentiated Service Architecture [DIFFSERV] was designed to
stream in order to bring the stream into compliance with a traffic provide a scalable QoS differentiation without requiring any signaling
profile. A shaper usually has a finite-sized buffer, and packets may protocols running between the hosts and the network. The QoS actions
be discarded if there is not sufficient buffer space to hold the modeled in QPIM can be used to control all the building blocks of the
delayed packets. Differentiated Service architecture, including per-hop behaviors, edge
classification, and policing and shaping, without a need to specify the
datapath mechanisms used by PEP implementations. This provides an
abstraction level hiding the unnecessary details and allowing the network
administrator to write rules that express the network requirements in a
more natural form. In this architecture, as no signaling between the end
host and the network occur before the sender starts sending information,
the QoS mechanisms should be setup in advance. This usually means that
PEPs need to be provisioned with the set of policy rules in advance.
Policing and Shaping actions are modeled as sub-classes of the QoS
admission action. DSCP and CoS marking are modeled as sub-classes of the
simplePolicyAction class. Bandwidth allocation, scheduling and congestion
control actions are modeled as sub-classes of the QoS PHB action.
Again, the qosPolicyPRAction class contains a number of properties that Snir, Ramberg, Strassner, Cohen expires November 2001 16
can be used to control the behavior of a shaper. For example, the value
of the property qpExcessAction or qpViolateAction should be set to
'shape' in order to model a shaper. Traffic should be shaped according
to a traffic profile defined by a qosPolicyPRTrfcProf class.
4.7.1.4. Droppers 3.3.1. Admission Actions: Controlling Policers and Shapers
Droppers are used to discard some or all of the packets in a traffic All Admission Actions have in common an association to a traffic profile
Stream. Usually, this is done in order to bring the stream into and a scope property that determines whether the traffic profile is
compliance with a traffic profile. This process is also known as compared against the rate parameters of each flow or against the
"policing" the stream. aggregate rate of all flows that match the rule's condition. For example,
using two provisioned policer actions the following policies can be
enforced:
Again, the qosPolicyPRAction class contains a number of properties that - Make sure that each HTTP flow will not exceed 64kb/s
can be used to control the behavior of a shaper. For example, the value - Make sure that the aggregate rate of all HTTP flows will not
of the property qpExcessAction or qpViolateAction should be set exceed 512Kb/s
to 'drop' to model a policer that drops packets according to the
traffic-profile specified by a qosPolicyPRTrfcProf class.
Snir, Ramberg, Strassner, Cohen expires May 2001 54 Both policies are modeled using the same QoSPolicyPoliceAction. The first
policy has its scope property set to 'flow', while the second policy has
its scope property set to 'class'. The two policies are modeled using a
rule with two police actions that, in a pseudo formal definition, looks
like the following:
4.7.1.5 Examples If (HTTP) Action1=police, Traffic Profile1=64kb/s, Scope1=flow
Action2=police, Traffic Profile2=512kb/s, Scope2=class
Below are two examples on how this document models rules specifying The provisioned policer action QoSPolicyPoliceAction has 3 associations,
provisioning actions to be enforced on the edge of a differential QoSPolicyConformAction, QoSPolicyExceedAction and QoSPolicyViolateAction.
service domain. The policer action is associated with a three-level token bucket traffic
profile carrying rate, burst and excess-burst parameters. Traffic
measured by a meter can be classified as conforming traffic when the
metered rate is below the rate defined by the traffic profile, as excess
traffic when the metered traffic is above the normal burst and below the
excess burst size, and violating traffic when rate is above the maximum
excess burst.
Example 1: The [DIFF-MIB] defines a two-level meter, and provides a means to combine
two-level meters into more complex meters. In this document, a three-
level traffic profile is defined. This allows construction of both two-
level meters as well as providing an easier definition for three-level
meters needed for creating AF [AF] provisioning actions.
Traffic flowing from one machine to another should be marked with DSCP A policer action with a non-specified conform action implies that
X to provide it with the correct per hop behavior. This traffic should conforming traffic should not be modified. A policer action with an
not exceed 1Mb/sec. Each flow should not exceed more than 300Kb/sec. A associated three-level traffic profile that does not specify an excess
single policy rule can be constructed to enforce this set of actions. action implies that the excess traffic should be treated as either
The condition can be built from two simple conditions matching the violating or conforming traffic according to some algorithm suitable for
source IP address of one machine and the destination of the other the enforcement of the rule. For example, the final enforcement of such a
machine. A set of three provisioning actions can be used in the rule may be the use of a random function similar to RED to determine
following form: whether traffic is conforming or violating. A policer action with a
three-level traffic profile that specifies an exceed action but does not
specify a violate action implies that violate action is identical to the
specified exceed action.
Action 1: Snir, Ramberg, Strassner, Cohen expires November 2001 17
Object: qosPolicyPRAction
qpMarkValueType: DSCP
qpMarkValue: X
Action 2: Shapers are used to delay some or all of the packets in a traffic stream
Object: qosPolicyPRAction in order to bring the stream into compliance with a traffic profile. A
PolicyMeterInAction association to: Meter-1 shaper usually has a finite-sized buffer, and packets may be discarded if
qpExcessAction: Drop there is not sufficient buffer space to hold the delayed packets. Shaping
is controlled by the QoSPolicyShapeAction class. The only required
association is a traffic profile that specifies the rate and burst
parameters that the outgoing flows should conform with.
Action 3: 3.3.2 Controlling Markers
Object: qosPolicyPRAction
PolicyMeterInAction association to: Meter-2
qpExcessAction: Drop
The meters and traffic profile can take the form of: Three types of markers are modeled in QPIM: Differentiated Services Code
Point (DSCP), IP Precedence (IPP) and layer-2 Class of Service (CoS). The
marking action itself is modeled by using the SimplePolicyAction class
associated with the appropriate variables and values.
Meter 1: DSCP markers set the DS field of a packet header to a particular DS Code
Object: GpsPolicyMeter Point (DSCP), adding the marked packet to a particular DS behavior
gpMeterScope: interface aggregate. The marker may be configured to mark all packets that it
PolicyTrfcProfileInMeter association to: Profile-1 receives 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. This can be achieved by associating a marking action
with a policer action using the conform, exceed and violate action
associations. The semantics of the DSCP marker is encapsulated in the
pairing of a DSCP variable and a DSCP value within a single
SimplePolicyAction instance via the appropriate associations.
Meter 2: IPP markers set the IPP field of a packet header to a particular IPP
Object: GpsPolicyMeter value (0 through 7). The semantics of the IPP marker is encapsulated in
gpMeterScope: flow the pairing of a DSCP variable masked to IPP sub-field and a DSCP value
PolicyTrfcProfileInMeter association to: Profile-2 masked to IPP sub-field within a single SimplePolicyAction instance via
the appropriate associations.
Profile 1: CoS markers control the mapping of a per-hop behavior to a layer-2 Class
Object: QosPolicyPRTrfcProf of Service. For example, mapping of a set of DSCP values into a 802.1q
QpPRRate: 1Mb/sec user priority value can be specified using a rule with a condition
QpPRNormalBurst: 1000 bytes describing the set of DSCP values, and a CoS marking action that
specifies the required mapping to the given user priority value. The
semantics of the CoS marker is encapsulated in the pairing of a CoS
variable and a CoS value (integer in the range of 0 through 7) within a
single SimplePolicyAction instance via the appropriate associations.
Snir, Ramberg, Strassner, Cohen expires May 2001 55 3.3.3 Controlling Edge Policies - Examples
Profile 2: Assuming that the AF1 behavior aggregate is enforced within a DS domain,
policy rules on the edge of the network should mark packets to one of the
AF1x DSCPs depending on conformance to a predetermined three-parameter
traffic profile. QPIM models such AF1 policing action as defined in
Figure 3.
Object: QosPolicyPRTrfcProf Snir, Ramberg, Strassner, Cohen expires November 2001 18
QpPRRate: 300Kb/sec +-----------------------+ +------------------------------+
QpPRNormalBurst: 1000 bytes | QoSPolicyPoliceAction |====| QoSPolicyTokenBucketTrfcProf |
| scope = class | | rate = x, bc = y, be = z |
+-----------------------+ +------------------------------+
* @ #
* @ #
* @ +-------------------------+ +--------------------+
* @ | SimplePolicyAction |---| PolicyIntegerValue |
* @ +-------------------------+ | AF13 |
* @ +--------------------+
* +-------------------------+ +--------------------+
* | SimplePolicyAction |---| PolicyIntegerValue |
* +-------------------------+ | AF12 |
* +--------------------+
+-------------------------+ +--------------------+
| SimplePolicyAction |---| PolicyIntegerValue |
+-------------------------+ | AF11 |
+--------------------+
Example 2: Conditioning traffic Association and Aggregation Legend:
Some PHBs require the successive application of a set of traffic **** QoSPolicyConformAction
conditioners to properly process the traffic. An example of a policy @@@@ QoSPolicyExceedAction
with two levels of traffic conditioning is the following: #### QoSPolicyViolateAction
==== QoSTrfcProfInAdmissionAction
---- PolicyValueInSimplePolicyAction ([PCIMe])
&&&& PolicyVariableInSimplePolicyAction ([PCIMe], not shown)
Mark packets to DSCP=24 if the rate is within profile x=<64Kb/s>, Figure 3. AF Policing and Marking
else mark packets with DSCP=25 if rate is within profile y=<128kb/s>,
else drop out-of-profile packets.
This policy rule can be modeled by using two actions. The first action The marker is made of an instance of the SimplePolicyAction class. The
measures the traffic against the first profile. If the traffic is aggregation PolicyVariableInSimplePolicyAction (which is defined in
within this profile, then the traffic is (re)marked with a DSCP of 24. [PCIMe]) is used to associate the value to mark (contained in the
If the traffic is out of profile, then the subsequent action measures PolicyDSCPValue) with the appropriate traffic action. This aggregation is
the traffic against the second higher profile. If the traffic is within not shown in this figure for simplicity. AF11 is marked on conforming
this profile, then the traffic is (re)marked with a DSCP of 25. traffic; AF12 is marked on exceeding action and AF13 on violating
Otherwise, the traffic is out of profile, and it will be dropped. traffic.
In this way, an arbitrary cascading of traffic conditioners can be The second example, shown in Figure 4, is the simplest policing action.
constructed, where each action measures traffic against a higher Traffic below a two-parameter traffic profile is unmodified, while
traffic profile and change only the out-of-profile action as required. traffic exceeding the traffic profile is discarded.
This policy rule can be build in another way using associations to Snir, Ramberg, Strassner, Cohen expires November 2001 19
actions that should be performed on exceeding or violating traffic. In +-----------------------+ +------------------------------+
this way, the first action measures traffic according to the first | QoSPolicyPoliceAction |====| QoSPolicyTokenBucketTrfcProf |
traffic profile, and reference the second action using | scope = class | | rate = x, bc = y |
policyExcessNextAction association. The second action than base its +-----------------------+ +------------------------------+
decision whether to discard or remark traffic according to the higher @
traffic profile. @
+-------------------------+
| QoSPolicyDiscardAction |
+-------------------------+
Association and Aggregation Legend:
**** QoSPolicyConformAction (not used)
@@@@ QoSPolicyExceedAction
#### QoSPolicyViolateAction (not used)
==== QoSTrfcProfInAdmissionAction
Snir, Ramberg, Strassner, Cohen expires May 2001 56 Figure 4. A Simple Policing Action
4.7.2 Per-Hop-Behavior Actions 3.4 Per-Hop Behavior Actions
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 [DIFF-SERV-ARCH]. The approach taken here is that a PHB aggregate [DIFFSERV]. The approach taken here is that a PHB action
action specifies both observable forwarding behavior (i.e., loss, delay specifies both observable forwarding behavior (i.e., loss, delay, jitter)
,jitter) as well as specifying the buffer and bandwidth resources that as well as specifying the buffer and bandwidth resources that need to be
needs to be allocated to each of the behavior aggregates in order to allocated to each of the behavior aggregates in order to achieve this
achieve these observables. That is, a rule with a set of PHB actions behavior. That is, a rule with a set of PHB actions can specify that an
can specify that an EF packet must not be delayed more than 20 msec in EF packet must not be delayed more than 20 msec in each hop. The same
each hop. The same rule may also specify that that EF packets needs to rule may also specify that EF packets need to be treated with preemptive
be treated with preemptive forwarding (priority queuing), and specify forwarding (e.g., with priority queuing), and specify the maximum
the maximal bandwidth for this class as well as the maximal buffer bandwidth for this class as well as the maximum buffer resources. PHB
resources. PHB actions can therefore be used to both represent the actions can therefore be used to both represent the final requirements
final requirements from PHBs as well as provide enough detail to be from PHBs as well as provide enough detail to be able to map the PHB
able to map the PHB actions into a set of configuration parameters to actions into a set of configuration parameters to configure queues,
configures queues, schedulers, droppers and other mechanism. In schedulers, droppers and other mechanisms.
particular, the PHB actions includes attributes that are directly
mapped to the differential service MIB configuration scheme
[DUFF-MIB].
Description of the properties of the PHB Action that are directly
mapped to the diffserv MIB [DIFF-MIB] are aligned with the
definition in the MIB. We refer to the MIB for a thorough discussion of
these properties and for an explanation of why this minimal set of
parameters where chosen to describe each mechanism.
4.7.2.1 Bandwidth and Delay Management
PHB actions allows specifying the minimal bandwidth that should be
reserved for a class of traffic. The property qpMinBandwidth can be
specified either in Kb/sec or in percentage of the total available
bandwidth. The property qpBandwidthValueType is used to determine
whether percentage of fixed values are used.
The property qpForwardingPriority is used whenever preemptive
forwarding is required. A policy rule that defines EF PHB should
indicate a non zero forwarding priority. QpForwardingPriority holds an
integer value to enable multiple levels of preemptive forwarding where
higher values specifies higher priority.
The property qpMaxBandwidth specifies the maximal bandwidth that should
be allocated to a class of traffic. This property may be specified in
PHB actions with non-zero forwarding priority in order to guard against
starvation of other PHBs.
The properties qpMaxDelay and qpMaxJitter specifies limits on the per
hop delay and jitter in milliseconds for any given packet within a
traffic class. Enforcement of the maximal delay and jitter may require
use of preemptive forwarding as well as minimal and maximal bandwidth
controls. Enforcement of low max delay and jitter values may also
require fragmentation and interleave mechanisms over low speed links.
Snir, Ramberg, Strassner, Cohen expires May 2001 57
4.7.2.2 Congestion Control and Buffer Management
PHB actions provide buffer resources and congestion control
management.
The property qpDropAlgorithm can be used to select either tail-
drop, head-drop or random-drop algorithms. The set of maximal and
minimal threshold values can be specified as well, either in bytes, in
packets or in percentage of the total available buffers. Two additional
properties are provided for controlling random drop, as explained in
[DIFF-MIB]. The properties are qpRandomDropInvWeight and
qpRandomDropProbMax that control the RED weight factor and worst
probability, see [DIFF-MIB] for more details.
4.7.2.3 Queues and PHB groups
PHB actions provide control on the way packets that match a rule The QoSPolicyPHBAction abstract class has two subclasses. The
should be queued for forwarding. The qosPolicyQueue class specify the QoSPolicyBandwidthAction class is used to control bandwidth, delay and
queuing properties of the PHB action. Two PHB actions, used within two forwarding behavior, while the QoSPolicyCongestionControlAction class is
different rules may reference the same qosPolicyQueue object, used to control queue size, thresholds and congestion algorithms. The
indicating that flows matched by these rules should use the same qpPacketSize property of the PHB action specifies the packet size in
queue. For example, rules specifying PHB actions for AF11 and bytes, and is needed when translating the actions into actual
AF12 [AF] PHBs should indicate that AF11 and AF12 belong to the implementation configurations. For example, implementation measuring
same PHB group and should be queued together to avoid packet reordering queue length in bytes will need to use this property to map the
affects. qpQueueSize property into queue length in bytes.
This can be achieved by reusing a PHB action within the AF1x
rules that specify the bandwidth and delay properties as well as
indicating that the same queue must be used.
The association PolicyQueueInPHBAction associates between a PHB Snir, Ramberg, Strassner, Cohen expires November 2001 20
action and a qosPolicyQueue.
The qosPolicyQueue class carries all properties described in the 3.4.1 Controlling Bandwidth and Delay
bandwidth and delay management section. The Boolean property
qpFairQueue indicates whether flows should have a fair chance to
be forwarded without drop or delay. A way to enforce a PHB
action with qpFairQueue set to TRUE would be to build a queue
per flow for the class of traffic specified in the rule's
filter. In this way interactive flows like terminal access will
not be queued behind a bursty ftp flow and therefore have a reasonable
response time.
Schedulers and Queue sets are not modeled directly in the QoS QoSPolicyBandwidthAction allows specifying the minimal bandwidth that
Policy Information model. Nevertheless, hierarchical policy rules may should be reserved for a class of traffic. The property qpMinBandwidth
require enforcement using more than a single scheduler or queue set. can be specified either in Kb/sec or in percentage of the total available
This is explained in the next section. bandwidth. The property qpBandwidthUnits is used to determine whether
percentage or fixed values are used.
Snir, Ramberg, Strassner, Cohen expires May 2001 58 The property qpForwardingPriority is used whenever preemptive forwarding
is required. A policy rule that defines the EF PHB should indicate a non-
zero forwarding priority. The qpForwardingPriority property holds an
integer value to enable multiple levels of preemptive forwarding where
higher values are used to specify higher priority.
4.7.2.4 Using Hierarchical policies The property qpMaxBandwidth specifies the maximum bandwidth that should
be allocated to a class of traffic. This property may be specified in PHB
actions with non-zero forwarding priority in order to guard against
starvation of other PHBs.
The ability to define sub rules within rules allow for definition of The properties qpMaxDelay and qpMaxJitter specify limits on the per-hop
hierarchical policies. Hierarchical policies form a hierarchy of delay and jitter in milliseconds for any given packet within a traffic
classification and specification of actions for each level of the class. Enforcement of the maximum delay and jitter may require use of
hierarchy. For example, a rule may specify the actions that preemptive forwarding as well as minimum and maximum bandwidth controls.
should be performed on all UDP traffic, while its sub rules specify the Enforcement of low max delay and jitter values may also require
actions that should be performed on various UDP applications. Rules fragmentation and interleave mechanisms over low speed links.
specified higher in the hierarchy also apply to all sub rules and are
logically performed first [see Section 5.3]. Bandwidth and Buffer
resources specified in relative terms (percentage of total resources)
relate to the resources allocated higher in the hierarchy. For example,
bandwidth resources can be shared between UDP applications summing up
to 100% of the resources allocated to UDP traffic.
Hierarchical policies defining PHB actions may therefore require
hierarchical scheduler for correct enforcement.
4.7.2.5 Examples The Boolean property qpFairness indicates whether flows should have a
fair chance to be forwarded without drop or delay. A way to enforce a
bandwidth action with qpFairness set to TRUE would be to build a queue
per flow for the class of traffic specified in the rule's filter. In this
way, interactive flows like terminal access will not be queued behind a
bursty flow (like FTP) and therefore have a reasonable response time.
This example provides a set of rules that specify PHBs enforced within 3.4.2 Congestion Control Actions
a Differential Service Domain. In this example the PHBs selected to be
enforced within the domain are EF, AF11 and AF12 and Best Effort. There
may be alternate ways to construct policy rules to represent these
PHBs.
The set of rules takes the form: The QoSPolicyCongestionControlAction class controls queue length,
thresholds and congestion control algorithms.
If (EF) than do EF actions A PEP should be able to keep in its queues qpQueueSize packets matching
If (AF11) than do AF11 actions the rule's condition. In order to provide a link-speed independent queue
If (AF12) than do AF12 actions size, the qpQueueSize can also be measured in milliseconds. The time
If (default) than do Default actions. interval specifies the time needed to transmit all packets within the
queue if the link speed is dedicated entirely for transmission of packets
within this queue. The property qpQueueSizeUnit determines whether queue
size is measured in number of packets or in milliseconds.
EF, AF11, AF12 represent conditions that filter traffic according to The property qpDropAlgorithm selects either tail-drop, head-drop or
DSCP values. These filters are represented using either a reusable or random-drop algorithms. The set of maximum and minimum threshold values
ad-hoc policy conditions. The default rule uses a 'catch all' filter can be specified as well, using qpThresholdMin and qpThresholdMax
and specifies the Best Effort rules. properties, either in packets or in percentage of the total available
The set of rules reside in a gpsPolicyGroup. queue size as specified by the qpThresholdUnits property.
The decision strategy is defined to be 'FIRST MATCH'.
The objects below specifies the set of actions used to describe each of Snir, Ramberg, Strassner, Cohen expires November 2001 21
the PHBs:
QosPolicyPHBAction BE: 3.4.3 Using Hierarchical Policies Examples for PHB actions
PolicyQueueInPHBAction association to: Beq
QpDropAlgorithm: random
qpDropThresholdValueType packet
qpDropMinThreshold: 6pckts
qpDropMaxThreshold: 40pckts
Snir, Ramberg, Strassner, Cohen expires May 2001 59 Hierarchical policy definition is a primary tool in the QoS Policy
Information model. Rule nesting introduced in [PCIMe] allows
specification of hierarchical policies controlling RSVP requests,
hierarchical shaping, policing and marking actions, as well as
hierarchical schedulers and definition of the differences in PHB groups.
An example of the use of hierarchical schedulers is provided in [PCIMe].
QosPolicyPHBAction AF11: This example provides a set of rules that specify PHBs enforced within a
Differentiated Service Domain. The network administrator chose to enforce
the EF, AF11 and AF13 and Best Effort PHBs. For simplicity, AF12 is not
differentiated. The set of rules takes the form:
PolicyQueueInPHBAction association to: AF1xq If (EF) then do EF actions
If (AF1) then do AF1 actions
If (AF13) then do AF13 actions
If (default) then do Default actions.
QpDropAlgorithm: random EF, AF1 and AF13 are conditions that filter traffic according to DSCP
values. The AF1 condition matches the entire AF1 PHB group including the
AF11, AF12 and AF13 DSCP values. The default rule uses a 'match all'
condition and specifies the Best Effort rules. The nesting of the AF13
rule within the AF1 rule specifies that there are further refinements on
how AF13 traffic should be treated relative to the entire AF1 PHB group.
The set of rules reside in a PolicyGroup with a decision strategy
property set to 'MATCH FIRST'.
qpDropThresholdValueType packet The class instances below specify the set of actions used to describe
each of the PHBs. Queue sizes are not specified, but can easily be added
to the example.
qpDropMinThreshold: 4pckts The actions used to describe the Best Effort PHB are simple. No bandwidth
qpDropMaxThreshold: 20pckts is allocated to Best Effort traffic. The first action specifies that Best
Effort traffic class should have fairness.
QosPolicyPHBAction AF12: QosPolicyBandwidthAction BE-B:
PolicyQueueInPHBAction association to: AF1xq qpFairness: True
QpDropAlgorithm: random
qpDropThresholdValueType packet
qpDropMinThreshold: 2pckts
qpDropMaxThreshold: 10pckts
QosPolicyPHBAction EF: The second action specifies that the congestion algorithm for the Best
PolicyQueueInPHBAction association to: EFq Effort traffic class should be random, and specifies the thresholds in
QpDropAlgorithm: drop percentage of the default queue size.
qpDropThresholdValueType packet
qpDropMaxThreshold: 3pckts
AF11 and AF12 share the same queue, indicating that they belong to the QoSPolicyCongestionControlAction BE-C:
same PHB group. Following are the qosPolicyQueue objects defined in qpDropAlgorithm: random
this example: qpDropThresholdUnits %
qpDropMinThreshold: 10%
qpDropMaxThreshold: 70%
qosPolicyQueue BEq: Snir, Ramberg, Strassner, Cohen expires November 2001 22
qpBandwidthValueType
qpFairQueue: TRUE
qosPolicyQueue AF1xq: EF requires preemptive forwarding. The maximum bandwidth is also
qpBandwidthValueType: kb/sec specified to make sure that the EF class does not starve the other
qpMinBandwidth: 512Kb/sec classes. EF PHB uses tail drop as the applications using EF are supposed
to be UDP-based and therefore would not benefit from a random dropper.
qosPolicyQueue EFq: QosPolicyBandwidthAction EF-B:
qpForwardingPriority: 1 qpForwardingPriority: 1
qpBandwidthValueType: % qpBandwidthUnits: %
qpMaxBandwidth 50% qpMaxBandwidth 50%
qpFairQueue: FALSE qpFairness: False
AF1x actions are associated with the same qosPolicyQueue
indicating that all AF rules performing this action belong to the same
PHB group. The AF1x queue specify the minimal bandwidth that should be
allocated to this PHB group. AF11 and AF12 actions indicate the maximal
and minimal thresholds for AF1x packets.
Snir, Ramberg, Strassner, Cohen expires May 2001 60
qpForwardingPriority property of the EF action specify that
preemptive forwarding is required for this PHB. qpMaxBandwidth
property specify that EF should not use more than 50% of the link
bandwidth.
Random Drop is enforced by AF and BE PHBs. EF PHB uses tail drop
as the applications using EF are supposed to be UDP based and rate
controlled and will not benefit from a random dropper.
The set of minimal and maximal thresholds in this example are
defined in packets. The remaining random drop parameters are not
specified and left for the enforcer defaults.
QpFairQueue property indicates that Best Effort traffic should
provide fairness among flows.
4.7.3 Signaling Actions
RSVP is the standard protocol used for requesting QoS resources
>From the network. The QoS policy signaling actions defined in this
document can be used to control whether to admit or reject an RSVP
request based on the request's attributes and the specified policy. The
QoS policy signaling actions allow modifying the content and forwarding
behavior of RSVP requests.
The signaling policies control the admission priority of
resources and provide preemption support. Mapping of integrated
services signaled by RSVP to differential services in a core network is
controlled by signaling policies as well, by assigning appropriate
DSCPs to flows on the boundary of the differential service core.
The set of policies specified allow a policy server (policy
Decision point) to instruct an RSVP node (policy enforcement point) to
Enforce all set of controls defined in the COPS protocol specification.
The actions defined here follow the different decision types of the
COPS protocol [COPS] and the guidelines for its use in an RSVP
Environment [COPS-RSVP]. The basic decision to accept or deny a
reservation is modeled by the qosPolicyRSVPAction class. Additional
control is provided through the use of two classes. The content and
forwarding behavior of RSVP flows is controlled by the
osPolicyRSVPSignalCtrlAction class. The qosPolicyRSVPInstallAction
class controls the processing of RSVP requests and accompanying flows
within the RSVP node itself.
QoS signaling policies does not require a policy server for
decision making. A local policy module can use signaling policies for
making local decisions or use either COPS or any other outsourcing
protocol for enforcement of these signaling policies.
Snir, Ramberg, Strassner, Cohen expires May 2001 61
The qosPolicyRSVPAction action includes a specification of the
Subset of RSVP flows on which the action should be taken. The following
parameters can be specified:
1. Direction - in/out
2. Message type - Path/Resv/PathErr/ResvErr
3. Service type - Guaranteed Service / Controlled Load / Null
4. Service style - SE, WF, FF
The direction refers to the direction of the flow, hence the
Direction of the RSVP Path messages. Therefore, out-direction policies
Control outgoing Path messages as well as incoming Resv messages.
4.7.3.1 Admission Control
The basic decision modeled by the qosPolicyRSVPAction class is
whether to admit or reject the RSVP request. The decision can be
based on comparison of the request TSPEC or FLOWSPEC against a meter.
This allows basing an admission decision both on the properties
of the reservation request itself as well as on the current
temporal resource allocation.
Meters allow enforcement of policies of the form: "Allow
allocation of resource via RSVP for flows coming from subnet x
up to a total aggregated rate of 256kb/sec". The meter tracks
the current state of resource allocated to subnet x, and
compares any new request for resources against a 256Kb/sec
traffic profile. A meter can be reused by two signaling actions
of two rules, indicating that the this meter should measure the
aggregated resource allocation for both rules.
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.
4.7.3.2 Forwarding Behavior
The qosPolicyRSVPInstallAction class provides control on the way
resource allocation requests are handles within the RSVP node,
without changing the content of the RSVP messages themselves. In
particular it allows instructing the RSVP node to:
1. Set the DSCP value of the flows for which the reservation
was made.
2. Set the preemption priority of the RSVP request.
Setting the DSCP of the flow on the edge of a differential
service core allow provisioning of QoS, end-to-end, over mixed
integrated and differential service clouds.
Snir, Ramberg, Strassner, Cohen expires May 2001 62
An RSVP node is responsible for deciding whether to admit flows
or not, based on its available resources. Setting the preemption
priority [RSVP_PREEMP] allows the RSVP node to decide which of its
reservations should be admitted, and when to make room for a newer
reservation by preempting an already installed one.
This class should be extended to cover other COPS install
decisions if required.
4.7.3.3 Signaling Control
The qosPolicyRSVPSignalCtrlAction class provides control on the
content of RSVP signaling message and their processing rules. In
particular it may include the following controls:
1. Replace/add DCLASS object in RSVP message.
2. Replace/add Preemption priority object in RSVP message.
3. Trigger an error/warning RSVP message.
4. Instruct the RSVP node to proxy RSVP message as if sent by
the RSVP end nodes.
Modifying the content of messages can be enforced using a COPS
replacement decision. This class should be extended to cover other
object replacements and, in particular, replacement of policy objects.
Triggering errors and warnings is important in scenarios when there is
a need to notify the end nodes that their reservation is about to
expire and various other information.
There are scenarios in which it makes sense not to carry RSVP requests
end-to-end. An RSVP node on the boundary of a differential service core
may map the RSVP request to specific PHB by setting the DSCP on the
flow packets, without forwarding the Path message downstream. Still,
this RSVP node may send back an RSVP Resv message as if the receiver
has sent it, to complete the RSVP cycle.
4.7.3.4 Examples
Below is an example on how this document models rules specifying
a set of signaling actions:
Admit RSVP reservation requests for VoIP traffic with FF style
only if the request asks for less the 64Kb/sec. Do not allow
more than 5 VoIP reservations to be admitted on any single
interface. In this examples two actions are used to represent
the required policy.
qosPolicyRSVPAction 1:
qpRSVPMessageType: Resv
qpRSVPStyle: FF
PolicyMeterInAction association to: Meter-1
Snir, Ramberg, Strassner, Cohen expires May 2001 63
qosPolicyRSVPAction 2:
qpRSVPMessageType: Resv
qpRSVPStyle: FF
PolicyMeterInAction association to: Meter-2
The two meters specify the different scopes of each of the meters and a
traffic profile. The first traffic profile limits the maximal resources
allocated to a single request while the second traffic profile limits
the number of reservations admitted at any given time.
gpsPolicyMeter Meter-1:
qpRSVPMeterScope: flow
PolicyTrfcProfileInMeter association to: Prof-1
gpsPolicyMeter Meter-1:
qpRSVPMeterScope: interface
PolicyTrfcProfileInMeter association to: Prof-2
qosPolicyRSVPTrfcProf Prof-1: QoSPolicyCongestionControlAction EF-C:
qpRSVPTokenRate: 64kb/sec QpDropAlgorithm: tail-drop
qpDropThresholdUnits packet
qpDropMaxThreshold: 3 packets
qosPolicyRSVPTrfcProf Prof-2: The AF1 actions define the bandwidth allocations and thresholds for the
qpRSVPSessionNum: 5 entire PHB group:
The various attributes of RSVP traffic profiles are described in the QosPolicyBandwidthAction AF1-B:
next section. qpBandwidthUnits: %
qpMinBandwidth: 30%
4.8. Meters and Traffic Profiles QoSPolicyCongestionControlAction AF1-C:
QpDropAlgorithm: random
qpDropThresholdUnits packet
qpDropMinThreshold: 4 packets
qpDropMaxThreshold: 20 packets
Meters measure the a temporal state of a flow or a set of flows The AF13 action specifies the differentiating refinement for the AF13 PHB
against a traffic profile. In this document meters are modeled within the AF1 PHB group. The lower threshold values provide the higher
by psPolicyMeter class, while traffic profiles are modeled by discard probability of the AF13 PHB.
gpsPolicyTrfcProf class. The association PolicyTrfcProfileInMeter
models the relation between a meter and a traffic profile. Two traffic
profiles are derived from the abstract class gpsPolicyTrfcProf.
Provisioning traffic profiles carry rate and burst parameters to be
compared with flow meters. RSVP traffic profiles are compared with
RSVPTSPEC and FLOWSPEC parameters, and with meters aggregating the
temporal state of admitted RSVP reservations and states.
Snir, Ramberg, Strassner, Cohen expires May 2001 64 QosPolicyCongestionControlAction AF13-C:
QpDropAlgorithm: random
qpDropThresholdUnits packet
qpDropMinThreshold: 2 packets
qpDropMaxThreshold: 10 packets
4.8.1. Provisioning traffic profiles 4. Traffic Profiles
Shaping, policing and remarking provisioning actions compare a Meters measure the temporal state of a flow or a set of flows against a
provisioning traffic profile against a meter. The provisioning traffic traffic profile. In this document, traffic profiles are modeled by the
profile is a template containing rate and burst values, modeled gpsPolicyTrfcProf class. The association
by the qosPolicyPRTrfcProf class. QoSPolicyTrfcProfileInAdmissionAction binds the traffic profile to the
admission action using it. Two traffic profiles are derived from the
abstract class gpsPolicyTrfcProf. The first is a Token Bucket
Provisioning traffic profile carrying rate and burst parameters. The
second is an RSVP traffic profile, which enables flows to be compared
with RSVP TSPEC and FLOWSPEC parameters.
The qosPolicyPRTrfcProf class includes the following properties: Snir, Ramberg, Strassner, Cohen expires November 2001 23
1. Rate measured in kbits/sec. 4.1 Provisioning Traffic Profiles
2. Normal burst measured in bytes.
3. Excess burst measured in bytes.
Rate determines the long-term average transmission rate. Traffic Provisioned Admission Actions including Shaping and policing are
That falls under this rate will always conform. The normal burst size specified using a two- or three-parameter token bucket traffic profile.
determines how large traffic bursts can be before some traffic The qosPolicyTokenBucketTrfcProf class includes the following properties:
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 1. Rate measured in kbits/sec
burst size. If the excess burst size is not specified, it is assumed 2. Normal burst measured in bytes
that excess burst size is equal to the normal burst size. In this 3. Excess burst measured in bytes
case, burst larger than the normal burst size will always be counted
as out-of-profile packets.
Snir, Ramberg, Strassner, Cohen expires May 2001 65 Rate determines the long-term average transmission rate. Traffic that
falls under this rate is conforming, as long as the normal burst is not
exceeded at any time. Traffic exceeding the normal burst but still below
the excess burst is exceeding the traffic profile. Traffic beyond the
excess burst is said to be violating the traffic profile.
4.8.2. RSVP traffic profiles Excess burst size is measured in bytes in addition to the burst size. A
zero excess burst size indicates that no excess burst is allowed.
RSVP signaling QoS policy can condition the decision whether to accept 4.2 RSVP traffic profiles
or deny an RSVP request based on the traffic specification of the flow
(TSPEC) or the amount of QoS resources requested (FLOWSPEC). The TSPEC
and FLOWSPEC objects are either compared directly with a traffic
profile, or aggregated to a meter that measures the temporal admitted
RSVP states and than compared to the traffic specification. The
qosPolicyRSVPTrfcProf class models such a traffic profile. The RSVP admission policy can condition the decision whether to accept or
qosPolicyRSVPTrfcProf class has the following properties: deny an RSVP request based on the traffic specification of the flow
(TSPEC) or the amount of QoS resources requested (FLOWSPEC). The
admission decision can be based on matching individual RSVP requests
against a traffic profile or by matching the aggregated sum of all
FLOWSPECs (TSPECs) currently admitted. The QosPolicyIntesrvTrfcProf
class models both such traffic profiles. This 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.
The first 5 parameters are the traffic specification parameters used in The first 5 parameters are the traffic specification parameters used in
the integrated service architecture. These parameters are used to the integrated service architecture. These parameters are used to define
define a sender TSPEC as well as FLOWSPEC for the Controlled Load a sender TSPEC as well as FLOWSPEC for the Controlled-Load service [CL].
service [CL]. For a definition and full explanation of their meaning, For a definition and full explanation of their meaning, please refer to
please refer to [RSVP-IS]. Parameters 6 and 7 are the additional [RSVP-IS]. Parameters 6 and 7 are the additional parameters used for
parameters used for specification of the Guaranteed Service FLOWSPEC specification of the Guaranteed Service FLOWSPEC [GS].
[GS]. The last parameter is used to specify the maximum number of
allowed RSVP sessions. This provides an easy way to limit the number of
admitted RSVP requests without requiring pre-knowledge of the
aggregated rates requested.
A partial order is defined between TSPECs (and FLOWSPECs). A TSPEC A is Snir, Ramberg, Strassner, Cohen expires November 2001 24
larger than TSPEC B if and only if rA>rB, pA>pB, bA>bB, mA<mB and
MA>MB. A TSPEC measured against a traffic profile uses the same
ordering rule. An RSVP message is accepted only if its TSPEC (FLOWSPEC)
is either smaller or equal to the traffic profile. Only parameters
specified in the traffic profile are compared.
The GS FLOWSPEC is also compared against the rate R and the slack term A partial order is defined between TSPECs (and FLOWSPECs). The TSPEC A is
S. R should not be larger than the traffic profile R parameter, while larger than the TSPEC B if and only if rA>rB, pA>pB, bA>bB, mA<mB and
the FLOWSPEC slack term should not be smaller than that specified in MA>MB. A TSPEC (FLOWSPEC) measured against a traffic profile uses the
the slack term. same ordering rule. An RSVP message is accepted only if its TSPEC
(FLOWSPEC) is either smaller or equal to the traffic profile. Only
parameters specified in the traffic profile are compared.
The GS FLOWSPEC is also compared against the rate R and the slack term S.
R should not be larger than the traffic profile R parameter, while the
FLOWSPEC slack term should not be smaller than that specified in the
slack term.
TSPECs as well as FLOWSPECs can be added. The sum of two TSPECs is 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 value of the minimum policed unit m and the maximum
packet size M. GS FLOWSPECs are summed by adding the Resv rate and value of the maximum packet size M. GS FLOWSPECs are summed by adding the
minimizing the slack term s. These rules are used to compute a meter Resv rate and minimizing the slack term s. These rules are used to
that measures the temporal state of admitted RSVP states. The meter is compute the temporal state of admitted RSVP states matching the traffic
than compared with the traffic profile specified in the signaling class defined by the rule condition. This state is compared with the
traffic profile to arrive to an admission decision when the scope of the
Snir, Ramberg, Strassner, Cohen expires May 2001 66 QoSPolicyRSVPAdmissionAction is set to 'class'.
policy using the same rules for comparison of TSPECs (FLOWSPECs) to a
traffic profile.
5. Decision strategy
Section 5.1 discusses how policy rules are organized into containers so
that decision strategies can be applied to groups of policy rules.
Section 5.2 defines two different decision strategies. Section 5.3
provides examples to illustrate how the different decision strategies
affect the policy rules they operate on.
5.1 Organizing the Application of Decision Strategies
This document recommends the following approach to be used by policy
servers and other policy decision points in the network for QoS
applications. The set of policies to be used is managed by first
assigning them to their respective policy domains or reusable-object
repositories. The policy rules will then be grouped into a set of
gpsPolicyGroup groups. The organization of these gpsPolicyGroup groups
is to be used to reflect any administrative, geographical, or other
constraints that should be enforced by the policy system. This set of
gpsPolicyGroup groups is used to partition behavior in the different
QoS policy domains.
The goal is to ensure that different policy servers using the same
group of policy rules will enforce consistent behavior. That is, they
will treat the conditions of the rules in the same way, and execute the
same actions in the same order. Therefore, the priority of the policy
rules must be pre-defined and the decision strategy implemented by each
different policy server must be defined explicitly.
The decision strategy is defined per domain and can be overridden by
any PolicyDomain or gpsPolicyGroup instances that are contained within
the domain. When a policy decision point evaluates a set of rules, it
implements the decision strategy defined in each PolicyDomain or
gpsPolicyGroup instance for that set of rules. Nested PolicyDomain or
gpsPolicyGroup instances can override the decision strategy of the
PolicyDomain or gpsPolicyGroup instances that contain them.
The order of decision making for policy rules is based on the rule
priority of PCIM. However, this rule priority has been extended in two
important ways. The first is that nested rules can be defined. For
nested rules, the contained, or innermost, rule has a higher priority
than the containing, or outermost, rule. The second extension is that
the gpsPolicyGroup class is given its own priority. This enables it to
be treated in the same way that a PolicyRule is. In fact, this is
purposely done so that the priority of a PolicyRule can be directly
compared to the priority of a gpsPolicyGroup. The comparison is done
for all instances at the same nesting level.
Notice that nested rules are affected in the following way from their
containing rules:
Snir, Ramberg, Strassner, Cohen expires May 2001 67
1. The containing rule's condition list is ANDed to the sub-rule
condition list.
2. The containing rule actions are added to the sub-rule action list
and performed in the appropriate order BEFORE the sub-rule actions.
The following example helps clarify rule and sub-rule policy
application. Rule 1.1 is nested within Rule 1 in the following form:
Rule 1: If (Condition A) then Action A
|
+--- Rule 1.1 If (Condition B) then Action B
These two rules can be ordered in a non hierarchical form and enforced
as follows:
Rule 1.1 If (Condition A AND Condition B) then Action A, Action B
Rule 1: If (Condition A) then Action A
Replacing the conditions and actions with concrete values:
Rule 1: If (UDP) then guarantee 50% BW.
|
+--- Rule 1.1 If (TFTP) then Mark to DSCP=3
Leads to:
Rule 1.1 IF (UDP AND TFTP)
THEN guarantee 50% BW sharing queue x, Mark DSCP=3
Rule 1: IF (UDP)
THEN guarantee 50% BW sharing queue x.
5.2 Decision Strategies
Many different types of decision strategies can be defined. This
section defines two different decision strategies:
1. "FIRST MATCH"
2. "MATCH ALL"
5.2.1. First Match Decision Strategy
The first match decision strategy is defined as a process that
evaluates the policy rules in the defined order, evaluating the
conditions of each rule, until a condition is evaluated to TRUE. The
rule's actions are then applied and the process of decision-making is
terminated.
5.2.2. Match All Decision Strategy
The match all decision strategy is defined as first scanning the
complete set of rules according to their defined order of priority and
then applying the actions of each rule that satisfies the rule's
conditions. This matching strategy may in many cases mean that a
Snir, Ramberg, Strassner, Cohen expires May 2001 68
number of rules may satisfy the same set of conditions, and all of
their actions will be applied.
A Match All strategy may result in applying conflicting rules. Handling
conflicts is outside the scope of this draft. The implementers of QoS
systems must provide proprietary conflict detection and avoidance or
resolution mechanisms to use this or any type of decision strategy that
allows the execution of more than one rule for a given condition.
5.3. Decision Strategy example
This section demonstrates both decision strategies and rule
prioritization. The rules to be evaluated are shown in Figure 4 below.
Domain
|
+--Rule1 (priority 19)
|
+--PolicyContainer1 (priority 5)
| |
| +--Rule 1.1 (priority 3)
| |
| +--Rule 1.2 (priority 33)
|
+--Rule3 (priority 4)
|
+--Rule4 (priority 2)
Figure 4: Decision Strategy example
This figure illustrates two extensions to PCIM. The first is that a
special type of PolicyGroup, the gpsPolicyGroup, can be assigned a
priority and have its priority compared to other PolicyRules and
gpsPolicyGroups. The second is rule nesting, as illustrated by Rule 3
and Rule 4.
The order of rule processing for the example above is:
1. Rule1 (higher priority between Rule1, PolicyContainer1 and Rule3
2. Rule1.2 (both Rule 1.1 and 1.2 will be considered next, because
the priority of PolicyContainer1 is higher than the priority of
Rule 3; Rule 1.2 executes next because its priority is higher
than the priority of Rule1.1)
3. Rule1.1 (because its container has a higher priority than Rule3
4. Rule4 (because it is nested in Rule 3)
5. Rule3
If the decision strategy of the domain is 'first-match' and it is not
overridden by PolicyContainer1, the decision process will stop once a
rule's condition is matched.
Snir, Ramberg, Strassner, Cohen expires May 2001 69
If the decision strategy of the domain is 'match-all' and it is not
overridden by PolicyContainerr1, the match all decision process will
run over all rules according to the order above.
If the decision strategy of the domain is 'first-match' and the
decision process of PolicyContainer1 is match all, Rule1 will be
evaluated first. If its condition matches, the decision process stops.
Else, both Rules 1.1 and 1.2 will be evaluated (because the priority of
the named container is higher than the priority of Rule 3). However,
since the decision strategy is overridden in the named container, one
or both of Rule 1.1 and Rule 1.2 will be executed if their conditions
match. If one or both of these rules in the named container
match, the decision process stops. Else Rules 3 and 4 will be evaluated
using 'first-match' decision strategy.
If the decision strategy of the domain is 'match-all' and the decision
process of PolicyContainer1 is first match, the decision process will
evaluate Rule1 and continue to evaluate both the PolicyContainer1 rules
as well as Rule 3. Rules 1.1 and 1.2 will be evaluated using first
match strategy. The decision process continues to evaluate rules 3 and
4 according to a 'match-all' decision strategy.
6. Per Hop Behavior
A per-hop behavior (PHB) is a description of the externally
observable forwarding behavior of a DS node applied to a particular DS
Behavior aggregate. A PHB is selected at a node by the DSCP contained
in a received packet. A set of PHBs is enforced on a QoS domain.
The set of PHBs share buffer and scheduler resources among them.
QPIM provides the means for defining a set of PHBs per qos
domain by definition of a gpsPolicyGroup that includes a set of
PHB rules. Each of this rules would classify packets based on DSCP
value and define the action to be performed on this qos Class.
PHB sets can be defined as reusable objects in the policy
reusable-object repository to allow different domains to share
the same per hop behavior.
Snir, Ramberg, Strassner, Cohen expires May 2001 70
7. QoS Policy Class Inheritance
The following diagram illustrates the class hierarchy for the
QPIM. Relevant classes from the PCIM are also included for
completeness:
top
|
+--policy (abstract, [PCIM])
| |
| +--policyGroup ([PCIM])
| | |
| | +--qosPolicyDomain
| | |
| | +--gpsPolicyGroup
| |
| +--policyRule ([PCIM])
| |
| +--policyCondition ([PCIM])
| | |
| | +--policyTimePeriodCondition ([PCIM])
| | |
| | +--vendorPolicyCondition ([PCIM])
| | |
| | +--gpsPolicySimpleCondition
| | |
| | +--gpsPolicyCompoundCondition
| |
| +--policyAction ([PCIM])
| | |
| | +--vendorPolicyAction ([PCIM])
| | +-- qosPolicyPRAction
| | |
| | +-- qosPolicyPHBAction
| | |
| | +-- qosPolicyRSVPAction
| | |
| | +-- qosPolicyRSVPSignalCtrlAction
| | |
| | +-- qosPolicyRSVPInstallAction
| |
| +--gpsPolicyVariable
| |
| +--gpsPolicyValue(abstract)
| | |
| | +--gpsPolicyIPv4AddrValue
| | |
| | +--gpsPolicyIPv6AddrValue
| | |
| | |
(diagram continued in next page)
Snir, Ramberg, Strassner, Cohen expires May 2001 71
(continued from the previous page)
top
| | +--gpsPolicyMACAddrValue
| | |
| | +--gpsPolicyStringValue
| | |
| | +--gpsPolicyBitStringValue
| | |
|
+--policy (abstract, [PCIM])
| |
| +--gpsPolicyValue (abstract)
| | |
| | +--gpsPolicyDNValue
| | |
| | +--gpsPolicyAttributeValue
| | |
| | +--gpsPolicyIntegerValue
| |
| +-- gpsPolicyMeter
| |
| +-- qosPolicyQueue
| |
| +-- gpsPolicyTrfcProf
| |
| +-- qosPolicyPRTrfcProf
| |
| +-- qosPolicyRSVPTrfcProf
|
|
+--CIM_ManagedSystemElement (abstract)
|
+--CIM_LogicalElement (abstract)
|
+--CIM_System (abstract)
|
+---CIM_AdminDomain (abstract)
|
+---PolicyRepository
Figure 5. Class Inheritance Hierarchy for the QPIM
The reader is encouraged to read section 6 and section 7 of [PCIM] in
their entirety. Section 6 defines all of the object classes listed
above, and section 7 defines the concepts of associations and
aggregations.
Snir, Ramberg, Strassner, Cohen expires May 2001 72
Ten associations and aggregations are defined in the [PCIM] as follows:
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
QPIM reuses the PCIM associations and aggregations listed above and
defines the following new associations and aggregations in the
following hierarchy:
(the diagram is in the next page)
Snir, Ramberg, Strassner, Cohen expires May 2001 73
[top]
|
+---PolicyComponent (abstract)
| |
| +--- PolicyGroupInPolicyRule
| |
| +--- PolicyRuleInPolicyRule
| |
| +--- PolicyConditionInPolicyRule ([PCIM])
| | |
| | +--- PolicyConditionInCompoundCondition
| |
| +--- PolicyVariableInPolicySimpleCondition
| |
| +--- PolicyValueInPolicySimpleCondition
|
|
+---Dependency (abstract)
| |
| +--- PolicyMeterInAction
| |
| +--- PolicyValueConstraintsInVariable
| |
| +--- PolicyTrfcProfileInMeter
| |
| +--- PolicyQueueInPHBAction
| |
| +--- PolicyConformNextAction
| |
| +--- PolicyExcessNextAction
| |
| +--- PolicyViolateNextAction
| |
| +--- PolicyInSystem
| |
| | +--- PolicyElementInPolicyRepository
Figure 6. Associations and Aggregation for the QPIM
Snir, Ramberg, Strassner, Cohen expires May 2001 74
8. Class Definitions
8.1. The Aggregation "PolicyGroupInPolicyRule"
A policy rule may aggregate one or more policy groups, via the
PolicyGroupInPolicyRule aggregation. Grouping of policy groups and
their subclasses into a policy rule is for administrative convenience,
scalability and manageability, as it enables more complex policies to
be constructed from multiple simpler policies. For example, a
PolicyRule may aggregate PolicyGroups and gpsPolicyGroups via this
aggregation.
Policy rules do not have to contain policy groups. In addition, a
policy group may also be used by itself, without belonging to a policy
rule and policy rules may be individually aggregated by other policy
rules by the PolicyRuleInPilicyRule aggregation (section 8.Z.). Note
that it is assumed that this aggregation is used to form directed
acyclic graphs and NOT ring structures.
The class definition for this aggregation is as follows:
NAME PolicyGroupInPolicyRule
DERIVED FROM PolicyComponent (defined in [PCIM])
ABSTRACT False
PROPERTIES GroupComponent[ref PolicyRule[0..n]]
PartComponent[ref PolicyGroup[0..n]]
8.1.1. The Reference "GroupComponent"
This property is inherited from PolicyComponent, and overridden
To become an object reference to a PolicyRule that contains one or
More PolicyGroups. Note that for any single instance of the
aggregation class PolicyGroupInPolicyRule, this property (like all
Reference properties) is single-valued. The [0..n] cardinality
indicates that there may be 0, 1 or more PolicyRules that contain any
given PolicyGroup.
8.1.2. The Reference "PartComponent"
This property is inherited from PolicyComponent, and overridden
to become an object reference to a PolicyGroup contained by one or
more PolicyRules. Note that for any single instance of the
aggregation class PolicyGroupInPolicyRule, this property (like all
Reference properties) is single-valued. The [0..n] cardinality
indicates that a given PolicyRule may contain 0, 1, or more than one
PolicyGroup.
Snir, Ramberg, Strassner, Cohen expires May 2001 75
8.2. The Aggregation "PolicyRuleInPolicyRule"
A policy rule may aggregate one or more policy rules, via the
PolicyRuleInPolicyRule aggregation. Grouping of policy rules into a
policy rule, as sub-rules is explained in section XXX. The ability to
nest policy rules and form sub-rules is important for manageability and
scalability, as it enables complex policy rules to be constructed from
multiple simpler policy rules.
A PolicyRule does not have to contain sub-rules. Note that it is
assumed that this aggregation is used to form directed acyclic graphs
and NOT ring structures.
The class definition for this aggregation is as follows:
NAME PolicyRuleInPolicyRule
DERIVED FROM PolicyComponent (defined in [PCIM])
ABSTRACT False
PROPERTIES GroupComponent[ref PolicyRule[0..n]]
PartComponent[ref PolicyRule[0..n]]
8.2.1. The Reference "GroupComponent"
This property is inherited from PolicyComponent, and overridden to
become an object reference to a PolicyRule that contains one or more
PolicyRules. Each contained PolicyRule can be conceptualized as a sub-
rule of the containing PolicyRule. This nesting can be done to any
desired level. However, the deeper the nesting, the more complex the
results of the decisions taken by the nested rules. Note that a group
of rules can be aggregated by a policy group(gpsPolicyGroups) and
aggregated as a unit by a policy rule (section 8.Z).
Note that for any single instance of the aggregation class
PolicyRuleInPolicyRule, this property is single-valued. The [0..n]
cardinality indicates that there may be 0, 1 or more PolicyRules that
contain any given PolicyRule.
8.2.2. The Reference "PartComponent"
This property is inherited from PolicyComponent, and overridden to
become an object reference to a PolicyRule contained by a PolicyRule.
Note that for any single instance of the aggregation class
PolicyRuleInPolicyRule, this property is single-valued. The [0..n]
cardinality indicates that a given PolicyRule may contain 0, 1, or more
PolicyRules.
Snir, Ramberg, Strassner, Cohen expires May 2001 76
8.3. The Aggregation "PolicyConditionInCompoundCondition"
A policy compound condition may aggregate one or more policy
conditions, via the PolicyConditionInCompoundCondition aggregation.
Grouping of policy conditions and their derivatives into a policy
compound condition is for reusability of partial or full Boolean
condition statements.
A qosPolicyCompoundCondition may aggregate PolicyConditions and
their derivatives, such as qosPolicySimpleConditions and
qosPolicyCompoundConditions. The properties GroupNumber and
ConditionNegated are inherited from PolicyConditionInPolicyRule and are
specified per instance of this aggregation class. There is no change in
their semantics, so they are not redefined here. However, the
GroupComponent and PartComponent properties DO have modified semantics,
and so they are described below. The class definition for this
aggregation is as follows:
NAME PolicyConditionInCompoundCondition
DERIVED FROM PolicyConditionInPolicyRule (defined in [PCIM])
ABSTRACT False
PROPERTIES GroupComponent[ref gpsPolicyCompoundCondition[0..n]]
PartComponent[ref PolicyCondition[0..n]]
8.3.1. The Reference "GroupComponent"
This property is inherited from PolicyComponent, and overridden to
become an object reference to a gpsPolicyCompoundCondition that
contains one or more PolicyConditions. Note that for any single
instance of the aggregation class PolicyConditionInCompoundCondition,
this property is single-valued. The [0..n] cardinality indicates that
there may be 0, 1 or more gpsPolicyCompoundCondition objects that
contain any given policyCondition object, or its subclasses.
8.3.2. The Reference "PartComponent"
This property is inherited from PolicyComponent, and overridden to
become an object reference to a PolicyCondition contained by one
or more gpsPolicyCompoundConditions. Note that for any single instance
of the aggregation class PolicyConditionInPolicyRule, this property is
single-valued. The [0..n] cardinality indicates that a given
gpsPolicyCompoundCondition may contain 0, 1 or more1 PolicyConditions
(or subclasses of PolicyCondition).
8.4. The aggregation "PolicyVariableInPolicySimpleCondition"
QoS policy simple conditions are represented as the ordered
triplet {variable, operator, value}. The PolicyElement class is
the common superclass for the PolicyVariable and PolicyValue classes
and their subclasses. A gpsPolicySimpleCondition associates exactly
Snir, Ramberg, Strassner, Cohen expires May 2001 77
one gpsPolicyVariable via the PolicyVariableInPolicySimpleCondition
aggregattion. This aggregation links a subclass of PolicyElement to the
gpsPolicySimpleCondition in whose scope the PolicyElement subclass is
defined.
The class definition for this aggregation is as follows:
NAME PolicyVariableInPolicySimpleCondition
DERIVED FROM PolicyComponent (defined in [PCIM])
ABSTRACT False
PROPERTIES GroupComponent[ref gpsPolicySimpleCondition[0..n]]
Partcomponent[ref gpsPolicyVariable[1..1] ]
8.4.1. The Reference "GroupComponent"
This property is inherited from PolicyComponent, and overridden to
become an object reference to a gpsPolicySimpleCondition that contains
exactly one gpsPolicyVariable. Note that for any single instance of the
aggregation class policyVariableInPolicySimpleCondition, this property
is single-valued. The [0..n] cardinality indicates that there may be 0,
1 or more gpsPolicySimpleCondition objects that contain any given
gpsPolicyVariable object, or its subclasses.
8.4.2. The Reference "PartComponent"
This property is inherited from Dependency, and overridden to become an
object reference to a PolicyVariable class (or one of its subclasses)
that is defined within the scope of a gpsPolicySimpleCondition. Note
that for any single instance of the association class
PolicyVariableInPolicySimpleCondition, this property (like all
reference properties) is single-valued. The [1..1] cardinality
indicates that a qpsPolicySimpleCondition must have exactly one
PolicyVariable class (or one of its subclasses) defined within its
scope in order to be a meaningful.
8.5. The Aggregation "PolicyValueInPolicySimpleCondition"
QoS policy simple conditions are represented as the ordered triplet
{variable, operator, value}. The PolicyElement class is the common
superclass for the PolicyVariable and PolicyValue classes and their
subclasses. A gpsPolicySimpleCondition associates exactly one
gpsPolicyValue via the PolicyValueInPolicySimpleCondition aggregation.
This aggregation links a subclass of PolicyElement to the
gpsPolicySimpleCondition in whose scope the PolicyElement subclass is
defined.
Snir, Ramberg, Strassner, Cohen expires May 2001 78
The class definition for this association is as follows:
NAME PolicyValueInPolicySimpleCondition
DERIVED FROM PolicyComponent (defined in [PCIM])
ABSTRACT False
PROPERTIES GroupComponent[ref gpsPolicySimpleCondition[0..n]]
PartComponent[ref gpsPolicyValue[1..1]]
8.5.1. The Reference "GroupComponent"
This property is inherited from PolicyComponent, and overridden to
become an object reference to a gpsPolicySimpleCondition that contains
exactly one gpsPolicyValue. Note that for any single instance of the
aggregation class PolicyValueInPolicySimpleCondition, this property is
single-valued. The [0..n] cardinality indicates that there may be 0, 1
or more gpsPolicySimpleCondition objects that contain any given
gpsPolicyValue object, or its subclasses.
8.5.2. The Reference "PartComponent"
This property is inherited from Dependency, and overridden to become an
object reference to a PolicyValue class (or one of its subclasses) that
is defined within the scope of a gpsPolicySimpleCondition. Note that
for any single instance of the association class
PolicyValueInPolicySimpleCondition, this property (like all reference
properties) is single-valued. The [1..1] cardinality indicates that a
qpsPolicySimpleCondition must have exactly one PolicyValue class (or
one of its subclasses) defined within its scope in order to be a
meaningful.
8.6. The Association "PolicyElementInPolicyRepository"
Policy objects (e.g., policy variables, values and other reusable
policy objects) can be made reusable. Reusable policy elements are
always related to a single PolicyRepository via the
PolicyElementInPolicyRepository association.
Policy conditions can use this association to assign reusable policy
variables and/or values. Note that either policy variables and/or
values do not have to be reused. In order to construct policy
conditions of this form, use the PolicyVariableInPolicySimpleCondition
and PolicyValueInPolicySimpleCondition weak associations as
appropriate.
The class definition for this association is as follows:
NAME PolicyElementInPolicyRepository 5. Pre-Defined QoS-Related Variables
DERIVED FROM PolicyInSystem
ABSTRACT FALSE
PROPERTIES Antecedent[ref PolicyRepository[0..1]]
Dependent[ref Policy[0..n]]
Snir, Ramberg, Strassner, Cohen expires May 2001 79 Pre-defined variables are necessary for ensuring interoperability among
policy servers and policy management tools from different vendors.
The purpose of this section is to define frequently used variables in QoS
policy domains.
8.6.1. The Reference "Antecedent" Notice that this section only adds to the variable classes as defined in
[PCIMe] and reuses the mechanism defined there.
This property is inherited from PolicyInSystem, and overridden to The QoS policy information model specifies a set of pre-defined variable
become an object reference to a PolicyRepository containing one or more classes to support a set of fundamental QoS terms that are commonly used
Policy objects. A reusable Policy object is always related to exactly to form conditions and actions and are missing from the [PCIMe]. Examples
one PolicyRepository via the PolicyElementInPolicyRepository of these include RSVP related variables. All variable classes defined in
association. The [0..1] cardinality for this property signifies this document extend the PolicyImplictVariable class, defined in [PCIMe].