One document matched: draft-ietf-policy-qos-info-model-02.txt
Differences from draft-ietf-policy-qos-info-model-01.txt
Policy Framework Y. Snir
Internet Draft Y. Ramberg
Expires May 2001 J. Strassner
draft-ietf-policy-qos-info-model-02.txt R. Cohen
November 2000 Cisco Systems
Policy Framework QoS Information Model
Status of this Memo
This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
This document presents an object-oriented information model for
representing network QoS policies. This document is based on the IETF
Policy Core Information Model as specified by [PCIM]. This draft
refines the concept of generic policy rules, conditions and actions
defined in [PCIM] in order to define extensions necessary for
representing IntServ and DiffServ QoS policies. It also provides
refinement of additional concepts that are important for building rule-
specific as well as reusable QoS policy rules.
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
information model, which by definition is independent of any particular
data storage mechanism and access protocol. Companion documents (e.g.,
[QoSSCHEMA]) define the mapping of these classes to specific data
models (schemata).
Snir, Ramberg, Strassner, Cohen expires May 2001 1
Draft-ietf-policy-qos-info-model-02.txt November 2000
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
1. Introduction 6
1.1 Goals 7
1.2 Approach and Related Documents 7
2. Information Model Hierarchy 8
2.1 Interaction Between the PCIM and This Document 8
2.1.1. Extension of Concepts in the PCIM 8
2.1.1.1 Hierarchical Policy Repositories 9
2.1.1.2 Extensions to Reusable Objects 9
2.1.1.3 Extensions to the Structure of a Policy Rule 9
2.1.2 Addition of New Concepts Not in the PCIM 9
2.1.2.1 Rule Nesting 9
2.1.2.2 Rule Decision Strategy 10
2.1.2.3 Compound Conditions 10
2.1.2.4 Pre-Defined Variables and Constants 10
2.1.2.5 Per-Hop Behaviors 11
2.1.3 Mapping to a Directory 11
2.2 High-Level Class Hierarchy 11
3. QPIM Hierarchies 13
3.1. Class and Relationship Hierarchies Defined in the QPIM 14
3.2. Implementation Guidelines 15
3.2.1 Modeling Containment 16
3.2.2. Implementing Relationships 17
3.2.2.1. Relationship modeling 17
3.2.2.2. Representing Containment in a Consistent Manner 18
3.2.3. Mapping Differences and Examples 18
3.3. QoS Domain Data Tree 19
3.4. Types of Grouping Classes 22
3.5. QoS Policy Domain Grouping and Nesting 23
3.6. Resource Sharing 25
3.7. Instance Location 26
3.8. Policy Containers 27
3.8.1 Semantics of a gpsPolicyGroup 27
3.8.2 Priority and Decision Strategy Applied to Containers 29
3.8.3 Sharing Policy Containers 30
3.9 Policy Roles associated with gpsPolicyGroup 31
3.10 Policy Rules 32
3.11 Conditions and Actions 33
3.12 Data Tree Example 33
3.13 Reusable-Object Repositories 34
3.14 Relationships Between QoS Domains and Repositories 35
Snir, Ramberg, Strassner, Cohen expires May 2001 2
Draft-ietf-policy-qos-info-model-02.txt November 2000
4. Constructing a QoS Policy Rule 36
4.1 Policy Rule Structure 36
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
4.8 Meters and Traffic Profiles 64
4.8.1 Provisioning Traffic Profiles 65
4.8.2 RSVP Traffic Profiles 66
5. Decision strategy 67
5.1 Organizing the Application of Decision Strategies 67
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 70
7. QoS Policy Class Inheritance 71
8. Class Definitions 75
8.1 The Aggregation "PolicyGroupInPolicyRule" 75
8.1.1. The Reference "GroupComponent" 75
Snir, Ramberg, Strassner, Cohen expires May 2001 3
Draft-ietf-policy-qos-info-model-02.txt November 2000
8.1.2. The Reference "PartComponent" 75
8.2 The Aggregation "PolicyRuleInPolicyRule" 76
8.2.1. The Reference "GroupComponent" 76
8.2.2. The Reference "PartComponent" 76
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
Snir, Ramberg, Strassner, Cohen expires May 2001 4
Draft-ietf-policy-qos-info-model-02.txt November 2000
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
Snir, Ramberg, Strassner, Cohen expires May 2001 5
Draft-ietf-policy-qos-info-model-02.txt November 2000
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
9. Extending the QoS Policy Schema 111
9.1. Extending gpsPolicyValue 111
9.2. Extending gpsPolicySimpleCondition 111
9.3. Extending qosPolicyAction 111
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
This document presents an object-oriented information model for
representing network QoS policies. As such, it is independent of any
specific data storage mechanism and access protocol. This document is
based on the IETF Policy Core Information Model as specified by [PCIM].
Specifically, this draft refines the concept of generic policy rules,
conditions and actions to cover extensions necessary for representing
IntServ and DiffServ QoS policies.
Snir, Ramberg, Strassner, Cohen expires May 2001 6
Draft-ietf-policy-qos-info-model-02.txt November 2000
This information model covers Differentiated Service QoS enforcement,
and Integrated Service QoS enforcement via policy control on RSVP
admission. Companion documents (e.g., [QoSSCHEMA]) define the mapping
of these classes to specific data models (schemata). For example,
[QoSSCHEMA] defines how to map the data in this information model to a
form that can be stored in a directory that uses LDAPv3 as its access
protocol.
1.1 Goals
This document defines a set of classes that can be used to build high
level policies that can be used to configure and enforce consistent QoS
behavior across a network. Specifically, the policies defined in this
document can be used to control and manage different vendor-specific
device mechanisms that are used to build different IntServ and DiffServ
QoS behaviors. The purpose of introducing a standard information model
is to allow interoperability between policy servers, policy management
applications, and network devices.
This document solves two problems. First, different devices have
different capabilities, and may respond differently to the same high-
level policy rule. This document solves this problem by defining a set
of common abstractions that can be used to build high-level QoS
policies. These high-level QoS policies control and manage low-level
QoS device mechanisms independent of the specific type of device that
is being managed. This enables different devices to use the same low-
level abstractions of mechanisms to implement QoS services, which are
controlled by the QoS policy rules defined in this document.
Second, different policy servers and applications may provision parts
of the network differently if no common high-level policy description
exists. This document defines a standard information model that
provides common definitions and semantics to be assigned to build,
interpret and enforce high-level policy rules.
1.2 Approach and Related Documents
The information model presented in this document contains information
that can be shared by other network policy managers (e.g., Security
managers, IP address managers, and others). Examples include sharing of
the same definition of well-known application port numbers, IP
addresses of servers and other network attributes. It allows checking
of consistent behaviors of the interaction between the different
managers by comparing, for example, the set of QoS and security actions
enforced on the same set of flows.
The remainder of this document presents, describes and defines the
QoS Policy Information Model (QPIM). QPIM is a set of entities and
relationships (both modeled by classes) that define managed objects and
Snir, Ramberg, Strassner, Cohen expires May 2001 7
Draft-ietf-policy-qos-info-model-02.txt November 2000
interactions between managed objects that can be used to define,
manage, and control IntServ and DiffServ QoS mechanisms using policies.
It uses basic concepts defined in [PCIM] but extends those to control
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
This section discusses the relationships between the Policy Core
Information Model [PCIM], the QoS Policy Information Model (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
conventions and nomenclature common to all types of policies. The
fundamental purpose of the [PCIM] is to provide a generic
representation of the structure of a policy rule, along with a set of
classes and relationships that can serve as a common representation of
policy groups, rules, conditions, and actions. This enables derived
information models and schemata to use a common set of terminology,
classes, and approaches, thus facilitating interoperability.
The QPIM refines and extends the concepts of the [PCIM] by introducing
a framework of classes and relationships dedicated to model IntServ and
DiffServ QoS Policies. This set of classes and relationships can be
used to configure and manage devices that are compliant with either the
integrated services [Intserv] and/or with the differentiated service
approach [Diffserv].
2.1.1 Extension of Concepts in the PCIM
The QPIM extends three fundamental concepts defined in [PCIM] in order
to be able to define policies that can control, manage and provision
the QoS mechanisms of devices. These are hierarchical policy
repositories, extensions to reusable objects, and extensions to the
structure of a policy rule.
Snir, Ramberg, Strassner, Cohen expires May 2001 8
Draft-ietf-policy-qos-info-model-02.txt November 2000
2.1.1.1 Hierarchical Policy Repositories
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.
2.1.1.2 Extensions to Reusable Objects
Similarly, the concepts of reusable objects vs. rule-specific objects
have been moved from an earlier version of this document to the [PCIM].
In addition, this document defines specific extensions to guide the
implementation of reusable- vs. rule-specific QoS objects.
2.1.1.3 Extensions to the Structure of a Policy Rule
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
There are several notable new concepts that are not part of the [PCIM].
These include rule nesting, rule decision strategy, compound
conditions, pre-defined variables and constants, and Per Hop Behavior
definition, as part of the QoS actions.
2.1.2.1 Rule Nesting
The [PCIM] defines the ability to group policy rules by defining the
policyGroup class. This class can be used to contain a set of
policyRules and/or a set of policyGroups. This grouping mechanism
allows for constructing a flexible and extensible information model.
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.
Snir, Ramberg, Strassner, Cohen expires May 2001 9
Draft-ietf-policy-qos-info-model-02.txt November 2000
Therefore, this document adds the concept of nesting one or more policy
rules within a policy rule. For example, one could think of a policy
rule that controls how a user logs onto the network as consisting of
two parts. A high-level rule is used to group together a set of lower-
level rules that are invoked at various stages of processing (e.g., how
the user is authenticated, how the IP Address is assigned, etc.). 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
need for a decision strategy to be used to define the order of
processing of these rules. However, since QPIM allows for nested rules,
different examples of decision strategies must be defined in this
document and shown that they can work in this new environment. This
document defines two such decision strategies: match-first and match-
all. Both define an ordering that can be applied to a set of
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
for use with QoS policies. This concept is not present in the [PCIM]
Snir, Ramberg, Strassner, Cohen expires May 2001 10
Draft-ietf-policy-qos-info-model-02.txt November 2000
because the purpose of the [PCIM] is to provide a general structure for
representing policy rules, conditions and actions. Variable and
constant definitions represent specific concepts that have pre-defined
semantics.
This version of this draft has these elements residing in this draft.
However, they have been generalized so that other applications besides
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
The following diagram shows how the classes in this document relate to
the classes defined in the PCIM.
Snir, Ramberg, Strassner, Cohen expires May 2001 11
Draft-ietf-policy-qos-info-model-02.txt November 2000
[unrooted]
|
+--Policy (abstract, defined in PCIM)
| |
| +---PolicyGroup (PCIM)
| | |
| | +---qosPolicyDomain (this document)
| | |
| | +---gpsPolicyGroup (this document)
| |
| +---PolicyRule (PCIM)
| |
| +---PolicyCondition (abstract, defined in PCIM)
| | |
| | +---PolicyTimePeriodCondition (PCIM)
| | |
| | +---VendorPolicyCondition (PCIM)
| | |
| | +---gpsPolicySimpleCondition (this document)
| | |
| | +---gpsPolicyCompoundCondition (this document)
| |
| +---PolicyAction (abstract, defined in PCIM)
| | |
| | +---VendorPolicyAction (PCIM)
| | |
| | +---qosPolicyPRAction (this document)
| | |
| | +---qosPolicyPHBAction (this document)
| | |
| | +---qosPolicyRSVPAction (this document)
| | |
| | +---qosPolicyRSVPSignalCtrlAction (this document)
| | |
| | +---qosPolicyRSVPInstallAction (this document)
| |
| +---gpsPolicyTrfcProf (this document)
| | |
| | +---qosPolicyPRTrfcProf (this document)
| | |
| | +---qosPolicyRSVPTrfcProf (this document)
| |
| +---gpsPolicyVariable (abstract, this document)
| |
| +---gpsPolicyValue (abstract, this document)
| | |
| | +---gpsPolicyIPv4AddrValue (this document)
| | |
| | +---gpsPolicyIPv6AddrValue (this document)
(continued on next page)
Snir, Ramberg, Strassner, Cohen expires May 2001 12
Draft-ietf-policy-qos-info-model-02.txt November 2000
(continued from previous page)
[unrooted]
|
+--Policy (abstract, defined in PCIM, repeated for convenience)
| |
| +---gpsPolicyValue (this document, repeated for convenience)
| | |
| | +---gpsPolicyMACAddrValue (this document)
| | |
| | +---gpsPolicyStringValue (this document)
| | |
| | +---gpsPolicyBitStringValue (this document)
| | |
| | +---gpsPolicyDNValue (this document)
| | |
| | +---gpsPolicyAttributeValue (this document)
| | |
| | +---gpsPolicyIntegerValue (this document)
| |
| +---gpsPolicyMeter
| |
| +---qosPolicyQueue
| |
+--CIM_ManagedSystemElement (abstract, defined in PCIM)
|
+--CIM_LogicalElement (abstract, defined in PCIM)
|
+--CIM_System (abstract, defined in PCIM)
|
+---CIM_AdminDomain (abstract, defined in PCIM)
|
+---PolicyRepository (PCIM)
3. QPIM Hierarchies
QPIM, following the information organizational paradigm of [PCIM], is
an object-oriented information model. As in [PCIM], this model defines
two hierarchies of object classes: structural classes representing
policy information and control of policies, and relationship classes
that indicate how instances of the structural classes are related to
each other.
In the rest of this section, we describe the organization and structure
of the QPIM hierarchies. Section 3.1 expands the previous paragraph and
describes the inheritance and relationship hierarchies that are used in
the construction of the QoS information hierarchies. Section 3.2
describes how the different information hierarchies can be used to
build the desired information hierarchies of the policy application.
Snir, Ramberg, Strassner, Cohen expires May 2001 13
Draft-ietf-policy-qos-info-model-02.txt November 2000
Section 3.3 describes the structure of the reusable objects repository.
Finally, section 3.4 explains the relationships between the domain data
tree and the reusable-object repositories.
3.1 Class and Relationship Hierarchies Defined in the QPIM
The QPIM consists of two hierarchies: an inheritance hierarchy that is
used to define a set of classes that represent entities in the managed
policy environment, and a relationship hierarchy that is used to define
a hierarchy of relationships that describe how different objects
interact with each other. These hierarchies work together to describe
entities in the managed environment and how they relate to and interact
with each other.
Two relationship constructs are used in the formal presentation of
QPIM. The first is an association, which models different types of
dependency relationships between two (or theoretically more) objects.
The second is an aggregation, which is a strong form of association
that typically represents a "whole-part" or a "containment"
relationship.
Both associations and aggregations are modeled as classes that contain
references to the objects that are participating in the relationship.
In addition, both associations and aggregations can be defined between
classes without affecting any of the related classes. That is, the
addition of either an association or an aggregation does not affect the
function or structure of the related classes.
Note that containment is a directional relationship - the containing
entity is known as the aggregate (the "whole" side of the
relationship), and the contained entities are known as the components
(the "part of" side of the relationship). For example, the relationship
between a policy container (e.g., gpsPolicyGroup, which is defined in
this document as a subclass of PolicyGroup, which is defined in [PCIM])
and the rules it contains (e.g., PolicyRule, which is defined in
[PCIM]) is modeled by an aggregation (PolicyRuleInPolicyGroup, which is
defined in [PCIM]). However, the association between a reusable object
and the repository in which it resides models a "resides-in"
relationship rather than "part-of" relationship. This is because a
given reusable object can reside in any repository according to the
discretion of the administrator - there is no whole-part relationship
connoted by placing a reusable object in a repository. Rather, there is
only a dependency relationship that states that in order to find the
given reusable object, you must look in this particular repository. On
the other hand, there is a whole-part relationship established when a
policy container, such as a PolicyGroup or a gpsPolicyGroup, is used to
contain a particular PolicyRule. Now, we are adding specific semantics
that say that a particular PolicyRule is-a-part-of a given policy
container.
Snir, Ramberg, Strassner, Cohen expires May 2001 14
Draft-ietf-policy-qos-info-model-02.txt November 2000
Relationship classes may be used to extend the semantics of the
relationship beyond the basic containment or reference concepts. For
example, a relationship class may contain added attributes that add
particular semantics. For example, the PolicyConditionInPolicyRule
aggregation defines the relationship between a PolicyRule and a set of
policy conditions (PolicyCondition, defined in [PCIM]). In this case,
the PolicyRule acts as a container, and can hold zero or more
PolicyConditions (which are the contained objects). Since this is
expressing a whole-part relationship, it is modeled as an aggregation.
However, this aggregation class carries two additional properties:
GroupNumber and ConditionNegated. These properties are used to add to
the relationship itself the semantics of sub-grouping of conditions and
whether to prepend a Boolean 'NOT' operator to the condition.
Implementers of a particular QoS Policy system may further sub-class
relationships to incorporate additional application-specific semantics
as required.
Comprehensive presentation of relationships and their modeling is
available in [PCIM].
Two important examples of using aggregation are composition and
scoping. An example of composition is the PolicyRule. It has its own
attributes, but it is only complete when it is used in conjunction with
a set of conditions and actions. Conceptually, a PolicyRule serves as a
container that aggregates a set of PolicyCondition objects and a set of
PolicyAction objects. An example of scoping is grouping objects under a
single container (e.g., qosPolicyDomain) so that common administrative
rules can be applied to all of the objects in a container.
3.2 Implementation Guidelines
The QPIM defines two information hierarchies. Objects that are to be
managed are represented by the classes in the inheritance hierarchy.
Behavior that is to be represented and managed is represented by the
classes in the relationship hierarchies. An implementation is not
complete if just the class inheritance hierarchy is implemented - both
hierarchies MUST be implemented.
Many data storage technologies are incapable of directly representing
relationships. However, all data storage mechanisms of interest can
either emulate relationships or have specific constructs that can
implement some, but not all, relationships. For example, an LDAP based
directory does not have the concept of a general dependency
relationship (although one can be implemented in a variety of ways),
but it does have the concept of a containment relationship.
In general, an implementation will define two types of information. The
first type of information is policy definition data. This information
consists of policy rules and groups, and the components of policy
Snir, Ramberg, Strassner, Cohen expires May 2001 15
Draft-ietf-policy-qos-info-model-02.txt November 2000
rules, that are used to govern the application of policies to manage
entities. The second type of information is a set of nested containers
that form a hierarchy for storing and managing reusable objects.
For applications that want to manage and control QoS, containers
provide significant convenience benefits. Containers can be used to
group similar policies and policy information together in order to make
the policy data easier to manage. They also enable an organization to
impose its own views of organizing policies and policy information in
the data store. This is done in QPIM by enabling a single monolithic
repository to be conceptually divided into a set of repositories that
reflect the administrative use of the policies. To this end, the QPIM
not only supports the use of containers for grouping information, but
also for determining execution semantics of policy rules.
3.2.1 Modeling Containment
Containment is a general concept that is expressed in an information
model using either an association or (more usually) an aggregation.
Different data stores have different characteristics (e.g., data
structures, organization of data, and access protocols). Therefore,
there will be many mappings from a single information model, one for
each type of data store. This means that containment may be expressed
differently in each mapping. However, this document makes no explicit
or implicit assumptions about the storage mechanism, access protocol,
or other characteristics of different data stores. The information
model presented here can be mapped to most storage mechanisms and
models, such as LDAP directories, relational DBMS, SMI, and others.
For example, the basic mechanism used for expressing containment when
mapping to a directory is placement of the objects in the data tree. To
express the relationship of "container - contained" between a container
object and the objects it contains, the contained objects are placed
below the container object. In a relational database system, on the
other hand, this relationship may be implemented by means of various
key/foreign-key join mechanisms.
In QPIM (as well as in [PCIM]) an object may be related to its
container in one of two ways. We refer to these methods as "ad-hoc"
containment and "indirect" containment, as follows:
1. To establish ad-hoc containment the object is created and is
associated to its container by means of an instance of the
appropriate aggregation class.
2. To establish indirect containment the object is created and placed
in a reusable-object repository The contained object must be given a
unique name that is scoped by the containing repository. The
instance of the aggregation class must now contain a reference to
the reusable object.
Snir, Ramberg, Strassner, Cohen expires May 2001 16
Draft-ietf-policy-qos-info-model-02.txt November 2000
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
Draft-ietf-policy-qos-info-model-02.txt November 2000
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
Draft-ietf-policy-qos-info-model-02.txt November 2000
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
Draft-ietf-policy-qos-info-model-02.txt November 2000
+---------------+
|qosPolicyDomain| (root of the data hierarchy)
+---------------+
| +----------+
|-->|policyRule| (a)
| +----------+
| | +------------------------+
| |-->|gpsPolicySimpleCondition| (b)
| | +------------------------+
| | +--------------------------+
| |-->|gpsPolicyCompoundCondition| (b)
| | +--------------------------+
| | | +------------------------+
| | |-->|gpsPolicySimpleCondition| (c)
| | | +------------------------+
| | | +--------------------------+
| | |-->|gpsPolicyCompoundCondition| (d)
| | +--------------------------+
| | +---------------+
| |-->|qosPolicyAction| (e)
| | +---------------+
| | +----------+
| |-->|policyRule| (f)
| | +----------+
| | +--------------+
| |-->|gpsPolicyGroup| (g)
| +--------------+
| +--------------+
|-->|gpsPolicyGroup| (h)
| +--------------+
| | +----------+
| |-->|PolicyRule| (i)
| | +----------+
| | +--------------+
| |-->|gpsPolicyGroup| (j)
| +--------------+
| +---------------+
|-->|qosPolicyDomain| (k)
+---------------+
Figure 1: Qos Domain Data Tree Hierarchy
Explanation to the relationships defined in figure 1:
a - Any number of PolicyRule instances may be contained by a given
qosPolicyDomain instance in the hierarchy by using the
PolicyRuleInPolicyGroup aggregation. This has the effect of making such
policyRules global for that container. Finer granularity can be
obtained by either nesting qosPolicyDomain instances (shown in
relationship (k)), or by embedding other types of containers (e.g.,
Snir, Ramberg, Strassner, Cohen expires May 2001 20
Draft-ietf-policy-qos-info-model-02.txt November 2000
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
Draft-ietf-policy-qos-info-model-02.txt November 2000
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
Draft-ietf-policy-qos-info-model-02.txt November 2000
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
Draft-ietf-policy-qos-info-model-02.txt November 2000
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
classes of service to different organizations within a single
enterprise. In this example, the enterprise is represented by an
instance of the PolicyGroup class. The different organizations are each
represented by a separate QoS policy domain (which is an instance of
the qosPolicyDomain class). Each qosPolicyDomain class is used as a
container to hold all of the policies for a given portion of the
organization. In Figure 2, this level is represented by the nesting
level of qosPolicyDomain classes that constitute the hierarchy of
container classes shown in Figure 2.
Each qosPolicyDomain instance serves as a container that contains an
ordered list of related QoS policy rules that apply to a different part
or function of the domain (e.g., Eastern Sales vs. Western Sales). This
grouping is done using instances of the gpsPolicyGroup class.
The gpsPolicyGroup class would in turn contain either a set of
PolicyRule instances, a set of PolicyGroup instances (to provide
further grouping of policy rules that are scoped by a given
gpsPolicyGroup), or both.
Snir, Ramberg, Strassner, Cohen expires May 2001 24
Draft-ietf-policy-qos-info-model-02.txt November 2000
+-------------+
|policyGroup | <------------------- QoS policies for an enterprise
+-------------+
|
| +---------------+
-->|qosPolicyDomain| <----------- QoS policies for the Sales group
+---------------+
|
| +---------------+
|-->|qosPolicyDomain| <-------- QoS policies for Western Sales
| +---------------+
| |
| | +--------------+
| |-->|gpsPolicyGroup| <--Qos Policies for group
| | +--------------+ A within Western Region
| |
| | +--------------+
| -->|gpsPolicyGroup| <--Qos Policies for group
| +--------------+ B within Western Region
|
| +---------------+
-->|qosPolicyDomain| <--------QoS policies for Eastern Sales
+---------------+
|
| +--------------+
|-->|gpsPolicyGroup| <--Qos Policies for group
| +--------------+ C within Eastern Region
|
| +--------------+
-->|gpsPolicyGroup| <--Qos Policies for group
+--------------+ D within Eastern Region
Figure 2: Top-level Policy Data Tree Example
The modeling approach used in the previous example is but one possible
strategy among many. This information model allows for arbitrary
nesting of containers, groups and rules, thus providing the means for
modeling both wide and deep policy hierarchies.
3.6. Resource Sharing
Object instances residing in different branches of the data tree
are independent of each other. That is, there is no cross-referencing
among objects located in different QoS policy domains. However,
multiple QoS policy domains may still share data by using a special
mechanism. This mechanism is called referencing reusable objects. A
reusable object is an object that is placed in a special portion of the
data store dedicated to sharing information among multiple clients that
Snir, Ramberg, Strassner, Cohen expires May 2001 25
Draft-ietf-policy-qos-info-model-02.txt November 2000
wish to access the same information. In fact, there may be multiple
such repositories, each used for collecting a different set of related
reusable objects. In this document, we will call such repositories
reusable-object repositories. (Note that [PCIM] refers to this object
as a PolicyRepository; we are using the term "reusable-object
repository" to emphasize the fact that this is a special "repository-
in-a-repository" for containing reusable objects).
The sharing of global or common objects enhances the interoperability
of various policy applications, thus serving the primary goal of this
information model. Such commonly used building blocks as PolicyGroup
and its subclasses (e.g., gpsPolicyGroup and qosPolicyDomain),
subclasses of PolicyCondition (e.g., qpsPolicySimpleCondition and
gpsPolicyCompoundCondition)and PolicyAction (e.g., qosPolicyPRAction
and qosPolicyRSVPAction), as well as lower-level objects (e.g.,
instances of qpsPolicyVariable and qpsPolicyValue) can be placed in the
reusable-object repository and used by multiple policy rules from
multiple domains.
Both the PCIM and the QPIM do not restrict the number of reusable-
object repositories that can be referenced from a single domain. Even a
single instance of a policy rule may contain references to objects
residing in more than one repository. It is important to note that the
QPIM does not dictate a QoS domain-wide scope for reusable objects, so
as to keep this concept as general as possible.
3.7. Instance Location
The purpose of the QPIM is to define a flexible structure of
information that does not pre-impose harsh restrictions on building the
data tree. When a data tree is derived from the QPIM, it is important
to ensure that this derivation is as free of restrictions as possible.
Although each data store has its own special considerations to be taken
into account, one of the most important considerations in mapping for
directories concerns placement of entries. The QPIM MUST NOT contain
any hidden assumptions about the placement of particular QoS policy
domain hierarchies (including, for that matter, placement of reusable-
object repositories as explained in section 3.13 below). Consequently,
the QPIM does not require any pre-defined locations for the portion of
the data tree that is dedicated to policy. An instance of the global
data tree (a corporate directory, for example) may in fact contain
several QoS policy domains that exist within the global date tree in
various places. Zero or more reusable-object repositories may also be
present in the global data tree.
In addition, the QPIM does not dictate any standard organization of
objects to be controlled via policy, either for QoS policy classes and
relationships or for reusable-object repositories that are used by QoS
applications.
Snir, Ramberg, Strassner, Cohen expires May 2001 26
Draft-ietf-policy-qos-info-model-02.txt November 2000
The only location/organizational rule that must be followed is:
Each QoS policy domain must contain complete policy information that
is necessary to describe that particular policy domain. Reusable
objects SHOULD be placed in one or more reusable-object repositories
and referenced by one or more objects that exist in the QoS policy
domain, as appropriate. Note specifically that there is no
requirement for reusable objects to be placed in the policy domain
itself. Furthermore, reusable objects MUST be referenced using the
properties defined in the appropriate [PCIM] and QPIM classes.
3.8. Policy Containers
A QoS policy domain is a container that provides scoping for QoS policy
containers, policy rules, and other policy information, as mentioned
previously. There are two information model class that are used to
represent QoS policy containers: the qosPolicyDomain and the
gpsPolicyGroup classes. Both classes extend the PolicyGroup class,
which is defined in [PCIM].
The ability to "divide" a given QoS policy domain's policy rules among
a set of policy containers provides a flexible framework to realize a
fine-grained administrative (or functional) structure. As the example
in figure 2 illustrates, it makes sense to divide policies for the
sales organization into two regional containers: Western and Eastern.
This enables a change in policies for one region to not affect the
policies currently in place for the other region.
Both the gpsPolicyGroup as well as the qosPolicyDomain policy
containers can be nested (e.g., a container may contain multiple
containers). A particular data tree, then, may be constructed with as
deep a hierarchy as needed.
3.8.1 Semantics of a gpsPolicyGroup
A (non-empty) gpsPolicyGroup holds an ordered list (i.e., a set) of
PolicyRule and/or gpsPolicyGroup instances. Both the gpsPolicyGroup
class and the PolicyRule class carry a priority property (called
gpPriority and Priority, respectively). Note that the PolicyGroup class
does NOT have a priority property - this is one of the reasons that the
PolicyGroup class has been subclassed in this document to provide these
semantics (through the gpsPolicyGroup class). These properties are used
to specify the order in which objects within a gpsPolicyGroup are
processed. The gpPriority property added to the gpsPolicyGroup enables
it to be treated the same way as a PolicyRule. That is, both the
gpsPolicyGroup as well as the PolicyRule will appear as atomic objects
that each has their own distinct priority.
Snir, Ramberg, Strassner, Cohen expires May 2001 27
Draft-ietf-policy-qos-info-model-02.txt November 2000
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
Draft-ietf-policy-qos-info-model-02.txt November 2000
+---------------+
|qosPolicyDomain|
+---------------+
|
| +--------------+
|-->|PolicyRule A |
| | Priority=19 |
| +--------------+
|
| +-----------------------+ +-------------+
|-->|gpsPolicyGroup |--->|PolicyRule C |
| | gpPriority=5 | | | Priority=7 |
| +-----------------------+ | +-------------+
| |
| +-------------+ | +-------------+
-->|PolicyRule B | ->|PolicyRule D |
| Priority=3 | | Priority=2 |
+-------------+ +-------------+
Figure 3. Example Ordering for a QoS Policy Decision
In this example, the ordering is A, then C, then D, then B. This is
because the gpPriority property of the gpsPolicyGroup is higher than
the Priority property of PolicyRule B, so each of the PolicyRules
contained in the gpsPolicyGroup (i.e., PolicyRule C and PolicyRule D)
are executed (in priority order) before PolicyRule B. If the
gpsPolicyGroup's priority was not defined, then the order between the
policy rules would have been A, then C, then B, and finally D (note in
this last example that the Priority property of a PolicyRule is treated
identically to the gpPriority property of a gpsPolicyGroup).
3.8.2 Priority and Decision Strategy Applied to Containers
Each policy rule as well as each policy container may have an order
attribute (Priority for PolicyRule and gpPriority for gpsPolicyGroup,
respectively). The ordering is interpreted as a function of the
priority value AND the particular level of aggregation that the
PolicyRule or gpsPolicyGroup resides in. For example, in Figure 3
above, PolicyRule A and PolicyRule B, as well as the gpsPolicyGroup,
are all at the same level of containment. The priority of each of these
objects must be compared with each other. Note that it would be
incorrect to ignore the priority of the gpsPolicyGroup and try and
compare the priorities of the policy rules that it contains (C and D)
to the priorities of policy rules A and B.
Snir, Ramberg, Strassner, Cohen expires May 2001 29
Draft-ietf-policy-qos-info-model-02.txt November 2000
3.8.3 Sharing Policy Containers
For shared (reusable) containers, the priority assigned to the shared
container must be correct for all containing objects. This restriction
makes it impractical to share a particular policy container directly
(i.e., for two applications belonging to two different QoS policy
domains to share the same policy container). This is because a policy
container can contain not just policy rules, but also additional policy
containers. However, sharing (i.e, reusing) a policy container can be
made possible by "enclosing" a shared container within an exclusive
container (i.e., a container that is used to contain just a single
instance of a gpsPolicyGroup object). This in effect makes the
gpsPolicyGroup act as a single-level container. Depending on the
sharing context, the following techniques can be used for sharing an
instance of the gpsPolicyGroup class:
1. Reusing a gpsPolicyGroup inside a gpsPolicyGroup
To reference a container C1 with priority P1 from a container C, an
enclosing container D is created and is assigned the desired priority
P1 within the context of the C container. The D container is placed
under the C container in the data tree implementation. The D container
contains a single object, C1, by means of the PolicyGroupInPolicyGroup
aggregation. The D container complies with the naming and ordering
restrictions -- it is only created in the context of the C container
and can not be reused by any other container. This means that the
container C1 can not contain additional containers, even though it is
normally able to.
2. Reusing a gpsPolicyGroup inside a policyRule
To reference a container C1 with priority P1 from a policy rule R
(making it a "sub-rule" object, as opposed to a (more general)
container that is shareable by multiple policy rules), an enclosing
container D is created and is assigned the desired priority P1 within
the context of the sub-rule. The D container is contained in the rule
by using the PolicyRuleInPolicyRule aggregation. This aggregation
effectively places a given rule under an existing rule (in our example,
PolicyRule R contains a set of conditions and actions as well as the
container D; container D contains a single object, which is another
policy rule, but this policy rule acts as a sub-rule of R) using the
PolicyGroupInPolicyGroup aggregation.
This structure enables either another rule, R', or a policy container,
C', or both, to now share the C1 container by similar means.
Note that a shared container (C1 in the descriptions under #1 and #2
above) MUST be named so that it can be placed in a reusable-object
repository (see section 3.13).
Snir, Ramberg, Strassner, Cohen expires May 2001 30
Draft-ietf-policy-qos-info-model-02.txt November 2000
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
Draft-ietf-policy-qos-info-model-02.txt November 2000
After identifying the relevant set of rules to be used, rules should be
prioritized according to the procedures and rules defined in Section 5.
The PolicyRoles values defined per gpsPolicyGroup include implicitly
the roles defined for the contained policy containers.Overriding a role
or role-combination that is defined for a containing policy container
is not allowed.
The following example illustrates this situation:
gpsPolicyGroup 1 : PolicyRoles: Role A, Role B
|
+--PolicyRule 1.1 : PolicyRoles: <Not defined>
|
+--PolicyRule 1.2 : PolicyRoles: Role A, Role D
|
+--PolicyRule 1.3 : PolicyRoles: <Not defined>
|
+--PolicyRule 1.3.1 : PolicyRoles: Role E
PolicyRule 1.1 will be associated with roles A & B, because it
inherits both of these roles from gpsPolicyGroup 1
PolicyRule 1.2 will be associated with roles A, B, & D, because it
inherits roles A and B from gpsPolicyGroup 1 and adds D
PolicyRule 1.3 will be associated with roles A & B, because it
inherits both of these roles from gpsPolicyGroup 1
PolicyRule 1.3.1 will be associated with Roles A, B, & E, because it
inherits roles A & B from PolicyRule 1.3 and adds E
For a definition of the gpsPolicyGroup's PolicyRole property,
refer to section 8.2.3. Extended explanation on the definition and
usage of Roles is provided in [PCIM], section 5.2.
Note: A role or role-combination defined in contained and containing
policy objects does not imply any special behavior. The example above
illustrates this situation in PolicyRule 1.2, regarding role A.
3.10. Policy Rules
QoS policy rules are modeled by the [PCIM] class PolicyRule. All new
behavior in [PCIM] is obtained not by altering the definition of a
PolicyRule, but rather by adding new types of PolicyConditions and
PolicyActions (along with other associated objects) that are used by
the PolicyRule.
The semantics of a policy rule is, in essence, a conditional imperative
statement in the form 'if <condition> then <action>'. Applying a rule
means evaluating its condition and, depending on the truth value of
the condition, to either execute the action or to do nothing.
Evaluating a condition is known as 'matching the rule', an expression
we'll be using in later sections of this document. [PCIM] requires that
Snir, Ramberg, Strassner, Cohen expires May 2001 32
Draft-ietf-policy-qos-info-model-02.txt November 2000
a given policy rule SHOULD belong to one (and only one) gpsPolicyGroup.
These semantics are enforced by a special association,
PolicyRuleInPolicyContainer (defined in [PCIM]), with the appropriate
cardinality (1 policy container can contain zero-or-more PolicyRules).
However, a policy designer may, in some cases, wish to reuse a
particular rule in more than one policy container. The designer MAY do
so by encapsulating the would-be reusable rule within a single,
reusable policy container and sharing that container, using the
technique described in section 3.8.3.
The order of the policy rules inside a container is based on the
relative values of the Priority attribute of each of the PolicyRules
(please see [PCIM] for more information). The enforcement of policy
rules also depends on particular settings belonging to the group. The
match strategy to be applied to the policy rules contained in a given
container is defined in the policyRuleMatchMethod attribute of the
gpsPolicyGroup object.
Policy rules may be nested. Placing a rule under another rule in the
data tree creates a nested rule. This is done by using the
PolicyRuleInPilicyRule aggregation.
3.11. Conditions and Actions
A policy rule is a composite object. The most
important components of a rule are the conditions and actions it
contains. A condition is a Boolean expression that is evaluated to find
out if the rule should be applied. An application of a rule means that
the actions that it contains will be executed. An action is a
specification of one or more QoS operations enforced on the designated
set of flows that MUST be done if the given policy rule is to be
applied. Actions are applied if the condition is TRUE (see [PCIM] for
more details).
3.12. Data Tree Example
The following example illustrates the hierarchical nature of the QoS
Policy data tree. Each organizational entity is related to a specific
type of class, which is shown in parentheses.
There are two QoS policy domains in this example, grouped together
under the same root (domain grouping). The QoS policy domains are:
1. EastCoast
2. WestCost
Snir, Ramberg, Strassner, Cohen expires May 2001 33
Draft-ietf-policy-qos-info-model-02.txt November 2000
Assume that each of these two qosPolicyDomains has its own PHB set
modeled by a gpsPolicyGroup with a set of policy rules defining the per
hop behavior for different DSCP values.
The EastCoast domain has 2 named policy containers. The first deals
only with ERP traffic and the second handles all other traffic:
1. EastCoast (implemented as a qosPolicyDomain)
1.1. ERP (implemented as a gpsPolicyGroup)
1.2. General (implemented as a gpsPolicyGroup)
The WestCoast domain has three named policy containers. The first deals
only with ERP traffic, the second deals with VoIP traffic, and the
third with all other traffic:
2. WestCoast
2.1. ERP (implemented as a gpsPolicyGroup)
2.2. VoIP (implemented as a gpsPolicyGroup)
2.3. General (implemented as a gpsPolicyGroup).
Each one of the gpsPolicyGroup entries can contain a
prioritized rule set. For example, the WestCoast ERP group contains the
rules relevant to ERP applications administered by the west coast
domain administrator.
We see from the above structure that this structure provides the
administrator with a great deal of flexibility. For example, similarly
containers, represented by the ERP and General
gpsPolicyGroups, can reuse common policy conditions and
actions. However, they are implemented as physically different
containers to enable the administrator to administer them
according to their own domain-specific needs.
3.13. Reusable-Object Repositories
Reusable objects are objects that can be referred by (hence "used by")
other objects. For example, the reference could be accomplished by
allocating an attribute on the referencing object that contains the
location of the referenced object. In this information model,
association classes (and naming rules) are used to establish
reusability of an object by creating a "resides-in" relationship
between the reusable object and the repository in which it resides. For
example, the PolicyConditionInPolicyRepository association is used to
enable an instance of a PolicyCondition class, or its subclasses, to
reside in an instance of a PolicyRepository class, or its subclasses.
The concept of reusable-object repositories is introduced by [PCIM] for
the purpose of allowing data tree constructors to share data among many
users. This document enhances this concept to model the needs of QoS
policy rules.
Snir, Ramberg, Strassner, Cohen expires May 2001 34
Draft-ietf-policy-qos-info-model-02.txt November 2000
A reusable-object repository hierarchy is rooted in an instance of the
policyRepository class (defined in [PCIM]). Individual reusable-object
repositories are named containers for reusable objects. Note that
[PCIM] allows arbitrary nesting of reusable-object repositories. This
can be conceptually thought of as a repository of repositories.
Each named reusable-object repository is a container of "reusable
objects" that can be used for a common purpose, and/or are administered
in a common way. A reusable object MUST have a unique name within the
the container that it resides in.
The complete aggregation model for the reusable-object repositories,
as well as detailed description of the various mechanisms for
constructing and maintaining such repositories, is described in detail
in [PCIM].
Common candidates for reusability are named instances of these classes
and their derivatives:
- gpsPolicyVariable
- gpsPolicyValue
- gpsPolicySimpleCondition
- gpsPolicyCompoundCondition
- policyAction
- gpsPolicyMeter, QoSPolicyTrfcProf, QoSPolicyQueue
- gpsPolicyGroup for policy rule reusability
3.14. Relationships Between QoS Domains and Repositories
As explained above, a QoS policy domain contains within it groups of
policy rules. A policy rule can contain ordered lists of conditions and
actions. The conditions and actions may be reusable objects that reside
in reusable-object repositories, or they may be rule-specific
conditions and actions that are embedded within the rule, or a
combination of both.
The advantage of reusable objects is that many different policy rules
may reference the same reusable object . References to reusable objects
need not all point to the same reusable-object repository; any policy
rule may contain references to reusable objects that reside in
different repositories.
The maintenance of the policy system is made somewhat more complicated
due to the flexibility provided by the ability to use multiple
repositories. For example, it is more difficult to prevent "dangling"
references to repositories that are no longer present. Schema designers
are encouraged to pay extra attention to this problem and exercise any
technique available from their implementation platform to maintain
integrity of their data trees. [PCIM] discusses this issue as well.
Snir, Ramberg, Strassner, Cohen expires May 2001 35
Draft-ietf-policy-qos-info-model-02.txt November 2000
4. Constructing a QoS Policy Rule
A policy rule modeled in [PCIM] represents the "If Condition then
Action" semantics associated with a policy. The QPIM extends these
semantics by refining the type of policy conditions and actions that
can be represented, extending the use of containers that hold policy
information, and providing additional features (nesting of rules,
aggregation of groups inside rules, defining extensible rule decision
strategies, linking to PHBs, and providing pre-defined
variables and constants that can be used to express the required
semantics of QoS policy rules in more detail).
The following sections describe these characteristics in more detail.
4.1 Policy Rule Structure
A policy rule has the following attributes (defined in [PCIM]) that can
be used to provide important semantics for QoS policy applications;
these are in addition to the attributes which serve as a key and
provide its name:
1. An Enable flag that indicates whether a policy rule is
administratively enabled, administratively disabled, or enabled
for debug mode.
2. A set of conditions,contained in the rules by means of the
PolicyConditionInPolicyRule aggregation. Note that the new
subclasses of PolicyCondition that the QPIM defines automatically
inherits this relationships
3. A flag indicating whether the rule's condition is in disjunctive
or conjunctive normal form
4. An (optionally ordered) list of actions, contained in the rule by
means of the PolicyActionInPolicyRule aggregation.
5. A priority value, defining the ordinal position of this rule
relative to other rules (or any other contained objects) in the
same container
6. The attribute named mandatory, which is used to define whether
the evaluation of conditions (and the subsequent execution of
actions if the conditions evaluate to TRUE) is mandatory or not
7. A SequencedActions attribute that defines how to execute the
actions if the condition is TRUE
8. An array of PolicyRoles attributes, that define the roles or
role-combinations that are used in this rule
9. A RuleUsage attribute, that contains a description of how this
rule should be used
The Boolean condition is evaluated in order to determine if the set of
actions should be performed on a network flow by matching the network
flow attributes against the condition. The PCIM defines a generic
simple policy condition class, called PolicyCondition, which can be
Snir, Ramberg, Strassner, Cohen expires May 2001 36
Draft-ietf-policy-qos-info-model-02.txt November 2000
used to contain a single condition term to be tested. This document
defines two new policy condition classes. The first,
gpsPolicySimpleCondition, extends the semantics of a policy condition
to contain an ordered triplet ({variable, operator, value}). The
second, gpsPolicyCompoundCondition, uses the gpsPolicySimpleCondition
class to build a more generic compound condition class. QoS-specific
conditions SHOULD be formed by using the gpsPolicySimpleCondition class
and/or the gpsPolicyCompoundCondition class (both of these classes are
defined in this document) and/or the policyTimePeriodCondition class
defined in [PCIM] (or their subclasses, of course). Note that QoS-
specific conditions MAY be mixed with more generic conditions that are
not derived from either of these classes. However, these non-QoS-
specific conditions SHOULD be derived from the PolicyCondition class
(defined in [PCIM]). The combination of individual conditions in a
policy rule is defined in [PCIM] using the PolicyConditionInPolicyRule
aggregation.
Each action in the list is modeled by an class derived from the
PolicyAction class. The collection of individual actions in a policy
rule is defined in [PCIM] using the PolicyActionInPolicyRule
aggregation. This class also contains a property, ActionOrder, that
defines the order in which policy actions are performed. .
The interpretation of a policy rule in regard to a given network flow
may be expressed as follows:
If the rule is enabled and the Boolean expression is evaluated to
TRUE, then use the Action list to extract the prescribed treatment
for this flow.
The rest of this section describes the components of the policyRule
class and their relationships to the other classes defined in this
information model.
4.2 QoS Policy Conditions
A policy rule, as modeled in [PCIM], represents the "If Condition then
Action" semantics associated with a policy. A condition is represented
as either an ORed set of ANDed terms (disjunctive normal form) or an
ANDed set of Ored terms (conjunctive normal form). Individual
conditions may either be negated (NOT C) or not negated (C). The
actions specified by a policy rule are to be performed if and only if
the policy rule condition evaluates to TRUE.
The semantics of an individual condition are not specified in [PCIM].
Rather, the PCIM limits itself to specifying the structure of a
condition and its naming attributes. This document provides semantics
for common QoS policy conditions. For example, conditions such as: "If
the source IP address of the flow belongs to 10.1.x.x subnet" as well
as "If the IP protocol number of the flow equals the TCP protocol
number" are modeled in this document.
Snir, Ramberg, Strassner, Cohen expires May 2001 37
Draft-ietf-policy-qos-info-model-02.txt November 2000
4.2.1 Simple Conditions
The gpsPolicySimpleCondition class models individual conditions. This
class refines the basic structure of the PolicyCondition class defined
in [PCIM] by specifying the contents of the condition using the triplet
<variable>, <operator> and <value> to form the condition.
The variable specifies the attribute of a flow that should be matched
when evaluating the condition. A set of predefined variables that cover
network attributes that are commonly used for filtering are introduced
to encourage interoperability. This list covers layer 3 IP attributes
such as IP network addresses, protocols and ports, as well as a set of
layer 2 attributes (e.g., MAC addresses) and higher level attributes
such as application and user identity.
The QPIM defines a single operator, "match", as explained in the
'Simple Condition Operator' section.
The bound variable is matched against a value to produce the Boolean
result. In the first example above, a source IP address variable is
matched against a 10.1.x.x subnet value. The operator specifies the
type of relation between the variable and the value evaluated in the
condition. The match operator that is defined in QPIM is not just a
simple equal operator - it carries additional semantics (which are
defined in the PolicyValueConstraintsInVariable association) that
ensure that it contains an allowed value that belongs to a pre-defined
acceptable range of values. For example, an IPv4SourceAddress variable
is defined as a string. But the literal value of the string must
conform to the defined semantics of an IPv4 address, and must represent
a legal IPv4 address in either dotted decimal or CIDR format.
Similarly, a port is defined to be an integer. But negative values, or
positive values greater than 65535, are not allowed.
4.2.2 Compound Conditions
Sometimes it is convenient to model a general Boolean expression as an
atomic condition. For example, many packet-related conditions in policy
rules, from a networking perspective, can be modeled as Filters.
Filters are not modeled directly in the PCIM (i.e., no Filter class is
defined). However, the filter concept is central in the QoS Policy data
model.
Note that a filter may consist of multiple terms. The problem, then, is
that if all we have are the PolicyCondition, PolicyTimePeriodCondition,
and gpsPolicySimpleCondition classes, we can't refer to a filter as an
atomic condition, because we will need to combine multiple instances of
one or more of these classes to construct the filter. This is why the
QPIM has defined the gpsPolicyCompoundCondition class.
Snir, Ramberg, Strassner, Cohen expires May 2001 38
Draft-ietf-policy-qos-info-model-02.txt November 2000
The gpsPolicyCompoundCondition class enables multiple instances of the
PolicyCondition, the PolicyTimePeriodCondition, the
gpsPolicySimpleCondition, and/or the gpsPolicyCompoundCondition classes
to be combined and treated as a single atomic entity. This enables the
gpsPolicyCompoundCondition class to be used to model any general
Boolean expression, including common traffic filters. A filter is
constructed by the mechanisms supplied in the following PCIM
attributes:
1. The ConditionListType attribute of the policyRule, which
is a Boolean expression type that defines whether the simple
condition is in conjunctive or disjunctive normal form.
2. The PolicyConditionInPolicyRule aggregation class that does three
things: associates conditions with a particular policy rule,
defines whether the condition is negated or not, and partitions
the referenced conditions into one or more groups. For more
details, please see [PCIM], section 6.3.
4.2.3. Using Simple Conditions
Simple conditions can be used in policy rules directly or as building
blocks for creating compound conditions.
Simple condition composition MUST enforce the following data type
conformance rule: The gpValueTypes property of the variable must be
compatible with the value class name. This ensures that the binding of
the variable to an acceptable value can be done.
The QPIM defines four different ways to compose a simple condition
through the combination of representations of variables and values. The
following combinations of representing a simple condition are possible:
Variable representation
1. An "ad-hoc" instance of the class gpsPolicyVariable may be contained
by the gpsPolicySimpleCondition instance using the
PolicyVariableInPolicySimpleCondition.
2. A reusable, named instance of the class gpsPolicyVariable, which
resides in a reusable-object repository may be indirectly linked
with the gpsPolicySimpleCondition instance (using the same
aggregation as above)
Value representation
1. An "ad-hoc" instance of the class gpsPolicyValue may be contained
by the gpsPolicySimpleCondition class using the
PolicyValueInPolicySimpleCondition aggregation.
Snir, Ramberg, Strassner, Cohen expires May 2001 39
Draft-ietf-policy-qos-info-model-02.txt November 2000
2. A reusable, named instance of the class gpsPolicyValue may be
indirectly linked with the gpsPolicySimpleCondition instance using
the same aggregation as above).
The first method for representing variables and values enables either
to be embedded directly in a policy condition. This is important for
allowing simple and efficient access to the policy condition and its
embedded variables and/or values. It also enables the condition along
with its embedded variables and values to be treated as an atomic
object. The second method for representing variables and values enables
the condition to reuse the variable and/or value. In this case, both
would be stored in a PolicyRepository. Note that the method described
here for composing conditions out of variables and values allows for
uniform handling for both "ad-hoc" reusable objects, as the
relationships between the aggregator and aggregated objects are unaware
of the reusability vs. ad-hoc status of the aggregated objects.
A simple condition can be added to a PolicyRule or to a
gpsPolicyCompoundCondition in two ways:
1. Building a rule-specific ("ad-hoc") condition. In this case, the
goal is to embed the condition directly in either the PolicyRule or the
gpsPolicyCompoundCondition instance. In many data storage mechanism
implementations, this will be realized by treating the PolicyRule or
the gpsPolicyCompoundCondition instance as a container, and placing an
instance of the condition in the container. For example, in a
directory implementation, the condition will be added as a leaf object
in the container. In the information model, we describe this case using
either the PolicyConditionInPolicyRule aggregation (in the case of a
embedding a condition directly in a PolicyRule) or the
PolicyConditionInCompoundCondition aggregation (for embedding either
gpsPolicySimpleConditions or gpsPolicyCompoundConditions in a
gpsPolicyCompoundCondition).
This case is called an "ad-hoc" simple condition. This method allows
the creation of a "private" simple condition, meaning that this
instance of the condition can't be used by any other policy rule or
compound condition, hence it is not reusable. However, this case
enables the condition and its container to be treated and managed
atomically.
2. Building a reusable condition. In this case, the goal is to treat
the condition as a reusable building block. Therefore, it will be
placed in a PolicyRepository and referenced by its containing object
(either a PolicyRule or a qpsCompoundPolicyCondition). In many data
storage mechanism implementations, this will be realized by treating
the PolicyRule or the gpsPolicyCompoundCondition instance as a
container, treating the PolicyRepository as a separate container, and
using an attribute in the PolicyRule or gpsPolicyCompoundCondition to
reference the condition in the PolicyRepository. For example, in a
Snir, Ramberg, Strassner, Cohen expires May 2001 40
Draft-ietf-policy-qos-info-model-02.txt November 2000
directory implementation, a DN pointer will be used to refer to the
condition. In the information model, we describe this case using two
relationship classes. One class, the PolicyConditionInPolicyRepository
association, establishes the "resides-in" relationship between the
reusable object and the reusable-object repository in which it resides.
Another class, the PolicyConditionInPolicyRule aggregation class,
establishes the "contained-in" relationship between the condition and
the rule that contains it.
The advantage of this approach is that by using an indirect reference
to refer to an instance of a condition that resides in a reusable-
object repository, this method allows the sharing of reusable
conditions by multiple policy rules or compound conditions.
Schema designers should keep in mind that in some cases, an
implementation platform introduces an added cost to access reusable
objects that are located in different areas of the data store than the
referencing object is located in. For example, in LDAP based storage,
fetching a sub-tree (i.e., a container object and its "leaves") is a
single operation while accessing a referenced object is an additional
operation.
4.2.4. Using Compound Conditions
Compound conditions should be used when the definition of a set of
terms that should be treated atomically (e.g., as a single condition)
is required. One such example is the common case of filtering on a
five- or six-tuple (e.g., the source and destination address and ports,
protocol, and DSCP). This type of filter can be modeled as a container
that holds one or more simple conditions.
If filter reusability is not required, then an ad-hoc set of simple
conditions that implement a rule-specific condition is sufficient (it
carries the same semantics except for reusability).
All instances of the gpsPolicyCompoundCondition MUST carry unique
names. A name is a MUST property for reusable objects (this is required
by [PCIM]).
The gpPolicyConditionListType of the gpsPolicyCompoundCondition is set
to DNF or CNF (disjunctive or conjunctive normal form, respectively),
as required. Each of the conditions that are to be used in this
compound condition are defined using the
PolicyConditionInCompoundCondition aggregation. This aggregation
enables the condition to be treated as a container so that it can
aggregate other conditions, and is defined in QPIM.
Each condition that is contained in the compound condition can be
either directly contained the compound condition (in which case it is
a rule-specific, ad-hoc condition) or be a reusable condition that
resides in a PolicyRepository.
Snir, Ramberg, Strassner, Cohen expires May 2001 41
Draft-ietf-policy-qos-info-model-02.txt November 2000
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
Draft-ietf-policy-qos-info-model-02.txt November 2000
the condition itself. In this case, embedding the values and variables
within the policy condition is specified by the
PolicyValueInPolicyCondition and PolicyVariableInPolicyCondition
aggregations, respectively. This is called a rule-specific condition,
because its components can not be shared with other rules.
Alternatively, a policy variable and/or a policy value can be
instantiated in a reusable-object repository and then referenced by the
(simple or compound) condition. The values (or variables) are linked to
the PolicyRepository using the PolicyElementInPolicyRepository
association; the condition is linked to the PolicyRepository using the
PolicyConditionInPolicyRepository association. Note that the reusable-
object repository may be part of the same data store as that which
contains the aggregating condition, or it may be a physically different
data store..
4.3 Simple Condition Operator
The QoS policy simple condition includes the gpOperator property,
which specifies the type of relation between the variable and the value
evaluated in the condition. In many cases, a generic 'match' operator
can be used, and the interpretation of the relation between the
variable and value is implied by the value itself. For example, the
variable SourceIPAddress can be matched to an IP address, where the
'equal' relation is implied, to a hostname in which the 'resolve to'
relation is implied, or to a subnet address in which 'belongs to'
relation is implied. Similarly, this same variable (which is a string)
has semantics that determine the acceptable values that the string can
take. For example, an improperly formed address in either CIDR or
dotted decimal notation can be detected and rejected.
The QPIM defines a single operator, "match", that models the most
generic relation: that of being equal or belonging to.
4.4 QoS Policy Variables
QoS policy variables are used for building individual conditions, as
defined in section 4.2. The variable specifies the attribute of a flow
that should be bound and evaluated according to a set of pre-defined
semantics in a condition. Its purpose is to act as a binding point,
associating a condition with an object whose data is evaluated
according to the specified operator/value. The QPIM has defined
semantics for some of the most common of these variables based upon
these sources to guide the binding of common data. However, such
binding could also be determined from a variety of other standard and
proprietary sources such as public or private MIBs or application-
specific data.
Snir, Ramberg, Strassner, Cohen expires May 2001 43
Draft-ietf-policy-qos-info-model-02.txt November 2000
Not every combination of a variable and a value creates a meaningful
condition. For example, a source IP address variable can not be matched
against a value that specifies a port number. The QPIM defines a set of
variables that can be used to model common QoS policy conditions, and
assigns appropriate semantics for each. Each type of variable
inherently selects the set of value types that it can be matched
against (i.e. a value that could be compared and evaluated to a Boolean
expression).
Variables have data types. Many of the variables defined in this draft
have associated semantics that limit the set of values within a
particular value type that can be matched against it in a condition.
This may be viewed as a second level of integrity checking. For
example, a variable representing the source-port must limit the set of
values that it can assume to the valid range of integers that
correspond to legal source-port values; values such as -3 or 2000000
are not legal values and can not be matched to this variable. Thus, it
is not enough to say that the data type of the source-port variable is
an integer; we also need to ensure that the value to be tested is
within a valid range of integers. This is achieved by associating the
source port variable with an integer value object that contains the
appropriate value range for that variable.
In this first implementation, simple semantics such as those described
above are realized by defining a separate class whose properties
contain the constraints. This constraint class is then linked to the
PolicyValue class through the PolicyValueConstraintsInVariable. In the
future, a more robust mechanism, such as an object constraint language,
may be integrated with the information model to provide even more
metadata to describe legal behavior, values and operations on the
variable. Currently, such a language is not integrated with either this
information model or PCIM. The mechanism defined in this draft enables
implementation experience to be gained to help guide the integration of
a constraint language in the future.
The QPIM defines one attribute, one association, and one general
purpose mechanism that together characterize each of the variables that
it defines:
1. The property gpVariableName of the qpsPolicyVariable class defines
the well-known name used for logically binding all variables that
are defined in this document to a set of allowed value data types.
2. The PolicyValueConstraintsInVariable association defines the set
of value classes that could be matched to this variable.
3. The list of constraints on the values that the PolicyVariable can
hold (i.e., values that the variable must match) are defined by
the appropriate properties of an associated PolicyValue class.
Snir, Ramberg, Strassner, Cohen expires May 2001 44
Draft-ietf-policy-qos-info-model-02.txt November 2000
For example, if a PolicyVariable represents the SourcePort of incoming
traffic, then a PolicyValueConstraintsInVariable association can be
used to link the PolicyVariable instance to an qosPolicyIntegerValue
instance. This association by itself constrains the data type of the
SourcePort PolicyVariable to be an integer. However, we can further
constrain the particular values that the SourcePort PolicyVariable can
hold by entering valid ranges in the qpIntegerList property of the
qosPolicyIntegerValue instance.
Note that implementations are free to realize the semantics defined by
these two associations in a number of different ways. The information
model defines these semantics based around an association, because that
is the most general form describing how this information is related. An
implementation could conceivably realize this using zero or more actual
relationships.
The combination of the qpVariableName and the
PolicyValueConstraintsInVariable assocation provide a consistent and
extensible set of metadata that define the semantics of variables that
are used to form QoS conditions. Since the
PolicyValueConstraintsInVariable association points to another class,
any of the properties in the PolicyValue class can be used to constrain
values that the PolicyVariable can hold. For example:
- The gpVariableName can be used to identify common processing rules
for a variable having a specific name.
- The PolicyValueConstraintsInVariable association can be used to
ensure that only proper classes are used in the expression. For
example, the SourcePort variable will not be allowed to associate
to the qpsPolicyIPv4AddrValue class, since source ports have
different semantics than IP addresses and may not be matched.
However, it will associate to a gpsPolicyIntegerValue class.
- The PolicyValueConstraintsInVariable association also ensures that
variable-specific semantics are enforced (e.g., the SourcePort
variable may include a constraint association to a value object
defining a specific integer range that should be matched).
4.4.1. Variable Binding
For the QoS Policy schema to be interoperable, different policy
management systems and policy servers must instantiate the same
variables with identical values (in the same evaluation operation).
While different policy servers may use a different binding mechanism,
the binding logic must result in an identical instantiation.
Each variable defined in the QoS policy data store must be bound to a
logical entity such as a specific field in the IP header, a specific
class or property in the QPIM or in a related Information or Data
Model, an application unique identifier or an application-specific
parameter.
Snir, Ramberg, Strassner, Cohen expires May 2001 45
Draft-ietf-policy-qos-info-model-02.txt November 2000
When a policy server attempts to evaluate an expression containing
variables, it must instantiate the variables. To instantiate a
variable, that variable must be bound to a specific value (or values,
depending on its type category) and associated with a logical entity.
For example, in the expression 'SourcePort == 80', the variable
'SourcePort' must be instantiated to a value and logically associated
with the packet header field containing the source port number, for the
expression to be evaluated.
If, in this example, the variable SourcePort is bound to a value of
'80', then the expression is evaluated to TRUE for each packet that the
source port number in the IP header field equal to 80. Otherwise it is
evaluated to FALSE.
4.4.2. Pre-Defined Variables
The purpose of this section is to explain the need and define the
relationship of standard, frequently used variables with their logical
entities. Pre-defined variables are necessary for ensuring
interoperability among policy servers and policy management tools from
different vendors.
For example, different policy servers may have to evaluate the same
policy rule. If each policy server uses a common set of variables, this
helps to abstract the condition term such that its evaluation can be
performed in the same way by all of those policy servers. If no such
set of common variables exist, then each policy server is free to
define its own set of variables. Variations in each variable that each
policy server defines will impede interoperability, and prevent the
same semantics and interpretation to be achieved when each policy
server implements the same policy rule.
The QoS Policy information model specifies a set of pre-defined
variables to support a set of fundamental QoS terms that are commonly
used to form conditions. Examples of these include IP header field
values, user information, applications, and others. A pre-defined
variable MUST always have the same name and binding semantics. For
example, a given pre-defined variable should be bound to the same
logical entity by all client systems (typically policy devices).
Similarly, the pre-defined variable should be stored in the reusable-
object repository to enable reuse and sharing of the pre-defined
variable.
Snir, Ramberg, Strassner, Cohen expires May 2001 46
Draft-ietf-policy-qos-info-model-02.txt November 2000
All standard variable names are case insensitive and do not include
spaces or other non-standard characters to promote ease of use.
The implementers of client systems that map the QPIM to a specific
repository-based implementation MUST provide binding methods to bind
pre-defined variables according to the semantics specified in this
section.
Following is a table that defines the predefined variable names and
their binding. The table indicates which fields are checked in actual
filters used in provisioning policies as well as in RSVP signaling
messages.
+-----------------+---------------------------------------------------+
|Variable name | Logical binding |
+-----------------+---------------------------------------------------+
| SourceIP | The source IP address of the flow. Compared to the|
| | source IP header field, or the sender address in |
| | the RSVP Filter spec object [RSVP]. |
+-----------------+---------------------------------------------------+
| SourcePort | The source Port of a UDP/TCP flow. Compared to the|
| | source port field in the TCP/UDP header, or the |
| | sender port in the RSVP Filter spec object [RSVP].|
+-----------------+---------------------------------------------------+
| DestinationIP | The destination IP address of the flow. Compared |
| | to the destination IP header field, or the session|
| | address in the RSVP SESSION object [RSVP]. |
+-----------------+---------------------------------------------------+
| DestinationPort | The destination Port of a UDP/TCP flow. Compared |
| | to the destination port field in the TCP/UDP |
| | header, or the session port in the RSVP SESSION |
| | object [RSVP]. |
+-----------------+---------------------------------------------------+
| IPProtocol | The IP protocol number. Compared to the protocol |
| | number in the IP header field or to the IP |
| | protocol in the RSVP SESSION object [RSVP]. |
+-----------------+---------------------------------------------------+
| ToS | The ToS variable is bound to the IP header ToS |
| | byte. |
+-----------------+---------------------------------------------------+
| DSCP | The DSCP variable is bound to the IP header DSCP |
| | byte or to the DCLASS RSVP object. |
+-----------------+---------------------------------------------------+
| DestinationMAC | The destination MAC address variable is bound the |
| | frame destination MAC address. |
+-----------------+---------------------------------------------------+
| SourceMAC | The source MAC address variable is bound the frame|
| | source MAC address. |
+-----------------+---------------------------------------------------+
(Table continued in next page)
Snir, Ramberg, Strassner, Cohen expires May 2001 47
Draft-ietf-policy-qos-info-model-02.txt November 2000
(Table continued from the previous page)
+-----------------+---------------------------------------------------+
| 8021QID | The VLAN ID is bound to the 802.1Q field of |
| | the header. |
+-----------------+---------------------------------------------------+
| Snap | The snap protocol variable is bound to the |
| | protocol type carried over SNAP encapsulation. |
+-----------------+---------------------------------------------------+
| Ethertype | The ethertype variable is bound to the frame |
| | header ethertype value. |
+-----------------+---------------------------------------------------+
| Ssap | The source sap variable is bound the frame header |
| | field containing the source SAP. |
+-----------------+---------------------------------------------------+
|Variable name | Logical binding |
+-----------------+---------------------------------------------------+
| Dsap | The destination sap variable is bound the frame |
| | header field containing the destination SAP. |
+-----------------+---------------------------------------------------+
| Application | The ID of the application that generated the flow.|
+-----------------+---------------------------------------------------+
| User | The ID of the user that initiated the flow, or is |
| | designated as the flow owner. |
+-----------------+---------------------------------------------------+
Table 1. Pre-defined Variables and Their Bindings
The definition of each predefined variable includes a standard name and
the allowed value types. The VariableHasDataValues association is used
to associate a variable object with a value object.
Following is a table of variable names and the value types defined
within this document that can be used together in a simple condition.
In reality, these are individual specializations of the general
association, PolicyValueConstraintsInVariable, that exists between the
PolicyVariable and PolicyValue classes and their subclasses. A given
variable can further restrict the values that can be combined with it
in a given condition. This is done by restricting the values that can
be held by the appropriate attributes of the PolicyValue class that is
used to represent the constraining object in the
PolicyValueConstraintsInVariable association. For example, by default,
a condition including a variable with the name "SourceIP" should also
include either a gpsPolicyIPv4AddrValue or a gpsPolicyIPv6AddrValue
value object. But, if there is a need to restrict values within a
condition to only IPv6 addresses of a certain range, then the
PolicyValueConstraintsInVariable association can be used to indicate
that only gpsPolicyIPv6Values of that range should be used. This is
done by placing this information into the qpIPv6AddrList attribute of
the gpsPolicyIPv6AddrValue class. The table below does not restrict new
Snir, Ramberg, Strassner, Cohen expires May 2001 48
Draft-ietf-policy-qos-info-model-02.txt November 2000
value classes defined elsewhere to be combined with variables defined
in this document.
+-----------------+---------------------------------------------------+
|Variable name | Allowed value types |
+-----------------+---------------------------------------------------+
| SourceIP | gpsPolicyIPv4AddrValue, gpsPolicyIPv6AddrValue |
+-----------------+---------------------------------------------------+
| SourcePort | gpsPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| DestinationIP | gpsPolicyIPv4AddrValue, gpsPolicyIPv6AddrValue |
+-----------------+---------------------------------------------------+
| DestinationPort | gpsPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| IPProtocol | gpsPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| ToS | gpsPolicyIntegerValue, gpsPolicyBitStringValue |
+-----------------+---------------------------------------------------+
| DSCP | gpsPolicyIntegerValue, gpsPolicyBitStringValue |
+-----------------+---------------------------------------------------+
| DestinationMAC | gpsPolicyMACAddrValue |
+-----------------+---------------------------------------------------+
| SourceMAC | gpsPolicyMACAddrValue |
+-----------------+---------------------------------------------------+
| 8021QID | gpsPolicyIntegerValue, gpsPolicyBitStringValue |
+-----------------+---------------------------------------------------+
| Snap | gpsPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| Ethertype | gpsPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| Ssap | gpsPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| Dsap | gpsPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| Application | gpsPolicyDNValue, gpsPolicyStringValue, |
| | gpsPolicyAttributeValue |
+-----------------+---------------------------------------------------+
| User | gpsPolicyDNValue, gpsPolicyStringValue, |
| | gpsPolicyAttributeValue |
+-----------------+---------------------------------------------------+
Table 2. Variable Names and Their Default Class Mappings
Note: Values are defined in section 4.5.
4.5 QoS Policy Value
The abstract class gpsPolicyValue is used for defining values and
constants used in policy conditions. Different value types are derived
Snir, Ramberg, Strassner, Cohen expires May 2001 49
Draft-ietf-policy-qos-info-model-02.txt November 2000
from this class and represent the various attributes required.
Extensions of the qpsPolicyValue class, defined in this document
provide a list of values for representing the basic network attribute.
Values can be used to represent constants as named values. Named values
could be kept in a reusable-object repository to be reused by multiple
conditions.
Examples of constants include well-known ports, well-known protocols,
server addresses, and other similar concepts.
The qpsPolicyValue classes define 3 basic types of values: scalars,
ranges and sets. For example, a well-known port number could be defined
using the gpsPolicyIntegerValue class, defining a single value (80 for
HTTP), a range (80-88), or a set (80, 82, 8080) of ports, respectively.
For details, please see the class definition for each value type in
section 8 of this document.
The QoS policy information model provide the following classes, all of
them extending the qpsPolicyValue class:
Classes for general use:
GpsPolicyStringValue,
gpsPolicyIntegerValue,
gpsPolicyBitStringValue,
gpsPolicyDNValue,
gpsPolicyAttributeValue.
Classes for layer 3 Network values:
gpsPolicyIPv4AddrValue,
gpsPolicyIPv6AddrValue.
Classes for layer 2 Network values:
gpsPolicyMACAddrValue.
For details, please see the class definition section of each value in
section 8 of this document.
4.6. PolicyTimePeriodCondition
The QoS Policy Information model uses the policyTimePeriodCondition
class (defined in [PCIM]) to define time based QoS policy rules. For
details, please see [PCIM], section 6.5.4.7. Actions
4.7 Actions
The QoS Policy information model defines actions to control QoS
enforcement in both the Integrated Service model as well as the
Differentiated Service model. Three types of actions are provided:
Signaling, Provisioning and Per-Hop-Behvior (PHB) actions.
Snir, Ramberg, Strassner, Cohen expires May 2001 50
Draft-ietf-policy-qos-info-model-02.txt November 2000
Signaling actions are used to provide policy control on RSVP
requests. Provisioning actions are used to enforce differentiated
service edge policies including marking, policing and shaping
operations. PHB actions are used to enforce per-hop behaviors across
the differentiated services domain.
A policy rule may aggregate zero or more policy actions. A QoS policy
rule extends this definition to include 0..n provisioning actions,
o..k PHB actions and 0..m signaling actions, each defined by an object
or objects describing the action(s) to perform. This extension is done
seamlessly by requiring all QoS action classes to be subclasses of the
PolicyAction class defined in [PCIM]. As such, all QoS action
subclasses automatically inherit the two relationships
(PolicyActionInPolicyRule and PolicyActionInPolicyRepository) that are
used by a policy rule to aggregate actions. Actions are ordered
(as opposed to rules, which are prioritized). The order of actions is
specified in [PCIM] using the ActionOrder property.
The property SequencedActions in the aggregating instance of a
PolicyRule (see section 6.3.6 of [PCIM]) defines whether a specified
action order is required, recommended, or of no significance.
Ordering semantics depend on how actions are represented. If actions
are represented as separate objects that are aggregated by PolicyRule,
the PolicyActionInPolicyRule aggregation can be used to express an
order. In this case, three attributes are used:
- GroupComponent, which defines zero or more PolicyRules that can
contain the same PolicyAction
- PartComponent, which defines zero or more PolicyActions that are
contained by a given policyRule
- ActionOrder, which is an unsigned integer 'n' that indicates the
relative position of an action in the sequence of actions that are
associated with a given policy rule. When 'n' is a positive
integer, it indicates a place in the sequence of actions to be
performed, with smaller integers indicating earlier positions in
the sequence. The special value '0' indicates "don't care". If
two or more actions have the same non-zero sequence number, they
may be performed in any order, but they must all be performed at
the appropriate place in the overall action sequence.
For actions defined explicitly in a subclass of policyRule, the
ordering mechanism must be specified in the subclass definition. Note
that QPIM does not define any policyRule subclasses. Instead, the QPIM
defines subclasses of policyCondition and policyAction to extend the
semantics of these classes.
Provisioning, PHB and signaling actions can be intermixed in a QoS
policy rule. Policy consumers (such as PDPs) MAY separate the actions
into separate lists, but MUST respect the internal order of the
specified actions.
Snir, Ramberg, Strassner, Cohen expires May 2001 51
Draft-ietf-policy-qos-info-model-02.txt November 2000
4.7.1 Provisioning Actions
QoS policy provisioning actions configure traffic conditioner
elements, as specified in [DIFF-SERV-ARCH]. Actions configure meters,
markers, shapers and droppers.
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
Meters measure the temporal properties of a stream of packets
selected by a classifier against a traffic profile.
A meter is associated with a provisioning action using the
PolicyMeterInAction association. A meter can be shared among
(i.e., used by) policy actions of different rules. If this is desired,
then the meter SHOULD reside in a reusable-object repository.
Meters measure flows matching the rule condition per flow, per
interface, per role within a device, per device or per role across all
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.
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
Draft-ietf-policy-qos-info-model-02.txt November 2000
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
Code Point (DSCP), adding the marked packet to a particular DS
behavior aggregate. The marker may be configured to mark all packets
that it receives to a single DSCP, or may be configured to mark a
packet to one of a set of DSCPs used to select a PHB in a PHB group
according to the state of a meter. The marker may also be configured to
allow or not allow remarking of packets. When the marker changes the
DSCP in a packet, it is said to have "re-marked" the packet.
Provisioning actions can include both DSCP (re)marking as well as
802.1Q, Precedence and CoS marking. Precedence marking is required for
legacy devices, i.e., devices that do not support the full DSCP field
(6 bits) in the ToS byte of the IP packet header for IPv4. CoS marking
is required when crossing a link layer that supports QoS via CoS.
Snir, Ramberg, Strassner, Cohen expires May 2001 53
Draft-ietf-policy-qos-info-model-02.txt November 2000
The qosPolicyPRAction class contains a number of properties that can be
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
Shapers are used to delay some or all of the packets in a traffic
stream in order to bring the stream into compliance with a traffic
profile. A shaper usually has a finite-sized buffer, and packets may
be discarded if there is not sufficient buffer space to hold the
delayed packets.
Again, the qosPolicyPRAction class contains a number of properties that
can be used to control the behavior of a shaper. For example, the value
of the property qpExcessAction or qpViolateAction should be set to
'shape' in order to model a shaper. Traffic should be shaped according
to a traffic profile defined by a qosPolicyPRTrfcProf class.
4.7.1.4. Droppers
Droppers are used to discard some or all of the packets in a traffic
Stream. Usually, this is done in order to bring the stream into
compliance with a traffic profile. This process is also known as
"policing" the stream.
Again, the qosPolicyPRAction class contains a number of properties that
can be used to control the behavior of a shaper. For example, the value
of the property qpExcessAction or qpViolateAction should be set
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
Draft-ietf-policy-qos-info-model-02.txt November 2000
4.7.1.5 Examples
Below are two examples on how this document models rules specifying
provisioning actions to be enforced on the edge of a differential
service domain.
Example 1:
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:
Action 1:
Object: qosPolicyPRAction
qpMarkValueType: DSCP
qpMarkValue: X
Action 2:
Object: qosPolicyPRAction
PolicyMeterInAction association to: Meter-1
qpExcessAction: Drop
Action 3:
Object: qosPolicyPRAction
PolicyMeterInAction association to: Meter-2
qpExcessAction: Drop
The meters and traffic profile can take the form of:
Meter 1:
Object: GpsPolicyMeter
gpMeterScope: interface
PolicyTrfcProfileInMeter association to: Profile-1
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
Draft-ietf-policy-qos-info-model-02.txt November 2000
Profile 2:
Object: QosPolicyPRTrfcProf
QpPRRate: 300Kb/sec
QpPRNormalBurst: 1000 bytes
Example 2: Conditioning traffic
Some PHBs require the successive application of a set of traffic
conditioners to properly process the traffic. An example of a policy
with two levels of traffic conditioning is the following:
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 drop out-of-profile packets.
This policy rule can be modeled by using two actions. The first action
measures the traffic against the first profile. If the traffic is
within this profile, then the traffic is (re)marked with a DSCP of 24.
If the traffic is out of profile, then the subsequent action measures
the traffic against the second higher profile. If the traffic is within
this profile, then the traffic is (re)marked with a DSCP of 25.
Otherwise, the traffic is out of profile, and it will be dropped.
In this way, an arbitrary cascading of traffic conditioners can be
constructed, where each action measures traffic against a higher
traffic profile and change only the out-of-profile action as required.
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.
Snir, Ramberg, Strassner, Cohen expires May 2001 56
Draft-ietf-policy-qos-info-model-02.txt November 2000
4.7.2 Per-Hop-Behavior Actions
A Per-Hop-Behavior (PHB) is a description of the externally observable
forwarding behavior of a DS node applied to a particular DS behavior
aggregate [DIFF-SERV-ARCH]. The approach taken here is that a PHB
action specifies both observable forwarding behavior (i.e., loss, delay
,jitter) as well as specifying the buffer and bandwidth resources that
needs to be allocated to each of the behavior aggregates in order to
achieve these observables. That is, a rule with a set of PHB actions
can specify that an EF packet must not be delayed more than 20 msec in
each hop. The same rule may also specify that that EF packets needs to
be treated with preemptive forwarding (priority queuing), and specify
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].
Description of the properties of the PHB Action that are directly
mapped to the diffserv MIB [DIFF-MIB] are aligned with the
definition in the MIB. We refer to the MIB for a thorough discussion of
these properties and for an explanation of why this minimal set of
parameters where chosen to describe each mechanism.
4.7.2.1 Bandwidth and Delay Management
PHB actions allows specifying the minimal bandwidth that should be
reserved for a class of traffic. The property qpMinBandwidth can be
specified either in Kb/sec or in percentage of the total available
bandwidth. The property qpBandwidthValueType is used to determine
whether percentage of fixed values are used.
The property qpForwardingPriority is used whenever preemptive
forwarding is required. A policy rule that defines EF PHB should
indicate a non zero forwarding priority. QpForwardingPriority holds an
integer value to enable multiple levels of preemptive forwarding where
higher values specifies higher priority.
The property qpMaxBandwidth specifies the maximal bandwidth that should
be allocated to a class of traffic. This property may be specified in
PHB actions with non-zero forwarding priority in order to guard against
starvation of other PHBs.
The properties qpMaxDelay and qpMaxJitter specifies limits on the per
hop delay and jitter in milliseconds for any given packet within a
traffic class. Enforcement of the maximal delay and jitter may require
use of preemptive forwarding as well as minimal and maximal bandwidth
controls. Enforcement of low max delay and jitter values may also
require fragmentation and interleave mechanisms over low speed links.
Snir, Ramberg, Strassner, Cohen expires May 2001 57
Draft-ietf-policy-qos-info-model-02.txt November 2000
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
Draft-ietf-policy-qos-info-model-02.txt November 2000
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
Draft-ietf-policy-qos-info-model-02.txt November 2000
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
Draft-ietf-policy-qos-info-model-02.txt November 2000
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
Draft-ietf-policy-qos-info-model-02.txt November 2000
The qosPolicyRSVPAction action includes a specification of the
Subset of RSVP flows on which the action should be taken. The following
parameters can be specified:
1. Direction - in/out
2. Message type - Path/Resv/PathErr/ResvErr
3. Service type - Guaranteed Service / Controlled Load / Null
4. Service style - SE, WF, FF
The direction refers to the direction of the flow, hence the
Direction of the RSVP Path messages. Therefore, out-direction policies
Control outgoing Path messages as well as incoming Resv messages.
4.7.3.1 Admission Control
The basic decision modeled by the qosPolicyRSVPAction class is
whether to admit or reject the RSVP request. The decision can be
based on comparison of the request TSPEC or FLOWSPEC against a meter.
This allows basing an admission decision both on the properties
of the reservation request itself as well as on the current
temporal resource allocation.
Meters allow enforcement of policies of the form: "Allow
allocation of resource via RSVP for flows coming from subnet x
up to a total aggregated rate of 256kb/sec". The meter tracks
the current state of resource allocated to subnet x, and
compares any new request for resources against a 256Kb/sec
traffic profile. A meter can be reused by two signaling actions
of two rules, indicating that the this meter should measure the
aggregated resource allocation for both rules.
Note that if a traffic profile is not provided, it is implicitly
assumed that the RSVP request should be accepted. Rejecting all RSVP
requests matching the condition is specified by a zero valued traffic
profile.
4.7.3.2 Forwarding Behavior
The qosPolicyRSVPInstallAction class provides control on the way
resource allocation requests are handles within the RSVP node,
without changing the content of the RSVP messages themselves. In
particular it allows instructing the RSVP node to:
1. Set the DSCP value of the flows for which the reservation
was made.
2. Set the preemption priority of the RSVP request.
Setting the DSCP of the flow on the edge of a differential
service core allow provisioning of QoS, end-to-end, over mixed
integrated and differential service clouds.
Snir, Ramberg, Strassner, Cohen expires May 2001 62
Draft-ietf-policy-qos-info-model-02.txt November 2000
An RSVP node is responsible for deciding whether to admit flows
or not, based on its available resources. Setting the preemption
priority [RSVP_PREEMP] allows the RSVP node to decide which of its
reservations should be admitted, and when to make room for a newer
reservation by preempting an already installed one.
This class should be extended to cover other COPS install
decisions if required.
4.7.3.3 Signaling Control
The qosPolicyRSVPSignalCtrlAction class provides control on the
content of RSVP signaling message and their processing rules. In
particular it may include the following controls:
1. Replace/add DCLASS object in RSVP message.
2. Replace/add Preemption priority object in RSVP message.
3. Trigger an error/warning RSVP message.
4. Instruct the RSVP node to proxy RSVP message as if sent by
the RSVP end nodes.
Modifying the content of messages can be enforced using a COPS
replacement decision. This class should be extended to cover other
object replacements and, in particular, replacement of policy objects.
Triggering errors and warnings is important in scenarios when there is
a need to notify the end nodes that their reservation is about to
expire and various other information.
There are scenarios in which it makes sense not to carry RSVP requests
end-to-end. An RSVP node on the boundary of a differential service core
may map the RSVP request to specific PHB by setting the DSCP on the
flow packets, without forwarding the Path message downstream. Still,
this RSVP node may send back an RSVP Resv message as if the receiver
has sent it, to complete the RSVP cycle.
4.7.3.4 Examples
Below is an example on how this document models rules specifying
a set of signaling actions:
Admit RSVP reservation requests for VoIP traffic with FF style
only if the request asks for less the 64Kb/sec. Do not allow
more than 5 VoIP reservations to be admitted on any single
interface. In this examples two actions are used to represent
the required policy.
qosPolicyRSVPAction 1:
qpRSVPMessageType: Resv
qpRSVPStyle: FF
PolicyMeterInAction association to: Meter-1
Snir, Ramberg, Strassner, Cohen expires May 2001 63
Draft-ietf-policy-qos-info-model-02.txt November 2000
qosPolicyRSVPAction 2:
qpRSVPMessageType: Resv
qpRSVPStyle: FF
PolicyMeterInAction association to: Meter-2
The two meters specify the different scopes of each of the meters and a
traffic profile. The first traffic profile limits the maximal resources
allocated to a single request while the second traffic profile limits
the number of reservations admitted at any given time.
gpsPolicyMeter Meter-1:
qpRSVPMeterScope: flow
PolicyTrfcProfileInMeter association to: Prof-1
gpsPolicyMeter Meter-1:
qpRSVPMeterScope: interface
PolicyTrfcProfileInMeter association to: Prof-2
qosPolicyRSVPTrfcProf Prof-1:
qpRSVPTokenRate: 64kb/sec
qosPolicyRSVPTrfcProf Prof-2:
qpRSVPSessionNum: 5
The various attributes of RSVP traffic profiles are described in the
next section.
4.8. Meters and 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
compared with flow meters. RSVP traffic profiles are compared with
RSVPTSPEC and FLOWSPEC parameters, and with meters aggregating the
temporal state of admitted RSVP reservations and states.
Snir, Ramberg, Strassner, Cohen expires May 2001 64
Draft-ietf-policy-qos-info-model-02.txt November 2000
4.8.1. Provisioning traffic profiles
Shaping, policing and remarking provisioning actions compare a
provisioning traffic profile against a meter. The provisioning traffic
profile is a template containing rate and burst values, modeled
by the qosPolicyPRTrfcProf class.
The qosPolicyPRTrfcProf class includes the following properties:
1. Rate measured in kbits/sec.
2. Normal burst measured in bytes.
3. Excess burst measured in bytes.
Rate determines the long-term average transmission rate. Traffic
That falls under this rate will always conform. The normal burst size
determines how large traffic bursts can be before some traffic
exceeds the traffic profile. The Excess Burst size determines how large
traffic bursts can be before all traffic exceeds the rate limit.
Traffic
that falls between the normal burst size and the Excess Burst size
exceeds the traffic profile with a probability that increases as the
burst size increases. This provides a Random Discard mechanism for
policers, markers and shapers.
Excess burst size SHOULD be greater than or equal to the normal
burst size. If the excess burst size is not specified, it is assumed
that excess burst size is equal to the normal burst size. In this
case, burst larger than the normal burst size will always be counted
as out-of-profile packets.
Snir, Ramberg, Strassner, Cohen expires May 2001 65
Draft-ietf-policy-qos-info-model-02.txt November 2000
4.8.2. RSVP traffic profiles
RSVP signaling QoS policy can condition the decision whether to accept
or deny an RSVP request based on the traffic specification of the flow
(TSPEC) or the amount of QoS resources requested (FLOWSPEC). The TSPEC
and FLOWSPEC objects are either compared directly with a traffic
profile, or aggregated to a meter that measures the temporal admitted
RSVP states and than compared to the traffic specification. The
qosPolicyRSVPTrfcProf class models such a traffic profile. The
qosPolicyRSVPTrfcProf class has the following properties:
1. Token Rate (r) measured in bits/sec.
2. Peak Rate (p) measured in bits/sec.
3. Bucket Size (b) measured in bytes.
4. Min Policed unit (m) measured in bytes.
5. Max packet size (M) measured in bytes.
6. Resv Rate (R) measured in bits/sec.
7. Slack term (s) measured in microseconds.
8. Number of sessions.
The first 5 parameters are the traffic specification parameters used in
the integrated service architecture. These parameters are used to
define a sender TSPEC as well as FLOWSPEC for the Controlled Load
service [CL]. For a definition and full explanation of their meaning,
please refer to [RSVP-IS]. Parameters 6 and 7 are the additional
parameters used for specification of the Guaranteed Service FLOWSPEC
[GS]. The last parameter is used to specify the maximum number of
allowed RSVP sessions. This provides an easy way to limit the number of
admitted RSVP requests without requiring pre-knowledge of the
aggregated rates requested.
A partial order is defined between TSPECs (and FLOWSPECs). A TSPEC A is
larger than TSPEC B if and only if rA>rB, pA>pB, bA>bB, mA<mB and
MA>MB. A TSPEC measured against a traffic profile uses the same
ordering rule. An RSVP message is accepted only if its TSPEC (FLOWSPEC)
is either smaller or equal to the traffic profile. Only parameters
specified in the traffic profile are compared.
The GS FLOWSPEC is also compared against the rate R and the slack term
S. R should not be larger than the traffic profile R parameter, while
the FLOWSPEC slack term should not be smaller than that specified in
the slack term.
TSPECs as well as FLOWSPECs can be added. The sum of two TSPECs is
computed by summing the rate r, the peak rate p, the bucket size b, and
by taking the minimum of min policed unit m and the maximum of the max
packet size M. GS FLOWSPECs are summed by adding the Resv rate and
minimizing the slack term s. These rules are used to compute a meter
that measures the temporal state of admitted RSVP states. The meter is
than compared with the traffic profile specified in the signaling
Snir, Ramberg, Strassner, Cohen expires May 2001 66
Draft-ietf-policy-qos-info-model-02.txt November 2000
policy using the same rules for comparison of TSPECs (FLOWSPECs) to a
traffic profile.
5. Decision strategy
Section 5.1 discusses how policy rules are organized into containers so
that decision strategies can be applied to groups of policy rules.
Section 5.2 defines two different decision strategies. Section 5.3
provides examples to illustrate how the different decision strategies
affect the policy rules they operate on.
5.1 Organizing the Application of Decision Strategies
This document recommends the following approach to be used by policy
servers and other policy decision points in the network for QoS
applications. The set of policies to be used is managed by first
assigning them to their respective policy domains or reusable-object
repositories. The policy rules will then be grouped into a set of
gpsPolicyGroup groups. The organization of these gpsPolicyGroup groups
is to be used to reflect any administrative, geographical, or other
constraints that should be enforced by the policy system. This set of
gpsPolicyGroup groups is used to partition behavior in the different
QoS policy domains.
The goal is to ensure that different policy servers using the same
group of policy rules will enforce consistent behavior. That is, they
will treat the conditions of the rules in the same way, and execute the
same actions in the same order. Therefore, the priority of the policy
rules must be pre-defined and the decision strategy implemented by each
different policy server must be defined explicitly.
The decision strategy is defined per domain and can be overridden by
any PolicyDomain or gpsPolicyGroup instances that are contained within
the domain. When a policy decision point evaluates a set of rules, it
implements the decision strategy defined in each PolicyDomain or
gpsPolicyGroup instance for that set of rules. Nested PolicyDomain or
gpsPolicyGroup instances can override the decision strategy of the
PolicyDomain or gpsPolicyGroup instances that contain them.
The order of decision making for policy rules is based on the rule
priority of PCIM. However, this rule priority has been extended in two
important ways. The first is that nested rules can be defined. For
nested rules, the contained, or innermost, rule has a higher priority
than the containing, or outermost, rule. The second extension is that
the gpsPolicyGroup class is given its own priority. This enables it to
be treated in the same way that a PolicyRule is. In fact, this is
purposely done so that the priority of a PolicyRule can be directly
compared to the priority of a gpsPolicyGroup. The comparison is done
for all instances at the same nesting level.
Notice that nested rules are affected in the following way from their
containing rules:
Snir, Ramberg, Strassner, Cohen expires May 2001 67
Draft-ietf-policy-qos-info-model-02.txt November 2000
1. The containing rule's condition list is ANDed to the sub-rule
condition list.
2. The containing rule actions are added to the sub-rule action list
and performed in the appropriate order BEFORE the sub-rule actions.
The following example helps clarify rule and sub-rule policy
application. Rule 1.1 is nested within Rule 1 in the following form:
Rule 1: If (Condition A) then Action A
|
+--- Rule 1.1 If (Condition B) then Action B
These two rules can be ordered in a non hierarchical form and enforced
as follows:
Rule 1.1 If (Condition A AND Condition B) then Action A, Action B
Rule 1: If (Condition A) then Action A
Replacing the conditions and actions with concrete values:
Rule 1: If (UDP) then guarantee 50% BW.
|
+--- Rule 1.1 If (TFTP) then Mark to DSCP=3
Leads to:
Rule 1.1 IF (UDP AND TFTP)
THEN guarantee 50% BW sharing queue x, Mark DSCP=3
Rule 1: IF (UDP)
THEN guarantee 50% BW sharing queue x.
5.2 Decision Strategies
Many different types of decision strategies can be defined. This
section defines two different decision strategies:
1. "FIRST MATCH"
2. "MATCH ALL"
5.2.1. First Match Decision Strategy
The first match decision strategy is defined as a process that
evaluates the policy rules in the defined order, evaluating the
conditions of each rule, until a condition is evaluated to TRUE. The
rule's actions are then applied and the process of decision-making is
terminated.
5.2.2. Match All Decision Strategy
The match all decision strategy is defined as first scanning the
complete set of rules according to their defined order of priority and
then applying the actions of each rule that satisfies the rule's
conditions. This matching strategy may in many cases mean that a
Snir, Ramberg, Strassner, Cohen expires May 2001 68
Draft-ietf-policy-qos-info-model-02.txt November 2000
number of rules may satisfy the same set of conditions, and all of
their actions will be applied.
A Match All strategy may result in applying conflicting rules. Handling
conflicts is outside the scope of this draft. The implementers of QoS
systems must provide proprietary conflict detection and avoidance or
resolution mechanisms to use this or any type of decision strategy that
allows the execution of more than one rule for a given condition.
5.3. Decision Strategy example
This section demonstrates both decision strategies and rule
prioritization. The rules to be evaluated are shown in Figure 4 below.
Domain
|
+--Rule1 (priority 19)
|
+--PolicyContainer1 (priority 5)
| |
| +--Rule 1.1 (priority 3)
| |
| +--Rule 1.2 (priority 33)
|
+--Rule3 (priority 4)
|
+--Rule4 (priority 2)
Figure 4: Decision Strategy example
This figure illustrates two extensions to PCIM. The first is that a
special type of PolicyGroup, the gpsPolicyGroup, can be assigned a
priority and have its priority compared to other PolicyRules and
gpsPolicyGroups. The second is rule nesting, as illustrated by Rule 3
and Rule 4.
The order of rule processing for the example above is:
1. Rule1 (higher priority between Rule1, PolicyContainer1 and Rule3
2. Rule1.2 (both Rule 1.1 and 1.2 will be considered next, because
the priority of PolicyContainer1 is higher than the priority of
Rule 3; Rule 1.2 executes next because its priority is higher
than the priority of Rule1.1)
3. Rule1.1 (because its container has a higher priority than Rule3
4. Rule4 (because it is nested in Rule 3)
5. Rule3
If the decision strategy of the domain is 'first-match' and it is not
overridden by PolicyContainer1, the decision process will stop once a
rule's condition is matched.
Snir, Ramberg, Strassner, Cohen expires May 2001 69
Draft-ietf-policy-qos-info-model-02.txt November 2000
If the decision strategy of the domain is 'match-all' and it is not
overridden by PolicyContainerr1, the match all decision process will
run over all rules according to the order above.
If the decision strategy of the domain is 'first-match' and the
decision process of PolicyContainer1 is match all, Rule1 will be
evaluated first. If its condition matches, the decision process stops.
Else, both Rules 1.1 and 1.2 will be evaluated (because the priority of
the named container is higher than the priority of Rule 3). However,
since the decision strategy is overridden in the named container, one
or both of Rule 1.1 and Rule 1.2 will be executed if their conditions
match. If one or both of these rules in the named container
match, the decision process stops. Else Rules 3 and 4 will be evaluated
using 'first-match' decision strategy.
If the decision strategy of the domain is 'match-all' and the decision
process of PolicyContainer1 is first match, the decision process will
evaluate Rule1 and continue to evaluate both the PolicyContainer1 rules
as well as Rule 3. Rules 1.1 and 1.2 will be evaluated using first
match strategy. The decision process continues to evaluate rules 3 and
4 according to a 'match-all' decision strategy.
6. Per Hop Behavior
A per-hop behavior (PHB) is a description of the externally
observable forwarding behavior of a DS node applied to a particular DS
Behavior aggregate. A PHB is selected at a node by the DSCP contained
in a received packet. A set of PHBs is enforced on a QoS domain.
The set of PHBs share buffer and scheduler resources among them.
QPIM provides the means for defining a set of PHBs per qos
domain by definition of a gpsPolicyGroup that includes a set of
PHB rules. Each of this rules would classify packets based on DSCP
value and define the action to be performed on this qos Class.
PHB sets can be defined as reusable objects in the policy
reusable-object repository to allow different domains to share
the same per hop behavior.
Snir, Ramberg, Strassner, Cohen expires May 2001 70
Draft-ietf-policy-qos-info-model-01.txt November 2000
7. QoS Policy Class Inheritance
The following diagram illustrates the class hierarchy for the
QPIM. Relevant classes from the PCIM are also included for
completeness:
top
|
+--policy (abstract, [PCIM])
| |
| +--policyGroup ([PCIM])
| | |
| | +--qosPolicyDomain
| | |
| | +--gpsPolicyGroup
| |
| +--policyRule ([PCIM])
| |
| +--policyCondition ([PCIM])
| | |
| | +--policyTimePeriodCondition ([PCIM])
| | |
| | +--vendorPolicyCondition ([PCIM])
| | |
| | +--gpsPolicySimpleCondition
| | |
| | +--gpsPolicyCompoundCondition
| |
| +--policyAction ([PCIM])
| | |
| | +--vendorPolicyAction ([PCIM])
| | +-- qosPolicyPRAction
| | |
| | +-- qosPolicyPHBAction
| | |
| | +-- qosPolicyRSVPAction
| | |
| | +-- qosPolicyRSVPSignalCtrlAction
| | |
| | +-- qosPolicyRSVPInstallAction
| |
| +--gpsPolicyVariable
| |
| +--gpsPolicyValue(abstract)
| | |
| | +--gpsPolicyIPv4AddrValue
| | |
| | +--gpsPolicyIPv6AddrValue
| | |
| | |
(diagram continued in next page)
Snir, Ramberg, Strassner, Cohen expires May 2001 71
Draft-ietf-policy-qos-info-model-01.txt November 2000
(continued from the previous page)
top
| | +--gpsPolicyMACAddrValue
| | |
| | +--gpsPolicyStringValue
| | |
| | +--gpsPolicyBitStringValue
| | |
|
+--policy (abstract, [PCIM])
| |
| +--gpsPolicyValue (abstract)
| | |
| | +--gpsPolicyDNValue
| | |
| | +--gpsPolicyAttributeValue
| | |
| | +--gpsPolicyIntegerValue
| |
| +-- gpsPolicyMeter
| |
| +-- qosPolicyQueue
| |
| +-- gpsPolicyTrfcProf
| |
| +-- qosPolicyPRTrfcProf
| |
| +-- qosPolicyRSVPTrfcProf
|
|
+--CIM_ManagedSystemElement (abstract)
|
+--CIM_LogicalElement (abstract)
|
+--CIM_System (abstract)
|
+---CIM_AdminDomain (abstract)
|
+---PolicyRepository
Figure 5. Class Inheritance Hierarchy for the QPIM
The reader is encouraged to read section 6 and section 7 of [PCIM] in
their entirety. Section 6 defines all of the object classes listed
above, and section 7 defines the concepts of associations and
aggregations.
Snir, Ramberg, Strassner, Cohen expires May 2001 72
Draft-ietf-policy-qos-info-model-01.txt November 2000
Ten associations and aggregations are defined in the [PCIM] as follows:
the Aggregation PolicyGroupInPolicyGroup
the Aggregation PolicyRuleInPolicyGroup
the Aggregation PolicyConditionInPolicyRule
the Aggregation PolicyRuleValidityPeriod
the Aggregation PolicyActionInPolicyRule
the Association PolicyConditionInPolicyRepository
the Association PolicyActionInPolicyRepository
the Weak Aggregation PolicyGroupInSystem
the Weak Aggregation PolicyRuleInSystem
the Aggregation PolicyRepositoryInPolicyRepository
QPIM reuses the PCIM associations and aggregations listed above and
defines the following new associations and aggregations in the
following hierarchy:
(the diagram is in the next page)
Snir, Ramberg, Strassner, Cohen expires May 2001 73
Draft-ietf-policy-qos-info-model-01.txt November 2000
[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
Draft-ietf-policy-qos-info-model-02.txt November 2000
8. Class Definitions
8.1. The Aggregation "PolicyGroupInPolicyRule"
A policy rule may aggregate one or more policy groups, via the
PolicyGroupInPolicyRule aggregation. Grouping of policy groups and
their subclasses into a policy rule is for administrative convenience,
scalability and manageability, as it enables more complex policies to
be constructed from multiple simpler policies. For example, a
PolicyRule may aggregate PolicyGroups and gpsPolicyGroups via this
aggregation.
Policy rules do not have to contain policy groups. In addition, a
policy group may also be used by itself, without belonging to a policy
rule and policy rules may be individually aggregated by other policy
rules by the PolicyRuleInPilicyRule aggregation (section 8.Z.). Note
that it is assumed that this aggregation is used to form directed
acyclic graphs and NOT ring structures.
The class definition for this aggregation is as follows:
NAME PolicyGroupInPolicyRule
DERIVED FROM PolicyComponent (defined in [PCIM])
ABSTRACT False
PROPERTIES GroupComponent[ref PolicyRule[0..n]]
PartComponent[ref PolicyGroup[0..n]]
8.1.1. The Reference "GroupComponent"
This property is inherited from PolicyComponent, and overridden
To become an object reference to a PolicyRule that contains one or
More PolicyGroups. Note that for any single instance of the
aggregation class PolicyGroupInPolicyRule, this property (like all
Reference properties) is single-valued. The [0..n] cardinality
indicates that there may be 0, 1 or more PolicyRules that contain any
given PolicyGroup.
8.1.2. The Reference "PartComponent"
This property is inherited from PolicyComponent, and overridden
to become an object reference to a PolicyGroup contained by one or
more PolicyRules. Note that for any single instance of the
aggregation class PolicyGroupInPolicyRule, this property (like all
Reference properties) is single-valued. The [0..n] cardinality
indicates that a given PolicyRule may contain 0, 1, or more than one
PolicyGroup.
Snir, Ramberg, Strassner, Cohen expires May 2001 75
Draft-ietf-policy-qos-info-model-01.txt November 2000
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
Draft-ietf-policy-qos-info-model-01.txt November 2000
8.3. The Aggregation "PolicyConditionInCompoundCondition"
A policy compound condition may aggregate one or more policy
conditions, via the PolicyConditionInCompoundCondition aggregation.
Grouping of policy conditions and their derivatives into a policy
compound condition is for reusability of partial or full Boolean
condition statements.
A qosPolicyCompoundCondition may aggregate PolicyConditions and
their derivatives, such as qosPolicySimpleConditions and
qosPolicyCompoundConditions. The properties GroupNumber and
ConditionNegated are inherited from PolicyConditionInPolicyRule and are
specified per instance of this aggregation class. There is no change in
their semantics, so they are not redefined here. However, the
GroupComponent and PartComponent properties DO have modified semantics,
and so they are described below. The class definition for this
aggregation is as follows:
NAME PolicyConditionInCompoundCondition
DERIVED FROM PolicyConditionInPolicyRule (defined in [PCIM])
ABSTRACT False
PROPERTIES GroupComponent[ref gpsPolicyCompoundCondition[0..n]]
PartComponent[ref PolicyCondition[0..n]]
8.3.1. The Reference "GroupComponent"
This property is inherited from PolicyComponent, and overridden to
become an object reference to a gpsPolicyCompoundCondition that
contains one or more PolicyConditions. Note that for any single
instance of the aggregation class PolicyConditionInCompoundCondition,
this property is single-valued. The [0..n] cardinality indicates that
there may be 0, 1 or more gpsPolicyCompoundCondition objects that
contain any given policyCondition object, or its subclasses.
8.3.2. The Reference "PartComponent"
This property is inherited from PolicyComponent, and overridden to
become an object reference to a PolicyCondition contained by one
or more gpsPolicyCompoundConditions. Note that for any single instance
of the aggregation class PolicyConditionInPolicyRule, this property is
single-valued. The [0..n] cardinality indicates that a given
gpsPolicyCompoundCondition may contain 0, 1 or more1 PolicyConditions
(or subclasses of PolicyCondition).
8.4. The aggregation "PolicyVariableInPolicySimpleCondition"
QoS policy simple conditions are represented as the ordered
triplet {variable, operator, value}. The PolicyElement class is
the common superclass for the PolicyVariable and PolicyValue classes
and their subclasses. A gpsPolicySimpleCondition associates exactly
Snir, Ramberg, Strassner, Cohen expires May 2001 77
Draft-ietf-policy-qos-info-model-01.txt November 2000
one gpsPolicyVariable via the PolicyVariableInPolicySimpleCondition
aggregattion. This aggregation links a subclass of PolicyElement to the
gpsPolicySimpleCondition in whose scope the PolicyElement subclass is
defined.
The class definition for this aggregation is as follows:
NAME PolicyVariableInPolicySimpleCondition
DERIVED FROM PolicyComponent (defined in [PCIM])
ABSTRACT False
PROPERTIES GroupComponent[ref gpsPolicySimpleCondition[0..n]]
Partcomponent[ref gpsPolicyVariable[1..1] ]
8.4.1. The Reference "GroupComponent"
This property is inherited from PolicyComponent, and overridden to
become an object reference to a gpsPolicySimpleCondition that contains
exactly one gpsPolicyVariable. Note that for any single instance of the
aggregation class policyVariableInPolicySimpleCondition, this property
is single-valued. The [0..n] cardinality indicates that there may be 0,
1 or more gpsPolicySimpleCondition objects that contain any given
gpsPolicyVariable object, or its subclasses.
8.4.2. The Reference "PartComponent"
This property is inherited from Dependency, and overridden to become an
object reference to a PolicyVariable class (or one of its subclasses)
that is defined within the scope of a gpsPolicySimpleCondition. Note
that for any single instance of the association class
PolicyVariableInPolicySimpleCondition, this property (like all
reference properties) is single-valued. The [1..1] cardinality
indicates that a qpsPolicySimpleCondition must have exactly one
PolicyVariable class (or one of its subclasses) defined within its
scope in order to be a meaningful.
8.5. The Aggregation "PolicyValueInPolicySimpleCondition"
QoS policy simple conditions are represented as the ordered triplet
{variable, operator, value}. The PolicyElement class is the common
superclass for the PolicyVariable and PolicyValue classes and their
subclasses. A gpsPolicySimpleCondition associates exactly one
gpsPolicyValue via the PolicyValueInPolicySimpleCondition aggregation.
This aggregation links a subclass of PolicyElement to the
gpsPolicySimpleCondition in whose scope the PolicyElement subclass is
defined.
Snir, Ramberg, Strassner, Cohen expires May 2001 78
Draft-ietf-policy-qos-info-model-02.txt November 2000
The class definition for this association is as follows:
NAME PolicyValueInPolicySimpleCondition
DERIVED FROM PolicyComponent (defined in [PCIM])
ABSTRACT False
PROPERTIES GroupComponent[ref gpsPolicySimpleCondition[0..n]]
PartComponent[ref gpsPolicyValue[1..1]]
8.5.1. The Reference "GroupComponent"
This property is inherited from PolicyComponent, and overridden to
become an object reference to a gpsPolicySimpleCondition that contains
exactly one gpsPolicyValue. Note that for any single instance of the
aggregation class PolicyValueInPolicySimpleCondition, this property is
single-valued. The [0..n] cardinality indicates that there may be 0, 1
or more gpsPolicySimpleCondition objects that contain any given
gpsPolicyValue object, or its subclasses.
8.5.2. The Reference "PartComponent"
This property is inherited from Dependency, and overridden to become an
object reference to a PolicyValue class (or one of its subclasses) that
is defined within the scope of a gpsPolicySimpleCondition. Note that
for any single instance of the association class
PolicyValueInPolicySimpleCondition, this property (like all reference
properties) is single-valued. The [1..1] cardinality indicates that a
qpsPolicySimpleCondition must have exactly one PolicyValue class (or
one of its subclasses) defined within its scope in order to be a
meaningful.
8.6. The Association "PolicyElementInPolicyRepository"
Policy objects (e.g., policy variables, values and other reusable
policy objects) can be made reusable. Reusable policy elements are
always related to a single PolicyRepository via the
PolicyElementInPolicyRepository association.
Policy conditions can use this association to assign reusable policy
variables and/or values. Note that either policy variables and/or
values do not have to be reused. In order to construct policy
conditions of this form, use the PolicyVariableInPolicySimpleCondition
and PolicyValueInPolicySimpleCondition weak associations as
appropriate.
The class definition for this association is as follows:
NAME PolicyElementInPolicyRepository
DERIVED FROM PolicyInSystem
ABSTRACT FALSE
PROPERTIES Antecedent[ref PolicyRepository[0..1]]
Dependent[ref Policy[0..n]]
Snir, Ramberg, Strassner, Cohen expires May 2001 79
Draft-ietf-policy-qos-info-model-01.txt November 2000
8.6.1. The Reference "Antecedent"
This property is inherited from PolicyInSystem, and overridden to
become an object reference to a PolicyRepository containing one or more
Policy objects. A reusable Policy object is always related to exactly
one PolicyRepository via the PolicyElementInPolicyRepository
association. The [0..1] cardinality for this property signifies
whether the Policy object is reusable or not. If it is 0, then the
association is not instantiated, which means that this Policy object is
specific to a single PolicyCondition. If this association is
instantiated, then it means that the Policy object (subclass) is
reusable, and is located in this specific PolicyRepository.
8.6.2. The Reference "Dependent"
This property is inherited from PolicyInSystem, and overridden to
become an object reference to a Policy object, or inheriting class
included in a PolicyRepository. If this association is not instantiated
(the "0" part of the cardinality), then this Policy object is embedded
(or attached) directly to the containig object. However, if this
association is instantiated, then the [0..n] cardinality indicates that
a given PolicyRepository may contain 0, 1, or more than one Policy
objects.
8.7. The Association "PolicyValueConstraintsInVariable"
This association links a gpsPolicyValue object to a gpsPolicyVariable
object, modeling specific value constraints. For example, the
gpsPolicyVariable assignment/binding may be constrained to a specific
value of IP Address. The constraints then are twofold. First, one may
want to constrain the set of allowable address values. Second, one may
want to ensure that the variable is of the correct data type. This
latter is provided by Table 1, which defines the set of value types
that each type of PolicyVariable can assume.
The class definition for the association is as follows:
NAME PolicyValueConstraintsInVariable
DESCRIPTION A class representing the association of a constraints
object to a variable object
DERIVED FROM Dependency (defined in [PCIM])
ABSTRACT FALSE
PROPERTIES Antecedent[ref gpsPolicyVariable[0..1]]
Dependent[ref gpsPolicyValue [0..n]]
Snir, Ramberg, Strassner, Cohen expires May 2001 80
Draft-ietf-policy-qos-info-model-01.txt November 2000
8.7.1. The Reference "Antecedent"
This property is inherited from Dependency. Its type is and
cardinality are overridden to provide the semantics of a variable
optionally having value constraints. This property itself is an object
reference to a policy variable (gpsPolicyVariable) that is optionally
constrained by one or more policy value class instances
(gpsPolicyValue).
8.7.2. The Reference "Dependent"
This property is inherited from Dependency, and overridden to become an
object reference to a gpsPolicyValue that is used to constrain the
values that a particular gpsPolicyVariable can have. The [0..n]
cardinality indicates that a given policy variable may have 0, 1 or
more gpsPolicyValues defined to model the constraints on the
values that the policy variable can take.
8.8. The Association "PolicyMeterInAction"
This association links a gpsPolicyMeter object modeling a specific
meter to a qosPolicyPRAction or a qosPolicyRSVPAction object.
The class definition for the association is as follows:
NAME PolicyMeterInAction
DESCRIPTION A class representing the association between a
gpsPolicyMeter object and a specific meter object.
DERIVED FROM Dependency
ABSTRACT FALSE
PROPERTIES Antecedent[ref PolicyAction[0..n]
Dependent[ref gpsPolicyMeter [0..n]
8.8.1. The Reference "Antecedent"
This property is inherited from Dependency. It serves as an object
reference to either a qosPolicyPRAction or a qosPolicyRSVPAction. The
[0..n] cardinality indicates that a given meter may be referenced by 0,
or 1 more policy actions.
8.8.2. The Reference "Dependent"
This property is inherited from Dependency, and is overridden to
become an object reference to a gpsPolicyMeter.
The [0..n] cardinality indicates that a given policy action may have 0
or more gpsPolicyMeter objects to which it applies.
Snir, Ramberg, Strassner, Cohen expires May 2001 81
Draft-ietf-policy-qos-info-model-02.txt November 2000
8.9. The Association "PolicyTrfcProfileInMeter"
This association links a gpsPolicyTrfcProf object modeling a specific
traffic profile to a gpsPolicyMeter object.
The class definition for this association is as follows:
NAME PolicyTrfcProfileInMeter
DESCRIPTION A class representing the association between a
traffic profile that is used for provisioning and a
meter.
DERIVED FROM Dependency
ABSTRACT FALSE
PROPERTIES Antecedent[ref gpsPolicyMeter [0..n]]
Dependent[ref gpsPolicyTrfcProf [0..1]]
8.9.1. The Reference "Antecedent"
This property is inherited from Dependency. It serves as an object
reference to a meter that uses a traffic profile object to provision
flows. The [0..n] cardinality indicates that a given meter may use zero
or more traffic profiles.
8.9.2. The Reference "Dependent"
This property is inherited from Dependency, and overridden to become an
object reference to a traffic profile used by a meter. The [0..n]
cardinality indicates that a given traffic profile may be used by 0 or
more meters.
8.10. The Weak Association " PolicyQueueInPHBAction "
This association links a qosPolicyQueue object modeling a specific
queue to a QoSPolicyPHBAction object.
The class definition for this association is as follows:
NAME PolicyQueueInPHBAction
DESCRIPTION A class representing the association between a queue
and a PHB action.
DERIVED FROM Dependency
ABSTRACT FALSE
PROPERTIES Antecedent[ref qosPolicyPHBAction[0..n]]
Dependent[ref qosPolicyQueue [0..n]]
8.10.1. The Reference "Antecedent"
This property is inherited from Dependency. It serves as an object
reference to a qosPolicyPHBAction that references a qosPolicyQueue. The
[0..n] cardinality indicates that a given queue may be referenced by 0
or more PHB actions.
Snir, Ramberg, Strassner, Cohen expires May 2001 82
Draft-ietf-policy-qos-info-model-02.txt November 2000
8.10.2. The Reference "Dependent"
This property is inherited from Dependency, and overridden to become an
object reference to a qosPolicyQueue defined within the scope of a
qosPolicyPHBAction. The [0..n] cardinality indicates that a given PHB
action may be used by zero or more qosPolicyQueues.
8.11. The Association "PolicyConformNextAction"
This association links an action using a meter with an object defining
an action to be applied on the conforming traffic, as defined by the
relevant traffic profile.
The class definition for this association is as follows:
NAME PolicyConformNextAction
DESCRIPTION A class representing the association between two
action object in order to model action to be applied
on traffic conforming to an associated traffic
profile.
DERIVED FROM Dependency
ABSTRACT FALSE
PROPERTIES Antecedent[ref QoSPolicyPRAction[0..1]]
Dependent[ref QoSPolicyPRAction [0..1]]
8.11.1. The Reference "Antecedent"
This property is inherited from Dependency. It serves as an object
reference to a qosPolicyPRAction object, which provides scoping for the
next action to be applied on conforming traffic. This next action is
modeled by a QoSPolicyPRAction object. The [0..1] cardinality means
that a given qosPolicyPRAction may define 0 or 1 qosPolicyPRAction
objects to use as its conforming action.
8.11.2. The Reference "Dependent"
This property is inherited from Dependency, and overridden to
become an object reference to a qosPolicyPRAction object that is
defined within the scope another QoSPolicyPRAction. The [0..1]
cardinality indicates that a given conforming action (modeled using a
qosPolicyPRAction object) may be used by 0 or 1 qosPolicyPRAction
objects.
Snir, Ramberg, Strassner, Cohen expires May 2001 83
Draft-ietf-policy-qos-info-model-02.txt November 2000
8.12. The Association "PolicyExcessNextAction"
This association links another action using a meter with an object
defining an action to be applied on excess traffic, as defined by the
relevant traffic profile.
The class definition for this association is as follows:
NAME PolicyExcessNextAction
DESCRIPTION A class representing the association between two
action objects in order to model action to be applied
on traffic in excess to an associated traffic
profile.
DERIVED FROM Dependency
ABSTRACT FALSE
PROPERTIES Antecedent[ref QoSPolicyPRAction[0..1]]
Dependent[ref QoSPolicyPRAction [0..1]]
8.12.1. The Reference "Antecedent"
This property is inherited from Dependency. It serves as an object
reference to a qosPolicyPRAction that provides a scope for the next
action applied on excess traffic, modeled by a qosPolicyPRAction
object. The [0..1] cardinality indicates that a given qosPolicyPRAction
object may have 0 or 1 qosPolicyPRAction objects defined to process
excess traffic.
8.12.2. The Reference "Dependent"
This property is inherited from Dependency, and overridden to
become an object reference to a qosPolicyPRAction that is handling the
excess traffic defined within the scope of another qosPolicyPRAction
object. The [0..1] cardinality indicates that a given excess action,
modeled as a qosPolicyPRAction object, may be used by 0 or 1
qosPolicyPRAction objects.
8.13. The Association "PolicyViolateNextAction"
This association links an action using a meter with an object defining
an action to be applied on the violating traffic, as a defined by the
relevant traffic profile.
The class definition for this association is as follows:
NAME PolicyExcessNextAction
DESCRIPTION A class representing the association between two
action objects in order to model action to be applied
on traffic in violation to an associated traffic
profile.
DERIVED FROM Dependency
ABSTRACT FALSE
Snir, Ramberg, Strassner, Cohen expires May 2001 84
Draft-ietf-policy-qos-info-model-02.txt November 2000
PROPERTIES Antecedent[ref QoSPolicyPRAction[0..1]]
Dependent[ref QoSPolicyPRAction [0..1]]
8.13.1. The Reference "Antecedent"
This property is inherited from Dependency. It serves as an object
reference to a qosPolicyPRAction that provides a scope for the next
action to be applied on violating traffic, modeled by a
qosPolicyPRAction object. The [0..1] cardinality indicates that a given
qosPolicyPRAction object may have 0 or 1 qosPolicyPRAction objects
defined to process violating traffic.
8.13.2. The Reference "Dependent"
This property is inherited from Dependency, and overridden to
become an object reference to a qosPolicyPRAction defined within the
scope of another qosPolicyPRAction object. The [0..1] cardinality
indicates that a given violating action, modeled as a qosPolicyPRAction
object, may be used by 0 or 1 QoSPolicyPRAction objects.
8.14. Class qosPolicyDomain
This class defines the root of a single administrative QoS policy
domain, and contains the domain's policy rules and definitions. This
enables the administrator to partition the set of QoS information into
different domains, where each domain has a potentially different set of
PHBs and policies, access rules, decision strategy or other application
of the policy information organized in some fashion. The class
definition is as follows:
NAME qosPolicyDomain
DERIVED FROM policyGroup (defined in [PCIM])
ABSTRACT False
PROPERTIES qpDomainName, qpPolicyRuleMatchMethod
8.14.1. The Property qpDomainName
This property provides a user-friendly name for the QoS policy domain.
Its definition is as follows:
NAME qpDomainName
SYNTAX String
Snir, Ramberg, Strassner, Cohen expires May 2001 85
Draft-ietf-policy-qos-info-model-02.txt November 2000
8.14.2. The Property qpPolicyRuleMatchMethod
This property defines the decision strategy to be applied on this set
of QoS policy rules by policy servers. It is an enumerated integer that
defines two values, first match and match all. Please see section 5 of
this document for more information on these decision strategies. Its
definition is as follows:
NAME qpPolicyRuleMatchMethod
SYNTAX Integer (ENUM) - {"FIRST MATCH " = 0; "MATCH ALL " = 1 }
8.15. Class gpsPolicyGroup
This class represents an administratively-defined policy rule
container. All policies that are commonly administered are defined in a
particular gpsPolicyGroup. For example, an administrator could define a
set of policies that serve a certain goal, or service a certain type of
application, or that handle a certain type of flow or device. Placing
these policies in a gpsPolicyGroup that resides in a particular
qosPolicyDomain enables the administrator to group different sets of
policy rules that perform different types of operations. It also
enables an organization to partition policies according to the
administrator (or other entity) that manages the policies.
The class definition is as follows:
NAME gpsPolicyGroup
DERIVED FROM policyGroup (defined in [PCIM])
ABSTRACT False
PROPERTIES gpPriority, gpNamedPolicyRuleMatchMethod
gpPolicyRoles
8.15.1. The Property gpPriority
This property is a non-negative integer that defines the priority of a
named group of rules. Conceptually, it is the priority of the
gpsPolicyGroup, and is used to determine when the policy rules that the
gpsPolicyGroup contains are evaluated with respect to other policyRules
and gpsPolicyGroups.
If two or more gpsPolicyGroup objects have the same priority, this
means that the order between these objects is of no importance, but
that they MUST each be evaluated before other objects that have a
numerically lower priority. The attribute is defined as follows:
NAME gpPriority
SYNTAX Integer (must be non-negative)
Snir, Ramberg, Strassner, Cohen expires May 2001 86
Draft-ietf-policy-qos-info-model-01.txt November 2000
8.15.2. The Property gpNamedPolicyRuleMatchMethod
This property is an enumerated integer that defines the decision
strategy to be applied on this set of QoS policy rules by policy
servers. Please see section 5 of this document for more information on
these decision strategies. See attribute definition of
qpPolicyRuleMatchMethod. The attribute is defined as follows.
NAME gpNamedPolicyRuleMatchMethod
SYNTAX Integer (ENUM) - {"MATCH FIRST" = 0; "MATCH ALL" = 1 }
8.15.3 The Property gpPolicyRoles
This property represents the roles and role combinations associated
with all policy rules contained in this Policy Group by placement or
aggregation. Each value represents one role combination.Since this is
a multi-valued property, more than one role combinationcan be
associated with a single policy rule. Each value is a string of the
form <RoleName>[&&<RoleName>]* where the individual role names appear
in alphabetical order (according to the collating sequence for UCS-2).
The property definition is as follows:
NAME gpPolicyRoles
SYNTAX string
8.16. Class qosPolicyPRAction
This class defines DiffServ actions to be applied on a flow or group of
flows, including the marking of a DSCP value, dropping, policing and
shaping.
The association PolicyMeterInAction is used to associate a meter to
qosPolicyPRAction. The associations PolicyConformNextAction,
PolicyExcessNextAction, PolicyViolateNextAction can be used to link
other actions to be enforced on flows that either conform, exceed or
violate the associated meter and traffic profile.
The class definition is as follows:
NAME qosPolicyPRAction
DERIVED FROM policyAction (defined in [PCIM])
ABSTRACT False
PROPERTIES qpDirection, qpMarkvalue, qpMarkValueType,
qpExcessAction, qpExcessMarkValue, qpViolateAction,
qpViolateMarkValue
8.16.1. The Property qpDirection
This property is an enumerated integer that defines whether the action
should be applied to incoming or/and outgoing interfaces. Note that
certain repositories MAY implement this enumeration in a different
form, as long as its semantics are preserved. For example, a directory
Snir, Ramberg, Strassner, Cohen expires May 2001 87
Draft-ietf-policy-qos-info-model-02.txt November 2000
MAY implement this property as a multi-valued attribute, with the
attribute having the values IN and OUT. The attribute is defined as
follows:
NAME qpDirection
SYNTAX Integer (ENUM) - {IN=0, OUT=1, BOTH=2}
8.16.2. The Property qpMarkValue
This property is an integer that defines the value for the mark action.
The range of values depend on the type defined in qpMarkValueType. If
qpMarkValueType property is not defined, qpMarkValue is assumed to
carry DSCP value in the range of 0-63 inclusive.
defined as follows:
NAME qpMarkValue
SYNTAX Integer
8.16.3. The Property qpMarkValueType
This property is an enumerated integer that defines the type of marking
value used in this provisioning action.
The attribute is defined as follows:
NAME qpMarkValueType
SYNTAX Integer (ENUM) {DSCP=0, IPP=1. TOS=2. COS=3}
8.16.4. The Property qpExcessAction
This property is an enumerated integer that defines the action to be
applied to out of profile, excess traffic, as defined in the qpTrfcProf
referenced traffic profile instance.
The attribute is defined as follows:
NAME qpExcessAction
SYNTAX Integer (ENUM) - {SHAPE=0,DISCARD=1,REMARK=2}
8.16.5. The Property qpExcessMarkValue
This property is an integer that defines the marking value to be
applied to excess out of profile packets if the qpExcessAction action
is defined as REMARK. Notice that the marking type is defined by the
Provisioning action qpMarkValueType property.
The attribute is defined as follows:
NAME qpExcessMarkValue
SYNTAX Integer
Snir, Ramberg, Strassner, Cohen expires May 2001 88
Draft-ietf-policy-qos-info-model-02.txt November 2000
8.16.6. The Property qpViolateAction
This property is an enumerated integer that defines the action to be
applied to out of profile, violating traffic, as defined in the
qpTrfcProf referenced traffic profile instance.
That entry contains values for each of the four types of actions that
are present in this attribute: shaping, discarding or remarking.
The attribute is defined as follows:
NAME qpViolateAction
SYNTAX Integer (ENUM) - {SHAPE=0,DISCARD=1,REMARK=2}
8.16.7. The Property qpViolateMarkValue
This property is an integer that defines the marking value to be
applied to violating out of profile packets if the qpViolateAction
action is defined as REMARK. Notice that the marking type is defined
by the provisioning action qpMarkValueType property.
The attribute is defined as follows:
NAME qpViolateMarkValue
SYNTAX Integer
8.17. Class qosPolicyPHBAction
This class defines DiffServ actions to be applied in order to provide
the correct Per Hop Behavior across the QoS domain. PHB actions control
the bandwidth and buffer resources and congestion control across each
hop.
The association PolicyQueueInPHBAction is used to associate a
qosPolicyQueue object with a PHB action.
The class definition is as follows:
NAME qosPolicyPHBAction
DERIVED FROM policyAction (defined in [PCIM])
ABSTRACT False
PROPERTIES qpPHBDirection, qpDropAlgorithm, pDropTreshholdValueType,
qpDropMinTreshholdValue, qpDropMaxTreshholdValue,
qpRandomDropInvWeight, qpRandomDropProbMax, qpPacketSize
8.17.1. The Property qpPHBDirection
This property is an enumerated integer that defines whether the action
should be applied to incoming or/and outgoing interfaces. Note that
certain repositories MAY implement this enumeration in a different
form, as long as its semantics are preserved. For example, a directory
MAY implement this property as a multi-valued attribute, with the
attribute having the values IN and OUT. The attribute is defined as
follows:
Snir, Ramberg, Strassner, Cohen expires May 2001 89
Draft-ietf-policy-qos-info-model-02.txt November 2000
NAME qpPHBDirection
SYNTAX Integer (ENUM) - {IN=0, OUT=1, BOTH=2}
8.17.2 The Property qpDropAlgorithm
This property specifies the congestion control drop algorithm that
should be used for this type of traffic. The attribute is defined as
follows.
NAME qpDropAlgorithm
SYNTAX Integer {ENUM} - {alwaysDrop=0, tailDrop=1, headDrop=2,
randomDrop=3}
8.17.3 The Property qpDropTreshholdValueType
This property specifies the units in which qpDropMinThresholdValue and
qpDropMaxThresholdValue are measured. The attribute is defined as
follows.
NAME qpDropThresholdValueType
SYNTAX Integer {ENUM} - {numberOfPackets=0, numberOfBytes=1,
percentageOfPackets=2, percentageOfBytes=3}
8.17.4 The Property qpDropMinThreshholdValue
This property specifies the minimal number of queuing and buffer
resources that should be reserved to this class of flows. The threshold
can be specified as either relative or absolute value according to the
value of qpDropThresholdValueType property. If this property specifies
a value of 5 packets than enough buffer and queuing resources should be
reserved to hold 5 packets before running the specified congestion
control drop algorithm. If this class of traffic is one member of a PHB
group and therefore shares a queue, the drop mechanism should not drop
any packet from this class of traffic before the queue holds 5 packets
of the entire PHB group:
NAME qpDropMinThresholdValue
SYNTAX Integer
8.17.5 The Property qpDropMaxTreshholdValue
This property specifies the maximal number of queuing and buffer
resources that should be reserved to this class of flows. The threshold
can be specified as either relative or absolute value according to the
value of qpDropThresholdValueType property. Congestion Control droppers
should not keep more packets than the value specified in this property.
Note however, that some dropper may calculate queue occupancy averages,
and therefore the actual maximal queue resources should be larger. The
attribute is defined as follows:
Snir, Ramberg, Strassner, Cohen expires May 2001 90
Draft-ietf-policy-qos-info-model-02.txt November 2000
NAME qpDropMaxThresholdValue
SYNTAX Integer
8.17.6 The Property qpRandomDropInvWeight
This property specifies the random dropper's weighting of past history
in affecting the calculation of the current queue average. The moving
average of the queue depth uses the inverse of this value as the factor
for the new queue depth, and one minus that inverse as the factor for
the historical average [DIFF-MIB]. The attribute is defined as follows:
NAME qpRandomDropInvWeight
SYNTAX Integer
8.17.7 The Property qpRandomDropProbMax
This property specifies the random dropper's worst case random drop
probability, expressed in drops per thousand packets. The attribute is
defined as follows.
NAME qpRandomDropProbMax
SYNTAX Integer
8.17.8 The Property qpPacketSize
This property defines a typical packet size for this class of traffic.
This property is used to translate threshold values specified in
packets to bytes and vice versa. The attribute is defined as follows.
NAME qpPacketSize
SYNTAX Integer
8.18. Class qosPolicyRSVPAction
This class defines a policy action to be applied on an RSVP signaling
message that matches the rule condition.
The association PolicyMeterInAction can be used to associate a meter
and an RSVP traffic profile to an RSVP action object to enforce an
admission decision.
The class definition is as follows:
NAME qosPolicyRSVPAction
DERIVED FROM policyAction (defined in [PCIM])
ABSTRACT False
PROPERTIES qpRSVPDirection, qpRSVPMessageType, qpRSVPService,
qpRSVPStyle,
Snir, Ramberg, Strassner, Cohen expires May 2001 91
Draft-ietf-policy-qos-info-model-02.txt November 2000
8.18.1. The Property qpRSVPDirection
This property is an enumerated integer, and defines whether the action
is to be applied to incoming or/and outgoing interfaces. Note that
certain repositories MAY implement this enumeration in a different
form, as long as its semantics are preserved. For example, a directory
MAY implement this property as a multi-valued attribute, with the
attribute having the values IN and OUT. The attribute is defined as
follows:
NAME qpRSVPDirection
SYNTAX Integer (ENUM) - {IN=0,OUT=1,BOTH=2}
8.18.2. The Property qpRSVPMessageType
This property is an enumerated integer, and defines different values
that limit the scope of the action to be enforced to specific types of
RSVP messages. The attribute is defined as follows:
NAME qpRSVPMessageType
SYNTAX Integer (ENUM) - {Path=0 Resv=1 ResvErr=2 PathErr=3}
8.18.3. The Property qpRSVPStyle
This property is an enumerated integer, and defines different values
that limit the scope of the action to be enforced to RSVP Requests with
the specified reservation style. The attribute is defined as follows:
NAME qpRSVPStyle
SYNTAX Integer (ENUM) - {SE=0 FF=1 WF=2}
8.18.4. The Property qpRSVPServiceType
This property is an enumerated integer, and defines different values
that limit the scope of the action to be enforced to RSVP Requests
asking for specified integrated service type. The attribute is defined
as follows:
NAME qpRSVPServiceType
SYNTAX Integer (ENUM) -
{ControlledLoad=0, GuaranteedService=1, NULL=2}
Snir, Ramberg, Strassner, Cohen expires May 2001 92
Draft-ietf-policy-qos-info-model-01.txt November 2000
8.19. Class qosPolicyRSVPSignalCtrlAction
This class extends the functionality of the qosPolicyRSVPAction class
by adding detailed control on the signaling protocol behavior itself.
The information carried in RSVP messages can be modified using this
action, as well as the RSVP forwarding behavior.
Since the purpose of this is to augment the behavior specified by the
qosPolicyRSVPAction class, this class SHOULD be used with a
qosPolicyRSVPAction object, and SHOULD NOT be used by itself.
This class can be extended to support replacement of additional object
in RSVP messages, beyond replacement of DCLASS and PREEMPTION object
replacement defined below.
The class definition is as follows:
NAME qosPolicyRSVPSignalCtrlAction
DERIVED FROM qosPolicyRSVPAction
ABSTRACT False
PROPERTIES qpForwardingMode, qpSendError, qpReplaceDSCP,
qpReplacePreemptionPriority, qpReplaceDefendingPriority
8.19.1. The Property qpForwardingMode
This property is an enumerated integer that controls the forwarding of
RSVP messages. If the mode is set to proxy, RSVP Path messages are not
forwarded and a Resv message is returned as if the Resv was returned by
the receiver. Otherwise, RSVP Path messages are forwarded. The
attribute is defined as follows:
NAME qpForwardingMode
SYNTAX Integer (ENUM) - {Forward=0 , Proxy=1}
8.19.2. The Property qpSendError
This property is an enumerated integer and controls the generation of
Resv-Err and Path-Err messages as defined in [COPSRSVP]. The attribute
is defined as follows:
NAME qpSendError
SYNTAX Integer {No=0, Yes=1}
8.19.3. The Property qpReplaceDSCP
This property is a non-negative integer that allows the replacement of
a DCLASS object carrying a DSCP value in an RSVP message. The attribute
specifies the DSCP value to be replaces, and is defined as follows:
Snir, Ramberg, Strassner, Cohen expires May 2001 93
Draft-ietf-policy-qos-info-model-02.txt November 2000
NAME qpReplaceDSCP
SYNTAX Integer (constrained to the range 0-63, inclusive)
8.19.4. The Property qpReplacePreemptionPriority
This property is a non-negative integer that is used to replace or add
a preemption priority object (defined in [RSVP_PREEMP]) to RSVP
messages. The attribute is defined as follows:
NAME qpReplacePreemptionPriority
SYNTAX Integer (must be non-negative)
8.19.5. The Property qpReplaceDefendingPriority
This property is a non-negative integer that is used to replace or add
a preemption priority object (defined in [RSVP_PREEMP]) to RSVP
messages. It specifies the defending priority within the preemption
object. The attribute is defined as follows:
NAME qpReplaceDefendingPriority
SYNTAX Integer (must be non-negative)
8.20. Class qosPolicyRSVPInstallAction
This class extends the functionality of the qosPolicyRSVPAction class
by adding detailed control for COPS Install decisions (defined in
[COPS]). This action allows assigning a preemption priority with an
RSVP request, to provide a device with information which RSVP requests
to accept in case of admission failures. This action specifies a DSCP
value (which provides an associated level of QoS) to set on the flow
that RSVP is requesting.
Since the purpose of this is to augment the behavior specified by the
qosPolicyRSVPAction class, this class SHOULD be used with a
qosPolicyRSVPAction object, and SHOULD NOT be used by itself.
This class can be extended to support additional install decisions that
need to be controlled.
The class definition is as follows:
NAME qosPolicyRSVPInstallAction
DERIVED FROM policyAction (defined in [PCIM])
ABSTRACT False
PROPERTIES qpSetDSCPValue, qpSetPreemptionPriority,
qpSetDefendingPriority
Snir, Ramberg, Strassner, Cohen expires May 2001 94
Draft-ietf-policy-qos-info-model-02.txt November 2000
8.20.1. The Property qpSetDSCPValue
This property is a non-negative integer that defines the setting of a
DSCP value in the device. In other words, this attribute controls the
remarking (by the device) of the flow signaled by the RSVP request. The
attribute is defined as follows:
NAME qpSetDSCPValue
SYNTAX Integer (constrained to the range 0-63, inclusive)
8.20.2. The Property qpSetDefendingPriority
This property is a non-negative integer, and is used to set the
defending priority within the preemption object (defined in
[RSVP_PREEMP]) of RSVP flows. The attribute is defined as follows:
NAME qpSetDefendingPriority
SYNTAX Integer (must be non-negative)
8.20.3. The Property qpSetPreemptionPriority
This property is a non-negative integer, and is used to set the
preemption priority [RSVP_PREEMP] of RSVP flows. The attribute is
defined as follows:
NAME qpSetPreemptionPriority
SYNTAX Integer (must be non-negative)
8.21 Class gpsPolicyTrfcProf
An abstract class that models a traffic profile. Traffic profile
specifies the
maximal rate parameters compared against a meter. The association
PolicyTrfcProfileInMeter is used to associate between the two.
NAME gpsPolicyTrfcProf
DERIVED FROM policy (defined in [PCIM])
ABSTRACT True
PROPERTIES
8.22. Class qosPolicyPRTrfcProf
A provisioning Traffic profile is a class that carries the policer or
shaper rate values to be enforced on a flow or a set of flows. The
class definition is as follows:
NAME qosPolicyPRTrfcProf
DERIVED FROM gpsPolicyTrfcProf
ABSTRACT False
PROPERTIES qpPRRate, qpPRNormalBurst, qpPRExcessBurst
Snir, Ramberg, Strassner, Cohen expires May 2001 95
Draft-ietf-policy-qos-info-model-02.txt November 2000
8.22.1. The Property qpPRRate
This is a non-negative integer that defines the token rate in kilo bits
per second. A rate of zero means that all packets will be out of
profile. The attribute is defined as follows:
NAME qpPRRate
SYNTAX Integer (must be non-negative)
8.22.2. The Property qpPRNormalBurst
This attribute is an integer that defines the normal size of a burst
measured in bytes. The attribute is defined as follows:
NAME qpPRNormalBurst
SYNTAX Integer (must be non-negative)
8.22.3. The Property qpPRExcessBurst
This attribute is an integer that defines the excess size of a burst
measured in bytes. The attribute is defined as follows:
NAME qpPRExcessBurst
SYNTAX Integer (must be non-negative)
8.23. Class qosPolicyRSVPTrfcProf
This class represents an IntServ RSVP Traffic profile. Values of RSVP
traffic profiles are compared against Traffic specification (TSPEC) and
QoS Reservation requests (FLOWSPEC) carried in RSVP requests. Traffic
profiles can be reusable objects or ad-hoc. The class definition is as
follows:
NAME qosPolicyRSVPTrfcProf
DERIVED FROM policy (defined in [PCIM])
ABSTRACT False
PROPERTIES qpRSVPTokenRate, qpRSVPPeakRate,
qpRSVPBucketSize, qpRSVPResvRate, qpRSVPResvSlack,
qpRSVPSessionNum, qpMinPolicedUnit, qpMaxPktSize
8.23.1. The Property qpRSVPTokenRate
This property is a non-negative integer that defines the token rate
parameter, measured in kilo bits per second. The attribute is defined
as follows:
NAME qpRSVPTokenRate
SYNTAX Integer (must be non-negative)
Snir, Ramberg, Strassner, Cohen expires May 2001 96
Draft-ietf-policy-qos-info-model-02.txt November 2000
8.23.2. The Property qpRSVPPeakRate
This property is a non-negative integer that defines the peak rate
parameter, measured in kilo bits per second. The attribute is defined
as follows:
NAME qpRSVPPeakRate
SYNTAX Integer (must be non-negative)
8.23.3. The Property qpRSVPBucketSize
This property is a non-negative integer that defines the token bucket
size parameter, measured in bytes. The attribute is defined as follows:
NAME qpRSVPBucketSize
SYNTAX Integer (must be non-negative)
8.23.4. The Property qpRSVPResvRate
This property is a non-negative integer that defines the RSVP rate (R-
Spec) in the RSVP Guaranteed service reservation. It is measured in
Kilo bits per second. The attribute is defined as follows:
NAME qpRSVPResvRate
SYNTAX Integer (must be non-negative)
8.23.5. The Property qpRSVPResvSlack
This property is a non-negative integer that defines the RSVP slack
term in the RSVP Guaranteed service reservation. It is measured in
microseconds. The attribute is defined as follows:
NAME qpRSVPResvSlack
SYNTAX Integer (must be non-negative)
8.23.6. The Property qpRSVPSessionNum
This property is a non-negative integer that defines the total number
of allowed RSVP sessions that can be active at any given time. The
attribute is defined as follows:
NAME qpRSVPSessionNum
SYNTAX Integer (must be non-negative)
Snir, Ramberg, Strassner, Cohen expires May 2001 97
Draft-ietf-policy-qos-info-model-02.txt November 2000
8.23.7. The Property qpMinPolicedUnit
This property is a non-negative integer that defines the minimum RSVP
policed unit, measure in bytes. The attribute is defined as follows:
NAME qpMinPolicedUnit
SYNTAX Integer (must be non-negative)
8.23.8. The Property qpMaxPktSize
This property is a non-negative integer that defines the maximum
allowed packet size for RSVP messages, measure in bytes. The attribute
is defined as follows:
NAME qpMaxPktSize
SYNTAX Integer (must be non-negative)
8.24. Class gpsPolicySimpleCondition
A simple condition is composed of an ordered triplet:
<Variable> <Operator> <Value>
The operator used in all condition definitions in this draft is
the 'match' operator. Such simple conditions are evaluated by answering
the question: Does <variable> match <value>? The operator property can
be extended to support other relations between variable and values.
Simple conditions are building blocks for more complex Boolean
conditions. The gpsPolicySimpleCondition class is derived from the
PolicyCondition class [PCIM]. Simple conditions can be kept in
repositories for reuse.
A variable and a value must be associated with a simple condition to
make it a meaningful condition, using the aggregations
PolicyVariableInPolicySimpleCondition and
PolicyValueInPolicySimpleCondition
The class definition is as follows:
NAME gpsPolicySimpleCondition
DERIVED FROM PolicyCondition (defined in [PCIM])
ABSTRACT False
PROPERTIES gpOperator
Snir, Ramberg, Strassner, Cohen expires May 2001 98
Draft-ietf-policy-qos-info-model-01.txt November 2000
8.24.1. The Property gpOperator
This property is an enumerated integer that defines the relation
between a variable
and a value. The default value is match, which has the semantics of
'belong to' or 'equal'. Applications can extend this property to
represent the specific type of relation that they are using to test
whether the condition is true or not. The attribute is defined as
follows:
NAME gpOperator
SYNTAX Integer - ENUM {0=Match}
DEFAULT VALUE 'match'
8.25. Class gpsPolicyCompoundCondition
The gpsPolicyCompoundCondition class is used to represent a Boolean
expression consisting of a set of policyConditions. As such, it can be
used to define traffic filters. The gpsPolicyCompoundCondition class is
linked to either a PolicyRule or a PolicyRepository using the
PolicyConditionInPolicyRule and PolicyConditionInPolicyRepository
associations, respectively. Compound conditions are constructed using
the PolicyConditionInCompoundCondition association. The class
definition is as follows:
NAME gpsPolicyCompoundCondition
DERIVED FROM PolicyCondition (defined in [PCIM])
ABSTRACT False
PROPERTIES gpPolicyConditionListType
8.25.1. The Property qpPolicyeConditionListType
The qpPolicyRuleConditionListType indicates whether the list of policy
conditions associated with this policy rule is in disjunctive normal
form (DNF) or conjunctive normal form (CNF). Defined values are DNF(1)
and CNF(2).
The attribute qpPolicyRuleConditionListType is defined to be identical
as the policyRuleConditionListType property of PolicyRule PCIM. The
attribute is defined as follows:
NAME 'policyConditionListType'
SYNTAX INTEGER (ENUM) - {1=DNF, 2=CNF}
DEFAULT VALUE: 1 (DNF)
Snir, Ramberg, Strassner, Cohen expires May 2001 99
Draft-ietf-policy-qos-info-model-02.txt November 2000
8.26. Class gpsPolicyVariable
Variables are used for building individual conditions. The variable
specifies the property of a flow that should be matched when evaluating
the condition. However, not every combination of a variable and a value
creates a meaningful condition. For example, a source IP address
variable can not be matched against a value that specifies a port
number. A given variable selects the set of matchable value types.
A variable can have constraints that limit the set of values within a
particular value type that can be matched against it in a condition.
For example, a source-port variable limits the set of values to
represent integers to the range of 0-65535. Integers outside this range
can not be matched to the source-port variable, even though they are of
the correct data type. Constraints for a given variable are indicated
through the PolicyValueConstraintsInVariable association.
The class definition is as follows:
NAME gpsPolicyVariable
DERIVED FROM policy (defined in [PCIM])
ABSTRACT False
PROPERTIES gpVariableName, gpValueTypes, gpVariableDescription,
8.26.1. The Property gpVariableName
This property is a string that provides a unique name for the variable.
This is very important, because the QPIM defines a correlation between
its pre-defined variable names and their logical bindings. This
correlation was defined earlier in Table 2. The attribute is defined as
follows:
NAME gpVariableName
SYNTAX String, whose values are defined in table 2
8.26.2 The Property gpValueTypes
This property is a string that specifies an unordered list of possible
value types that can be used in a simple condition together with this
variable. The value types are specified by their class names. The list
of class names enables an application to search for a specific set of
class names, as well as ensure that the data type of the value is of
the correct type. The list of class names was defined earlier in Table
2. The list of default qpValueTypes for each Variable is defined
earlier in Table 3. The attribute is defined as follows:
NAME gpValueTypes
SYNTAX String
Snir, Ramberg, Strassner, Cohen expires May 2001 100
Draft-ietf-policy-qos-info-model-02.txt November 2000
8.26.2. The Property gpVariableDescription
This property is a string that provides a textual description of the
variable. The attribute is defined as follows:
NAME gpVariableDescription
SYNTAX String
8.27. Class gpsPolicyValue
This is an abstract class that serves as the base class for all
subclasses that are used to define value objects in the QPIM. It is
used for defining values and constants used in policy conditions. The
class definition is as follows:
NAME gpsPolicyValue
DERIVED FROM policy (defined in [PCIM])
ABSTRACT True
PROPERTIES
8.28. Class gpsPolicyIPv4AddrValue
This class is used to provide a list of IPv4Addresses, hostnames and
address range values to be matched against in a policy condition. The
class definition is as follows:
NAME gpsPolicyIPv4AddrValue
DERIVED FROM gpsPolicyValue
ABSTRACT False
PROPERTIES gpIPv4AddrList
8.28.1. The Property gpIPv4AddrList
This Property provides an unordered list of strings, each specifying a
single IPv4 address, a hostname, or a range of IPv4 addresses,
according to the ABNF definition [ABNF] of an IPv4 address as specified
below:
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
IPv4prefix = IPv4address "/" 1*2DIGIT
IPv4range = IPv4address"-"IPv4address
IPv4maskedaddress = IPv4address","IPv4address
Hostname (as defined in [NAMES])
In the above definition, each string entry is either:
1. A single Ipv4address in dot notation as defined above.
Example: 121.1.1.2
Snir, Ramberg, Strassner, Cohen expires May 2001 101
Draft-ietf-policy-qos-info-model-02.txt November 2000
2. A single Hostname. Hostname format follows the guidelines and
restrictions specified in [NAMES].
Example: www.bigcompany.com
3. An IPv4range address range defined above, specified by a start
address in dot notation and an end address in dot notation,
separated by "-". The range includes all addresses between the
range's start and end addresses, including the start and end
addresses.
Example: 1.1.22.1-1.1.22.5
4. An IPv4maskedaddress address range defined above, specified by an
address and mask. The address and mask are represented in dot
notation separated by a comma ",".
Example: 2.3.128.0,255.255.248.0.
5. An IPv4prefix address range defined above specified by an address
and a prefix length separated by "/".
Example: 2.3.128.0/15
The class definition is as follows:
NAME gpIPv4AddrList
SYNTAX String
FORMAT IPv4address | hostname | IPv4addressrange |
IPv4maskedaddress | IPv4prefix
8.29. Class gpsPolicyIPv6AddrValue
This class is used to define a list of IPv6 addresses, hostnames, and
address range values. The class definition is as follows:
NAME gpsPolicyIPv6AddrValue
DERIVED FROM gpsPolicyValue
ABSTRACT False
PROPERTIES gpIPv6AddrList
8.29.1. The Property gpIPv6AddrList
This property provides an unordered list of strings, each specifying an
IPv6 address, a hostname, or a range of IPv6 addresses. IPv6 address
format definition uses the standard address format defined in [IPv6].
The ABNF definition [ABNF] as specified in [IPv6] is:
IPv6address = hexpart [ ":" IPv4address ]
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
IPv6prefix = hexpart "/" 1*2DIGIT
hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
IPv6range = IPv6address"-"IPv6address
Snir, Ramberg, Strassner, Cohen expires May 2001 102
Draft-ietf-policy-qos-info-model-02.txt November 2000
IPv6maskedaddress = IPv6address","IPv6address
Hostname (as defines in [NAMES])
Each string entry is either:
1. A single IPv6address as defined above.
2. A single Hostname. Hostname format follows guidelines and
restrictions specified in [NAMES].
3. An IPv6range address range, specified by a start address in dot
notation and an end address in dot notation, separated by "-".
The range includes all addresses between the range's start and end
addresses, including the start and end addresses.
4. An IPv4maskedaddress address range defined above specified by an
address and mask. The address and mask are represented in dot
notation separated by a comma ",".
5. A single IPv6prefix as defined above.
NAME gpIPv6AddrList
SYNTAX String
FORMAT IPv6address | hostname | IPv6addressrange |
IPv6maskedaddress | IPv6prefix
8.30. Class gpsPolicyMACAddrValue
This class is used to define a list of MAC addresses and MAC address
range values. The class definition is as follows:
NAME gpsPolicyMACAddrValue
DERIVED FROM gpsPolicyValue
ABSTRACT False
PROPERTIES gpMACAddrList
8.30.1. The Property gpMACAddrList
This property provides an unordered list of strings, each specifying a
MAC address or a range of MAC addresses. The 802 MAC address canonical
format is used. The ABNF definition [ABNF] is:
MACaddress = 1*4HEXDIG ":" 1*4HEXDIG ":" 1*4HEXDIG
MACmaskedaddress = MACaddress","MACaddress
Each string entry is either:
1. A single MAC address. Example: 0000:00A5:0000
2. A MACmaskedaddress address range defined specified by an address
and mask. The mask specifies the relevant bits in the address.
Example: 0000:00A5:0000, FFFF:FFFF:0000 defines a range of MAC
addresses in which the first 4 8-bit bytes are equal to 0000:00A5.
Snir, Ramberg, Strassner, Cohen expires May 2001 103
Draft-ietf-policy-qos-info-model-01.txt November 2000
NAME gpMACAddrList
SYNTAX String
FORMAT MACaddress | MACmaskedaddress
8.31. Class gpsPolicyStringValue
This class is used to represent a single or set of string values. Each
can have wildcards. The class definition is as follows:
NAME gpsPolicyStringValue
DERIVED FROM gpsPolicyValue
ABSTRACT False
PROPERTIES gpStringList
8.31.1. The Property gpStringList
This property provides an unordered list of strings, each representing
a single string with wildcards. The asterisk character "*" is used as a
wildcard, and represents an arbitrary sub-string replacement. For
example, the value "abc*def" match "abcxyzdef", and the value
"abc*def*" match "abcxxxdefyyyzzz". The syntax definition is identical
to the substring assertion syntax defined in [LDAP_ATTR]. If the
asterisk character is required as part of the string value itself, it
MUST be quoted as described in section 4.3 of [LDAP_ATTR].
The attribute definition is as follows:
NAME gpStringList
SYNTAX String
8.32 Class gpsPolicyBitStringValue
This class is used to represent a single or set of bit string values.
The class definition is as follows:
NAME gpsPolicyBitStringValue
DERIVED FROM gpsPolicyValue
ABSTRACT False
PROPERTIES gpBitStringList
8.32.1. The Property gpBitStringList
This property provides an unordered list of strings, each representing
a single bit string or a set of bit strings. The number of bits
specified SHOULD equal the number of bits of the expected variable. For
example, for an 8-bit byte variable, 8 bits should be specified. If the
variable does not have a fixed length, the bit string should be matched
against the variable most significant bit string. The formal
definition of a bit string is:
Snir, Ramberg, Strassner, Cohen expires May 2001 104
Draft-ietf-policy-qos-info-model-01.txt November 2000
binary-digit = "0" / "1"
bitstring = 1*binary-digit
maskedBitString = bitstring","bitstring
Each string entry is either:
1. A single bit string. Example: 00111010
2. A range of bit strings specifies using a bit string and a bit
mask. The bit string and mask properties have the same number of
bits specified. The mask bit string specifies the significant bits
in the bit string value. For example, 110110, 100110 and 110111
would match the maskedBitString 100110,101110 but 100100 would
not.
NAME gpBitStringList
SYNTAX String
FORMAT bitString | maskedBitString
8.33. Class gpsPolicyDNValue
This class is used to represent a single or set of Distinguished
Name [DNDEF] values, including wildcards. This value type is
specifically defined for an LDAP based implementation of this
information model. A Distinguished Name is a name that can be used as a
key to retrieve an object from a directory service. This value can be
used in comparison to reference values carried in RSVP policy objects,
as specified in [IDENT].
The class definition is as follows:
NAME gpsPolicyDNValue
DERIVED FROM gpsPolicyValue
ABSTRACT False
PROPERTIES qpDNList
8.33.1. The Property qpDNList
This attribute provides an unordered list of strings, each representing
a Distinguished Name (DN) with wildcards. The format of a DN is defined
in [DNDEF]. The asterisk character ("*") is used as wildcard for either
a single attribute value or a wildcard for an RDN. The order of RDNs is
significant. For example: A qpDNList attribute carrying the following
value: "OU=Sales, CN=*, O=Widget Inc., *, C=US"
matches: "OU=Sales, CN=J. Smith, O=Widget Inc, C=US" and also matches:
"OU=Sales, CN=J. Smith, O=Widget Inc, C=US, CN=CA".
The attribute is defined as follows:
Snir, Ramberg, Strassner, Cohen expires May 2001 105
Draft-ietf-policy-qos-info-model-01.txt November 2000
NAME qpDNList
SYNTAX List of Distinguished Names implemented as strings, each of
which serves as a reference to another object.
8.34. Class gpsPolicyAttributeValue
This class is used to represent a single or set of property values in
an object. This value can be used in conjunction with reference values
carried in RSVP objects, as specified in [IDENT]. The property name is
used to specify which of the properties in the object is being used as
the condition. The value of this property will then be retrieved, and a
match (which is dependent on the property name) will be used to see if
the condition is satisfied or not.
For example, suppose a User class has a multi-valued Property called
'member-of' that lists the names of groups that this user belongs to.
Suppose this property uses caseIgnoreMatch matching. A simple condition
can be constructed to match the reference carried in an RSVP Identity
policy object to a gpsPolicyAttributeValue with the following
characteristics:
gpAttributeName="member-of",
gpAttributeValueList = "group-A".
An Identity policy object carrying the following reference:
"OU=Sales, CN=J. Smith, O=Widget Inc."
will match this simple condition only if J. Smith belongs to group-a.
The class definition is as follows:
NAME gpsPolicyAttributeValue
DERIVED FROM gpsPolicyValue
ABSTRACT False
PROPERTIES gpAttributeName, gpAttributeValueList
8.34.1. The Property gpAttributeName
This attribute defines the name of the property that the list of values
should be compared against. The attribute is defined as follows:
NAME gpAttributeName
SYNTAX String
8.34.2. The Property gpAttributeValueList
This attribute contains a list of property values. Each value is
compared to a value of the property specified by gpAttributeName. The
attribute is defined as follows:
NAME gpAttributeValueList
SYNTAX String
Snir, Ramberg, Strassner, Cohen expires May 2001 106
Draft-ietf-policy-qos-info-model-02.txt November 2000
8.35. Class gpsPolicyIntegerValue
This class provides a list of integer and integer range values.
Integers of arbitrary sizes can be represented. For a given variable,
the set of possible ranges of integer values allowed is specified via
the variable's gpValueConstraints Property. The class definition is as
follows:
NAME gpsPolicyIntegerValue
DERIVED FROM gpsPolicyValue
ABSTRACT False
PROPERTIES gpIntegerList
8.35.1. The Property gpIntegerList
This property provides an unordered list of integers and integer range
values. The format of this property can take on of the following forms:
1. An integer value.
2. A range of integers. The range is specifies by a start integer and
an end integer separated by "-". The range includes all integers
between start and end integers, including the start and end
integers.
To represent a range of integers that is not bounded, the reserved word
INFINITY can be used as the end range integer.
The ABNF definition [ABNF] is:
integer = 1*DIGIT | "INFINITY"
integerrange = integer"-"integer
Using ranges, the operators greater-than, greater-than-or-equal-to,
less-than and less-than-or-equal-to can be expressed. This enables the
match condition semantics of the gpOperator property of the
gpsPolicySimpleCondition class to be kept simple (i.e., just the value
"match"). The attribute is defined as follows.
NAME gpIntegerList
SYNTAX String
FORMAT integer | integerrange
Snir, Ramberg, Strassner, Cohen expires May 2001 107
Draft-ietf-policy-qos-info-model-01.txt November 2000
8.36 Class gpsPolicyMeter
This class models a meter. Within provisioning actions, meters measure
the temporal properties of the stream of packets selected by a
classifier against a traffic profile. Within Signaling policies, meters
measure the temporal resource allocations for flows matching a rule's
condition. A traffic profile is associated to a meter using the
PolicyTrfcProfileInMeter association.
A meter can be shared between different policy rules. A meter shared by
more than one policy rule resides in a repository and is referenced by
all sharing rules. A meter is associated with an action using the
PolicyMeterInAction association.
The class is defined as follows:
NAME gpsPolicyMeter
DERIVED FROM policy (defined in [PCIM])
ABSTRACT True
PROPERTIES gpMeterScope, gpMeterTimeInterval
8.36.1. The Property gpMeterScope
This property is an enumerated integer that defines whether this
metering action should be applied on a per-flow, per-interface,
per-role within a device, per device or per role across all devices.
The attribute is defined as follows:
NAME gpMeterScope
SYNTAX Integer (ENUM) {flow=0,interface=1 role-in-device=2,
device=3, role=4}
8.36.2. The Property gpMeterTimeInterval
This optional property specifies the time interval used to measure
traffic in microseconds. The attribute is defined as follows:
NAME gpMeterTimeInterval
SYNTAX Integer
Snir, Ramberg, Strassner, Cohen expires May 2001 108
Draft-ietf-policy-qos-info-model-02.txt November 2000
8.37 Class qosPolicyQueue
This class models a sharable queue used by more than one policy rule.
A set of actions defining PHBs may be associated to the same queue
object using the PolicyQueueInPHBAction association to indicate that
they belong to the same PHB group. Bandwidth and Delay attributes are
than managed for the entire PHB group in a single place.
The class is defined as follows:
NAME qosPolicyQueue
DERIVED FROM policy (defined in [PCIM])
ABSTRACT True
PROPERTIES qpForwardingPriority, qpBandwidthValueType,
qpMinBandwidth, qpMaxBandwidth, qpMaxDelay, qpMaxJitter,
qpFairQueue
8.37.1. The Property qpForwardingPriority
This property defines the forwarding priority that should be given to
this set of flows. A non zero value indicate that preemptive forwarding
should be provided to the class of traffic. Higher values represent
higher forwarding priority. The attribute is defined as follows.
NAME qpForwardingPriority
SYNTAX Integer
8.37.2. The Property qpBandwidthValueType
This property defines in what units the properties qpMinBandwidth and
qpMaxBandwidth are defined. Bandwidth can either be defined in bits/sec
or in percentage of the available bandwidth or scheduler resources. The
attribute is defined as follows.
NAME qpBandwidthValueType
SYNTAX Integer {ENUM} - {bits/sec=0, percentage=1}
8.37.3. The Property qpMinBandwidth
This property defines the minimal bandwidth that should be reserved to
this class of traffic. Both relative and absolute values can be
specified according to the value qpBandwidthValueType property. The
attribute is defined as follows.
NAME qpMinBandwidth
SYNTAX Integer
Snir, Ramberg, Strassner, Cohen expires May 2001 109
Draft-ietf-policy-qos-info-model-02.txt November 2000
8.37.4. The Property qpMaxBandwidth
This property defines the maximal bandwidth that should be allocated to
this class of traffic. Both relative and absolute values can be
specified according to the value qpBandwidthValueType property. The
attribute is defined as follows.
NAME qpMaxBandwidth
SYNTAX Integer
8.37.5 The Property qpMaxDelay
This property defines the maximal per hop delay that traffic of this
class should experience while being forwarded through this hop.
The maximal delay is measured in milliseconds. The attribute is defined
as follows.
NAME qpMaxDelay
SYNTAX Integer (milliseconds)
8.37.6 The Property qpMaxJitter
This property defines the maximal per hop delay variance that traffic
of this class should experience while being forwarded through this hop.
The maximal jitter is measured in milliseconds. The attribute is
defined as follows.
NAME qpMaxJitter
SYNTAX Integer (milliseconds)
8.37.7 The Property qpPacketSize
This property defines a typical packet size for this class of traffic.
This property is used to translate threshold values specified in
packets to bytes and vice versa.
NAME qpPacketSize
SYNTAX Integer
8.37.8 The Property qpFairQueue
This property defines whether fair queuing is required for this class
of traffic. The attribute is defined as follows.
NAME qpFairQueue
SYNTAX Integer {Boolean} - {FALSE=0, TRUE=1}
Snir, Ramberg, Strassner, Cohen expires May 2001 110
Draft-ietf-policy-qos-info-model-01.txt November 2000
9. Extending the QoS Policy Schema
The following subsections provide general guidance on how to create a
domain-specific information model derived from the QPIM by extending
the QoS policy classes.
9.1. Extending gpsPolicyValue
The gpsPolicyValue class and its subclasses describe the common
value types used in the QPIM. When other specific types are required,
such as a floating-point numbers, the required class SHOULD be derived
from the gpsPolicyValue class and properties that contain the
corresponding values SHOULD be added.
Notice that in many cases, using the gpsPolicyAttributeValue class
allows the definition of non-standard policy atoms without extending
the gpsPolicyValue class.
9.2. Extending gpsPolicySimpleCondition
The gpsPolicySimpleCondition class is used to describe a single atomic
Boolean condition. For Boolean conditions that are not structured as
the ordered triple <variable - relation - value>, a new type of
condition class SHOULD be defined. An example would be a unary
condition.
Subclassing could be done using either the policyCondition or
gpsPolicySimpleCondition classes as the superclass.
9.3. Extending qosPolicyAction
The Qos Policy actions classes defined in the QoS Policy Schema
Includes the following types of actions:
Provisioning actions:
* Marking
* Policing, shaping and remarking according to a traffic profile
Signaling RSVP action:
* RSVP policy admission
* RSVP signal control extensions
* RSVP flow control extensions
Additional actions could be associated with QoS policy rules by
extending the policyAction class with the appropriate properties.
Snir, Ramberg, Strassner, Cohen expires May 2001 111
Draft-ietf-policy-qos-info-model-01.txt November 2000
10. Security Considerations
The security considerations for this document are the same as those of
the [PCIM].
11. Editorial information
<this section will be removed before publication>
Changes from the previous version:
1. Some of the classes defined in QPIM are intended for usage
outside the scope of QoS domain. The concept of conditions as building
blocks of filters, the basic condition structure of <variable operator
value>, the concept of variable binding and the concept of variable to
value relationship are valuable to domains out side QoS policy. In
order to allow more natural usage of these concept in other domains,
the relevant classes prefix was changed from qosPolicyXXX to
gpsPolicyXXX and properties prefix was changed from qpPolicyXXX to
gpPolicy ,i.e., general policy XXX.
2. The notion of a class representing a filter or a Boolean expression
made of policy conditions, that could also serve as a reusable filter
was added. The class gpsPolicyCompoundCondition allows the definition
of a flexible reusable filter, leveraging the mechanism defined in CPIM
for associating policy conditions to a policy rule .
3. This draft was updated to be compatible with the latest PCIM draft.
4. PHB Actions added to allow full coverage of the QoS policy model
required for definition of policies for a differential service domain.
References to external PHB definitions removed.
5. Alignment between policy definition of QPIM and low level PIB / MIB
Was illustrated.
6. Reuse of Policy groups and their QPIM extensions,
gpsPolicyGroups and Policy rules were explained and examples
were added.
7. Role usage in the context of QoS policy was explained. No new
concepts were introduced. Role were also defined per
gpsPolicyGroups.
8. Change gpsPolicyMeter to include a traffic profile and scope. The
previous way of binding the meter the traffic profile and a scope using
a provisioning action could lead to inconsistencies if not used
properly (Bob).
9. Clarification of the use of gpValueTypes property of values and the
meaning of table 3 (Bob).
10. Rewriting the draft in a storage independent way. The previous
draft was not general enough. Added appropriate association and
aggregations and removed references from objects. Changed text
appropriately.
11. qpsNamedPolicyContainer class name was changes to gpsPolicyGroup to
allow for usage outside the scope of QoS domain
Snir, Ramberg, Strassner, Cohen expires May 2001 112
Draft-ietf-policy-qos-info-model-02.txt November 2000
12. Acknowledgments
The authors wish to thank the input of the participants of the Policy
Framework working group, and especially Bob Moore and Alex Wang for
their helpful contributions.
13. References
[PCIM] J. Strassner, E. Ellesson, B. Moore, "Policy Framework Core
Information Model", Internet Draft
<draft-ietf-policy-core-info-model-05.txt>
[PFSCHEMA] J. Strassner, E. Ellesson, B. Moore, "Policy Framework LDAP
Core Schema", Internet Draft
<draft-ietf-policy-core-schema-06.txt>
[QOSSCHEMA] Y. Snir, Y Ramberg, J. Strassner, R. Cohen, "QoS
Policy Schema", Internet Draft
<draft-ietf-policy-qos-schema-01.txt>
[DIFF-SERV-ARCH] S. Blake et al, "An Architecture for
Differentiated Services", RFC2475
[EF] V. Jacobson, K. Nichols, K. Poduri, " An Expedited Forwarding
PHB", RFC2598, September 1999
[AF] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured
Forwarding PHB Group", RFC2597, September 1999
[DIFF-MIB] F. Baker, K. Chan, A. Smith "Management Information Base
for the Differentiated Services Architecture",
draft-ietf-diffserv-mib-05.txt, November 2000
[PIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, A.
Smith, "Quality of Service Policy Information Base",
Internet Draft <draft-mfine-cops-pib-01.txt>
[RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) -
Functional Specification.", IETF RFC 2205,
Proposed Standard, Sep. 1997.
[RSVP-IS] J. Wroclawski, "The Use of RSVP with IETF Integrated
Services", RFC2210, September 1997
[GS] S. Shenker, C. Partridge, R. Guerin, "Specification
of the Guaranteed Quality of Service", RFC2212,
September 1997
Snir, Ramberg, Strassner, Cohen expires May 2001 113
Draft-ietf-policy-qos-info-model-01.txt November 2000
[CL] J. Wroclawski, "Specification of the Controlled-Load
Network Element Service", RFC2211, September 1997
[RSVP_PREEMP] Shai Herzog, "Signaled Preemption Priority Policy
Element", RFC2751
[IDNET] S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T.
Moore, S. Herzog, "Identity Representation for
RSVP", RFC 2752, January 2000
[COPS] D. Durham, J. Boyle, R . Cohen, S. Herzog, R. Rajan, A.
Sastry, "The COPS (Common Open Policy Service) Protocol",
RFC2748
[COPSRSVP] S. Herzog, J. Boyle, R . Cohen, D. Durham, R. Rajan, A.
Sastry, "COPS Usage for RSVP", RFC2749
[IPv6] R. Hinden, S. Deering, "IP Version 6 Addressing
Architecture", RFC2373, July 1998
[NAME] P. Mockapetris, " Domain names - implementation and
specification", RFC1035
[ABNF] Crocker, D., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, November
1997.
[DNDEF] Wahl, M., Kille, S., and T. Howes, "Lightweight
Directory Access Protocol (v3): UTF-8 String
Representation of Distinguished Names", RFC 2253,
December 1997.
[DEREF] R. Moats, J. Maziarski, J. Strassner, "Extensible Match
Rules to Dereference Pointer", Internet Draft
<draft-moats-ldap-dereference-match-02.txt>
[LDAP_ATTR] M. Wahl, A. Coulbeck, " Lightweight Directory Access
Protocol (v3): Attribute Syntax Definitions", RFC 2252
[TERMS] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", Internet RFC 2119, March 1997.
Snir, Ramberg, Strassner, Cohen expires May 2001 114
Draft-ietf-policy-qos-info-model-01.txt November 2000
14. Author's Addresses
Yoram Snir
Cisco Systems
4 Maskit Street
Herzliya Pituach, Israel 46766
Phone: +972-9-970-0085
Fax: +972-9-970-0366
E-mail: ysnir@cisco.com
Yoram Ramberg
Cisco Systems
4 Maskit Street
Herzliya Pituach, Israel 46766
Phone: +972-9-970-0081
Fax: +972-9-970-0219
E-mail: yramberg@cisco.com
John Strassner
Cisco Systems
Bldg 15
170 West Tasman Drive
San Jose, CA 95134
Phone: +1-408-527-1069
Fax: +1-408-527-2477
E-mail: johns@cisco.com
Ron Cohen
Cisco Systems
4 Maskit Street
Herzliya Pituach, Israel 46766
Phone: +972-9-970-0064
Fax: +972-9-970-0219
E-mail: ronc@cisco.com
15. Full Copyright Statement
This document and translations of it be copied and furnished to others,
and derivative works that comment on or otherwise explain it or assist
in its implementation be prepared, copied, published and distributed,
in whole or in part, without restriction of any kind, provided that the
above copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself not be
modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process PROPERTIES be followed, or as required to translate
it into languages other than English.
Snir, Ramberg, Strassner, Cohen expires May 2001 115
Draft-ietf-policy-qos-info-model-01.txt November 2000
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE
Snir, Ramberg, Strassner, Cohen expires May 2001 116
| PAFTECH AB 2003-2026 | 2026-04-24 03:06:36 |