draft-ietf-policy-qos-info-model-01.txt   draft-ietf-policy-qos-info-model-02.txt 
Policy Framework Y. Snir Policy Framework Y. Snir
Internet Draft Y. Ramberg Internet Draft Y. Ramberg
Expires April 2000 J. Strassner Expires May 2001 J. Strassner
draft-ietf-policy-qos-info-model-01.txt R. Cohen draft-ietf-policy-qos-info-model-02.txt R. Cohen
Cisco Systems November 2000 Cisco Systems
Policy Framework QoS Information Model Policy Framework QoS Information Model
Status of this Memo Status of this Memo
This document is an Internet Draft and is in full conformance with This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet Drafts are working documents of the Internet Engineering Internet Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at line 38 skipping to change at line 38
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract Abstract
This document presents an object-oriented information model for This document presents an object-oriented information model for
representing network QoS policies. This document refines the core representing network QoS policies. This document is based on the IETF
policy information model presented in [PCIM]. Specifically, this draft Policy Core Information Model as specified by [PCIM]. This draft
refines the concept of generic policy rules, conditions and actions to refines the concept of generic policy rules, conditions and actions
cover extensions necessary for representing QoS policies. It also defined in [PCIM] in order to define extensions necessary for
provides refinement of additional concepts that are important for representing IntServ and DiffServ QoS policies. It also provides
building rule-specific as well as reusable QoS policy rules. This refinement of additional concepts that are important for building rule-
information model covers Differentiated Services QoS enforcement, and specific as well as reusable QoS policy rules.
Integrated Service QoS enforcement via policy control on RSVP
This information model covers Differentiated Services QoS enforcement,
and Integrated Service QoS enforcement via policy control on RSVP
admission. It is important to note that this document defines an admission. It is important to note that this document defines an
information model, which by definition is independent of any particular information model, which by definition is independent of any particular
repository and access protocol. A companion document [QoSSCHEMA] data storage mechanism and access protocol. Companion documents (e.g.,
defines the mapping of these classes to a directory that uses LDAPv3 as [QoSSCHEMA]) define the mapping of these classes to specific data
its access protocol. A second companion document [QOSDEV] supplies low- models (schemata).
level definitions of QoS mechanisms that are controlled by this
document.
Snir, Ramberg, Strassner, Cohen expires October 2000 1 Snir, Ramberg, Strassner, Cohen expires May 2001 1
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.
Table of Contents Table of Contents
1. Introduction 5 1. Introduction 6
1.1 Goals 5 1.1 Goals 7
1.2 Approach and Related Documents 5 1.2 Approach and Related Documents 7
2. Information Model Hierarchy 6 2. Information Model Hierarchy 8
2.1 Interaction Between the PCIM and This Document 7 2.1 Interaction Between the PCIM and This Document 8
2.1.1 Extension of Concepts in the PCIM 7 2.1.1. Extension of Concepts in the PCIM 8
2.1.2 Addition of New Concepts Not in the PCIM 7 2.1.1.1 Hierarchical Policy Repositories 9
2.2 High-Level Class Hierarchy 8 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. Containment Hierarchy 11 3. QPIM Hierarchies 13
3.1. Containment Model 11 3.1. Class and Relationship Hierarchies Defined in the QPIM 14
3.2. QoS Domain Containment Hierarchy 12 3.2. Implementation Guidelines 15
3.2.1. Domain Grouping and Nesting 13 3.2.1 Modeling Containment 16
3.2.2. Resource Sharing 15 3.2.2. Implementing Relationships 17
3.2.3. Placement 15 3.2.2.1. Relationship modeling 17
3.2.4. Named Policy Containers 16 3.2.2.2. Representing Containment in a Consistent Manner 18
3.2.5. Policy Rules 17 3.2.3. Mapping Differences and Examples 18
3.2.6. Conditions and Actions 18 3.3. QoS Domain Data Tree 19
3.2.7. Data Tree Example 19 3.4. Types of Grouping Classes 22
3.3. Reusable-Object Repositories 19 3.5. QoS Policy Domain Grouping and Nesting 23
3.4. Relationships Between QoS Domains and Repositories 20 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
4. Constructing a QoS Policy Rule 21 Snir, Ramberg, Strassner, Cohen expires May 2001 2
4.1 Policy Rule Structure 21
4.2 QoS Policy Conditions 22
4.2.1 Reusable vs. Ad-Hoc Conditions 23
4.2.2. Using Simple Conditions 24
4.2.3. Composing Complex Conditions 24
4.3 Simple Condition Operator 25
4.4. QoS Policy Variables 25
4.4.1 Variable Binding 26
4.4.2. Pre-Defined Variables 26
4.5 QoS Policy Values 30
4.6. PolicyTimePeriodCondition 30
4.7. Actions 30
4.7.1 Provisioning Actions 31
4.7.1.1 Meters 32
4.7.1.2 Markers 32
4.7.1.3 Shapers 32
4.7.1.4 Droppers 33
4.7.1.5 Examples 33
4.7.2 Signaling Actions 34
4.8 Traffic Profiles 37
4.8.1 Provisioning Traffic Profiles 37
4.8.1 RSVP Traffic Profiles 38
5. Decision strategy 39 4. Constructing a QoS Policy Rule 36
5.1. First match 39 4.1 Policy Rule Structure 36
5.2. Match All 39 4.2 QoS Policy Conditions 37
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
Snir, Ramberg, Strassner, Cohen expires October 2000 2 4.8 Meters and Traffic Profiles 64
4.8.1 Provisioning Traffic Profiles 65
4.8.2 RSVP Traffic Profiles 66
5.3. Decision Strategy example 40 5. Decision strategy 67
5.3.1 Default Operation using First Match Everywhere 40 5.1 Organizing the Application of Decision Strategies 67
5.3.2 Operation Using Other Decision Strategies 41 5.2 Decision Strategies 68
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 42 6. Per Hop Behavior 70
6.1. PHBs 42
6.2. PHB Sets 42
7. QoS Policy Class Inheritance 43 7. QoS Policy Class Inheritance 71
8. Class Definitions 45 8. Class Definitions 75
8.1. Class qosPolicyDomain 45 8.1 The Aggregation "PolicyGroupInPolicyRule" 75
8.1.1. The Property qpDomainName 45 8.1.1. The Reference "GroupComponent" 75
8.1.2. The Property qpPHBSet 45
8.1.3. The Property qpPolicyRuleMatchMethod 45
8.2. Class qosNamedPolicyContainer 46
8.2.1. The Property qpPriority 46
8.2.2. The Property qpNamedPolicyRuleMatchMethod 46
8.3. Class qosPolicyPRAction 47
8.3.1. The Property qpDirection 47
8.3.2. The Property qpSetDSCPvalue 47
8.3.3. The Property qpMeter 47
8.3.4. The Property qpMeterScope 48
8.3.5. The Property qpTrfcProf 48
8.3.6. The Property qpOutOfProfileAction 48
8.3.7. The Property qpOutofProfileRemarkValue 48
8.4. Class qosPolicyRSVPAction 48
8.4.1. The Property qpRSVPDirection 49
8.4.2. The Property qpRSVPMessageType 49
8.4.3. The Property qpRSVPStyle 49
8.4.4. The Property qpRSVPServiceType 49
8.4.5. The Property qpRSVPInstallAction 50
8.4.6. The Property qpRSVPCtrlAction 50
8.4.7. The Property qpRSVPMeter 50
8.4.8. The Property qpRSVPMeterScope 50
8.4.9. The Property qpRSVPTrfcProf 51
8.5. Class qosPolicyPRTrfcProf 51
8.5.1. The Property qpPRRate 51
8.5.2. The Property qpPRNormalBurst 51
8.5.3. The Property qpPRExcessBurst 51
8.6. Class qosPolicyRSVPTrfcProf 52
8.6.1. The Property qpRSVPTokenRate 52
8.6.2. The Property qpRSVPPeakRate 52
8.6.3. The Property qpRSVPBucketSize 52
8.6.4. The Property qpRSVPResvRate 53
8.6.5. The Property qpRSVPResvSlack 53
8.6.6. The Property qpRSVPSessionNum 53
8.6.7. The Property qpMinPolicedUnit 53
8.6.8. The Property qpMaxPktSize 53
8.7. Class qosPolicyRSVPSignalCtrlAction 54
8.7.1. The Property qpForwardingMode 54
8.7.2. The Property qpSendError 54
Snir, Ramberg, Strassner, Cohen expires October 2000 3 Snir, Ramberg, Strassner, Cohen expires May 2001 3
8.7.3. The Property qpReplaceDSCP 55 8.1.2. The Reference "PartComponent" 75
8.7.4. The Property qpReplacePreemptionPriority 55
8.7.5. The Property qpReplaceDefendingPriority 55
8.8. Class qosPolicyRSVPInstallAction 55
8.8.1. The Property qpSetDSCPValue 56
8.8.2. The Property qpSetDefendingPriority 56
8.8.3. The Property qpSetPreemptionPriority 56
8.9. Class qosPolicySimpleCondition 56
8.9.1. The Property qpOperator 57
8.9.2. The Property qpVariableAtom 57
8.9.3. The Property qpValueAtom 57
8.10. Class qosPolicyVariable 57
8.10.1. The Property qpVariableName 58
8.10.2 The Property qpValueTypes 58
8.10.3. The Property qpVariableDescription 58
8.10.4. The Property qpValueConstraints 59
8.11. Class qosPolicyValue 59
8.12. Class qosPolicyIPv4AddrValue 59
8.12.1. The Property qpIPv4AddrList 59
8.13. Class qosPolicyIPv6AddrValue 60
8.13.1. The Property qpIPv6AddrList 60
8.14. Class qosPolicyMACAddrValue 61
8.14.1. The Property qpMACAddrList 61
8.15. Class qosPolicyStringValue 62
8.15.1. The Property qpStringList 62
8.16 Class qosPolicyBitStringValue 62
8.16.1. The Property qpBitStringList 62
8.17. Class qosPolicyDNValue 63
8.17.1. The Property qpDNList 63
8.18. Class qosPolicyAttributeValue 63
8.18.1. The Property qpAttributeName 64
8.18.2. The Property qpAttributeValueList 64
8.19. Class qosPolicyIntegerValue 64
8.19.1. The Property qpIntegerList 65
8.20. Class qosPolicyPHBSet 65
8.21. Class qosPolicyPHB 65
8.21.1. The Property qpDSCP 66
8.22. Class qosPolicyMeter 66
9. Extending the QoS Policy Schema 67 8.2 The Aggregation "PolicyRuleInPolicyRule" 76
9.1. Extending qosPolicyValue 67 8.2.1. The Reference "GroupComponent" 76
9.2. Extending qosPolicySimpleCondition 67 8.2.2. The Reference "PartComponent" 76
9.3. Extending qosPolicyAction 67 8.3 The Aggregation "PolicyConditionInCompoundCondition " 77
8.3.1. The Reference "GroupComponent" 77
8.3.2. The Reference "PartComponent" 77
8.4 The Aggregation " PolicyVariableInPolicySimpleCondition " 77
8.4.1. The Reference "GroupComponent" 78
8.4.2. The Reference "PartComponent" 78
8.5 The Aggregation " PolicyValueInPolicySimpleCondition " 78
8.5.1. The Reference "GroupComponent" 79
8.5.2. The Reference "PartComponent" 79
8.6. The Association "PolicyElementInPolicyRepository" 79
8.6.1. The Reference "Antecedent" 80
8.6.2. The Reference "Dependent" 80
8.7. The Association "PolicyValueConstraintsInVariable" 80
8.7.1. The Reference "Antecedent" 81
8.7.2. The Reference "Dependent" 81
8.8. The Association "PolicyMeterInAction" 81
8.8.1. The Reference "Antecedent" 81
8.8.2. The Reference "Dependent" 81
8.9. The Association "PolicyTrfcProfileInMeter" 82
8.9.1. The Reference "Antecedent" 82
8.9.2. The Reference "Dependent" 82
8.10. The Association "PolicyQueueInPHBAction" 82
8.10.1. The Reference "Antecedent" 82
8.10.2. The Reference "Dependent" 83
8.11. The Association "PolicyConformNextAction" 83
8.11.1. The Reference "Antecedent" 83
8.11.2. The Reference "Dependent" 83
8.12. The Association "PolicyExcessNextAction" 84
8.12.1. The Reference "Antecedent" 84
8.12.2. The Reference "Dependent" 84
8.13. The Association "PolicyViolateNextAction" 84
8.13.1. The Reference "Antecedent" 85
8.13.2. The Reference "Dependent" 85
8.14. Class qosPolicyDomain 85
8.14.1. The Property qpDomainName 85
8.14.2. The Property qpPolicyRuleMatchMethod 86
8.15. Class gpsPolicyGroup 86
8.15.1. The Property gpPriority 86
8.15.2. The Property gpNamedPolicyRuleMatchMethod 87
8.15.3. The Property gpPolicyRoles 87
8.16. Class qosPolicyPRAction 87
8.16.1. The Property qpDirection 87
8.16.2. The Property qpMarkvalue 88
8.16.3. The Property qpMarkValueType 88
8.16.4. The Property qpExcessAction 88
8.16.5. The Property qpExcessMarkValue 88
8.16.6. The Property qpViolateAction 89
8.16.7. The Property qpViolateMarkValue 89
10. Security Considerations 68 Snir, Ramberg, Strassner, Cohen expires May 2001 4
11. Acknowledgments 68 8.17. Class qosPolicyPHBAction 89
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
12. References 68 Snir, Ramberg, Strassner, Cohen expires May 2001 5
13. Author's Addresses 69 8.30. Class gpsPolicyMACAddrValue 103
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
14. Full Copyright Statement 70 9. Extending the QoS Policy Schema 111
9.1. Extending gpsPolicyValue 111
9.2. Extending gpsPolicySimpleCondition 111
9.3. Extending qosPolicyAction 111
Snir, Ramberg, Strassner, Cohen expires October 2000 4 10. Security Considerations 112
11. Editorial Changes 112
12. Acknowledgments 113
13. References 113
14. Author's Addresses 115
15. Full Copyright Statement 115
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. As such, it is independent of any
specific repository type and access protocol. This document refines the specific data storage mechanism and access protocol. This document is
core policy information model presented in [PCIM]. Specifically, this based on the IETF Policy Core Information Model as specified by [PCIM].
draft refines the concept of generic policy rules, conditions and Specifically, this draft refines the concept of generic policy rules,
actions to cover extensions necessary for representing QoS policies. conditions and actions to cover extensions necessary for representing
IntServ and DiffServ QoS policies.
Snir, Ramberg, Strassner, Cohen expires May 2001 6
This information model covers Differentiated Service QoS enforcement, This information model covers Differentiated Service QoS enforcement,
and Integrated Service QoS enforcement via policy control on RSVP and Integrated Service QoS enforcement via policy control on RSVP
admission. A companion document [QoSSCHEMA] defines the mapping admission. Companion documents (e.g., [QoSSCHEMA]) define the mapping
of these classes to a directory that uses LDAPv3 as its access of these classes to specific data models (schemata). For example,
protocol. A second companion document [QOSDEV] supplies low-level [QoSSCHEMA] defines how to map the data in this information model to a
definitions of QoS mechanisms that are controlled by this document. form that can be stored in a directory that uses LDAPv3 as its access
protocol.
1.1 Goals 1.1 Goals
This document presents high level QoS policies that can be used to This document defines a set of classes that can be used to build high
enforce consistent behavior across a network, regardless of the actual level policies that can be used to configure and enforce consistent QoS
vendor-specific implementation details. The purpose of introducing a behavior across a network. Specifically, the policies defined in this
standard information model is to allow interoperability between Policy document can be used to control and manage different vendor-specific
Servers, Policy Management Applications, and Network devices. 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 This document solves two problems. First, different devices have
different capabilities, and may respond differently to the same high- different capabilities, and may respond differently to the same high-
level policy rule. This document solves this by defining a set of level policy rule. This document solves this problem by defining a set
common abstractions that can be used to build high-level QoS policies. of common abstractions that can be used to build high-level QoS
This enables different devices to use the same low-level abstractions policies. These high-level QoS policies control and manage low-level
of mechanisms to implement QoS services, which are controlled by the QoS device mechanisms independent of the specific type of device that
QoS policy rules defined in this document. The companion document is being managed. This enables different devices to use the same low-
[QOSDEV] defines an information model for representing low-level QoS level abstractions of mechanisms to implement QoS services, which are
mechanisms. controlled by the QoS policy rules defined in this document.
Second, different policy servers and applications may provision parts Second, different policy servers and applications may provision parts
of the network differently if no common high-level policy description of the network differently if no common high-level policy description
exists. This document defines a standard information model that exists. This document defines a standard information model that
provides common definitions and semantics to be assigned to build, provides common definitions and semantics to be assigned to build,
interpret and enforce high-level policy rules. interpret and enforce high-level policy rules.
1.2 Approach and Related Documents 1.2 Approach and Related Documents
The information model presented in this document contains information The information model presented in this document contains information
that can be shared by other network policy managers (e.g., Security that can be shared by other network policy managers (e.g., Security
managers, IP address managers, and others). Examples include sharing of managers, IP address managers, and others). Examples include sharing of
the same definition of well-known application port numbers, IP the same definition of well-known application port numbers, IP
addresses of servers and other network attributes. It allows checking addresses of servers and other network attributes. It allows checking
of consistent behaviors of the interaction between the different of consistent behaviors of the interaction between the different
managers by comparing, for example, the set of QoS and security actions managers by comparing, for example, the set of QoS and security actions
enforced on the same set of flows. enforced on the same set of flows.
Snir, Ramberg, Strassner, Cohen expires October 2000 5 The remainder of this document presents, describes and defines the
QoS Policy Information Model (QPIM). QPIM is a set of entities and
Representation of the inherent QoS mechanisms of devices is described relationships (both modeled by classes) that define managed objects and
in a companion draft [QOSDEV]. It provides a standard information model
for representing low-level QoS mechanisms that exist in devices in a
vendor-independent way. This document, augmented with the information
provided in [QOSDEV], together provide a set of enforceable policies
that control the QoS mechanisms on network devices.
The concept of PHBs is central to Differentiated Services. An Snir, Ramberg, Strassner, Cohen expires May 2001 7
additional information model for representation of PHBs is defined in
[PHBSET], and a corresponding LDAP representation is provided in
[PHBLDAP]. This document is also intended to work with [PHBSET].
The remainder of this document presents, describes and defines the interactions between managed objects that can be used to define,
concepts of the QoS Policy Information Model (QPIM). Relationships to manage, and control IntServ and DiffServ QoS mechanisms using policies.
the Core schema and issues related to correct usage of the schema are It uses basic concepts defined in [PCIM] but extends those to control
defined in [QOSSCHEMA]. IntServ and DiffServ QoS mechanisms. Since QPIM is an information model
(and is therefore independent of any specific data storage mechanism
and access protocol limitations), this document is limited to
discussing the different managed objects that are used to define and
provision IntServ and DiffServ QoS policies. Relationships to the Core
schema [PCLS] and issues related to mapping this information to a form
suitable for implementation in a directory, along with correct usage of
the mapped schema, are defined in [QOSSCHEMA].
2. Information Model Hierarchy 2. Information Model Hierarchy
This section discusses the relationships between the Policy Core This section discusses the relationships between the Policy Core
Information Model ([PCIM]), the QoS Policy Information Model (QPIM, Information Model [PCIM], the QoS Policy Information Model (QPIM,
which is this document) and future extensions of the QPIM. which is this document) and future extensions of the QPIM.
2.1 Relationship Between the PCIM and This Document
This document both extends concepts that are part of the [PCIM] and
adds new functions that are not part of the [PCIM].
The [PCIM] models high-level policy concepts and introduces structural The [PCIM] models high-level policy concepts and introduces structural
conventions and nomenclature common to all types of policies. The conventions and nomenclature common to all types of policies. The
fundamental purpose of the [PCIM] is to provide a generic fundamental purpose of the [PCIM] is to provide a generic
representation of the structure of a policy rule, along with a set of representation of the structure of a policy rule, along with a set of
classes and relationships that can serve as a common representation of classes and relationships that can serve as a common representation of
policy groups, rules, conditions, and actions. This enables derived policy groups, rules, conditions, and actions. This enables derived
information models and schemata to all use a common set of terminology, information models and schemata to use a common set of terminology,
classes, and approaches, thus facilitating interoperability. classes, and approaches, thus facilitating interoperability.
The QPIM refines the concepts of the [PCIM] and introduces a framework The QPIM refines and extends the concepts of the [PCIM] by introducing
of classes and relationships dedicated to model QoS Policies. This set a framework of classes and relationships dedicated to model IntServ and
of classes and relationships can be used to configure and manage DiffServ QoS Policies. This set of classes and relationships can be
devices that are IntServ- and DiffServ-compliant. The QPIM provides used to configure and manage devices that are compliant with either the
building blocks to control most of the policy aspects required by integrated services [Intserv] and/or with the differentiated service
IntServ and DiffServ, but it is clear that not all functions are approach [Diffserv].
provided.
It is also clear that other information models and their derived
schemata can use some of the concepts in this document. For example,
the concept of representing IP Addresses, as well as variables and
constants, are not specific to QoS. However, this is the first
information model that is derived from the [PCIM], and it is not clear
that other working groups will be satisfied with these representations.
These concepts will be socialized to other working groups and, if they
agree with the representation in this document (or if a suitable
compromise can be developed), then these concepts will be moved into a
separate document.
Snir, Ramberg, Strassner, Cohen expires October 2000 6
The PCIM and QPIM are both inherently extensible. Furthermore, they are 2.1.1 Extension of Concepts in the PCIM
designed to fit together to produce one virtual information model. As
such, both are independent of any particular repository and access
protocol. However, mappings can be defined to translate the data from
this single "virtual information model" to a form that can be
implemented in a specific type of repository that uses one or more
specific access protocols. Examples of mapping the concepts of the
[PCIM] and this document to a form that can be implemented in a
directory that uses LDAP as its access protocol are provided in
[PFSCHEMA] and [QOSSCHEMA], respectively.
This document specifies an extensible information model. While this The QPIM extends three fundamental concepts defined in [PCIM] in order
document defines facilities for building policy rules, conditions and to be able to define policies that can control, manage and provision
actions to build QoS policies, it is recognized that not all required the QoS mechanisms of devices. These are hierarchical policy
functionality can or should be defined in this document. Therefore, any repositories, extensions to reusable objects, and extensions to the
implementation-specific schema that is derived from this information structure of a policy rule.
model should further concretize the QoS concepts of the QoS Policy
schema to suit its own application-specific needs.
2.1 Interaction Between the PCIM and This Document Snir, Ramberg, Strassner, Cohen expires May 2001 8
This document both extends concepts that are part of the [PCIM] as well 2.1.1.1 Hierarchical Policy Repositories
as adds new functions that are not part of the [PCIM].
2.1.1 Extension of Concepts in the PCIM The concept of a "nested" policy repository (i.e., a repository that
is embedded within another repository) that contains policy
information, was originally defined in an earlier version of the QPIM.
It has subsequently been moved into the [PCIM], since it is a general
concept that is not limited to QoS, and can be used by other
applications. This document reuses this concept, but defines specific
refinements for using "embedded policy repositories" to accommodate the
application-specific needs of QoS provisioning. These reflect the need
to provide nested levels of administration and scoping to policies and
policy information.
The concept of a policy repository, that is embedded within another 2.1.1.2 Extensions to Reusable Objects
repository that contains policy and non-policy information, was
originally defined in an earlier version of the QPIM. It has
subsequently been moved into the [PCIM], since it is a generic concept
that is not limited to QoS, and can be used by other applications. This
document defines specific refinements of the "embedded policy
repository" to accommodate the application-specific needs of QoS
provisioning.
Similarly, the concepts of reusable- objects vs. rule-specific objects Similarly, the concepts of reusable objects vs. rule-specific objects
have been moved from an earlier version of this document to the [PCIM]. have been moved from an earlier version of this document to the [PCIM].
Equally similarly, this document defines specific extensions to In addition, this document defines specific extensions to guide the
guide the implementation of reusable- vs. rule-specific QoS objects. implementation of reusable- vs. rule-specific QoS objects.
This document also extends the concept of a policy rule, along with 2.1.1.3 Extensions to the Structure of a Policy Rule
conditions and actions that are specific to QoS. It further defines
different types of actions that target DiffServ and IntServ actions. This document also extends the concept of a policy rule. It is
important to note that this is done without having to redefine or
subclass of PolicyRule (as defined in [PCIM]), because if that was
done, then interoperability would be adversely affected. This document
also defines additional conditions and actions that are specific to
QoS. It further defines different types of actions that target DiffServ
and IntServ actions.
2.1.2 Addition of New Concepts Not in the PCIM 2.1.2 Addition of New Concepts Not in the PCIM
There are several notable new concepts that are not part of the [PCIM]. There are several notable new concepts that are not part of the [PCIM].
These include rule nesting, rule decision strategy, pre-defined These include rule nesting, rule decision strategy, compound
variables and constants, and PHBs. conditions, pre-defined variables and constants, and Per Hop Behavior
definition, as part of the QoS actions.
Snir, Ramberg, Strassner, Cohen expires October 2000 7 2.1.2.1 Rule Nesting
The [PCIM] defines the ability to group policy rules by defining the The [PCIM] defines the ability to group policy rules by defining the
policyGroup class. This class has the following semantics: it can policyGroup class. This class can be used to contain a set of
either be used to contain a set of policyRules, or a set of policyRules and/or a set of policyGroups. This grouping mechanism
policyGroups, but not both. However, this simply gathers policy rules allows for constructing a flexible and extensible information model.
together in a common container. It does not nest policy rules. However, it treats PolicyRules as atomic objects that can contain only
conditions and actions. In practice, this is not flexible enough for
some of the needs of IntServ and DiffServ.
This document adds the concept of nesting one or more policy rules Snir, Ramberg, Strassner, Cohen expires May 2001 9
within a policy rule. For example, one could think of a policy rule
that controls how a user logs onto the network as consisting of the Therefore, this document adds the concept of nesting one or more policy
high-level rule itself. This high-level rule could consist of a set of rules within a policy rule. For example, one could think of a policy
lower-level rules that are invoked at various stages of processing rule that controls how a user logs onto the network as consisting of
(e.g., how the user is authenticated, how the IP Address is assigned, two parts. A high-level rule is used to group together a set of lower-
etc.). level rules that are invoked at various stages of processing (e.g., how
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
Since there is no concept of nested rules in the [PCIM], there is no Since there is no concept of nested rules in the [PCIM], there is no
need for a decision strategy to be used to define the order of need for a decision strategy to be used to define the order of
processing of these rules. However, such a decision strategy must be processing of these rules. However, since QPIM allows for nested rules,
defined in this document because it does define nested rules. This different examples of decision strategies must be defined in this
strategy defines an ordering that can be applied to a set of policyRule document and shown that they can work in this new environment. This
and policyGroup objects within a larger context (e.g., a policy document defines two such decision strategies: match-first and match-
domain). This in turn controls the execution of different policy all. Both define an ordering that can be applied to a set of
actions. policyRules and policyGroup objects within a larger context (e.g., a
policy domain). This in turn controls the execution of different policy
actions. Note that choosing a different decision strategy is one way to
change the result of executing a set of policy rules without changing
the policy rules themselves.
2.1.2.3 Compound Conditions
[PCIM] defines conditions that consist of a single term. [PCIM] allows
such conditions to be logically combined using 'AND' and 'OR' terms.
This makes sense, because all conditions can be constructed from such
primitives. However, a richer means of representing common conditions
is called for.
This document extends the concept of a simple (i.e., one-term)
condition to define compound conditions. This is conceptually
equivalent to using a set of simple conditions. However, supporting
compound conditions enables a better matching of the information model
to the environment that it is modeling, and also simplifies the mapping
of the information model to different types of data models. In
addition, it enhances the manageability and reusability of complex
conditions. Therefore, the classes and relationships needed to build
this in as efficient a manner as possible are defined in this document.
2.1.2.4 Pre-Defined Variables and Constants
This document also defines a set of variable and constant definitions This document also defines a set of variable and constant definitions
for use with QoS policies. This concept is not present in the [PCIM] for use with QoS policies. This concept is not present in the [PCIM]
Snir, Ramberg, Strassner, Cohen expires May 2001 10
because the purpose of the [PCIM] is to provide a general structure for because the purpose of the [PCIM] is to provide a general structure for
representing policy rules, conditions and actions. Variable and representing policy rules, conditions and actions. Variable and
constant definitions represent specific concepts that have pre-defined constant definitions represent specific concepts that have pre-defined
semantics. semantics.
Finally, this document adds a general structure for accommodating PHBs. This version of this draft has these elements residing in this draft.
PHBs are a concept that is specific to DiffServ, and thus are not However, they have been generalized so that other applications besides
defined in the [PCIM]. QoS can use them.
2.1.2.5 Per-Hop Behaviors
Finally, QoS Policy definition may require the notion of a Per-Hop
Behavior (specified by the differentiated services paradigm). This
document provides interpretation for this notion by providing a way to
represent Per-Hop Behaviors using policy rules.
2.1.3 Mapping to a Directory
The PCIM and QPIM are both inherently extensible. Furthermore, they are
designed to fit together to produce one "virtual" information model. As
such, both are independent of any particular data storage mechanism and
access protocol. However, mappings can be defined to translate the data
from this single virtual information model to a form that can be
implemented in a specific type of 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
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.2 High-Level Class Hierarchy
The following diagram shows how the classes in this document relate to The following diagram shows how the classes in this document relate to
the classes defined in the PCIM. the classes defined in the PCIM.
Snir, Ramberg, Strassner, Cohen expires October 2000 8 Snir, Ramberg, Strassner, Cohen expires May 2001 11
(continued from previous page)
[unrooted] [unrooted]
| |
+--Policy (abstract, defined in PCIM) +--Policy (abstract, defined in PCIM)
| | | |
| +---PolicyGroup (PCIM) | +---PolicyGroup (PCIM)
| | | | | |
| | +---qosPolicyDomain (this document) | | +---qosPolicyDomain (this document)
| | | | | |
| | +---qosNamedPolicyContainer (this document) | | +---gpsPolicyGroup (this document)
| | | |
| +---PolicyRule (PCIM) | +---PolicyRule (PCIM)
| | | |
| +---PolicyCondition (PCIM) | +---PolicyCondition (abstract, defined in PCIM)
| | | | | |
| | +---PolicyTimePeriodCondition (PCIM) | | +---PolicyTimePeriodCondition (PCIM)
| | | | | |
| | +---VendorPolicyCondition (PCIM) | | +---VendorPolicyCondition (PCIM)
| | | | | |
| | +---qosPolicySimpleCondition (this document) | | +---gpsPolicySimpleCondition (this document)
| | |
| | +---gpsPolicyCompoundCondition (this document)
| | | |
| +---PolicyAction (PCIM) | +---PolicyAction (abstract, defined in PCIM)
| | | | | |
| | +---VendorPolicyAction (PCIM) | | +---VendorPolicyAction (PCIM)
| | | | | |
| | +---qosPolicyPRAction (this document) | | +---qosPolicyPRAction (this document)
| | | | | |
| | +---qosPolicyPHBAction (this document)
| | |
| | +---qosPolicyRSVPAction (this document) | | +---qosPolicyRSVPAction (this document)
| | | | | |
| | +---qosPolicyRSVPSignalCtrlAction (this document) | | +---qosPolicyRSVPSignalCtrlAction (this document)
| | | | | |
| | +---qosPolicyRSVPInstallAction (this document) | | +---qosPolicyRSVPInstallAction (this document)
| | |
| +---qosPolicyPRTrfcProf (this document)
| |
| +---qosPolicyRSVPTrfcProf (this document)
| |
| +---qosPolicyVariable (this document)
| | | |
| +---qosPolicyValue (this document) | +---gpsPolicyTrfcProf (this document)
| | |
| | +---qosPolicyIPv4AddrValue (this document)
| | | | | |
| | +---qosPolicyIPv6AddrValue (this document) | | +---qosPolicyPRTrfcProf (this document)
| | | | | |
| | +---qosPolicyMACAddrValue (this document) | | +---qosPolicyRSVPTrfcProf (this document)
| |
| +---gpsPolicyVariable (abstract, this document)
| |
| +---gpsPolicyValue (abstract, this document)
| | | | | |
| | +---qosPolicyStringValue (this document) | | +---gpsPolicyIPv4AddrValue (this document)
| | | | | |
| | +---gpsPolicyIPv6AddrValue (this document)
(continued on next page) (continued on next page)
Snir, Ramberg, Strassner, Cohen expires October 2000 9 Snir, Ramberg, Strassner, Cohen expires May 2001 12
(continued from previous page) (continued from previous page)
[unrooted] [unrooted]
| |
+--Policy (abstract, defined in PCIM, repeated for convenience) +--Policy (abstract, defined in PCIM, repeated for convenience)
| | | |
| +---qosPolicyValue (this document, repeated for convenience) | +---gpsPolicyValue (this document, repeated for convenience)
| | | | | |
| | +---qosPolicyBitStringValue (this document) | | +---gpsPolicyMACAddrValue (this document)
| | | | | |
| | +---qosPolicyDNValue (this document) | | +---gpsPolicyStringValue (this document)
| | | | | |
| | +---qosPolicyAttributeValue (this document) | | +---gpsPolicyBitStringValue (this document)
| | | | | |
| | +---qosPolicyIntegerValue (this document) | | +---gpsPolicyDNValue (this document)
| | | | |
| +---qosPolicyMeter | | +---gpsPolicyAttributeValue (this document)
| | |
| | +---gpsPolicyIntegerValue (this document)
| | | |
| +---qosPolicyPHBSet (this document) | +---gpsPolicyMeter
| | | |
| +---qosPolicyPHB (this document) | +---qosPolicyQueue
| | | |
+--CIM_ManagedSystemElement (abstract, defined in PCIM) +--CIM_ManagedSystemElement (abstract, defined in PCIM)
| |
+--CIM_LogicalElement (abstract, defined in PCIM) +--CIM_LogicalElement (abstract, defined in PCIM)
| |
+--CIM_System (abstract, defined in PCIM) +--CIM_System (abstract, defined in PCIM)
| |
+---CIM_AdminDomain (abstract, defined in PCIM) +---CIM_AdminDomain (abstract, defined in PCIM)
| |
+---PolicyRepository (PCIM) +---PolicyRepository (PCIM)
Snir, Ramberg, Strassner, Cohen expires October 2000 10 3. QPIM Hierarchies
3. Containment Hierarchy 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 this section, we describe the organization and structure of the QPIM In the rest of this section, we describe the organization and structure
hierarchy. 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.
The QPIM consists of two hierarchies: A policy Snir, Ramberg, Strassner, Cohen expires May 2001 13
definition hierarchy and a reusable objects repository hierarchy. A
particular data tree may contain any number of instances of each
hierarchy. Section 3.1 explains the containment and reference model
used in the construction of QoS Policy data trees. Section 3.2
describes the particular containment hierarchy of the policy definition
entity, which is modeled by the qosPolicyDomain class. Section 3.3
describes the structure of the reusable objects repository. Further
down (section 3.4) we explain the relationships between those entities.
3.1. Containment Model 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.
The QPIM uses and extends the containment model of [PCIM]. The 3.1 Class and Relationship Hierarchies Defined in the QPIM
following paragraphs summarize this containment model. For more detail,
please refer to [PCIM].
Conceptually, the QPIM takes the form of a tree hierarchy. To describe The QPIM consists of two hierarchies: an inheritance hierarchy that is
the hierarchy using actual instances of model data, we use the term used to define a set of classes that represent entities in the managed
'data tree'. A data tree is simply an arrangement of objects in a tree policy environment, and a relationship hierarchy that is used to define
structure. The data tree starts from a root object node. The data tree a hierarchy of relationships that describe how different objects
itself consists of leaf and non-leaf (i.e., container) nodes. The root interact with each other. These hierarchies work together to describe
node has one or more branch nodes that are either leaf or non-leaf entities in the managed environment and how they relate to and interact
nodes. The tree construction involves placing objects as leaves of with each other.
other objects while maintaining a strict tree structure.
The basic mechanism used for expressing containment is placement of the Two relationship constructs are used in the formal presentation of
objects in the data tree. To express the relationship of "container - QPIM. The first is an association, which models different types of
contained" between a container object and the objects it contains, the dependency relationships between two (or theoretically more) objects.
contained objects are placed below the container object. The second is an aggregation, which is a strong form of association
that typically represents a "whole-part" or a "containment"
relationship.
Certain elements of the QPIM need a mechanism for an entity to Both associations and aggregations are modeled as classes that contain
reference objects in a different tree in the containment hierarchy than references to the objects that are participating in the relationship.
the tree in which the referencing entity exists. For example, the class In addition, both associations and aggregations can be defined between
policyRule (defined in [PCIM]) is a container of conditions and actions classes without affecting any of the related classes. That is, the
(policyCondition and policyAction classes, defined in [PCIM], or their addition of either an association or an aggregation does not affect the
subclasses, such as those defined in this document). However, the function or structure of the related classes.
information model should allow the formation of (complex) conditions
(and actions), where some of the condition's (and/or actionĂs)
components are referenced remotely. An example of such a remote
reference is a reusable condition or a reusable action. Such reusable
objects must be referenced remotely because they always reside in a
specialized portion of the tree (in this case, in the policyRepository
container) that is different from the one where the referencing rule
resides.
Snir, Ramberg, Strassner, Cohen expires October 2000 11 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.
To support a unified mechanism for containment of "local" and "remote" Snir, Ramberg, Strassner, Cohen expires May 2001 14
objects, [PCIM] introduces the notion of association and aggregation
classes. These classes denote some type of dependency relationship that
exists between the classes that they are connecting. One type of
dependency that can be represented is, of course, containment.
[PCIM] recommends that associations and aggregations are also Relationship classes may be used to extend the semantics of the
implemented as classes. With respect to containment, an association relationship beyond the basic containment or reference concepts. For
class represents the act of containment itself. For example, the example, a relationship class may contain added attributes that add
PolicyConditionInPolicyRule aggregation (defined in [PCIM]) defines particular semantics. For example, the PolicyConditionInPolicyRule
that zero or more policy conditions are contained in a given policy aggregation defines the relationship between a PolicyRule and a set of
rule. 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.
In general, containment may be direct or indirect. Direct containment Comprehensive presentation of relationships and their modeling is
means that when the association or aggregation is instantiated in a available in [PCIM].
repository, the child object will be directly scoped by the container
object. Indirect containment means that when the association or
aggregation is instantiated in a repository, the child object will
instead be referenced by the container object. As an example, if the
target repository is a directory, then direct containment is
implemented by instantiating the child object as a child node of a
container. Similarly, indirect containment would be implemented using
an attribute that is a DN (i.e., the DN points to another object).
The association classes can (and do) carry the added semantics needed Two important examples of using aggregation are composition and
by the information model. For example, internal order of contained scoping. An example of composition is the PolicyRule. It has its own
objects is information that can be carried on the association objects attributes, but it is only complete when it is used in conjunction with
themselves. This makes the containment model more flexible, since the a set of conditions and actions. Conceptually, a PolicyRule serves as a
same object may be used by two containers in different parts of the container that aggregates a set of PolicyCondition objects and a set of
containment tree. 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.
Containment is implemented differently in different data stores. 3.2 Implementation Guidelines
Therefore, the containment tree that is being described is not
expressed directly in the information model. Rather, the information
model specifies classes and relationships that are used to model
entities and relationships between entities that are represented in the
containment data model. A mapping of the data specified in an
information model to a form that is repository-dependent must also be
specified. This is what [PFSCHEMA] and [QOSSCHEMA] do for the [PCIM]
and this document, respectively. Please refer to [PCIM] for more
information on the details of the association and aggregation class
mechanisms.
3.2. QoS Domain Containment Hierarchy 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.
The entity that represents a single policy hierarchy is called QOS Many data storage technologies are incapable of directly representing
Domain and is modeled by the qosDomain class, which is a derivative of relationships. However, all data storage mechanisms of interest can
the PolicyGroup class in [PCIM]. 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.
Snir, Ramberg, Strassner, Cohen expires October 2000 12 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
Figure 1 shows a summary view of the QoS domain containment hierarchy. Snir, Ramberg, Strassner, Cohen expires May 2001 15
The text in parenthesis denotes object containment style: either
through placement in the data tree (i.e., using a class to form a rules, that are used to govern the application of policies to manage
container in a specific place in the data tree) or indirectly through entities. The second type of information is a set of nested containers
association or aggregation classes. 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) |qosPolicyDomain| (root of the data hierarchy)
+---------------+ +---------------+
|
| +-----------------------+
-->|qosNamedPolicyContainer| (placement)
+-----------------------+
|
| +----------+ | +----------+
-->|policyRule| (placement) |-->|policyRule| (a)
+----------+ | +----------+
| | | +------------------------+
| +------------------------+ | |-->|gpsPolicySimpleCondition| (b)
|-->|qosPolicySimpleCondition| (via association) | | +------------------------+
| +------------------------+ | | +--------------------------+
| | |-->|gpsPolicyCompoundCondition| (b)
| | +--------------------------+
| | | +------------------------+
| | |-->|gpsPolicySimpleCondition| (c)
| | | +------------------------+
| | | +--------------------------+
| | |-->|gpsPolicyCompoundCondition| (d)
| | +--------------------------+
| | +---------------+
| |-->|qosPolicyAction| (e)
| | +---------------+
| | +----------+
| |-->|policyRule| (f)
| | +----------+
| | +--------------+
| |-->|gpsPolicyGroup| (g)
| +--------------+
| +--------------+
|-->|gpsPolicyGroup| (h)
| +--------------+
| | +----------+
| |-->|PolicyRule| (i)
| | +----------+
| | +--------------+
| |-->|gpsPolicyGroup| (j)
| +--------------+
| +---------------+ | +---------------+
-->|qosPolicyAction| (via association) |-->|qosPolicyDomain| (k)
+---------------+ +---------------+
Figure 1: Qos Domain containment hierarchy Figure 1: Qos Domain Data Tree Hierarchy
3.2.1. Domain Grouping and Nesting Explanation to the relationships defined in figure 1:
QoS policy domains may be grouped together to model multi-domain a - Any number of PolicyRule instances may be contained by a given
systems. Here, a domain is a contiguous set of nodes that operate under qosPolicyDomain instance in the hierarchy by using the
a common system of administration and provide a common set of services. PolicyRuleInPolicyGroup aggregation. This has the effect of making such
Grouping may be desired to enhance various administrative tasks, or it policyRules global for that container. Finer granularity can be
may be required by a particular policy application. The grouping obtained by either nesting qosPolicyDomain instances (shown in
strategy (as well as all location-oriented strategies) is left for relationship (k)), or by embedding other types of containers (e.g.,
users/vendors to model based on their unique situations and
requirements. This document presents guidelines and recommendations for
grouping QoS domains, but specific implementations may use other
techniques without violating the integrity and consistency of the QPIM.
One way to group QoS policy domains is by creating a common root for Snir, Ramberg, Strassner, Cohen expires May 2001 20
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. In this case, all that is needed is to place the
appropriate number of qosPolicyDomain (defined in this document)
instances under the appropriate policyGroup instance.
Snir, Ramberg, Strassner, Cohen expires October 2000 13 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
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 Figure 2 is an example that depicts the ability to provide different
classes of service to different organizations within a single classes of service to different organizations within a single
enterprise. In this example, the enterprise is represented by an enterprise. In this example, the enterprise is represented by an
instance of the policyGroup class. The different organizations are each instance of the PolicyGroup class. The different organizations are each
represented by a separate QoS policy domain (which is an instance of represented by a separate QoS policy domain (which is an instance of
the qosPolicyDomain class). Each qosPolicyDomain class is used as a the qosPolicyDomain class). Each qosPolicyDomain class is used as a
container to hold all of the policies for a given portion of the container to hold all of the policies for a given portion of the
organization. In Figure 2, this level is represented by the nesting of organization. In Figure 2, this level is represented by the nesting
qosPolicyDomain classes. 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 Each qosPolicyDomain instance serves as a container that contains an
ordered list of related QoS policy rules that apply to a different part 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 or function of the domain (e.g., Eastern Sales vs. Western Sales). This
grouping is done using instances of the qosNamedPolicyContainer clas. grouping is done using instances of the gpsPolicyGroup class.
The qosNamedPolicyContainer class would in turn contain either a set of The gpsPolicyGroup class would in turn contain either a set of
policyRule instances, a set of policyGroup instances (to provide PolicyRule instances, a set of PolicyGroup instances (to provide
further grouping of policy rules that are scoped by a given further grouping of policy rules that are scoped by a given
qosNamedPolicyContainer), or both. gpsPolicyGroup), or both.
Snir, Ramberg, Strassner, Cohen expires May 2001 24
+-------------+ +-------------+
|policyGroup | <------------------- QoS policies for an enterprise |policyGroup | <------------------- QoS policies for an enterprise
+-------------+ +-------------+
| |
| +---------------+ | +---------------+
-->|qosPolicyDomain| <----------- QoS policies for the Sales group -->|qosPolicyDomain| <----------- QoS policies for the Sales group
+---------------+ +---------------+
| |
| +---------------+ | +---------------+
|-->|qosPolicyDomain| <-------- QoS policies for Western Sales |-->|qosPolicyDomain| <-------- QoS policies for Western Sales
| +---------------+ | +---------------+
| | | |
| | +-----------------------+ | | +--------------+
| |-->|qosNamedPolicyContainer| <--Qos Policies for group | |-->|gpsPolicyGroup| <--Qos Policies for group
| | +-----------------------+ A within Western Region | | +--------------+ A within Western Region
| | | |
| | +-----------------------+ | | +--------------+
| -->|qosNamedPolicyContainer| <--Qos Policies for group | -->|gpsPolicyGroup| <--Qos Policies for group
| +-----------------------+ B within Western Region | +--------------+ B within Western Region
| |
| +---------------+ | +---------------+
-->|qosPolicyDomain| <--------QoS policies for Eastern Sales -->|qosPolicyDomain| <--------QoS policies for Eastern Sales
+---------------+ +---------------+
| |
| +-----------------------+ | +--------------+
|-->|qosNamedPolicyContainer| <--Qos Policies for group |-->|gpsPolicyGroup| <--Qos Policies for group
| +-----------------------+ C within Eastern Region | +--------------+ C within Eastern Region
| |
| +-----------------------+ | +--------------+
-->|qosNamedPolicyContainer| <--Qos Policies for group -->|gpsPolicyGroup| <--Qos Policies for group
+-----------------------+ D within Eastern Region +--------------+ D within Eastern Region
Figure 2: Top-level policy data tree example
Snir, Ramberg, Strassner, Cohen expires October 2000 14 Figure 2: Top-level Policy Data Tree Example
The modeling approach used in the previous example is but one possible The modeling approach used in the previous example is but one possible
strategy among many. The information model allows for arbitrary nesting strategy among many. This information model allows for arbitrary
of groups, thus providing the means for modeling both wide and deep nesting of containers, groups and rules, thus providing the means for
hierarchies. modeling both wide and deep policy hierarchies.
3.2.2. Resource Sharing 3.6. Resource Sharing
Object instances residing in different parts of the containment tree Object instances residing in different branches of the data tree
are independent to each other. That is, there is no cross-referencing are independent of each other. That is, there is no cross-referencing
among objects located in different QoS policy domains. However, among objects located in different QoS policy domains. However,
multiple QoS policy domains may still share data by means of multiple QoS policy domains may still share data by using a special
referencing reusable objects. These are objects that are placed in a mechanism. This mechanism is called referencing reusable objects. A
special portion of the repository dedicated to this purpose. In fact, reusable object is an object that is placed in a special portion of the
there may be multiple such repositories, each used for collecting a set data store dedicated to sharing information among multiple clients that
of related reusable objects. In this document, we will call such
repositories reusable-objects repositories. 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 The sharing of global or common objects enhances the interoperability
of various policy agents, thus serving the primary goal of this of various policy applications, thus serving the primary goal of this
information model. Such commonly used building blocks as important information model. Such commonly used building blocks as PolicyGroup
conditions (policyCondition and its subclasses ) and actions and its subclasses (e.g., gpsPolicyGroup and qosPolicyDomain),
(policyAction and its subclasses) can be placed in the reusable-object subclasses of PolicyCondition (e.g., qpsPolicySimpleCondition and
repository and used by multiple policy rules from multiple domains. gpsPolicyCompoundCondition)and PolicyAction (e.g., qosPolicyPRAction
Both the [PCIM] and the QPIM do not restrict the number of reusable- 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 object repositories that can be referenced from a single domain. Even a
single instance of a policy rule may contain references to objects single instance of a policy rule may contain references to objects
residing in more than one repository. It is important to note that the 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 QPIM does not dictate a QoS domain-wide scope for reusable objects, so
as to keep this concept as general as possible. as to keep this concept as general as possible.
3.2.3. Placement 3.7. Instance Location
The purpose of the QPIM is to define a flexible structure of The purpose of the QPIM is to define a flexible structure of
information that does not pre-impose harsh restrictions on building the information that does not pre-impose harsh restrictions on building the
data tree. Therefore, the QPIM must not contain any hidden assumptions data tree. When a data tree is derived from the QPIM, it is important
about the placement of particular QoS policy domain hierarchies to ensure that this derivation is as free of restrictions as possible.
(including, for that matter, placement of reusable-object repositories
as explained in section 3.3 below). Consequently, the QPIM does not Although each data store has its own special considerations to be taken
require any pre-defined locations for the portion of the data tree that into account, one of the most important considerations in mapping for
is dedicated to policy. An instance of the global data tree (a directories concerns placement of entries. The QPIM MUST NOT contain
corporate directory, for example) may in fact contain several QoS any hidden assumptions about the placement of particular QoS policy
policy domains that exist within the global date tree in various domain hierarchies (including, for that matter, placement of reusable-
places. Zero or more reusable object-repositories may also be present object repositories as explained in section 3.13 below). Consequently,
in the global data tree. 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 In addition, the QPIM does not dictate any standard organization of
objects to be controlled via policy, either for QoS policy classes and objects to be controlled via policy, either for QoS policy classes and
relationships or for reusable-object repositories that are used by QoS relationships or for reusable-object repositories that are used by QoS
applications. applications.
Snir, Ramberg, Strassner, Cohen expires October 2000 15 Snir, Ramberg, Strassner, Cohen expires May 2001 26
The only location/organizational rule that must be followed is: The only location/organizational rule that must be followed is:
Each QoS policy domain must contain complete policy information, Each QoS policy domain must contain complete policy information that
either by containment of objects or by containment of association is necessary to describe that particular policy domain. Reusable
and/or aggregation objects, that is necessary to describe that objects SHOULD be placed in one or more reusable-object repositories
policy domain. Reusable objects SHOULD be placed in one or more and referenced by one or more objects that exist in the QoS policy
reusable-object repositories and referenced by one or more objects domain, as appropriate. Note specifically that there is no
that exist in the QoS policy domain, as appropriate. 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.2.4. Named Policy Containers 3.8. Policy Containers
A QoS policy domain is a container of (named) QoS Policy Containers, as A QoS policy domain is a container that provides scoping for QoS policy
explained above. The information model class representing named QoS containers, policy rules, and other policy information, as mentioned
policy containers is the qosNamedPolicyContainer class. This class previously. There are two information model class that are used to
extends the policyGroup class, which is defined in [PCIM]. represent QoS policy containers: the qosPolicyDomain and the
gpsPolicyGroup classes. Both classes extend the PolicyGroup class,
which is defined in [PCIM].
A (non-empty) qosNamedPolicyContainer holds an unordered list of The ability to "divide" a given QoS policy domain's policy rules among
policyRules. There are two levels of priority that the QPIM specifies a set of policy containers provides a flexible framework to realize a
that can be used to determine the order of execution of QoS policy fine-grained administrative (or functional) structure. As the example
rules. At the highest level, we can define an unordered set of policy in figure 2 illustrates, it makes sense to divide policies for the
containers, each of which has a priority attribute (called qpPriority). sales organization into two regional containers: Western and Eastern.
This property is used to order the top level of the containment This enables a change in policies for one region to not affect the
hierarchy. Within a given containment level, we can then use the policies currently in place for the other region.
Priority attribute of the policyRule class to establish an order of
which policy rule in a given container executes next. Figure 3 shows a Both the gpsPolicyGroup as well as the qosPolicyDomain policy
simple example of the ordering process. Section 4 describes policy containers can be nested (e.g., a container may contain multiple
rules in more detail. 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| |qosPolicyDomain|
+---------------+ +---------------+
| |
| +--------------+ | +--------------+
|-->|policyRule A | |-->|PolicyRule A |
| | Priority=19 | | | Priority=19 |
| +--------------+ | +--------------+
| |
| +-----------------------+ +-------------+ | +-----------------------+ +-------------+
|-->|qosNamedPolicyContainer|--->|policyRule C | |-->|gpsPolicyGroup |--->|PolicyRule C |
| | qpPriority=5 | | | Priority=7 | | | gpPriority=5 | | | Priority=7 |
| +-----------------------+ | +-------------+ | +-----------------------+ | +-------------+
| | | |
| +-------------+ | +-------------+ | +-------------+ | +-------------+
-->|policyRule B | ->|policyRule D | -->|PolicyRule B | ->|PolicyRule D |
| Priority=3 | | Priority=2 | | Priority=3 | | Priority=2 |
+-------------+ +-------------+ +-------------+ +-------------+
Figure 3. Example Ordering for a QoS Policy Decision Figure 3. Example Ordering for a QoS Policy Decision
Here, the ordering is A, then C, then D, then B. This is because the In this example, the ordering is A, then C, then D, then B. This is
qpPriority of the qosNamedPolicyContainer is higher than B, so each of because the gpPriority property of the gpsPolicyGroup is higher than
its contained rules are executed (in order) before B. 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).
Snir, Ramberg, Strassner, Cohen expires October 2000 16 3.8.2 Priority and Decision Strategy Applied to Containers
As implied by the class name, each instance of the Each policy rule as well as each policy container may have an order
qosPolicyNamedContainer class MUST be assigned a name that is unique attribute (Priority for PolicyRule and gpPriority for gpsPolicyGroup,
within its given QoS policy domain. A given policy container must respectively). The ordering is interpreted as a function of the
belong to (i.e.: contained in) a single QoS policy domain. Sharing of priority value AND the particular level of aggregation that the
policy containers among QoS policy domains is not possible because of PolicyRule or gpsPolicyGroup resides in. For example, in Figure 3
the dependency of the decision strategy on the relative priority within above, PolicyRule A and PolicyRule B, as well as the gpsPolicyGroup,
each QoS policy domain. 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.
The ability to "divide" a given QoS policy domain's policy rules among Snir, Ramberg, Strassner, Cohen expires May 2001 29
a set of policy containers provides a flexible framework to realize a
fine-grained administrative (or functional) structure. As the example
in figure 2 illustrates, it makes sense to divide policies for the
sales organization into two regional containers: Western and Eastern.
This enables a change in policies for one region to not affect the
policies currently in place for the other region.
While this strategy should meet most needs, taking a slightly different 3.8.3 Sharing Policy Containers
approach can provide additional flexibility. This approach is
illustrated by looking at how PHBs are modeled (see section 6). In this
approach, a different set of PHBs can be assigned to different policy
containers. This has the effect of modifying the interpretation of the
same PHBs by each policy container.
Each policy container is assigned a "match strategy". This is defined For shared (reusable) containers, the priority assigned to the shared
in the qpNamedPolicyRuleMatchMethod attribute of the container must be correct for all containing objects. This restriction
qosPolicyNamedContainer class. This attribute defines how to interpret makes it impractical to share a particular policy container directly
the order of the QoS policy rules that it contains. For example, a (i.e., for two applications belonging to two different QoS policy
FirstMatch strategy means that the rules will be "matched" according to domains to share the same policy container). This is because a policy
ascending order of their Priority attribute. Decision strategies are container can contain not just policy rules, but also additional policy
explained in section 5. 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:
Policy container can be nested. A policy container may contain policy 1. Reusing a gpsPolicyGroup inside a gpsPolicyGroup
rules (PolicyRule [PCIM]) or named policy containers. A particular
data tree, then, can be constructed as a deep hierarchy, if the
designers of the policy system deem it desirable.
3.2.5. Policy Rules 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.
Each qosNamedPolicyContainer holds a set of policy rules (or possibly 2. Reusing a gpsPolicyGroup inside a policyRule
additional policy containers, which could be policyGroups or
qosNamedPolicyContainers, that contain policy rules). QoS policy rules To reference a container C1 with priority P1 from a policy rule R
are modeled by the [PCIM] class policyRule. (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 The semantics of a policy rule is, in essence, a conditional imperative
statement in the form 'if <condition> then <action>'. Applying a rule statement in the form 'if <condition> then <action>'. Applying a rule
means evaluating its condition and, depending on the truth value of means evaluating its condition and, depending on the truth value of
the condition, to execute the action or do nothing. Evaluating a the condition, to either execute the action or to do nothing.
condition is known as 'matching the rule', an expression we'll be using
in later sections of this document.
Snir, Ramberg, Strassner, Cohen expires October 2000 17 Evaluating a condition is known as 'matching the rule', an expression
we'll be using in later sections of this document. [PCIM] requires that
A given policy rule MUST belong to one (and only one) Snir, Ramberg, Strassner, Cohen expires May 2001 32
qosNamedPolicyContainer. This restriction is necessary because the
units of reusability are, in reality, the policy condition and action a given policy rule SHOULD belong to one (and only one) gpsPolicyGroup.
terms that comprise a policy rule (as opposed to the policy rule These semantics are enforced by a special association,
itself). This is because a policy rule is a composite object, made up PolicyRuleInPolicyContainer (defined in [PCIM]), with the appropriate
of several objects, but SHOULD be viewed as a coherent statement. It is cardinality (1 policy container can contain zero-or-more PolicyRules).
believed that allowing a policy rule to belong to more than one policy However, a policy designer may, in some cases, wish to reuse a
container would decrease or even destroy its coherence. For example, particular rule in more than one policy container. The designer MAY do
the rule itself is "aware" of its position inside its policy container, so by encapsulating the would-be reusable rule within a single,
so if we wanted to share a rule among many containers we'd have to reusable policy container and sharing that container, using the
remove this knowledge from the rule. The notion of ordering of rules is technique described in section 3.8.3.
so essential to the concept of policy that removing it from the rule
also renders the rule less expressive, making policy modeling a more
difficult job. Furthermore, there are other important attributes that
are unique to the rule's specific placement inside a policy group
and/or a policy domain. For example, the DSCP values (section 6) that
define how a flow is colored (which in turn define the set of QoS
policy actions that should be invoked by the rule) may be interpreted
differently in different QoS policy domains (or policy containers).
These examples show that the modeling of shared rules is inappropriate
for the QPIM.
The order of the policy rules inside a container is based on the The order of the policy rules inside a container is based on the
relative values of the Priority attribute of each of the policyRules relative values of the Priority attribute of each of the PolicyRules
(please see [PCIM] for more information). The enforcement of policy (please see [PCIM] for more information). The enforcement of policy
rules also depends on particular settings belonging to the group. The rules also depends on particular settings belonging to the group. The
match strategy to be applied to the policy rules contained in a given match strategy to be applied to the policy rules contained in a given
container is defined in the policyRuleMatchMethod attribute of the container is defined in the policyRuleMatchMethod attribute of the
qosNamedPolicyContainer object. Note that actions taken on packets may gpsPolicyGroup object.
use a different mechanism. For example, a DSCP value can be set
directly using the qpSetDSCPValue attribute of the qosPolicyPRAction
class. However, this class could also define a set of token bucket
parameters using the qpTrfcProf attribute. This references a traffic
profile (represented by the qosPolicyPRTrfcProf class) that carries the
policer or shaper rate values to be enforced on a flow or a set of
flows.
3.2.6. Conditions and Actions 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.
A policy rule is a composite object, as mentioned above. The most 3.11. Conditions and Actions
important components of a rule are the conditions and actions it
contains. A condition is a Boolean expression that is evaluated to see
if the rule should be applied. An action is a specification of 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).
Snir, Ramberg, Strassner, Cohen expires October 2000 18 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.2.7. Data Tree Example 3.12. Data Tree Example
The following example illustrates the hierarchical nature of the QoS The following example illustrates the hierarchical nature of the QoS
Policy data tree. Each organizational entity is related to a specific Policy data tree. Each organizational entity is related to a specific
type of class, which is shown in parentheses. type of class, which is shown in parentheses.
There are two QoS policy domains in this example, grouped together There are two QoS policy domains in this example, grouped together
under the same root (domain grouping). The QoS policy domains are: under the same root (domain grouping). The QoS policy domains are:
1. EastCoast (qosPolicyDomain) 1. EastCoast
2. WestCost (qosPolicyDomain) 2. WestCost
Each of these two QoS policy domains has its own PHB set. The EastCoast Snir, Ramberg, Strassner, Cohen expires May 2001 33
domain has 2 named policy containers. The first deals only with ERP
traffic and the second handles all other traffic:
1. EastCoast (qosPolicyDomain) Assume that each of these two qosPolicyDomains has its own PHB set
1.1. ERP (qosNamedPolicyContainer) modeled by a gpsPolicyGroup with a set of policy rules defining the per
1.2. General (qosNamedPolicyContainer) hop behavior for different DSCP values.
The WestCoast domain has 3 named policy container. The first deals only The EastCoast domain has 2 named policy containers. The first deals
With ERP flows, the second deals with VoIP, and the third with all only with ERP traffic and the second handles all other traffic:
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. WestCoast
2.1. ERP (qosNamedPolicyContainer) 2.1. ERP (implemented as a gpsPolicyGroup)
2.2. VoIP (qosNamedPolicyContainer) 2.2. VoIP (implemented as a gpsPolicyGroup)
2.3. General (qosNamedPolicyContainer). 2.3. General (implemented as a gpsPolicyGroup).
Each one of the qosNamedPolicyContainer entries can contain a Each one of the gpsPolicyGroup entries can contain a
prioritized rule set. For example, the WestCoast ERP group contains the prioritized rule set. For example, the WestCoast ERP group contains the
rules relevant to ERP applications administrated by the west coast rules relevant to ERP applications administered by the west coast
domain administrator. domain administrator.
We see from the above structure that this structure provides the We see from the above structure that this structure provides the
administrator with a great deal of flexibility. For example, similarly administrator with a great deal of flexibility. For example, similarly
named containers, represented by the ERP and General containers, represented by the ERP and General
qosNamedPolicyContainers, can reuse common policy conditions and gpsPolicyGroups, can reuse common policy conditions and
actions. However, they are implemented as physically different actions. However, they are implemented as physically different
containers to enable the administrator to administrate them containers to enable the administrator to administer them
according to their own domain-specific needs. according to their own domain-specific needs.
3.3. Reusable-Object Repositories 3.13. Reusable-Object Repositories
Reusable objects are objects that can be referred by (hence "used by") Reusable objects are objects that can be referred by (hence "used by")
other objects. For example, the reference could be accomplished by other objects. For example, the reference could be accomplished by
allocating an attribute on the referencing object that contains the allocating an attribute on the referencing object that contains the
location of the referenced object. location of the referenced object. In this information model,
association classes (and naming rules) are used to establish
Snir, Ramberg, Strassner, Cohen expires October 2000 19 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 concept of reusable-object repositories is introduced by [PCIM] for
the purpose of allowing data tree constructors to share data among many the purpose of allowing data tree constructors to share data among many
users. This document enhances this concept to model the needs of QoS users. This document enhances this concept to model the needs of QoS
policy rules. policy rules.
Snir, Ramberg, Strassner, Cohen expires May 2001 34
A reusable-object repository hierarchy is rooted in an instance of the A reusable-object repository hierarchy is rooted in an instance of the
policyRepository class (defined in [PCIM]). Individual reusable-object policyRepository class (defined in [PCIM]). Individual reusable-object
repositories are named containers for reusable objects. Note that repositories are named containers for reusable objects. Note that
[PCIM] allows arbitrary nesting of reusable-object repositories. This [PCIM] allows arbitrary nesting of reusable-object repositories. This
can be conceptually thought of as a repository of repositories. can be conceptually thought of as a repository of repositories.
Each named reusable-object repository is a container of "reusable Each named reusable-object repository is a container of "reusable
objects" that can be used for a common purpose, and/or are administered 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 in a common way. A reusable object MUST have a unique name within the
the container that it resides in. the container that it resides in.
The complete containment model for the reusable-object repositories, The complete aggregation model for the reusable-object repositories,
as well as detailed description of the various mechanisms for as well as detailed description of the various mechanisms for
constructing and maintaining such repositories, is described in detail constructing and maintaining such repositories, is described in detail
in [PCIM]. in [PCIM].
Anywhere in the QoS Policy information model, where a reference to an
object can be made (a 'reference' type attribute), this reference
SHOULD point to a reusable object in a reusable-object repository.
Common candidates for reusability are named instances of these classes Common candidates for reusability are named instances of these classes
and their derivatives: and their derivatives:
- qosPolicyVariable - gpsPolicyVariable
- qosPolicyValue - gpsPolicyValue
- qosPolicySimpleCondition - gpsPolicySimpleCondition
- gpsPolicyCompoundCondition
- policyAction - policyAction
- qosPolicyMeter, QoSPolicyPRTrfcProf and QoSPolicyRSVPTrfcProf - gpsPolicyMeter, QoSPolicyTrfcProf, QoSPolicyQueue
- QoSPolicyPHBSet - gpsPolicyGroup for policy rule reusability
Throughout this document, we point out the possible use of repository
and repository objects, wherever this is appropriate.
<span class="insert">gpsPolicyGroup for policy rule reusability</span> 3.14. Relationships Between QoS Domains and Repositories
3.4. Relationships Between QoS Domains and Repositories
As explained above, a QoS policy domain contains within it groups of As explained above, a QoS policy domain contains within it groups of
policy rules. A policy rule can contain ordered lists of conditions and policy rules. A policy rule can contain ordered lists of conditions and
actions. The conditions and actions may be reusable object that reside actions. The conditions and actions may be reusable objects that reside
in reusable objects repositories. in reusable-object repositories, or they may be rule-specific
conditions and actions that are embedded within the rule, or a
Many references to reusable objects may be made from the rules of a combination of both.
given QoS policy domain. Those references need not be all pointing to
the same reusable-object repository; even e single rule may contain
references to reusable objects that reside in different repositories.
Snir, Ramberg, Strassner, Cohen expires October 2000 20 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 The maintenance of the policy system is made somewhat more complicated
due to the flexibility of the reference model. For example, it is more due to the flexibility provided by the ability to use multiple
difficult to prevent "dangling" references to repositories that are no repositories. For example, it is more difficult to prevent "dangling"
longer present. Schema designers are encouraged to pay extra attention references to repositories that are no longer present. Schema designers
to this problem and exercise any technique available from their are encouraged to pay extra attention to this problem and exercise any
implementation platform to maintain integrity of their data trees. technique available from their implementation platform to maintain
[PCIM] discusses this issue as well. 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 4. Constructing a QoS Policy Rule
A policy rule modeled in [PCIM] represents the "If Condition then A policy rule modeled in [PCIM] represents the "If Condition then
Action" semantics associated with a policy. The QPIM extends these Action" semantics associated with a policy. The QPIM extends these
semantics by refining the type of policy conditions and actions that semantics by refining the type of policy conditions and actions that
can be represented, extending the use of containers, and providing can be represented, extending the use of containers that hold policy
additional features (nesting of rules, defining extensible rule information, and providing additional features (nesting of rules,
decision strategies, linking to PHBs, and providing pre-defined 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 variables and constants that can be used to express the required
semantics of QoS policy rules in more detail. semantics of QoS policy rules in more detail).
The following sections describe these characteristics in more detail. The following sections describe these characteristics in more detail.
4.1 Policy Rule Structure 4.1 Policy Rule Structure
A policy rule has the following attributes (defined in [PCIM]) that can A policy rule has the following attributes (defined in [PCIM]) that can
be used to provide important semantics for QoS policy applications; be used to provide important semantics for QoS policy applications;
these are in addition to the attributes which serve as a key and these are in addition to the attributes which serve as a key and
provide its name: provide its name:
1. An Enable flag that indicates whether a policy rule is 1. An Enable flag that indicates whether a policy rule is
administratively enabled, administratively disabled, or enabled administratively enabled, administratively disabled, or enabled
for debug mode. for debug mode.
2. A set of conditions (defined in either the 2. A set of conditions,contained in the rules by means of the
PolicyConditionInPolicyRule or PolicyConditionInPolicyRepository PolicyConditionInPolicyRule aggregation. Note that the new
aggregation) subclasses of PolicyCondition that the QPIM defines automatically
3. A flag indicating whether this condition is in disjunctive or inherits this relationships
conjunctive normal form 3. A flag indicating whether the rule's condition is in disjunctive
4. An (optionally ordered) list of actions (defined in either the or conjunctive normal form
PolicyActionInPolicyRule or PolicyActionInPolicyRepository 4. An (optionally ordered) list of actions, contained in the rule by
Aggregation) means of the PolicyActionInPolicyRule aggregation.
5. A priority value, defining the priority of this rule relative to 5. A priority value, defining the ordinal position of this rule
other rules in the same container relative to other rules (or any other contained objects) in the
6. The attribute named ˘mandatory÷, which is used to define whether same container
6. The attribute named mandatory, which is used to define whether
the evaluation of conditions (and the subsequent execution of the evaluation of conditions (and the subsequent execution of
actions if the conditions evaluate to TRUE) is mandatory or not actions if the conditions evaluate to TRUE) is mandatory or not
7. A SequencedActions attribute that defines how to execute the 7. A SequencedActions attribute that defines how to execute the
actions if the condition is TRUE actions if the condition is TRUE
8. An array of PolicyRoles attributes, that define the roles or 8. An array of PolicyRoles attributes, that define the roles or
role-combinations that are used in this rule role-combinations that are used in this rule
9. A RuleUsage attribute, that contains a description of how this 9. A RuleUsage attribute, that contains a description of how this
rule should be used rule should be used
Snir, Ramberg, Strassner, Cohen expires October 2000 21 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
The Boolean condition is used to evaluate if the set of actions should Snir, Ramberg, Strassner, Cohen expires May 2001 36
be performed on a network flow by matching the network flow attributes
against the condition. QoS-specific conditions SHOULD be formed from
using either the qosPolicySimpleCondition class 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 ConditionInPolicyRule class.
Each action in the list is modeled by an action derived from the used to contain a single condition term to be tested. This document
PolicyAction class. The ActionInPolicyRule class defines the order in defines two new policy condition classes. The first,
which policy actions are performed. 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 The interpretation of a policy rule in regard to a given network flow
may be expressed as follows: may be expressed as follows:
If the rule is enabled and the Boolean expression is evaluated to If the rule is enabled and the Boolean expression is evaluated to
TRUE, then use the Action list to extract the prescribed treatment TRUE, then use the Action list to extract the prescribed treatment
for this flow. for this flow.
The rest of this section describes the components of the policyRule The rest of this section describes the components of the policyRule
class and their relationships to the other classes defined in this class and their relationships to the other classes defined in this
schema. information model.
4.2 QoS Policy Conditions 4.2 QoS Policy Conditions
A policy rule modeled in [PCIM] represents the "If Condition then A policy rule, as modeled in [PCIM], represents the "If Condition then
Action" semantics associated with a policy. A condition is represented Action" semantics associated with a policy. A condition is represented
as either an ORed set of ANDed conditions or an ANDed set of ORed as either an ORed set of ANDed terms (disjunctive normal form) or an
conditions. Individual conditions may either be negated (NOT C) or ANDed set of Ored terms (conjunctive normal form). Individual
not negated (C). The actions specified by a policy rule are to be conditions may either be negated (NOT C) or not negated (C). The
performed if and only if the policy rule condition evaluates to TRUE. actions specified by a policy rule are to be performed if and only if
the policy rule condition evaluates to TRUE.
Many conditions in policy rules, from a networking perspective, can be The semantics of an individual condition are not specified in [PCIM].
modeled as Filters. Filters are not modeled directly in either the QPIM Rather, the PCIM limits itself to specifying the structure of a
or the PCIM (i.e., no Filter class is defined). However, the filter condition and its naming attributes. This document provides semantics
concept is central in the QoS Policy data model, and is modeled in the for common QoS policy conditions. For example, conditions such as: "If
Network Model of DEN and used in the companion QoS Device information the source IP address of the flow belongs to 10.1.x.x subnet" as well
model draft [QOSDEV]. as "If the IP protocol number of the flow equals the TCP protocol
number" are modeled in this document.
The semantics of an individual condition is not specified in [PCIM]. Snir, Ramberg, Strassner, Cohen expires May 2001 37
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 October 2000 22 4.2.1 Simple Conditions
The qosPolicySimpleCondition class models individual conditions. This The gpsPolicySimpleCondition class models individual conditions. This
class refines the basic structure of the policyCondition class defined class refines the basic structure of the PolicyCondition class defined
in [PCIM] by using the triplet <variable>, <operator> and <value> to in [PCIM] by specifying the contents of the condition using the triplet
form a condition. <variable>, <operator> and <value> to form the condition.
The variable specifies the attribute of a flow that should be matched The variable specifies the attribute of a flow that should be matched
when evaluating the condition. A set of predefined variables that cover when evaluating the condition. A set of predefined variables that cover
the basic network attribute are introduced to foster interoperability. network attributes that are commonly used for filtering are introduced
The list cover layer 3 IP attribute such as IP network addresses, to encourage interoperability. This list covers layer 3 IP attributes
protocols and ports, as well as a set of layer 2 attributes and higher such as IP network addresses, protocols and ports, as well as a set of
level attributes such as application and user identity. layer 2 attributes (e.g., MAC addresses) and higher level attributes
such as application and user identity.
The variable is matched against a value to produce the Boolean result. The QPIM defines a single operator, "match", as explained in the
In the first example above, a source IP address variable is matched 'Simple Condition Operator' section.
against a 10.1.x.x subnet value. The operator specifies the type of
relation between the variable and the value evaluated in the condition.
Operators should model the 'belong to' and 'equal' relations in the
examples above. In many cases, a generic 'match' operator can be used,
and the interpretation of the relation between the variable and value
is implied by the value itself. For example, the variable source IP
address can be matched to an IP address, where the 'equal' relation is
implied, to a hostname in which the 'resolve to' relation is implied,
or to a subnet address in which 'belongs to' relation is implied.
4.2.1 Reusable vs. Ad-Hoc Conditions The 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.
This schema enables the reuse of simple conditions by placing them in a 4.2.2 Compound Conditions
common portion of the policy information tree (called the reusable-
object repository). In order for a simple condition to be a member of
this repository, it must carry a unique name.
A qosPolicySimpleCondition can either directly contain a value and a Sometimes it is convenient to model a general Boolean expression as an
variable, or can reference either one or both of them if they are kept atomic condition. For example, many packet-related conditions in policy
in a reusable-object repository. 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.
Simple condition composition must enforce the following type Note that a filter may consist of multiple terms. The problem, then, is
conformance rule: The qpValueTypes property of the variable must be that if all we have are the PolicyCondition, PolicyTimePeriodCondition,
compatible with the value class name. 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 The QPIM defines four different ways to compose a simple condition
through the combination of representations of variables and values. The through the combination of representations of variables and values. The
following combinations of representing a simple condition by references following combinations of representing a simple condition are possible:
and containment are possible:
Variable representation Variable representation
1. The class qosPolicyVariable may be contained in the 1. An "ad-hoc" instance of the class gpsPolicyVariable may be contained
qosPolicySimpleCondition instance. by the gpsPolicySimpleCondition instance using the
PolicyVariableInPolicySimpleCondition.
2. The class qosPolicyVariable may be referenced from the
qosPolicySimpleCondition instance (Reusable variable)
Snir, Ramberg, Strassner, Cohen expires October 2000 23 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 Value representation
1. The qosPolicyValue class may be contained in the 1. An "ad-hoc" instance of the class gpsPolicyValue may be contained
qosPolicySimpleCondition class. by the gpsPolicySimpleCondition class using the
PolicyValueInPolicySimpleCondition aggregation.
2. The qosPolicyValue class may be referenced from the Snir, Ramberg, Strassner, Cohen expires May 2001 39
qosPolicySimpleCondition instance. This allows reusing the
qosPolicyValue object, which could be named and considered a named
constant.
4.2.2. Using Simple Conditions 2. A reusable, named instance of the class gpsPolicyValue may be
indirectly linked with the gpsPolicySimpleCondition instance using
the same aggregation as above).
In most cases, the use of the qosPolicySimpleCondition class is The first method for representing variables and values enables either
sufficient for the definition of a condition for a policyRule. A simple to be embedded directly in a policy condition. This is important for
condition can be added to a policyRule in two ways: 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.
1. A direct attachment of an instance of the condition to the A simple condition can be added to a PolicyRule or to a
ConditionInPolicyRule instance. In this case, we call this an gpsPolicyCompoundCondition in two ways:
"ad-hoc" simple condition. This method allows the creation of a
"private" simple condition, meaning that this instance of the
condition can't be referenced by any other policy rule, and
therefore is not reusable. However, since it embeds the condition
directly in the ConditionInPolicyRule instance, it eliminates the
extra access(es) required to fetch each of the condition elements
that are refernced by pointers.
2. An indirect reference to an instance of a condition that resides in 1. Building a rule-specific ("ad-hoc") condition. In this case, the
a reusable-object repository. This is called a reusable condition. goal is to embed the condition directly in either the PolicyRule or the
This method allows the sharing of conditions by multiple policy gpsPolicyCompoundCondition instance. In many data storage mechanism
rules. 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).
4.2.3. Composing Complex Conditions 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.
A complex condition consists of groups of simple conditions (i.e., 2. Building a reusable condition. In this case, the goal is to treat
instances of either the policyCondition and/or the the condition as a reusable building block. Therefore, it will be
qosPolicySimpleCondition classes) that are combined in either placed in a PolicyRepository and referenced by its containing object
conjunctive or disjunctive normal form (as defined in [PCIM]). (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
A complex condition is modeled by the mechanisms supplied in the Snir, Ramberg, Strassner, Cohen expires May 2001 40
following PCIM attributes:
1. The ConditionListType attribute of the policyRule, which directory implementation, a DN pointer will be used to refer to the
is a boolean expression type that defines whether the simple condition. In the information model, we describe this case using two
condition is in conjunctive or disjunctive normal form. relationship classes. One class, the PolicyConditionInPolicyRepository
2. The PolicyConditionInPolicyRule aggregation class that does three association, establishes the "resides-in" relationship between the
things: associates conditions to a particular policy rule, defines reusable object and the reusable-object repository in which it resides.
whether the condition is negated or not, and partitions the Another class, the PolicyConditionInPolicyRule aggregation class,
referenced conditions into one or more groups. For more details, establishes the "contained-in" relationship between the condition and
please see [PCIM], section 6.3. the rule that contains it.
Snir, Ramberg, Strassner, Cohen expires October 2000 24 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 4.3 Simple Condition Operator
The QoS policy simple condition includes the qpOperator property, The QoS policy simple condition includes the gpOperator property,
Which specifies the type of relation between the variable and the value which specifies the type of relation between the variable and the value
evaluated in the condition. In many cases, a generic 'match' operator evaluated in the condition. In many cases, a generic 'match' operator
can be used, and the interpretation of the relation between the can be used, and the interpretation of the relation between the
variable and value is implied by the value itself. For example, the variable and value is implied by the value itself. For example, the
variable source IP address can be matched to an IP address, where the variable SourceIPAddress can be matched to an IP address, where the
'equal' relation is implied, to a hostname in which the 'resolve to' '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, or to a subnet address in which 'belongs to'
relation is implied. 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 The QPIM defines a single operator, "match", that models the most
generic relation: that of being equal or belonging to. generic relation: that of being equal or belonging to.
4.4 QoS Policy Variables 4.4 QoS Policy Variables
QoS Policy Variables are used for building individual conditions, as QoS policy variables are used for building individual conditions, as
defined in section 4.2. The variable specifies the attribute of a flow defined in section 4.2. The variable specifies the attribute of a flow
that should be matched when evaluating the condition. that should be 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 Not every combination of a variable and a value creates a meaningful
condition. For example, a source IP address variable can not be matched 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 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 variables that can be used to model common QoS policy conditions, and
assigns appropriate semantics for each. Each type of variable assigns appropriate semantics for each. Each type of variable
inherently selects the set of value types that it can be matched 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 against (i.e. a value that could be compared and evaluated to a Boolean
expression). expression).
A variable may also limit, or constrain, the set of values within a 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. particular value type that can be matched against it in a condition.
This may be viewed as a second level of integrity checking. For This may be viewed as a second level of integrity checking. For
example, a variable representing the source-port must limit the set of example, a variable representing the source-port must limit the set of
values that it can assume to the valid range of integers that values that it can assume to the valid range of integers that
correspond to legal source-port values (which is 0-65535). Integers correspond to legal source-port values; values such as -3 or 2000000
outside this range can not be matched to this variable. Thus, it is not are not legal values and can not be matched to this variable. Thus, it
enough to say that the data type of the source-port variable is an is not enough to say that the data type of the source-port variable is
integer ű we also need to ensure that the value to be tested is within an integer; we also need to ensure that the value to be tested is
a valid range of integers. 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.
The QPIM defines three important attributes that characterize each of In this first implementation, simple semantics such as those described
the variables that it defines: 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.
1. The property qpVariableName of the QosPolicyVariable class defines The QPIM defines one attribute, one association, and one general
the well-known name used for logical binding of all variables that purpose mechanism that together characterize each of the variables that
are defined in this document. it defines:
2. The qpValueTypes is the list of value classes that could be
matched to this variable.
3. The qpValueConstraints defines a list of constraint on the
variable (i.e., values that the Variable must match).
Snir, Ramberg, Strassner, Cohen expires October 2000 25 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.
The combination of these three attributes provide a consistent and 2. The PolicyValueConstraintsInVariable association defines the set
extensible set of meta-data that define the semantics of variables that of value classes that could be matched to this variable.
are used to form QoS conditions. For example:
- The qpVariableName can be used to identify common processing rules 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. for a variable having a specific name.
- The qpValueTypes attribute can be used to ensure that only proper - The PolicyValueConstraintsInVariable association can be used to
classes are used as operators. For example, the source-port ensure that only proper classes are used in the expression. For
variable will not include the QosPolicyIPv4AddrValue class, since example, the SourcePort variable will not be allowed to associate
source ports have different semantics than IP addresses. However, to the qpsPolicyIPv4AddrValue class, since source ports have
it will include the QosPolicyIntegerValue class name. different semantics than IP addresses and may not be matched.
ű The qpValueConstraints attribute ensures that variable-specific However, it will associate to a gpsPolicyIntegerValue class.
semantics are enforced (e.g., the source-port variable may include - The PolicyValueConstraintsInVariable association also ensures that
a constraint reference to a value object defining the integer range variable-specific semantics are enforced (e.g., the SourcePort
0..63535). variable may include a constraint association to a value object
defining a specific integer range that should be matched).
4.4.1. Variable Binding 4.4.1. Variable Binding
For the QoS Policy schema to be interoperable, different policy For the QoS Policy schema to be interoperable, different policy
management systems and policy servers must instantiate the same management systems and policy servers must instantiate the same
variables with identical values (in the same evaluation operation). variables with identical values (in the same evaluation operation).
While different policy servers may use a different binding mechanism, While different policy servers may use a different binding mechanism,
the binding logic must result in an identical instantiation. the binding logic must result in an identical instantiation.
Each variable defined in the QoS policy repository must be bound to a Each variable defined in the QoS policy data store must be bound to a
logical entity such as a specific field in the IP header, application logical entity such as a specific field in the IP header, a specific
unique identifier or an application-specific parameter. 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 When a policy server attempts to evaluate an expression containing
variables, it must instantiate the variables. To instantiate a variables, it must instantiate the variables. To instantiate a
variable, that variable must be bound to a specific value (or values, variable, that variable must be bound to a specific value (or values,
depending on its type category) and associated with a logical entity. depending on its type category) and associated with a logical entity.
For example, in the expression 'source-port == 80', the variable For example, in the expression 'SourcePort == 80', the variable
'source-port' must be instantiated to a value and logically associated 'SourcePort' must be instantiated to a value and logically associated
with the packet header field containing the source port number, for the with the packet header field containing the source port number, for the
expression to be evaluated. expression to be evaluated.
If, in this example, the variable source-port is bound to a value of 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 '80', then the expression is evaluated to TRUE for each packet that the
source port number in the IP header field equals 80. Otherwise it is source port number in the IP header field equal to 80. Otherwise it is
evaluated to FALSE. evaluated to FALSE.
4.4.2. Pre-Defined Variables 4.4.2. Pre-Defined Variables
The purpose of this section is to explain the need and define the The purpose of this section is to explain the need and define the
relationship of standard, frequently used variables with their logical relationship of standard, frequently used variables with their logical
entities. Pre-defined variables are necessary for ensuring entities. Pre-defined variables are necessary for ensuring
interoperability among policy servers and policy management tools from interoperability among policy servers and policy management tools from
different vendors. different vendors.
Snir, Ramberg, Strassner, Cohen expires October 2000 26
For example, different policy servers may have to evaluate the same For example, different policy servers may have to evaluate the same
policy rule. If each policy server uses a common set of variables, this 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 helps to abstract the condition term such that its evaluation can be
performed in the same way. 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 The QoS Policy information model specifies a set of pre-defined
variables to support a set of fundamental QoS terms that are commonly variables to support a set of fundamental QoS terms that are commonly
used to form conditions. Examples of these include IP header field used to form conditions. Examples of these include IP header field
values, user information, applications, and others. A pre-defined values, user information, applications, and others. A pre-defined
variable MUST always have the same name and binding semantics. For variable MUST always have the same name and binding semantics. For
example, a given pre-defined variable should be bound to the same example, a given pre-defined variable should be bound to the same
logical entity by all client systems (typically policy devices). logical entity by all client systems (typically policy devices).
Similarly, the pre-defined variable should be stored in the reusable- Similarly, the pre-defined variable should be stored in the reusable-
object repository to enable reuse and sharing of the pre-defined object repository to enable reuse and sharing of the pre-defined
variable. variable.
Snir, Ramberg, Strassner, Cohen expires May 2001 46
All standard variable names are case insensitive and do not include All standard variable names are case insensitive and do not include
spaces or other non-standard characters to promote ease of use. spaces or other non-standard characters to promote ease of use.
The implementers of client systems that map the QPIM to a specific The implementers of client systems that map the QPIM to a specific
repository-based implementation MUST provide binding methods to bind repository-based implementation MUST provide binding methods to bind
pre-defined variables according to the semantics specified in this pre-defined variables according to the semantics specified in this
section. section.
Following is a table that defines the predefined variable names and Following is a table that defines the predefined variable names and
their binding. The table indicates which fields are checked in actual their binding. The table indicates which fields are checked in actual
skipping to change at line 1393 skipping to change at line 2388
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| DestinationIP | The destination IP address of the flow. Compared | | DestinationIP | The destination IP address of the flow. Compared |
| | to the destination IP header field, or the session| | | to the destination IP header field, or the session|
| | address in the RSVP SESSION object [RSVP]. | | | address in the RSVP SESSION object [RSVP]. |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| DestinationPort | The destination Port of a UDP/TCP flow. Compared | | DestinationPort | The destination Port of a UDP/TCP flow. Compared |
| | to the destination port field in the TCP/UDP | | | to the destination port field in the TCP/UDP |
| | header, or the session port in the RSVP SESSION | | | header, or the session port in the RSVP SESSION |
| | object [RSVP]. | | | object [RSVP]. |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
(Table continued in next page)
Snir, Ramberg, Strassner, Cohen expires October 2000 27
(Table continued from the previous page)
+-----------------+---------------------------------------------------+
|Variable name | Logical binding |
+-----------------+---------------------------------------------------+
| IPProtocol | The IP protocol number. Compared to the protocol | | IPProtocol | The IP protocol number. Compared to the protocol |
| | number in the IP header field or to the IP | | | number in the IP header field or to the IP |
| | protocol in the RSVP SESSION object [RSVP]. | | | protocol in the RSVP SESSION object [RSVP]. |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| ToS | The ToS variable is bound to the IP header ToS | | ToS | The ToS variable is bound to the IP header ToS |
| | byte. | | | byte. |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| DSCP | The DSCP variable is bound to the IP header DSCP | | DSCP | The DSCP variable is bound to the IP header DSCP |
| | byte or to DCLASS RSVP object. | | | byte or to the DCLASS RSVP object. |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| DestinationMAC | The destination MAC address variable is bound the | | DestinationMAC | The destination MAC address variable is bound the |
| | frame destination MAC address. | | | frame destination MAC address. |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| SourceMAC | The source MAC address variable is bound the frame| | SourceMAC | The source MAC address variable is bound the frame|
| | source MAC address. | | | source MAC address. |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| 8021QID | The VLAN ID as represented in the 802.1Q field of |
(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. | | | the header. |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| Snap | The snap protocol variable is bound to protocol | | Snap | The snap protocol variable is bound to the |
| | type carried over SNAP encapsulation. | | | protocol type carried over SNAP encapsulation. |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| Ethertype | The ethertype variable is bound to the frame | | Ethertype | The ethertype variable is bound to the frame |
| | header ethertype value. | | | header ethertype value. |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| Ssap | The source sap variable is bound the frame header | | Ssap | The source sap variable is bound the frame header |
| | field containing the source SAP. | | | field containing the source SAP. |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
|Variable name | Logical binding |
+-----------------+---------------------------------------------------+
| Dsap | The destination sap variable is bound the frame | | Dsap | The destination sap variable is bound the frame |
| | header field containing the destination SAP. | | | header field containing the destination SAP. |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| Application | The ID of the application that generated the flow.| | Application | The ID of the application that generated the flow.|
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| User | The ID of the user that initiated the flow, or is | | User | The ID of the user that initiated the flow, or is |
| | designated as the flow owner. | | | designated as the flow owner. |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
Table 2. Pre-defined Variable Names and Their Bindings Table 1. Pre-defined Variables and Their Bindings
The definition of each predefined variable includes a standard name and The definition of each predefined variable includes a standard name and
the allowed value types, i.e. the variable's qpValueTypes property. the allowed value types. The VariableHasDataValues association is used
to associate a variable object with a value object.
Following is a table of variable names and their allowed class types. 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 October 2000 28 Snir, Ramberg, Strassner, Cohen expires May 2001 48
value classes defined elsewhere to be combined with variables defined
in this document.
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
|Variable name | Allowed class types | |Variable name | Allowed value types |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| SourceIP | qosPolicyIPv4AddrValue, qosPolicyIPv6AddrValue | | SourceIP | gpsPolicyIPv4AddrValue, gpsPolicyIPv6AddrValue |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| SourcePort | qosPolicyIntegerValue | | SourcePort | gpsPolicyIntegerValue |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| DestinationIP | qosPolicyIPv4AddrValue, qosPolicyIPv6AddrValue | | DestinationIP | gpsPolicyIPv4AddrValue, gpsPolicyIPv6AddrValue |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| DestinationPort | qosPolicyIntegerValue | | DestinationPort | gpsPolicyIntegerValue |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| IPProtocol | qosPolicyIntegerValue | | IPProtocol | gpsPolicyIntegerValue |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| ToS | qosPolicyIntegerValue, qosPolicyBitStringValue | | ToS | gpsPolicyIntegerValue, gpsPolicyBitStringValue |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| DSCP | qosPolicyIntegerValue, qosPolicyBitStringValue | | DSCP | gpsPolicyIntegerValue, gpsPolicyBitStringValue |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| DestinationMAC | qosPolicyMACAddrValue | | DestinationMAC | gpsPolicyMACAddrValue |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| SourceMAC | qosPolicyMACAddrValue | | SourceMAC | gpsPolicyMACAddrValue |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| 8021QID | qosPolicyIntegerValue, qosPolicyBitStringValue | | 8021QID | gpsPolicyIntegerValue, gpsPolicyBitStringValue |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| Snap | qosPolicyIntegerValue | | Snap | gpsPolicyIntegerValue |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| Ethertype | qosPolicyIntegerValue | | Ethertype | gpsPolicyIntegerValue |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| Ssap | qosPolicyIntegerValue | | Ssap | gpsPolicyIntegerValue |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| Dsap | qosPolicyIntegerValue | | Dsap | gpsPolicyIntegerValue |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| Application | qosPolicyDNValue, qosPolicyStringValue, | | Application | gpsPolicyDNValue, gpsPolicyStringValue, |
| | qosPolicyAttributeValue | | | gpsPolicyAttributeValue |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| User | qosPolicyDNValue, qosPolicyStringValue, | | User | gpsPolicyDNValue, gpsPolicyStringValue, |
| | qosPolicyAttributeValue | | | gpsPolicyAttributeValue |
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
Table 3. Allowed Variable Names and Their Default Class Types Table 2. Variable Names and Their Default Class Mappings
Note: For Value type definition, check the QoS Policy Value section.
Snir, Ramberg, Strassner, Cohen expires October 2000 29 Note: Values are defined in section 4.5.
4.5 QoS Policy Value 4.5 QoS Policy Value
This abstract class qosPolicyValue is used for defining values and The abstract class gpsPolicyValue is used for defining values and
constants used in policy conditions. Different value types are derived constants used in policy conditions. Different value types are derived
Snir, Ramberg, Strassner, Cohen expires May 2001 49
from this class and represent the various attributes required. from this class and represent the various attributes required.
Extensions of the qosPolicValue class, defined in this document Extensions of the qpsPolicyValue class, defined in this document
provide a list of values for representing the basic network attribute. provide a list of values for representing the basic network attribute.
Values can be used to represent constants as named values. Named values Values can be used to represent constants as named values. Named values
could be kept in a repository to be reused by multiple conditions. could be kept in a reusable-object repository to be reused by multiple
Examples of constants include well-known ports, well-known protocol, conditions.
Examples of constants include well-known ports, well-known protocols,
server addresses, and other similar concepts. server addresses, and other similar concepts.
The QoS Policy value classes define 3 types of basic values: scalars, The qpsPolicyValue classes define 3 basic types of values: scalars,
ranges and sets. For example, a well-known port number could be defined ranges and sets. For example, a well-known port number could be defined
using the qosPolicyIntegerValue, defining a single value (80 for HTTP) using the gpsPolicyIntegerValue class, defining a single value (80 for
a range (80-88) or a set (80, 82, 8080). For details, please see the HTTP), a range (80-88), or a set (80, 82, 8080) of ports, respectively.
class definition for each value type. 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 The QoS policy information model provide the following classes, all of
them extending the QoSPolicyvalue: them extending the qpsPolicyValue class:
General: Classes for general use:
qosPolicyStringValue GpsPolicyStringValue,
qosPolicyIntegerValue, gpsPolicyIntegerValue,
qosPolicyBitStringValue, gpsPolicyBitStringValue,
qosPolicyDNValue, gpsPolicyDNValue,
qosPolicyAttributeValue. gpsPolicyAttributeValue.
Layer 3 Network values: Classes for layer 3 Network values:
qosPolicyIPv4AddrValue, gpsPolicyIPv4AddrValue,
qosPolicyIPv6AddrValue. gpsPolicyIPv6AddrValue.
Layer 2 Network values: Classes for layer 2 Network values:
qosPolicyMACAddrValue. gpsPolicyMACAddrValue.
For details, please see the class definition section of each value. For details, please see the class definition section of each value in
section 8 of this document.
4.6. PolicyTimePeriodCondition 4.6. PolicyTimePeriodCondition
The QoS Policy Information model uses the policyTimePeriodCondition The QoS Policy Information model uses the policyTimePeriodCondition
class (defined in [PCIM]) to define time based QoS policy rules. For class (defined in [PCIM]) to define time based QoS policy rules. For
details, please see [PCIM], section 6.5. details, please see [PCIM], section 6.5.4.7. Actions
4.7. Actions 4.7 Actions
The QoS Policy schema defines actions to control QoS enforcement in The QoS Policy information model defines actions to control QoS
both the Integrated-Service model as well as the Differential service enforcement in both the Integrated Service model as well as the
model. Two types of actions are provided: Signaling and Provisioning Differentiated Service model. Three types of actions are provided:
actions. Signaling, Provisioning and Per-Hop-Behvior (PHB) actions.
Snir, Ramberg, Strassner, Cohen expires October 2000 30 Snir, Ramberg, Strassner, Cohen expires May 2001 50
Signaling actions are used to provide policy control on RSVP Signaling actions are used to provide policy control on RSVP
requests. Provisioning actions are used to directly control the data requests. Provisioning actions are used to enforce differentiated
traffic, regardless of any out-of-band signaling. 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 A policy rule may aggregate zero or more policy actions. A QoS policy
rule extends this definition to include 0..n provisioning actions and rule extends this definition to include 0..n provisioning actions,
0..m signaling actions, each defined by an object or objects describing o..k PHB actions and 0..m signaling actions, each defined by an object
the action(s) to perform. Actions are ordered (as opposed to rules, or objects describing the action(s) to perform. This extension is done
which are prioritized). The order of actions is specified in [PCIM]. 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 defines The property SequencedActions in the aggregating instance of a
whether a specified action order is required, recommended, or of no PolicyRule (see section 6.3.6 of [PCIM]) defines whether a specified
significance. action order is required, recommended, or of no significance.
Ordering semantics depend on how actions are represented. If actions Ordering semantics depend on how actions are represented. If actions
are represented as separate objects, the PolicyActionInPolicyRule are represented as separate objects that are aggregated by PolicyRule,
aggregation can be used to express an order. In this case, three the PolicyActionInPolicyRule aggregation can be used to express an
attributes are used: order. In this case, three attributes are used:
- ContainingRule, which contains a reference to a policyRule that - GroupComponent, which defines zero or more PolicyRules that can
contains one or more policyActions contain the same PolicyAction
- ContainedAction, which contains an object reference to a - PartComponent, which defines zero or more PolicyActions that are
policyAction contained by one or more policyRules contained by a given policyRule
- ActionOrder, which is an unsigned integer 'n' that indicates the - ActionOrder, which is an unsigned integer 'n' that indicates the
relative position of an action in the sequence of actions that are relative position of an action in the sequence of actions that are
associated with a given policy rule. When 'n' is a positive associated with a given policy rule. When 'n' is a positive
integer, it indicates a place in the sequence of actions to be integer, it indicates a place in the sequence of actions to be
performed, with smaller integers indicating earlier positions in performed, with smaller integers indicating earlier positions in
the sequence. The special value '0' indicates "don't care". If the sequence. The special value '0' indicates "don't care". If
two or more actions have the same non-zero sequence number, they 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 may be performed in any order, but they must all be performed at
the appropriate place in the overall action sequence. the appropriate place in the overall action sequence.
For actions defined explicitly in a subclass of policyRule, the For actions defined explicitly in a subclass of policyRule, the
ordering mechanism must be specified in the subclass definition. Note ordering mechanism must be specified in the subclass definition. Note
that QPIM does not define any policyRule subclasses. Instead, the QPIM that QPIM does not define any policyRule subclasses. Instead, the QPIM
defines subclasses of policyCondition and policyAction to extend the defines subclasses of policyCondition and policyAction to extend the
semantics of these classes. semantics of these classes.
Provisioning and signaling actions can be intermixed in a QoS policy Provisioning, PHB and signaling actions can be intermixed in a QoS
rule. Policy consumers (such as PDPs) MAY separate the actions into policy rule. Policy consumers (such as PDPs) MAY separate the actions
separate lists, but MUST respect the internal order of the specified into separate lists, but MUST respect the internal order of the
actions. specified actions.
Snir, Ramberg, Strassner, Cohen expires May 2001 51
4.7.1 Provisioning Actions 4.7.1 Provisioning Actions
QoS Policy provisioning actions model traffic conditioner elements, as QoS policy provisioning actions configure traffic conditioner
specified in [DIFF-SERV-ARCH]. Actions model meters, markers, shapers elements, as specified in [DIFF-SERV-ARCH]. Actions configure meters,
and droppers. markers, shapers and droppers.
Snir, Ramberg, Strassner, Cohen expires October 2000 31 The qosPolicyPRAction class is a generic class that defines a
set of DiffServ actions that can be applied to an individual flow or
to a group of flows.
4.7.1.1 Meters 4.7.1.1 Meters
Meters measure the temporal properties of the stream of packets Meters measure the temporal properties of a stream of packets
selected by a classifier against a traffic profile. Meters are modeled selected by a classifier against a traffic profile.
by the QosPolicyMeter class. A meter can be shared between different
policy rules. If this is desired, then the meter SHOULD reside in a
reusable-object repository. This enables it to be referenced by all
policy rules that want to share it.
The property qpMeter is used to hold a reference to a (reusable) meter A meter is associated with a provisioning action using the
that is kept in a reusable-object repository. The qpMeterScope property PolicyMeterInAction association. A meter can be shared among
specifies whether the meter should measure flows matching the rule (i.e., used by) policy actions of different rules. If this is desired,
condition per interface, per device or per flow. A per flow meter then the meter SHOULD reside in a reusable-object repository.
conceptually creates a new meter for each flow, measuring each flow
against the profile. A per interface meter measures the aggregate set
of flows matching the rule condition forwarded via a single interface.
Meters are measured against traffic profile modeled by the Meters measure flows matching the rule condition per flow, per
qosPolicyPRTrfcProf object. The property qpTrfcProf holds a reference interface, per role within a device, per device or per role across all
to a traffic profile that resides in a reusable-object repository. devices. A per flow meter conceptually creates a new meter for each
flow, measuring each flow against the profile. A per interface meter
measures the aggregate set of flows matching the rule condition
forwarded via a single interface. Other options measure traffic across
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.
4.7.1.2 Markers The [DIFF-MIB] definition of a meter combines the traffic profile and a
meter as one unit. Separation of the concepts provides more flexibility
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
A metered provisioning action using three level traffic profile
specifies the actions that should be enforced on excess and
violating traffic using the qpExcessAction and qpViolateAction
properties. A three level metered action that does not specify
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
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
Markers are used to set the DS field of a packet to a particular DS Markers are used to set the DS field of a packet to a particular DS
codepoint (DSCP), adding the marked packet to a particular DS behavior Code Point (DSCP), adding the marked packet to a particular DS
aggregate. The marker may be configured to mark all packets steered to behavior aggregate. The marker may be configured to mark all packets
it to a single DSCP, or may be configured to mark a packet to one of a that it receives to a single DSCP, or may be configured to mark a
set of DSCPs used to select a PHB in a PHB group, according to the packet to one of a set of DSCPs used to select a PHB in a PHB group
state of a meter. When the marker changes the DSCP in a packet, it is according to the state of a meter. The marker may also be configured to
said to have "re-marked" the packet. 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.
Marking is modeled by the property qpSetDSCPValue, which specifies the Snir, Ramberg, Strassner, Cohen expires May 2001 53
DSCP to set. Remarking out-of-profile packets is modeled by the
qpOutofProfileRemarkValue property. The property qpOutOfProfileAction The qosPolicyPRAction class contains a number of properties that can be
should be set to 'remark' when the remark DSCP value is used. 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
qpViolateMarkValue carries the marking values. The value type is
determined by the property qpMarkValueType. Both excess and violate
actions may be specified when measuring a meter against a three level
traffic profile. Please see section 8.3 for more detail.
4.7.1.3 Shapers 4.7.1.3 Shapers
Shapers are used to delay some or all of the packets in a traffic Shapers are used to delay some or all of the packets in a traffic
stream in order to bring the stream into compliance with a traffic stream in order to bring the stream into compliance with a traffic
profile. A shaper usually has a finite-sized buffer, and packets may profile. A shaper usually has a finite-sized buffer, and packets may
be discarded if there is not sufficient buffer space to hold the be discarded if there is not sufficient buffer space to hold the
delayed packets. delayed packets.
If the value of the property qpOutOfProfileAction is set to 'shape', Again, the qosPolicyPRAction class contains a number of properties that
then this specifies that packets measured by a meter should be shaped can be used to control the behavior of a shaper. For example, the value
according to the traffic profile specified by a qosPolicyPRTrfcProf of the property qpExcessAction or qpViolateAction should be set to
object. 'shape' in order to model a shaper. Traffic should be shaped according
to a traffic profile defined by a qosPolicyPRTrfcProf class.
Snir, Ramberg, Strassner, Cohen expires October 2000 32
4.7.1.4. Droppers 4.7.1.4. Droppers
Droppers are used to discard some or all of the packets in a traffic Droppers are used to discard some or all of the packets in a traffic
stream in order to bring the stream into compliance with a traffic Stream. Usually, this is done in order to bring the stream into
profile. This process is also known as "policing" the stream. compliance with a traffic profile. This process is also known as
"policing" the stream.
If the value of the property qpOutOfProfileAction is set to 'drop', Again, the qosPolicyPRAction class contains a number of properties that
then it specifies that packets measured by a meter should be policed can be used to control the behavior of a shaper. For example, the value
according to the traffic-profile specified by a qosPolicyPRTrfcProf of the property qpExcessAction or qpViolateAction should be set
object. 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
4.7.1.5 Examples 4.7.1.5 Examples
The following examples will help to show how these classes can be used Below are two examples on how this document models rules specifying
to perform general provisioning actions. provisioning actions to be enforced on the edge of a differential
service domain.
Example 1: Set up a rule enforcing QoS provisioning actions: Example 1:
LetĂs define a policy rule, P, as follows: Traffic flowing from one machine to another should be marked with DSCP
X to provide it with the correct per hop behavior. This traffic should
not exceed 1Mb/sec. Each flow should not exceed more than 300Kb/sec. A
single policy rule can be constructed to enforce this set of actions.
The condition can be built from two simple conditions matching the
source IP address of one machine and the destination of the other
machine. A set of three provisioning actions can be used in the
following form:
If (<condition>) THEN, on outgoing traffic, Action 1:
mark with <DS Value> AND Object: qosPolicyPRAction
activate a per-flow policer <FLOWP> AND qpMarkValueType: DSCP
activate a per policy rule policer <CLASSP> qpMarkValue: X
Rule P is represented using 3 qosPolicyPRAction objects: Action 2:
Object: qosPolicyPRAction
PolicyMeterInAction association to: Meter-1
qpExcessAction: Drop
Object 1: Action 3:
qpDirection: OUT Object: qosPolicyPRAction
qpSetDSCPValue: <DS Value> PolicyMeterInAction association to: Meter-2
qpExcessAction: Drop
Object 2: The meters and traffic profile can take the form of:
qpDirection: OUT
qpMeterScope: flow
qpTrfcProf: <FLOWP> (this is a repository-specific reference to a
per-flow policer object)
qpOutOfProfileAction: discard
Object 3: Meter 1:
qpDirection: OUT Object: GpsPolicyMeter
qpMeterScope: Interface gpMeterScope: interface
qpTrfcProf: <CLASSP> (this is a repository-specific reference to a PolicyTrfcProfileInMeter association to: Profile-1
per-policyRule policer object)
qpOutOfProfileAction: discard
qpMeter: <Meter>
Snir, Ramberg, Strassner, Cohen expires October 2000 33 Meter 2:
Object: GpsPolicyMeter
gpMeterScope: flow
PolicyTrfcProfileInMeter association to: Profile-2
Profile 1:
Object: QosPolicyPRTrfcProf
QpPRRate: 1Mb/sec
QpPRNormalBurst: 1000 bytes
Snir, Ramberg, Strassner, Cohen expires May 2001 55
Profile 2:
Object: QosPolicyPRTrfcProf
QpPRRate: 300Kb/sec
QpPRNormalBurst: 1000 bytes
Example 2: Conditioning traffic Example 2: Conditioning traffic
Some PHBs require the successive application of a set of traffic Some PHBs require the successive application of a set of traffic
conditioners to properly process the traffic. An example of a policy conditioners to properly process the traffic. An example of a policy
with two levels of traffic conditioning is the following: with two levels of traffic conditioning is the following:
Mark packets to DSCP=24 if the rate is within profile x=<64Kb/s>, Mark packets to DSCP=24 if the rate is within profile x=<64Kb/s>,
else mark packets with DSCP=25 if rate is within profile y=<128kb/s>, else mark packets with DSCP=25 if rate is within profile y=<128kb/s>,
else drop out-of-profile packets. else drop out-of-profile packets.
skipping to change at line 1718 skipping to change at line 2841
within this profile, then the traffic is (re)marked with a DSCP of 24. within this profile, then the traffic is (re)marked with a DSCP of 24.
If the traffic is out of profile, then the subsequent action measures If the traffic is out of profile, then the subsequent action measures
the traffic against the second higher profile. If the traffic is within the traffic against the second higher profile. If the traffic is within
this profile, then the traffic is (re)marked with a DSCP of 25. this profile, then the traffic is (re)marked with a DSCP of 25.
Otherwise, the traffic is out of profile, and it will be dropped. Otherwise, the traffic is out of profile, and it will be dropped.
In this way, an arbitrary cascading of traffic conditioners can be In this way, an arbitrary cascading of traffic conditioners can be
constructed, where each action measures traffic against a higher constructed, where each action measures traffic against a higher
traffic profile and change only the out-of-profile action as required. traffic profile and change only the out-of-profile action as required.
4.7.2 Signaling Action This policy rule can be build in another way using associations to
actions that should be performed on exceeding or violating traffic. In
this way, the first action measures traffic according to the first
traffic profile, and reference the second action using
policyExcessNextAction association. The second action than base its
decision whether to discard or remark traffic according to the higher
traffic profile.
RSVP is the standard protocol used for requesting QoS resources from Snir, Ramberg, Strassner, Cohen expires May 2001 56
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 4.7.2 Per-Hop-Behavior Actions
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 A Per-Hop-Behavior (PHB) is a description of the externally observable
point) to instruct an RSVP node (policy enforcement point) to enforce forwarding behavior of a DS node applied to a particular DS behavior
all set of controls defined in the COPS protocol specification. The aggregate [DIFF-SERV-ARCH]. The approach taken here is that a PHB
actions defined here follow the different decision types of the COPS action specifies both observable forwarding behavior (i.e., loss, delay
protocol [COPS] and the guidelines for its use in an RSVP environment ,jitter) as well as specifying the buffer and bandwidth resources that
[COPS-RSVP]. The basic decision to accept or deny a reservation is needs to be allocated to each of the behavior aggregates in order to
modeled by the qosPolicyRSVPAction class. Additional control is achieve these observables. That is, a rule with a set of PHB actions
provided through the use of two classes. The content and forwarding can specify that an EF packet must not be delayed more than 20 msec in
behavior of RSVP flows is defined by the qosPolicyRSVPSignalCtrlAction each hop. The same rule may also specify that that EF packets needs to
class. The qosPolicyRSVPInstallAction class controls the processing of be treated with preemptive forwarding (priority queuing), and specify
RSVP requests and accompanying flows within the RSVP node itself. the maximal bandwidth for this class as well as the maximal buffer
resources. PHB actions can therefore be used to both represent the
final requirements from PHBs as well as provide enough detail to be
able to map the PHB actions into a set of configuration parameters to
configures queues, schedulers, droppers and other mechanism. In
particular, the PHB actions includes attributes that are directly
mapped to the differential service MIB configuration scheme
[DUFF-MIB].
Snir, Ramberg, Strassner, Cohen expires October 2000 34 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.
QoS signaling policies does not require a policy server for decision 4.7.2.1 Bandwidth and Delay Management
making. A local policy module can use signaling policies for making
local decisions, as well as if other outsourcing policy protocol beside PHB actions allows specifying the minimal bandwidth that should be
COPS is used. 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
should be queued for forwarding. The qosPolicyQueue class specify the
queuing properties of the PHB action. Two PHB actions, used within two
different rules may reference the same qosPolicyQueue object,
indicating that flows matched by these rules should use the same
queue. For example, rules specifying PHB actions for AF11 and
AF12 [AF] PHBs should indicate that AF11 and AF12 belong to the
same PHB group and should be queued together to avoid packet reordering
affects.
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
action and a qosPolicyQueue.
The qosPolicyQueue class carries all properties described in the
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
Policy Information model. Nevertheless, hierarchical policy rules may
require enforcement using more than a single scheduler or queue set.
This is explained in the next section.
Snir, Ramberg, Strassner, Cohen expires May 2001 58
4.7.2.4 Using Hierarchical policies
The ability to define sub rules within rules allow for definition of
hierarchical policies. Hierarchical policies form a hierarchy of
classification and specification of actions for each level of the
hierarchy. For example, a rule may specify the actions that
should be performed on all UDP traffic, while its sub rules specify the
actions that should be performed on various UDP applications. Rules
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
This example provides a set of rules that specify PHBs enforced within
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:
If (EF) than do EF actions
If (AF11) than do AF11 actions
If (AF12) than do AF12 actions
If (default) than do Default actions.
EF, AF11, AF12 represent conditions that filter traffic according to
DSCP values. These filters are represented using either a reusable or
ad-hoc policy conditions. The default rule uses a 'catch all' filter
and specifies the Best Effort rules.
The set of rules reside in a gpsPolicyGroup.
The decision strategy is defined to be 'FIRST MATCH'.
The objects below specifies the set of actions used to describe each of
the PHBs:
QosPolicyPHBAction BE:
PolicyQueueInPHBAction association to: Beq
QpDropAlgorithm: random
qpDropThresholdValueType packet
qpDropMinThreshold: 6pckts
qpDropMaxThreshold: 40pckts
Snir, Ramberg, Strassner, Cohen expires May 2001 59
QosPolicyPHBAction AF11:
PolicyQueueInPHBAction association to: AF1xq
QpDropAlgorithm: random
qpDropThresholdValueType packet
qpDropMinThreshold: 4pckts
qpDropMaxThreshold: 20pckts
QosPolicyPHBAction AF12:
PolicyQueueInPHBAction association to: AF1xq
QpDropAlgorithm: random
qpDropThresholdValueType packet
qpDropMinThreshold: 2pckts
qpDropMaxThreshold: 10pckts
QosPolicyPHBAction EF:
PolicyQueueInPHBAction association to: EFq
QpDropAlgorithm: drop
qpDropThresholdValueType packet
qpDropMaxThreshold: 3pckts
AF11 and AF12 share the same queue, indicating that they belong to the
same PHB group. Following are the qosPolicyQueue objects defined in
this example:
qosPolicyQueue BEq:
qpBandwidthValueType
qpFairQueue: TRUE
qosPolicyQueue AF1xq:
qpBandwidthValueType: kb/sec
qpMinBandwidth: 512Kb/sec
qosPolicyQueue EFq:
qpForwardingPriority: 1
qpBandwidthValueType: %
qpMaxBandwidth 50%
qpFairQueue: 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
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: parameters can be specified:
1. Direction - in/out 1. Direction - in/out
2. Message type - Path/Resv/PathErr/ResvErr 2. Message type - Path/Resv/PathErr/ResvErr
3. Service type - Guaranteed Service / Controlled Load / Null 3. Service type - Guaranteed Service / Controlled Load / Null
4. Service style - SE, WF, FF 4. Service style - SE, WF, FF
The direction refers to the direction of the flow, hence the direction The direction refers to the direction of the flow, hence the
of the RSVP Path messages. Therefore, out-direction policies control Direction of the RSVP Path messages. Therefore, out-direction policies
outgoing Path messages as well as incoming Resv messages. Control outgoing Path messages as well as incoming Resv messages.
The basic decision modeled by this class is whether to admit or reject
the RSVP request. The decision can be based on comparison of the
request TSPEC or FLOWSPEC to a traffic profile and a meter. A meter can
be used to track the temporal resources allocation of RSVP requests
matching a network condition. Such meters allow enforcement of policies
of the form: "Allow allocation of resource via RSVP for flows coming
from subnet x up to a total aggregated rate of 256kb/sec". Use of
meters and meter scope is identical to their use in provisioning
policies. The following properties are used:
1. Traffic Profile - referencing a traffic profile. 4.7.3.1 Admission Control
2. Meter - referencing a meter.
Both traffic profile and meter specifications can be directly included The basic decision modeled by the qosPolicyRSVPAction class is
within the action as well. 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 Note that if a traffic profile is not provided, it is implicitly
assumed that the RSVP request should be accepted. Rejecting all RSVP assumed that the RSVP request should be accepted. Rejecting all RSVP
requests matching the condition is specified by a zero valued traffic requests matching the condition is specified by a zero valued traffic
profile. profile.
The qosPolicyRSVPInstallAction adds the following actions: 4.7.3.2 Forwarding Behavior
1. Set the DSCP value 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. 2. Set the preemption priority of the RSVP request.
Setting the DSCP of the flow on the edge of a differential service core Setting the DSCP of the flow on the edge of a differential
allow provisioning of QoS, end-to-end, over mixed integrated and service core allow provisioning of QoS, end-to-end, over mixed
differential service clouds. integrated and differential service clouds.
Snir, Ramberg, Strassner, Cohen expires October 2000 35 Snir, Ramberg, Strassner, Cohen expires May 2001 62
An RSVP node is responsible for deciding whether to admit flows or not, An RSVP node is responsible for deciding whether to admit flows
based on its available resources. Setting the preemption priority or not, based on its available resources. Setting the preemption
[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 priority [RSVP_PREEMP] allows the RSVP node to decide which of its
required. reservations should be admitted, and when to make room for a newer
reservation by preempting an already installed one.
The qosPolicyRSVPSignalCtrlAction adds the following controls: 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. 1. Replace/add DCLASS object in RSVP message.
2. Replace/add Preemption priority object in RSVP message. 2. Replace/add Preemption priority object in RSVP message.
3. Trigger an error/warning RSVP message. 3. Trigger an error/warning RSVP message.
4. Instruct the RSVP node to proxy RSVP message as if sent by 4. Instruct the RSVP node to proxy RSVP message as if sent by
the RSVP end nodes. the RSVP end nodes.
Modifying the content of messages can be enforced using a COPS Modifying the content of messages can be enforced using a COPS
replacement decision. This class should be extended to cover other replacement decision. This class should be extended to cover other
object replacements and, in particular, replacement of policy objects. object replacements and, in particular, replacement of policy objects.
skipping to change at line 1829 skipping to change at line 3195
a need to notify the end nodes that their reservation is about to a need to notify the end nodes that their reservation is about to
expire and various other information. expire and various other information.
There are scenarios in which it makes sense not to carry RSVP requests There are scenarios in which it makes sense not to carry RSVP requests
end-to-end. An RSVP node on the boundary of a differential service core end-to-end. An RSVP node on the boundary of a differential service core
may map the RSVP request to specific PHB by setting the DSCP on the may map the RSVP request to specific PHB by setting the DSCP on the
flow packets, without forwarding the Path message downstream. Still, flow packets, without forwarding the Path message downstream. Still,
this RSVP node may send back an RSVP Resv message as if the receiver this RSVP node may send back an RSVP Resv message as if the receiver
has sent it, to complete the RSVP cycle. has sent it, to complete the RSVP cycle.
The following is an example for a rule enforcing QoS signaling actions: 4.7.3.4 Examples
Rule S:
If <condition> THEN, for all WF and SE style Resv messages,
accept RSVP request requesting less than <64kb/sec> AND
make sure that the total number of admitted active reservations
is restricted to <5>.
The actions for Rule S are represented using two qosPolicyRSVPAction Below is an example on how this document models rules specifying
objects, as follows: 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.
Object 1: qosPolicyRSVPAction 1:
qpRSVPDirection: OUT
qpRSVPMessageType: Resv qpRSVPMessageType: Resv
qpRSVPStyle: SE, WF qpRSVPStyle: FF
qpRSVPTrfcProf : DN {8Kb} (repository reference) PolicyMeterInAction association to: Meter-1
qpRSVPMeterScope: flow
Snir, Ramberg, Strassner, Cohen expires October 2000 36 Snir, Ramberg, Strassner, Cohen expires May 2001 63
Object 2: qosPolicyRSVPAction 2:
qpRSVPDirection: OUT
qpRSVPMessageType: Resv qpRSVPMessageType: Resv
qpRSVPStyle: SE, WF qpRSVPStyle: FF
qpRSVPTrfcProf : {6 session Max} (repository reference) PolicyMeterInAction association to: Meter-2
qpRSVPMeter: Meter (repository reference)
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 qpRSVPMeterScope: interface
PolicyTrfcProfileInMeter association to: Prof-2
qosPolicyRSVPTrfcProf Prof-1:
qpRSVPTokenRate: 64kb/sec
qosPolicyRSVPTrfcProf Prof-2:
qpRSVPSessionNum: 5
The various attributes of RSVP traffic profiles are described in the The various attributes of RSVP traffic profiles are described in the
next section. next section.
4.8. Traffic Profiles 4.8. Meters and Traffic Profiles
The QoS Policy schema defines two categories of traffic profiles. Meters measure the a temporal state of a flow or a set of flows
against a traffic profile. In this document meters are modeled
by psPolicyMeter class, while traffic profiles are modeled by
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 Provisioning traffic profiles carry rate and burst parameters to be
compared with flow meters. RSVP traffic profiles are compared with RSVP compared with flow meters. RSVP traffic profiles are compared with
TSPEC and FLOWSPEC parameters, and with meters aggregating the temporal RSVPTSPEC and FLOWSPEC parameters, and with meters aggregating the
state of admitted RSVP reservations and states. temporal state of admitted RSVP reservations and states.
Traffic profiles can be kept in a repository for reusability. Traffic Snir, Ramberg, Strassner, Cohen expires May 2001 64
profiles can also be directly attached to actions.
4.8.1. Provisioning traffic profiles 4.8.1. Provisioning traffic profiles
Shaping, policing and remarking provisioning actions compare a Shaping, policing and remarking provisioning actions compare a
provisioning traffic profile against a meter. The provisioning traffic provisioning traffic profile against a meter. The provisioning traffic
profile is a template containing rate and burst values, modeled by the profile is a template containing rate and burst values, modeled
qosPolicyPRTrfcProf class. by the qosPolicyPRTrfcProf class.
The qosPolicyPRTrfcProf class includes the following properties: The qosPolicyPRTrfcProf class includes the following properties:
1. Rate measured in bits/sec. 1. Rate measured in kbits/sec.
2. Normal burst measured in bytes. 2. Normal burst measured in bytes.
3. Excess burst measured in bytes. 3. Excess burst measured in bytes.
Rate determines the long-term average transmission rate. Traffic that Rate determines the long-term average transmission rate. Traffic
falls under this rate will always conform. The normal burst size That falls under this rate will always conform. The normal burst size
determines how large traffic bursts can be before some traffic exceeds determines how large traffic bursts can be before some traffic
the traffic profile. The Excess Burst size determines how large traffic exceeds the traffic profile. The Excess Burst size determines how large
bursts can be before all traffic exceeds the rate limit. Traffic that traffic bursts can be before all traffic exceeds the rate limit.
falls between the normal burst size and the Excess Burst size exceeds Traffic
the traffic profile with a probability that increases as the burst size that falls between the normal burst size and the Excess Burst size
increases. This provides a Random Discard mechanism for policers, exceeds the traffic profile with a probability that increases as the
markers and shapers. burst size increases. This provides a Random Discard mechanism for
policers, markers and shapers.
Excess burst size SHOULD be greater than or equal to the normal burst Excess burst size SHOULD be greater than or equal to the normal
size. If the excess burst size is not specified, it is assumed that burst size. If the excess burst size is not specified, it is assumed
excess burst size is equal to the normal burst size. In this case, that excess burst size is equal to the normal burst size. In this
burst larger than the normal burst size will always be counted as out- case, burst larger than the normal burst size will always be counted
of-profile packets. as out-of-profile packets.
Snir, Ramberg, Strassner, Cohen expires October 2000 37 Snir, Ramberg, Strassner, Cohen expires May 2001 65
4.8.2. RSVP traffic profiles 4.8.2. RSVP traffic profiles
RSVP signaling QoS policy can condition the decision whether to accept RSVP signaling QoS policy can condition the decision whether to accept
or deny an RSVP request based on the traffic specification of the flow or deny an RSVP request based on the traffic specification of the flow
(TSPEC) or the amount of QoS resources requested (FLOWSPEC). The TSPEC (TSPEC) or the amount of QoS resources requested (FLOWSPEC). The TSPEC
and FLOWSPEC objects are either compared directly with a traffic and FLOWSPEC objects are either compared directly with a traffic
profile, or aggregated to a meter that measures the temporal admitted profile, or aggregated to a meter that measures the temporal admitted
RSVP states and than compared to the traffic specification. The RSVP states and than compared to the traffic specification. The
qosPolicyRSVPTrfcProf class models such a traffic profile. The qosPolicyRSVPTrfcProf class models such a traffic profile. The
qosPolicyRSVPTrfcProf class has the following properties: qosPolicyRSVPTrfcProf class has the following properties:
1. Token Rate (r) measured in bits/sec. 1. Token Rate (r) measured in bits/sec.
2. Peak Rate (p) measured in bits/sec. 2. Peak Rate (p) measured in bits/sec.
3. Bucket Size (b) measured in bytes. 3. Bucket Size (b) measured in bytes.
4. Min Policed unit (m) measured in bytes. 4. Min Policed unit (m) measured in bytes.
5. Max packet size (M) measured in bytes. 5. Max packet size (M) measured in bytes.
6. Resv Rate (R) measured in bits/sec. 6. Resv Rate (R) measured in bits/sec.
7. Slack term (s) measured in microseconds. 7. Slack term (s) measured in microseconds.
skipping to change at line 1952 skipping to change at line 3337
the FLOWSPEC slack term should not be smaller than that specified in the FLOWSPEC slack term should not be smaller than that specified in
the slack term. the slack term.
TSPECs as well as FLOWSPECs can be added. The sum of two TSPECs is TSPECs as well as FLOWSPECs can be added. The sum of two TSPECs is
computed by summing the rate r, the peak rate p, the bucket size b, and computed by summing the rate r, the peak rate p, the bucket size b, and
by taking the minimum of min policed unit m and the maximum of the max by taking the minimum of min policed unit m and the maximum of the max
packet size M. GS FLOWSPECs are summed by adding the Resv rate and packet size M. GS FLOWSPECs are summed by adding the Resv rate and
minimizing the slack term s. These rules are used to compute a meter minimizing the slack term s. These rules are used to compute a meter
that measures the temporal state of admitted RSVP states. The meter is that measures the temporal state of admitted RSVP states. The meter is
than compared with the traffic profile specified in the signaling than compared with the traffic profile specified in the signaling
Snir, Ramberg, Strassner, Cohen expires May 2001 66
policy using the same rules for comparison of TSPECs (FLOWSPECs) to a policy using the same rules for comparison of TSPECs (FLOWSPECs) to a
traffic profile. traffic profile.
Snir, Ramberg, Strassner, Cohen expires October 2000 38
5. Decision strategy 5. Decision strategy
The decision strategy to be used by policy servers and other policy Section 5.1 discusses how policy rules are organized into containers so
decision points in the network on a set of policies is defined by that decision strategies can be applied to groups of policy rules.
grouping policies into various qosNamedPolicyContainer groups, and Section 5.2 defines two different decision strategies. Section 5.3
using these groups to partition behavior in different QoS policy provides examples to illustrate how the different decision strategies
domains. In order to get a consistent behavior of different policy affect the policy rules they operate on.
servers using the same group of policy rules, the priority of the
policy rules must be pre-defined and the decision strategy implemented
by each different policy server must be defined explicitly.
The decision strategy is defined per domain and can be overridden per 5.1 Organizing the Application of Decision Strategies
qosNamedPolicyContainer. When a policy decision point evaluates a set
of rules, it implements the decision strategy defined in each container
of rules. Nested containers can override the decision strategy of their
containers.
The order of decision making of nested rules is defined by the This document recommends the following approach to be used by policy
combination of their internal priority, the priority of the policy rule servers and other policy decision points in the network for QoS
containing the nested rule and the priority of their containers. applications. The set of policies to be used is managed by first
Nested rules have a higher priority than their containing rule. assigning them to their respective policy domains or reusable-object
Priority is compared between rules and qosNamedPolicyContainers, as repositories. The policy rules will then be grouped into a set of
Defined in [PCIM]. The rule priority of PCIM is extended by introducing gpsPolicyGroup groups. The organization of these gpsPolicyGroup groups
the qpPriority (group priority) property of qosNamedPolicyContainer. 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.
Two decision strategies are defined: 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" 1. "FIRST MATCH"
2. "MATCH ALL" 2. "MATCH ALL"
5.1. First match 5.2.1. First Match Decision Strategy
The first match decision strategy is defined as a process that The first match decision strategy is defined as a process that
evaluates the policy rules in the defined order, evaluating the evaluates the policy rules in the defined order, evaluating the
conditions of each rule, until a condition is evaluated to TRUE. 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 rule's actions are then applied and the process of decision-making is
terminated. terminated.
5.2. Match All 5.2.2. Match All Decision Strategy
The match all decision strategy is defined as first scanning the The match all decision strategy is defined as first scanning the
complete set of rules according to their defined order of priority and complete set of rules according to their defined order of priority and
then applying the actions of each rule that the flow meets with the then applying the actions of each rule that satisfies the rule's
rule's conditions. This matching strategy may in many cases mean that a conditions. This matching strategy may in many cases mean that a
number of rules may meet the flow's parameters and all of their actions
will be applied. 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 A Match All strategy may result in applying conflicting rules. Handling
conflicts is outside the scope of this draft. The implementers of QoS conflicts is outside the scope of this draft. The implementers of QoS
systems must provide proprietary conflict detection and avoidance or systems must provide proprietary conflict detection and avoidance or
resolution mechanisms. resolution mechanisms to use this or any type of decision strategy that
allows the execution of more than one rule for a given condition.
Snir, Ramberg, Strassner, Cohen expires October 2000 39
5.3. Decision Strategy example 5.3. Decision Strategy example
This section demonstrates both decision strategies and rule This section demonstrates both decision strategies and rule
prioritization. The rules to be evaluated are shown in Figure 4 below. prioritization. The rules to be evaluated are shown in Figure 4 below.
Domain Domain
| |
+--Rule1 (priority 19) +--Rule1 (priority 19)
| |
+--NamedContainer1 (priority 5) +--PolicyContainer1 (priority 5)
| | | |
| +--Rule 1.1 (priority 3) | +--Rule 1.1 (priority 3)
| | | |
| +--Rule 1.2 (priority 33) | +--Rule 1.2 (priority 33)
| |
+--Rule3 (priority 4) +--Rule3 (priority 4)
| |
+--Rule4 (priority 2) +--Rule4 (priority 2)
Figure 4: Decision Strategy example Figure 4: Decision Strategy example
NOTE: rule nesting is not defined in PCIM, but rather is defined in This figure illustrates two extensions to PCIM. The first is that a
this document special type of PolicyGroup, the gpsPolicyGroup, can be assigned a
priority and have its priority compared to other PolicyRules and
5.3.1 Default Operation using First Match Everywhere gpsPolicyGroups. The second is rule nesting, as illustrated by Rule 3
and Rule 4.
For simplicity we assume that a Policy Decision Point needs to enforce The order of rule processing for the example above is:
all rules described above. Therefore, the rules will be evaluated in
the following order:
1. Rule1 (higher priority between Rule1, namedContainer1 and Rule3 1. Rule1 (higher priority between Rule1, PolicyContainer1 and Rule3
2. Rule1.2 (higher priority between Rule1.1 and Rule1.2) 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 3. Rule1.1 (because its container has a higher priority than Rule3
4. Rule4 (because it is nested in Rule 3) 4. Rule4 (because it is nested in Rule 3)
5. Rule3 5. Rule3
If the decision strategy of the domain is first match and it is not If the decision strategy of the domain is 'first-match' and it is not
overridden by NamedContainer1, the decision process will stop once a overridden by PolicyContainer1, the decision process will stop once a
rule's condition is matched. rule's condition is matched.
Note: this equates priority with order. This is very different than how Snir, Ramberg, Strassner, Cohen expires May 2001 69
this same example would work using priority as defined in [PCIM] (in
fact, this could not even be represented in [PCIM]). This is because of
the following two reasons:
- PCIM does not provide the ability to assign an order to a named
container. It therefore has no concept of ordering containers among
its policy rules
- PCIM has no concept of nested rules
Snir, Ramberg, Strassner, Cohen expires October 2000 40
5.3.2 Operation Using Other Decision Strategies
However, if the decision strategy of the domain is match all and it is If the decision strategy of the domain is 'match-all' and it is not
not overridden by NamedContainer1, the match all decision process will overridden by PolicyContainerr1, the match all decision process will
run over all rules according to the order above. run over all rules according to the order above.
If the decision strategy of the domain is first match and the decision If the decision strategy of the domain is 'first-match' and the
process of NamedContainer1 is match all, Rule1 will be evaluated decision process of PolicyContainer1 is match all, Rule1 will be
first. If its condition matches, the decision process stops. Else, evaluated first. If its condition matches, the decision process stops.
both Rules 1.1 and 1.2 will be evaluated and executed if their Else, both Rules 1.1 and 1.2 will be evaluated (because the priority of
conditions match. If one of NamedContainer1 rule match, the decision the named container is higher than the priority of Rule 3). However,
process stops. Else Rules 3 and 4 will be evaluated using first match since the decision strategy is overridden in the named container, one
decision strategy. 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
If the decision strategy of the domain is match all and the decision match, the decision process stops. Else Rules 3 and 4 will be evaluated
process of NamedContainer1 is first match, the decision process will using 'first-match' decision strategy.
evaluate Rule1 and continue to evaluate NamedContainer1 rules. Rules
1.1 and 1.2 will be evaluated using first match strategy. The decision
process continues to evaluate rules 3 and 4 according to match-all
decision strategy.
Snir, Ramberg, Strassner, Cohen expires October 2000 41 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 6. Per Hop Behavior
A per-hop behavior (PHB) is a description of the externally observable A per-hop behavior (PHB) is a description of the externally
forwarding behavior of a DS node applied to a particular DS behavior observable forwarding behavior of a DS node applied to a particular DS
aggregate. A PHB is selected at a node by the DSCP in a received Behavior aggregate. A PHB is selected at a node by the DSCP contained
packet. A set of PHBs is enforced on a QoS domain. The set of PHBs in a received packet. A set of PHBs is enforced on a QoS domain.
share buffer and scheduler resources among them. The QPIM provides The set of PHBs share buffer and scheduler resources among them.
abstract placeholders for PHBs and for a set of PHBs enforced together QPIM provides the means for defining a set of PHBs per qos
on a QoS domain. Further specification of PHBs and PHB sets are outside domain by definition of a gpsPolicyGroup that includes a set of
the scope of this document; please refer to [PHBSET] for more PHB rules. Each of this rules would classify packets based on DSCP
information. value and define the action to be performed on this qos Class.
PHB sets can be defined as reusable objects in the policy
6.1. PHBs reusable-object repository to allow different domains to share
the same per hop behavior.
The qosPolicyPHB abstract class models a single PHB. The qosPolicyPHB
class includes a single property, the DSCP value, which is an integer
with allowed values in the range of 0 to 63, inclusive. The
qosPolicyPHB name will be defined using the cn property belonging
to the Policy class [PCIM].
6.1. PHB Sets
The qosPolicyPHBSet abstract class serves as a named container for
instances of qosPolicyPHB classes. It models the set of PHBs enforced
together on a QoS domain. Different PHB sets can be kept in a
repository. A PHB set enforced on the domain is specified by either a
reference from the qosPolicyDomain class to one of the PHB sets that
are located in the reusable-object repository, or by directly including
the PHB set in the domain (the method for doing this is repository-
specific; for example, attachment could be used if the repository is a
directory).
To fine tune PHB parameters and to further restrict the namespace in
which a particular PHB is used, PHB sets can be referenced or augment
the semantics of qosNamedPolicyContainers. However, in order to
maintain an end-to-end consistent behavior, overriding the domain's PHB
set should be done only to fine tune the parameters of each PHBs, and
not to use a different set of PHBs altogether.
Markers coloring packets of flows on domain ingress edges should pick a
DSCP selecting one of the PHBs enforced on the QoS domain.
Snir, Ramberg, Strassner, Cohen expires October 2000 42 Snir, Ramberg, Strassner, Cohen expires May 2001 70
7. QoS Policy Class Inheritance 7. QoS Policy Class Inheritance
The following diagram illustrates the class hierarchy for the QPIM. The following diagram illustrates the class hierarchy for the
Relevant classes from the PCIM are also included for completeness: QPIM. Relevant classes from the PCIM are also included for
completeness:
top top
| |
+--policy (abstract, [PCIM]) +--policy (abstract, [PCIM])
| | | |
| +--policyGroup ([PCIM]) | +--policyGroup ([PCIM])
| | | | | |
| | +--qosPolicyDomain | | +--qosPolicyDomain
| | | | | |
| | +--qosNamedPolicyContainer | | +--gpsPolicyGroup
| | | |
| +--policyRule ([PCIM]) | +--policyRule ([PCIM])
| | | |
| +--policyCondition ([PCIM]) | +--policyCondition ([PCIM])
| | | | | |
| | +--policyTimePeriodCondition ([PCIM]) | | +--policyTimePeriodCondition ([PCIM])
| | | | | |
| | +--vendorPolicyCondition ([PCIM]) | | +--vendorPolicyCondition ([PCIM])
| | | | | |
| | +--qosPolicySimpleCondition | | +--gpsPolicySimpleCondition
| | |
| | +--gpsPolicyCompoundCondition
| | | |
| +--policyAction | +--policyAction ([PCIM])
| | | | | |
| | +--vendorPolicyAction ([PCIM]) | | +--vendorPolicyAction ([PCIM])
| | |
| | +-- qosPolicyPRAction | | +-- qosPolicyPRAction
| | | | | |
| | +-- qosPolicyPHBAction
| | |
| | +-- qosPolicyRSVPAction | | +-- qosPolicyRSVPAction
| | | | | |
| | +-- qosPolicyRSVPSignalCtrlAction | | +-- qosPolicyRSVPSignalCtrlAction
| | | | | |
| | +-- qosPolicyRSVPInstallAction | | +-- qosPolicyRSVPInstallAction
| | | |
| +--qosPolicyVariable | +--gpsPolicyVariable
| | | |
| +--qosPolicyValue(abstract) | +--gpsPolicyValue(abstract)
| | |
| | +--qosPolicyIPv4AddrValue
| | |
| | +--qosPolicyIPv6AddrValue
| | | | | |
| | +--qosPolicyMACAddrValue | | +--gpsPolicyIPv4AddrValue
| | | | | |
| | +--qosPolicyStringValue | | +--gpsPolicyIPv6AddrValue
| | | | | |
| | +--qosPolicyBitStringValue
| | | | | |
(Diagram continued in next page) (diagram continued in next page)
Snir, Ramberg, Strassner, Cohen expires October 2000 43
(Diagram continued from previous page) Snir, Ramberg, Strassner, Cohen expires May 2001 71
(continued from the previous page)
top top
| | +--gpsPolicyMACAddrValue
| | |
| | +--gpsPolicyStringValue
| | |
| | +--gpsPolicyBitStringValue
| | |
| |
+--policy (abstract, [PCIM]) +--policy (abstract, [PCIM])
| | | |
| +--qosPolicyValue(abstract, continued from previous page) | +--gpsPolicyValue (abstract)
| | | | | |
| | +--qosPolicyDNValue | | +--gpsPolicyDNValue
| | | | | |
| | +--qosPolicyAttributeValue | | +--gpsPolicyAttributeValue
| | | | | |
| | +--qosPolicyIntegerValue | | +--gpsPolicyIntegerValue
| | | |
| +-- qosPolicyMeter | +-- gpsPolicyMeter
| | | |
| +-- qosPolicyPRTrfcProf | +-- qosPolicyQueue
| | | |
| +-- qosPolicyRSVPTrfcProf | +-- gpsPolicyTrfcProf
| | | |
| +-- qosPolicyPHBSet (abstract) | +-- qosPolicyPRTrfcProf
| | | |
| +-- qosPHB (abstract) | +-- qosPolicyRSVPTrfcProf
|
| |
+--CIM_ManagedSystemElement (abstract) +--CIM_ManagedSystemElement (abstract)
| |
+--CIM_LogicalElement (abstract) +--CIM_LogicalElement (abstract)
| |
+--CIM_System (abstract) +--CIM_System (abstract)
| |
+---CIM_AdminDomain (abstract) +---CIM_AdminDomain (abstract)
| |
+---PolicyRepository +---PolicyRepository
Figure 5. Class Inheritance Hierarchy for the QPIM Figure 5. Class Inheritance Hierarchy for the QPIM
The reader is encouraged to read section 7 of [PCIM] in its entirety, The reader is encouraged to read section 6 and section 7 of [PCIM] in
which defines the concepts of associations and aggregations. Ten their entirety. Section 6 defines all of the object classes listed
associations and aggregations are defined in the [PCIM]; note that the above, and section 7 defines the concepts of associations and
QPIM does not define any new associations or aggregations: 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 PolicyGroupInPolicyGroup
the Aggregation PolicyRuleInPolicyGroup the Aggregation PolicyRuleInPolicyGroup
the Aggregation PolicyConditionInPolicyRule the Aggregation PolicyConditionInPolicyRule
the Aggregation PolicyRuleValidityPeriod the Aggregation PolicyRuleValidityPeriod
the Aggregation PolicyActionInPolicyRule the Aggregation PolicyActionInPolicyRule
the Association PolicyConditionInPolicyRepository the Association PolicyConditionInPolicyRepository
the Association PolicyActionInPolicyRepository the Association PolicyActionInPolicyRepository
the Weak Aggregation PolicyGroupInSystem the Weak Aggregation PolicyGroupInSystem
the Weak Aggregation PolicyRuleInSystem the Weak Aggregation PolicyRuleInSystem
the Aggregation PolicyRepositoryInPolicyRepository the Aggregation PolicyRepositoryInPolicyRepository
Snir, Ramberg, Strassner, Cohen expires October 2000 44 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. Class Definitions
8.1. Class qosPolicyDomain 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 PolicyConditionInCompo