Policy Framework                                                Y. Snir
Internet Draft                                               Y. Ramberg
Expires April 2000 May 2001                                           J. Strassner
draft-ietf-policy-qos-info-model-01.txt
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 refines is based on the core
policy information model presented in IETF
Policy Core Information Model as specified by [PCIM]. Specifically, this This draft
refines the concept of generic policy rules, conditions and actions
defined in [PCIM] in order to
cover define extensions necessary for
representing IntServ and DiffServ QoS policies. It also provides
refinement of additional concepts that are important for building rule-specific 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
repository
data storage mechanism and access protocol. A companion document [QoSSCHEMA]
defines Companion documents (e.g.,
[QoSSCHEMA]) define the mapping of these classes to specific data
models (schemata).

Snir, Ramberg, Strassner, Cohen         expires May 2001             1

For example, [QoSSCHEMA] defines how to map the data in this
information model to a form that can be stored in a directory that uses
LDAPv3 as its access protocol. A second companion document [QOSDEV] supplies low-
level definitions of QoS mechanisms that are controlled by this
document.

Snir, Ramberg, Strassner, Cohen     expires October 2000		    1

Table of Contents

1. Introduction                                                       5                                                       6
1.1  Goals                                                            5                                                            7
1.2 Approach and Related Documents                                    5                                    7

2. Information Model Hierarchy                                        6                                        8
2.1  Interaction Between the PCIM and This Document                   7
2.1.1                   8
2.1.1. Extension of Concepts in the PCIM                              7                              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                       7                        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                                       8

3. Containment Hierarchy                                      11

3. QPIM Hierarchies                                                  13
3.1. Containment Model                                               11 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 Containment Hierarchy                                12
3.2.1. Data Tree                                         19
3.4.    Types of Grouping Classes                                    22
3.5. QoS Policy Domain Grouping and Nesting                                   13
3.2.2.                          23
3.6. Resource Sharing                                              15
3.2.3. Placement                                                     15
3.2.4. Named                                                25
3.7. Instance Location                                               26
3.8. Policy Containers                                       16
3.2.5.                                               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                                                  17
3.2.6.                                                    32
3.11 Conditions and Actions                                        18
3.2.7.                                          33
3.12 Data Tree Example                                             19
3.3.                                               33
3.13 Reusable-Object Repositories                                    19
3.4.                                    34
3.14 Relationships Between QoS Domains and Repositories              20              35

Snir, Ramberg, Strassner, Cohen         expires May 2001             2

4. Constructing a QoS Policy Rule                                    21                                    36
4.1 Policy Rule Structure                                            21                                            36
4.2 QoS Policy Conditions                                            22
4.2.1 Reusable vs. Ad-Hoc                                            37
4.2.1. Simple Conditions                                 23                                             38
4.2.2. Compound Conditions                                           38
4.2.3. Using Simple Conditions                                       24
4.2.3. Composing Complex                                       39
4.2.4. Using Compound Conditions                                  24                                     41
4.2.5. Reusable vs. Rule-Specific Conditions                         42
4.3 Simple Condition Operator                                        25
4.4.                                        43
4.4 QoS Policy Variables                                            25                                             43
4.4.1 Variable Binding                                               26
4.4.2.                                               45
4.4.2 Pre-Defined Variables                                         26                                          46
4.5 QoS Policy Values                                                30 Value                                                 49
4.6. PolicyTimePeriodCondition                                       30                                       50
4.7. Actions                                                         30                                                         50
4.7.1  Provisioning Actions                                           31                                          52
4.7.1.1  Meters                                                      32                                                      52
4.7.1.2  Markers                                                     32                                                     53
4.7.1.3  Shapers                                                     32                                                     54
4.7.1.4  Droppers                                                    33                                                    54
4.7.1.5  Examples                                                    33                                                    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                                              34                                              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                                                 37 			             64
4.8.1 Provisioning Traffic Profiles                                  37
4.8.1                                  65
4.8.2 RSVP Traffic Profiles                                          38                                          66

5. Decision strategy                                                 39
5.1.                                                 67
5.1 Organizing the Application of Decision Strategies                67
5.2  Decision Strategies                                             68
5.2.1. First match                                                     39
5.2. Match Decision Strategy                                 68
5.2.2. Match All                                                       39

Snir, Ramberg, Strassner, Cohen     expires October 2000		    2 Decision Strategy                                   68
5.3. Decision Strategy example                                       40
5.3.1 Default Operation using First Match Everywhere                 40
5.3.2 Operation Using Other Decision Strategies                      41                                       69

6. Per Hop Behavior                                                  42
6.1. PHBs                                                            42
6.2. PHB Sets                                                        42                                                  70

7. QoS Policy Class Inheritance                                      43                                      71

8. Class Definitions                                                 45
8.1. Class qosPolicyDomain                                           45                                                 75
8.1 The Aggregation "PolicyGroupInPolicyRule"                        75
8.1.1. The Property qpDomainName                                     45 Reference "GroupComponent"                                75

Snir, Ramberg, Strassner, Cohen         expires May 2001             3

8.1.2. The Property qpPHBSet                                         45
8.1.3. Reference "PartComponent"                                 75

8.2 The Property qpPolicyRuleMatchMethod                          45
8.2. Class qosNamedPolicyContainer                                   46 Aggregation "PolicyRuleInPolicyRule"                         76
8.2.1. The Property qpPriority                                       46 Reference "GroupComponent"                                76
8.2.2. The Property qpNamedPolicyRuleMatchMethod                     46
8.3. Class qosPolicyPRAction                                         47 Reference "PartComponent"                                 76
8.3 The Aggregation "PolicyConditionInCompoundCondition "            77
8.3.1. The Property qpDirection                                      47 Reference "GroupComponent"                                77
8.3.2. The Property qpSetDSCPvalue                                   47
8.3.3. The Property qpMeter                                          47
8.3.4. The Property qpMeterScope                                     48
8.3.5. The Property qpTrfcProf                                       48
8.3.6. The Property qpOutOfProfileAction                             48
8.3.7. Reference "PartComponent"                                 77
8.4 The Property qpOutofProfileRemarkValue                        48
8.4. Class qosPolicyRSVPAction                                       48 Aggregation " PolicyVariableInPolicySimpleCondition "        77
8.4.1. The Property qpRSVPDirection                                  49 Reference "GroupComponent"                                78
8.4.2. The Property qpRSVPMessageType                                49
8.4.3. Reference "PartComponent"                                 78
8.5 The Property qpRSVPStyle                                      49
8.4.4. Aggregation " PolicyValueInPolicySimpleCondition "           78
8.5.1. The Property qpRSVPServiceType                                49
8.4.5. Reference "GroupComponent"                                79
8.5.2. The Property qpRSVPInstallAction                              50
8.4.6. Reference "PartComponent"                                 79
8.6. The Property qpRSVPCtrlAction                                 50
8.4.7. Association "PolicyElementInPolicyRepository"               79
8.6.1. The Property qpRSVPMeter                                      50
8.4.8. Reference "Antecedent"                                    80
8.6.2. The Property qpRSVPMeterScope                                 50
8.4.9. Reference "Dependent"                                     80
8.7. The Property qpRSVPTrfcProf                                   51
8.5. Class qosPolicyPRTrfcProf                                       51
8.5.1. Association "PolicyValueConstraintsInVariable"              80
8.7.1. The Property qpPRRate                                         51
8.5.2. Reference "Antecedent"                                    81
8.7.2. The Property qpPRNormalBurst                                  51
8.5.3. Reference "Dependent"                                     81
8.8. The Property qpPRExcessBurst                                  51
8.6. 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 qosPolicyRSVPTrfcProf                                    52
8.6.1. qosPolicyDomain                                          85
8.14.1. The Property qpRSVPTokenRate                                  52
8.6.2. qpDomainName                                    85
8.14.2. The Property qpRSVPPeakRate                                   52
8.6.3. qpPolicyRuleMatchMethod                         86
8.15. Class gpsPolicyGroup                                           86
8.15.1. The Property qpRSVPBucketSize                                 52
8.6.4. gpPriority                                      86
8.15.2. The Property qpRSVPResvRate                                   53
8.6.5. gpNamedPolicyRuleMatchMethod                    87
8.15.3. The Property qpRSVPResvSlack                                  53
8.6.6. gpPolicyRoles                                   87
8.16. Class qosPolicyPRAction                                        87
8.16.1. The Property qpRSVPSessionNum                                 53
8.6.7. qpDirection                                     87
8.16.2. The Property qpMinPolicedUnit                                 53
8.6.8. qpMarkvalue                                     88
8.16.3. The Property qpMaxPktSize                                     53
8.7. Class qosPolicyRSVPSignalCtrlAction                             54
8.7.1. qpMarkValueType                                 88
8.16.4. The Property qpForwardingMode                                 54
8.7.2. qpExcessAction                                  88
8.16.5. The Property qpSendError                                      54 qpExcessMarkValue                               88
8.16.6.  The Property qpViolateAction                                89
8.16.7. The Property qpViolateMarkValue                              89

Snir, Ramberg, Strassner, Cohen         expires October 2000		    3

8.7.3. May 2001             4

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                                    55
8.7.4.                                   93
8.19.4. The Property qpReplacePreemptionPriority                      55
8.7.5.                     94
8.19.5. The Property qpReplaceDefendingPriority                       55
8.8.                      94
8.20. Class qosPolicyRSVPInstallAction                                55
8.8.1.                               94
8.20.1. The Property qpSetDSCPValue                                   56
8.8.2.                                  95
8.20.2. The Property qpSetDefendingPriority                           56
8.8.3.                          95
8.20.3. The Property qpSetPreemptionPriority                          56
8.9.                         95
8.21. Class qosPolicySimpleCondition                                  56
8.9.1. gpsPolicyTrfcProf                                        95
8.22. Class qosPolicyPRTrfcProf                                      96
8.22.1. The Property qpOperator                                       57
8.9.2. qpPRRate                                        96
8.22.2. The Property qpVariableAtom                                   57
8.9.3. qpPRNormalBurst                                 96
8.22.3. The Property qpValueAtom                                      57
8.10. qpPRExcessBurst                                 96
8.23.  Class qosPolicyVariable                                        57
8.10.1. qosPolicyRSVPTrfcProf                                   96
8.23.1. The Property qpVariableName                                  58
8.10.2 qpRSVPTokenRate                                 96
8.23.2. The Property qpValueTypes                                   58
8.10.3. qpRSVPPeakRate                                  97
8.23.3. The Property qpVariableDescription                          58
8.10.4. qpRSVPBucketSize                                97
8.23.4. The Property qpValueConstraints                              59
8.11. Class qosPolicyValue                                           59
8.12. 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 qosPolicyIPv4AddrValue                                   59
8.12.1. gpsPolicySimpleCondition                                 98
8.24.1. The Property qpIPv4AddrList                                  59
8.13. gpOperator                                      99
8.25. Class qosPolicyIPv6AddrValue                                   60
8.13.1. gpsPolicyCompoundCondition                               99
8.25.1 The Property qpIPv6AddrList                                  60
8.14. gpPolicyConditionListType                        99
8.26. Class qosPolicyMACAddrValue                                    61
8.14.1. gpsPolicyVariable                                       100
8.26.1. The Property qpMACAddrList                                   61
8.15. gpVariableName                                 100
8.26.2.  The Property gpVariableDescription                         101
8.27. Class qosPolicyStringValue                                     62
8.15.1. gpsPolicyValue                                          101
8.28. Class gpsPolicyIPv4AddrValue                                  101
8.28.1. The Property qpStringList                                    62
8.16 gpIPv4AddrList                                 102
8.29. Class qosPolicyBitStringValue                                   62
8.16.1. gpsPolicyIPv6AddrValue                                  102
8.29.1. The Property qpBitStringList                                 62
8.17. gpIPv6AddrList                                 102

Snir, Ramberg, Strassner, Cohen         expires May 2001             5

8.30. Class qosPolicyDNValue                                         63
8.17.1. gpsPolicyMACAddrValue                                   103
8.30.1. The Property qpDNList                                        63
8.18. gpMACAddrList                                  103
8.31. Class qosPolicyAttributeValue                                  63
8.18.1. gpsPolicyStringValue                                    104
8.31.1. The Property qpAttributeName                                 64
8.18.2. gpStringList                                   104
8.32 Class gpsPolicyBitStringValue                                  104
8.32.1. The Property qpAttributeValueList                            64
8.19. gpBitStringList                                104
8.33. Class qosPolicyIntegerValue                                    64
8.19.1. gpsPolicyDNValue                                        105
8.33.1. The Property qpIntegerList                                   65
8.20. gpDNList                                       105
8.34. Class qosPolicyPHBSet                                          65
8.21. gpsPolicyAttributeValue                                 106
8.34.1. The Property gpAttributeName                                106
8.34.2. The Property gpAttributeValueList                           106
8.35. Class qosPolicyPHB                                             65
8.21.1. gpsPolicyIntegerValue                                   107
8.35.1. The Property qpDSCP                                          66
8.22. gpIntegerList                                  107
8.36. Class qosPolicyMeter                                           66 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                                   67                                  111
9.1. Extending qosPolicyValue                                        67 gpsPolicyValue                                       111
9.2. Extending qosPolicySimpleCondition                              67 gpsPolicySimpleCondition                             111
9.3. Extending qosPolicyAction                                       67                                      111

10. Security Considerations                                          68                                         112

11. Acknowledgments                                                  68 Editorial Changes                                               112
12. References                                                       68 Acknowledgments                                                 113
13. References                                                      113

14. Author's Addresses                                               69

14.                                              115

15. Full Copyright Statement                                         70

Snir, Ramberg, Strassner, Cohen     expires October 2000		    4                                        115

1. Introduction

This document presents an object-oriented information model for
representing network QoS policies. As such, it is independent of any
specific repository type data storage mechanism and access protocol. This document refines is
based on the
core policy information model presented in 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

This information model covers Differentiated Service QoS enforcement,
and Integrated Service QoS enforcement via policy control on RSVP
admission. A companion document [QoSSCHEMA] defines 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. A second companion document [QOSDEV] supplies low-level
definitions of QoS mechanisms that are controlled by this document.

1.1  Goals

This document presents defines a set of classes that can be used to build high
level QoS policies that can be used to configure and enforce consistent QoS
behavior across a network, regardless of network. Specifically, the actual policies defined in this
document can be used to control and manage different vendor-specific implementation details.
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, policy servers, policy management
applications, and Network 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 low-
level abstractions of mechanisms to implement QoS services, which are
controlled by the QoS policy rules defined in this document. The companion document
[QOSDEV] defines an information model for representing low-level QoS
mechanisms.

Second, different policy servers and applications may provision parts
of the network differently if no common high-level policy description
exists. This document defines a standard information model that
provides common definitions and semantics to be assigned to build,
interpret and enforce high-level policy rules.

1.2 Approach and Related Documents

The information model presented in this document contains information
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.

Snir, Ramberg, Strassner, Cohen     expires October 2000		    5

Representation

The remainder of this document presents, describes and defines the inherent
QoS mechanisms of devices Policy Information Model (QPIM). QPIM is described
in a companion draft [QOSDEV]. It provides a standard information model
for representing low-level QoS mechanisms that exist in devices in a
vendor-independent way. This document, augmented with the information
provided in [QOSDEV], together provide a set of enforceable policies entities and
relationships (both modeled by classes) that define managed objects and

Snir, Ramberg, Strassner, Cohen         expires May 2001             7

interactions between managed objects that can be used to define,
manage, and control the IntServ and DiffServ QoS mechanisms on network devices.

The concept of PHBs is central to Differentiated Services. An
additional information model for representation of PHBs is using policies.
It uses basic concepts defined in
[PHBSET], [PCIM] but extends those to control
IntServ and a corresponding LDAP representation DiffServ QoS mechanisms. Since QPIM is provided in
[PHBLDAP]. This document an information model
(and is also intended to work with [PHBSET].

The remainder therefore independent of any specific data storage mechanism
and access protocol limitations), this document presents, describes and defines the
concepts of is limited to
discussing the different managed objects that are used to define and
provision IntServ and DiffServ QoS Policy Information Model (QPIM). 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 schema mapped schema, are defined in [QOSSCHEMA].

2. Information Model Hierarchy

This section discusses the relationships between the Policy Core
Information Model ([PCIM]), [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 all use a common set of terminology,
classes, and approaches, thus facilitating interoperability.

The QPIM refines and extends the concepts of the [PCIM] and introduces 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 IntServ- and DiffServ-compliant. 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 provides
building blocks extends three fundamental concepts defined in [PCIM] in order
to control most of be able to define policies that can control, manage and provision
the QoS mechanisms of devices. These are hierarchical policy aspects required by
IntServ
repositories, extensions to reusable objects, and DiffServ, but it is clear that not all functions are
provided.

It is also clear that other information models and their derived
schemata can use some of the concepts in this document. For example,
the concept of representing IP Addresses, as well as variables and
constants, are not specific to QoS. However, this is the first
information model that is derived from the [PCIM], and it is not clear
that other working groups will be satisfied with these representations.
These concepts will be socialized extensions to other working groups and, if they
agree with the representation in this document (or if a suitable
compromise can be developed), then these concepts will be moved into
structure of a
separate document. policy rule.

Snir, Ramberg, Strassner, Cohen         expires October 2000		    6 May 2001             8

2.1.1.1 Hierarchical Policy Repositories

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 concept of any particular repository and access
protocol. However, mappings can be defined to translate the data from
this single "virtual information model" to a form that can be
implemented in "nested" policy repository (i.e.,  a specific type of repository that uses one or more
specific access protocols. Examples
is embedded within another repository) that contains policy
information, was originally defined in an earlier version of mapping the concepts of QPIM.
It has subsequently been moved into the
[PCIM] and this document to [PCIM], since it is a form general
concept that is not limited to QoS, and can be implemented in a
directory that uses LDAP as its access protocol are provided in
[PFSCHEMA] and [QOSSCHEMA], respectively. used by other
applications. This document specifies an extensible information model. While reuses this
document concept, but defines facilities specific
refinements for building using "embedded policy rules, conditions and
actions repositories" 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 accommodate the QoS Policy
schema to suit its own
application-specific needs.

2.1  Interaction Between the PCIM and This Document

This document both extends concepts that are part of the [PCIM] as well
as adds new functions that are not part of the [PCIM].

2.1.1  Extension needs of Concepts in QoS provisioning. These reflect the PCIM

The concept need
to provide nested levels of a policy repository, that is embedded within another
repository that contains policy administration and non-policy information, was
originally defined in an earlier version of the QPIM. It has
subsequently been moved into the [PCIM], since it is a generic concept
that is not limited scoping to QoS, policies and can be used by other applications. This
document defines specific refinements of the "embedded
policy
repository" information.

2.1.1.2  Extensions to accommodate the application-specific needs of QoS
provisioning. Reusable Objects

Similarly, the concepts of reusable- reusable objects vs. rule-specific objects
have been moved from an earlier version of this document to the [PCIM].
Equally similarly,
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, along with 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 PHBs.

Snir, Ramberg, Strassner, Cohen     expires October 2000		    7 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 has the following semantics: it can
either be used to contain a set of policyRules, or
policyRules and/or a set of
policyGroups, but not both. However, this simply gathers policy rules
together in a common container. It does not nest policy rules. policyGroups. This document 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

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 the
high-level rule itself. This
two parts. A high-level rule could consist of is used to group together a set of
lower-level 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, such a since QPIM allows for nested rules,
different examples of decision strategy strategies must be defined in this
document because it does define nested rules. and shown that they can work in this new environment. This
strategy
document defines two such decision strategies: match-first and match-
all. Both define an ordering that can be applied to a set of policyRule
policyRules and policyGroup objects within a larger context (e.g., a
policy domain). This in turn controls the execution of different policy
actions.

This document also defines Note that choosing a different decision strategy is one way to
change the result of executing a set of variable and constant definitions
for use with QoS policies. This concept is not present in policy rules without changing
the policy rules themselves.

2.1.2.3  Compound Conditions

[PCIM]
because the purpose defines conditions that consist of the a single term. [PCIM] is allows
such conditions to provide be logically combined using 'AND' and 'OR' terms.
This makes sense, because all conditions can be constructed from such
primitives. However, a general structure for richer means of representing policy rules, common conditions and actions. Variable and
constant definitions represent specific concepts that have pre-defined
semantics.

Finally, this
is called for.

This document adds extends the concept of a general structure for accommodating PHBs.
PHBs are simple (i.e., one-term)
condition to define compound conditions. This is conceptually
equivalent to using a concept set of simple conditions. However, supporting
compound conditions enables a better matching of the information model
to the environment that it is specific to DiffServ, modeling, and thus are not
defined in also simplifies the [PCIM].

2.2  High-Level Class Hierarchy

The following diagram shows how mapping
of the classes in this document relate 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. [PCIM]

Snir, Ramberg, Strassner, Cohen         expires October 2000		    8

(continued from previous page)

[unrooted]
   |
   +--Policy (abstract, defined May 2001             10

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 PCIM)
   |  |
   |  +---PolicyGroup (PCIM)
   |  |     |
   |  |     +---qosPolicyDomain (this document)
   |  |     |
   |  |     +---qosNamedPolicyContainer (this document)
   |  |
   |  +---PolicyRule (PCIM)
   |  |
   |  +---PolicyCondition (PCIM)
   |  |     |
   |  |     +---PolicyTimePeriodCondition (PCIM)
   |  |     |
   |  |     +---VendorPolicyCondition (PCIM)
   |  |     |
   |  |     +---qosPolicySimpleCondition (this document)
   |  |
   |  +---PolicyAction (PCIM)
   |  |     |
   |  |     +---VendorPolicyAction (PCIM)
   |  |     |
   |  |     +---qosPolicyPRAction (this document)
   |  |     |
   |  |     +---qosPolicyRSVPAction (this document)
   |  |     |
   |  |     +---qosPolicyRSVPSignalCtrlAction (this document)
   |  |     |
   |  |     +---qosPolicyRSVPInstallAction (this document)
   |  |     |
   |  +---qosPolicyPRTrfcProf (this document)
   |  |
   |  +---qosPolicyRSVPTrfcProf (this document)
   |  |
   |  +---qosPolicyVariable (this document)
   |  |
   |  +---qosPolicyValue (this document)
   |  |     |
   |  |     +---qosPolicyIPv4AddrValue (this document)
   |  |     |
   |  |     +---qosPolicyIPv6AddrValue (this document)
   |  |     |
   |  |     +---qosPolicyMACAddrValue (this document)
   |  |     |
   |  |     +---qosPolicyStringValue (this document)
   |  |     |

(continued on next page)

Snir, Ramberg, Strassner, Cohen     expires October 2000		    9

(continued from previous page)

[unrooted]
   |
   +--Policy (abstract, defined in PCIM, repeated for convenience)
   |  |
   |  +---qosPolicyValue (this document, repeated for convenience)
   |  |     |
   |  |     +---qosPolicyBitStringValue (this document)
   |  |     |
   |  |     +---qosPolicyDNValue (this document)
   |  |     |
   |  |     +---qosPolicyAttributeValue (this document)
   |  |     |
   |  |     +---qosPolicyIntegerValue (this document)
   |  |
   |  +---qosPolicyMeter
   |  |
   |  +---qosPolicyPHBSet (this document)
   |  |
   |  +---qosPolicyPHB (this document)
   |  |
   +--CIM_ManagedSystemElement (abstract, defined in PCIM)
         |
         +--CIM_LogicalElement (abstract, defined in PCIM)
            |
            +--CIM_System (abstract, defined in PCIM)
               |
               +---CIM_AdminDomain (abstract, defined in PCIM)
                     |
                     +---PolicyRepository (PCIM)

Snir, Ramberg, Strassner, Cohen     expires October 2000		   10

3. Containment Hierarchy

In this section, we describe 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 organization and structure notion of a Per-Hop
Behavior (specified by the QPIM
hierarchy. 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 consists are both inherently extensible. Furthermore, they are
designed to fit together to produce one "virtual" information model. As
such, both are independent of two hierarchies: A policy
definition hierarchy and a reusable objects repository hierarchy. A any particular data tree may contain any number of instances of each
hierarchy. Section 3.1 explains the containment storage mechanism and reference
access protocol. However, mappings can be defined to translate the data
from this single virtual information model
used to a form that can be
implemented in the construction a specific type of QoS Policy data trees. Section 3.2
describes storage mechanism that uses one
or more specific access protocols. Examples of mapping the particular containment hierarchy 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 definition
entity, which rules, conditions and
actions to build QoS policies, it is modeled by the qosPolicyDomain class. Section 3.3
describes 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 structure QoS concepts of the reusable objects repository. Further
down (section 3.4) we explain the relationships between those entities.

3.1. Containment Model

The QPIM uses and extends QoS Policy
schema to suit its own application-specific needs. This is best done by
extending the containment model set of [PCIM]. 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 paragraphs summarize diagram shows how the classes in this containment model. For more detail,
please refer document relate to [PCIM].

Conceptually,
the QPIM takes classes defined in the form of a tree hierarchy. To describe
the hierarchy using actual instances of model data, we use the term
'data tree'. A data tree is simply an arrangement of objects in a tree
structure. The data tree starts from a root object node. The data tree
itself consists of leaf and non-leaf (i.e., container) nodes. The root
node has one or more branch nodes that are either leaf or non-leaf
nodes. The tree construction involves placing objects as leaves of
other objects while maintaining a strict tree structure.

The basic mechanism used for expressing containment is 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.

Certain elements of the QPIM need a mechanism for an entity to
reference objects in a different tree in the containment hierarchy than
the tree in which the referencing entity exists. For example, the class
policyRule (defined in [PCIM]) is a container of conditions and actions
(policyCondition and policyAction classes, defined in [PCIM], or their
subclasses, such as those defined in this document). However, the
information model should allow the formation of (complex) conditions
(and actions), where some of the condition's (and/or actionĂs)
components are referenced remotely. An example of such a remote
reference is a reusable condition or a reusable action. Such reusable
objects must be referenced remotely because they always reside in a
specialized portion of the tree (in this case, in the policyRepository
container) that is different from the one where the referencing rule
resides. PCIM.

Snir, Ramberg, Strassner, Cohen         expires October 2000 May 2001             11

To support a unified mechanism for containment of "local" and "remote"
objects, [PCIM] introduces the notion

[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

(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

Section 3.3 describes the structure of the reusable objects repository.
Finally, section 3.4 explains the relationships between the domain data
tree and the reusable-object repositories.

3.1  Class and Relationship Hierarchies Defined in the QPIM

The QPIM consists of two hierarchies: an inheritance hierarchy that is
used to define a set of classes that represent entities in the managed
policy environment, and a relationship hierarchy that is used to define
a hierarchy of relationships that describe how different objects
interact with each other. These hierarchies work together to describe
entities in the managed environment and how they relate to and interact
with each other.

Two relationship constructs are used in the formal presentation of
QPIM. The first is an association, which models different types of
dependency relationships between two (or theoretically more) objects.
The second is an aggregation, which is a strong form of association
that typically represents a "whole-part" or a "containment"
relationship.

Both associations and aggregations are modeled as classes that contain
references to the objects that are participating in the relationship.
In addition, both associations and aggregations can be defined between
classes without affecting any of the related classes. That is, the
addition of either an association or an aggregation does not affect the
function or structure of the related classes.

Note that containment is a directional relationship - the containing
entity is known as the aggregate (the "whole" side of the
relationship), and the contained entities are known as the components
(the "part of" side of the relationship). For example, the relationship
between a policy container (e.g., gpsPolicyGroup, which is defined in
this document as a subclass of PolicyGroup, which is defined in [PCIM])
and the rules it contains (e.g., PolicyRule, which is defined in
[PCIM]) is modeled by an aggregation (PolicyRuleInPolicyGroup, which is
defined in [PCIM]). However, the association between a reusable object
and the repository in which it resides models a "resides-in"
relationship rather than "part-of" relationship. This is because a
given reusable object can reside in any repository according to the
discretion of the administrator - there is no whole-part relationship
connoted by placing a reusable object in a repository. Rather, there is
only a dependency relationship that states that in order to find the
given reusable object, you must look in this particular repository. On
the other hand, there is a whole-part relationship established when a
policy container, such as a PolicyGroup or a gpsPolicyGroup, is used to
contain a particular PolicyRule. Now, we are adding specific semantics
that say that a particular PolicyRule is-a-part-of a given policy
container.

Snir, Ramberg, Strassner, Cohen         expires May 2001             14

Relationship classes may be used to extend the semantics of the
relationship beyond the basic containment or reference concepts. For
example, a relationship class may contain added attributes that add
particular semantics. For example, the PolicyConditionInPolicyRule
aggregation defines the relationship between a PolicyRule and a set of
policy conditions (PolicyCondition, defined in [PCIM]). In this case,
the PolicyRule acts as a container, and can hold zero or more
PolicyConditions (which are the contained objects). Since this is
expressing a whole-part relationship, it is modeled as an aggregation.
However, this aggregation class carries two additional properties:
GroupNumber and ConditionNegated. These properties are used to add to
the relationship itself the semantics of sub-grouping of conditions and
whether to prepend a Boolean 'NOT' operator to the condition.
Implementers of a particular QoS Policy system may further sub-class
relationships to incorporate additional application-specific semantics
as required.

Comprehensive presentation of relationships and their modeling is
available in [PCIM].

Two important examples of using aggregation are composition and
scoping. An example of composition is the PolicyRule. It has its own
attributes, but it is only complete when it is used in conjunction with
a set of conditions and actions. Conceptually, a PolicyRule serves as a
container that aggregates a set of PolicyCondition objects and a set of
PolicyAction objects. An example of scoping is grouping objects under a
single container (e.g., qosPolicyDomain) so that common administrative
rules can be applied to all of the objects in a container.

3.2  Implementation Guidelines

The QPIM defines two information hierarchies. Objects that are to be
managed are represented by the classes in the inheritance hierarchy.
Behavior that is to be represented and managed is represented by the
classes in the relationship hierarchies. An implementation is not
complete if just the class inheritance hierarchy is implemented - both
hierarchies MUST be implemented.

Many data storage technologies are incapable of directly representing
relationships. However, all data storage mechanisms of interest can
either emulate relationships or have specific constructs that can
implement some, but not all, relationships. For example, an LDAP based
directory does not have the concept of a general dependency
relationship (although one can be implemented in a variety of ways),
but it does have the concept of a containment relationship.

In general, an implementation will define two types of information. The
first type of information is policy definition data. This information
consists of policy rules and groups, and the components of policy

Snir, Ramberg, Strassner, Cohen         expires May 2001             15

rules, that are used to govern the application of policies to manage
entities. The second type of information is a set of nested containers
that form a hierarchy for storing and managing reusable objects.

For applications that want to manage and control QoS, containers
provide significant convenience benefits. Containers can be used to
group similar policies and policy information together in order to make
the policy data easier to manage. They also enable an organization to
impose its own views of organizing policies and policy information in
the data store. This is done in QPIM by enabling a single monolithic
repository to be conceptually divided into a set of repositories that
reflect the administrative use of the policies. To this end, the QPIM
not only supports the use of containers for grouping information, but
also for determining execution semantics of policy rules.

3.2.1  Modeling Containment

Containment is a general concept that is expressed in an information
model using either an association or (more usually) an aggregation.
Different data stores have different characteristics (e.g., data
structures, organization of data, and access protocols). Therefore,
there will be many mappings from a single information model, one for
each type of data store. This means that containment may be expressed
differently in each mapping. However, this document makes no explicit
or implicit assumptions about the storage mechanism, access protocol,
or other characteristics of different data stores. The information
model presented here can be mapped to most storage mechanisms and
models, such as LDAP directories, relational DBMS, SMI, and others.

For example, the basic mechanism used for expressing containment when
mapping to a directory is placement of the objects in the data tree. To
express the relationship of "container - contained" between a container
object and the objects it contains, the contained objects are placed
below the container object. In a relational database system, on the
other hand, this relationship may be implemented by means of various
key/foreign-key join mechanisms.

In QPIM (as well as in [PCIM]) an object may be related to its
container in one of two ways. We refer to these methods as "ad-hoc"
containment and "indirect" containment, as follows:

1. To establish ad-hoc containment the object is created and is
associated to its container by means of an instance of the
appropriate aggregation class.

2. To establish indirect containment the object is created and placed
in a reusable-object repository The contained object must be given a
unique name that is scoped by the containing repository. The
instance of the aggregation class must now contain a reference to
the reusable object.

Snir, Ramberg, Strassner, Cohen         expires May 2001             16

The difference between ad-hoc objects and reusable objects is that ad-
hoc objects need not be named - they are implicitly scoped by their
containing object. However, reusable objects must be uniquely named so
that the object that is referencing them can differentiate between
reusable objects of the same type.

Reusable-object repositories facilitate the central management of
commonly referenced objects like named conditions and actions, or
commonly occurring variables and values that are used in conditions.

3.2.2  Implementing Relationships

[PCIM] recommends that relationships be implemented as classes. In
[PCIM] (as well as in QPIM), aggregation and association classes serve
these two purposes:

1. Model a relationship between two objects. One of the most important
types of relationships for QoS is containment. Relationships are
used in QPIM to model the relation between a container entity and
its contained entities.
2. Unify the containment model so that both ad-hoc and indirectly
contained objects (which are accessed in a reusable-object
repository) are treated identically

The following paragraphs explain how the three purposes are
accomplished.

3.2.2.1 Relationship modeling

A relationship class models containment (as well as other types of
dependencies) as a set of (usually bi-directional) references. For a
binary relationship (which is the overwhelming majority of
relationships used), one reference property points to an object on one
side of the relationship while another property points an object in the
other side of the relationship.

Sometimes it is important for a relationship to express added
semantics. Since a relationship is modeled as a class, the relationship
itself may use all the power of class design. This means that in [PCIM]
and QPIM, relationships can contain properties and methods, and may
take advantage of inheritance. For example, the relationship may be
assigned properties that are used to represent specific semantics of
the relationship itself. For example, if the information order requires
some sub-grouping of the contained object, as is the case for
conditions in a policy rule (e.g., PolicyCondition, which is defined in
[PCIM]), then the corresponding relationship class (e.g.,
PolicyConditionInPolicyRule, which is defined in [PCIM]) will have a
corresponding property (i.e., GroupNumber) that represents the group
membership number. This is a technique that enhances the independence
of the two objects on both ends of a relationship, because such

Snir, Ramberg, Strassner, Cohen         expires May 2001             17

properties connote that their values reflect the relationship itself
and not an inherent property of either object participating in the
relationship. In other words, the container doesn't carry constituent
specific information, and the contained object is independent from
other contained objects and its container.

3.2.2.2  Representing Containment in a Consistent Manner

Recall that a container may contain reusable objects as well as "ad-
hoc" objects. The contained objects themselves are not "aware" of their
reusability status; there's no property in the contained object class
that denotes reusability. The aggregation relationship is also unaware
of whether the contained object happens to be reusable or not. It
merely carries a reference to this object in one of its properties
(e.g., the PartComponent property of the PolicyConditionInPolicyRule
class, defined in [PCIM]). The membership of an object in a reusable-
object repository is represented by an association between the
particular repository and the member object. It is fully expressed by
this association so that the repository, the container and the
contained objects can be independent. This approach also contributes to
data integrity and scalable data storage mapping implementation.

3.2.3  Mapping Differences and Examples

Mapping the information model to different data storage mechanisms may
result in various interpretations and implementations. To end this
section we'll discuss two comprehensive examples to illustrate some of
the issues concerning implementation and to highlight the flexible
design this model provides. Note that even for an LDAP directory, there
could be many different interpretations that result in different data
models. Two companion documents to QPIM, [PFSCHEMA] and [QOSSCHEMA],
specify a standard mapping of QPIM to an LDAP directory.

Example 1: Aggregation in LDAP directories

An LDAP aggregation class is specified to implement each aggregation
class in the information model. When adding a contained object to a
container, an instance of the aggregation class is created and the
aggregation property that points toward the contained object is
assigned a DN for that object. No distinction is possible (nor is it
desired!) between an aggregation instance for an ad-hoc object and that
of a reusable object.

All instances of the aggregation as well as all ad-hoc objects are
placed directly under the container instance in the DIT. When
collecting the contained object, a single LDAP search may be used to
fetch all objects residing directly under the container. A simple
procedure can determine if reusable objects exist and require added
fetch operations. The procedure scans the aggregation instances and
fetches those that have not already been fetched because they did not
reside in the node directly under the container. Fetching a reusable

Snir, Ramberg, Strassner, Cohen         expires May 2001             18

object is done by using the DN in the aggregation property that
contains a reference to the contained object.

Example 2: Aggregation in a relational DBMS

No standards-based mapping has yet been defined for any RDBMS at this
time. This example merely studies a possible implementation.

We'll assume that the aggregation is "simple" and does not define any
additional properties to carry added semantics beyond the container-
contained relationship.

Two tables are of interest:

1. Container object class: A row exists for each container object of
this class.
2. Contained object class: A row exists for each contained object of
this class.

Because this is a "simple" relationship as described above, no special
relationship class is necessary. Instead, the contained object table
has a column that is a foreign key to the container object.

For example, suppose a container class C is implemented in a table CT
with a primary key column pkc. A contained object class CO is
implemented in a table COT with a foreign key column fkc (referencing
CT). When collecting contained objects in table COT for the container
object (which is table CT), the following SQL statement can do the job
through a simple join:

  Select <properties list> from COT, C where COT.fkc == C.pkc;

Note, however, that this is a very restrictive implementation. It might
be advisable to implement a third table for the aggregation itself so
that adding columns to carry added semantics can be done without having
to redefine the schema.

3.3. QoS Domain Data Tree

The entity that represents a single policy hierarchy is called a QOS
Domain, and is modeled by the qosPolicyDomain class. This class is a
derivative of the PolicyGroup class in [PCIM].

Figure 1 shows a summary view of the QoS domain data tree hierarchy.
The text in parentheses refers to the explanations below the figure,
which provide specific semantics for each object in the hierarchy.

Snir, Ramberg, Strassner, Cohen         expires May 2001             19
   +---------------+
   |qosPolicyDomain| (root of the data hierarchy)
   +---------------+
      |   +----------+
      |-->|policyRule| (a)
      |   +----------+
      |      |   +------------------------+
      |      |-->|gpsPolicySimpleCondition| (b)
      |      |   +------------------------+
      |      |   +--------------------------+
      |      |-->|gpsPolicyCompoundCondition| (b)
      |      |   +--------------------------+
      |      |       |   +------------------------+
      |      |       |-->|gpsPolicySimpleCondition| (c)
      |      |       |   +------------------------+
      |      |       |   +--------------------------+
      |      |       |-->|gpsPolicyCompoundCondition| (d)
      |      |           +--------------------------+
      |      |   +---------------+
      |      |-->|qosPolicyAction| (e)
      |      |   +---------------+
      |      |   +----------+
      |      |-->|policyRule| (f)
      |      |   +----------+
      |      |   +--------------+
      |      |-->|gpsPolicyGroup| (g)
      |          +--------------+
      |   +--------------+
      |-->|gpsPolicyGroup| (h)
      |   +--------------+
      |      |   +----------+
      |      |-->|PolicyRule| (i)
      |      |   +----------+
      |      |   +--------------+
      |      |-->|gpsPolicyGroup| (j)
      |          +--------------+
      |   +---------------+
      |-->|qosPolicyDomain| (k)
          +---------------+

           Figure 1: Qos Domain Data Tree Hierarchy

Explanation to the relationships defined in figure 1:

a - Any number of PolicyRule instances may be contained by a given
qosPolicyDomain instance in the hierarchy by using the
PolicyRuleInPolicyGroup aggregation. This has the effect of making such
policyRules global for that container. Finer granularity can be
obtained by either nesting qosPolicyDomain instances (shown in
relationship (k)), or by embedding other types of containers (e.g.,

Snir, Ramberg, Strassner, Cohen         expires May 2001             20

gpsPolicyGroup, which is shown in relationship h) within a given
qosPolicyDomain container. Note that gpsPolicyGroup objects can also be
nested, as shown in relationship (j).

b - Any number of qpsPolicySimpleCondition and
gpsPolicyCompoundCondition instances may be contained by a PolicyRule
instance via the PolicyConditionInPolicyRule aggregation.

c - Any number of gpsPolicySimpleCondition instances may be contained
by an instance of a gpsPolicyCompoundCondition via the
PolicyConditionInPolicyCompoundCondition aggregation.

d - Any number of gpsPolicyCompoundCondition instances may be contained
by an instance of a gpsPolicyCompoundCondition via the
PolicyConditionInPolicyCompoundCondition aggregation. The nested
containment combined with (c) above facilitates formation of arbitrary
Boolean expression and reuse of existing conditions as components of
such expressions.

e - Any number of qosPolicyAction instances may be contained by a
PolicyRule instance via the PolicyActionInPolicyRule aggregation.

f - Any number of PolicyRule instances may be contained by another
PolicyRule instance by using the PolicyRuleInPolicyRule aggregation.
This allows for recursively nesting policy rules within a given
policyRule instance, thus forming rule/sub-rule semantics.

g - Any number of gpsPolicyGroup instances may be contained by an
instance of PolicyRule via the PolicyGroupInPolicyRule aggregation.
This aggregation also implements a rule/sub-rule relationship similar
to the one defined in (f). However, it is somewhat richer, in that it
allows a complete policy container (i.e., a group of rules) to be
nested within a rule as a reusable unit.

h - Any number of gpsPolicyGroup instances may be contained by an
instance of a qosPolicyDomain via the PolicyGroupInPolicyGroup
aggregation.

i - Any number of PolicyRule instances may be contained by an instance
of a gpsPolicyGroup via the PolicyRuleInPolicyGroup aggregation.

j - Any number of gpsPolicyGroup instances may be contained within
another gpsPolicyGroup instance by using the PolicyGroupInPolicyGroup
aggregation. This allows for recursive nesting of groups of rules
within a given gpsPolicyGroup instance. This enables one policy
container to scope other contained policy containers. Note also that
all subclasses of PolicyGroup (e.g., both the gpsPolicyGroup as well as
the qosPolicyDomain class) inherit this relationship.

Snir, Ramberg, Strassner, Cohen         expires May 2001             21

k - Any number of qosPolicyDomain instances may be contained by an
instance of a qosPolicyDomain class via the PolicyGroupInPolicyGroup
aggregation. This effectively enables the administrator to define a
hierarchical set of administrative roots within a single, larger
administrative scope.

3.4  Types of Grouping Classes

There are three fundamental types of grouping mechanisms defined in
this document, represented by three different classes. These are the
PolicyGroup, QoSPolicyDomain, and gpsPolicyGroup classes.

The PolicyGroup class is defined in PCIM. This class is a generalized
aggregation container.  It enables either PolicyRules or PolicyGroups
to be aggregated in a single container. It has no properties and no
additional semantics.

The qosPolicyDomain class is defined in section 8.14 of this document.
This class is a subclass of PolicyGroup, and is used to define the root
of a single administrative QoS policy domain. As such, it contains the
domain's policy rules and other associated data. Note that additional
containers that are aggregated by this object can define additional
policy rules and other policy data that are specific to that level of
scoping. This class defines the following additional semantics compared
to a PolicyGroup:

  - the root of a single administrative policy domain
  - the decision match strategy to be employed by default for all
    objects that are aggregated by this object (note that individual
    containers may override this default behavior by defining their
    own match strategies at their scoping level)

The gpsPolicyGroup class is defined in section 8.15 of this document.
This class is also a subclass of PolicyGroup, and represents an
administratively-defined policy rule container. All policies that are
commonly administered are defined in a particular gpsPolicyGroup. This
class defines the following additional semantics compared to a
PolicyGroup:

  - the container is allowed to have its own priority; this enables it
    to be treated the same as a policy rule when the order of execution
    is determined
  - the container is allowed to have its own decision match strategy
    (note that this may be used to override the default match strategy
    defined in a qosPolicyDomain)
  - the container has a property that collects the roles and role-
    combinations that are associated with all of the policy rules that
    are aggregated by this container.

Snir, Ramberg, Strassner, Cohen         expires May 2001             22

The difference between the qosPolicyDomain and the gpsPolicyGroup
classes are:

  - the qosPolicyDomain class serves as the root of a policy domain;
    the gpsPolicyGroup is not to be used for this purpose
  - conceptually, gpsPolicyGroups are aggregated by a
    qosPolicyDomain; the gpsPolicyGroups serve to provide a
    finer level of granularity in defining and applying policies
  - gpsPolicyGroups have roles and role-combinations, while
    qosPolicyDomains do not
  - gpsPolicyGroups have priorities, which qosPolicyDomains
    do not

One final note: each of these classes can serve as a container in
various data store implementations. Thus, the more general term
"container" will be used in this document to refer to a class that can
aggregate objects. If special semantics are required, then either a
qosPolicyDomain or a gpsPolicyGroup will be specifically called out,
according to the desired semantics.

3.5. QoS Policy Domain Grouping and Nesting

The qosPolicyDomain class is used to establish a QoS policy domain
within a particular data store. Different objects can be placed in this
policy domain so that they can then be grouped together and managed
according to a common set of policies. However, sometimes a more
sophisticated organization of policy information is required. In this
case, multiple QoS policy domains may be grouped together to provide
more granular management of policy data.

Each domain may be viewed as a contiguous set of nodes that operate
under a common system of administration and provide a common set of
services. Each node can contain policy rules and/or policy information.
Grouping may be desired to enhance various administrative tasks (e.g.,
ensure that a set of objects are all updated), or it may be required by
a particular policy application. For example, a particular policy
application may need a combination of policy rules and other data.
Storing these different data in a common container in a domain that
belongs to that application considerably simplifies this process.

The grouping strategy (as well as all location-oriented strategies) is
left for users and vendors to model, based on their unique situations
and requirements. This document presents guidelines and recommendations
for constructing QoS domains and grouping objects within a QoS domain.
Specific implementations may use other techniques to construct QoS
domains and to group objects within a QoS domain without violating the
integrity and consistency of the QPIM as long as two constraints are
met. First, the implementation MUST NOT define a class that performs
the same function as a QPIM class. If a QPIM class is deemed

Snir, Ramberg, Strassner, Cohen         expires May 2001             23

insufficient for a specific application, then that application SHOULD
derive a subclass from the QPIM class (as opposed to build a parallel
class that conflicts with the QPIM class). Second, the implementation
MUST NOT redefine QPIM classes in any way. This includes, but is not
limited to, canceling (also called deleting) attributes, renaming
attributes, or changing the purpose that a class or attribute was
designed for.

One way to group QoS policy domains is by creating a common root (which
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

+-------------+
|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

wish to access the same information. In fact, there may be multiple
such repositories, each used for collecting a different set of related
reusable objects. In this document, we will call such repositories
reusable-object repositories. (Note that [PCIM] refers to this object
as a PolicyRepository; we are using the term "reusable-object
repository" to emphasize the fact that this is a special "repository-
in-a-repository" for containing reusable objects).

The sharing of global or common objects enhances the interoperability
of various policy applications, thus serving the primary goal of this
information model. Such commonly used building blocks as PolicyGroup
and its subclasses (e.g., gpsPolicyGroup and qosPolicyDomain),
subclasses of PolicyCondition (e.g., qpsPolicySimpleCondition and
gpsPolicyCompoundCondition)and PolicyAction (e.g., qosPolicyPRAction
and qosPolicyRSVPAction), as well as lower-level objects (e.g.,
instances of qpsPolicyVariable and qpsPolicyValue) can be placed in the
reusable-object repository and used by multiple policy rules from
multiple domains.

Both the PCIM and the QPIM do not restrict the number of reusable-
object repositories that can be referenced from a single domain. Even a
single instance of a policy rule may contain references to objects
residing in more than one repository. It is important to note that the
QPIM does not dictate a QoS domain-wide scope for reusable objects, so
as to keep this concept as general as possible.

3.7. Instance Location

The purpose of the QPIM is to define a flexible structure of
information that does not pre-impose harsh restrictions on building the
data tree. When a data tree is derived from the QPIM, it is important
to ensure that this derivation is as free of restrictions as possible.

Although each data store has its own special considerations to be taken
into account, one of the most important considerations in mapping for
directories concerns placement of entries. The QPIM MUST NOT contain
any hidden assumptions about the placement of particular QoS policy
domain hierarchies (including, for that matter, placement of reusable-
object repositories as explained in section 3.13 below). Consequently,
the QPIM does not require any pre-defined locations for the portion of
the data tree that is dedicated to policy. An instance of the global
data tree (a corporate directory, for example) may in fact contain
several QoS policy domains that exist within the global date tree in
various places. Zero or more reusable-object repositories may also be
present in the global data tree.

In addition, the QPIM does not dictate any standard organization of
objects to be controlled via policy, either for QoS policy classes and
relationships or for reusable-object repositories that are used by QoS
applications.

Snir, Ramberg, Strassner, Cohen         expires May 2001             26

The only location/organizational rule that must be followed is:

   Each QoS policy domain must contain complete policy information that
   is necessary to describe that particular policy domain. Reusable
   objects SHOULD be placed in one or more reusable-object repositories
   and referenced by one or more objects that exist in the QoS policy
   domain, as appropriate. Note specifically that there is no
   requirement for reusable objects to be placed in the policy domain
   itself. Furthermore, reusable objects MUST be referenced using the
   properties defined in the appropriate [PCIM] and QPIM classes.

3.8. Policy Containers

A QoS policy domain is a container that provides scoping for QoS policy
containers, policy rules, and other policy information, as mentioned
previously. There are two information model class that are used to
represent QoS policy containers: the qosPolicyDomain and the
gpsPolicyGroup classes. Both classes extend the PolicyGroup class,
which is defined in [PCIM].

The ability to "divide" a given QoS policy domain's policy rules among
a set of policy containers provides a flexible framework to realize a
fine-grained administrative (or functional) structure. As the example
in figure 2 illustrates, it makes sense to divide policies for the
sales organization into two regional containers: Western and Eastern.
This enables a change in policies for one region to not affect the
policies currently in place for the other region.

Both the gpsPolicyGroup as well as the qosPolicyDomain policy
containers can be nested (e.g., a container may contain multiple
containers). A particular data tree, then, may be constructed with as
deep a hierarchy as needed.

3.8.1  Semantics of a gpsPolicyGroup

A (non-empty) gpsPolicyGroup holds an ordered list (i.e., a set) of
PolicyRule and/or gpsPolicyGroup instances. Both the gpsPolicyGroup
class and the PolicyRule class carry a priority property (called
gpPriority and Priority, respectively). Note that the PolicyGroup class
does NOT have a priority property - this is one of the reasons that the
PolicyGroup class has been subclassed in this document to provide these
semantics (through the gpsPolicyGroup class). These properties are used
to specify the order in which objects within a gpsPolicyGroup are
processed. The gpPriority property added to the gpsPolicyGroup enables
it to be treated the same way as a PolicyRule. That is, both the
gpsPolicyGroup as well as the PolicyRule will appear as atomic objects
that each has their own distinct priority.

Snir, Ramberg, Strassner, Cohen         expires May 2001             27

The semantics of the gpPriority property in the gpsPolicyGroup class
are identical to the semantics of the Priority property in the
PolicyRule class. Larger values mean higher priority (i.e., objects
having a higher priority will be processed before objects that have a
lower priority). If two or more objects have equal values, then those
objects may be evaluated in any order with respect to each other. For
example, if there are four objects A, B, C, and D having priorities 3,
5, 5, and 8, respectively, acceptable processing orders are {D, C, B,
A} and {D, B, C, A}. Note that the gpPriority and Priority properties
of the gpsPolicyGroup and PolicyRule classes respectively may be
unassigned, in which case they are treated as having the numerical
value of 0.

The reason to define a priority for the gpsPolicyGroup is to be able to
assign a "match strategy" (this is the gpNamedPolicyRuleMatchMethod
property of the gpsPolicyGroup class) to the gpsPolicyGroup. Remember
that a gpsPolicyGroup contains its own set of PolicyRules (and possibly
additional gpsPolicyGroups). Therefore, we need a way to evaluate the
PolicyRules that are contained in a gpsPolicyGroup relative to
PolicyRules that exist at the same level as the gpsPolicyGroup. This
property dictates the execution order of the contained QoS policy
rules, based on the values of the priority properties of the contained
instances. For example, a 'First Match' strategy means that the groups
and/or rules will be "matched" according to ascending order of their
Priority attribute. Decision strategies are explained in section 5.

Note also that the specific semantics of "execution order" depend on
the match decision strategy that is being used. For example, if a
"match-first" strategy is being used, then the first rule whose
conditions match (i.e., evaluated to Boolean 'TRUE') will have its
actions executed. However, if a "match-all" strategy is being used,
then all rules will be scanned for conditions that match. Then, the
actions for each rule that has matched will be executed in priority
order for all rules whose conditions were matched.

Figure 3 shows a simple example of the above execution process. Section
4 describes policy rules in more detail.

Snir, Ramberg, Strassner, Cohen         expires May 2001             28
  +---------------+
  |qosPolicyDomain|
  +---------------+
     |
     |   +--------------+
     |-->|PolicyRule A  |
     |   |  Priority=19 |
     |   +--------------+
     |
     |   +-----------------------+    +-------------+
     |-->|gpsPolicyGroup         |--->|PolicyRule C |
     |   |  gpPriority=5         | |  |  Priority=7 |
     |   +-----------------------+ |  +-------------+
     |                             |
     |   +-------------+           |  +-------------+
      -->|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

3.8.3  Sharing Policy Containers

For shared (reusable) containers, the priority assigned to the shared
container must be correct for all containing objects. This restriction
makes it impractical to share a particular policy container directly
(i.e., for two applications belonging to two different QoS policy
domains to share the same policy container). This is because a policy
container can contain not just policy rules, but also additional policy
containers. However, sharing (i.e, reusing) a policy container can be
made possible by "enclosing" a shared container within an exclusive
container (i.e., a container that is used to contain just a single
instance of a gpsPolicyGroup object). This in effect makes the
gpsPolicyGroup act as a single-level container. Depending on the
sharing context, the following techniques can be used for sharing an
instance of the gpsPolicyGroup class:

1. Reusing a gpsPolicyGroup inside a gpsPolicyGroup

To reference a container C1 with priority P1 from a container C, an
enclosing container D is created and is assigned the desired priority
P1 within the context of the C container. The D container is placed
under the C container in the data tree implementation. The D container
contains a single object, C1, by means of the PolicyGroupInPolicyGroup
aggregation. The D container complies with the naming and ordering
restrictions -- it is only created in the context of the C container
and can not be reused by any other container. This means that the
container C1 can not contain additional containers, even though it is
normally able to.

2. Reusing a gpsPolicyGroup inside a policyRule

To reference a container C1 with priority P1 from a policy rule R
(making it a "sub-rule" object, as opposed to a (more general)
container that is shareable by multiple policy rules), an enclosing
container D is created and is assigned the desired priority P1 within
the context of the sub-rule. The D container is contained in the rule
by using the PolicyRuleInPolicyRule aggregation. This aggregation
effectively places a given rule under an existing rule (in our example,
PolicyRule R contains a set of conditions and actions as well as the
container D; container D contains a single object, which is another
policy rule, but this policy rule acts as a sub-rule of R) using the
PolicyGroupInPolicyGroup aggregation.

This structure enables either another rule, R', or a policy container,
C', or both, to now share the C1 container by similar means.

Note that a shared container (C1 in the descriptions under #1 and #2
above) MUST be named so that it can be placed in a reusable-object
repository (see section 3.13).

Snir, Ramberg, Strassner, Cohen         expires May 2001             30

Figure 4 illustrates the above example of sharing a policy container
between a policy container and a policy rule. The numbers in
parentheses denote in-context ordering.

(rest of the hierarchy)
|
|   +-------+
|-->| C (1) |
|   +-------+
|       |   +--------+
(cont.) |-->| R1 (1) |
        |   +--------+
        |   +-------+
        |-->| D (2) |
        |   +-------+
        |      |                             +--------+
        |      |--PolicyGroupInPolicyGroup-->| C1 (*) |<----+
        |                                    +--------+     ^
        |   +--------+                                      |
        |-->| R2 (3) |             |
        |   +--------+                                      |
        |   +--------+                                      |
        |-->| R3 (4) |             |
        |   +--------+                                      |
        |      |   +--------+                               |
   (cont.)     |-->| R5 (1) |      |
               |   +--------+                               |
               |   +--------+                               |
               |-->| D' (2) |      |
               |   +--------+                               |
          (cont.)     |                                     |
                      |--PolicyGroupInPolicyGroup---------->+

(*) denotes a priority which is always ignored for reusable (shared)
policy containers.

  Figure 4. Sharing policy containers

3.9 Policy Roles associated with gpsPolicyGroup

The property gpPolicyRoles in the gpsPolicyGroup class
represents the roles and role-combinations associated with the set of
policy rules and gpsPolicyGroups aggregated by a gpsPolicyGroup. Roles
and role-combinations are defined in [POLTERM] and further elaborated
on in [PCIM].

Each value represents one role-combination. Since this is a multi-
valued property, more than one role-combination can be associated with
a single gpsPolicyGroup.

Snir, Ramberg, Strassner, Cohen         expires May 2001             31

After identifying the relevant set of rules to be used, rules should be
prioritized according to the procedures and rules defined in Section 5.
The PolicyRoles values defined per gpsPolicyGroup include implicitly
the roles defined for the contained policy containers.Overriding a role
or role-combination that is defined for a containing policy container
is not allowed.

The following example illustrates this situation:

gpsPolicyGroup 1 : PolicyRoles: Role A, Role B
|
+--PolicyRule 1.1 : PolicyRoles: <Not defined>
|
+--PolicyRule 1.2 : PolicyRoles: Role A, Role D
|
+--PolicyRule 1.3 : PolicyRoles: <Not defined>
|
+--PolicyRule 1.3.1 : PolicyRoles: Role E

PolicyRule 1.1 will be associated with roles A & B, because it
inherits both of these roles from gpsPolicyGroup 1
PolicyRule 1.2 will be associated with roles A, B, & D, because it
inherits roles A and B from gpsPolicyGroup 1 and adds D
PolicyRule 1.3 will be associated with roles A & B, because it
inherits both of these roles from gpsPolicyGroup 1
PolicyRule 1.3.1 will be associated with Roles A, B, & E, because it
inherits roles A & B from PolicyRule 1.3 and adds E

For a definition of the gpsPolicyGroup's PolicyRole property,
refer to section 8.2.3. Extended explanation on the definition and
usage of Roles is provided in [PCIM], section 5.2.

Note: A role or role-combination defined in contained and containing
policy objects does not imply any special behavior. The example above
illustrates this situation in PolicyRule 1.2, regarding role A.

3.10. Policy Rules

QoS policy rules are modeled by the [PCIM] class PolicyRule. All new
behavior in [PCIM] is obtained not by altering the definition of a
PolicyRule, but rather by adding new types of PolicyConditions and
PolicyActions (along with other associated objects) that are used by
the PolicyRule.

The semantics of a policy rule is, in essence, a conditional imperative
statement in the form 'if <condition> then <action>'. Applying a rule
means evaluating its condition and, depending on the truth value of
the condition, to either execute the action or to do nothing.

Evaluating a condition is known as 'matching the rule', an expression
we'll be using in later sections of this document. [PCIM] requires that

Snir, Ramberg, Strassner, Cohen         expires May 2001             32

a given policy rule SHOULD belong to one (and only one) gpsPolicyGroup.
These semantics are enforced by a special association,
PolicyRuleInPolicyContainer (defined in [PCIM]), with the appropriate
cardinality (1 policy container can contain zero-or-more PolicyRules).
However,  a policy designer may, in some cases, wish to reuse a
particular rule in more than one policy container. The designer MAY do
so by encapsulating the would-be reusable rule within a single,
reusable policy container and sharing that container, using the
technique described in section 3.8.3.

The order of the policy rules inside a container is based on the
relative values of the Priority attribute of each of the PolicyRules
(please see [PCIM] for more information). The enforcement of policy
rules also depends on particular settings belonging to the group. The
match strategy to be applied to the policy rules contained in a given
container is defined in the policyRuleMatchMethod attribute of the
gpsPolicyGroup object.

Policy rules may be nested. Placing a rule under another rule in the
data tree creates a nested rule. This is done by using the
PolicyRuleInPilicyRule aggregation.

3.11. Conditions and Actions

A policy rule is a composite object. The most
important components of a rule are the conditions and actions it
contains. A condition is a Boolean expression that is evaluated to find
out if the rule should be applied. An application of a rule means that
the actions that it contains will be executed. An action is a
specification of one or more QoS operations enforced on the designated
set of flows that MUST be done if the given policy rule is to be
applied. Actions are applied if the condition is TRUE (see [PCIM] for
more details).

3.12. Data Tree Example

The following example illustrates the hierarchical nature of the QoS
Policy data tree. Each organizational entity is related to a specific
type of class, which is shown in parentheses.

There are two QoS policy domains in this example, grouped together
under the same root (domain grouping). The QoS policy domains are:

  1. EastCoast
  2. WestCost

Snir, Ramberg, Strassner, Cohen         expires May 2001             33

Assume that each of these two qosPolicyDomains has its own PHB set
modeled by a gpsPolicyGroup with a set of policy rules defining the per
hop behavior for different DSCP values.

The EastCoast domain has 2 named policy containers. The first deals
only with ERP traffic and the second handles all other traffic:

  1. EastCoast (implemented as a qosPolicyDomain)
  1.1. ERP     (implemented as a gpsPolicyGroup)
  1.2. General (implemented as a gpsPolicyGroup)

The WestCoast domain has three named policy containers. The first deals
only with ERP traffic, the second deals with VoIP traffic, and the
third with all other traffic:

  2. WestCoast
  2.1. ERP     (implemented as a gpsPolicyGroup)
  2.2. VoIP    (implemented as a gpsPolicyGroup)
  2.3. General (implemented as a gpsPolicyGroup).

Each one of the gpsPolicyGroup entries can contain a
prioritized rule set. For example, the WestCoast ERP group contains the
rules relevant to ERP applications administered by the west coast
domain administrator.

We see from the above structure that this structure provides the
administrator with a great deal of flexibility. For example, similarly
containers, represented by the ERP and General
gpsPolicyGroups, can reuse common policy conditions and
actions. However, they are implemented as physically different
containers to enable the administrator to administer them
according to their own domain-specific needs.

3.13. Reusable-Object Repositories

Reusable objects are objects that can be referred by (hence "used by")
other objects. For example, the reference could be accomplished by
allocating an attribute on the referencing object that contains the
location of the referenced object. In this information model,
association classes (and naming rules) are used to establish
reusability of an object by creating a "resides-in" relationship
between the reusable object and the repository in which it resides. For
example, the PolicyConditionInPolicyRepository association is used to
enable an instance of a PolicyCondition class, or its subclasses, to
reside in an instance of a PolicyRepository class, or its subclasses.

The concept of reusable-object repositories is introduced by [PCIM] for
the purpose of allowing data tree constructors to share data among many
users. This document enhances this concept to model the needs of QoS
policy rules.

Snir, Ramberg, Strassner, Cohen         expires May 2001             34

A reusable-object repository hierarchy is rooted in an instance of the
policyRepository class (defined in [PCIM]). Individual reusable-object
repositories are named containers for reusable objects. Note that
[PCIM] allows arbitrary nesting of reusable-object repositories. This
can be conceptually thought of as a repository of repositories.

Each named reusable-object repository is a container of "reusable
objects" that can be used for a common purpose, and/or are administered
in a common way. A reusable object MUST have a unique name within the
the container that it resides in.

The complete aggregation model for the reusable-object repositories,
as well as detailed description of the various mechanisms for
constructing and maintaining such repositories, is described in detail
in [PCIM].

Common candidates for reusability are named instances of these classes
and their derivatives:

  - gpsPolicyVariable
  - gpsPolicyValue
  - gpsPolicySimpleCondition
  - gpsPolicyCompoundCondition
  - policyAction
  - gpsPolicyMeter, QoSPolicyTrfcProf, QoSPolicyQueue
- gpsPolicyGroup for policy rule reusability

3.14. Relationships Between QoS Domains and Repositories

As explained above, a QoS policy domain contains within it groups of
policy rules. A policy rule can contain ordered lists of conditions and
actions. The conditions and actions may be reusable objects that reside
in reusable-object repositories, or they may be rule-specific
conditions and actions that are embedded within the rule, or a
combination of both.

The advantage of reusable objects is that many different policy rules
may reference the same reusable object . References to reusable objects
need not all point to the same reusable-object repository; any policy
rule may contain references to reusable objects that reside in
different repositories.

The maintenance of the policy system is made somewhat more complicated
due to the flexibility provided by the ability to use multiple
repositories. For example, it is more difficult to prevent "dangling"
references to repositories that are no longer present. Schema designers
are encouraged to pay extra attention to this problem and exercise any
technique available from their implementation platform to maintain
integrity of their data trees. [PCIM] discusses this issue as well.

Snir, Ramberg, Strassner, Cohen         expires May 2001             35

4. Constructing a QoS Policy Rule

A policy rule modeled in [PCIM] represents the "If Condition then
Action" semantics associated with a policy. The QPIM extends these
semantics by refining the type of policy conditions and actions that
can be represented, extending the use of containers that hold policy
information, and providing additional features (nesting of rules,
aggregation of groups inside rules, defining extensible rule decision
strategies, linking to PHBs, and providing pre-defined
variables and constants that can be used to express the required
semantics of QoS policy rules in more detail).

The following sections describe these characteristics in more detail.

4.1 Policy Rule Structure

A policy rule has the following attributes (defined in [PCIM]) that can
be used to provide important semantics for QoS policy applications;
these are in addition to the attributes which serve as a key and
provide its name:

  1. An Enable flag that indicates whether a policy rule is
     administratively enabled, administratively disabled, or enabled
     for debug mode.
  2. A set of conditions,contained in the rules by means of the
     PolicyConditionInPolicyRule aggregation. Note that the new
     subclasses of PolicyCondition that the QPIM defines automatically
     inherits this relationships
  3. A flag indicating whether the rule's condition is in disjunctive
     or conjunctive normal form
  4. An (optionally ordered) list of actions, contained in the rule by
     means of the PolicyActionInPolicyRule aggregation.
  5. A priority value, defining the ordinal position of this rule
     relative to other rules (or any other contained objects) in the
     same container
  6. The attribute named mandatory, which is used to define whether
     the evaluation of conditions (and the subsequent execution of
     actions if the conditions evaluate to TRUE) is mandatory or not
  7. A SequencedActions attribute that defines how to execute the
     actions if the condition is TRUE
  8. An array of PolicyRoles attributes, that define the roles or
     role-combinations that are used in this rule
  9. A RuleUsage attribute, that contains a description of how this
     rule should be used

The Boolean condition is evaluated in order to determine if the set of
actions should be performed on a network flow by matching the network
flow attributes against the condition. The PCIM defines a generic
simple policy condition class, called PolicyCondition, which can be

Snir, Ramberg, Strassner, Cohen         expires May 2001             36

used to contain a single condition term to be tested. This document
defines two new policy condition classes. The first,
gpsPolicySimpleCondition, extends the semantics of a policy condition
to contain an ordered triplet ({variable, operator, value}). The
second, gpsPolicyCompoundCondition, uses the gpsPolicySimpleCondition
class to build a more generic compound condition class. QoS-specific
conditions SHOULD be formed by using the gpsPolicySimpleCondition class
and/or the gpsPolicyCompoundCondition class (both of these classes are
defined in this document) and/or the policyTimePeriodCondition class
defined in [PCIM] (or their subclasses, of course). Note that QoS-
specific conditions MAY be mixed with more generic conditions that are
not derived from either of these classes. However, these non-QoS-
specific conditions SHOULD be derived from the PolicyCondition class
(defined in [PCIM]). The combination of individual conditions in a
policy rule is defined in [PCIM] using the PolicyConditionInPolicyRule
aggregation.

Each action in the list is modeled by an class derived from the
PolicyAction class. The collection of individual actions in a policy
rule is defined in [PCIM] using the PolicyActionInPolicyRule
aggregation. This  class also contains a property, ActionOrder, that
defines the order in which policy actions are performed. .

The interpretation of a policy rule in regard to a given network flow
may be expressed as follows:

  If the rule is enabled and the Boolean expression is evaluated to
  TRUE, then use the Action list to extract the prescribed treatment
  for this flow.

The rest of this section describes the components of the policyRule
class and their relationships to the other classes defined in this
information model.

4.2 QoS Policy Conditions

A policy rule, as modeled in [PCIM], represents the "If Condition then
Action" semantics associated with a policy.  A condition is represented
as either an ORed set of ANDed terms (disjunctive normal form) or an
ANDed set of Ored terms (conjunctive normal form). Individual
conditions may either be negated (NOT C) or not negated (C).  The
actions specified by a policy rule are to be performed if and only if
the policy rule condition evaluates to TRUE.

The semantics of an individual condition are not specified in [PCIM].
Rather, the PCIM limits itself to specifying the structure of a
condition and its naming attributes. This document provides semantics
for common QoS policy conditions. For example, conditions such as: "If
the source IP address of the flow belongs to 10.1.x.x subnet" as well
as "If the IP protocol number of the flow equals the TCP protocol
number" are modeled in this document.

Snir, Ramberg, Strassner, Cohen         expires May 2001             37

4.2.1  Simple Conditions

The gpsPolicySimpleCondition class models individual conditions. This
class refines the basic structure of the PolicyCondition class defined
in [PCIM] by specifying the contents of the condition using the triplet
<variable>, <operator> and <value> to form the condition.

The variable specifies the attribute of a flow that should be matched
when evaluating the condition. A set of predefined variables that cover
network attributes that are commonly used for filtering are introduced
to encourage interoperability. This list covers layer 3 IP attributes
such as IP network addresses, protocols and ports, as well as a set of
layer 2 attributes (e.g., MAC addresses) and higher level attributes
such as application and user identity.

The QPIM defines a single operator, "match", as explained in the
'Simple Condition Operator' section.

The bound variable is matched against a value to produce the Boolean
result. In the first example above, a source IP address variable is
matched against a 10.1.x.x subnet value. The operator specifies the
type of relation between the variable and the value evaluated in the
condition. The match operator that is defined in QPIM is not just a
simple equal operator - it carries additional semantics (which are
defined in the PolicyValueConstraintsInVariable association) that
ensure that it contains an allowed value that belongs to a pre-defined
acceptable range of values. For example, an IPv4SourceAddress variable
is defined as a string. But the literal value of the string must
conform to the defined semantics of an IPv4 address, and must represent
a legal IPv4 address in either dotted decimal or CIDR format.
Similarly, a port is defined to be an integer. But negative values, or
positive values greater than 65535, are not allowed.

4.2.2  Compound Conditions

Sometimes it is convenient to model a general Boolean expression as an
atomic condition. For example, many packet-related conditions in policy
rules, from a networking perspective, can be modeled as Filters.
Filters are not modeled directly in the PCIM (i.e., no Filter class is
defined). However, the filter concept is central in the QoS Policy data
model.

Note that a filter may consist of multiple terms. The problem, then, is
that if all we have are the PolicyCondition, PolicyTimePeriodCondition,
and gpsPolicySimpleCondition classes, we can't refer to a filter as an
atomic condition, because we will need to combine multiple instances of
one or more of these classes to construct the filter. This is why the
QPIM has defined the gpsPolicyCompoundCondition class.

Snir, Ramberg, Strassner, Cohen         expires May 2001             38

The gpsPolicyCompoundCondition class enables multiple instances of the
PolicyCondition, the PolicyTimePeriodCondition, the
gpsPolicySimpleCondition, and/or the gpsPolicyCompoundCondition classes
to be combined and treated as a single atomic entity. This enables the
gpsPolicyCompoundCondition class to be used to model any general
Boolean expression, including common traffic filters. A filter is
constructed by the mechanisms supplied in the following PCIM
attributes:

  1. The ConditionListType attribute of the policyRule, which
     is a Boolean expression type that defines whether the simple
     condition is in conjunctive or disjunctive normal form.
  2. The PolicyConditionInPolicyRule aggregation class that does three
     things: associates conditions with a particular policy rule,
     defines whether the condition is negated or not, and partitions
     the referenced conditions into one or more groups. For more
     details, please see [PCIM], section 6.3.

4.2.3. Using Simple Conditions

Simple conditions can be used in policy rules directly or as building
blocks for creating compound conditions.

Simple condition composition MUST enforce the following data type
conformance rule: The gpValueTypes property of the variable must be
compatible with the value class name. This ensures that the binding of
the variable to an acceptable value can be done.

The QPIM defines four different ways to compose a simple condition
through the combination of representations of variables and values. The
following combinations of representing a simple condition are possible:

Variable representation

1. An "ad-hoc" instance of the class gpsPolicyVariable may be contained
   by the gpsPolicySimpleCondition instance using the
   PolicyVariableInPolicySimpleCondition.

2. A reusable, named instance of the class gpsPolicyVariable, which
   resides in a reusable-object repository may be indirectly linked
   with the gpsPolicySimpleCondition instance (using the same
   aggregation as above)

Value representation

1. An "ad-hoc" instance of the class gpsPolicyValue may be contained
   by the gpsPolicySimpleCondition class using the
   PolicyValueInPolicySimpleCondition aggregation.

Snir, Ramberg, Strassner, Cohen         expires May 2001             39

2. A reusable, named instance of the class gpsPolicyValue may be
   indirectly linked with the  gpsPolicySimpleCondition instance using
   the same aggregation as above).

The first method for representing variables and values enables either
to be embedded directly in a policy condition. This is important for
allowing simple and efficient access to the policy condition and its
embedded variables and/or values. It also enables the condition along
with its embedded variables and values to be treated as an atomic
object. The second method for representing variables and values enables
the condition to reuse the variable and/or value. In this case, both
would be stored in a PolicyRepository. Note that the method described
here for composing conditions out of variables and values allows for
uniform handling for both "ad-hoc" reusable objects, as the
relationships between the aggregator and aggregated objects are unaware
of the reusability vs. ad-hoc status of the aggregated objects.

A simple condition can be added to a PolicyRule or to a
gpsPolicyCompoundCondition in two ways:

1. Building a rule-specific ("ad-hoc") condition. In this case, the
goal is to embed the condition directly in either the PolicyRule or the
gpsPolicyCompoundCondition instance. In many data storage mechanism
implementations, this will be realized by treating the PolicyRule or
the gpsPolicyCompoundCondition instance as a container, and placing an
instance of the condition  in the container. For example, in a
directory implementation, the condition will be added as a leaf object
in the container. In the information model, we describe this case using
either the PolicyConditionInPolicyRule aggregation (in the case of a
embedding a condition directly in a PolicyRule) or the
PolicyConditionInCompoundCondition aggregation (for embedding either
gpsPolicySimpleConditions or gpsPolicyCompoundConditions in a
gpsPolicyCompoundCondition).

This case is called an "ad-hoc" simple condition. This method allows
the creation of a "private" simple condition, meaning that this
instance of the condition can't be used by any other policy rule or
compound condition, hence it is not reusable. However, this case
enables the condition and its container to be treated and managed
atomically.

2. Building a reusable condition. In this case, the goal is to treat
the condition as a reusable building block. Therefore, it will be
placed in a PolicyRepository and referenced by its containing object
(either a PolicyRule or a qpsCompoundPolicyCondition). In many data
storage mechanism implementations, this will be realized by treating
the PolicyRule or the gpsPolicyCompoundCondition instance as a
container, treating the PolicyRepository as a separate container, and
using an attribute in the PolicyRule or gpsPolicyCompoundCondition to
reference the condition in the PolicyRepository. For example, in a

Snir, Ramberg, Strassner, Cohen         expires May 2001             40

directory implementation, a DN pointer will be used to refer to the
condition. In the information model, we describe this case using two
relationship classes. One class, the PolicyConditionInPolicyRepository
association, establishes the "resides-in" relationship between the
reusable object and the reusable-object repository in which it resides.
Another class, the PolicyConditionInPolicyRule aggregation class,
establishes the "contained-in" relationship between the condition and
the rule that contains it.

The advantage of this approach is that by using an indirect reference
to refer to an instance of a condition that resides in a reusable-
object repository, this method allows the sharing of reusable
conditions by multiple policy rules or compound conditions.

Schema designers should keep in mind that in some cases, an
implementation platform introduces an added cost to access reusable
objects that are located in different areas of the data store than the
referencing object is located in. For example, in LDAP based storage,
fetching a sub-tree (i.e., a container object and its "leaves") is a
single operation while accessing a referenced object is an additional
operation.

4.2.4. Using Compound Conditions

Compound conditions should be used when the definition of a set of
terms that should be treated atomically (e.g., as a single condition)
is required. One such example is the common case of association filtering on a
five- or six-tuple (e.g., the source and destination address and ports,
protocol, and DSCP). This type of filter  can be modeled as a container
that holds one or more simple conditions.

If filter reusability is not required, then an ad-hoc set of simple
conditions that implement a rule-specific condition is sufficient (it
carries the same semantics except for reusability).

All instances of the gpsPolicyCompoundCondition MUST carry unique
names. A name is a MUST property for reusable objects (this is required
by [PCIM]).

The gpPolicyConditionListType of the gpsPolicyCompoundCondition is set
to DNF or CNF (disjunctive or conjunctive normal form, respectively),
as required. Each of the conditions that are to be used in this
compound condition are defined using the
PolicyConditionInCompoundCondition aggregation. This aggregation
enables the condition to be treated as a container so that it can
aggregate other conditions, and is defined in QPIM.

Each condition that is contained in the compound condition can be
either  directly contained the compound condition (in which case it is
a rule-specific, ad-hoc condition) or be  a reusable condition that
resides in a PolicyRepository.

Snir, Ramberg, Strassner, Cohen         expires May 2001             41

An implementation may realize these three relationships in any way
desired to implement their semantics. Sometimes, this means that these
relationships will be implemented as their own classes, and sometimes
it means that they will be implemented in some other way that is
particular to that type of data store. For example, the [PFSCHEMA] uses
a combination of a class and a mechanism (DIT containment) to implement
these three relationships. The class is used to specify an optional NOT

operation to be applied to a condition (e.g., the condition is matched
if the term is NOT true), and aggregation
classes. These classes denote some type to define the interpretation of dependency relationship that
exists between the classes that term
(i.e., which terms are grouped together, and whether they are connecting. One type of
dependency that can be represented is, ORED or
ANDed together).

The following example illustrates the construction of course, containment.

[PCIM] recommends a reusable
compound condition, named "My-Server", that associations expresses the following
logic: SourceIPAddress=1.1.1.1 AND SourcePort=7777:

A compound condition is created and aggregations are 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 as classes. With respect to containment, using a gpsPolicySimpleCondition object. It includes a
SourcePort variable and an association
class represents the act integer value of 7777.

Each of containment itself. For example, the
PolicyConditionInPolicyRule aggregation (defined simple conditions is linked to the compound condition
container using the PolicyConditionInCompoundCondition aggregation.
The qpsPolicyCompoundCondition is then made reusable by placing it in [PCIM]) defines
that zero or more 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 are contained (using
the qpsPolicySimpleCondition class) as well as more complex expressions
(using the qosPolicyCompoundCondition class) by placing them in a given
common portion of the policy
rule. information tree (called the reusable-
object repository). In general, containment may 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 direct or indirect. Direct containment
means embedded within the
condition directly. Conceptually, this can be thought of as specifying
that when the association or aggregation condition is instantiated in a
repository, the child object instantiated, its variables and values will
also be directly scoped by instantiated as part of the container
object. Indirect containment means same object that when is used to build

Snir, Ramberg, Strassner, Cohen         expires May 2001             42

the association or
aggregation 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 repository, the child object will
instead be reusable-object repository and then referenced by the container object. As an example, if
(simple or compound) condition. The values (or variables) are linked to
the
target repository is a directory, then direct containment PolicyRepository using the PolicyElementInPolicyRepository
association; the condition is
implemented by instantiating linked to the PolicyRepository using the
PolicyConditionInPolicyRepository association. Note that the child reusable-
object as a child node of a
container. Similarly, indirect containment would repository may be implemented using
an attribute part of the same data store as that is a DN (i.e., which
contains the DN points to another object). aggregating condition, or it may be a physically different
data store..

4.3 Simple Condition Operator

The association classes can (and do) carry QoS policy simple condition includes the added semantics needed
by gpOperator property,
which specifies the information model. For example, internal order type of contained
objects is information that relation between the variable and the value
evaluated in the condition. In many cases, a generic 'match' operator
can be carried on used, and the association objects
themselves. This makes interpretation of the relation between the containment model more flexible, since
variable and value is implied by the
same object may value itself. For example, the
variable SourceIPAddress can be used by two containers in different parts of matched to an IP address, where the
containment tree.

Containment
'equal' relation is implemented differently implied, to a hostname in different data stores.
Therefore, which the containment tree that is being described 'resolve to'
relation is not
expressed directly 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 information model. Rather, acceptable values that the information
model specifies classes string can
take. For example, an improperly formed address in either CIDR or
dotted decimal notation can be detected and relationships rejected.

The QPIM defines a single operator, "match", that are used to model
entities and relationships between entities models the most
generic relation: that of being equal or belonging to.

4.4 QoS Policy Variables

QoS policy variables are represented used for building individual conditions, as
defined in section 4.2. The variable specifies the
containment data model. A mapping attribute of the data specified in an
information model to a form flow
that is repository-dependent must also should be
specified. This is what [PFSCHEMA] and [QOSSCHEMA] do for the [PCIM] bound and this document, respectively. Please refer evaluated according to [PCIM] for more
information on the details a set of the association and aggregation class
mechanisms.

3.2. QoS Domain Containment Hierarchy

The entity that represents pre-defined
semantics in a single policy hierarchy condition. Its purpose is called QOS
Domain and to act as a binding point,
associating a condition with an object whose data is modeled by evaluated
according to the specified operator/value. The QPIM has defined
semantics for some of the qosDomain class, which is a derivative most common of these variables based upon
these sources to guide the PolicyGroup class in [PCIM]. 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 October 2000		   12

Figure 1 shows a summary view May 2001             43

Not every combination of the QoS domain containment hierarchy.
The text in parenthesis denotes object containment style: either
through placement in the data tree (i.e., using a class to form variable and a
container in value creates a specific place in the data tree) or indirectly through
association or aggregation classes.

   +---------------+
   |qosPolicyDomain| (root)
   +---------------+
      |
      |   +-----------------------+
       -->|qosNamedPolicyContainer| (placement)
          +-----------------------+
             |
             |   +----------+
              -->|policyRule| (placement)
                 +----------+
                    |
                    |   +------------------------+
                    |-->|qosPolicySimpleCondition| (via association)
                    |   +------------------------+
                    |
                    |   +---------------+
                     -->|qosPolicyAction| (via association)
                        +---------------+

           Figure 1: Qos Domain containment hierarchy

3.2.1. Domain Grouping and Nesting

QoS policy domains may be grouped together to model multi-domain
systems. Here, meaningful
condition. For example, a domain is source IP address variable can not be matched
against a contiguous set of nodes value that operate under specifies a common system of administration and provide port number. The QPIM defines a common set of services.
Grouping may be desired to enhance various administrative tasks, or it
may
variables that can be required by a particular policy application. The grouping
strategy (as well as all location-oriented strategies) is left for
users/vendors used to model based on their unique situations and
requirements. This document presents guidelines and recommendations for
grouping QoS domains, but specific implementations may use other
techniques without violating the integrity and consistency of the QPIM.

One way to group QoS policy domains is by creating a common root for
several QoS policy domain data tree instances. This conditions, and
assigns appropriate semantics for each. Each type of variable
inherently selects the set of value types that it can be done by
using the PolicyGroup (defined in [PCIM]) class as matched
against (i.e. a root for the
multi-domain tree. In this case, all value that is needed is could be compared and evaluated to place the
appropriate number a Boolean
expression).

Variables have data types. Many of qosPolicyDomain (defined the variables defined in this document)
instances under the appropriate policyGroup instance.

Snir, Ramberg, Strassner, Cohen     expires October 2000		   13

Figure 2 is an example draft
have associated semantics that depicts limit the ability to provide different
classes set of service to different organizations values 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
particular value type that can be matched against it in a separate QoS policy domain (which is an instance of
the qosPolicyDomain class). Each qosPolicyDomain class is used condition.
This may be viewed as a
container to hold all second level of the policies for integrity checking. For
example, a given portion variable representing the source-port must limit the set of
values that it can assume to the
organization. In Figure 2, 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 level variable. Thus, it
is represented by not enough to say that the nesting data type of
qosPolicyDomain classes.

Each qosPolicyDomain instance serves as a container that contains the source-port variable is
an
ordered list of related QoS policy rules integer; we also need to ensure that apply the value to be tested is
within a different part
or function valid range of the domain (e.g., Eastern Sales vs. Western Sales). integers. This
grouping is done using instances of achieved by associating the qosNamedPolicyContainer clas.
The qosNamedPolicyContainer class would in turn contain either a set of
policyRule instances, a set of policyGroup instances (to provide
further grouping of policy rules
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 scoped realized by defining a given
qosNamedPolicyContainer), or both.

+-------------+
|policyGroup  | <------------------- QoS policies for 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 enterprise
+-------------+
   |
   |   +---------------+
    -->|qosPolicyDomain| <----------- QoS policies for object constraint language,
may be integrated with the Sales group
       +---------------+
         |
         |   +---------------+
         |-->|qosPolicyDomain| <-------- QoS policies for Western Sales
         |   +---------------+
         |     |
         |     |   +-----------------------+
         |     |-->|qosNamedPolicyContainer| <--Qos Policies for group
         |     |   +-----------------------+    A within Western Region
         |     |
         |     |   +-----------------------+
         |      -->|qosNamedPolicyContainer| <--Qos Policies for group
         |         +-----------------------+    B within Western Region
         |
         |   +---------------+
          -->|qosPolicyDomain|  <--------QoS policies for Eastern Sales
             +---------------+
               |
               |   +-----------------------+
               |-->|qosNamedPolicyContainer| <--Qos Policies for group
               |   +-----------------------+    C within Eastern Region
               |
               |   +-----------------------+
                -->|qosNamedPolicyContainer| <--Qos Policies for group
                   +-----------------------+    D within Eastern Region

       Figure 2: Top-level policy data tree example

Snir, Ramberg, Strassner, Cohen     expires October 2000		   14

The modeling approach used in information model to provide even more
metadata to describe legal behavior, values and operations on the previous example
variable. Currently, such a language is but one possible
strategy among many. The not integrated with either this
information model allows for arbitrary nesting or PCIM. The mechanism defined in this draft enables
implementation experience to be gained to help guide the integration of groups, thus providing
a constraint language in the means for modeling both wide future.

The QPIM defines one attribute, one association, and deep
hierarchies.

3.2.2. Resource Sharing

Object instances residing in different parts one general
purpose mechanism that together characterize each of the containment tree
are independent to 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 means variables that
it defines:

  1. The property gpVariableName of
referencing reusable objects. These are objects the qpsPolicyVariable class defines
     the well-known name used for logically binding all variables that
     are placed defined in this document to a
special portion set of allowed value data types.

  2. The PolicyValueConstraintsInVariable association defines the repository dedicated set
     of value classes that could be matched to this purpose. In fact,
there may variable.

  3. The list of constraints on the values that the PolicyVariable can
     hold (i.e., values that the variable must match) are defined by
     the appropriate properties of an associated PolicyValue class.

Snir, Ramberg, Strassner, Cohen         expires May 2001             44

For example, if a PolicyVariable represents the SourcePort of incoming
traffic, then a PolicyValueConstraintsInVariable association can be multiple such repositories, each
used for collecting a set to link the PolicyVariable instance to an qosPolicyIntegerValue
instance. This association by itself constrains the data type of related reusable objects. In this document, the
SourcePort PolicyVariable to be an integer. However, we will call such
repositories reusable-objects repositories.

The sharing of global or common objects enhances can further
constrain the particular values that the SourcePort PolicyVariable can
hold by entering valid ranges in the interoperability qpIntegerList property of various policy agents, thus serving the primary goal
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 model. Such commonly used building blocks as important
conditions (policyCondition and its subclasses ) and actions
(policyAction and its subclasses) can be placed in is related. An
implementation could conceivably realize this using zero or more actual
relationships.

The combination of the reusable-object
repository qpVariableName and used by multiple policy rules from multiple domains.
Both the [PCIM]
PolicyValueConstraintsInVariable assocation provide a consistent and
extensible set of metadata that define the QPIM do not restrict semantics of variables that
are used to form QoS conditions. Since the number
PolicyValueConstraintsInVariable association points to another class,
any of reusable-
object repositories the properties in the PolicyValue class can be used to constrain
values that the PolicyVariable can hold. For example:

  - The gpVariableName can be referenced from a single domain. Even used to identify common processing rules
    for a
single instance of variable having a policy rule may contain references specific name.
  - The PolicyValueConstraintsInVariable association can be used to objects
residing
    ensure that only proper classes are used in more than one repository. It is important the expression. For
    example, the SourcePort variable will not be allowed to associate
    to note that the
QPIM does qpsPolicyIPv4AddrValue class, since source ports have
    different semantics than IP addresses and may not dictate a QoS domain-wide scope for reusable objects, so
as be matched.
    However, it will associate to keep this concept as general as possible.

3.2.3. Placement a gpsPolicyIntegerValue class.
  - The purpose of PolicyValueConstraintsInVariable association also ensures that
    variable-specific semantics are enforced (e.g., the QPIM is SourcePort
    variable may include a constraint association to define a flexible structure of
information value object
    defining a specific integer range that does not pre-impose harsh restrictions on building the
data tree. Therefore, the QPIM must not contain any hidden assumptions
about should be matched).

4.4.1. Variable Binding

For the placement of particular QoS Policy schema to be interoperable, different policy domain hierarchies
(including, for that matter, placement of reusable-object repositories
as explained in section 3.3 below). Consequently, the QPIM does not
require any pre-defined locations for the portion of
management systems and policy servers must instantiate the data tree that
is dedicated to policy. An instance of same
variables with identical values (in the global data tree (a
corporate directory, for example) same evaluation operation).
While different policy servers may use a different binding mechanism,
the binding logic must result in fact contain several an identical instantiation.

Each variable defined in the QoS policy domains that exist within the global date tree in various
places. Zero or more reusable object-repositories may also data store must be present bound to a
logical entity such as a specific field in the global data tree.

In addition, IP header, a specific
class or property in 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. in a related Information or Data
Model, an application unique identifier or an application-specific
parameter.

Snir, Ramberg, Strassner, Cohen         expires October 2000		   15

The only location/organizational rule May 2001             45

When a policy server attempts to evaluate an expression containing
variables, it must instantiate the variables. To instantiate a
variable, that variable must be followed is:

   Each QoS policy domain must contain complete policy information,
   either by containment of objects or by containment of association
   and/or aggregation objects, that is necessary bound to describe that
   policy domain. Reusable objects SHOULD be placed a specific value (or values,
depending on its type category) and associated with a logical entity.
For example, in one or more
   reusable-object repositories the expression 'SourcePort == 80', the variable
'SourcePort' must be instantiated to a value and referenced by one or more objects
   that exist logically associated
with the packet header field containing the source port number, for the
expression to be evaluated.

If, in this example, the QoS policy domain, as appropriate.

3.2.4. Named Policy Containers

A QoS policy domain variable SourcePort is bound to a container value of (named) QoS Policy Containers, as
explained above. The information model class representing named QoS
policy containers
'80', then the expression is evaluated to TRUE for each packet that the qosNamedPolicyContainer class. This class
extends
source port number in the policyGroup class, which IP header field equal to 80. Otherwise it is defined in [PCIM].

A (non-empty) qosNamedPolicyContainer holds an unordered list
evaluated to FALSE.

4.4.2. Pre-Defined Variables

The purpose of
policyRules. There this section is to explain the need and define the
relationship of standard, frequently used variables with their logical
entities. Pre-defined variables are two levels 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 priority that variables, this
helps to abstract the QPIM specifies condition term such that its evaluation can be used to determine
performed in the order same way by all of execution those policy servers. If no such
set of QoS common variables exist, then each policy
rules. At the highest level, we can server is free to
define an unordered its own set of variables. Variations in each variable that each
policy
containers, 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 which has pre-defined
variables to support a priority attribute (called qpPriority).
This property is set of fundamental QoS terms that are commonly
used to order the top level form conditions. Examples of these include IP header field
values, user information, applications, and others. A pre-defined
variable MUST always have the containment
hierarchy. Within same name and binding semantics. For
example, a given containment level, we can then use pre-defined variable should be bound to the
Priority attribute 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 policyRule class pre-defined
variable.

Snir, Ramberg, Strassner, Cohen         expires May 2001             46

All standard variable names are case insensitive and do not include
spaces or other non-standard characters to establish an order promote ease of
which policy rule in use.

The implementers of client systems that map the QPIM to a given container executes next. Figure 3 shows specific
repository-based implementation MUST provide binding methods to bind
pre-defined variables according to the semantics specified in this
section.

Following is a
simple example of table that defines the ordering process. Section 4 describes policy
rules predefined variable names and
their binding. The table indicates which fields are checked in more detail.

  +---------------+
  |qosPolicyDomain|
  +---------------+
     |
     |   +--------------+
     |-->|policyRule A  |
     |   |  Priority=19 | actual
filters used in provisioning policies as well as in RSVP signaling
messages.

+-----------------+---------------------------------------------------+
|Variable name    |   +--------------+                Logical binding                    |
+-----------------+---------------------------------------------------+
|   +-----------------------+    +-------------+
     |-->|qosNamedPolicyContainer|--->|policyRule C SourceIP        | The source IP address of the flow. Compared to the|
|                 |  qpPriority=5 source IP header field, or the sender address in  |
|                 |  Priority=7 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   |   +-------------+
|  +-------------+
      -->|policyRule B                 |            ->|policyRule D sender port in the RSVP Filter spec object [RSVP].|
+-----------------+---------------------------------------------------+
| DestinationIP   |  Priority=3 The destination IP address of the flow. Compared  |
|  Priority=2                 |
         +-------------+              +-------------+

  Figure 3. Example Ordering for a QoS Policy Decision

Here, the ordering is A, then C, then D, then B. This is because the
qpPriority of the qosNamedPolicyContainer is higher than B, so each of
its contained rules are executed (in order) before B.

Snir, Ramberg, Strassner, Cohen     expires October 2000		   16

As implied by the class name, each instance of the
qosPolicyNamedContainer class MUST be assigned a name that is unique
within its given QoS policy domain. A given policy container must
belong to (i.e.: contained in) a single QoS policy domain. Sharing of
policy containers among QoS policy domains is not possible because of the dependency of the decision strategy on destination IP header field, or the relative priority within
each QoS policy domain.

The ability to "divide" a given QoS policy domain's policy rules among
a set session|
|                 | address in the RSVP SESSION object [RSVP].        |
+-----------------+---------------------------------------------------+
| DestinationPort | The destination Port of policy containers provides a flexible framework UDP/TCP flow. Compared  |
|                 | to realize a
fine-grained administrative (or functional) structure. As the example destination port field in figure 2 illustrates, it makes sense the TCP/UDP      |
|                 | header, or the session port in the RSVP SESSION   |
|                 | object [RSVP].                                    |
+-----------------+---------------------------------------------------+
| IPProtocol      | The IP protocol number. Compared to divide policies for the
sales organization into two regional containers: Western and Eastern.
This enables a change protocol  |
|                 | number in policies for one region the IP header field or to not affect the
policies currently IP        |
|                 | protocol in place for the other region.

While this strategy should meet most needs, taking a slightly different
approach can provide additional flexibility. This approach RSVP SESSION object [RSVP].       |
+-----------------+---------------------------------------------------+
| ToS             | The ToS variable is
illustrated by looking at how PHBs are modeled (see section 6). In this
approach, a different set of PHBs can be assigned bound to different policy
containers. This has the effect of modifying IP header ToS    |
|                 | byte.                                             |
+-----------------+---------------------------------------------------+
| DSCP            | The DSCP variable is bound to the interpretation of IP header DSCP  |
|                 | byte or to the DCLASS RSVP object.                |
+-----------------+---------------------------------------------------+
| DestinationMAC  | The destination MAC address variable is bound the |
|                 | frame destination MAC address.                    |
+-----------------+---------------------------------------------------+
| SourceMAC       | The source MAC address variable is bound the frame|
|                 | source MAC address.                               |
+-----------------+---------------------------------------------------+

(Table continued in next page)

Snir, Ramberg, Strassner, Cohen         expires May 2001             47

(Table continued from the
same PHBs by each policy container.

Each policy container is assigned a "match strategy". This previous page)

+-----------------+---------------------------------------------------+
| 8021QID         | The VLAN ID is defined
in bound to the qpNamedPolicyRuleMatchMethod attribute 802.1Q field of       |
|                 | the
qosPolicyNamedContainer class. This attribute defines how header.                                       |
+-----------------+---------------------------------------------------+
| Snap            | The snap protocol variable is bound to interpret the order of        |
|                 | protocol type carried over SNAP encapsulation.    |
+-----------------+---------------------------------------------------+
| Ethertype       | The ethertype variable is bound to the QoS policy rules that it contains. For example, a
FirstMatch strategy means that frame      |
|                 | header ethertype value.                           |
+-----------------+---------------------------------------------------+
| Ssap            | The source sap variable is bound the rules will be "matched" according to
ascending order of their Priority attribute. Decision strategies are
explained in section 5.

Policy container can be nested. A policy container may contain policy
rules (PolicyRule [PCIM]) or named policy containers. A particular
data tree, then, can be constructed as a deep hierarchy, if frame header |
|                 | field containing the
designers of source SAP.                  |
+-----------------+---------------------------------------------------+
|Variable name    |                Logical binding                    |
+-----------------+---------------------------------------------------+
| Dsap            | The destination sap variable is bound the policy system deem it desirable.

3.2.5. Policy Rules

Each qosNamedPolicyContainer holds a set of policy rules (or possibly
additional policy containers, which could be policyGroups or
qosNamedPolicyContainers, that contain policy rules). QoS policy rules
are modeled by frame   |
|                 | header field containing the [PCIM] class policyRule. destination SAP.      |
+-----------------+---------------------------------------------------+
| Application     | The semantics ID 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 application that generated the truth value flow.|
+-----------------+---------------------------------------------------+
| User            | The ID of the condition, to execute user that initiated the action flow, or do nothing. Evaluating a
condition is known |
|                 | designated as 'matching the rule', an expression we'll be using
in later sections of this document.

Snir, Ramberg, Strassner, Cohen     expires October 2000		   17

A given policy rule MUST belong to one (and only one)
qosNamedPolicyContainer. This restriction is necessary because the
units of reusability are, in reality, the policy condition flow owner.                     |
+-----------------+---------------------------------------------------+

        Table 1. Pre-defined Variables and action
terms that comprise Their Bindings

The definition of each predefined variable includes a policy rule (as opposed to standard name and
the policy rule
itself). This is because a policy rule allowed value types. The VariableHasDataValues association is used
to associate a composite object, made up
of several objects, but SHOULD be viewed as a coherent statement. It is
believed that allowing variable object with a policy rule to belong to more than one policy
container would decrease or even destroy its coherence. For example,
the rule itself value object.

Following is "aware" of its position inside its policy container,
so if we wanted to share a rule among many containers we'd have to
remove this knowledge from the rule. The notion of ordering table of rules is
so essential to variable names and the concept of policy value types defined
within this document that removing it from the rule
also renders the rule less expressive, making policy modeling can be used together in a more
difficult job. Furthermore, there simple condition.
In reality, these are other important attributes individual specializations of the general
association, PolicyValueConstraintsInVariable, that
are unique to exists between the rule's specific placement inside a policy group
and/or a policy domain. For example,
PolicyVariable and PolicyValue classes and their subclasses. A given
variable can further restrict the DSCP values (section 6) that
define how can be combined with it
in a flow given condition. This is colored (which in turn define done by restricting the set of QoS
policy actions values that should can
be invoked held by the rule) may be interpreted
differently in different QoS policy domains (or policy containers).
These examples show that the modeling appropriate attributes of shared rules the PolicyValue class that is inappropriate
for
used to represent the QPIM.

The order of constraining object in the policy rules inside
PolicyValueConstraintsInVariable association. For example, by default,
a container is based on condition including a variable with the
relative 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 Priority attribute of each
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 policyRules
(please see [PCIM] for more information). The enforcement qpIPv6AddrList attribute of policy
rules also depends on particular settings belonging to
the group. gpsPolicyIPv6AddrValue class. The
match strategy table below does not restrict new

Snir, Ramberg, Strassner, Cohen         expires May 2001             48

value classes defined elsewhere to be applied to the policy rules contained 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 a given
container section 4.5.

4.5 QoS Policy Value

The abstract class gpsPolicyValue is defined used for defining values and
constants used in the policyRuleMatchMethod attribute of the
qosNamedPolicyContainer object. Note that actions taken on packets may
use a different mechanism. For example, a DSCP policy conditions. Different value can be set
directly using types are derived

Snir, Ramberg, Strassner, Cohen         expires May 2001             49

from this class and represent the qpSetDSCPValue attribute various attributes required.
Extensions of the qosPolicyPRAction
class. However, qpsPolicyValue class, defined in this class could also define document
provide a set list of token bucket
parameters using values for representing the qpTrfcProf basic network attribute. This references a traffic
profile (represented by the qosPolicyPRTrfcProf class) that carries the
policer or shaper rate values to
Values can be enforced on a flow or a set of
flows.

3.2.6. Conditions and Actions

A policy rule is a composite object, used to represent constants as mentioned above. The most
important components of a rule are the conditions and actions it
contains. A condition is named values. Named values
could be kept in a Boolean expression that is evaluated reusable-object repository to see
if the rule should be applied. An action is a specification reused by multiple
conditions.
Examples of one or
more QoS operations enforced on the designated set constants include well-known ports, well-known protocols,
server addresses, and other similar concepts.

The qpsPolicyValue classes define 3 basic types of flows that MUST
be done if the given policy rule is to values: scalars,
ranges and sets. For example, a well-known port number could be applied. Actions are applied
if defined
using the condition is TRUE (see [PCIM] gpsPolicyIntegerValue class, defining a single value (80 for more details).

Snir, Ramberg, Strassner, Cohen     expires October 2000		   18

3.2.7. Data Tree Example

The following example illustrates the hierarchical nature
HTTP), a range (80-88), or a set (80, 82, 8080) of ports, respectively.
For details, please see the QoS
Policy data tree. Each organizational entity is related to a specific class definition for each value type of class, which is shown in parentheses.

There are two QoS policy domains in
section 8 of this example, grouped together
under the same root (domain grouping). document.

The QoS policy domains are:

  1. EastCoast (qosPolicyDomain)
  2. WestCost (qosPolicyDomain)

Each of these two QoS policy domains has its own PHB set. The EastCoast
domain has 2 named policy containers. The first deals only with ERP
traffic and the second handles all other traffic:

  1. EastCoast (qosPolicyDomain)
  1.1. ERP (qosNamedPolicyContainer)
  1.2. General (qosNamedPolicyContainer)

The WestCoast domain has 3 named policy container. The first deals only
With ERP flows, the second deals with VoIP, and information model provide the third with following classes, all
other traffic:

  2. WestCoast
  2.1. ERP (qosNamedPolicyContainer)
  2.2. VoIP (qosNamedPolicyContainer)
  2.3. General (qosNamedPolicyContainer).

Each one of
them extending the qosNamedPolicyContainer entries can contain a
prioritized rule set. 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 example, the WestCoast ERP group contains details, please see the
rules relevant to ERP applications administrated by class definition section of each value in
section 8 of this document.

4.6. PolicyTimePeriodCondition

The QoS Policy Information model uses the west coast
domain administrator.

We policyTimePeriodCondition
class (defined in [PCIM]) to define time based QoS policy rules. For
details, please see from [PCIM], section 6.5.4.7. Actions

4.7 Actions

The QoS Policy information model defines actions to control QoS
enforcement in both the above structure that this structure provides Integrated Service model as well as the
administrator with a great deal
Differentiated Service model. Three types of flexibility. For example, similarly
named containers, represented by the ERP and General
qosNamedPolicyContainers, can reuse common policy conditions actions are provided:
Signaling, Provisioning and Per-Hop-Behvior (PHB) actions. However, they

Snir, Ramberg, Strassner, Cohen         expires May 2001             50

Signaling actions are implemented as physically different
containers to enable the administrator used to administrate them
according provide policy control on RSVP
requests. Provisioning actions are used to their own domain-specific needs.

3.3. Reusable-Object Repositories

Reusable objects enforce differentiated
service edge policies including marking, policing and shaping
operations. PHB actions are objects that can be referred by (hence "used by")
other objects. For example, used to enforce per-hop behaviors across
the reference could be accomplished 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
allocating an attribute on the referencing object that contains the
location of
or objects describing the referenced object.

Snir, Ramberg, Strassner, Cohen     expires October 2000		   19

The concept of reusable-object repositories action(s) to perform. This extension is introduced done
seamlessly by [PCIM] for
the purpose requiring all QoS action classes to be subclasses of allowing data tree constructors 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 share data among many
users. This document enhances this concept aggregate actions. Actions are ordered
(as opposed to model the needs rules, which are prioritized). The order of QoS
policy rules.

A reusable-object repository hierarchy actions is rooted
specified in an instance of [PCIM] using the
policyRepository class (defined ActionOrder property.

The property SequencedActions 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 the aggregating instance of as a repository
PolicyRule (see section 6.3.6 of repositories.

Each named reusable-object repository is [PCIM]) defines whether a container specified
action order is required, recommended, or of "reusable
objects" 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 for a common purpose, and/or are administered
in a common way. A reusable object MUST have a unique name within the
the container that it resides in.

The complete containment model for the reusable-object repositories,
as well as detailed description of the various mechanisms for
constructing and maintaining such repositories, is described in detail
in [PCIM].

Anywhere in the QoS Policy information model, where a reference to express an
object can be made (a 'reference' type attribute),
order. In this reference
SHOULD point to a reusable object in a reusable-object repository.

Common candidates for reusability case, three attributes are named instances of these classes
and their derivatives:

  - qosPolicyVariable
  - qosPolicyValue
  - qosPolicySimpleCondition used:

  - policyAction GroupComponent, which defines zero or more PolicyRules that can
    contain the same PolicyAction
  - qosPolicyMeter, QoSPolicyPRTrfcProf and QoSPolicyRSVPTrfcProf PartComponent, which defines zero or more PolicyActions that are
    contained by a given policyRule
  - QoSPolicyPHBSet

Throughout this document, we point out ActionOrder, which is an unsigned integer 'n' that indicates the possible use
    relative position of repository
and repository objects, wherever this is appropriate.

3.4. Relationships Between QoS Domains and Repositories

As explained above, an action in the sequence of actions that are
    associated with a QoS given policy domain contains within rule.  When 'n' is a positive
    integer, it groups of
policy rules. A policy rule can contain ordered lists indicates a place in the sequence of conditions and
actions. The conditions and actions may be reusable object that reside
in reusable objects repositories.

Many references to reusable objects may be made from
    performed, with smaller integers indicating earlier positions in
    the rules of a
given QoS policy domain. Those references need not be all pointing to sequence.  The special value '0' indicates "don't care".  If
    two or more actions have the same reusable-object repository; even e single rule non-zero sequence number, they
    may contain
references to reusable objects that reside be performed in different repositories.

Snir, Ramberg, Strassner, Cohen     expires October 2000		   20

The maintenance of the policy system is made somewhat more complicated
due to any order, but they must all be performed at
    the flexibility of appropriate place in the reference model. overall action sequence.

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.

4. Constructing actions defined explicitly in a QoS Policy Rule

A policy rule modeled subclass of policyRule, the
ordering mechanism must be specified in [PCIM] represents the "If Condition then
Action" semantics associated with a policy. The subclass definition. Note
that QPIM extends these
semantics by refining does not define any policyRule subclasses. Instead, the type QPIM
defines subclasses of policy conditions policyCondition and policyAction to extend the
semantics of these classes.

Provisioning, PHB and signaling actions that can be represented, extending intermixed in a QoS
policy rule. Policy consumers (such as PDPs) MAY separate the use actions
into separate lists, but MUST respect the internal order of containers, the
specified actions.

Snir, Ramberg, Strassner, Cohen         expires May 2001             51

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 providing
additional features (nesting droppers.

The qosPolicyPRAction class is a generic class that defines a
set of rules, defining extensible rule
decision strategies, linking to PHBs, and providing pre-defined
variables and constants DiffServ actions that can be used applied to express an individual flow or
to a group of flows.

4.7.1.1  Meters

Meters measure the required
semantics temporal properties of QoS policy rules in more detail.

The following sections describe these characteristics in more detail.

4.1 Policy Rule Structure a stream of packets
selected by a classifier against a traffic profile.

A policy rule has meter is associated with a provisioning action using the following attributes (defined in [PCIM]) that
PolicyMeterInAction association. A meter can be shared among
(i.e., used to provide important semantics for QoS by) policy applications;
these are in addition to actions of different rules. If this is desired,
then the attributes which serve as a key and
provide its name:

  1. An Enable flag that indicates whether meter SHOULD reside in a policy reusable-object repository.

Meters measure flows matching the rule is
     administratively enabled, administratively disabled, condition per flow, per
interface, per role within a device, per device or enabled per role across all
devices. A per flow meter conceptually creates a new meter for debug mode.
  2. each
flow, measuring each flow against the profile. A per interface meter
measures the aggregate set of conditions (defined in either flows matching the
     PolicyConditionInPolicyRule or PolicyConditionInPolicyRepository
     aggregation)
  3. A flag indicating whether this rule condition is in disjunctive or
     conjunctive normal form
  4. An (optionally ordered) list
forwarded via a single interface. Other options measure  traffic across
a set of actions (defined in either interfaces assigned with the
     PolicyActionInPolicyRule same role or PolicyActionInPolicyRepository
     Aggregation)
  5. A priority value, defining the priority across a whole
device.  The gpMeterScope property of this rule relative the gpsPolicyMeter class is used
to
     other rules in determine which of the same container
  6. options above is selected.Meters are measured
against traffic profile modeled by the qosPolicyPRTrfcProf object.  The attribute named ˘mandatory÷, which
association PolicyTrfcProfileInMeter is used to define whether 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 evaluation of conditions (and qosPolicyPRTrfcProf class. Traffic measured by a meter
can be classified as conforming traffic when the subsequent execution of
     actions if metered rate is below
the conditions evaluate to TRUE) rate defined by the traffic profile, as excess traffic, when the
metered traffic is mandatory or not
  7. A SequencedActions attribute that defines how to execute above the
     actions if normal burst and below the condition Excess burst
size and violating traffic when rate is TRUE
  8. An array above the maximum excess burst.

The [DIFF-MIB] definition of a meter combines the traffic profile and a
meter as one unit. Separation of PolicyRoles attributes, that define the roles or
     role-combinations that are used 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 rule
  9. A RuleUsage attribute, that contains document a description three level traffic
profile is defined. This allows construction of how this
     rule should be used 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 October 2000		   21

The Boolean condition is used to evaluate if May 2001             52

A metered provisioning action using three level traffic profile
specifies the set of actions that should be performed enforced on a network flow by matching excess and
violating traffic using the network flow attributes
against qpExcessAction and qpViolateAction
properties. A three level metered action that does not specify
an excess action implies that the condition. QoS-specific conditions SHOULD excess traffic should be formed from
using
treated as either violating or conforming traffic according to
an algorithm suitable for the qosPolicySimpleCondition class defined in this
document and/or enforcement of the policyTimePeriodCondition class defined in [PCIM]
(or their subclasses, rule. For
example, the final enforcement of course). Note that QoS-specific conditions MAY such a rule may be mixed the use of
a RED like behavior to determine whether traffic is conforming
or violating. A metered action with more generic conditions 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 derived from either associated with the
set of these classes. However, these non-QoS-specific conditions SHOULD be
derived from actions aggregated via the policyCondition class PolicyActionInPolicyRule aggregation
relationship (defined in [PCIM]). The
combination [PCIM]), and are enforced only according to
the state of individual conditions in the meter.
Once an a policy rule action is defined in
[PCIM] enforced, all actions associated to it using
one of the ConditionInPolicyRule class.

Each next action in association should be enforced prior to
other actions associated to the list 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 modeled by an a metered provisioning action derived from the
PolicyAction class. 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 ActionInPolicyRule class defines the order in
which policy of enforcement of the three actions are 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 interpretation 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 policy rule set of DSCPs used to select a PHB in regard a PHB group
according to the state of a given network flow meter. The marker may also be expressed as follows:

  If configured to
allow or not allow remarking of packets. When the rule is enabled and marker changes the Boolean expression
DSCP in a packet, it is evaluated to
  TRUE, then use the Action list said to extract have "re-marked" the prescribed treatment packet.
Provisioning actions can include both DSCP (re)marking as well as
802.1Q, Precedence and CoS marking. Precedence marking is required for this flow.

The rest of this section describes
legacy devices, i.e., devices that do not support the components full DSCP field
(6 bits) in the ToS byte of the policyRule IP packet header for IPv4. CoS marking
is required when crossing a link layer that supports QoS via CoS.

Snir, Ramberg, Strassner, Cohen         expires May 2001             53

The qosPolicyPRAction class and their relationships contains a number of properties that can be
used to control the other classes defined in this
schema.

4.2 QoS Policy Conditions

A policy rule modeled in [PCIM] represents the "If Condition then
Action" semantics associated with behavior of a policy.  A condition is represented
as either an ORed set marker. For example, the values of ANDed conditions
the property qpExcessAction or an ANDed qpViolateAction should be set
to 'remark' in order to model a marker that marks packets according to

a state of ORed
conditions. Individual conditions may either be negated (NOT C) or
not negated (C). 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 by when measuring a policy rule are to be
performed if and only if the policy rule condition evaluates to TRUE.

Many conditions in policy rules, from meter against a networking perspective, can be
modeled as Filters. Filters three level
traffic profile. Please see section 8.3 for more detail.

4.7.1.3  Shapers

Shapers are not modeled directly in either the QPIM used to delay some or all of the PCIM (i.e., no Filter class is defined). However, the filter
concept is central packets in a traffic
stream in order to bring the QoS Policy data model, stream into compliance with a traffic
profile.  A shaper usually has a finite-sized buffer, and packets may
be discarded if there is modeled in not sufficient buffer space to hold the
Network Model
delayed packets.

Again, the qosPolicyPRAction class contains a number of DEN and properties that
can be used in to control the companion QoS Device information
model draft [QOSDEV].

The semantics behavior of an individual condition is not specified in [PCIM].
This document provides semantics for common QoS policy conditions. a shaper. For example, conditions such as: "If the source IP address value
of the flow
belongs property qpExcessAction or qpViolateAction should be set to 10.1.x.x subnet" as well as "If the IP protocol number
'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 flow equals the TCP protocol number" are modeled packets in a traffic
Stream. Usually, this document.

Snir, Ramberg, Strassner, Cohen     expires October 2000		   22

The qosPolicySimpleCondition class models individual conditions. 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 refines contains a number of properties that
can be used to control the basic structure behavior of a shaper. For example, the policyCondition class defined
in [PCIM] by using value
of the triplet <variable>, <operator> and <value> property  qpExcessAction or qpViolateAction should be set
to 'drop' to model a policer that drops packets according to
form the
traffic-profile specified by a condition.

The variable specifies qosPolicyPRTrfcProf class.

Snir, Ramberg, Strassner, Cohen         expires May 2001             54

4.7.1.5 Examples

Below are two examples on how this document models rules specifying
provisioning actions to be enforced on the attribute edge of a flow that differential
service domain.

Example 1:

Traffic flowing from one machine to another should be matched
when evaluating marked with DSCP
X to provide it with the condition. correct per hop behavior. This traffic should
not exceed 1Mb/sec. Each flow should not exceed more than 300Kb/sec. A set of predefined variables that cover
the basic network attribute are introduced
single policy rule can be constructed to foster interoperability.
The list cover layer 3 IP attribute such as IP network addresses,
protocols and ports, as well as a enforce this set of layer 2 attributes and higher
level attributes such as application and user identity. actions.
The variable is matched against a value to produce the Boolean result.
In condition can be built from two simple conditions matching 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 one machine and the value evaluated in destination of the condition.
Operators should model other
machine. A set of three provisioning actions can be used in the 'belong to'
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 'equal' relations in 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

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
examples above. In many cases, traffic. An example of a generic 'match' operator can be used,
and the interpretation policy
with two levels of traffic conditioning is the relation between following:

  Mark packets to DSCP=24 if the variable and value rate is implied 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 value itself. For example, traffic against the variable source IP
address can be matched to an IP address, where first profile. If the 'equal' relation traffic is
implied, to a hostname in which
within this profile, then the 'resolve to' relation traffic is implied,
or to (re)marked with a subnet address in which 'belongs to' relation is implied.

4.2.1 Reusable vs. Ad-Hoc Conditions

This schema enables the reuse DSCP of simple conditions by placing them in a
common portion 24.
If the traffic is out of profile, then the policy information tree (called subsequent action measures
the reusable-
object repository). In order for a simple condition to be a member of
this repository, it must carry a unique name.

A qosPolicySimpleCondition can either directly contain a value and a
variable, or can reference either one or both of them if they are kept
in a reusable-object repository.

Simple condition composition must enforce traffic against the following type
conformance rule: The qpValueTypes property of second higher profile. If the variable must be
compatible with traffic is within
this profile, then the value class name.

The QPIM defines four different ways to compose traffic is (re)marked with a simple condition
through the combination DSCP of representations 25.
Otherwise, the traffic is out of variables profile, and values. The
following combinations it will be dropped.

In this way, an arbitrary cascading of representing traffic conditioners can be
constructed, where each action measures traffic against a simple condition by references higher
traffic profile and containment are possible:

Variable representation

1. The class qosPolicyVariable may change only the out-of-profile action as required.

This policy rule can be contained build in another way using associations to
actions that should be performed on exceeding or violating traffic. In
this way, the
   qosPolicySimpleCondition instance.

2. first action measures traffic according to the first
traffic profile, and reference the second action using
policyExcessNextAction association. The class qosPolicyVariable may be referenced from second action than base its
decision whether to discard or remark traffic according to the
   qosPolicySimpleCondition instance (Reusable variable) higher
traffic profile.

Snir, Ramberg, Strassner, Cohen         expires October 2000		   23

Value representation

1. May 2001             56

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 qosPolicyValue class may 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 contained in allocated to each of the
   qosPolicySimpleCondition class.

2. 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 qosPolicyValue class same rule may also specify that that EF packets needs to
be referenced from the
   qosPolicySimpleCondition instance. This allows reusing the
   qosPolicyValue object, which could be named treated with preemptive forwarding (priority queuing), and considered a named
   constant.

4.2.2. Using Simple Conditions

In most cases, the use of specify
the qosPolicySimpleCondition class is
sufficient maximal bandwidth for this class as well as the definition of a condition for a policyRule. A simple
condition maximal buffer
resources. PHB actions can therefore be added used to a policyRule in two ways:

1. A direct attachment of an instance of both represent the condition
final requirements from PHBs as well as provide enough detail to be
able to map the
   ConditionInPolicyRule instance. In this case, we call this an
   "ad-hoc" simple condition. This method allows the creation of PHB actions into a
   "private" simple condition, meaning that this instance set of the
   condition can't be referenced by any other policy rule, configuration parameters to
configures queues, schedulers, droppers and
   therefore is not reusable. However, since it embeds other mechanism. In
particular, the condition PHB actions includes attributes that are directly in
mapped to the ConditionInPolicyRule instance, it eliminates differential service MIB configuration scheme
[DUFF-MIB].

Description of the
   extra access(es) required to fetch each properties of the condition elements PHB Action that are refernced by pointers.

2. An indirect reference directly
mapped to an instance of a condition that resides the diffserv MIB [DIFF-MIB] are aligned with the
definition in
   a reusable-object repository. This is called a reusable condition.
   This method allows the sharing of conditions by multiple policy
   rules.

4.2.3. Composing Complex Conditions

A complex condition consists MIB. We refer to the MIB for a thorough discussion of groups
these properties and for an explanation of simple conditions (i.e.,
instances why this minimal set of either the policyCondition and/or
parameters where chosen to describe each mechanism.

4.7.2.1 Bandwidth and Delay Management

PHB actions allows specifying the
qosPolicySimpleCondition classes) minimal bandwidth that are combined in should be
reserved for a class of traffic. The property qpMinBandwidth can be
specified either
conjunctive or disjunctive normal form (as defined in [PCIM]).

A complex condition is modeled by the mechanisms supplied Kb/sec or in percentage of the
following PCIM attributes:

  1. total available
bandwidth. The ConditionListType attribute property qpBandwidthValueType is used to determine
whether percentage of the policyRule, which fixed values are used.
The property qpForwardingPriority is a boolean expression type used whenever preemptive
forwarding is required. A policy rule that defines whether the simple
     condition is in conjunctive or disjunctive normal form.
  2. 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 PolicyConditionInPolicyRule aggregation class property qpMaxBandwidth specifies the maximal bandwidth that does three
     things: associates conditions should
be allocated to a particular policy rule, defines
     whether 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 condition is negated or not, per
hop delay and partitions jitter in milliseconds for any given packet within a
traffic class. Enforcement of the
     referenced conditions into one or more groups. For more details,
     please see [PCIM], section 6.3. 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 October 2000	    24

4.3 Simple Condition Operator May 2001             57

4.7.2.2 Congestion Control and Buffer Management

PHB actions provide buffer resources and congestion control
management.
The QoS policy simple condition includes the qpOperator property,
Which specifies the type property qpDropAlgorithm can be used to select either tail-
drop, head-drop or random-drop algorithms. The set of relation between the variable maximal and
minimal threshold values can be specified as well, either in bytes, in
packets or in percentage of the value
evaluated 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 condition. In many cases, 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 generic 'match' operator
can rule
should be used, and queued for forwarding. The qosPolicyQueue class specify the interpretation
queuing properties of the relation between PHB action. Two PHB actions, used within two
different rules may reference the
variable and value is implied same qosPolicyQueue object,
indicating that flows matched by these rules should use the value itself. same
queue. For example, rules specifying PHB actions for AF11 and
AF12 [AF] PHBs should indicate that AF11 and AF12 belong to the
variable source IP address can
same PHB group and should be matched queued together to an IP address, where avoid packet reordering
affects.
This can be achieved by reusing a PHB action within the
'equal' relation is implied, to 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 hostname PHB
action and a qosPolicyQueue.

The qosPolicyQueue class carries all properties described in which the 'resolve to'
relation is implied,
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 subnet address in which 'belongs to'
relation is implied.

The QPIM defines PHB
action with qpFairQueue set to TRUE would be to build a single operator, "match", that models queue
per flow for the most
generic relation: that class of being equal or belonging to.

4.4 QoS Policy Variables 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 Variables are used Information model. Nevertheless, hierarchical policy rules may
require enforcement using more than a single scheduler or queue set.
This is explained in the next section.

Snir, Ramberg, Strassner, Cohen         expires May 2001             58

4.7.2.4 Using Hierarchical policies

The ability to define sub rules within rules allow for definition of
hierarchical policies. Hierarchical policies form a hierarchy of
classification and specification of actions for building individual conditions, as
defined in section 4.2. The variable specifies the attribute each level of the
hierarchy. For example, a flow rule may specify the actions that
should be matched when evaluating performed on all UDP traffic, while its sub rules specify the condition.

Not every combination of a variable
actions that should be performed on various UDP applications. Rules
specified higher in the hierarchy also apply to all sub rules and a value creates a meaningful
condition. 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, a source IP address variable
bandwidth resources can not be matched
against a value that specifies a port number. The QPIM defines 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
variables rules that can specify PHBs enforced within
a Differential Service Domain. In this example the PHBs selected to be used
enforced within the domain are EF, AF11 and AF12 and Best Effort. There
may be alternate ways to model common QoS construct policy conditions, and
assigns appropriate semantics for each. Each type of variable
inherently selects the rules to represent these
PHBs.

The set of value types that it can be matched
against (i.e. a value 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 could be compared and evaluated filter traffic according to
DSCP values. These filters are represented using either a Boolean
expression).

A variable may also limit, reusable or constrain,
ad-hoc policy conditions. The default rule uses a 'catch all' filter
and specifies the Best Effort rules.
The set of values within a
particular value type that can be matched against it rules reside in a condition.
This may gpsPolicyGroup.
The decision strategy is defined to be viewed as a second level of integrity checking. For
example, a variable representing the source-port must limit 'FIRST MATCH'.

The objects below specifies the set of
values that it can assume actions used to the valid range describe each of integers
the PHBs:

QosPolicyPHBAction  BE:
  PolicyQueueInPHBAction association to: Beq
  QpDropAlgorithm: random
  qpDropThresholdValueType packet
  qpDropMinThreshold:  6pckts
  qpDropMaxThreshold:  40pckts

Snir, Ramberg, Strassner, Cohen         expires May 2001             59

QosPolicyPHBAction  AF11:

  PolicyQueueInPHBAction association to: AF1xq

  QpDropAlgorithm: random

  qpDropThresholdValueType packet

  qpDropMinThreshold:  4pckts
  qpDropMaxThreshold:  20pckts

QosPolicyPHBAction  AF12:
  PolicyQueueInPHBAction association to: AF1xq
  QpDropAlgorithm: random
  qpDropThresholdValueType packet
  qpDropMinThreshold:  2pckts
  qpDropMaxThreshold:  10pckts

QosPolicyPHBAction  EF:
  PolicyQueueInPHBAction association to: EFq
  QpDropAlgorithm: drop
  qpDropThresholdValueType packet
  qpDropMaxThreshold:  3pckts

AF11 and AF12 share the same queue, indicating that
correspond they belong to legal source-port values (which is 0-65535). Integers
outside the
same PHB group. Following are the qosPolicyQueue objects defined in
this range can not be matched to 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 variable. Thus, it is not
enough action belong to say that the data type of same
PHB group. The AF1x queue specify the source-port variable is an
integer ű we also need to ensure minimal bandwidth that the value to should be tested is within
a valid range of integers.

The QPIM defines three important attributes that characterize each
allocated to this PHB group. AF11 and AF12 actions indicate the maximal
and minimal thresholds for AF1x packets.

Snir, Ramberg, Strassner, Cohen         expires May 2001             60

qpForwardingPriority property of the variables EF action specify that it defines:

  1. The

preemptive forwarding is required for this PHB. qpMaxBandwidth

property qpVariableName specify that EF should not use more than 50% of the QosPolicyVariable class defines link
bandwidth.

Random Drop is enforced by AF and BE PHBs. EF PHB uses tail drop
as the well-known name used for logical binding of all variables that applications using EF are defined in this document.
  2. supposed to be UDP based and rate
controlled and will not benefit from a random dropper.
The qpValueTypes is the list set of value classes that could be
     matched to minimal and maximal thresholds in this variable.
  3. example are

defined in packets. The qpValueConstraints defines a list of constraint on remaining random drop parameters are not
specified and left for the
     variable (i.e., values enforcer defaults.
QpFairQueue property indicates that the Variable must match).

Snir, Ramberg, Strassner, Cohen     expires October 2000		   25

The combination of these three attributes Best Effort traffic should
provide a consistent and
extensible set of meta-data that define fairness among flows.

4.7.3 Signaling Actions

RSVP is the semantics of variables that
are standard protocol used to form for requesting QoS conditions. For example:

  - resources
>From the network. The qpVariableName QoS policy signaling actions defined in this
document can be used to identify common processing rules
    for a variable having a specific name.
  - The qpValueTypes attribute can be used control whether to ensure that only proper
    classes are used as operators. For example, the source-port
    variable will not include admit or reject an RSVP
request based on the QosPolicyIPv4AddrValue class, since
    source ports have different semantics than IP addresses. However,
    it will include request's attributes and the QosPolicyIntegerValue class name.
  ű specified policy. The qpValueConstraints attribute ensures that variable-specific
    semantics are enforced (e.g., the source-port variable may include
    a constraint reference to a value object defining the integer range
    0..63535).

4.4.1. Variable Binding

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, signaling actions allow modifying the binding logic must result in an identical instantiation.

Each variable defined in content and forwarding
behavior of RSVP requests.

The signaling policies control the QoS policy repository must be bound admission priority of
resources and provide preemption support. Mapping of integrated
services signaled by RSVP to differential services in a
logical entity such core network is
controlled by signaling policies as a specific field in well, by assigning appropriate
DSCPs to flows on the IP header, application
unique identifier or an application-specific parameter.

When boundary of the differential service core.

The set of policies specified allow a policy server attempts (policy
Decision point) to evaluate instruct an expression containing
variables, it must instantiate the variables. To instantiate a
variable, that variable must be bound RSVP node (policy enforcement point) to a specific value (or values,
depending on its type category) and associated with a logical entity.
For example,
Enforce all set of controls defined in the expression 'source-port == 80', COPS protocol specification.
The actions defined here follow the variable
'source-port' must be instantiated to a value and logically associated
with different decision types of the packet header field containing
COPS protocol [COPS] and the source port number, guidelines for the
expression to be evaluated.

If, its use in this example, the variable source-port is bound an RSVP
Environment [COPS-RSVP]. The basic decision to accept or deny a value of
'80', then the expression
reservation is evaluated to TRUE for each packet that the
source port number in modeled by the IP header field equals 80. Otherwise it is
evaluated to FALSE.

4.4.2. Pre-Defined Variables

The purpose of this section qosPolicyRSVPAction class. Additional
control is to explain provided through the need use of two classes. The content and define the
relationship
forwarding behavior of standard, frequently used variables with their logical
entities. Pre-defined variables are necessary for ensuring
interoperability among policy servers 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 management tools from
different vendors. 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 October 2000		   26

For example, different policy servers may have to evaluate the same
policy rule. If each policy server uses May 2001             61

The qosPolicyRSVPAction action includes a common set specification of variables, this
helps to abstract the condition term such that its evaluation

Subset of RSVP flows on which the action should be taken. The following

parameters can be
performed in the same way. 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 QoS Policy information model specifies a set of pre-defined
variables direction refers to support a set the direction of fundamental QoS terms that are commonly
used to form conditions. Examples the flow, hence the
Direction 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 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 same
logical entity by all client systems (typically policy devices).
Similarly, properties
of the pre-defined variable should be stored in reservation request itself as well as on the reusable-
object repository to enable reuse and sharing current
temporal resource allocation.
Meters allow enforcement of policies of the pre-defined
variable.

All standard variable names are case insensitive and do not include
spaces or other non-standard characters form: "Allow
allocation of resource via RSVP for flows coming from subnet x
up to promote ease a total aggregated rate of use. 256kb/sec". The implementers of client systems that map meter tracks
the QPIM current state of resource allocated to subnet x, and
compares any new request for resources against a specific
repository-based implementation MUST provide binding methods to bind
pre-defined variables according to 256Kb/sec
traffic profile. A meter can be reused by two signaling actions
of two rules, indicating that the semantics specified in this
section.

Following is meter should measure the
aggregated resource allocation for both rules.

Note that if a table traffic profile is not provided, it is implicitly
assumed 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 request should be accepted. Rejecting all RSVP
requests matching the flow. Compared to the|
|                 | source IP header field, or condition is specified by a zero valued traffic
profile.

4.7.3.2 Forwarding Behavior

The qosPolicyRSVPInstallAction class provides control on the sender address in  |
|                 | way
resource allocation requests are handles within the RSVP Filter spec object [RSVP].               |
+-----------------+---------------------------------------------------+
| SourcePort      | The source Port of a UDP/TCP flow. Compared to the|
|                 | source port field in node,
without changing the TCP/UDP header, or content of the   |
|                 | sender port in RSVP messages themselves. In
particular it allows instructing the RSVP Filter spec object [RSVP].|
+-----------------+---------------------------------------------------+
| DestinationIP   | The destination IP address of node to:

   1. Set the flow. Compared  |
|                 | to DSCP value of the destination IP header field, or flows for which the session|
|                 | address in reservation
      was made.
   2. Set the RSVP SESSION object [RSVP].        |
+-----------------+---------------------------------------------------+
| DestinationPort | The destination Port preemption priority of a UDP/TCP flow. Compared  |
|                 | to the destination port field in RSVP request.

Setting the TCP/UDP      |
|                 | header, or DSCP of the session port in flow on the RSVP SESSION   |
|                 | object [RSVP].                                    |
+-----------------+---------------------------------------------------+

(Table continued in next page) 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 October 2000		   27

(Table continued from May 2001             62

An RSVP node is responsible for deciding whether to admit flows
or not, based on its available resources. Setting the previous page)

+-----------------+---------------------------------------------------+
|Variable name    |                Logical binding                    |
+-----------------+---------------------------------------------------+
| IPProtocol      | The IP protocol number. Compared 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 protocol  |
|                 | number
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 IP header field or RSVP node to the IP        |
|                 | protocol in proxy RSVP message as if sent by
      the RSVP SESSION end nodes.

Modifying the content of messages can be enforced using a COPS
replacement decision. This class should be extended to cover other
object [RSVP].       |
+-----------------+---------------------------------------------------+
| ToS             | The ToS variable replacements and, in particular, replacement of policy objects.

Triggering errors and warnings is bound important in scenarios when there is
a need to notify the IP header ToS    |
|                 | byte.                                             |
+-----------------+---------------------------------------------------+
| DSCP            | The DSCP variable end nodes that their reservation is bound about to the IP header DSCP  |
|                 | byte or
expire and various other information.

There are scenarios in which it makes sense not to DCLASS carry RSVP object.                    |
+-----------------+---------------------------------------------------+
| DestinationMAC  | The destination MAC address variable is bound requests
end-to-end. An RSVP node on the |
|                 | frame destination MAC address.                    |
+-----------------+---------------------------------------------------+
| SourceMAC       | The source MAC address variable is bound boundary of a differential service core
may map the frame|
|                 | source MAC address.                               |
+-----------------+---------------------------------------------------+
| 8021QID         | The VLAN ID 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 represented in if the 802.1Q field of |
|                 | receiver
has sent it, to complete the header.                                       |
+-----------------+---------------------------------------------------+
| Snap            | The snap protocol variable RSVP cycle.

4.7.3.4 Examples

Below is bound 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 protocol   |
|                 | type carried over SNAP encapsulation.             |
+-----------------+---------------------------------------------------+
| Ethertype       | The ethertype variable is bound be admitted on any single
interface. In this examples two actions are used to represent
the frame      |
|                 | header ethertype value.                           |
+-----------------+---------------------------------------------------+
| Ssap            | required policy.

qosPolicyRSVPAction 1:
  qpRSVPMessageType: Resv
  qpRSVPStyle: FF
  PolicyMeterInAction association to: Meter-1

Snir, Ramberg, Strassner, Cohen         expires May 2001             63

qosPolicyRSVPAction 2:
  qpRSVPMessageType: Resv
  qpRSVPStyle: FF
  PolicyMeterInAction association to: Meter-2

The source sap variable is bound two meters specify the frame header |
|                 | field containing different scopes of each of the source SAP.                  |
+-----------------+---------------------------------------------------+
| Dsap            | meters and a
traffic profile. The destination sap variable is bound the frame   |
|                 | header field containing first traffic profile limits the destination SAP.      |
+-----------------+---------------------------------------------------+
| Application     | The ID of maximal resources
allocated to a single request while the application that generated second traffic profile limits
the flow.|
+-----------------+---------------------------------------------------+
| User            | 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 ID various attributes of RSVP traffic profiles are described in the user that initiated the flow, or is |
|                 | designated as
next section.

4.8. Meters and Traffic Profiles

Meters measure the a temporal state of a flow owner.                     |
+-----------------+---------------------------------------------------+

        Table 2. Pre-defined Variable Names and Their Bindings

The definition or a set of each predefined variable includes flows
against a standard name and
the allowed value types, i.e. traffic profile. In this document meters are modeled
by psPolicyMeter class, while traffic profiles are modeled by
gpsPolicyTrfcProf class. The association PolicyTrfcProfileInMeter
models the variable's qpValueTypes property.

Following is relation between a table of variable names meter and their allowed class types.

Snir, Ramberg, Strassner, Cohen     expires October 2000		   28

+-----------------+---------------------------------------------------+
|Variable name    |                Allowed a traffic profile. Two traffic
profiles are derived from the abstract class types                |
+-----------------+---------------------------------------------------+
| SourceIP        | qosPolicyIPv4AddrValue, qosPolicyIPv6AddrValue    |
+-----------------+---------------------------------------------------+
| SourcePort      | qosPolicyIntegerValue                             |
+-----------------+---------------------------------------------------+
| DestinationIP   | qosPolicyIPv4AddrValue, qosPolicyIPv6AddrValue    |
+-----------------+---------------------------------------------------+
| DestinationPort | qosPolicyIntegerValue                             |
+-----------------+---------------------------------------------------+
| IPProtocol      | qosPolicyIntegerValue                             |
+-----------------+---------------------------------------------------+
| ToS             | qosPolicyIntegerValue, qosPolicyBitStringValue    |
+-----------------+---------------------------------------------------+
| DSCP            | qosPolicyIntegerValue, qosPolicyBitStringValue    |
+-----------------+---------------------------------------------------+
| DestinationMAC  | qosPolicyMACAddrValue                             |
+-----------------+---------------------------------------------------+
| SourceMAC       | qosPolicyMACAddrValue                             |
+-----------------+---------------------------------------------------+
| 8021QID         | qosPolicyIntegerValue, qosPolicyBitStringValue    |
+-----------------+---------------------------------------------------+
| Snap            | qosPolicyIntegerValue                             |
+-----------------+---------------------------------------------------+
| Ethertype       | qosPolicyIntegerValue                             |
+-----------------+---------------------------------------------------+
| Ssap            | qosPolicyIntegerValue                             |
+-----------------+---------------------------------------------------+
| Dsap            | qosPolicyIntegerValue                             |
+-----------------+---------------------------------------------------+
| Application     | qosPolicyDNValue, qosPolicyStringValue,           |
|                 | qosPolicyAttributeValue                           |
+-----------------+---------------------------------------------------+
| User            | qosPolicyDNValue, qosPolicyStringValue,           |
|                 | qosPolicyAttributeValue                           |
+-----------------+---------------------------------------------------+

       Table 3. Allowed Variable Names gpsPolicyTrfcProf.
Provisioning traffic profiles carry rate and Their Default Class Types

Note: For Value type definition, check burst parameters to be
compared with flow meters. RSVP traffic profiles are compared with
RSVPTSPEC and FLOWSPEC parameters, and with meters aggregating the QoS Policy Value section.
temporal state of admitted RSVP reservations and states.

Snir, Ramberg, Strassner, Cohen         expires October 2000		   29

4.5 QoS Policy Value

This abstract class qosPolicyValue is used for defining values May 2001             64

4.8.1. Provisioning traffic profiles

Shaping, policing and
constants used in policy conditions. Different value types are derived
from this class remarking provisioning actions compare a
provisioning traffic profile against a meter. The provisioning traffic
profile is a template containing rate and represent burst values, modeled
by the various attributes required.
Extensions of qosPolicyPRTrfcProf class.

The qosPolicyPRTrfcProf class includes the qosPolicValue class, defined 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 document
provide a list of values for representing rate will always conform. The normal burst size
determines how large traffic bursts can be before some traffic
exceeds the basic network attribute.
Values traffic profile. The Excess Burst size determines how large
traffic bursts can be used to represent constants 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 named values. Named values
could be kept in the
burst size increases. This provides a repository 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 reused by multiple conditions.
Examples of constants include well-known ports, well-known protocol,
server addresses, and other similar concepts.

The counted
as out-of-profile packets.

Snir, Ramberg, Strassner, Cohen         expires May 2001             65

4.8.2.  RSVP traffic profiles

RSVP signaling QoS Policy value classes define 3 types policy can condition the decision whether to accept
or deny an RSVP request based on the traffic specification of basic values: scalars,
ranges and sets. For example, a well-known port number could be defined
using the qosPolicyIntegerValue, defining a single value (80 for HTTP) flow
(TSPEC) or the amount of QoS resources requested (FLOWSPEC). The TSPEC
and FLOWSPEC objects are either compared directly with a range (80-88) traffic
profile, or aggregated to a set (80, 82, 8080). For details, please see meter that measures the temporal admitted
RSVP states and than compared to the traffic specification. The

qosPolicyRSVPTrfcProf class definition for each value type. models such a traffic profile. The QoS policy information model provide
qosPolicyRSVPTrfcProf class has the following classes, all of
them extending the QoSPolicyvalue:

General:
  qosPolicyStringValue
  qosPolicyIntegerValue,
  qosPolicyBitStringValue,
  qosPolicyDNValue,
  qosPolicyAttributeValue.

Layer 3 Network values:
  qosPolicyIPv4AddrValue,
  qosPolicyIPv6AddrValue.

Layer 2 Network values:
  qosPolicyMACAddrValue.

For details, please see the class definition section 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 each value.

4.6. PolicyTimePeriodCondition sessions.

The QoS Policy Information model uses first 5 parameters are the policyTimePeriodCondition
class (defined traffic specification parameters used in [PCIM])
the integrated service architecture. These parameters are used to
define time based QoS policy rules. For
details, please see [PCIM], section 6.5.

4.7. Actions

The QoS Policy schema defines actions to control QoS enforcement in
both the Integrated-Service model a sender TSPEC as well as FLOWSPEC for the Differential Controlled Load
service
model. Two types [CL]. For a definition and full explanation of actions are provided: Signaling their meaning,
please refer to [RSVP-IS]. Parameters 6 and Provisioning
actions.

Snir, Ramberg, Strassner, Cohen     expires October 2000		   30

Signaling actions 7 are the additional
parameters used for specification of the Guaranteed Service FLOWSPEC
[GS]. The last parameter is used to provide policy control on specify the maximum number of
allowed RSVP
requests. Provisioning actions are used sessions. This provides an easy way to directly control limit the data
traffic, regardless number of any out-of-band signaling.
admitted RSVP requests without requiring pre-knowledge of the
aggregated rates requested.

A policy rule may aggregate zero or more policy actions. partial order is defined between TSPECs (and FLOWSPECs). A QoS policy
rule extends this definition to include 0..n provisioning actions TSPEC A is
larger than TSPEC B if and
0..m signaling actions, each defined by an object or objects describing only if rA>rB, pA>pB, bA>bB, mA<mB and
MA>MB. A TSPEC measured against a traffic profile uses the action(s) to perform. Actions are ordered (as opposed to rules,
which are prioritized). The order of actions 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 [PCIM].

The property SequencedActions in the aggregating instance of defines
whether a specified action order is required, recommended, or of no
significance.

Ordering semantics depend on how actions are represented. If actions traffic profile are represented as separate objects, compared.

The GS FLOWSPEC is also compared against the rate R and the slack term
S. R should not be larger than the PolicyActionInPolicyRule
aggregation can traffic profile R parameter, while
the FLOWSPEC slack term should not be used to express an order. In this case, three
attributes are used:

  - ContainingRule, which contains a reference to a policyRule smaller than that
    contains one or more policyActions
  - ContainedAction, which contains an object reference to a
    policyAction contained by one or more policyRules
  - ActionOrder, which specified in
the slack term.

TSPECs as well as FLOWSPECs can be added. The sum of two TSPECs is an unsigned integer 'n' that indicates
computed by summing the
    relative position rate r, the peak rate p, the bucket size b, and
by taking the minimum of an action in min policed unit m and the sequence maximum of actions that the max
packet size M. GS FLOWSPECs are
    associated with a given policy rule.  When 'n' is a positive
    integer, it indicates summed by adding the Resv rate and
minimizing the slack term s. These rules are used to compute a place in meter
that measures the sequence temporal state of actions to be
    performed, admitted RSVP states. The meter is
than compared with smaller integers indicating earlier positions the traffic profile specified in the sequence.  The special value '0' indicates "don't care".  If
    two or more actions have signaling

Snir, Ramberg, Strassner, Cohen         expires May 2001             66

policy using the same non-zero sequence number, they
    may be performed in any order, but they must all 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 performed at applied to groups of policy rules.
Section 5.2 defines two different decision strategies. Section 5.3
provides examples to illustrate how the appropriate place in different decision strategies
affect the overall action sequence.

For actions defined explicitly in a subclass policy rules they operate on.

5.1 Organizing the Application of policyRule, Decision Strategies

This document recommends the
ordering mechanism must following approach to be specified used by policy
servers and other policy decision points in the subclass definition. Note
that QPIM does not define any policyRule subclasses. Instead, the QPIM
defines subclasses network for QoS
applications. The set of policyCondition and policyAction policies to extend the
semantics 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 classes.

Provisioning and signaling actions can gpsPolicyGroup groups
is to be intermixed 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 a the different
QoS policy
rule. Policy consumers (such as PDPs) MAY separate domains.

The goal is to ensure that different policy servers using the actions into
separate lists, but MUST respect same
group of policy rules will enforce consistent behavior. That is, they
will treat the internal order conditions of the specified
actions.

4.7.1 Provisioning Actions

QoS Policy provisioning actions model traffic conditioner elements, as
specified rules in [DIFF-SERV-ARCH]. Actions model meters, markers, shapers the same way, and droppers.

Snir, Ramberg, Strassner, Cohen     expires October 2000		   31

4.7.1.1  Meters

Meters measure execute the temporal properties of
same actions in the stream same order. Therefore, the priority of packets
selected by a classifier against a traffic profile. Meters are modeled
by the QosPolicyMeter class. A meter can policy
rules must be shared between pre-defined and the decision strategy implemented by each
different policy rules. If this server must be defined explicitly.

The decision strategy is desired, then the meter SHOULD reside in a
reusable-object repository. This enables it to defined per domain and can be referenced overridden by all
policy rules
any PolicyDomain or gpsPolicyGroup instances that want to share it.

The property qpMeter is used to hold a reference to are contained within
the domain. When a (reusable) meter
that is kept in policy decision point evaluates a reusable-object repository. The qpMeterScope property
specifies whether the meter should measure flows matching set of rules, it
implements the rule
condition per interface, per device decision strategy defined in each PolicyDomain or per flow. A per flow meter
conceptually creates a new meter
gpsPolicyGroup instance for each flow, measuring each flow
against the profile. A per interface meter measures the aggregate that set of flows matching rules. Nested PolicyDomain or
gpsPolicyGroup instances can override the rule condition forwarded via a single interface.

Meters are measured against traffic profile modeled by decision strategy of the
qosPolicyPRTrfcProf object. The property qpTrfcProf holds a reference
to a traffic profile
PolicyDomain or gpsPolicyGroup instances that resides in a reusable-object repository.

4.7.1.2  Markers

Markers are used to set the DS field contain them.

The order of a packet to a particular DS
codepoint (DSCP), adding decision making for policy rules is based on the marked packet to a particular DS behavior
aggregate. rule
priority of PCIM. However, this rule priority has been extended in two
important ways. The marker may first is that nested rules can be configured to mark all packets steered to
it to a single DSCP, defined. For
nested rules, the contained, or may be configured to mark innermost, rule has a packet 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 one of
be treated in the same way that a
set PolicyRule is. In fact, this is
purposely done so that the priority of DSCPs used to select a PHB in a PHB group, according PolicyRule can be directly
compared to the
state priority of a meter. When the marker changes gpsPolicyGroup. The comparison is done
for all instances at the DSCP same nesting level.
Notice that nested rules are affected in a packet, it the following way from their
containing rules:

Snir, Ramberg, Strassner, Cohen         expires May 2001             67

1. The containing rule's condition list is
said ANDed to have "re-marked" the packet.

Marking is modeled by sub-rule
   condition list.
2. The containing rule actions are added to the property qpSetDSCPValue, which specifies sub-rule action list
   and performed in the
DSCP to set. Remarking out-of-profile packets appropriate order BEFORE the sub-rule actions.

The following example helps clarify rule and sub-rule policy
application. Rule 1.1 is modeled by nested within Rule 1 in the
qpOutofProfileRemarkValue property. 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 property qpOutOfProfileAction
should be set to 'remark' when the remark DSCP value first match decision strategy is used.

4.7.1.3  Shapers

Shapers are used to delay some or all of the packets in defined as a traffic
stream process that
evaluates the policy rules in order to bring the stream into compliance with a traffic
profile.  A shaper usually has defined order, evaluating the
conditions of each rule, until a finite-sized buffer, and packets may
be discarded if there condition is not sufficient buffer space evaluated to hold the
delayed packets.

If TRUE. The
rule's actions are then applied and the value process of the property qpOutOfProfileAction 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 'shape', their defined order of priority and
then this specifies applying the actions of each rule that packets measured by a meter should be shaped
according to satisfies the traffic profile specified by rule's
conditions. This matching strategy may in many cases mean that a qosPolicyPRTrfcProf
object.

Snir, Ramberg, Strassner, Cohen         expires October 2000		   32

4.7.1.4. Droppers

Droppers are used May 2001             68

number of rules may satisfy the same set of conditions, and all of
their actions will be applied.

A Match All strategy may result in applying conflicting rules. Handling
conflicts is outside the scope of this draft. The implementers of QoS
systems must provide proprietary conflict detection and avoidance or
resolution mechanisms to discard some use this or all any type of decision strategy that
allows the packets in execution of more than one rule for a traffic
stream in order given condition.

5.3. Decision Strategy example

This section demonstrates both decision strategies and rule
prioritization. The rules to bring the stream into compliance with a traffic
profile. 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 process is also known as "policing" the stream.

If the value of the property qpOutOfProfileAction is set figure illustrates two extensions to 'drop',
then it specifies PCIM. The first is that packets measured by a meter should be policed
according to
special type of PolicyGroup, the traffic-profile specified by a qosPolicyPRTrfcProf
object.

4.7.1.5 Examples

The following examples will help to show how these classes gpsPolicyGroup, can be used
to perform general provisioning actions.

Example 1: Set up assigned a
priority and have its priority compared to other PolicyRules and
gpsPolicyGroups. The second is rule enforcing QoS provisioning actions:

LetĂs define a policy rule, P, nesting, as follows:

   If (<condition>) THEN, on outgoing traffic,
	mark with <DS Value> AND
      activate a per-flow policer <FLOWP> AND
      activate a per policy rule policer <CLASSP> illustrated by Rule P is represented using 3 qosPolicyPRAction objects:

Object 1:
qpDirection: OUT
qpSetDSCPValue: <DS Value>

Object 2:
qpDirection: OUT
qpMeterScope: flow
qpTrfcProf: <FLOWP> (this is a repository-specific reference to a
            per-flow policer object)
qpOutOfProfileAction: discard

Object 3:
qpDirection: OUT
qpMeterScope: Interface
qpTrfcProf: <CLASSP> (this is a repository-specific reference to a
            per-policyRule policer object)
qpOutOfProfileAction: discard
qpMeter: <Meter>

Snir, Ramberg, Strassner, Cohen     expires October 2000		   33

Example 2: Conditioning traffic

Some PHBs require
and Rule 4.
The order of rule processing for the successive application 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 a set PolicyContainer1 is higher than the priority of traffic
conditioners to properly process
     Rule 3; Rule 1.2 executes next because its priority is higher
     than the traffic. An example priority of Rule1.1)
  3. Rule1.1 (because its container has a policy
with two levels of traffic conditioning higher priority than Rule3
  4. Rule4 (because it is nested in Rule 3)
  5. Rule3

If the following:

  Mark packets to DSCP=24 if decision strategy of the rate domain is within profile x=<64Kb/s>,
  else mark packets with DSCP=25 if rate 'first-match' and it is within profile y=<128kb/s>,
  else drop out-of-profile packets.

This policy rule can be modeled not
overridden by using two actions. The first action
measures the traffic against the first profile. If the traffic is
within this profile, then PolicyContainer1, the traffic is (re)marked with decision process will stop once a DSCP of 24.
rule's condition is matched.

Snir, Ramberg, Strassner, Cohen         expires May 2001             69

If the traffic is out decision strategy of profile, then the subsequent action measures domain is 'match-all' and it is not
overridden by PolicyContainerr1, the traffic against match all decision process will
run over all rules according to the second higher profile. order above.

If the traffic is within
this profile, then the traffic is (re)marked with a DSCP decision strategy of 25.
Otherwise, the traffic domain 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 'first-match' and change only the out-of-profile action as required.

4.7.2 Signaling Action

RSVP
decision process of PolicyContainer1 is the standard protocol used for requesting QoS resources from
the network. The QoS policy signaling actions defined in this document
can match all, Rule1 will be used to control whether to admit or reject an RSVP request based
on
evaluated first. If its condition matches, the request's attributes decision process stops.
Else, both Rules 1.1 and 1.2 will be evaluated (because the specified policy. The QoS policy
signaling actions allow modifying the content and forwarding behavior priority of RSVP requests.

The signaling policies control
the admission named container is higher than the priority of resources Rule 3). However,
since the decision strategy is overridden in the named container, one
or both of Rule 1.1 and
provide preemption support. Mapping Rule 1.2 will be executed if their conditions
match. If one or both of integrated services signaled by
RSVP to differential services these rules in a core network is controlled by
signaling policies as well, by assigning appropriate DSCPs to flows on the boundary of named container
match, 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 process stops. Else Rules 3 and 4 will be evaluated
using 'first-match' decision strategy.

If the decision strategy of controls defined in the COPS protocol specification. The
actions defined here follow domain is 'match-all' and the different decision types
process of PolicyContainer1 is first match, the COPS
protocol [COPS] decision process will
evaluate Rule1 and continue to evaluate both the guidelines for its use in an RSVP environment
[COPS-RSVP]. PolicyContainer1 rules
as well as Rule 3. Rules 1.1 and 1.2 will be evaluated using first
match strategy. The basic decision process continues to evaluate rules 3 and
4 according to accept or deny a reservation is
modeled by the qosPolicyRSVPAction class. Additional control 'match-all' decision strategy.

6. Per Hop Behavior

A per-hop behavior (PHB) is
provided through the use a description of two classes. The content and the externally
observable forwarding behavior of RSVP flows a DS node applied to a particular DS
Behavior aggregate. A PHB is defined selected at a node by the qosPolicyRSVPSignalCtrlAction
class. DSCP contained
in a received packet. A set of PHBs is enforced on a QoS domain.
The qosPolicyRSVPInstallAction class controls the processing set of
RSVP requests PHBs share buffer and accompanying flows within scheduler resources among them.
QPIM provides the RSVP node itself.

Snir, Ramberg, Strassner, Cohen     expires October 2000		   34

QoS signaling policies does not require a policy server for decision
making. A local policy module can use signaling policies means for making
local decisions, as well as if other outsourcing policy protocol beside
COPS is used.

The qosPolicyRSVPAction action defining a set of PHBs per qos
domain by definition of a gpsPolicyGroup that includes a specification set of the subset
PHB rules. Each of RSVP flows this rules would classify packets based on which DSCP
value  and define the action should to be taken. The following
parameters performed on this qos Class.
PHB sets 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 defined as incoming Resv messages.

The basic decision modeled by this class is whether reusable objects in the policy
reusable-object repository to admit or reject allow different domains to share
the RSVP request. same per hop behavior.

Snir, Ramberg, Strassner, Cohen         expires May 2001             70

7. QoS Policy Class Inheritance

The decision can be based on comparison of following diagram illustrates the class hierarchy for the
request TSPEC or FLOWSPEC to a traffic profile and a meter. A meter can
be used to track
QPIM. Relevant classes from the temporal resources allocation of RSVP requests
matching a network condition. Such meters allow enforcement of policies
of PCIM are also included for
completeness:

     top
      |
      +--policy (abstract, [PCIM])
      |   |
      |   +--policyGroup ([PCIM])
      |   |    |
      |   |    +--qosPolicyDomain
      |   |    |
      |   |    +--gpsPolicyGroup
      |   |
      |   +--policyRule ([PCIM])
      |   |
      |   +--policyCondition ([PCIM])
      |   |    |
      |   |    +--policyTimePeriodCondition ([PCIM])
      |   |    |
      |   |    +--vendorPolicyCondition ([PCIM])
      |   |    |
      |   |    +--gpsPolicySimpleCondition
      |   |    |
      |   |    +--gpsPolicyCompoundCondition
      |   |
      |   +--policyAction ([PCIM])
      |   |    |
      |   |    +--vendorPolicyAction ([PCIM])
      |   |    +-- qosPolicyPRAction
      |   |    |
      |   |    +-- qosPolicyPHBAction
      |   |    |
      |   |    +-- qosPolicyRSVPAction
      |   |        |
      |   |        +-- qosPolicyRSVPSignalCtrlAction
      |   |        |
      |   |        +-- qosPolicyRSVPInstallAction
      |   |
      |   +--gpsPolicyVariable
      |   |
      |   +--gpsPolicyValue(abstract)
      |   |   |
      |   |   +--gpsPolicyIPv4AddrValue
      |   |   |
      |   |   +--gpsPolicyIPv6AddrValue
      |   |   |
      |   |   |

 (diagram continued in next page)

Snir, Ramberg, Strassner, Cohen         expires May 2001             71

(continued from the form: "Allow allocation of resource via RSVP 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 flows coming
from subnet x up the QPIM

The reader is encouraged to a total aggregated rate read section 6 and section 7 of 256kb/sec". Use [PCIM] in
their entirety. Section 6 defines all of
meters the object classes listed
above, and meter scope is identical to their use in provisioning
policies. The following properties are used:

   1. Traffic Profile - referencing a traffic profile.
   2. Meter - referencing a meter.

Both traffic profile section 7 defines the concepts of associations and meter specifications can be directly included
within
aggregations.

Snir, Ramberg, Strassner, Cohen         expires May 2001             72

Ten associations and aggregations are defined in the action [PCIM] as well.

Note that if a traffic profile is not provided, it is implicitly
assumed that follows:

  the RSVP request should be accepted. Rejecting all RSVP
requests matching Aggregation PolicyGroupInPolicyGroup
  the condition is specified by a zero valued traffic
profile.

The qosPolicyRSVPInstallAction adds Aggregation PolicyRuleInPolicyGroup
  the following actions:

   1. Set Aggregation PolicyConditionInPolicyRule
  the DSCP value
   2. Set Aggregation PolicyRuleValidityPeriod
  the preemption priority of Aggregation PolicyActionInPolicyRule
  the RSVP request.

Setting Association PolicyConditionInPolicyRepository
  the DSCP of Association PolicyActionInPolicyRepository
  the flow on Weak Aggregation PolicyGroupInSystem
  the edge of a differential service core
allow provisioning of QoS, end-to-end, over mixed integrated Weak Aggregation PolicyRuleInSystem
  the Aggregation PolicyRepositoryInPolicyRepository

QPIM reuses the PCIM associations and aggregations listed above and
defines the following new associations and aggregations in the
following hierarchy:

(the diagram is in the next page)

Snir, Ramberg, Strassner, Cohen         expires May 2001             73

[top]
|
+---PolicyComponent (abstract)
|   |
|   +--- PolicyGroupInPolicyRule
|   |
|   +--- PolicyRuleInPolicyRule
|   |
|   +--- PolicyConditionInPolicyRule ([PCIM])
|   |    |
|   |    +--- PolicyConditionInCompoundCondition
|   |
|   +--- PolicyVariableInPolicySimpleCondition
|   |
|   +--- PolicyValueInPolicySimpleCondition
|
|
+---Dependency (abstract)
|   |
|   +--- PolicyMeterInAction
|   |
|   +--- PolicyValueConstraintsInVariable
|   |
|   +--- PolicyTrfcProfileInMeter
|   |
|   +--- PolicyQueueInPHBAction
|   |
|   +--- PolicyConformNextAction
|   |
|   +--- PolicyExcessNextAction
|   |
|   +--- PolicyViolateNextAction
|   |
|   +--- PolicyInSystem
|   |
|   |    +--- PolicyElementInPolicyRepository

Figure 6. Associations and
differential service clouds. Aggregation for the QPIM

Snir, Ramberg, Strassner, Cohen         expires October 2000		   35

An RSVP node is responsible for deciding whether to admit flows May 2001             74

8. Class Definitions

8.1. The Aggregation "PolicyGroupInPolicyRule"

A policy rule may aggregate one or not,
based on its available resources. Setting the preemption priority
[RSVP_PREEMP] allows more policy groups, via the RSVP node to decide which
PolicyGroupInPolicyRule aggregation. Grouping of its reservations
should be admitted, policy groups and when to make room for
their subclasses into a newer reservation by
preempting an already installed one.

This class should be extended to cover other COPS install decisions if
required.

The qosPolicyRSVPSignalCtrlAction adds the following controls:

   1. Replace/add DCLASS object in RSVP message.
   2. Replace/add Preemption priority object in RSVP message.
   3. Trigger an error/warning RSVP message.
   4. Instruct the RSVP node to proxy RSVP message policy rule is for administrative convenience,
scalability and manageability, as if sent by
      the RSVP end nodes.

Modifying the content of messages can it enables more complex policies to
be enforced using constructed from multiple simpler policies. For example, a COPS
replacement decision. This class should be extended
PolicyRule may aggregate PolicyGroups and gpsPolicyGroups via this
aggregation.

Policy rules do not have to cover other
object replacements and, in particular, replacement of contain policy objects.

Triggering errors and warnings is important in scenarios when there is groups. In addition, a need
policy group may also be used by itself, without belonging to notify a policy
rule and policy rules may be individually aggregated by other policy
rules by the end nodes PolicyRuleInPilicyRule aggregation (section 8.Z.). Note
that their reservation it is about assumed that this aggregation is used to
expire form directed
acyclic graphs and various other information.

There are scenarios NOT ring structures.

The class definition for this aggregation is as follows:

NAME		 PolicyGroupInPolicyRule
DERIVED FROM PolicyComponent (defined in which it makes sense not [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 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 PolicyRule that contains one or
More PolicyGroups. Note that for any single instance of the Path message downstream. Still,
aggregation class PolicyGroupInPolicyRule, this RSVP node property (like all
Reference properties) is single-valued. The [0..n] cardinality
indicates that there may send back an RSVP Resv message as if the receiver
has sent it, to complete the RSVP cycle. be 0, 1 or more PolicyRules that contain any
given PolicyGroup.

8.1.2. The following Reference "PartComponent"

This property is inherited from PolicyComponent, and overridden
to become an example for object reference to a rule enforcing QoS signaling actions:

  Rule S:
    If <condition> THEN, for all WF and SE style Resv messages,
	 accept RSVP request requesting less than <64kb/sec> AND
       make sure PolicyGroup contained by one or
more PolicyRules. Note that the total number for any single instance of admitted active reservations the
aggregation class PolicyGroupInPolicyRule, this property (like all
Reference properties) is restricted to <5>. single-valued. The actions for Rule S are represented using two qosPolicyRSVPAction
objects, as follows:

Object 1:
  qpRSVPDirection: OUT
  qpRSVPMessageType: Resv
  qpRSVPStyle: SE, WF
  qpRSVPTrfcProf : DN {8Kb} (repository reference)
  qpRSVPMeterScope: flow [0..n] cardinality
indicates that a given PolicyRule may contain 0, 1, or more than one
PolicyGroup.

Snir, Ramberg, Strassner, Cohen     expires October 2000		   36

Object 2:
  qpRSVPDirection: OUT
  qpRSVPMessageType: Resv
  qpRSVPStyle: SE, WF
  qpRSVPTrfcProf : {6 session Max} (repository reference)
  qpRSVPMeter: Meter (repository reference)
  qpRSVPMeterScope: interface Strassner, Cohen         expires May 2001             75

8.2. The various attributes Aggregation "PolicyRuleInPolicyRule"

A policy rule may aggregate one or more policy rules, via the
PolicyRuleInPolicyRule aggregation. Grouping of RSVP traffic profiles are described policy rules into a
policy rule, as sub-rules is explained in the
next section.

4.8. Traffic Profiles section XXX. The QoS Policy schema defines two categories of traffic profiles.
Provisioning traffic profiles carry rate and burst parameters ability to be
compared with flow meters. RSVP traffic profiles are compared with RSVP
TSPEC and FLOWSPEC parameters, and with meters aggregating the temporal
state of admitted RSVP reservations
nest policy rules and states.

Traffic profiles can be kept in a repository form sub-rules is important for reusability. Traffic
profiles can also manageability and
scalability, as it enables complex policy rules to be directly attached constructed from
multiple simpler policy rules.

A PolicyRule does not have to actions.

4.8.1. Provisioning traffic profiles

Shaping, policing and remarking provisioning actions compare a
provisioning traffic profile against a meter. The provisioning traffic
profile contain sub-rules. Note that it is a template containing rate
assumed that this aggregation is used to form directed acyclic graphs
and burst values, modeled by the
qosPolicyPRTrfcProf class. NOT ring structures.

The qosPolicyPRTrfcProf class includes the following properties:

   1. Rate measured in bits/sec.
   2. Normal burst measured in bytes.
   3. Excess burst measured in bytes.

Rate determines the long-term average transmission rate. Traffic that
falls under definition for this rate will always conform. 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 normal burst size
determines how large traffic bursts 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 before some traffic exceeds be conceptualized as a sub-
rule of the traffic profile. The Excess Burst size determines how large traffic
bursts containing PolicyRule. This nesting can be before all traffic exceeds done to any
desired level. However, the rate limit. Traffic that
falls between deeper the normal burst size and nesting, the Excess Burst size exceeds more complex the traffic profile with a probability
results of the decisions taken by the nested rules. Note that increases a group
of rules can be aggregated by a policy group(gpsPolicyGroups) and
aggregated as the burst size
increases. This provides a Random Discard mechanism unit by a policy rule (section 8.Z).

Note that for policers,
markers and shapers.

Excess burst size SHOULD any single instance of the aggregation class
PolicyRuleInPolicyRule, this property is single-valued. The [0..n]
cardinality indicates that there may be greater than 0, 1  or equal 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 normal burst
size. If the excess burst size is not specified, it aggregation class
PolicyRuleInPolicyRule, this property is assumed single-valued. The [0..n]
cardinality indicates that
excess burst size a given PolicyRule may contain 0, 1, or more
PolicyRules.

Snir, Ramberg, Strassner, Cohen         expires May 2001             76

8.3. The Aggregation "PolicyConditionInCompoundCondition"

A policy compound condition may aggregate one or more policy
conditions, via the PolicyConditionInCompoundCondition aggregation.
Grouping of policy conditions and their derivatives into a policy
compound condition is equal to 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 normal burst size. In
GroupComponent and PartComponent properties DO have modified semantics,
and so they are described below. The class definition for this case,
burst larger than the normal burst size will always be counted
aggregation is as out-
of-profile packets.

Snir, Ramberg, Strassner, Cohen     expires October 2000		   37

4.8.2.  RSVP traffic profiles

RSVP signaling QoS policy can condition the decision whether 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 accept
or deny
become an RSVP request based on the traffic specification of the flow
(TSPEC) object reference to a gpsPolicyCompoundCondition that
contains one or the amount more PolicyConditions. Note that for any single
instance of QoS resources requested (FLOWSPEC). the aggregation class PolicyConditionInCompoundCondition,
this property is single-valued. The TSPEC
and FLOWSPEC [0..n] cardinality indicates that
there may be 0, 1 or more gpsPolicyCompoundCondition objects are either compared directly with a traffic
profile, that
contain any given policyCondition object, or aggregated its subclasses.

8.3.2. The Reference "PartComponent"

This property is inherited from PolicyComponent, and overridden to
become an object reference to a meter PolicyCondition contained by one
or more gpsPolicyCompoundConditions. Note that measures the temporal admitted
RSVP states and than compared to for any single instance
of the traffic specification. The
qosPolicyRSVPTrfcProf aggregation class models such a traffic profile. PolicyConditionInPolicyRule, this property is
single-valued. 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 [0..n] cardinality indicates that a given
gpsPolicyCompoundCondition may contain 0, 1 or more1  PolicyConditions
(or subclasses of sessions. PolicyCondition).

8.4. The first 5 parameters  aggregation "PolicyVariableInPolicySimpleCondition"

QoS policy simple conditions are represented as the traffic specification parameters used in ordered
triplet {variable, operator, value}. The PolicyElement class is
the integrated service architecture. These parameters are used to
define a sender TSPEC as well as FLOWSPEC common superclass for the Controlled Load
service [CL]. For a definition PolicyVariable and full explanation of their meaning,
please refer to [RSVP-IS]. Parameters 6 PolicyValue classes
and 7 are their subclasses. A gpsPolicySimpleCondition associates exactly

Snir, Ramberg, Strassner, Cohen         expires May 2001             77

one gpsPolicyVariable via the additional
parameters used for specification PolicyVariableInPolicySimpleCondition
aggregattion. This aggregation links a subclass of PolicyElement to the Guaranteed Service FLOWSPEC
[GS].
gpsPolicySimpleCondition in whose scope the PolicyElement subclass is
defined.

The last parameter class definition for this aggregation is used to specify the maximum number of
allowed RSVP sessions. 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 provides property is inherited from PolicyComponent, and overridden to
become an easy way object reference to limit the number of
admitted RSVP requests without requiring pre-knowledge a gpsPolicySimpleCondition that contains
exactly one gpsPolicyVariable. Note that for any single instance of the
aggregated rates requested.

A partial order
aggregation class policyVariableInPolicySimpleCondition, this property
is defined between TSPECs (and FLOWSPECs). A TSPEC A 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
larger than TSPEC B if and only if rA>rB, pA>pB, bA>bB, mA<mB inherited from Dependency, and
MA>MB. A TSPEC measured against overridden to become an
object reference to a traffic profile uses the same
ordering rule. An RSVP message is accepted only if PolicyVariable class (or one of its TSPEC (FLOWSPEC)
is either smaller or equal to the traffic profile. Only parameters
specified in the traffic profile are compared.

The GS FLOWSPEC subclasses)
that is also compared against the rate R and the slack term
S. R should not be larger than defined within the traffic profile R parameter, while scope of a gpsPolicySimpleCondition. Note
that for any single instance of the FLOWSPEC slack term should not be smaller than association class
PolicyVariableInPolicySimpleCondition, this property (like all
reference properties) is single-valued. The [1..1] cardinality
indicates that specified a qpsPolicySimpleCondition must have exactly one
PolicyVariable class (or one of its subclasses) defined within its
scope in
the slack term.

TSPECs as well as FLOWSPECs can order to be added. a meaningful.

8.5. The sum of two TSPECs is
computed by summing  Aggregation "PolicyValueInPolicySimpleCondition"

QoS policy simple conditions are represented as the rate r, ordered triplet
{variable, operator, value}. The PolicyElement class is the peak rate p, common
superclass for the bucket size b, PolicyVariable and
by taking the minimum of min policed unit m PolicyValue classes and their
subclasses. A gpsPolicySimpleCondition associates exactly one
gpsPolicyValue via the maximum PolicyValueInPolicySimpleCondition aggregation.
This aggregation links a subclass of PolicyElement to the max
packet size M. GS FLOWSPECs are summed by adding
gpsPolicySimpleCondition in whose scope the Resv rate PolicyElement subclass is
defined.

Snir, Ramberg, Strassner, Cohen         expires May 2001             78

The class definition for this association is as follows:

NAME		 PolicyValueInPolicySimpleCondition
DERIVED FROM PolicyComponent (defined in [PCIM])
ABSTRACT     False
PROPERTIES 	 GroupComponent[ref gpsPolicySimpleCondition[0..n]]
             PartComponent[ref gpsPolicyValue[1..1]]

8.5.1. The Reference "GroupComponent"

This property is inherited from PolicyComponent, and
minimizing the slack term s. These rules are used overridden to
become an object reference to compute a meter gpsPolicySimpleCondition that measures the temporal state contains
exactly one gpsPolicyValue. Note that for any single instance of admitted RSVP states. the
aggregation class PolicyValueInPolicySimpleCondition, this property is
single-valued. The meter [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
than compared with the traffic profile specified in the signaling
policy using defined within the same rules for comparison scope of TSPECs (FLOWSPECs) to a
traffic profile.

Snir, Ramberg, Strassner, Cohen     expires October 2000		   38

5. Decision strategy gpsPolicySimpleCondition. Note that
for any single instance of the association class
PolicyValueInPolicySimpleCondition, this property (like all reference
properties) is single-valued.  The decision strategy [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 used by a
meaningful.

8.6. The Association "PolicyElementInPolicyRepository"

Policy objects (e.g., policy servers variables, values and other reusable
policy
decision points in the network on objects) can be made reusable. Reusable policy elements are
always related to a set of policies is defined by
grouping policies into various qosNamedPolicyContainer groups, and
using these groups single PolicyRepository via the
PolicyElementInPolicyRepository association.

Policy conditions can use this association to partition behavior in different QoS assign reusable policy
domains.
variables and/or values. Note that either policy variables and/or
values do not have to be reused. In order to get a consistent behavior of different policy
servers using the same group of construct policy rules, the priority
conditions of this form, use the
policy rules must be pre-defined PolicyVariableInPolicySimpleCondition
and the decision strategy implemented
by each different policy server must be defined explicitly. PolicyValueInPolicySimpleCondition weak associations as
appropriate.

The decision strategy class definition for this association is defined per domain and can be overridden per
qosNamedPolicyContainer. When a policy decision point evaluates a set
of rules, it implements the decision strategy defined in each container
of rules. Nested containers can override the decision strategy of their
containers. 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

8.6.1. The order of decision making of nested rules Reference "Antecedent"

This property is defined by the
combination of their internal priority, the priority of the policy rule
containing the nested rule inherited from PolicyInSystem, and the priority of their containers.
Nested rules have overridden to
become an object reference to a higher priority than their PolicyRepository containing rule.
Priority one or more
Policy objects.  A reusable Policy object is compared between rules and qosNamedPolicyContainers, as
Defined in [PCIM]. always related to exactly
one PolicyRepository via the PolicyElementInPolicyRepository
association.  The rule priority of PCIM [0..1] cardinality for this property signifies
whether the Policy object is extended by introducing reusable or not. If it is 0, then the qpPriority (group priority) property of qosNamedPolicyContainer.

Two decision strategies are defined:

  1. "FIRST MATCH"
  2. "MATCH ALL"

5.1. First match

The first match decision strategy
association is defined as not instantiated, which means that this Policy object is
specific to a process single PolicyCondition. If this association is
instantiated, then it means that
evaluates the policy rules in the defined order, evaluating the
conditions of each rule, until a condition Policy object (subclass) is evaluated to TRUE.
reusable, and is located in this specific PolicyRepository.

8.6.2. The
rule's actions are then applied Reference "Dependent"

This property is inherited from PolicyInSystem, and the process 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 decision-making the cardinality), then this Policy object is
terminated.

5.2. Match All

The match all decision strategy embedded
(or attached) directly to the containig object. However, if this
association is defined as first scanning instantiated, then the
complete set of rules according [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 their defined order a gpsPolicyVariable
object, modeling specific value constraints. For example, the
gpsPolicyVariable assignment/binding may be constrained to  a specific
value of priority and IP Address. The constraints then applying are twofold. First, one may
want to constrain the actions set of each rule allowable address values. Second, one may
want to ensure that the flow meets with variable is of the
rule's conditions. correct data type. This matching strategy may in many cases mean
latter is provided by Table 1, which defines the set of value types
that a
number each type of rules may meet PolicyVariable can assume.

The class definition for the flow's parameters and all of their actions
will be applied.

A Match All strategy may result in applying conflicting rules. Handling
conflicts association is outside as follows:

NAME			PolicyValueConstraintsInVariable
DESCRIPTION     	A class representing the scope of this draft. The implementers association of QoS
systems must provide proprietary conflict detection and avoidance or
resolution mechanisms. 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 October 2000		   39

5.3. Decision Strategy example May 2001             80

8.7.1. The Reference "Antecedent"

This section demonstrates both decision strategies property is inherited from Dependency.  Its type is and rule
prioritization. The rules to be evaluated
cardinality are shown in Figure 4 below.

   Domain
     |
     +--Rule1 (priority 19)
     |
     +--NamedContainer1 (priority 5)
     | 	|
     |      +--Rule 1.1 (priority 3)
     |	|
     |      +--Rule 1.2 (priority 33)
     |
     +--Rule3 (priority 4)
	   |
	   +--Rule4 (priority 2)

       Figure 4: Decision Strategy example

NOTE: rule nesting overridden to provide the semantics of a variable
optionally having value constraints. This property itself is not defined in PCIM, but rather an object
reference to a policy variable (gpsPolicyVariable) that is defined in
this document

5.3.1  Default Operation using First Match Everywhere

For simplicity we assume 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 Policy Decision Point needs particular gpsPolicyVariable can have.  The [0..n]
cardinality indicates that a given policy variable may have 0, 1 or
more gpsPolicyValues defined to enforce
all rules described above. Therefore, model the rules will be evaluated in constraints on the following order:

  1. Rule1 (higher priority between Rule1, namedContainer1 and Rule3
  2. Rule1.2 (higher priority between Rule1.1 and Rule1.2)
  3. Rule1.1 (because its container has a higher priority than Rule3
  4. Rule4 (because it is nested in Rule 3)
  5. Rule3

If
values that the decision strategy of 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 domain is first match and it association is not
overridden by NamedContainer1, as follows:

NAME			PolicyMeterInAction
DESCRIPTION     	A class representing the decision process will stop once association between a
rule's condition is matched.

Note: this equates priority with order.
                  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 very different than how
this same example would work using priority inherited from Dependency.  It serves as defined in [PCIM] (in
fact, this could not even an object
reference to either a qosPolicyPRAction or a qosPolicyRSVPAction. The
[0..n] cardinality indicates that a given meter may be represented in [PCIM]). referenced by 0,
or 1 more policy actions.

8.8.2. The Reference "Dependent"

This property is because of
the following two reasons:

- PCIM does not provide the ability inherited from Dependency, and is overridden to assign
become an order object reference to a named
    container. It therefore has no concept of ordering containers among
    its policy rules
  - PCIM has no concept of nested rules 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 October 2000		   40

5.3.2  Operation Using Other Decision Strategies

However, if the decision strategy of May 2001             81

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 domain association between a
                  traffic profile that is match all used for provisioning and it 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
not overridden by NamedContainer1, the match all decision process will
run over all rules according inherited from Dependency.  It serves as an object
reference to the order above.

If the decision strategy of the domain 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 first match inherited from Dependency, and the decision
process of NamedContainer1 is match all, Rule1 will 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 evaluated
first. If its condition matches, 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 decision process stops. Else,
both Rules 1.1 association between a queue
                  and 1.2 will 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 evaluated referenced by 0
or more PHB actions.

Snir, Ramberg, Strassner, Cohen         expires May 2001             82

8.10.2. The Reference "Dependent"

This property is inherited from Dependency, and executed if their
conditions match. If one of NamedContainer1 rule match, overridden to become an
object reference to a qosPolicyQueue defined within the decision
process stops. Else Rules 3 and 4 will scope of a
qosPolicyPHBAction. The [0..n] cardinality indicates that a given PHB
action may be evaluated used by zero or more qosPolicyQueues.

8.11. The Association "PolicyConformNextAction"

This association links an action using first match
decision strategy.

If a meter with an object defining
an action to be applied on the decision strategy of conforming traffic, as defined by the domain
relevant traffic profile.

The class definition for this association is match all and as follows:

NAME			PolicyConformNextAction
DESCRIPTION     	A class representing the decision
process of NamedContainer1 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 first match, inherited from Dependency.  It serves as an object
reference to a qosPolicyPRAction object, which provides scoping for the decision process will
evaluate Rule1 and continue
next action to evaluate NamedContainer1 rules. Rules
1.1 and 1.2 will be evaluated using first match strategy. applied on conforming traffic. This next action is
modeled by a QoSPolicyPRAction object. The decision
process continues [0..1] cardinality means
that a given qosPolicyPRAction may define 0 or 1 qosPolicyPRAction
objects to evaluate rules 3 use as its conforming action.

8.11.2. The Reference "Dependent"

This property is inherited from Dependency, and 4 according overridden to match-all
decision strategy.
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 October 2000		   41

6. Per Hop Behavior

A per-hop behavior (PHB) is May 2001             83

8.12. The Association "PolicyExcessNextAction"

This association links another action using a description of meter with an object
defining an action to be applied on excess traffic, as defined by the externally observable
forwarding behavior of a DS node
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 a particular DS behavior
aggregate. A PHB 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 selected at inherited from Dependency.  It serves as an object
reference to a node by the DSCP in qosPolicyPRAction that provides a received
packet. A set of PHBs is enforced scope for the next
action applied on excess traffic, modeled by a QoS domain. qosPolicyPRAction
object. The set of PHBs
share buffer and scheduler resources among them. [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 QPIM provides
abstract placeholders for PHBs Reference "Dependent"

This property is inherited from Dependency, and for a set of PHBs enforced together
on overridden to
become an object reference to a QoS domain. Further specification of PHBs and PHB sets are outside qosPolicyPRAction that is handling the
excess traffic defined within the scope of this document; please refer 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 [PHBSET] for more
information.

6.1. PHBs

The qosPolicyPHB abstract class models be applied on the violating traffic, as a single PHB. defined by the
relevant traffic profile.

The qosPolicyPHB class includes a single property, the DSCP value, which definition for this association is an integer
with allowed values in as follows:

NAME			PolicyExcessNextAction
DESCRIPTION     	A class representing the range of 0 association between two
                  action objects in order to model action to 63, inclusive. The
qosPolicyPHB name will be defined using the cn property belonging applied
                  on traffic in violation to the Policy class [PCIM].

6.1. PHB Sets an associated traffic
                  profile.
DERIVED FROM     	Dependency
ABSTRACT         	FALSE

Snir, Ramberg, Strassner, Cohen         expires May 2001             84

PROPERTIES  	Antecedent[ref QoSPolicyPRAction[0..1]]
                  Dependent[ref QoSPolicyPRAction [0..1]]

8.13.1. The qosPolicyPHBSet abstract class Reference "Antecedent"

This property is inherited from Dependency.  It serves as an object
reference to a named container qosPolicyPRAction that provides a scope for
instances of qosPolicyPHB classes. It models the set of PHBs enforced
together on a QoS domain. Different PHB sets can next
action to be kept in a
repository. A PHB set enforced applied on the domain is specified violating traffic, modeled by either a
reference from the qosPolicyDomain class to one of the PHB sets
qosPolicyPRAction object. The [0..1] cardinality indicates that
are located in the reusable-object repository, a given
qosPolicyPRAction object may have 0 or by directly including
the PHB set in the domain (the method for doing this is repository-
specific; for example, attachment could be used if the repository 1 qosPolicyPRAction objects
defined to process violating traffic.

8.13.2. The Reference "Dependent"

This property is a
directory).

To fine tune PHB parameters inherited from Dependency, and overridden to further restrict
become an object reference to a qosPolicyPRAction defined within the namespace in
which
scope of another qosPolicyPRAction object. The [0..1] cardinality
indicates that a particular PHB is used, PHB sets can given violating action, modeled as a qosPolicyPRAction
object, may be referenced used by 0 or augment 1 QoSPolicyPRAction objects.

8.14. Class qosPolicyDomain

This class defines the semantics root of qosNamedPolicyContainers. However, in order to
maintain an end-to-end consistent behavior, overriding a single administrative QoS policy
domain, and contains the domain's PHB
set should be done only policy rules and definitions. This
enables the administrator to fine tune partition the parameters set of QoS information into
different domains, where each PHBs, and
not to use domain has a potentially different set of
PHBs altogether.

Markers coloring packets of flows on domain ingress edges should pick a
DSCP selecting one and policies, access rules, decision strategy or other application
of the PHBs enforced on the QoS domain.

Snir, Ramberg, Strassner, Cohen     expires October 2000		   42

7. QoS Policy Class Inheritance policy information organized in some fashion. 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
      |   |    |
      |   |    +--qosNamedPolicyContainer
      |   |
      |   +--policyRule ([PCIM])
      |   |
      |   +--policyCondition ([PCIM])
      |   |    |
      |   |    +--policyTimePeriodCondition ([PCIM])
      |   |    |
      |   |    +--vendorPolicyCondition ([PCIM])
      |   |    |
      |   |    +--qosPolicySimpleCondition
      |   |
      |   +--policyAction
      |   |    |
      |   |    +--vendorPolicyAction ([PCIM])
      |   |    |
      |   |    +-- qosPolicyPRAction
      |   |    |
      |   |    +-- qosPolicyRSVPAction
      |   |    |
      |   |    +-- qosPolicyRSVPSignalCtrlAction
      |   |    |
      |   |    +-- qosPolicyRSVPInstallAction
      |   |
      |   +--qosPolicyVariable
      |   |
      |   +--qosPolicyValue(abstract)
      |   |   |
      |   |   +--qosPolicyIPv4AddrValue
      |   |   |
      |   |   +--qosPolicyIPv6AddrValue
      |   |   |
      |   |   +--qosPolicyMACAddrValue
      |   |   |
      |   |   +--qosPolicyStringValue
      |   |   |
      |   |   +--qosPolicyBitStringValue
      |   |   |

(Diagram continued
definition is as follows:

NAME		  qosPolicyDomain
DERIVED FROM  policyGroup (defined in next page) [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 October 2000		   43

(Diagram continued from previous page)

     top
      |
      +--policy (abstract, [PCIM])
      |   |
      |   +--qosPolicyValue(abstract, continued from previous page)
      |   |   |
      |   |   +--qosPolicyDNValue
      |   |   |
      |   |   +--qosPolicyAttributeValue
      |   |   |
      |   |   +--qosPolicyIntegerValue
      |   |
      |   +-- qosPolicyMeter
      |   |
      |   +-- qosPolicyPRTrfcProf
      |   |
      |   +-- qosPolicyRSVPTrfcProf
      |   |
      |   +-- qosPolicyPHBSet (abstract)
      |   |
      |   +-- qosPHB (abstract)
      |
      +--CIM_ManagedSystemElement (abstract)
         |
         +--CIM_LogicalElement (abstract)
            |
            +--CIM_System (abstract)
               |
               +---CIM_AdminDomain (abstract)
                       |
                       +---PolicyRepository

  Figure 5. Class Inheritance Hierarchy May 2001             85

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 QPIM
administrator (or other entity) that manages the policies.

The reader class definition is encouraged to read section 7 of [PCIM] as follows:

NAME		  gpsPolicyGroup
DERIVED FROM  policyGroup (defined in its entirety,
which [PCIM])
ABSTRACT      False
PROPERTIES	  gpPriority, gpNamedPolicyRuleMatchMethod
		  gpPolicyRoles

8.15.1. The Property gpPriority

This property is a non-negative integer that defines the concepts priority of associations and aggregations. Ten
associations a
named group of rules. Conceptually, it is the priority of the
gpsPolicyGroup, and aggregations are defined in is used to determine when the [PCIM]; note policy rules that the
QPIM does not define any new associations
gpsPolicyGroup contains are evaluated with respect to other policyRules
and gpsPolicyGroups.

If two or aggregations:

  the Aggregation PolicyGroupInPolicyGroup
  the Aggregation PolicyRuleInPolicyGroup
  the Aggregation PolicyConditionInPolicyRule more gpsPolicyGroup objects have the Aggregation PolicyRuleValidityPeriod same priority, this
means that the Aggregation PolicyActionInPolicyRule 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

8.15.2. The Property gpNamedPolicyRuleMatchMethod

This property is an enumerated integer that defines the Association PolicyConditionInPolicyRepository 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 Association PolicyActionInPolicyRepository 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 Weak Aggregation PolicyGroupInSystem
form <RoleName>[&&<RoleName>]* where the Weak Aggregation PolicyRuleInSystem individual role names appear
in alphabetical order (according to the Aggregation PolicyRepositoryInPolicyRepository

Snir, Ramberg, Strassner, Cohen     expires October 2000		   44

8. Class Definitions

8.1. collating sequence for UCS-2).
The property definition is as follows:

NAME             gpPolicyRoles
SYNTAX           string

8.16. Class qosPolicyDomain qosPolicyPRAction

This class defines DiffServ actions to be applied on a flow or group of
flows, including the root marking of a single administrative QoS policy
domain, and contains the domain's policy rules DSCP value, dropping, policing and definitions. This
enables the administrator
shaping.

The association PolicyMeterInAction is used to partition the set of QoS information into
different domains, where each domain has associate a potentially different set of
PHBs and policies, access rules, decision strategy or meter to
qosPolicyPRAction. The associations PolicyConformNextAction,
PolicyExcessNextAction, PolicyViolateNextAction can be used to link
other application
of actions to be enforced on flows that either conform, exceed or
violate the policy information organized in some fashion. associated meter and traffic profile.

The class definition is as follows:

NAME		  qosPolicyDomain		  qosPolicyPRAction
DERIVED FROM  policyGroup  policyAction (defined in [PCIM])
ABSTRACT      False
PROPERTIES    qpDomainName, qpPHBSet, qpPolicyRuleMatchMethod

8.1.1.	  qpDirection, qpMarkvalue, qpMarkValueType,
              qpExcessAction, qpExcessMarkValue, qpViolateAction,
              qpViolateMarkValue

8.16.1. The Property qpDomainName qpDirection

This property provides 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 user-friendly name different
form, as long as its semantics are preserved. For example, a directory

Snir, Ramberg, Strassner, Cohen         expires May 2001             87

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 QoS policy domain.
Its definition 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		qpDomainName		qpMarkValue
SYNTAX	String

8.1.2.	Integer

8.16.3. The Property qpPHBSet qpMarkValueType

This property contains a reference to is an enumerated integer that defines the PHB set defined for type of marking
value used in this
domain. Its definition provisioning action.
The attribute is defined as follows:

NAME		qpPHBSet		qpMarkValueType
SYNTAX	Reference to a PHBSet object

8.1.3.	Integer (ENUM) {DSCP=0, IPP=1. TOS=2. COS=3}

8.16.4. The Property qpPolicyRuleMatchMethod qpExcessAction

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 the action to be
applied to out of
this document for more information on these decision strategies. Its
definition profile, excess traffic, as defined in the qpTrfcProf
referenced traffic profile instance.
The attribute is defined as follows:

NAME		qpPolicyRuleMatchMethod		qpExcessAction
SYNTAX	Integer (ENUM) - {"FIRST MATCH " = 0; "MATCH ALL " =  1 }

Snir, Ramberg, Strassner, Cohen     expires October 2000		   45

8.2. Class qosNamedPolicyContainer {SHAPE=0,DISCARD=1,REMARK=2}

8.16.5. The Property qpExcessMarkValue

This class represents an administratively-defined policy rule
container. All policies that are commonly administered are defined in a
particular qosNamedPolicyContainer. For example, property is an administrator could
define a set of policies that serve a certain goal, or service a
certain type of application, or that handle a certain type of flow or
device. Placing these policies in a qosNamedPolicyContainer integer that
resides in a particular qosPolicyDomain enables defines the administrator to
group different sets of policy rules that perform different types of
operations. It also enables an organization marking value to partition policies
according be
applied to excess out of profile packets if the administrator (or other entity) qpExcessAction action
is defined as REMARK. Notice that manages the
policies. marking type is defined by the
Provisioning action qpMarkValueType property.
The class definition attribute is defined as follows:

NAME		  qosNamedPolicyContainer
DERIVED FROM  policyGroup (defined in [PCIM])
ABSTRACT      False
PROPERTIES	  qpPriority, qpNamedPolicyRuleMatchMethod

8.2.1.		qpExcessMarkValue
SYNTAX	Integer

Snir, Ramberg, Strassner, Cohen         expires May 2001             88

8.16.6. The Property qpPriority qpViolateAction

This property is a non-negative an enumerated integer that defines the priority of a
named group action to be
applied to out of rules. Conceptually, it is profile, violating traffic, as defined in the priority
qpTrfcProf referenced traffic profile instance.
That entry contains values for each of the
qosNamedPolicyContainer, and is used to determine when the policy rules four types of actions that the qosNamedPolicyContainer contains
are evaluated with respect to
other policyRules, policyGroups, and other qosNamedPolicyContainters.

If two or more qosPolicyNamedContainer objects have the same priority, present in this means that the order between these objects is of no importance,
but that they each be evaluated before other objects that have a
numerically lower priority. attribute: shaping, discarding or remarking.
The attribute is defined as follows:

NAME		qpPriority		qpViolateAction
SYNTAX	Integer (must be non-negative)

8.2.2. (ENUM) - {SHAPE=0,DISCARD=1,REMARK=2}

8.16.7. The Property qpNamedPolicyRuleMatchMethod qpViolateMarkValue

This property is an enumerated integer that defines the decision
strategy marking value to be
applied on this set to violating out of QoS policy rules profile packets if the qpViolateAction
action is defined as REMARK. Notice that the marking type is defined
by policy
servers. Please see section 5 of this document for more information on
these decision strategies. the provisioning action qpMarkValueType property.
The attribute is defined as follows:

NAME		qpNamedPolicyRuleMatchMethod		qpViolateMarkValue
SYNTAX	Integer (ENUM) - {"FIRST MATCH " = 0; "MATCH ALL " =  1 }

Snir, Ramberg, Strassner, Cohen     expires October 2000		   46

8.3.

8.17. Class qosPolicyPRAction qosPolicyPHBAction

This class defines DiffServ actions to be applied on a flow or group of
flows, including in order to provide
the marking of a DSCP value, dropping, policing correct Per Hop Behavior across the QoS domain. PHB actions control
the bandwidth and
shaping. 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		  qosPolicyPRAction		  qosPolicyPHBAction
DERIVED FROM  policyAction (defined in [PCIM])
ABSTRACT      False
PROPERTIES	  qpDirection, qpSetDSCPvalue, qpMeter, qpMeterScope,
		  qpTrfcProf, qpOutOfProfileAction,
		  qpOutOfProfileRemarkValue

8.3.1.	  qpPHBDirection, qpDropAlgorithm, pDropTreshholdValueType,
              qpDropMinTreshholdValue, qpDropMaxTreshholdValue,
              qpRandomDropInvWeight, qpRandomDropProbMax, qpPacketSize

8.17.1. The Property qpDirection 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

NAME		qpDirection		qpPHBDirection
SYNTAX	Integer (ENUM) - {IN=0, OUT=1, BOTH=2}

8.3.2.

8.17.2  The Property qpSetDSCPvalue qpDropAlgorithm

This property is an integer (constrained to specifies the range 0-63, inclusive) congestion control drop algorithm that defines the DSCP value
should be used for this type of the (re)mark action. traffic. The attribute is defined as follows:
follows.

NAME		qpSetDSCPvalue		qpDropAlgorithm
SYNTAX	Integer (must be in the range 0-63, inclusive)

8.3.3. {ENUM} - {alwaysDrop=0,  tailDrop=1, headDrop=2,
            randomDrop=3}

8.17.3  The Property qpMeter qpDropTreshholdValueType

This property defines a reference to a qosPolicyMeter object used specifies the units in
this provisioning action. which qpDropMinThresholdValue and
qpDropMaxThresholdValue are measured. The attribute is defined as follows:
follows.

NAME		qpMeter		qpDropThresholdValueType
SYNTAX	Reference to a qosPolicyMeter object

Snir, Ramberg, Strassner, Cohen     expires October 2000		   47

8.3.4.	Integer {ENUM} - {numberOfPackets=0, numberOfBytes=1,
            percentageOfPackets=2, percentageOfBytes=3}

8.17.4  The Property qpMeterScope qpDropMinThreshholdValue

This property is an enumerated integer specifies the minimal number of queuing and buffer
resources that defines whether this
metering action should be applied on a per-flow, per-interface, or per-
device basis. reserved to this class of flows. The attribute is defined threshold
can be specified as follows: 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		qpMeterScope		qpDropMinThresholdValue
SYNTAX	Integer (ENUM) ű {flow=0,interface=1 device=2}

8.3.5.

8.17.5  The Property qpTrfcProf qpDropMaxTreshholdValue

This property contains a reference to an object that defines specifies the
DiffServ provisioning policing instruction value, defined maximal number of queuing and buffer
resources that should be reserved to this class of flows. The threshold
can be specified as a
reference either relative or absolute value according to a qosPolicyPRTrfcProf instance. 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

NAME		qpTrfcProf		qpDropMaxThresholdValue
SYNTAX	Reference to a qosPolicyPRTrfcProf object

8.3.6.	Integer

8.17.6  The Property qpOutOfProfileAction qpRandomDropInvWeight

This property is an enumerated integer that defines specifies the action to be
applied to out random dropper's weighting of profile packets, as defined past history
in affecting the DiffServTrfcProf
entry. That entry contains values for each calculation of the three types current queue average. The moving
average of the queue depth uses the inverse of
actions that are present in this attribute: shaping, discarding, or
remarking. 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		qpOutOfProfileAction		qpRandomDropInvWeight
SYNTAX	Integer (ENUM) - {SHAPE=0,DISCARD=1,REMARK=2}

8.3.7.

8.17.7  The Property qpOutofProfileRemarkValue qpRandomDropProbMax

This property is an integer that defines the DSCP value to be applied
to out of profile packets if specifies the qpOutofProfile action random dropper's worst case random drop
probability, expressed in drops per thousand packets. The attribute is
defined as
REMARK. 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: follows.

NAME		qpOutofProfileRemarkValue		qpPacketSize
SYNTAX	Integer (constrained to the range 0-63, inclusive)

8.4.

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:

Snir, Ramberg, Strassner, Cohen     expires October 2000		   48

NAME		  qosPolicyRSVPAction
DERIVED FROM  policyAction (defined in [PCIM])
ABSTRACT      False
PROPERTIES	  qpRSVPDirection, qpRSVPMessageType, qpRSVPService,
		  qpRSVPStyle, qpRSVPInstallAction, qpRSVPCtrlAction,
		  qpRSVPMeter, qpRSVPMeterScope, qpRSVPTrfcProf

8.4.1.

Snir, Ramberg, Strassner, Cohen         expires May 2001             91

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.4.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.4.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.4.4.

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 October 2000		   49

8.4.5. The Property qpRSVPInstallAction

This property is a reference to a qosPolicyRSVPInstallAction object.
This object is used in conjunction with the RSVP reservation, and
defines detailed control for COPS install decisions (defined in
[COPS]). The attribute is defined as follows:

NAME		qpRSVPInstallAction
SYNTAX	Reference to a qosPolicyRSVPInstallAction object

8.4.6. The Property qpRSVPCtrlAction

This property is a reference to a May 2001             92

8.19. Class qosPolicyRSVPSignalCtrlAction object.

This object is used in conjunction with class extends the RSVP reservation, and
defines 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. The attribute

Since the purpose of this is
defined as follows:

NAME		qpRSVPCtrlAction
SYNTAX	Reference to augment the behavior specified by the
qosPolicyRSVPAction class, this class SHOULD be used with a qosPolicyRSVPSignalCtrlAction object

8.4.7. The Property qpRSVPMeter
qosPolicyRSVPAction object, and SHOULD NOT be used by itself.

This property is a reference class can be extended to a qosPolicyMeter object. This support replacement of additional object is
used
in conjunction with the RSVP reservation, and defines the detailed
definition messages, beyond replacement of the meter characteristics. DCLASS and PREEMPTION object
replacement defined below.

The attribute class definition is defined as follows:

NAME		qpRSVPMeter
SYNTAX	Reference to a qosPolicyMeter object

8.4.8.		  qosPolicyRSVPSignalCtrlAction
DERIVED FROM  qosPolicyRSVPAction
ABSTRACT      False
PROPERTIES	  qpForwardingMode, qpSendError, qpReplaceDSCP,
              qpReplacePreemptionPriority, qpReplaceDefendingPriority

8.19.1. The Property qpRSVPMeterScope qpForwardingMode

This property is an enumerated integer that defines controls the scope forwarding of
RSVP messages. If the
metering action mode is set to be on proxy, RSVP Path messages are not
forwarded and a per-flow, per-interface, or per-device
basis. 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		qpRSVPMeterScope		qpForwardingMode
SYNTAX	Integer (ENUM) ű {flow=0,interface=1 device=2}

Snir, Ramberg, Strassner, Cohen     expires October 2000		   50

8.4.9. - {Forward=0 , Proxy=1}

8.19.2. The Property qpRSVPTrfcProf qpSendError

This property is a reference to a qosPolicyRSVPTrfcProf object, which
defines an IntServ RSVP Traffic profile. Values enumerated integer and controls the generation of RSVP traffic
profiles are compared against Traffic specification (TSPEC)
Resv-Err and QoS
Reservation requests (FLOWSPEC) carried Path-Err messages as defined in RSVP requests. [COPSRSVP]. The attribute
is defined as follows:

NAME		qpRSVPTrfcProf		qpSendError
SYNTAX	Reference to a qosPolicyRSVPTrfcProf object

8.5. Class qosPolicyPRTrfcProf

A provisioning Traffic profile is a class that carries the policer or
shaper rate values to be enforced on a flow or a set of flows. The
class definition is as follows:

NAME		  qosPolicyPRTrfcProf
DERIVED FROM  policy (defined in [PCIM])
ABSTRACT      False
PROPERTIES	  qpPRRate, qpPRNormalBurst, qpPRExcessBurst

8.5.1.	Integer {No=0, Yes=1}

8.19.3. The Property qpPRRate qpReplaceDSCP

This property is a non-negative integer that defines allows the token rate in bits per
second. A rate of zero means that all packets will be out replacement of profile.
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

NAME		qpPRRate		qpReplaceDSCP
SYNTAX	Integer (must be non-negative)

8.5.2. (constrained to the range 0-63, inclusive)

8.19.4. The Property qpPRNormalBurst qpReplacePreemptionPriority

This attribute property is an a non-negative integer that defines the normal size of is used to replace or add
a burst
measured preemption priority object (defined in bytes. [RSVP_PREEMP]) to RSVP
messages. The attribute is defined as follows:

NAME		qpPRNormalBurst		qpReplacePreemptionPriority
SYNTAX	Integer (must be non-negative)

8.5.3.

8.19.5. The Property qpPRExcessBurst qpReplaceDefendingPriority

This attribute property is an a non-negative integer that defines the excess size of is used to replace or add
a burst
measured preemption priority object (defined in bytes. [RSVP_PREEMP]) to RSVP
messages. It specifies the defending priority within the preemption
object. The attribute is defined as follows:

NAME		qpPRExcessBurst		qpReplaceDefendingPriority
SYNTAX	Integer (must be non-negative)

Snir, Ramberg, Strassner, Cohen     expires October 2000		   51

8.6.

8.20. Class qosPolicyRSVPTrfcProf qosPolicyRSVPInstallAction

This class represents 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 IntServ
RSVP Traffic profile. Values of request, to provide a device with information which RSVP
traffic profiles are compared against Traffic specification (TSPEC) and
QoS Reservation requests (FLOWSPEC) carried
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 requests. Traffic
profiles 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 reusable objects or ad-hoc. extended to support additional install decisions that
need to be controlled.

The class definition is as follows:

NAME		  qosPolicyRSVPTrfcProf		  qosPolicyRSVPInstallAction
DERIVED FROM  policy  policyAction (defined in [PCIM])
ABSTRACT      False
PROPERTIES	  qpRSVPTokenRate, qpRSVPPeakRate,
              qpRSVPBucketSize, qpRSVPResvRate, qpRSVPResvSlack,
              qpRSVPSessionNum, qpMinPolicedUnit, qpMaxPktSize

8.6.1. The Property qpRSVPTokenRate

This property is a non-negative integer that defines the token rate
parameter, measured in bits per second. The attribute is defined as
follows:

NAME		qpRSVPTokenRate
SYNTAX	Integer (must be non-negative)

8.6.2. The Property qpRSVPPeakRate

This property is a non-negative integer that defines the peak rate
parameter, measured in bits per second. The attribute is defined as
follows:

NAME		qpRSVPPeakRate
SYNTAX	Integer (must be non-negative)

8.6.3. The Property qpRSVPBucketSize

This property is a non-negative integer that defines the token bucket
size parameter, measured in bits per second. The attribute is defined
as follows:

NAME		qpRSVPBucketSize
SYNTAX	Integer (must be non-negative)	  qpSetDSCPValue, qpSetPreemptionPriority,
		  qpSetDefendingPriority

Snir, Ramberg, Strassner, Cohen         expires October 2000		   52

8.6.4. May 2001             94

8.20.1. The Property qpRSVPResvRate qpSetDSCPValue

This property is a non-negative integer that defines the RSVP rate (R-
Spec) setting of a
DSCP value in the RSVP Guaranteed service reservation. It is measured in
bits per second. The device. In other words, this attribute is defined as follows:

NAME		qpRSVPResvRate
SYNTAX	Integer (must be non-negative)

8.6.5. The Property qpRSVPResvSlack

This property is a non-negative integer that defines controls the RSVP slack
term in
remarking (by the device) of the flow signaled by the RSVP Guaranteed service reservation. It is measured in
microseconds. request. The
attribute is defined as follows:

NAME		qpRSVPResvSlack		qpSetDSCPValue
SYNTAX	Integer (must be non-negative)

8.6.6. (constrained to the range 0-63, inclusive)

8.20.2. The Property qpRSVPSessionNum qpSetDefendingPriority

This property is a non-negative integer that defines integer, and is used to set the total number
defending priority within the preemption object (defined in
[RSVP_PREEMP]) of allowed RSVP sessions that can be active at any given time. RSVP flows. The attribute is defined as follows:

NAME		qpRSVPSessionNum		qpSetDefendingPriority
SYNTAX	Integer (must be non-negative)

8.6.7.

8.20.3. The Property qpMinPolicedUnit qpSetPreemptionPriority

This property is a non-negative integer that defines integer, and is used to set the minimum
preemption priority [RSVP_PREEMP] of RSVP
policed unit, measure in bytes. flows. The attribute is
defined as follows:

NAME		qpMinPolicedUnit		qpSetPreemptionPriority
SYNTAX	Integer (must be non-negative)

8.6.8.

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

8.22.1. The Property qpMaxPktSize qpPRRate

This property is a non-negative integer that defines the maximum
allowed packet size for RSVP messages, measure token rate in bytes. kilo bits
per second. A rate of zero means that all packets will be out of
profile. The attribute is defined as follows:

NAME		qpMaxPktSize		qpPRRate
SYNTAX	Integer (must be non-negative)

Snir, Ramberg, Strassner, Cohen     expires October 2000		   53

8.7. Class qosPolicyRSVPSignalCtrlAction

This class extends the functionality of the qosPolicyRSVPAction class
by adding detailed control on the signaling protocol behavior itself.

8.22.2. The information carried in RSVP messages can be modified using this
action, as well as the RSVP forwarding behavior.

Since the purpose of this Property qpPRNormalBurst

This attribute is to augment the behavior specified by an integer that defines 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. normal size of a burst
measured in bytes. The class definition attribute is defined as follows:

NAME		  qosPolicyRSVPSignalCtrlAction
DERIVED FROM  policyAction (defined in [PCIM])
ABSTRACT      False
PROPERTIES	  qpForwardingMode, qpSendError, qpReplaceDSCP,
              qpReplacePreemptionPriority, qpReplaceDefendingPriority

8.7.1.		qpPRNormalBurst
SYNTAX	Integer (must be non-negative)

8.22.3. The Property qpForwardingMode qpPRExcessBurst

This property attribute is an enumerated integer that controls defines the forwarding excess size 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. burst
measured in bytes.  The attribute is defined as follows:
NAME		qpForwardingMode		qpPRExcessBurst
SYNTAX	Integer (ENUM) - {Forward=0 , Proxy=1}

8.7.2. (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 qpSendError qpRSVPTokenRate

This property is an enumerated a non-negative integer and controls that defines the generation of
Resv-Err and Path-Err messages as defined token rate
parameter, measured in [COPSRSVP]. kilo bits per second. The attribute is defined
as follows:

NAME		qpSendError		qpRSVPTokenRate
SYNTAX	Integer {No=0, Yes=1} (must be non-negative)

Snir, Ramberg, Strassner, Cohen         expires October 2000		   54

8.7.3. May 2001             96

8.23.2. The Property qpReplaceDSCP qpRSVPPeakRate

This property is a non-negative integer that allows defines the replacement of
a DCLASS object carrying a DSCP value peak rate
parameter, measured in an RSVP message. kilo bits per second. The attribute
specifies the DSCP value to be replaces, and is defined
as follows:

NAME		qpReplaceDSCP		qpRSVPPeakRate
SYNTAX	Integer (constrained to the range 0-63, inclusive)

8.7.4. (must be non-negative)

8.23.3. The Property qpReplacePreemptionPriority qpRSVPBucketSize

This property is a non-negative integer that is used to replace or add
a preemption priority object (defined defines the token bucket
size parameter, measured in [RSVP_PREEMP]) to RSVP
messages. bytes. The attribute is defined as follows:

NAME		qpReplacePreemptionPriority		qpRSVPBucketSize
SYNTAX	Integer (must be non-negative)

8.7.5.

8.23.4. The Property qpReplaceDefendingPriority qpRSVPResvRate

This property is a non-negative integer that is used to replace or add
a preemption priority object (defined defines the RSVP rate (R-
Spec) in [RSVP_PREEMP]) to the RSVP
messages. Guaranteed service reservation. It specifies the defending priority within the preemption
object. is measured in
Kilo bits per second. The attribute is defined as follows:

NAME		qpReplaceDefendingPriority		qpRSVPResvRate
SYNTAX	Integer (must be non-negative)

8.8. Class qosPolicyRSVPInstallAction

This class extends the functionality of the qosPolicyRSVPAction class
by adding detailed control for COPS Install decisions (defined in
[COPS]).

8.23.5. The Property qpRSVPResvSlack

This action allows assigning a preemption priority with an
RSVP request, to provide property is a device with information which non-negative integer that defines the RSVP requests
to accept slack
term 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 Guaranteed service reservation. It 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. measured in
microseconds. The class definition attribute is defined as follows:

Snir, Ramberg, Strassner, Cohen     expires October 2000		   55

NAME		  qosPolicyRSVPInstallAction
DERIVED FROM  policyAction (defined in [PCIM])
ABSTRACT      False
PROPERTIES	  qpSetDSCPValue, qpSetPreemptionPriority,
		  qpSetDefendingPriority

8.8.1.		qpRSVPResvSlack
SYNTAX	Integer (must be non-negative)

8.23.6. The Property qpSetDSCPValue qpRSVPSessionNum

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) total number
of the flow signaled by the allowed RSVP request. sessions that can be active at any given time. The
attribute is defined as follows:

NAME		qpSetDSCPValue		qpRSVPSessionNum
SYNTAX	Integer (constrained to the range 0-63, inclusive)

8.8.2. (must be non-negative)

Snir, Ramberg, Strassner, Cohen         expires May 2001             97

8.23.7. The Property qpSetDefendingPriority qpMinPolicedUnit

This property is a non-negative integer, and is used to set the
defending priority within integer that defines the preemption object (defined in
[RSVP_PREEMP]) of minimum RSVP flows.
policed unit, measure in bytes. The attribute is defined as follows:

NAME		qpSetDefendingPriority		qpMinPolicedUnit
SYNTAX	Integer (must be non-negative)

8.8.3.

8.23.8. The Property qpSetPreemptionPriority qpMaxPktSize

This property is a non-negative integer, and is used to set integer that defines the
preemption priority [RSVP_PREEMP] of maximum
allowed packet size for RSVP flows. messages, measure in bytes. The attribute
is defined as follows:

NAME		qpSetPreemptionPriority		qpMaxPktSize
SYNTAX	Integer (must be non-negative)

8.9.

8.24. Class qosPolicySimpleCondition (Aux) 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 qosPolicySimpleCondition gpsPolicySimpleCondition class is derived from the
policyCondition
PolicyCondition class in [PCIM]. Simple conditions can be kept in
repositories for reuse.

Snir, Ramberg, Strassner, Cohen     expires October 2000		   56

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		  qosPolicySimpleCondition		  gpsPolicySimpleCondition
DERIVED FROM  policyCondition  PolicyCondition (defined in [PCIM])
ABSTRACT      False
PROPERTIES	  qpOperator, qpVariableAtom, qpValueAtom

8.9.1.	  gpOperator

Snir, Ramberg, Strassner, Cohen         expires May 2001             98

8.24.1. The Property qpOperator gpOperator

This property is a string an enumerated integer that defines the relation
between a variable
and a value. The default value is ˘match÷, 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		   qpOperator		   gpOperator
SYNTAX	   String	   Integer - ENUM {0=Match}
DEFAULT VALUE  'match'

8.9.2.

8.25. Class gpsPolicyCompoundCondition

The Property qpVariableAtom

This property gpsPolicyCompoundCondition class is a reference to an object that defines the variable used to represent a Boolean
expression consisting of a set of policyConditions. As such, it can be
used in a QoS policy condition. to define traffic filters. The referenced object SHOULD be gpsPolicyCompoundCondition class is
linked to either a
subclass of PolicyRule or a PolicyRepository using the qosPolicyVariable class.
PolicyConditionInPolicyRule and PolicyConditionInPolicyRepository
associations, respectively. Compound conditions are constructed using
the PolicyConditionInCompoundCondition association. The attribute class
definition is defined as follows:

NAME		qpVariableAtom
SYNTAX	Reference to an object that is a subclass of the
            qosPolicyVariable class

8.9.3.		   gpsPolicyCompoundCondition
DERIVED FROM   PolicyCondition (defined in [PCIM])
ABSTRACT       False
PROPERTIES     gpPolicyConditionListType

8.25.1. The Property qpValueAtom

This property is a reference to an object that defines qpPolicyeConditionListType

The qpPolicyRuleConditionListType indicates whether the value to be
used in a QoS list of policy condition.
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 referenced object SHOULD attribute qpPolicyRuleConditionListType is defined to be a
subclass of identical
as the qosPolicyValue class. policyRuleConditionListType property of PolicyRule PCIM. The
attribute is defined as follows:

NAME		qpValueAtom 'policyConditionListType'
SYNTAX	Reference to an object that is a subclass of the
            qosPolicyValue class

8.10. INTEGER (ENUM) - {1=DNF, 2=CNF}
DEFAULT VALUE: 1 (DNF)

Snir, Ramberg, Strassner, Cohen         expires May 2001             99

8.26. Class qosPolicyVariable 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. A 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.

Snir, Ramberg, Strassner, Cohen     expires October 2000		   57
A variable also limits 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 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
16 bits port entity. 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		  qosPolicyVariable		  gpsPolicyVariable
DERIVED FROM  policy (defined in [PCIM])
ABSTRACT      False
PROPERTIES	  qpVariableName, qpValueTypes, qpVariableDescription,
		  QpValueConstraints

8.10.1.	  gpVariableName, gpValueTypes, gpVariableDescription,

8.26.1. The Property qpVariableName gpVariableName

This property is a string that is 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		qpVariableName		gpVariableName
SYNTAX	String, whose values are defined in the following table:

8.10.2 table 2

8.26.2   The Property qpValueTypes 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 allows efficient retrieval enables an application to search for a specific set of
class names, as well as ensure that the possible set data type of
relevant values from a repository, and 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		qpValueTypes		gpValueTypes
SYNTAX	String

8.10.3.

Snir, Ramberg, Strassner, Cohen         expires May 2001            100

8.26.2.  The Property qpVariableDescription gpVariableDescription

This property is a string that provides a textual description of the
variable. The attribute is defined as follows:

NAME		qpVariableDescription		gpVariableDescription
SYNTAX	String

Snir, Ramberg, Strassner, Cohen     expires October 2000		   58

8.10.4. The Property qpValueConstraints

This property is a set of references to objects serving as constraints
for this variable. This attribute is defined as follows:

NAME		qpValueConstraints
SYNTAX	Set of references to objects that constrain this variable

8.11.

8.27. Class qosPolicyValue 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		  qosPolicyValue		  gpsPolicyValue
DERIVED FROM  policy (defined in [PCIM])
ABSTRACT	  True
PROPERTIES

8.12.

8.28. Class qosPolicyIPv4AddrValue gpsPolicyIPv4AddrValue

This class is used to provide a list of IPv4Addresses, hostnames and
address range values. values to be matched against in a policy condition. The
class definition is as follows:

NAME		  qosPolicyIPv4AddrValue		  gpsPolicyIPv4AddrValue
DERIVED FROM  qosPolicyValue  gpsPolicyValue
ABSTRACT      False
PROPERTIES	  qpIPv4AddrList

8.12.1.	  gpIPv4AddrList

8.28.1. The Property qpIPv4AddrList gpIPv4AddrList

This Property provides an unordered list of strings, each specifying a
single IPv4 address, a hostname, or a range of IPv4 addresses. The addresses,
according to the ABNF definition [ABNF] of an IPv4 address is: 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])

Each

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
  2. A single Hostname. Hostname format follows the guidelines and
     restrictions specified in [NAMES].
     Example: www.bigcompany.com

Snir, Ramberg, Strassner, Cohen     expires October 2000		   59

  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		qpIPv4AddrList		gpIPv4AddrList
SYNTAX	String
FORMAT       IPv4address | hostname | IPv4addressrange |
             IPv4maskedaddress | IPv4prefix

8.13.

8.29. Class qosPolicyIPv6AddrValue gpsPolicyIPv6AddrValue

This class is used to define a list of IPv6 addresses, hostnames, and
address range values. The class definition is as follows:

NAME		  qosPolicyIPv6AddrValue		  gpsPolicyIPv6AddrValue
DERIVED FROM  qosPolicyValue  gpsPolicyValue
ABSTRACT      False
PROPERTIES	  qpIPv6AddrList

8.13.1.	  gpIPv6AddrList

8.29.1. The Property qpIPv6AddrList 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
      IPv6maskedaddress = IPv6address","IPv6address
      Hostname (as defines in [NAMES])

Snir, Ramberg, Strassner, Cohen         expires October 2000		   60 May 2001            102
      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		qpIPv6AddrList		gpIPv6AddrList
SYNTAX	String
FORMAT      IPv6address | hostname | IPv6addressrange |
            IPv6maskedaddress | IPv6prefix

8.14.

8.30. Class qosPolicyMACAddrValue gpsPolicyMACAddrValue

This class is used to define a list of MAC addresses and MAC address
range values. The class definition is as follows:

NAME		  qosPolicyMACAddrValue		  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

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  qosPolicyValue  gpsPolicyValue
ABSTRACT      False
PROPERTIES    qpMACAddrList

8.14.1.	  gpBitStringList

8.32.1. The Property qpMACAddrList gpBitStringList

This property provides an unordered list of strings, each specifying representing
a
MAC address single bit string or a range set of MAC addresses. bit strings. The 802 MAC address canonical
format is used. 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 ABNF formal
definition [ABNF] of a bit string is:

      MACaddress

Snir, Ramberg, Strassner, Cohen         expires May 2001            104
      binary-digit = 1*4HEXDIG ":" 1*4HEXDIG ":" 1*4HEXDIG
      MACmaskedaddress "0" / "1"
      bitstring = MACaddress","MACaddress 1*binary-digit
      maskedBitString = bitstring","bitstring

Each string entry is either:

  1. A single MAC address. bit string. Example: 0000:00A5:0000 00111010
  2. A MACmaskedaddress address range defined specified by an address 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 relevant significant bits
     in the address.
     Example: 0000:00A5:0000, FFFF:FFFF:0000 defines a range of MAC
     addresses in which bit string value. For example, 110110, 100110 and 110111
     would match the first 4 8-bit bytes are equal to 0000:00A5. maskedBitString 100110,101110 but 100100 would
     not.

NAME		qpMACAddrList		gpBitStringList
SYNTAX	String
FORMAT      MACaddress      bitString | MACmaskedaddress

Snir, Ramberg, Strassner, Cohen     expires October 2000		   61

8.15. maskedBitString

8.33. Class qosPolicyStringValue gpsPolicyDNValue

This class is used to represent a single or set of string values. Each
can have 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		  qosPolicyStringValue		  gpsPolicyDNValue
DERIVED FROM  qosPolicyValue  gpsPolicyValue
ABSTRACT      False
PROPERTIES	  qpStringList

8.15.1.	  qpDNList

8.33.1. The Property qpStringList qpDNList

This property attribute provides an unordered list of strings, each representing
a single string Distinguished Name (DN) with wildcards. The format of a DN is defined
in [DNDEF]. The asterisk character "*" ("*") is used as wildcard for either
a
wildcard, and represents single attribute value or a wildcard for an arbitrary sub-string replacement. RDN. The order of RDNs is
significant. For
example, example: A qpDNList attribute carrying the value "abc*def" match "abcxyzdef", following
value: "OU=Sales, CN=*, O=Widget Inc., *, C=US"
matches: "OU=Sales, CN=J. Smith, O=Widget Inc, C=US" and the value
"abc*def*" match "abcxxxdefyyyzzz". also matches:
"OU=Sales, CN=J. Smith, O=Widget Inc, C=US, CN=CA".

The syntax definition attribute is identical
to the substring assertion syntax defined in [LDAP_ATTR]. If the
asterisk character is required as part follows:

Snir, Ramberg, Strassner, Cohen         expires May 2001            105

NAME		qpDNList
SYNTAX	List of the string 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 itself, it
MUST can be quoted used in conjunction with reference values
carried in RSVP objects, as described specified in section 4.3 of [LDAP_ATTR]. [IDENT]. The attribute definition property name is
used to specify which of the properties in the object is being used as follows:

NAME			qpStringList
SYNTAX		String

8.16 Class qosPolicyBitStringValue

This class
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 represent a single or set of bit string values. 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		  qosPolicyBitStringValue		  gpsPolicyAttributeValue
DERIVED FROM  qosPolicyValue  gpsPolicyValue
ABSTRACT      False
PROPERTIES	  qpBitStringList

8.16.1.	  gpAttributeName, gpAttributeValueList

8.34.1. The Property qpBitStringList gpAttributeName

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 attribute defines the number of bits name 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, property that the bit string list of values
should be matched
against the variable most significant bit string. compared against. The formal
definitions are:

      binary-digit = "0" / "1"
      bitstring = 1*binary-digit
      maskedBitString = bitstring","bitstring

Snir, Ramberg, Strassner, Cohen     expires October 2000		   62

Each string entry attribute 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. defined as follows:

NAME		qpBitStringList		gpAttributeName
SYNTAX	String
FORMAT      bitString | maskedBitString

8.17. Class qosPolicyDNValue

8.34.2. The Property gpAttributeValueList

This class attribute contains a list of property values. Each value is used
compared to represent a single or set value of Distinguished Name
values, including wildcards. A Distinguished Name the property specified by gpAttributeName. The
attribute is a name that can be
used defined as a key to retrieve an object. follows:

NAME		gpAttributeValueList
SYNTAX	String

Snir, Ramberg, Strassner, Cohen         expires May 2001            106

8.35. Class gpsPolicyIntegerValue

This value class provides a list of integer and integer range values.
Integers of arbitrary sizes can be used in
comparison to reference represented. For a given variable,
the set of possible ranges of integer values carried in RSVP policy objects, as allowed is specified in [IDENT]. via
the variable's gpValueConstraints Property. The class definition is as
follows:

NAME		  qosPolicyDNValue		  gpsPolicyIntegerValue
DERIVED FROM  qosPolicyValue  gpsPolicyValue
ABSTRACT      False
PROPERTIES	  qpDNList

8.17.1.	  gpIntegerList

8.35.1. The Property qpDNList gpIntegerList

This property provides an unordered list of Distinguished Name
references to objects. integers and integer range
values. The attribute is defined as follows:

NAME		qpDNList
SYNTAX	List format of Distinguished Names, each this property can take on of which serves as a
            reference to another object.

8.18. Class qosPolicyAttributeValue

This class the following forms:

  1. An integer value.
  2. A range of integers. The range is used to represent specifies by a single or set of property values in start integer and
     an object. This value can be used in conjunction with reference values
carried in RSVP objects, as specified in [IDENT]. end integer separated by "-". The property name is
used to specify which of the properties in range includes all integers
     between start and end integers, including the object start and end
     integers.

To represent a range of integers that is being not bounded, the reserved word
INFINITY can be used as the condition. end range integer.

The value of this property will then be retrieved, 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 a less-than-or-equal-to can be expressed. This enables the
match (which is dependent on condition semantics of the gpOperator property name) will be used of the
gpsPolicySimpleCondition class to see if be kept simple (i.e., just the condition value
"match"). The attribute is satisfied or not. defined as follows.

NAME		gpIntegerList
SYNTAX	String
FORMAT      integer | integerrange

Snir, Ramberg, Strassner, Cohen         expires October 2000		   63

For example, suppose a User May 2001            107

8.36 Class gpsPolicyMeter

This class has models a multi-valued Property called
'member-of' that lists meter. Within provisioning actions, meters measure
the names temporal properties of groups that this user belongs to.
Suppose this property uses caseIgnoreMatch matching. 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 simple condition
can be constructed traffic profile is associated to match a meter using the reference carried in an RSVP Identity
PolicyTrfcProfileInMeter association.
A meter can be shared between different policy object to rules. A meter shared by
more than one policy rule resides in a qosPolicyAttributeValue repository and is referenced by
all sharing rules. A meter is associated with an action using the following
characteristics:
  qpAttributeName="member-of",
  qpAttributeValueList = "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.
PolicyMeterInAction association.

The class definition is defined as follows:

NAME		  qosPolicyAttributeValue		  gpsPolicyMeter
DERIVED FROM  qosPolicyValue  policy (defined in [PCIM])
ABSTRACT      False      True
PROPERTIES	  qpAttributeName, qpAttributeValueList

8.18.1.    gpMeterScope, gpMeterTimeInterval

8.36.1. The Property qpAttributeName gpMeterScope

This attribute defines the name of the property is an enumerated integer that the list of values defines whether this
metering action should be compared against. 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		qpAttributeName		gpMeterScope
SYNTAX	String

8.18.2.	Integer (ENUM) {flow=0,interface=1 role-in-device=2,
            device=3, role=4}

8.36.2. The Property qpAttributeValueList gpMeterTimeInterval

This attribute contains a list of optional property values. Each value is
compared to a value of specifies the property specified by qpAttributeName. time interval used to measure
traffic in microseconds. The attribute is defined as follows:

NAME		qpAttributeValueList		gpMeterTimeInterval
SYNTAX	String

8.19. Class qosPolicyIntegerValue

This class provides a list of integer and integer range values.
Integers of arbitrary sizes can be represented. For	Integer

Snir, Ramberg, Strassner, Cohen         expires May 2001            108

8.37 Class qosPolicyQueue

This class models a given variable,
the sharable queue used by more than one policy rule.
A set of possible ranges of integer values allowed is specified via actions defining PHBs may be associated to the variable's qpValueConstraints Property. 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 definition is defined as follows:

NAME		  qosPolicyIntegerValue		  qosPolicyQueue
DERIVED FROM  qosPolicyValue  policy (defined in [PCIM])
ABSTRACT      False      True
PROPERTIES	  qpIntegerList

Snir, Ramberg, Strassner, Cohen     expires October 2000		   64

8.19.1.    qpForwardingPriority, qpBandwidthValueType,
              qpMinBandwidth, qpMaxBandwidth, qpMaxDelay, qpMaxJitter,
              qpFairQueue

8.37.1. The Property qpIntegerList qpForwardingPriority

This property provides an unordered list of integers and integer range
values. The format of defines the forwarding priority that should be given to
this property can take on set of the following forms:

  1. An integer value.
  2. flows. 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 non zero value indicate that is not bounded, the reserved word
INFINITY can preemptive forwarding
should be used as provided to the end range integer. class of traffic. Higher values represent
higher forwarding priority. 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. attribute is defined as follows.

NAME		qpIntegerList		qpForwardingPriority
SYNTAX	String
FORMAT      integer | integerrange

8.20. Class qosPolicyPHBSet	Integer

8.37.2. The qosPolicyPHBSet is a class that serves as a named container for
qosPolicyPHB objects. A single PHB set is associated with a QoS domain
using the domain Property qpBandwidthValueType

This property defines in what units the properties qpMinBandwidth and
qpMaxBandwidth are defined. Bandwidth can either be defined in the qosPolicyDomain object.
Instances bits/sec
or in percentage of the qosNamedPolicyContainer class can override the
domain's PHB set by referencing another PHB set via the qosPolicyPHBSet
Property available bandwidth or by aggregation of a qosPolicyPHBSet object. scheduler resources. The class
attribute is defined as follows: follows.

NAME		  qosPolicyPHBSet
DERIVED FROM  policy (defined in [PCIM])
ABSTRACT        False
PROPERTIES

8.21. Class qosPolicyPHB		qpBandwidthValueType
SYNTAX	Integer {ENUM} - {bits/sec=0, percentage=1}

8.37.3. The qosPolicyPHB Class is an abstract class that extends Property qpMinBandwidth

This property defines the policy minimal bandwidth that should be reserved to
this class (defined in the [PCIM]) with the information required of traffic. Both relative and absolute values can be
specified according to model
a PHB service class. the value qpBandwidthValueType property. The PHB service class
attribute is an abstraction over
device-specific parameters. defined as follows.

NAME		qpMinBandwidth
SYNTAX	Integer

Snir, Ramberg, Strassner, Cohen         expires October 2000		   65 May 2001            109

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: follows.

NAME		  qosPolicyPHB
DERIVED FROM  policy (defined in [PCIM])
ABSTRACT      True
PROPERTIES	  qpDSCP

8.21.1.		qpMaxBandwidth
SYNTAX	Integer

8.37.5  The Property qpDSCP qpMaxDelay

This property is an integer, constrained to have a value in the range
0..63 inclusive, for representing the service classes in defines the QoS policy
domain maximal per hop delay that are used for traffic classification. of this
class should experience while being forwarded through this hop.
The maximal delay is measured in milliseconds. The attribute is defined
as follows: follows.

NAME		qpDSCP		qpMaxDelay
SYNTAX	Integer (must be in the range 0..63, inclusive)

8.22 Class qosPolicyMeter (milliseconds)

8.37.6  The Property qpMaxJitter

This class models a meter, as defined in (for example)
[DIFF-SERV-ARCH]. Meters measure the temporal properties of property defines the stream
of packets selected by a classifier against a maximal per hop delay variance that traffic profile.

A meter can be shared between different policy rules. A meter shared by
more than one policy rule resides
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 repository and typical packet size for this class of traffic.
This property is referenced by
all sharing rules. 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: follows.

NAME		  qosPolicyMeter
DERIVED FROM  policy (defined in [PCIM])
ABSTRACT      True
PROPERTIES		qpFairQueue
SYNTAX	Integer {Boolean} - {FALSE=0, TRUE=1}

Snir, Ramberg, Strassner, Cohen         expires October 2000		   66 May 2001            110

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 qosPolicyValue gpsPolicyValue

The qosPolicyValue 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 qosPolicyValue gpsPolicyValue class and properties that contain the
corresponding values SHOULD be added.

Notice that in many cases, using the qosPolicyAttributeValue gpsPolicyAttributeValue class
allows the definition of non-standard policy atoms without extending
the qosPolicyValue gpsPolicyValue class.

9.2. Extending qosPolicySimpleCondition gpsPolicySimpleCondition

The qosPolicySimpleCondition 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
qosPolicySimpleCondition classes
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

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 the superclass.

9.3. Extending qosPolicyAction a reusable filter
was added. The Qos Policy actions classes 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 Schema
Includes groups and their QPIM extensions,
gpsPolicyGroups and Policy rules were explained and examples
were added.
7. Role usage in the following types context of actions:

  Provisioning actions:
    * Marking
    * Policing, shaping and remarking according QoS policy was explained. No new
concepts were introduced. Role were also defined per
gpsPolicyGroups.
8. Change gpsPolicyMeter to include a traffic profile

  Signaling RSVP action:
    * RSVP policy admission
    * RSVP signal control extensions
    * RSVP flow control extensions

Additional actions and scope. The
previous way of binding the meter the traffic profile and a scope using
a provisioning action could be associated with QoS policy rules by
extending lead to inconsistencies if not used
properly (Bob).
9. Clarification of the policyAction class with use of gpValueTypes property of values and the appropriate properties.

Snir, Ramberg, Strassner, Cohen     expires October 2000		   67
meaning of table 3 (Bob).
10. Security Considerations Rewriting the draft in a storage independent way. The security considerations 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 this document are usage outside the same as those scope of
the [PCIM].

11. QoS domain

Snir, Ramberg, Strassner, Cohen         expires May 2001            112

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.

12.

13. References

[ABNF]      Crocker, D., and P. Overell, "Augmented BNF for
            Syntax Specifications: ABNF", RFC 2234, November
            1997.

[CL]        J. Wroclawski, "Specification of the Controlled-Load
            Network Element Service", RFC2211, September 1997

[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

[DEREF]     R. Moats, J. Maziarski, J. Strassner, "Extensible Match
            Rules to Dereference Pointer", Internet Draft
            <draft-moats-ldap-dereference-match-02.txt>

[DIFF-SERV-ARCH] S. Blake  D. Blake, "An Architecture for
                 Differentiated Services", RFC2475

[DNDEF]     Wahl, M., Kille, S., and T. Howes, "Lightweight
            Directory Access Protocol (v3): UTF-8 String
            Representation of Distinguished Names", RFC 2253,
            December 1997.

[GS]        S. Shenker, C. Partridge, R. Guerin, "Specification
            of the Guaranteed Quality of Service", RFC2212,
            September 1997

[IDNET]     S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T.
            Moore, S. Herzog, "Identity Representation for
            RSVP", RFC 2752, January 2000

[IPv6]      R. Hinden, S. Deering, "IP Version 6 Addressing

Snir, Ramberg, Strassner, Cohen     expires October 2000		   68

[LDAP_ATTR] M. Wahl, A. Coulbeck, " Lightweight Directory Access
            Protocol (v3): Attribute Syntax Definitions", RFC 2252

[NAME]      P. Mockapetris, " Domain names - implementation and
            specification", RFC1035

[PCIM]      J. Strassner, E. Ellesson, B. Moore, "Policy Framework Core
            Information Model", Internet Draft
            <draft-ietf-policy-core-info-model-05.txt>

[PHBLDAP]   R. Cohen, Y. Snir,

[PFSCHEMA]  J. Strassner, ˘LDAP schema for Domain
            Per Hop Behavior Set÷, E. Ellesson, B. Moore, "Policy Framework LDAP
            Core Schema", Internet Draft
            <draft-ronc-domain-phb-set-ldap-rep-00.txt>

[PHBSET]
            <draft-ietf-policy-core-schema-06.txt>

[QOSSCHEMA]	Y. Snir, Y Ramberg, J. Strassner, R. Cohen, A. Zavalkovsky, N. Elfassy, ˘Domain Per Hop
            Behavior Set Specification÷, "QoS
            Policy Schema", Internet Draft
            <draft-ronc-domain-phb-set-specification-00.txt>

[PFSCHEMA]
            <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. Strassner, E. Ellesson, B. Moore, "Policy Framework LDAP
            Core Schema", Internet Draft
            <draft-ietf-policy-core-schema-06.txt> 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>

[QOSDEV]    J. Strassner, W. Weiss, D. Durham, A. Westerinen,
            ˘Information Model for Describing Network Device QoS
            Mechanisms÷, Internet Draft
            <draft-ietf-policy-qos-device-info-model-00.txt>

[QOSSCHEMA]	Y. Snir, Y Ramberg, J. Strassner, R. Cohen, ˘QoS
            Policy Schema÷, Internet Draft
            <draft-ietf-policy-qos-schema-01.txt>

[RSVP]      Braden, R. ed., "Resource ReSerVation Protocol (RSVP) -
            Functional Specification.", IETF RFC 2205,
            Proposed Standard, Sep. 1997.

[RSVP-IS]   J. Wroclawski, "The Use of RSVP with IETF Integrated
            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

[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

[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 October 2000		   69

13. May 2001            114

14. Author's Addresses

Yoram Snir
    Cisco Systems
    4 Maskit Street
    Herzliya Pituach, Israel  46766
    Phone:  +972-9-970-0085
    Fax:    +972-9-970-0219    +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

14.

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 October 2000		   70 May 2001            115

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 October 2000		   71 May 2001            116