Policy Framework Working Group                                   Y. Snir
Internet Draft
INTERNET-DRAFT                                                Y. Ramberg
Expires May 2001
Category: Standards Track                                   J. Strassner
draft-ietf-policy-qos-info-model-02.txt                        R. Cohen
November 2000
                                                           Cisco Systems
                                                                R. Cohen
                                                               Ntear LLC
                           Policy Framework QoS Information Model
                    <draft-ietf-policy-qos-info-model-03.txt>

Status of this Memo

This document is an Internet Draft Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet Drafts

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 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). (2001).  All Rights Reserved.

Abstract

This document presents an object-oriented information model for
representing network QoS policies. This document is based on the IETF
Policy Core Information Model and its extensions as specified by [PCIM]. [PCIM]
and [PCIMe]. This draft
refines the concept of generic policy rules, conditions and actions
defined in [PCIM] in order builds upon these two documents to define extensions necessary for
representing IntServ and DiffServ QoS policies. It also provides
refinement of additional concepts that are important for building rule-
specific as well as reusable QoS policy rules.

This an
information model covers Differentiated Services QoS enforcement,
and Integrated Service for QoS enforcement via policy control on RSVP
admission. for differentiated and integrated
services using policy. It is important to note that this document defines
an information model, which by definition is independent of any
particular data storage mechanism and access protocol. Companion documents (e.g.,
[QoSSCHEMA]) define the mapping

Definition of these classes Key Word Usage

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
document are to specific data
models (schemata). be interpreted as described in RFC 2119 [KEYWORDS].

Snir, Ramberg, Strassner, Cohen          expires May November 2001          1

For example, [QoSSCHEMA] defines how to map the data in this
information model to a form that can be stored in a directory that uses
LDAPv3 as its access protocol.

Table of Contents

1.  Introduction                                                       6
1.1                                                        5
1.1.  Goals                                                             5
1.1.1.  Modeling Abstract QoS Policies                                  5
1.1.2.  Enhancing Interoperability                                      6
1.1.3.  Intended Audiences                                              7
1.2 Approach and Related Documents                                    7

2. Information Model Hierarchy                                        8
2.1  Interaction Between the PCIM and This Document                   8
2.1.1. Extension of Concepts in the PCIM
1.2.  QPIM Characteristics                                              8
2.1.1.1 Hierarchical Policy Repositories                              9
2.1.1.2 Extensions to Reusable Objects                                9
2.1.1.3 Extensions to the Structure of a Policy Rule                  9
2.1.2 Addition of New Concepts Not in the PCIM                        9
2.1.2.1 Rule Nesting                                                  9
2.1.2.2 Rule Decision Strategy                                       10
2.1.2.3 Compound Conditions                                          10
2.1.2.4 Pre-Defined Variables
1.3.  QPIM and Constants Other Published Standards                               10
2.1.2.5 Per-Hop Behaviors                                            11
2.1.3 Mapping to a Directory                                         11
2.2  High-Level

2.  Class Hierarchies                                                  11
2.1.  Inheritance Hierarchy                                            11

3. QPIM Hierarchies
2.2.  Relationship Hierarchy                                           13

3.  QoS Actions                                                        14
3.1. Class and Relationship Hierarchies Defined in the QPIM  Overview                                                         14
3.2. Implementation Guidelines  RSVP Policy Actions                                              15
3.2.1 Modeling Containment
3.3.  Provisioning Policy Actions                                      16
3.2.2. Implementing Relationships                                    17
3.2.2.1. Relationship modeling
3.3.1.  Admission Actions: Controlling Policers and Shapers            17
3.2.2.2. Representing Containment in a Consistent Manner
3.3.2.  Controlling Markers                                            18
3.2.3. Mapping Differences and
3.3.3.  Controlling Edge Policies  Examples                           18
3.3. 	QoS Domain Data Tree                                         19
3.4.    Types of Grouping Classes                                    22
3.5. QoS Policy Domain Grouping and Nesting                          23
3.6. Resource Sharing                                                25
3.7. Instance Location                                               26
3.8. Policy Containers                                               27
3.8.1 Semantics of a gpsPolicyGroup                                  27
3.8.2 Priority and Decision Strategy Applied to Containers           29
3.8.3 Sharing Policy Containers                                      30
3.9 Policy Roles associated with gpsPolicyGroup                      31
3.10 Policy Rules                                                    32
3.11 Conditions and Actions                                          33
3.12 Data Tree Example                                               33
3.13 Reusable-Object Repositories                                    34
3.14 Relationships Between QoS Domains and Repositories              35

Snir, Ramberg, Strassner, Cohen         expires May 2001             2

4. Constructing a QoS Policy Rule                                    36
4.1 Policy Rule Structure                                            36
4.2 QoS Policy Conditions                                            37
4.2.1. Simple Conditions                                             38
4.2.2. Compound Conditions                                           38
4.2.3. Using Simple Conditions                                       39
4.2.4. Using Compound Conditions                                     41
4.2.5. Reusable vs. Rule-Specific Conditions                         42
4.3 Simple Condition Operator                                        43
4.4 QoS Policy Variables                                             43
4.4.1 Variable Binding                                               45
4.4.2 Pre-Defined Variables                                          46
4.5 QoS Policy Value                                                 49
4.6. PolicyTimePeriodCondition                                       50
4.7. Actions                                                         50
4.7.1  Provisioning  Per-Hop Behavior Actions                                          52
4.7.1.1  Meters                                                      52
4.7.1.2  Markers                                                     53
4.7.1.3  Shapers                                                     54
4.7.1.4  Droppers                                                    54
4.7.1.5  Examples                                                    55
4.7.2  PHB actions                                                   57
4.7.2.1                                         20
3.4.1.  Controlling Bandwidth and Delay management                              57
4.7.2.2                                21
3.4.2.  Congestion Control and Buffer management                    58
4.7.2.3  Queues and PHB groups                                       58
4.7.2.4 Actions                                     21
3.4.3.  Using hierarchical policies                                 59
4.7.2.5 Hierarchical Policies  Examples                                                    59
4.7.3 Signaling for PHB Actions                                              61
4.7.3.1 Admission Control                                            62
4.7.3.2 Forwarding Behavior                                          62
4.7.3.3 Signaling Control                                            63
4.7.3.4 Examples                                                     63

4.8 Meters and         22

4.  Traffic Profiles 			             64
4.8.1                                                   23
4.1.  Provisioning Traffic Profiles                                  65
4.8.2                                    24
4.2.  RSVP Traffic Profiles                                          66                                            24

5. Decision strategy                                                 67
5.1 Organizing the Application of Decision Strategies                67
5.2  Decision Strategies                                             68
5.2.1. First Match Decision Strategy                                 68
5.2.2. Match All Decision Strategy                                   68
5.3. Decision Strategy example                                       69  Pre-Defined QoS-Related Variables                                  25

6. Per Hop Behavior                                                  70

7.  QoS Policy Class Inheritance                                      71

8. Related Values                                                 27

7.  Class Definitions                                                 75
8.1 The Aggregation "PolicyGroupInPolicyRule"                        75
8.1.1. The Reference "GroupComponent"                                75

Snir, Ramberg, Strassner, Cohen         expires May 2001             3

8.1.2. The Reference "PartComponent"                                 75

8.2 The Aggregation "PolicyRuleInPolicyRule"                         76
8.2.1. The Reference "GroupComponent"                                76
8.2.2. The Reference "PartComponent"                                 76
8.3 The Aggregation "PolicyConditionInCompoundCondition "            77
8.3.1. The Reference "GroupComponent"                                77
8.3.2. The Reference "PartComponent"                                 77
8.4 The Aggregation " PolicyVariableInPolicySimpleCondition "        77
8.4.1. The Reference "GroupComponent"                                78
8.4.2. The Reference "PartComponent"                                 78
8.5 The Aggregation " PolicyValueInPolicySimpleCondition "           78
8.5.1. The Reference "GroupComponent"                                79
8.5.2. The Reference "PartComponent"                                 79
8.6. The Definitions: Association "PolicyElementInPolicyRepository"               79
8.6.1. The Reference "Antecedent"                                    80
8.6.2. The Reference "Dependent"                                     80
8.7. Hierarchy                           28
7.1.  The Association "PolicyValueConstraintsInVariable"              80
8.7.1. "QoSPolicyTrfcProfInAdmissionAction"             28
7.1.1.  The Reference "Antecedent"                                    81
8.7.2.                                     28
7.1.2.  The Reference "Dependent"                                     81
8.8.                                      28
7.2.  The Association "PolicyMeterInAction"                           81
8.8.1. "PolicyConformAction"                            28
7.2.1.  The Reference "Antecedent"                                    81
8.8.2.                                     29
7.2.2.  The Reference "Dependent"                                     81
8.9.                                      29
7.3.  The Association "PolicyTrfcProfileInMeter"                      82
8.9.1. "PolicyExcessAction"                             29
7.3.1.  The Reference "Antecedent"                                    82
8.9.2.                                     29
7.3.2.  The Reference "Dependent"                                     82
8.10.                                      29
7.4.  The Association "PolicyQueueInPHBAction"                       82
8.10.1. "PolicyViolateAction"                            30
7.4.1.  The Reference "Antecedent"                                   82
8.10.2.                                     30
7.4.2.  The Reference "Dependent"                                    83
8.11.                                      30

Snir, Ramberg, Strassner, Cohen          expires November 2001          2

Table of Contents (continued)

8.  Class Definitions: Inheritance Hierarchy                           31
8.1.  The Association "PolicyConformNextAction"                      83
8.11.1. Class QoSPolicyDiscardAction                                 31
8.2.  The Reference "Antecedent"                                   83
8.11.2. The Reference "Dependent"                                    83
8.12. The Association "PolicyExcessNextAction"                       84
8.12.1. The Reference "Antecedent"                                   84
8.12.2. The Reference "Dependent"                                    84
8.13. The Association "PolicyViolateNextAction"                      84
8.13.1. The Reference "Antecedent"                                   85
8.13.2. The Reference "Dependent"                                    85
8.14. Class qosPolicyDomain                                          85
8.14.1. QoSPolicyAdmissionAction                               31
8.2.1.  The Property qpDomainName                                    85
8.14.2. qpAdmissionScope                                  31
8.3.  The Property qpPolicyRuleMatchMethod                         86
8.15. Class gpsPolicyGroup                                           86
8.15.1. The Property gpPriority                                      86
8.15.2. The Property gpNamedPolicyRuleMatchMethod                    87
8.15.3. QoSPolicyPoliceAction                                  32
8.4.  The Property gpPolicyRoles                                   87
8.16. Class qosPolicyPRAction                                        87
8.16.1. The Property qpDirection                                     87
8.16.2. QoSPolicyShapeAction                                   32
8.5.  The Property qpMarkvalue                                     88
8.16.3. Class QoSPolicyRSVPAdmissionAction                           33
8.5.1.  The Property qpMarkValueType                                 88
8.16.4. qpRSVPWarnOnly                                    33
8.5.2.  The Property qpExcessAction                                  88
8.16.5. qpRSVPMaxSessions                                 33
8.6.  The Property qpExcessMarkValue                               88
8.16.6. Class QoSPolicyPHBAction                                     34
8.6.1.  The Property qpViolateAction                                89
8.16.7. qpPacketSize                                      34
8.7.  The Property qpViolateMarkValue                              89

Snir, Ramberg, Strassner, Cohen         expires May 2001             4

8.17. Class qosPolicyPHBAction                                       89
8.17.1. QoSPolicyBandwidthAction                               34
8.7.1.  The Property qpPHBDirection 				     89
8.17.2. qpForwardingPriority                              35
8.7.2.  The Property qpDropAlgorithm                                90
8.17.3. qpBandwidthUnits                                  35
8.7.3.  The Property qpDropTreshholdValueType                       90
8.17.4. qpMinBandwidth                                    35
8.7.4.  The Property qpDropMinTreshholdValue 			     90
8.17.5. qpMaxBandwidth                                    35
8.7.5.  The Property qpDropMaxTreshholdValue 			     90
8.17.6. qpMaxDelay                                        36
8.7.6.  The Property qpRandomDropInvWeight 			     91
8.17.7. qpMaxJitter                                       36
8.7.7.  The Property qpRandomDropProbMax 			     91
8.17.8 qpFairness                                        36
8.8.  The Property qpPacketSize                                    91
8.18. Class qosPolicyRSVPAction                                      91
8.18.1. The Property qpRSVPDirection                                 92
8.18.2. QoSPolicyCongestionControlAction                       36
8.8.1.  The Property qpRSVPMessageType                               92
8.18.3. qpSizeUnits                                       37
8.8.2.  The Property qpRSVPStyle                                     92
8.18.4. qpQueueSize                                       37
8.8.3.  The Property qpRSVPServiceType                               92
8.19. Class qosPolicyRSVPSignalCtrlAction                            93
8.19.1. qpDropAlgorithm                                   37
8.8.4.  The Property qpForwardingMode                                93
8.19.2. qpDropThresholdUnits                              37
8.8.5.  The Property qpSendError                                     93
8.19.3. qpDropMinThresholdValue                           38
8.8.6.  The Property qpReplaceDSCP                                   93
8.19.4. qpDropMaxThresholdValue                           38
8.9.  The Property qpReplacePreemptionPriority                     94
8.19.5. Class QoSPolicyTrfcProf                                      38
8.10.  The Property qpReplaceDefendingPriority                      94
8.20. Class qosPolicyRSVPInstallAction                               94
8.20.1. QoSPolicyTokenBucketTrfcProf                          39
8.10.1.  The Property qpSetDSCPValue                                  95
8.20.2. qpTBRate                                         39
8.10.2.  The Property qpSetDefendingPriority                          95
8.20.3. qpTBNormalBurst                                  39
8.10.3.  The Property qpSetPreemptionPriority                         95
8.21. Class gpsPolicyTrfcProf                                        95
8.22. qpTBExcessBurst                                  39
8.11.  The Class qosPolicyPRTrfcProf                                      96
8.22.1. QoSPolicyIntServTrfcProf                              40
8.11.1.  The Property qpPRRate                                        96
8.22.2. qpISTokenRate                                    40
8.11.2.  The Property qpPRNormalBurst                                 96
8.22.3. qpISPeakRate                                     40
8.11.3.  The Property qpPRExcessBurst                                 96
8.23.  Class qosPolicyRSVPTrfcProf                                   96
8.23.1. qpISBucketSize                                   40
8.11.4.  The Property qpRSVPTokenRate                                 96
8.23.2. qpISResvRate                                     41
8.11.5.  The Property qpRSVPPeakRate                                  97
8.23.3. qpISResvSlack                                    41
8.11.6.  The Property qpRSVPBucketSize                                97
8.23.4. qpISMinPolicedUnit                               41
8.11.7.  The Property qpRSVPResvRate                                  97
8.23.5. qpISMaxPktSize                                   41
8.12.  The Property qpRSVPResvSlack                                 97
8.23.6. Class QoSPolicyAttributeValue                               42
8.12.1.  The Property qpRSVPSessionNum                                97
8.23.7. qpAttributeName                                  42
8.12.2.  The Property qpMinPolicedUnit                                98
8.23.8. qpAttributeValueList                             42
8.13.  The Property qpMaxPktSize                                    98
8.24. Class gpsPolicySimpleCondition                                 98
8.24.1. QoSPolicyRSVPVariable                                 42
8.14.  The Property gpOperator                                      99
8.25. Class gpsPolicyCompoundCondition                               99
8.25.1 QoSPolicyRSVPSourceIPv4Variable                       43
8.15.  The Property gpPolicyConditionListType                        99
8.26. Class gpsPolicyVariable                                       100
8.26.1. The Property gpVariableName                                 100
8.26.2. QoSPolicyRSVPDestinationIPv4Variable                  43
8.16.  The Property gpVariableDescription                         101
8.27. Class gpsPolicyValue                                          101
8.28. QoSPolicyRSVPSourceIPv6Variable                       43
8.17.  The Class gpsPolicyIPv4AddrValue                                  101
8.28.1. QoSPolicyRSVPDestinationIPv6Variable                  44
8.18.  The Property gpIPv4AddrList                                 102
8.29. Class gpsPolicyIPv6AddrValue                                  102
8.29.1. QoSPolicyRSVPSourcePortVariable                       44
8.19.  The Property gpIPv6AddrList                                 102 Class QoSPolicyRSVPDestinationPortVariable                  44

Snir, Ramberg, Strassner, Cohen          expires May November 2001             5

8.30. Class gpsPolicyMACAddrValue                                   103
8.30.1.          3

Table of Contents (continued)

8.20.  The Property gpMACAddrList                                  103
8.31. Class gpsPolicyStringValue                                    104
8.31.1. QoSPolicyRSVPIPProtocolVariable                       45
8.21.  The Property gpStringList                                   104
8.32 Class gpsPolicyBitStringValue                                  104
8.32.1. QoSPolicyRSVPIPVersionVariable                        45
8.22.  The Property gpBitStringList                                104
8.33. Class gpsPolicyDNValue                                        105
8.33.1. QoSPolicyRSVPDCLASSVariable                           45
8.23.  The Property gpDNList                                       105
8.34. Class gpsPolicyAttributeValue                                 106
8.34.1. The Property gpAttributeName                                106
8.34.2. QoSPolicyRSVPStyleVariable                            46
8.24.  The Property gpAttributeValueList                           106
8.35. Class gpsPolicyIntegerValue                                   107
8.35.1. QoSPolicyRSVPIntServVariable                          46
8.25.  The Property gpIntegerList                                  107
8.36. Class gpsPolicyMeter                                          108
8.36.1. The Property gpMeterScope                                   108
8.36.2. QoSPolicyRSVPMessageTypeVariable                      46
8.26.  The Property gpMeterTimeInterval                            108
8.37. Class qosPolicyQueue                                          109
8.37.1. QoSPolicyRSVPPreemptionPriorityVariable               47
8.27.  The Property qpForwardingPriority 			    109
8.37.2. Class QoSPolicyRSVPPreemptionDefPriorityVariable            47
8.28.  The Property qpBandwidthValueType		            109
8.37.3. Class QoSPolicyRSVPUserVariable                             48
8.29.  The Property qpMinBandwidth 				    109
8.37.4. Class QoSPolicyRSVPApplicationVariable                      48
8.30.  The Property qpMaxBandwidth 				    110
8.37.5 Class QoSPolicyRSVPAuthMethodVariable                       49
8.31.  The Property qpMaxDelay                                     110
8.37.6 Class QosPolicyDNValue                                      49
8.31.1.  The Property qpMaxJitter                                    110
8.37.7 qpDNList                                         49
8.32.  The Property qpPacketSize                                   110
8.37.8 Class QoSPolicyRSVPSimpleAction                             50
8.32.1.  The Property qpFairQueue                                    110 qpRSVPActionType                                 50

9. Extending the QoS Policy Schema                                  111
9.1. Extending gpsPolicyValue                                       111
9.2. Extending gpsPolicySimpleCondition                             111
9.3. Extending qosPolicyAction                                      111  Acknowledgements                                                   50

10.  Security Considerations                                         112                                           50

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

14. Author's                                                        51

12.  Authors' Addresses                                              115

15.                                                52

13.  Full Copyright Statement                                        115                                          53

Snir, Ramberg, Strassner, Cohen          expires November 2001          4

1.  Introduction

This document presents an object-oriented information model for
representing network QoS policies. As such, it is independent of any
specific data storage mechanism and access protocol. This document is based on the IETF
Policy Core Information Model and its extensions as specified by [PCIM].
Specifically, this draft refines the concept of generic policy rules,
conditions and actions to cover extensions necessary for representing
IntServ [PCIM]
and DiffServ QoS policies.

Snir, Ramberg, Strassner, Cohen         expires May 2001             6 [PCIMe]. This draft builds upon these two documents to define an
information model covers Differentiated Service QoS enforcement,
and Integrated Service for QoS enforcement via policy control on RSVP
admission. Companion documents (e.g., [QoSSCHEMA]) define the mapping
of these classes to specific data models (schemata). For example,
[QoSSCHEMA] defines how for differentiated and integrated
services using policy. It is important to map the data in note that this document defines
an information model to a
form that can be stored in a directory that uses LDAPv3 as its model, which by definition is independent of any
particular data storage mechanism and access protocol.

The following subsections describe the goals and purposes of the QoS
Policy Information Model (QPIM), its intended audience, and its
relationships to other published standards.

1.1  Goals

This document defines a set section explains the goals for creating QPIM.

1.1.1.  Modeling Abstract QoS Policies

The main goal of classes that can be used the QPIM is to build high
level policies create an information model that can be
used to configure help bridge part of the conceptual gap between a human policy
maker and enforce consistent QoS
behavior across a network. Specifically, network element that is configured to enforce the policies defined in policy.
Clearly this
document can be used wide gap implies several translation levels, from the
abstract to control and manage different vendor-specific
device mechanisms that the concrete. At the abstract end are used to build different IntServ and DiffServ the business QoS behaviors. The purpose of introducing a standard information model
is to allow interoperability between policy servers, policy management
applications, and network devices.

This document solves two problems. First, different devices have
different capabilities, and may respond differently to the same high-
level policy rule. This document solves this problem by defining
rules. QPIM facilitates a set formal representation of common abstractions that can be used to build high-level network QoS
policies. These high-level business
rules, thus providing the first concretization level: formally
representing humanly expressed QoS policies control policy.

When a human business executive defines network policy, it is usually
done using informal business terms and manage low-level
QoS device mechanisms independent of the specific type of device language. For example, a human may
utter a policy statement that
is being managed. This enables different devices reads: "traffic generated by our human-
resources application should have higher priority for making it through
to use the same low-
level abstractions of mechanisms its destination compared to implement QoS services, which are
controlled traffic generated by people browsing the QoS policy rules defined in
WEB during their lunch breaks". While this document.

Second, different statement clearly defines QoS
policy servers and applications may provision parts
of for the network, 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 itself cannot 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, it. Translation
to "network terms and others). Examples include sharing of language" is required.

On the same definition of well-known application port numbers, IP
addresses of servers and other network attributes. It allows checking
of consistent behaviors end of the interaction between the different
managers by comparing, scale, a network element functioning as a Policy
Enforcement Point (PEP, see [TERMS] for example, its definition), such as a
router, can be configured with specific commands that determine the set
operational parameters of its inner working QoS and security actions
enforced on mechanisms. For example,
the same set of flows.

The remainder (imaginary) command "output-queue-depth = 100" may be an instruction
to a network interface card of this document presents, describes and defines a router to allow up to 100 packets to be
stored before subsequent packets are discarded (not forwarded). On a
different device within the
QoS Policy Information Model (QPIM). QPIM is same network, the same instruction may take
another form, because a different vendor built that device or it has a
different set of entities functions, and
relationships (both modeled by classes) hence implementation, even though it is
from the same vendor. In addition, a particular PEP may not have the
ability to create queues that define managed objects and are longer than, say, 50 packets, which may
result in a different instruction implementing the same business policy.

Snir, Ramberg, Strassner, Cohen          expires May November 2001             7

interactions between managed objects that          5

The first example illustrates 'abstract policy', while the second
illustrates 'concrete configuration'. Furthermore, the first example
illustrates end-to-end policy, which covers the conditioning of
application traffic throughout the network. The second example
illustrates configuration for a particular PEP or a set thereof. While an
end-to-end policy statement can only be used to define,
manage, and control IntServ and DiffServ QoS mechanisms using policies.
It uses basic concepts defined enforced by configuration of PEPs
in [PCIM] but extends those to control
IntServ and DiffServ QoS mechanisms. Since QPIM is an various parts of the network, the information model
(and is therefore independent of any specific data storage mechanism policy and access protocol limitations), this document is limited to
discussing the different managed objects that are used to define and
provision IntServ and DiffServ QoS policies. Relationships to
of the Core
schema [PCLS] and issues related mechanisms that a PEP uses to mapping this information implement that policy is vastly
different.

The translation process from abstract business policy to concrete PEP
configuration is roughly expressed as follows:

1.	Informal business QoS policy is expressed by a form
suitable for implementation in human policy maker
(e.g. "All executives' WEB requests should be prioritized")
2.	A network administrator models the informal policy by using QPIM
constructs, thus creating a directory, along with correct usage formal representation of the mapped schema, are defined abstract
policy. (e.g. "If packet's protocol is HTTP and its destination is in [QOSSCHEMA].

2. Information Model Hierarchy

This section discusses
the relationships between 'EXECUTIVES' user group, then assign IPP 7 to the Policy Core
Information Model [PCIM], packet header").
Note that the QoS Policy Information Model (QPIM,
which administrator is this document) and future extensions of the very likely to use a particular data
model (e.g., LDAP schema) that is mapped to QPIM.

2.1  Relationship Between
3.	The network administrator maps the PCIM abstract, formal policy to PEPs
(most likely by using roles, as specified in  [PCIMe, sections 2.2.4
and This Document

This document both extends concepts 4.6]).
4.	A configuration/distribution agent (or a PDP  see [TERMS] for its
definition) consults a device capability model to determine how to
translate the policy into device configuration. An example for a
standards-based capability model is [QDDIM]. Note that one or more
such translations are part of possible, depending on the [PCIM] particular
capabilities of a given PEP and
adds new functions that are not part the implementation of the [PCIM].

The [PCIM] models high-level policy concepts and introduces structural
conventions and nomenclature common system.
5.	For each PEP in the network, the configuration/distribution agent
configures the appropriate instructions to all types of policies. The
fundamental purpose of enforce the [PCIM] policy.

QPIM is intended to provide a generic
representation of be the bridging mechanism between step #1 and step #2
in the structure methodology just described.

1.1.2.  Enhancing Interoperability

Another goal of a QPIM is to facilitate interoperability among policy rule, along with
systems, PDPs in particular. QPIM accomplishes its interoperability goal
by standardizing a set representation of
classes policy. Producers and relationships that can serve as a common representation consumers of
QoS policy groups, rules, conditions, and actions. This enables derived
information models and need only rely on QPIM-based schemata (or data models) to use a common set of terminology,
classes,
ensure mutual understanding and approaches, thus facilitating interoperability.

The QPIM refines and extends agreement on the concepts semantics of the [PCIM] by introducing QoS policy.
For example, suppose that 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 policy management application, built by
vendor A, writes its policies based on an LDAP schema that are compliant with either the
integrated services [Intserv] and/or with the differentiated service
approach [Diffserv].

2.1.1  Extension of Concepts in the PCIM

The maps from QPIM extends three fundamental concepts defined in [PCIM] in order
to be able
to define policies that can control, manage a directory implementation.A separately built PDP from vendor B may
then read this policy and provision "understand" it as both the QoS mechanisms of devices. These are hierarchical policy
repositories, extensions to reusable objects, management
application and extensions the PDP were architected to comply with the
structure of a policy rule. QPIM
standard.

Snir, Ramberg, Strassner, Cohen          expires May November 2001             8

2.1.1.1 Hierarchical Policy Repositories

The concept          6

Interoperability of a "nested" policy repository (i.e.,  a repository that QPIM producers/consumers is embedded within another repository) by definition at a high
level, and does not guarantee that contains the same policy
information, was originally defined will result in an earlier version of the QPIM.
It has subsequently been moved into the [PCIM], since it is a general
concept that is not limited to QoS,
same PEP configuration. First, different PEPs will have different
capabilities and can be used by other
applications. This document reuses this concept, but defines specific
refinements for using "embedded policy repositories" to accommodate functions, which necessitate different individual
configurations even if the
application-specific needs of QoS provisioning. These reflect different PEPs are controlled by the need
to provide nested levels of administration same
policy. Second, different PDPs will also have different capabilities and scoping to policies
functions, and may choose to translate the high-level QPIM policy information.

2.1.1.2  Extensions to Reusable Objects

Similarly,
differently depending on the concepts functionality of reusable objects vs. rule-specific objects
have been moved from an earlier version the PDP as well as the
capabilities of this document to the [PCIM].
In addition, this document defines specific extensions to guide the
implementation of reusable- vs. rule-specific QoS objects.

2.1.1.3  Extensions to PEPs that are being controlled by the Structure of a Policy Rule

This document also extends PDP. Finally,
the concept of same policy may be interpreted slightly differently depending on
various factors. For example, a QPIM policy rule. It is
important to note rule that this reads "If packet's
protocol is done without having HTTP then assign 7 to redefine or
subclass of PolicyRule (as defined IPP", may result in [PCIM]), because if different
configurations depending on how that was
done, then interoperability would rule is implemented. For example, an
application recognition mechanism can be adversely affected. This document
also defines additional conditions and actions that are specific used to
QoS. It further defines different types of actions that target DiffServ
and IntServ actions.

2.1.2  Addition of New Concepts Not in enforce the PCIM

There are several notable new concepts that are policy. If
the device does not part of supports this particular mechanism, then an alternate
mechanism must be used. For example, the [PCIM].
These include rule nesting, rule decision strategy, compound
conditions, pre-defined variables and constants, and Per Hop Behavior
definition, as part packets could be classified
based on their destination TCP port.

Therefore, we define interoperability of the QoS actions.

2.1.2.1  Rule Nesting

The [PCIM] defines policies as the ability to group policy rules by defining the
policyGroup class. This class can be used to contain a set of
policyRules and/or
specify a set of policyGroups. This grouping mechanism
allows for constructing policy rule in a flexible and extensible information model.
However, it treats PolicyRules as atomic objects standard format. The advantage is that such a
policy can contain only
conditions be understood by PDPs and actions. In practice, this is PEPs manufactured from different
vendors having different capabilities and functionality, as well as
policy-based applications. We specifically do not flexible enough for
some of require a policy to be
translated into exactly the needs of IntServ and DiffServ.

Snir, Ramberg, Strassner, Cohen         expires May 2001             9

Therefore, this document adds same configuration in different PEPs. This is
why we view the concept of nesting one or more policy
rules within a policy rule. For example, one could think of a policy
rule above two systems that controls how a user logs onto differ in the network as consisting interpretation of
two parts. A high-level rule is used
recognizing WEB traffic as interoperable with regard to group together a set of lower-
level rules that are invoked at various stages policy. The
advantage of processing (e.g., how
the user using QPIM policies is authenticated, how that incompatible device capabilities
may still be employed and controlled using the IP Address QPIM policy.

1.1.3.  Intended Audiences

QPIM is assigned, etc.). intended for several audiences. The
high-level rule would also contain information to properly control the
execution sequence following lists some of the lower-level rules, as well
intended audiences and their respective uses:

1.	Application vendors who build QoS policy management applications can
use this model as an extensible framework for defining policies to provide a
consistent
control PEPs and conceptually simpler interface to other objects PDPs in the
system. This is implemented by allowing a PolicyRule to contain a
PolicyRule or a PolicyGroup as one an interoperable manner
2.	Developers of its components.

2.1.2.2  Rule Policy Decision Strategy

Since there is no concept of nested rules in the [PCIM], there is no
need for a decision strategy to be used Point (PDP) systems can use this
framework to define the order of
processing of these rules. However, since QPIM allows develop interoperable policies
3.	QoS policy makers who seek a standardized model for nested rules,
different examples expressing a
formal representation of decision strategies must be defined in this
document and shown that they QoS policy can work in use this new environment. This
document defines two such decision strategies: match-first and match-
all. Both define an ordering that can be applied model to a set control PEPs
of
policyRules varying capabilities and policyGroup objects within a larger context (e.g., a
policy domain). This in turn controls the execution functionality
4.	Builders of different policy
actions. Note that choosing a different decision strategy is one way large organization data and knowledge bases who decide to
change the result of executing a set of
combine QoS policy rules without changing
the information with other networking policy rules themselves.

2.1.2.3  Compound Conditions

[PCIM] defines conditions that consist of a single term.
information, assuming all modeling is based on [PCIM] allows
such conditions to be logically combined using 'AND' and 'OR' terms.
This makes sense, because all conditions can be constructed from such
primitives. However, a richer means [PCIMe]
5.	Authors of representing common conditions
is called for.

This various standards may use constructs introduced in this
document extends the concept to enhance their work. Authors of a simple (i.e., one-term)
condition data models wishing to define compound conditions. This is conceptually
equivalent map
a storage specific technology to using QPIM must use this document as well.

Snir, Ramberg, Strassner, Cohen          expires November 2001          7

1.2.  QPIM Characteristics

First, a set general statement that characterizes QPIM:

"The QoS Policy Information Model (QPIM) establishes a standard framework
and constructs for specifying and representing business QoS policies.
This framework consists of simple conditions. However, supporting
compound conditions enables a better matching set of the classes and relationships, organized
in an object-oriented information model
to the environment that it model. It is modeling, agnostic of any specific
PDP or PEP implementation and also simplifies the mapping independent of the information model any particular QoS
technology mechanism.  It is intended to different types be used to control the
provisioning of data models. end-to-end network services."

In
addition, it enhances the manageability and reusability rest of complex
conditions. Therefore, the classes and relationships needed to build this in section, we itemize and expand the general statement
presented above.

1.	QPIM, as efficient the name implies, is a manner as possible QoS Policy Information Model. This
means that it only models QoS concepts. These concepts are defined either
derived in this document.

2.1.2.4  Pre-Defined Variables and Constants

This document also defines a set of variable and constant definitions document, or adapted for use with QoS policies. This concept is not present in the [PCIM]

Snir, Ramberg, Strassner, Cohen         expires May 2001             10

because the purpose of the [PCIM] is to provide a general structure for
representing policy rules, conditions and actions. Variable and
constant definitions represent specific concepts that have pre-defined
semantics.

This version of this draft has these elements residing in this draft.
However, they have been generalized so that modelingQoS from other applications besides
QoS can use them.

2.1.2.5  Per-Hop Behaviors

Finally, QoS Policy definition may require the notion of a Per-Hop
Behavior (specified by the differentiated services paradigm). This
document provides interpretation for this notion by providing a way to
represent Per-Hop Behaviors using policy rules.

2.1.3  Mapping to a Directory

The PCIM and
documents.

2.	QPIM are both inherently extensible. Furthermore, they are
designed to fit together to produce one "virtual" is an information model. As such, both are it is independent of any particular
specific data storage mechanism and access protocol. However, mappings can QPIM's constructs
may be defined mapped to translate the various storage and data organization technologies. A
data
from this single virtual information model mapped to a form that QPIM can be
implemented created in a specific type of data storage mechanism that uses one
or more specific access protocols. Examples of mapping relational database, an
object oriented database, an LDAP directory and more. Because QPIM is
not a schema, the concepts of reader is encouraged to focus on the [PCIM] conceptual
level and this document to not on the data organization methodology. Clearly a form that can be implemented mapped
schema would include enhancements and optimizations not appropriate in
the information-modeling realm. For example, a
directory that uses LDAP given association
between two classes is always modeled as its access protocol are provided in
[PFSCHEMA] and [QOSSCHEMA], respectively.

This document specifies an extensible information model. While this
document defines facilities for building policy rules, conditions association class in QPIM.
A given schema may find it useful and
actions efficient to build QoS policies, it is recognized that not all required
functionality can model such a
relationship using a reference object attribute in a directory or should be defined a
keyforeign key relationship in this document. Therefore, any
implementation-specific schema that a relational database.

3.	QPIM is derived from this information standard. The model should further concretize standardizes the QoS concepts process of the specifying
business QoS Policy
schema to suit its own application-specific needs. This policies. It is best done by
extending the set of classes an interpretation and relationships extension of the
core policy information model as defined in this
document, as opposed [PCIM] and [PCIMe]. It
references other IETF standards (e.g. [TERMS], [DIFFSERV] and others)
and is meant to redefining new concepts that are not compatible
with either this document or PCIM.

2.2  High-Level Class Hierarchy

The enhance interoperability of QoS systems from different
vendors.

QPIM establishes a conceptual framework by fully and closely following diagram shows how the classes in this document relate to
the classes defined core policy framework as specified in [PCIM] and [PCIMe]. QPIM
inherits all of its constructs from the PCIM. core model, providing QoS
interpretation and extensions where necessary.

4.	QPIM is object oriented. The modeling methodology is based on UML
(Unified Modeling Language [UML]. This is a ubiquitous modeling method
that is easy to understand and read. In addition, UML-based models
lend themselves to further extensions and natural progression toward
detailed data models.

Snir, Ramberg, Strassner, Cohen          expires May November 2001             11

[unrooted]
   |
   +--Policy (abstract, defined          8

5.	QPIM is a formal model. It expresses its concepts by describing and
defining classes and inter-class associations. Classes are formal
definitions of major concepts. For example, the concept of a traffic
profile is represented by the QosPolicyTrfcProf (abstract) class. A
derivative of this class provides several attributes to describe the
traffic 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 filtering on a
five- or six-tuple (e.g., the source and destination address and ports,
protocol, and DSCP). This type of filter  can be modeled as a container
that holds one or more simple conditions.

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

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

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

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

Snir, Ramberg, Strassner, Cohen         expires May 2001             41

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

operation to be applied to a condition (e.g., the condition is matched
if the term is NOT true), and to define the interpretation of the term
(i.e., which terms are grouped together, and whether they are ORED or
ANDed together).

The following example illustrates the construction of a reusable
compound condition, named "My-Server", that expresses the following
logic: SourceIPAddress=1.1.1.1 AND SourcePort=7777:

A compound condition is created and is assigned a unique name, in this
case, "My-Server". The gpsPolicyCompoundCondition property
policyConditionListType is set to DNF.

The compound condition is built by ANDing two gpsPolicySimpleCondition
instances. The first simple condition is implemented using a
gpsPolicySimpleCondition object. It includes a SourceIPAddress variable
and an IP address value of "1.1.1.1". The second simple condition is
also implemented using a gpsPolicySimpleCondition object. It includes a
SourcePort variable and an integer value of 7777.

Each of the simple conditions is linked to the compound condition
container using the PolicyConditionInCompoundCondition aggregation.
The qpsPolicyCompoundCondition is then made reusable by placing it in a
reusable-object repository using  the PolicyConditionInPolicyRepository
association. To use this compound condition in a policy rule, the
PolicyConditionInPolicyRule aggregation is used.

4.2.5 Reusable vs. Rule-Specific Conditions

This information model facilitates reuse of simple conditions (using
the qpsPolicySimpleCondition class) as well as more complex expressions
(using the qosPolicyCompoundCondition class) by placing them in a
common portion of the policy information tree (called the reusable-
object repository). In order for a condition to be placed in this
repository, it must carry a unique name.

A reusable gpsPolicySimpleCondition contains a value and a variable.
There are two different ways to build simple (or compound) conditions.
One way is for the values and variables to be embedded within the
condition directly. Conceptually, this can be thought of as specifying
that when the condition is instantiated, its variables and values will
also be instantiated as part of the same object that is used to build

Snir, Ramberg, Strassner, Cohen         expires May 2001             42

the condition itself. In this case, embedding the values and variables
within the policy condition is specified by the
PolicyValueInPolicyCondition and PolicyVariableInPolicyCondition
aggregations, respectively. This is called a rule-specific condition,
because its components can not be shared with other rules.

Alternatively, a policy variable and/or a policy value can be
instantiated in a reusable-object repository and then referenced by the
(simple or compound) condition. The values (or variables) are linked to
the PolicyRepository using the PolicyElementInPolicyRepository
association; the condition is linked to the PolicyRepository using the
PolicyConditionInPolicyRepository association. Note that the reusable-
object repository may be part of the same data store as that which
contains the aggregating condition, or it may be a physically different
data store..

4.3 Simple Condition Operator

The QoS policy simple condition includes the gpOperator property,
which specifies the type of relation between the variable and the value
evaluated in the condition. In many cases, a generic 'match' operator
can be used, and the interpretation of the relation between the
variable and value is implied by the value itself. For example, the
variable SourceIPAddress can be matched to an IP address, where the
'equal' relation is implied, to a hostname in which the 'resolve to'
relation is implied, or to a subnet address in which 'belongs to'
relation is implied. Similarly, this same variable (which is a string)
has semantics that determine the acceptable values that the string can
take. For example, an improperly formed address in either CIDR or
dotted decimal notation can be detected and rejected.

The QPIM defines a single operator, "match", that models the most
generic relation: that of being equal or belonging to.

4.4 QoS Policy Variables

QoS policy variables are used for building individual conditions, as
defined in section 4.2. The variable specifies the attribute of a flow
that should be bound and evaluated according to a set of pre-defined
semantics in a condition. Its purpose is to act as a binding point,
associating a condition with an object whose data is evaluated
according to the specified operator/value. The QPIM has defined
semantics for some of the most common of these variables based upon
these sources to guide the binding of common data. However, such
binding could also be determined from a variety of other standard and
proprietary sources such as public or private MIBs or application-
specific data.

Snir, Ramberg, Strassner, Cohen         expires May 2001             43

Not every combination of a variable and a value creates a meaningful
condition. For example, a source IP address variable can not be matched
against a value that specifies a port number. The QPIM defines a set of
variables that can be used to model common QoS policy conditions, and
assigns appropriate semantics for each. Each type of variable
inherently selects the set of value types that it can be matched
against (i.e. a value that could be compared and evaluated to a Boolean
expression).

Variables have data types. Many of the variables defined in this draft
have associated semantics that limit the set of values within a
particular value type that can be matched against it in a condition.
This may be viewed as a second level of integrity checking. For
example, a variable representing the source-port must limit the set of
values that it can assume to the valid range of integers that
correspond to legal source-port values; values such as -3 or 2000000
are not legal values and can not be matched to this variable. Thus, it
is not enough to say that the data type of the source-port variable is
an integer; we also need to ensure that the value to be tested is
within a valid range of integers. This is achieved by associating the
source port variable with an integer value object that contains the
appropriate value range for that variable.

In this first implementation, simple semantics such as those described
above are realized by defining a separate class whose properties
contain the constraints. This constraint class is then linked to the
PolicyValue class through the PolicyValueConstraintsInVariable. In the
future, a more robust mechanism, such as an object constraint language,
may be integrated with the information model to provide even more
metadata to describe legal behavior, values and operations on the
variable. Currently, such a language is not integrated with either this
information model or PCIM. The mechanism defined in this draft enables
implementation experience to be gained to help guide the integration of
a constraint language in the future.

The QPIM defines one attribute, one association, and one general
purpose mechanism that together characterize each of the variables that
it defines:

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

  2. The PolicyValueConstraintsInVariable association defines the set
     of value classes that could be matched to this variable.

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

Snir, Ramberg, Strassner, Cohen         expires May 2001             44

For example, if a PolicyVariable represents the SourcePort of incoming
traffic, then a PolicyValueConstraintsInVariable association can be
used to link the PolicyVariable instance to an qosPolicyIntegerValue
instance. This association by itself constrains the data type of the
SourcePort PolicyVariable to be an integer. However, we can further
constrain the particular values that the SourcePort PolicyVariable can
hold by entering valid ranges in the qpIntegerList property of the
qosPolicyIntegerValue instance.

Note that implementations are free to realize the semantics defined by
these two associations in a number of different ways. The information
model defines these semantics based around an association, because that
is the most general form describing how this information is related. An
implementation could conceivably realize this using zero or more actual
relationships.

The combination of the qpVariableName and the
PolicyValueConstraintsInVariable assocation provide a consistent and
extensible set of metadata that define the semantics of variables that
are used to form QoS conditions. Since the
PolicyValueConstraintsInVariable association points to another class,
any of the properties in the PolicyValue class can be used to constrain
values that the PolicyVariable can hold. For example:

  - The gpVariableName can be used to identify common processing rules
    for a variable having a specific name.
  - The PolicyValueConstraintsInVariable association can be used to
    ensure that only proper classes are used in the expression. For
    example, the SourcePort variable will not be allowed to associate
    to the qpsPolicyIPv4AddrValue class, since source ports have
    different semantics than IP addresses and may not be matched.
    However, it will associate to a gpsPolicyIntegerValue class.
  - The PolicyValueConstraintsInVariable association also ensures that
    variable-specific semantics are enforced (e.g., the SourcePort
    variable may include a constraint association to a value object
    defining a specific integer range that should be matched).

4.4.1. Variable Binding

For the QoS Policy schema to be interoperable, different policy
management systems and policy servers must instantiate the same
variables with identical values (in the same evaluation operation).
While different policy servers may use a different binding mechanism,
the binding logic must result in an identical instantiation.

Each variable defined in the QoS policy data store must be bound to a
logical entity such as a specific field in the IP header, a specific
class or property in the QPIM or in a related Information or Data
Model, an application unique identifier or an application-specific
parameter.

Snir, Ramberg, Strassner, Cohen         expires May 2001             45

When a policy server attempts to evaluate an expression containing
variables, it must instantiate the variables. To instantiate a
variable, that variable must be bound to a specific value (or values,
depending on its type category) and associated with a logical entity.
For example, in the expression 'SourcePort == 80', the variable
'SourcePort' must be instantiated to a value and logically associated
with the packet header field containing the source port number, for the
expression to be evaluated.

If, in this example, the variable SourcePort is bound to a value of
'80', then the expression is evaluated to TRUE for each packet that the
source port number in the IP header field equal to 80. Otherwise it is
evaluated to FALSE.

4.4.2. Pre-Defined Variables

The purpose of this section is to explain the need and define the
relationship of standard, frequently used variables with their logical
entities. Pre-defined variables are necessary for ensuring
interoperability among policy servers and policy management tools from
different vendors.

For example, different policy servers may have to evaluate the same
policy rule. If each policy server uses a common set of variables, this
helps to abstract the condition term such that its evaluation can be
performed in the same way by all of those policy servers. If no such
set of common variables exist, then each policy server is free to
define its own set of variables. Variations in each variable that each
policy server defines will impede interoperability, and prevent the
same semantics and interpretation to be achieved when each policy
server implements the same policy rule.

The QoS Policy information model specifies a set of pre-defined
variables to support a set of fundamental QoS terms that are commonly
used to form conditions. Examples of these include IP header field
values, user information, applications, and others. A pre-defined
variable MUST always have the same name and binding semantics. For
example, a given pre-defined variable should be bound to the same
logical entity by all client systems (typically policy devices).
Similarly, the pre-defined variable should be stored in the reusable-
object repository to enable reuse and sharing of the pre-defined
variable.

Snir, Ramberg, Strassner, Cohen         expires May 2001             46

All standard variable names are case insensitive and do not include
spaces or other non-standard characters to promote ease of use.

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

Following is a table that defines the predefined variable names and
their binding. The table indicates which fields are checked in actual
filters used in provisioning policies as well as in RSVP signaling
messages.

+-----------------+---------------------------------------------------+
|Variable name    |                Logical binding                    |
+-----------------+---------------------------------------------------+
| SourceIP        | The source IP address of the flow. Compared to the|
|                 | source IP header field, or the sender address in  |
|                 | the RSVP Filter spec object [RSVP].               |
+-----------------+---------------------------------------------------+
| SourcePort      | The source Port of a UDP/TCP flow. Compared to the|
|                 | source port field in the TCP/UDP header, or the   |
|                 | sender port in the RSVP Filter spec object [RSVP].|
+-----------------+---------------------------------------------------+
| DestinationIP   | The destination IP address of the flow. Compared  |
|                 | to the destination IP header field, or the session|
|                 | address in the RSVP SESSION object [RSVP].        |
+-----------------+---------------------------------------------------+
| DestinationPort | The destination Port of a UDP/TCP flow. Compared  |
|                 | to the destination port field in the TCP/UDP      |
|                 | header, or the session port in the RSVP SESSION   |
|                 | object [RSVP].                                    |
+-----------------+---------------------------------------------------+
| IPProtocol      | The IP protocol number. Compared to the protocol  |
|                 | number in the IP header field or to the IP        |
|                 | protocol in the RSVP SESSION object [RSVP].       |
+-----------------+---------------------------------------------------+
| ToS             | The ToS variable is bound to the IP header ToS    |
|                 | byte.                                             |
+-----------------+---------------------------------------------------+
| DSCP            | The DSCP variable is bound to the IP header DSCP  |
|                 | byte or to the DCLASS RSVP object.                |
+-----------------+---------------------------------------------------+
| DestinationMAC  | The destination MAC address variable is bound the |
|                 | frame destination MAC address.                    |
+-----------------+---------------------------------------------------+
| SourceMAC       | The source MAC address variable is bound the frame|
|                 | source MAC address.                               |
+-----------------+---------------------------------------------------+

(Table continued in next page)

Snir, Ramberg, Strassner, Cohen         expires May 2001             47

(Table continued from the previous page)

+-----------------+---------------------------------------------------+
| 8021QID         | The VLAN ID is bound to the 802.1Q field of       |
|                 | the header.                                       |
+-----------------+---------------------------------------------------+
| Snap            | The snap protocol variable is bound to the        |
|                 | protocol type carried over SNAP encapsulation.    |
+-----------------+---------------------------------------------------+
| Ethertype       | The ethertype variable is bound to the frame      |
|                 | header ethertype value.                           |
+-----------------+---------------------------------------------------+
| Ssap            | The source sap variable is bound the frame header |
|                 | field containing the source SAP.                  |
+-----------------+---------------------------------------------------+
|Variable name    |                Logical binding                    |
+-----------------+---------------------------------------------------+
| Dsap            | The destination sap variable is bound the frame   |
|                 | header field containing the destination SAP.      |
+-----------------+---------------------------------------------------+
| Application     | The ID of the application that generated the flow.|
+-----------------+---------------------------------------------------+
| User            | The ID of the user that initiated the flow, or is |
|                 | designated as the flow owner.                     |
+-----------------+---------------------------------------------------+

        Table 1. Pre-defined Variables and Their Bindings

The definition of each predefined variable includes a standard name and
the allowed value types. The VariableHasDataValues association is used
to associate a variable object with a value object.

Following is a table of variable names and the value types defined
within this document that can be used together in a simple condition.
In reality, these are individual specializations of the general
association, PolicyValueConstraintsInVariable, that exists between the
PolicyVariable and PolicyValue classes and their subclasses. A given
variable can further restrict the values that can be combined with it
in a given condition. This is done by restricting the values that can
be held by the appropriate attributes of the PolicyValue class that is
used to represent the constraining object in the
PolicyValueConstraintsInVariable association. For example, by default,
a condition including a variable with the name "SourceIP" should also
include either a gpsPolicyIPv4AddrValue or a gpsPolicyIPv6AddrValue
value object. But, if there is a need to restrict values within a
condition to only IPv6 addresses of a certain range, then the
PolicyValueConstraintsInVariable association can be used to indicate
that only gpsPolicyIPv6Values of that range should be used. This is
done by placing this information into the qpIPv6AddrList attribute of
the gpsPolicyIPv6AddrValue class. The table below does not restrict new

Snir, Ramberg, Strassner, Cohen         expires May 2001             48

value classes defined elsewhere to be combined with variables defined
in this document.

+-----------------+---------------------------------------------------+
|Variable name    |              Allowed value types                  |
+-----------------+---------------------------------------------------+
| SourceIP        | gpsPolicyIPv4AddrValue, gpsPolicyIPv6AddrValue    |
+-----------------+---------------------------------------------------+
| SourcePort      | gpsPolicyIntegerValue                             |
+-----------------+---------------------------------------------------+
| DestinationIP   | gpsPolicyIPv4AddrValue, gpsPolicyIPv6AddrValue    |
+-----------------+---------------------------------------------------+
| DestinationPort | gpsPolicyIntegerValue                             |
+-----------------+---------------------------------------------------+
| IPProtocol      | gpsPolicyIntegerValue                             |
+-----------------+---------------------------------------------------+
| ToS             | gpsPolicyIntegerValue, gpsPolicyBitStringValue    |
+-----------------+---------------------------------------------------+
| DSCP            | gpsPolicyIntegerValue, gpsPolicyBitStringValue    |
+-----------------+---------------------------------------------------+
| DestinationMAC  | gpsPolicyMACAddrValue                             |
+-----------------+---------------------------------------------------+
| SourceMAC       | gpsPolicyMACAddrValue                             |
+-----------------+---------------------------------------------------+
| 8021QID         | gpsPolicyIntegerValue, gpsPolicyBitStringValue    |
+-----------------+---------------------------------------------------+
| Snap            | gpsPolicyIntegerValue                             |
+-----------------+---------------------------------------------------+
| Ethertype       | gpsPolicyIntegerValue                             |
+-----------------+---------------------------------------------------+
| Ssap            | gpsPolicyIntegerValue                             |
+-----------------+---------------------------------------------------+
| Dsap            | gpsPolicyIntegerValue                             |
+-----------------+---------------------------------------------------+
| Application     | gpsPolicyDNValue, gpsPolicyStringValue,           |
|                 | gpsPolicyAttributeValue                           |
+-----------------+---------------------------------------------------+
| User            | gpsPolicyDNValue, gpsPolicyStringValue,           |
|                 | gpsPolicyAttributeValue                           |
+-----------------+---------------------------------------------------+

       Table 2. Variable Names and Their Default Class Mappings

Note: Values are defined in section 4.5.

4.5 QoS Policy Value

The abstract class gpsPolicyValue is used for defining values and
constants used in policy conditions. Different value types are derived

Snir, Ramberg, Strassner, Cohen         expires May 2001             49

from this class and represent the various attributes required.
Extensions of the qpsPolicyValue class, defined in this document
provide a list of values for representing the basic network attribute.
Values can be used to represent constants as named values. Named values
could be kept in a reusable-object repository to be reused by multiple
conditions.
Examples of constants include well-known ports, well-known protocols,
server addresses, and other similar concepts.

The qpsPolicyValue classes define 3 basic types of values: scalars,
ranges and sets. For example, a well-known port number could be defined
using the gpsPolicyIntegerValue class, defining a single value (80 for
HTTP), a range (80-88), or a set (80, 82, 8080) of ports, respectively.
For details, please see the class definition for each value type in
section 8 of this document.

The QoS policy information model provide the following classes, all of
them extending the qpsPolicyValue class:

Classes for general use:
  GpsPolicyStringValue,
  gpsPolicyIntegerValue,
  gpsPolicyBitStringValue,
  gpsPolicyDNValue,
  gpsPolicyAttributeValue.

Classes for layer 3 Network values:
  gpsPolicyIPv4AddrValue,
  gpsPolicyIPv6AddrValue.

Classes for layer 2 Network values:
  gpsPolicyMACAddrValue.

For details, please see the class definition section of each value in
section 8 of this document.

4.6. PolicyTimePeriodCondition

The QoS Policy Information model uses the policyTimePeriodCondition
class (defined in [PCIM]) to define time based QoS policy rules. For
details, please see [PCIM], section 6.5.4.7. Actions

4.7 Actions

The QoS Policy information model defines actions to control QoS
enforcement in both the Integrated Service model as well as the
Differentiated Service model. Three types of actions are provided:
Signaling, Provisioning and Per-Hop-Behvior (PHB) actions.

Snir, Ramberg, Strassner, Cohen         expires May 2001             50

Signaling actions are used to provide policy control on RSVP
requests. Provisioning actions are used to enforce differentiated
service edge policies including marking, policing and shaping
operations. PHB actions are used to enforce per-hop behaviors across
the differentiated services domain.

A policy rule may aggregate zero or more policy actions. A QoS policy
rule extends this definition to include 0..n provisioning actions,
o..k PHB actions and 0..m signaling actions, each defined by an object
or objects describing the action(s) to perform. This extension is done
seamlessly by requiring all QoS action classes to be subclasses of the
PolicyAction class defined in [PCIM]. As such, all QoS action
subclasses automatically inherit the two relationships
(PolicyActionInPolicyRule and PolicyActionInPolicyRepository) that are
used by a policy rule to aggregate actions. Actions are ordered
(as opposed to rules, which are prioritized). The order of actions is
specified in [PCIM] using the ActionOrder property.

The property SequencedActions in the aggregating instance of a
PolicyRule (see section 6.3.6 of [PCIM]) defines whether a specified
action order is required, recommended, or of no significance.

Ordering semantics depend on how actions are represented. If actions
are represented as separate objects that are aggregated by PolicyRule,
the PolicyActionInPolicyRule aggregation can be used to express an
order. In this case, three attributes are used:

  - GroupComponent, which defines zero or more PolicyRules that can
    contain the same PolicyAction
  - PartComponent, which defines zero or more PolicyActions that are
    contained by a given policyRule
  - ActionOrder, which is an unsigned integer 'n' that indicates the
    relative position of an action in the sequence of actions that are
    associated with a given policy rule.  When 'n' is a positive
    integer, it indicates a place in the sequence of actions to be
    performed, with smaller integers indicating earlier positions in
    the sequence.  The special value '0' indicates "don't care".  If
    two or more actions have the same non-zero sequence number, they
    may be performed in any order, but they must all be performed at
    the appropriate place in the overall action sequence.

For actions defined explicitly in a subclass of policyRule, the
ordering mechanism must be specified in the subclass definition. Note
that QPIM does not define any policyRule subclasses. Instead, the QPIM
defines subclasses of policyCondition and policyAction to extend the
semantics of these classes.

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

Snir, Ramberg, Strassner, Cohen         expires May 2001             51

4.7.1 Provisioning Actions

QoS policy provisioning actions configure traffic conditioner
elements, as specified in [DIFF-SERV-ARCH]. Actions configure meters,
markers, shapers and droppers.

The qosPolicyPRAction class is a generic class that defines a
set of DiffServ actions that can be applied to an individual flow or
to a group of flows.

4.7.1.1  Meters

Meters measure the temporal properties of a stream of packets
selected by a classifier against a traffic profile.

A meter is associated with a provisioning action using the
PolicyMeterInAction association. A meter can be shared among
(i.e., used by) policy actions of different rules. If this is desired,
then the meter SHOULD reside in a reusable-object repository.

Meters measure flows matching the rule condition per flow, per
interface, per role within a device, per device or per role across all
devices. A per flow meter conceptually creates a new meter for each
flow, measuring each flow against the profile. A per interface meter
measures the aggregate set of flows matching the rule condition
forwarded via a single interface. Other options measure  traffic across
a set of interfaces assigned with the same role or across a whole
device.  The gpMeterScope property of the gpsPolicyMeter class is used
to determine which of the options above is selected.Meters are measured
against traffic profile modeled by the qosPolicyPRTrfcProf object.  The
association PolicyTrfcProfileInMeter is used to associate between a
meter and its traffic profile. The traffic profile used for
provisioning actions is a template containing rate and burst values,
modeled by the qosPolicyPRTrfcProf class. Traffic measured by a meter
can be classified as conforming traffic when the metered rate is below
the rate defined by the traffic profile, as excess traffic, when the
metered traffic is above the normal burst and below the Excess burst
size and violating traffic when rate is above the maximum excess burst.

The [DIFF-MIB] definition of a meter combines the traffic profile and a
meter as one unit. Separation of the concepts provides more flexibility
in reuse of traffic profiles across different rules. The [DIFF-MIB]
defines a two level meter, and provides means to combine two level
meters into more complex meters. In this document a three level traffic
profile is defined. This allows construction of both two level meters
as well as providing an easier definition for three level meters needed
for creating AF [AF] provisioning actions.

Snir, Ramberg, Strassner, Cohen         expires May 2001             52

A metered provisioning action using three level traffic profile
specifies the actions that should be enforced on excess and
violating traffic using the qpExcessAction and qpViolateAction
properties. A three level metered action that does not specify
an excess action implies that the excess traffic should be
treated as either violating or conforming traffic according to
an algorithm suitable for the enforcement of the rule. For
example, the final enforcement of such a rule may be the use of
a RED like behavior to determine whether traffic is conforming
or violating. A metered action with three level traffic profile
that specifies an exceed action but does not specify a violate
action implies that violate action is identical to the specified
exceed action.

A metered provisioning action allows additional flexibility by
linking actions that should be enforced only on traffic that either
conforms, exceeds or violates a meter. The associations
PolicyConformNextAction, PolicyExcessNextAction and
PolicyViolateNextAction define actions that are not associated with the
set of actions aggregated via the PolicyActionInPolicyRule aggregation
relationship (defined in [PCIM]), and are enforced only according to
the state of the meter.
Once an a action is enforced, all actions associated to it using
one of the next action association should be enforced prior to
other actions associated to the rule using the policyActionInPolicyRule
aggregation. For example, a rule may contain two actions A and B via
the aggregation policyActionInPolicyRule. The aggregation property
ActionOrder specifies that action A should be performed prior to action
B. Action A is a metered provisioning action that specifies that
exceeding traffic should be marked with DSCP 5 and associates a
third action, action C to be enforced only on exceeding traffic.
The order of enforcement of the three actions A, B and C is as follows:
First, action A is performed.
If traffic exceeds the traffic profile, C is performed. Action B
is always performed following A or C.

4.7.1.2  Markers
Markers are used to set the DS field of a packet to a particular DS
Code Point (DSCP), adding the marked packet to a particular DS
behavior aggregate. The marker may be configured to mark all packets
that it receives to a single DSCP, or may be configured to mark a
packet to one of a set of DSCPs used to select a PHB in a PHB group
according to the state of a meter. The marker may also be configured to
allow or not allow remarking of packets. When the marker changes the
DSCP in a packet, it is said to have "re-marked" the packet.
Provisioning actions can include both DSCP (re)marking as well as
802.1Q, Precedence and CoS marking. Precedence marking is required for
legacy devices, i.e., devices that do not support the full DSCP field
(6 bits) in the ToS byte of the IP packet header for IPv4. CoS marking
is required when crossing a link layer that supports QoS via CoS.

Snir, Ramberg, Strassner, Cohen         expires May 2001             53

The qosPolicyPRAction class contains a number of properties that can be
used to control the behavior of a marker. For example, the values of
the property qpExcessAction or qpViolateAction should be set
to 'remark' in order to model a marker that marks packets according to

a state of a meter. The properties qpExcessRemarkValue and
qpViolateMarkValue carries the marking values. The value type is
determined by the property qpMarkValueType. Both excess and violate
actions may be specified when measuring a meter against a three level
traffic profile. Please see section 8.3 for more detail.

4.7.1.3  Shapers

Shapers are used to delay some or all of the packets in a traffic
stream in order to bring the stream into compliance with a traffic
profile.  A shaper usually has a finite-sized buffer, and packets may
be discarded if there is not sufficient buffer space to hold the
delayed packets.

Again, the qosPolicyPRAction class contains a number of properties that
can be used to control the behavior of a shaper. For example, the value
of the property qpExcessAction or qpViolateAction should be set to
'shape' in order to model a shaper. Traffic should be shaped according
to a traffic profile defined by a qosPolicyPRTrfcProf class.

4.7.1.4. Droppers

Droppers are used to discard some or all of the packets in a traffic
Stream. Usually, this is done in order to bring the stream into
compliance with a traffic profile. This process is also known as
"policing" the stream.

Again, the qosPolicyPRAction class contains a number of properties that
can be used to control the behavior of a shaper. For example, the value
of the property  qpExcessAction or qpViolateAction should be set
to 'drop' to model a policer that drops packets according to the
traffic-profile specified by a qosPolicyPRTrfcProf class.

Snir, Ramberg, Strassner, Cohen         expires May 2001             54

4.7.1.5 Examples

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

Example 1:

Traffic flowing from one machine to another should be marked with DSCP
X to provide it with the correct per hop behavior. This traffic should
not exceed 1Mb/sec. Each flow should not exceed more than 300Kb/sec. A
single policy rule can be constructed to enforce this set of actions.
The condition can be built from two simple conditions matching the
source IP address of one machine and the destination of the other
machine. A set of three provisioning actions can be used in the
following form:

Action 1:
  Object: qosPolicyPRAction
   qpMarkValueType: DSCP
   qpMarkValue: X

Action 2:
  Object: qosPolicyPRAction
   PolicyMeterInAction association to: Meter-1
   qpExcessAction: Drop

Action 3:
  Object: qosPolicyPRAction
   PolicyMeterInAction association to: Meter-2
   qpExcessAction: Drop

The meters and traffic profile can take the form of:

Meter 1:
  Object: GpsPolicyMeter
    gpMeterScope: interface
    PolicyTrfcProfileInMeter association to: Profile-1

Meter 2:
  Object: GpsPolicyMeter
    gpMeterScope: flow
    PolicyTrfcProfileInMeter association to: Profile-2

Profile 1:
  Object: QosPolicyPRTrfcProf
    QpPRRate: 1Mb/sec
    QpPRNormalBurst: 1000 bytes

Snir, Ramberg, Strassner, Cohen         expires May 2001             55

Profile 2:

  Object: QosPolicyPRTrfcProf
    QpPRRate: 300Kb/sec
    QpPRNormalBurst: 1000 bytes

Example 2: Conditioning traffic

Some PHBs require the successive application of a set of traffic
conditioners to properly process the traffic. An example of a policy
with two levels of traffic conditioning is the following:

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

This policy rule can be modeled by using two actions. The first action
measures the traffic against the first profile. If the traffic is
within this profile, then the traffic is (re)marked with a DSCP of 24.
If the traffic is out of profile, then the subsequent action measures
the traffic against the second higher profile. If the traffic is within
this profile, then the traffic is (re)marked with a DSCP of 25.
Otherwise, the traffic is out of profile, and it will be dropped.

In this way, an arbitrary cascading of traffic conditioners can be
constructed, where each action measures traffic against a higher
traffic profile and change only the out-of-profile action as required.

This policy rule can be build in another way using associations to
actions that should be performed on exceeding or violating traffic. In
this way, the first action measures traffic according to the first
traffic profile, and reference the second action using
policyExcessNextAction association. The second action than base its
decision whether to discard or remark traffic according to the higher
traffic profile.

Snir, Ramberg, Strassner, Cohen         expires May 2001             56

4.7.2 Per-Hop-Behavior Actions

A Per-Hop-Behavior (PHB) is a description of the externally observable
forwarding behavior of a DS node applied to a particular DS behavior
aggregate [DIFF-SERV-ARCH]. The approach taken here is that a PHB
action specifies both observable forwarding behavior (i.e., loss, delay
,jitter) as well as specifying the buffer and bandwidth resources that
needs to be allocated to each of the behavior aggregates in order to
achieve these observables. That is, a rule with a set of PHB actions
can specify that an EF packet must not be delayed more than 20 msec in
each hop. The same rule may also specify that that EF packets needs to
be treated with preemptive forwarding (priority queuing), and specify
the maximal bandwidth for this class as well as the maximal buffer
resources. PHB actions can therefore be used to both represent the
final requirements from PHBs as well as provide enough detail to be
able to map the PHB actions into a set of configuration parameters to
configures queues, schedulers, droppers and other mechanism. In
particular, the PHB actions includes attributes that are directly
mapped to the differential service MIB configuration scheme
[DUFF-MIB].

Description of the properties of the PHB Action that are directly
mapped to the diffserv MIB [DIFF-MIB] are aligned with the
definition in the MIB. We refer to the MIB for a thorough discussion of
these properties and for an explanation of why this minimal set of
parameters where chosen to describe each mechanism.

4.7.2.1 Bandwidth and Delay Management

PHB actions allows specifying the minimal bandwidth that should be
reserved for a class of traffic. The property qpMinBandwidth can be
specified either in Kb/sec or in percentage of the total available
bandwidth. The property qpBandwidthValueType is used to determine
whether percentage of fixed values are used.
The property qpForwardingPriority is used whenever preemptive
forwarding is required. A policy rule that defines EF PHB should
indicate a non zero forwarding priority. QpForwardingPriority holds an
integer value to enable multiple levels of preemptive forwarding where
higher values specifies higher priority.
The property qpMaxBandwidth specifies the maximal bandwidth that should
be allocated to a class of traffic. This property may be specified in
PHB actions with non-zero forwarding priority in order to guard against
starvation of other PHBs.
The properties qpMaxDelay and qpMaxJitter specifies limits on the per
hop delay and jitter in milliseconds for any given packet within a
traffic class. Enforcement of the maximal delay and jitter may require
use of preemptive forwarding as well as minimal and maximal bandwidth
controls. Enforcement of low max delay and jitter values may also
require fragmentation and interleave mechanisms over low speed links.

Snir, Ramberg, Strassner, Cohen         expires May 2001             57

4.7.2.2 Congestion Control and Buffer Management

PHB actions provide buffer resources and congestion control
management.
The property qpDropAlgorithm can be used to select either tail-
drop, head-drop or random-drop algorithms. The set of maximal and
minimal threshold values can be specified as well, either in bytes, in
packets or in percentage of the total available buffers. Two additional
properties are provided for controlling random drop, as explained in
[DIFF-MIB]. The properties are qpRandomDropInvWeight and
qpRandomDropProbMax that control the RED weight factor and worst
probability, see [DIFF-MIB] for more details.

4.7.2.3 Queues and PHB groups

PHB actions provide control on the way packets that match a rule
should be queued for forwarding. The qosPolicyQueue class specify the
queuing properties of the PHB action. Two PHB actions, used within two
different rules may reference the same qosPolicyQueue object,
indicating that flows matched by these rules should use the same
queue. For example, rules specifying PHB actions for AF11 and
AF12 [AF] PHBs should indicate that AF11 and AF12 belong to the
same PHB group and should be queued together to avoid packet reordering
affects.
This can be achieved by reusing a PHB action within the AF1x
rules that specify the bandwidth and delay properties as well as
indicating that the same queue must be used.

The association PolicyQueueInPHBAction associates between a PHB
action and a qosPolicyQueue.

The qosPolicyQueue class carries all properties described in the
bandwidth and delay management section. The Boolean property
qpFairQueue indicates whether flows should have a fair chance to
be forwarded without drop or delay. A way to enforce a PHB
action with qpFairQueue set to TRUE would be to build a queue
per flow for the class of traffic specified in the rule's
filter. In this way interactive flows like terminal access will
not be queued behind a bursty ftp flow and therefore have a reasonable
response time.

Schedulers and Queue sets are not modeled directly in the QoS
Policy Information model. Nevertheless, hierarchical policy rules may
require enforcement using more than a single scheduler or queue set.
This is explained in the next section.

Snir, Ramberg, Strassner, Cohen         expires May 2001             58

4.7.2.4 Using Hierarchical policies

The ability to define sub rules within rules allow for definition of
hierarchical policies. Hierarchical policies form a hierarchy of
classification and specification of actions for each level of the
hierarchy. For example, a rule may specify the actions that
should be performed on all UDP traffic, while its sub rules specify the
actions that should be performed on various UDP applications. Rules
specified higher in the hierarchy also apply to all sub rules and are
logically performed first [see Section 5.3]. Bandwidth and Buffer
resources specified in relative terms (percentage of total resources)
relate to the resources allocated higher in the hierarchy. For example,
bandwidth resources can be shared between UDP applications summing up
to 100% of the resources allocated to UDP traffic.
Hierarchical policies defining PHB actions may therefore require
hierarchical scheduler for correct enforcement.

4.7.2.5 Examples

This example provides a set of rules that specify PHBs enforced within
a Differential Service Domain. In this example the PHBs selected to be
enforced within the domain are EF, AF11 and AF12 and Best Effort. There
may be alternate ways to construct policy rules to represent these
PHBs.

The set of rules takes the form:

If (EF) than do EF actions
If (AF11) than do AF11 actions
If (AF12) than do AF12 actions
If (default) than do Default actions.

EF, AF11, AF12 represent conditions that filter traffic according to
DSCP values. These filters are represented using either a reusable or
ad-hoc policy conditions. The default rule uses a 'catch all' filter
and specifies the Best Effort rules.
The set of rules reside in a gpsPolicyGroup.
The decision strategy is defined to be 'FIRST MATCH'.

The objects below specifies the set of actions used to describe each of
the PHBs:

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

Snir, Ramberg, Strassner, Cohen         expires May 2001             59

QosPolicyPHBAction  AF11:

  PolicyQueueInPHBAction association to: AF1xq

  QpDropAlgorithm: random

  qpDropThresholdValueType packet

  qpDropMinThreshold:  4pckts
  qpDropMaxThreshold:  20pckts

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

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

AF11 and AF12 share the same queue, indicating that they belong to the
same PHB group. Following are the qosPolicyQueue objects defined in
this example:

qosPolicyQueue BEq:
  qpBandwidthValueType
  qpFairQueue: TRUE

qosPolicyQueue AF1xq:
  qpBandwidthValueType: kb/sec
  qpMinBandwidth: 512Kb/sec

qosPolicyQueue EFq:
  qpForwardingPriority: 1
  qpBandwidthValueType: %
  qpMaxBandwidth  50%
  qpFairQueue: FALSE

AF1x actions are associated with the same qosPolicyQueue
indicating that all AF rules performing this action belong to the same
PHB group. The AF1x queue specify the minimal bandwidth that should be
allocated to this PHB group. AF11 and AF12 actions indicate the maximal
and minimal thresholds for AF1x packets.

Snir, Ramberg, Strassner, Cohen         expires May 2001             60

qpForwardingPriority property of the EF action specify that

preemptive forwarding is required for this PHB. qpMaxBandwidth

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

Random Drop is enforced by AF and BE PHBs. EF PHB uses tail drop
as the applications using EF are supposed to be UDP based and rate
controlled and will not benefit from a random dropper.
The set of minimal and maximal thresholds in this example are

defined in packets. The remaining random drop parameters are not
specified and left for the enforcer defaults.
QpFairQueue property indicates that Best Effort traffic should
provide fairness among flows.

4.7.3 Signaling Actions

RSVP is the standard protocol used for requesting QoS resources
>From the network. The QoS policy signaling actions defined in this
document can be used to control whether to admit or reject an RSVP
request based on the request's attributes and the specified policy. The
QoS policy signaling actions allow modifying the content and forwarding
behavior of RSVP requests.

The signaling policies control the admission priority of
resources and provide preemption support. Mapping of integrated
services signaled by RSVP to differential services in a core network is
controlled by signaling policies as well, by assigning appropriate
DSCPs to flows on the boundary of the differential service core.

The set of policies specified allow a policy server (policy
Decision point) to instruct an RSVP node (policy enforcement point) to
Enforce all set of controls defined in the COPS protocol specification.
The actions defined here follow the different decision types of the
COPS protocol [COPS] and the guidelines for its use in an RSVP
Environment [COPS-RSVP]. The basic decision to accept or deny a
reservation is modeled by the qosPolicyRSVPAction class. Additional
control is provided through the use of two classes. The content and
forwarding behavior of RSVP flows is controlled by the
osPolicyRSVPSignalCtrlAction class. The qosPolicyRSVPInstallAction
class controls the processing of RSVP requests and accompanying flows
within the RSVP node itself.

QoS signaling policies does not require a policy server for
decision making. A local policy module can use signaling policies for
making local decisions or use either COPS or any other outsourcing
protocol for enforcement of these signaling policies.

Snir, Ramberg, Strassner, Cohen         expires May 2001             61

The qosPolicyRSVPAction action includes a specification of the

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

parameters can be specified:

  1. Direction - in/out
  2. Message type - Path/Resv/PathErr/ResvErr
  3. Service type - Guaranteed Service / Controlled Load / Null
  4. Service style - SE, WF, FF

The direction refers to the direction of the flow, hence the
Direction of the RSVP Path messages. Therefore, out-direction policies
Control outgoing Path messages as well as incoming Resv messages.

4.7.3.1 Admission Control

The basic decision modeled by the qosPolicyRSVPAction class is
whether to admit or reject the RSVP request. The decision can be
based on comparison of the request TSPEC or FLOWSPEC against a meter.
This allows basing an admission decision both on the properties
of the reservation request itself as well as on the current
temporal resource allocation.
Meters allow enforcement of policies of the form: "Allow
allocation of resource via RSVP for flows coming from subnet x
up to a total aggregated rate of 256kb/sec". The meter tracks
the current state of resource allocated to subnet x, and
compares any new request for resources against a 256Kb/sec
traffic profile. A meter can be reused by two signaling actions
of two rules, indicating that the this meter should measure the
aggregated resource allocation for both rules.

Note that if a traffic profile is not provided, it is implicitly
assumed that the RSVP request should be accepted. Rejecting all RSVP
requests matching the condition is specified by a zero valued traffic
profile.

4.7.3.2 Forwarding Behavior

The qosPolicyRSVPInstallAction class provides control on the way
resource allocation requests are handles within the RSVP node,
without changing the content of the RSVP messages themselves. In
particular it allows instructing the RSVP node to:

   1. Set the DSCP value of the flows for which the reservation
      was made.
   2. Set the preemption priority of the RSVP request.

Setting the DSCP of the flow on the edge of a differential
service core allow provisioning of QoS, end-to-end, over mixed
integrated and differential service clouds.

Snir, Ramberg, Strassner, Cohen         expires May 2001             62

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

priority [RSVP_PREEMP] allows the RSVP node to decide which of its
reservations should be admitted, and when to make room for a newer
reservation by preempting an already installed one.

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

4.7.3.3 Signaling Control

The qosPolicyRSVPSignalCtrlAction class provides control on the
content of RSVP signaling message and their processing rules. In
particular it may include the following controls:

   1. Replace/add DCLASS object in RSVP message.
   2. Replace/add Preemption priority object in RSVP message.
   3. Trigger an error/warning RSVP message.
   4. Instruct the RSVP node to proxy RSVP message as if sent by
      the RSVP end nodes.

Modifying the content of messages can be enforced using a COPS
replacement decision. This class should be extended to cover other
object replacements and, in particular, replacement of policy objects.

Triggering errors and warnings is important in scenarios when there is
a need to notify the end nodes that their reservation is about to
expire and various other information.

There are scenarios in which it makes sense not to carry RSVP requests
end-to-end. An RSVP node on the boundary of a differential service core
may map the RSVP request to specific PHB by setting the DSCP on the
flow packets, without forwarding the Path message downstream. Still,
this RSVP node may send back an RSVP Resv message as if the receiver
has sent it, to complete the RSVP cycle.

4.7.3.4 Examples

Below is an example on how this document models rules specifying
a set of signaling actions:
Admit RSVP reservation requests for VoIP traffic with FF style
only if the request asks for less the 64Kb/sec. Do not allow
more than 5 VoIP reservations to be admitted on any single
interface. In this examples two actions are used to represent
the required policy.

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

Snir, Ramberg, Strassner, Cohen         expires May 2001             63

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

The two meters specify the different scopes of each of the meters and a
traffic profile. The first traffic profile limits the maximal resources
allocated to a single request while the second traffic profile limits
the number of reservations admitted at any given time.

gpsPolicyMeter Meter-1:
  qpRSVPMeterScope: flow
  PolicyTrfcProfileInMeter association to: Prof-1

gpsPolicyMeter Meter-1:
  qpRSVPMeterScope: interface
  PolicyTrfcProfileInMeter association to: Prof-2

qosPolicyRSVPTrfcProf Prof-1:
  qpRSVPTokenRate: 64kb/sec

qosPolicyRSVPTrfcProf Prof-2:
 qpRSVPSessionNum: 5

The various attributes of RSVP traffic profiles are described in the
next section.

4.8. Meters and Traffic Profiles

Meters measure the a temporal state of a flow or a set of flows
against a traffic profile. In this document meters are modeled
by psPolicyMeter class, while traffic profiles are modeled by
gpsPolicyTrfcProf class. The association PolicyTrfcProfileInMeter
models the relation between a meter and a traffic profile. Two traffic
profiles are derived from the abstract class gpsPolicyTrfcProf.
Provisioning traffic profiles carry rate and burst parameters to be
compared with flow meters. RSVP traffic profiles are compared with
RSVPTSPEC and FLOWSPEC parameters, and with meters aggregating the
temporal state of admitted RSVP reservations and states.

Snir, Ramberg, Strassner, Cohen         expires May 2001             64

4.8.1. Provisioning traffic profiles

Shaping, policing and remarking provisioning actions compare a
provisioning traffic profile against a meter. The provisioning traffic
profile is a template containing rate and burst values, modeled
by the qosPolicyPRTrfcProf class.

The qosPolicyPRTrfcProf class includes the following properties:

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

Rate determines the long-term average transmission rate. Traffic
That falls under this rate will always conform. The normal burst size
determines how large traffic bursts can be before some traffic
exceeds the traffic profile. The Excess Burst size determines how large
traffic bursts can be before all traffic exceeds the rate limit.
Traffic
that falls between the normal burst size and the Excess Burst size
exceeds the traffic profile with a probability that increases as the
burst size increases. This provides a Random Discard mechanism for
policers, markers and shapers.

Excess burst size SHOULD be greater than or equal to the normal
burst size. If the excess burst size is not specified, it is assumed
that excess burst size is equal to the normal burst size. In this
case, burst larger than the normal burst size will always be counted
as out-of-profile packets.

Snir, Ramberg, Strassner, Cohen         expires May 2001             65

4.8.2.  RSVP traffic profiles

RSVP signaling QoS policy can condition the decision whether to accept
or deny an RSVP request based on the traffic specification of the flow
(TSPEC) or the amount of QoS resources requested (FLOWSPEC). The TSPEC
and FLOWSPEC objects are either compared directly with a traffic
profile, or aggregated to a meter that measures the temporal admitted
RSVP states and than compared to the traffic specification. The

qosPolicyRSVPTrfcProf class models such a traffic profile. The
qosPolicyRSVPTrfcProf class has the following properties:

   1. Token Rate (r) measured in bits/sec.
   2. Peak Rate (p) measured in bits/sec.
   3. Bucket Size (b) measured in bytes.
   4. Min Policed unit (m) measured in bytes.
   5. Max packet size (M) measured in bytes.
   6. Resv Rate (R) measured in bits/sec.
   7. Slack term (s) measured in microseconds.
   8. Number of sessions.

The first 5 parameters are the traffic specification parameters used in
the integrated service architecture. These parameters are used to
define a sender TSPEC as well as FLOWSPEC for the Controlled Load
service [CL]. For a definition and full explanation of their meaning,
please refer to [RSVP-IS]. Parameters 6 and 7 are the additional
parameters used for specification of the Guaranteed Service FLOWSPEC
[GS]. The last parameter is used to specify the maximum number of
allowed RSVP sessions. This provides an easy way to limit the number of
admitted RSVP requests without requiring pre-knowledge of the
aggregated rates requested.

A partial order is defined between TSPECs (and FLOWSPECs). A TSPEC A is
larger than TSPEC B if and only if rA>rB, pA>pB, bA>bB, mA<mB and
MA>MB. A TSPEC measured against a traffic profile uses the same
ordering rule. An RSVP message is accepted only if its TSPEC (FLOWSPEC)
is either smaller or equal to the traffic profile. Only parameters
specified in the traffic profile are compared.

The GS FLOWSPEC is also compared against the rate R and the slack term
S. R should not be larger than the traffic profile R parameter, while
the FLOWSPEC slack term should not be smaller than that specified in
the slack term.

TSPECs as well as FLOWSPECs can be added. The sum of two TSPECs is
computed by summing the rate r, the peak rate p, the bucket size b, and
by taking the minimum of min policed unit m and the maximum of the max
packet size M. GS FLOWSPECs are summed by adding the Resv rate and
minimizing the slack term s. These rules are used to compute a meter
that measures the temporal state of admitted RSVP states. The meter is
than compared with the traffic profile specified in the signaling

Snir, Ramberg, Strassner, Cohen         expires May 2001             66

policy using the same rules for comparison of TSPECs (FLOWSPECs) to a
traffic profile.

5. Decision strategy

Section 5.1 discusses how policy rules are organized into containers so
that decision strategies can be applied to groups of policy rules.
Section 5.2 defines two different decision strategies. Section 5.3
provides examples to illustrate how the different decision strategies
affect the policy rules they operate on.

5.1 Organizing the Application of Decision Strategies

This document recommends the following approach to be used by policy
servers and other policy decision points in the network for QoS
applications. The set of policies to be used is managed by first
assigning them to their respective policy domains or reusable-object
repositories. The policy rules will then be grouped into a set of
gpsPolicyGroup groups. The organization of these gpsPolicyGroup groups
is to be used to reflect any administrative, geographical, or other
constraints that should be enforced by the policy system. This set of
gpsPolicyGroup groups is used to partition behavior in the different
QoS policy domains.

The goal is to ensure that different policy servers using the same
group of policy rules will enforce consistent behavior. That is, they
will treat the conditions of the rules in the same way, and execute the
same actions in the same order. Therefore, the priority of the policy
rules must be pre-defined and the decision strategy implemented by each
different policy server must be defined explicitly.

The decision strategy is defined per domain and can be overridden by
any PolicyDomain or gpsPolicyGroup instances that are contained within
the domain. When a policy decision point evaluates a set of rules, it
implements the decision strategy defined in each PolicyDomain or
gpsPolicyGroup instance for that set of rules. Nested PolicyDomain or
gpsPolicyGroup instances can override the decision strategy of the
PolicyDomain or gpsPolicyGroup instances that contain them.

The order of decision making for policy rules is based on the rule
priority of PCIM. However, this rule priority has been extended in two
important ways. The first is that nested rules can be defined. For
nested rules, the contained, or innermost, rule has a higher priority
than the containing, or outermost, rule. The second extension is that
the gpsPolicyGroup class is given its own priority. This enables it to
be treated in the same way that a PolicyRule is. In fact, this is
purposely done so that the priority of a PolicyRule can be directly
compared to the priority of a gpsPolicyGroup. The comparison is done
for all instances at the same nesting level.
Notice that nested rules are affected in the following way from their
containing rules:

Snir, Ramberg, Strassner, Cohen         expires May 2001             67

1. The containing rule's condition list is ANDed to the sub-rule
   condition list.
2. The containing rule actions are added to the sub-rule action list
   and performed in the appropriate order BEFORE the sub-rule actions.

The following example helps clarify rule and sub-rule policy
application. Rule 1.1 is nested within Rule 1 in the following form:

  Rule 1: If (Condition A) then Action A
   |
   +--- Rule 1.1 If (Condition B) then Action B

These two rules can be ordered in a non hierarchical form and enforced
as follows:

  Rule 1.1 If (Condition A AND Condition B) then Action A, Action B
  Rule 1: If (Condition A) then Action A

Replacing the conditions and actions with concrete values:

  Rule 1: If (UDP) then guarantee 50% BW.
   |
   +--- Rule 1.1 If (TFTP) then Mark to DSCP=3

Leads to:

  Rule 1.1 IF (UDP AND TFTP)
     THEN guarantee 50% BW sharing queue x, Mark DSCP=3
  Rule 1: IF (UDP)
     THEN guarantee 50% BW sharing queue x.

5.2  Decision Strategies

Many different types of decision strategies can be defined. This
section defines two different decision strategies:

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

5.2.1. First Match Decision Strategy

The first match decision strategy is defined as a process that
evaluates the policy rules in the defined order, evaluating the
conditions of each rule, until a condition is evaluated to TRUE. The
rule's actions are then applied and the process of decision-making is
terminated.

5.2.2. Match All Decision Strategy

The match all decision strategy is defined as first scanning the
complete set of rules according to their defined order of priority and
then applying the actions of each rule that satisfies the rule's
conditions. This matching strategy may in many cases mean that a

Snir, Ramberg, Strassner, Cohen         expires May 2001             68

number of rules may satisfy the same set terms of conditions, average rate 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 other characteristics.
Associations represent relationships among instances of QoS
systems must provide proprietary conflict detection and avoidance or
resolution mechanisms to use this different
classes or any type of decision strategy that
allows the execution of more than one rule for a given condition.

5.3. Decision Strategy example

This section demonstrates both decision strategies and rule
prioritization. The rules to be evaluated are shown in Figure 4 below.

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

       Figure 4: Decision Strategy example

This figure illustrates two extensions to PCIM. The first is that a
special type of PolicyGroup, same class. For example, the gpsPolicyGroup, can be assigned association
QoSPolicyViolateAction links a
priority and have its priority compared to other PolicyRules and
gpsPolicyGroups. The second is rule nesting, as illustrated certain restriction on traffic
(represented by Rule 3
and Rule 4.
The order an instance of rule processing for the example above is:

  1. Rule1 (higher priority between Rule1, PolicyContainer1 and Rule3
  2. Rule1.2 (both Rule 1.1 and 1.2 will QoSPolicyPoliceAction class) to an
action to be considered next, because taken when the priority of PolicyContainer1 restriction is higher than the priority of
     Rule 3; Rule 1.2 executes next because its priority violated.

6.	QPIM is higher
     than the priority of Rule1.1)
  3. Rule1.1 (because its container has a higher priority than Rule3
  4. Rule4 (because it abstract. The model is nested in Rule 3)
  5. Rule3

If aimed at the decision strategy formalization of humanly
expressed business QoS policies. For example, QPIM provides the domain is 'first-match' and it is not
overridden by PolicyContainer1, the decision process will stop once means
of expressing formally a
rule's condition is matched.

Snir, Ramberg, Strassner, Cohen         expires May 2001             69

If business policy that states: "In our network,
IP telephony should receive the decision strategy same service quality as that of our
legacy phone systems". QPIM provides the domain is 'match-all' and it is not
overridden by PolicyContainerr1, topmost link from the match all decision process will
run over all rules according
abstract business policy to the order above.

If the decision strategy of concrete device implementation by
expressing the domain is 'first-match' and abstract business policy in high-level networking
terms. QPIM compliant tools can be built to further concretize the
decision process of PolicyContainer1 is match all, Rule1 will
high-level QoS policies defined in QPIM terms so that actual network
elements (PEPs) can be
evaluated first. If its condition matches, configured to enforce the decision process stops.
Else, both Rules 1.1 and 1.2 will abstract business
policy.

7.	QPIM is QoS technology-agnostic, as it assumes no particular mechanism
(e.g., class-based weighted fair queuing) for policy enforcement. For
example, a certain policy may require that traffic adhere to a given
traffic profile. The traffic profile itself can be evaluated (because represented by an
instance of the priority QosPolicyTrfcProf class. The properties of the named container is higher than profile
class may include an attribute representing the priority average rate of Rule 3).
traffic in units of bits per second. However,
since QPIM neither describes
nor mandates a mechanism to perform the decision strategy measuring mechanism itself.
Specifying such mechanisms is overridden in the named container, one
or both realm of Rule 1.1 and Rule 1.2 will network modeling, not
policy modeling.

Though a particular QoS mechanism (e.g., class-based weighted fair
queuing) is generic to many types of devices, individual devices may
implement this generic mechanism differently. This necessitates a
device-independent view of controlling QoS mechanisms, which is
precisely what QPIM is intended for. A single QPIM policy can be executed if their conditions
match. If one or both
translated into different configurations of these rules in the named container
match, the decision process stops. Else Rules 3 different devices. For
example, a network interface card that can be configured to implement
several output queues and 4 will be evaluated
using 'first-match' decision strategy.

If the decision strategy of the domain is 'match-all' assign size and the decision
process bandwidth allocation
parameters to each of PolicyContainer1 them is first match, a concrete element whose configuration
can be controlled with QPIM policies.

Snir, Ramberg, Strassner, Cohen          expires November 2001          9

8.	QPIM adheres to and interprets the decision process will
evaluate Rule1 two predominant QoS paradigms:
Differentiated (DiffServ) Services and continue to evaluate Integrated Services (IntServ).
While both DiffServ and IntServ inherently model technology, the PolicyContainer1 rules
as well as Rule 3. Rules 1.1
mechanisms implementing those technologies are not specified and 1.2 will be evaluated using first
match strategy. The decision process continues are
left to evaluate rules 3 the implementer's interpretation. DiffServ and
4 according IntServ are
described in [DIFFSERV] and [INTSERV], respectively. The term RSVP
refers to a 'match-all' decision strategy.

6. Per Hop Behavior

A per-hop behavior (PHB) protocol developed to implement IntServ [RSVP]. The terms
IntServ and RSVP are sometime used interchangeably.

9.	QPIM is a description of network-end-to-end model. This means that QPIM policies can
describe the externally
observable forwarding behavior QoS allocated to traffic throughout the network. QPIM
does not represent explicitly network topological concepts. Section
4.6 of [PCIMe] explains a DS node applied role based mechanism that can be used for
mapping policies to PEPs. Neither [PCIM], [PCIMe] nor [QPIM] require a
particular DS
Behavior aggregate. A PHB topological view of the network in order to express
abstract policy.

1.3.  QPIM and Other Published Standards

QPIM makes extensive use of the concepts and constructs that are
introduced by [PCIM] and [PCIMe]. The entire QPIM class hierarchy is selected at a node
derived from [PCIM] and [PCIMe] classes. The concepts of policy, policy
groups, policy conditions, reusable objects values and variables are used
in QPIM directly. QPIM only introduces extensions where QoS actions,
values and variables are necessary to add QoS specific semantics to the
framework defined by [PCIM] and [PCIMe].

By modeling the DSCP contained
in a received packet. A set information of PHBs is enforced on a both predominant QoS domain.
The set of PHBs share buffer paradigms, DiffServ
and scheduler resources among them. IntServ, QPIM provides unifies the means for defining a set of PHBs per qos
domain by definition of two methodologies using a gpsPolicyGroup that includes single class
inheritance tree, thus allowing a set of
PHB rules. Each of this rules would classify packets based on DSCP
value  and single context for thinking about QoS
policy.

Companion documents (e.g., [QoSSCHEMA]) define the action mapping of QPIM's
classes to be performed on specific data models (schemata). For example, [QoSSCHEMA]
defines how to map the data in this qos Class.
PHB sets information model to a form that can
be defined stored in a directory that uses LDAPv3 as reusable objects its access protocol.

QPIM adheres to terminology as defined in the policy
reusable-object repository [TERMS].

QPIM intentionally avoids references to allow different domains documents that present network
models. A network model is the OBJECT of policy. QPIM models the SUBJECT
of policy. The latter distinction makes it inappropriate for QPIM to share
model the same per hop behavior. actual network. An example for network modeling is available in
[QDDIM], a document that models QoS device data path and capabilities.

Snir, Ramberg, Strassner, Cohen          expires May November 2001             70

7. QoS Policy         10

2.  Class Hierarchies

2.1.  Inheritance

The following diagram illustrates the class Hierarchy

QPIM's inheritance hierarchy for is rooted in [PCIM] and [PCIMe]. Figures 1
and 2 depict the
QPIM. Relevant classes from QPIM inheritance hierarchy while noting its
relationships to [PCIM] and [PCIMe] classes. Figure 1 shows the PCIM are also included for
completeness:

     top QPIM
inheritance hierarchy,.

 [ManagedElement] (abstract, PCIM)
   |
   +--Policy (abstract, PCIM)
   |  |
   |  +---PolicyAction (abstract, PCIM)
   |  |     |
   |  |     +---SimplePolicyAction (PCIMe)
   |  |     |   |
   |  |     |   +---QoSPolicyRSVPSimpleAction (QPIM)
   |  |     |
   |  |     +---QoSPolicyDiscardAction (QPIM)
   |  |     |
   |  |     +---QoSPolicyAdmissionAction (abstract, QPIM)
   |  |     |   |
   |  |     |   +---QoSPolicyPoliceAction (QPIM)
   |
      +--policy (abstract, [PCIM])  |     |   |   +--policyGroup ([PCIM])
   |  |     |   +---QoSPolicyShapeActionAction (QPIM)
   |  |    +--qosPolicyDomain     |   |
   |  |     |    +--gpsPolicyGroup   +---QoSPolicyRSVPAdmissionAction (QPIM)
   |  |     |   +--policyRule ([PCIM])
   |  |     +---QosPolicyPHBAction (abstract, QPIM)
   |  |         |
   |   +--policyCondition ([PCIM])  |         +---QoSPolicyBandwidthAction (QPIM)
   |  |         |
   |    +--policyTimePeriodCondition ([PCIM])  |         +---QoSPolicyCongestionControlAction (QPIM)
   |  |
   |  +---QosPolicyTrfcProf (abstract, QPIM)
   |    +--vendorPolicyCondition ([PCIM])  |   |
   |  |   +---QosPolicyTokenBucketTrfcProf (QPIM)
   |    +--gpsPolicySimpleCondition  |   |
   |  |   +---QosPolicyIntServTrfcProf (QPIM)
   |    +--gpsPolicyCompoundCondition  |

(continued on the next page)

Snir, Ramberg, Strassner, Cohen          expires November 2001         11

(continued from the previous page)

[ManagedElement] (abstract, PCIM, repeated for convenience)
   |
   +--Policy (abstract, PCIM, repeated for convenience)
   |   +--policyAction ([PCIM])  |
   |  +---PolicyVariable (abstract, PCIMe)
   |  |   |    +--vendorPolicyAction ([PCIM])
   |  |    +-- qosPolicyPRAction   +---PolicyImplicitVariable (abstract, PCIMe)
   |  |       |
   |  |    +-- qosPolicyPHBAction       +---QoSPolicyRSVPVariable (abstract, QPIM)
   |  |           |
   |  |    +-- qosPolicyRSVPAction           +---QoSPolicyRSVPSourceIPv4Variable (QPIM)
   |  |           |
   |  |        +-- qosPolicyRSVPSignalCtrlAction           +---QoSPolicyRSVPDestinationIPv4Variable (QPIM)
   |  |           |
   |  |        +-- qosPolicyRSVPInstallAction           +---QoSPolicyRSVPSourceIPv6Variable (QPIM)
   |  |           |   +--gpsPolicyVariable
   |  |           +---QoSPolicyRSVPDestinationIPv6Variable (QPIM)
   |   +--gpsPolicyValue(abstract)  |           |
   |  |           +---QoSPolicyRSVPSourcePortVariable (QPIM)
   |   +--gpsPolicyIPv4AddrValue  |           |
   |  |           +---QoSPolicyRSVPDestinationPortVariable (QPIM)
   |   +--gpsPolicyIPv6AddrValue  |           |
   |  |           +---QoSPolicyRSVPIPProtocolVariable (QPIM)
   |  |

 (diagram continued in next page)

Snir, Ramberg, Strassner, Cohen         expires May 2001             71

(continued from the previous page)
     top           |
   |   +--gpsPolicyMACAddrValue  |           +---QoSPolicyRSVPIPVersionVariable (QPIM)
   |  |           |
   |   +--gpsPolicyStringValue  |           +---QoSPolicyRSVPDCLASSVariable (QPIM)
   |  |           |
   |   +--gpsPolicyBitStringValue  |           +---QoSPolicyRSVPStyleVariable (QPIM)
   |  |           |
      +--policy (abstract, [PCIM])
   |  |           +---QoSPolicyRSVPDIntServVariable (QPIM)
   |   +--gpsPolicyValue (abstract)  |           |
   |  |           +---QoSPolicyRSVPMessageTypeVariable (QPIM)
   |   +--gpsPolicyDNValue  |           |
   |  |           +---QoSPolicyRSVPPreemptionPriorityVariable (QPIM)
   |   +--gpsPolicyAttributeValue  |           |
   |  |           +---QoSPolicyRSVPPreemptionDefPriorityVariable (QPIM)
   |   +--gpsPolicyIntegerValue  |           |
   |   +-- gpsPolicyMeter  |           +---QoSPolicyRSVPUserVariable (QPIM)
   |  |   +-- qosPolicyQueue           |
   |  |   +-- gpsPolicyTrfcProf           +---QoSPolicyRSVPApplicationVariable (QPIM)
   |  |           |       +-- qosPolicyPRTrfcProf
   |  |           +---QoSPolicyRSVPAuthMethodVariable (QPIM)
   |       +-- qosPolicyRSVPTrfcProf  |
   |
      +--CIM_ManagedSystemElement (abstract)  +---PolicyValue (abstract, PCIMe)
   |
         +--CIM_LogicalElement (abstract)  |
            +--CIM_System (abstract)     |
               +---CIM_AdminDomain (abstract)
   |
                       +---PolicyRepository  |     +---QoSPolicyDNValue (QPIM)
   |  |     |
   |  |     +---QoSPolicyAttributeValue (QPIM)

Figure 5. Class 1.  The QPIM Inheritance Hierarchy

Snir, Ramberg, Strassner, Cohen          expires November 2001         12

2.2.  Relationship Hierarchy

Figure 2 shows the QPIM association hierarchy.

[unrooted] (abstract, PCIM)
  |
  +---Dependency (abstract)
  |   |
  |   +--- QosPolicyTrfcProfInAdmissionAction (QPIM)
  |   |
  |   +--- QoSPolicyConformAction (QPIM)
  |   |
  |   +--- QoSPolicyExceedAction (QPIM)
  |   |
  |   +--- QoSPolicyViolateAction (QPIM)

Figure 2.  The QPIM Association Hierarchy

Snir, Ramberg, Strassner, Cohen          expires November 2001         13

3.  QoS Actions

This section describes the QoS actions that are modeled by QPIM. QoS
actions are policy enforced network behaviors that are specified for
traffic selected by QoS conditions. QoS actions are modeled using the
classes PolicyAction (defined in [PCIM]), SimplePolicyAction (defined in
[PCIMe]) and several QoS actions defined in this document (described
below).

3.1  Overview

QoS policy based systems allow the network administrator to specify a set
of rules that control both the selection of the flows that need to be
provided with a preferred forwarding treatment, as well as specifying the
specific set of preferred forwarding behaviors. QPIM provides an
information model for specifying such a set of rules.

QoS policy rules allow controlling environments in which RSVP signaling
is used to request different forwarding treatment for different traffic
types from the network as well as environments where no signaling is
used, but preferred treatment is desired for the QPIM

The reader some (not all) traffic. QoS
policy rules allow controlling environments where strict QoS guarantees
are provided to individual flows as well as environments where QoS is encouraged
provided to read section 6 and section 7 flow aggregates. QoS actions allow a PDP or a PEP to
determine which RSVP requests should be admitted because they satisfy a
given policy, before network resources are allocated. They allow control
of [PCIM] in
their entirety. Section 6 defines all the RSVP signaling content itself, as well as differentiation between
priorities of requests. QoS actions also allow specification of the object classes listed
above,
Differential Service edge enforcement including policing, shaping and section 7 defines
marking, as well as the concepts per-hop behaviors used in the network core.
Finally, QoS actions can be used to control mapping of associations and
aggregations.

Snir, Ramberg, Strassner, Cohen         expires May 2001             72

Ten associations and aggregations RSVP request at
the edge of a differential service cloud into per hop behaviors.

Four groups of actions are derived from action classes defined in the [PCIM] as follows:

  the Aggregation PolicyGroupInPolicyGroup
  the Aggregation PolicyRuleInPolicyGroup
  the Aggregation PolicyConditionInPolicyRule
  the Aggregation PolicyRuleValidityPeriod
  the Aggregation PolicyActionInPolicyRule
  the Association PolicyConditionInPolicyRepository
and [PCIMe]. The first QoS action group contains a single action,
QoSPolicyRSVPSimpleAction. This action is used for both signal control
and install actions depending on a type attribute. The second QoS action
group determines whether a flow or class of flows should be admitted.
This is done by specifying an appropriate traffic profile. These set of
actions are called QoS admission actions. The third group of actions
control bandwidth allocation and congestion control differentiations,
which together specify the Association PolicyActionInPolicyRepository per-hop behavior forwarding treatment. The
forth QoS action is unconditional packet discard action. This action is
used either by itself or as a building block of the Weak Aggregation PolicyGroupInSystem
QoSPolicyPoliceAction.

Note that some QoS actions are not directly modeled. Instead, they are
modeled by using the Weak Aggregation PolicyRuleInSystem class SimplePolicyAction with the Aggregation PolicyRepositoryInPolicyRepository

QPIM reuses appropriate
associations. For example, the PCIM associations and aggregations listed above three marking actions (DSCP, IPP and
defines CoS)
are modeled by using the following new associations SimplePolicyAction class, associating it with
variables and aggregations in the
following hierarchy:

(the diagram is in values of the next page) appropriate type.

Snir, Ramberg, Strassner, Cohen          expires May November 2001             73

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

Figure 6. Associations and Aggregation for         14

3.2  RSVP Policy Actions

There are three types of decisions a PDP (either remote or within a PEP)
can make when it evaluates an RSVP request:

1.	Admit or reject the request
2.	Use admission parameters to decide whether to admit the request or
not
3.	Use signaling parameters to decide how to modify the RSVP signaling
messages

The COPS for RSVP [RFC2749] specification uses different Decision object
types to model each of these decisions. QPIM

Snir, Ramberg, Strassner, Cohen         expires May 2001             74

8. Class Definitions

8.1. follows the COPS
specification and models each decision using a different action class.
The Aggregation "PolicyGroupInPolicyRule"

A policy rule may aggregate one QoSPolicyRSVPAdmissionAction with its associated
QosPolicyIntServTrfcProf determine whether to accept or reject a given
RSVP request by comparing the RSVP request's TSPEC or more policy groups, via RSPEC parameters
against the
PolicyGroupInPolicyRule aggregation. Grouping of policy groups and
their subclasses into traffic profile. For a policy rule is for administrative convenience,
scalability and manageability, as it enables full description of the comparison
method, see section 4, which describes traffic profiles in more complex policies to
be constructed from multiple simpler policies. For example, detail.

Using the QoSPolicyRSVPAdmissionAction, a
PolicyRule may aggregate PolicyGroups and gpsPolicyGroups via this
aggregation.

Policy rules do not have to contain policy groups. In addition, limit on the number of admitted
reservations can be enforced as well. The QoSPolicyRSVPAdmissionAction
can specify that a
policy group may also set of RSVP requests will be used by itself, without belonging to accepted yet a policy
rule and policy rules may warning
message would be individually aggregated by other policy
rules by the PolicyRuleInPilicyRule aggregation (section 8.Z.). Note
that it is assumed that this aggregation is used sent to form directed
acyclic graphs and NOT ring structures. the RSVP end points. The class definition
QoSPolicyRSVPAdmissionAction controls the Decision Command and Decision
Flags objects used within COPS for this aggregation is as follows:

NAME		 PolicyGroupInPolicyRule
DERIVED FROM PolicyComponent (defined in [PCIM])
ABSTRACT     False
PROPERTIES 	 GroupComponent[ref PolicyRule[0..n]]
             PartComponent[ref PolicyGroup[0..n]]

8.1.1. RSVP.

The Reference "GroupComponent"

This property class QoSPolicyRSVPSimpleAction, which is inherited derived from PolicyComponent, and overridden
To become an object reference the
PolicySimpleAction class [PCIMe], can be used to a PolicyRule that contains one or
More PolicyGroups. Note that for any single specify RSVP decisions.

The property qpRSVPActionType designates the instance of the
aggregation class PolicyGroupInPolicyRule, this property (like all
Reference properties) is single-valued. The [0..n] cardinality
indicates that there may to be 0, 1
either of type 'REPLACE', 'STATELESS', or more PolicyRules that contain any
given PolicyGroup.

8.1.2. The Reference "PartComponent"

This both. For instances carrying a
qpRSVPActionType property value of 'REPLACE', the action is inherited from PolicyComponent, and overridden
to become an object reference to interpreted
as a COPS Replace Decision, controlling the contents of the RSVP message.
For instances carrying a qpRSVPActionType property value of 'STATELESS',
the action is interpreted as a PolicyGroup contained COPS Stateless Decision, controlling the
admission parameters. If both of these actions are required, this can be
done by one or
more PolicyRules. Note that for any single instance assigning both of the
aggregation two qpRSVPActionType values, since it is a
multi-valued property.

This class PolicyGroupInPolicyRule, this property (like all
Reference properties) is single-valued. modeled to represent the COPS for RSVP Replace and
Stateless decisions. This similarity allows future use of these COPS
decisions to be directly controlled by a QoSPolicySimpleAction. The [0..n] cardinality
indicates that only
required extension might be the definition of a given PolicyRule may contain 0, 1, or more than one
PolicyGroup. new RSVP variable.

Snir, Ramberg, Strassner, Cohen          expires May November 2001             75

8.2.         15

Example: Controlling COPS Stateless Decision

The Aggregation "PolicyRuleInPolicyRule"

A policy rule may aggregate one or more policy rules, via QoSPolicyRSVPSimpleAction allows the
PolicyRuleInPolicyRule aggregation. Grouping specification of admission
parameters. It allows specification of the preemption priority [RFC2751]
of policy rules into a
policy rule, as sub-rules is explained in section XXX. The ability to
nest policy rules and form sub-rules is important for manageability given RSVP Reservation request. Using the preemption priority value,
the PEP can determine the importance of a Reservation compared with
already admitted reservations, and
scalability, as it enables complex policy rules if necessary can preempt lower
priority reservations to make room for the higher priority one. This
class can also be constructed from
multiple simpler policy rules.

A PolicyRule does not have to contain sub-rules. Note that it is
assumed that this aggregation is used to form directed acyclic graphs
and NOT ring structures.

The class definition for this aggregation is as follows:

NAME		 PolicyRuleInPolicyRule
DERIVED FROM PolicyComponent (defined in [PCIM])
ABSTRACT     False
PROPERTIES 	 GroupComponent[ref PolicyRule[0..n]]
             PartComponent[ref PolicyRule[0..n]]

8.2.1. The Reference "GroupComponent" control mapping of RSVP requests to a
differentiated services domain by setting the QoSPolicyRSVPDSCPVariable
to the required value. This property is inherited from PolicyComponent, and overridden instructs the PEP to
become mark traffic matching
the Session and Sender specifications carried in an object reference RSVP request to a PolicyRule that contains one or more
PolicyRules. Each contained PolicyRule can be conceptualized as a sub-
rule of
given DSCP value.

Example: Controlling the containing PolicyRule. This nesting can COPS Replace Decision

A Policy system should be done able to any
desired level. However, the deeper the nesting, control the more complex information carried in the
results
RSVP messages. The QoSPolicyRSVPSimpleAction allows control of the decisions taken by the nested rules. Note that a group
content of rules RSVP signaling messages. An RSVP message can be aggregated by carry a
preemption policy group(gpsPolicyGroups) and
aggregated as a unit by object [RFC2751] specifying the priority of the
reservation request in comparison to other requests. An RSVP message can
also carry a policy rule (section 8.Z).

Note that object for any single instance of the aggregation class
PolicyRuleInPolicyRule, this property is single-valued. The [0..n]
cardinality indicates authentication purposes. An RSVP message
can carry a DCLASS [DCLASS] object that there may be 0, 1 specifies to the receiver or more PolicyRules
sender the particular DSCP value 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 should be set on the data traffic.
A COPS for RSVP Replacement Data Decision controls the content of the
RSVP message by specifying a PolicyRule.
Note that for any single instance set of RSVP objects replacing or removing
the aggregation class
PolicyRuleInPolicyRule, this property is single-valued. existing ones.

3.3  Provisioning Policy Actions

The [0..n]
cardinality indicates that differentiated Service Architecture [DIFFSERV] was designed to
provide a given PolicyRule may contain 0, 1, or more
PolicyRules.

Snir, Ramberg, Strassner, Cohen         expires May 2001             76

8.3. scalable QoS differentiation without requiring any signaling
protocols running between the hosts and the network. The Aggregation "PolicyConditionInCompoundCondition"

A policy compound condition may aggregate one or more policy
conditions, via QoS actions
modeled in QPIM can be used to control all the PolicyConditionInCompoundCondition aggregation.
Grouping building blocks of policy conditions the
Differentiated Service architecture, including per-hop behaviors, edge
classification, and their derivatives into policing and shaping, without a policy
compound condition is for reusability of partial or full Boolean
condition statements.

A qosPolicyCompoundCondition may aggregate PolicyConditions need to specify the
datapath mechanisms used by PEP implementations. This provides an
abstraction level hiding the unnecessary details and
their derivatives, such allowing the network
administrator to write rules that express the network requirements in a
more natural form. In this architecture, as qosPolicySimpleConditions no signaling between the end
host and
qosPolicyCompoundConditions. The properties GroupNumber the network occur before the sender starts sending information,
the QoS mechanisms should be setup in advance. This usually means that
PEPs need to be provisioned with the set of policy rules in advance.
Policing and
ConditionNegated Shaping actions are inherited from PolicyConditionInPolicyRule modeled as sub-classes of the QoS
admission action. DSCP and CoS marking are
specified per instance modeled as sub-classes of this aggregation the
simplePolicyAction class. There is no change in
their semantics, so they Bandwidth allocation, scheduling and congestion
control actions are not redefined here. However, modeled as sub-classes of the
GroupComponent QoS PHB action.

Snir, Ramberg, Strassner, Cohen          expires November 2001         16

3.3.1.  Admission Actions: Controlling Policers and PartComponent properties DO Shapers

All Admission Actions have modified semantics,
and so they are described below. The class definition for this
aggregation is as follows:

NAME		 PolicyConditionInCompoundCondition
DERIVED FROM PolicyConditionInPolicyRule (defined in [PCIM])
ABSTRACT     False
PROPERTIES 	 GroupComponent[ref gpsPolicyCompoundCondition[0..n]]
             PartComponent[ref PolicyCondition[0..n]]

8.3.1. The Reference "GroupComponent"

This property is inherited from PolicyComponent, and overridden to
become common an object reference association to a gpsPolicyCompoundCondition traffic profile
and a scope property that
contains one determines whether the traffic profile is
compared against the rate parameters of each flow or more PolicyConditions. Note against the
aggregate rate of all flows that for any single
instance match the rule's condition. For example,
using two provisioned policer actions the following policies can be
enforced:

   - Make sure that each HTTP flow will not exceed 64kb/s
   - Make sure that the aggregate rate of all HTTP flows will not
     exceed 512Kb/s

Both policies are modeled using the aggregation class PolicyConditionInCompoundCondition,
this property is single-valued. same QoSPolicyPoliceAction. The [0..n] cardinality indicates that
there may be 0, 1 or more gpsPolicyCompoundCondition objects that
contain any given policyCondition object, or first
policy has its subclasses.

8.3.2. The Reference "PartComponent"

This scope property is inherited from PolicyComponent, and overridden to
become an object reference set to a PolicyCondition contained by one
or more gpsPolicyCompoundConditions. Note that for any single instance
of 'flow', while the aggregation class PolicyConditionInPolicyRule, this second policy has
its scope property is
single-valued. set to 'class'. The [0..n] cardinality indicates that two policies are modeled using a given
gpsPolicyCompoundCondition may contain 0, 1 or more1  PolicyConditions
(or subclasses of PolicyCondition).

8.4.
rule with two police actions that, in a pseudo formal definition, looks
like the following:

   If (HTTP) Action1=police, Traffic Profile1=64kb/s, Scope1=flow
             Action2=police, Traffic Profile2=512kb/s, Scope2=class

The  aggregation "PolicyVariableInPolicySimpleCondition"

QoS policy simple conditions are represented provisioned policer action QoSPolicyPoliceAction has 3 associations,
QoSPolicyConformAction, QoSPolicyExceedAction and QoSPolicyViolateAction.
The policer action is associated with a three-level token bucket traffic
profile carrying rate, burst and excess-burst parameters. Traffic
measured by a meter can be classified as conforming traffic when the ordered
triplet {variable, operator, value}. The PolicyElement class
metered rate is below the common superclass for rate defined by the PolicyVariable and PolicyValue classes
and their subclasses. A gpsPolicySimpleCondition associates exactly

Snir, Ramberg, Strassner, Cohen         expires May 2001             77

one gpsPolicyVariable via traffic profile, as excess
traffic when the PolicyVariableInPolicySimpleCondition
aggregattion. This aggregation links a subclass of PolicyElement to metered traffic is above the
gpsPolicySimpleCondition in whose scope normal burst and below the PolicyElement subclass
excess burst size, and violating traffic when rate is
defined. above the maximum
excess burst.

The class definition for [DIFF-MIB] defines a two-level meter, and provides a means to combine
two-level meters into more complex meters. In this aggregation document, a three-
level traffic profile is as follows:

NAME		 PolicyVariableInPolicySimpleCondition
DERIVED FROM PolicyComponent (defined in [PCIM])
ABSTRACT     False
PROPERTIES 	 GroupComponent[ref gpsPolicySimpleCondition[0..n]]
             Partcomponent[ref gpsPolicyVariable[1..1] ]

8.4.1. The Reference "GroupComponent" defined. This property is inherited from PolicyComponent, and overridden to
become allows construction of both two-
level meters as well as providing an object reference to easier definition for three-level
meters needed for creating AF [AF] provisioning actions.

A policer action with a gpsPolicySimpleCondition non-specified conform action implies that contains
exactly one gpsPolicyVariable. Note
conforming traffic should not be modified. A policer action with an
associated three-level traffic profile that does not specify an excess
action implies that the excess traffic should be treated as either
violating or conforming traffic according to some algorithm suitable for any single instance
the enforcement of the
aggregation class policyVariableInPolicySimpleCondition, this property
is single-valued. The [0..n] cardinality indicates that there rule. For example, the final enforcement of such a
rule may be 0,
1 the use of a random function similar to RED to determine
whether traffic is conforming or more gpsPolicySimpleCondition objects violating. A policer action with a
three-level traffic profile that contain any given
gpsPolicyVariable object, or its subclasses.

8.4.2. The Reference "PartComponent"

This property is inherited from Dependency, and overridden to become specifies an
object reference to exceed action but does not
specify a PolicyVariable class (or one of its subclasses) violate action implies that violate action is defined within identical to the scope of a gpsPolicySimpleCondition. Note
that for any single instance
specified exceed action.

Snir, Ramberg, Strassner, Cohen          expires November 2001         17

Shapers are used to delay some or all of the association class
PolicyVariableInPolicySimpleCondition, this property (like all
reference properties) is single-valued. The [1..1] cardinality
indicates that packets in a qpsPolicySimpleCondition must have exactly one
PolicyVariable class (or one of its subclasses) defined within its
scope traffic stream
in order to be a meaningful.

8.5. The  Aggregation "PolicyValueInPolicySimpleCondition"

QoS policy simple conditions are represented as the ordered triplet
{variable, operator, value}. The PolicyElement class is the common
superclass for bring the PolicyVariable and PolicyValue classes and their
subclasses. stream into compliance with a traffic profile.  A gpsPolicySimpleCondition associates exactly one
gpsPolicyValue via the PolicyValueInPolicySimpleCondition aggregation.
This aggregation links
shaper usually has a subclass of PolicyElement finite-sized buffer, and packets may be discarded if
there is not sufficient buffer space to hold the
gpsPolicySimpleCondition in whose scope the PolicyElement subclass delayed packets. Shaping
is
defined.

Snir, Ramberg, Strassner, Cohen         expires May 2001             78 controlled by the QoSPolicyShapeAction class. The class definition for this only required
association is as follows:

NAME		 PolicyValueInPolicySimpleCondition
DERIVED FROM PolicyComponent (defined a traffic profile that specifies the rate and burst
parameters that the outgoing flows should conform with.

3.3.2  Controlling Markers

Three types of markers are modeled in [PCIM])
ABSTRACT     False
PROPERTIES 	 GroupComponent[ref gpsPolicySimpleCondition[0..n]]
             PartComponent[ref gpsPolicyValue[1..1]]

8.5.1. QPIM: Differentiated Services Code
Point (DSCP), IP Precedence (IPP) and layer-2 Class of Service (CoS). The Reference "GroupComponent"

This property
marking action itself is inherited from PolicyComponent, modeled by using the SimplePolicyAction class
associated with the appropriate variables and overridden to
become an object reference values.

DSCP markers set the DS field of a packet header to a gpsPolicySimpleCondition that contains
exactly one gpsPolicyValue. Note that for any single instance of particular DS Code
Point (DSCP), adding the
aggregation class PolicyValueInPolicySimpleCondition, this property is
single-valued. marked packet to a particular DS behavior
aggregate. The [0..n] cardinality indicates that there marker may be 0, 1
or more gpsPolicySimpleCondition objects configured to mark all packets that contain any given
gpsPolicyValue object, or its subclasses.

8.5.2. The Reference "PartComponent"

This property is inherited from Dependency, and overridden it
receives to become an
object reference a single DSCP, or may be configured to mark a PolicyValue class (or packet to one
of its subclasses) that a set of DSCPs used to select a PHB in a PHB group according to the
state of a meter. This can be achieved by associating a marking action
with a policer action using the conform, exceed and violate action
associations. The semantics of the DSCP marker is defined within encapsulated in the scope
pairing of a gpsPolicySimpleCondition. Note that
for any DSCP variable and a DSCP value within a single
SimplePolicyAction instance via the appropriate associations.

IPP markers set the IPP field of a packet header to a particular IPP
value (0 through 7). The semantics of the association class
PolicyValueInPolicySimpleCondition, this property (like all reference
properties) IPP marker is single-valued.  The [1..1] cardinality indicates that a
qpsPolicySimpleCondition must have exactly one PolicyValue class (or
one encapsulated in
the pairing of its subclasses) defined a DSCP variable masked to IPP sub-field and a DSCP value
masked to IPP sub-field within its scope in order a single SimplePolicyAction instance via
the appropriate associations.

CoS markers control the mapping of a per-hop behavior to be a
meaningful.

8.6. The Association "PolicyElementInPolicyRepository"

Policy objects (e.g., policy variables, layer-2 Class
of Service. For example, mapping of a set of DSCP values and other reusable
policy objects) into a 802.1q
user priority value can be made reusable. Reusable policy elements are
always related specified using a rule with a condition
describing the set of DSCP values, and a CoS marking action that
specifies the required mapping to the given user priority value. The
semantics of the CoS marker is encapsulated in the pairing of a CoS
variable and a CoS value (integer in the range of 0 through 7) within a
single PolicyRepository SimplePolicyAction instance via the
PolicyElementInPolicyRepository association.

Policy conditions can use this association to assign reusable policy
variables and/or values. Note appropriate associations.

3.3.3  Controlling Edge Policies - Examples

Assuming that either the AF1 behavior aggregate is enforced within a DS domain,
policy variables and/or
values do not have to be reused. In order rules on the edge of the network should mark packets to construct policy
conditions one of this form, use the PolicyVariableInPolicySimpleCondition
and PolicyValueInPolicySimpleCondition weak associations as
appropriate.

The class definition for this association is as follows:

NAME             PolicyElementInPolicyRepository
DERIVED FROM     PolicyInSystem
ABSTRACT         FALSE
PROPERTIES       Antecedent[ref PolicyRepository[0..1]]
                 Dependent[ref Policy[0..n]]
AF1x DSCPs depending on conformance to a predetermined three-parameter
traffic profile. QPIM models such AF1 policing action as defined in
Figure 3.

Snir, Ramberg, Strassner, Cohen          expires May November 2001             79

8.6.1.         18
     +-----------------------+    +------------------------------+
     | QoSPolicyPoliceAction |====| QoSPolicyTokenBucketTrfcProf |
     | scope = class         |    | rate = x, bc = y, be = z     |
     +-----------------------+    +------------------------------+
       *     @     #
       *     @     #
       *     @  +-------------------------+   +--------------------+
       *     @  | SimplePolicyAction      |---| PolicyIntegerValue |
       *     @  +-------------------------+   |        AF13        |
       *     @                                +--------------------+
       *  +-------------------------+   +--------------------+
       *  | SimplePolicyAction      |---| PolicyIntegerValue |
       *  +-------------------------+   |        AF12        |
       *                                +--------------------+
     +-------------------------+   +--------------------+
     | SimplePolicyAction      |---| PolicyIntegerValue |
     +-------------------------+   |        AF11        |
                                   +--------------------+

   Association and Aggregation Legend:

     ****  QoSPolicyConformAction
     @@@@  QoSPolicyExceedAction
     ####  QoSPolicyViolateAction
     ====  QoSTrfcProfInAdmissionAction
     ----  PolicyValueInSimplePolicyAction ([PCIMe])
     &&&&  PolicyVariableInSimplePolicyAction ([PCIMe], not shown)

   Figure 3.    AF Policing and Marking

The Reference "Antecedent"

This property marker is inherited from PolicyInSystem, and overridden to
become made of an object reference to a PolicyRepository containing one or more
Policy objects.  A reusable Policy object is always related to exactly
one PolicyRepository via instance of the PolicyElementInPolicyRepository
association. SimplePolicyAction class. The [0..1] cardinality for this property signifies
whether the Policy object
aggregation PolicyVariableInSimplePolicyAction (which is reusable or not. If it defined in
[PCIMe]) is 0, then used to associate the
association value to mark (contained in the
PolicyDSCPValue) with the appropriate traffic action. This aggregation is
not instantiated, which means that shown in this Policy object figure for simplicity. AF11 is
specific to marked on conforming
traffic; AF12 is marked on exceeding action and AF13 on violating
traffic.

The second example, shown in Figure 4, is the simplest policing action.
Traffic below a single PolicyCondition. If this association two-parameter traffic profile is
instantiated, then it means that unmodified, while
traffic exceeding the Policy object (subclass) traffic profile is
reusable, discarded.

Snir, Ramberg, Strassner, Cohen          expires November 2001         19
     +-----------------------+    +------------------------------+
     | QoSPolicyPoliceAction |====| QoSPolicyTokenBucketTrfcProf |
     | scope = class         |    | rate = x, bc = y             |
     +-----------------------+    +------------------------------+
            @
            @
         +-------------------------+
         | QoSPolicyDiscardAction  |
         +-------------------------+
   Association and Aggregation Legend:
     ****  QoSPolicyConformAction (not used)
     @@@@  QoSPolicyExceedAction
     ####  QoSPolicyViolateAction (not used)
     ====  QoSTrfcProfInAdmissionAction

   Figure 4.    A Simple Policing Action

3.4  Per-Hop Behavior Actions

A Per-Hop Behavior (PHB) is located in this specific PolicyRepository.

8.6.2. a description of the externally observable
forwarding behavior of a DS node applied to a particular DS behavior
aggregate [DIFFSERV]. The Reference "Dependent"

This property approach taken here is inherited from PolicyInSystem, that a PHB action
specifies both observable forwarding behavior (i.e., loss, delay, jitter)
as well as specifying the buffer and overridden bandwidth resources that need to
become an object reference be
allocated to a Policy object, or inheriting class
included in a PolicyRepository. If this association is not instantiated
(the "0" part each of the cardinality), then this Policy object is embedded
(or attached) directly behavior aggregates in order to the containig object. However, if achieve this
association is instantiated, then the [0..n] cardinality indicates that
behavior. That is, a given PolicyRepository may contain 0, 1, or rule with a set of PHB actions can specify that an
EF packet must not be delayed more than one Policy
objects.

8.7. 20 msec in each hop. The Association "PolicyValueConstraintsInVariable"

This association links a gpsPolicyValue object same
rule may also specify that EF packets need to a gpsPolicyVariable
object, modeling specific value constraints. For example, be treated with preemptive
forwarding (e.g., with priority queuing), and specify the
gpsPolicyVariable assignment/binding may maximum
bandwidth for this class as well as the maximum buffer resources. PHB
actions can therefore be constrained used to  a specific
value of IP Address. The constraints then are twofold. First, one may
want both represent the final requirements
from PHBs as well as provide enough detail to be able to constrain map the PHB
actions into a set of allowable address values. Second, one may
want configuration parameters to ensure that the variable configure queues,
schedulers, droppers and other mechanisms.

The QoSPolicyPHBAction abstract class has two subclasses. The
QoSPolicyBandwidthAction class is of used to control bandwidth, delay and
forwarding behavior, while the correct data type. This
latter QoSPolicyCongestionControlAction class is provided by Table 1, which defines the set of value types
that each type of PolicyVariable can assume.
used to control queue size, thresholds and congestion algorithms. The class definition for
qpPacketSize property of the association PHB action specifies the packet size in
bytes, and is as follows:

NAME			PolicyValueConstraintsInVariable
DESCRIPTION     	A class representing needed when translating the association of a constraints
                  object actions into actual
implementation configurations. For example, implementation measuring
queue length in bytes will need to a variable object
DERIVED FROM     	Dependency (defined use this property to map the
qpQueueSize property into queue length in [PCIM])
ABSTRACT         	FALSE
PROPERTIES  	Antecedent[ref gpsPolicyVariable[0..1]]
                  Dependent[ref gpsPolicyValue [0..n]] bytes.

Snir, Ramberg, Strassner, Cohen          expires May November 2001             80

8.7.1.         20

3.4.1  Controlling Bandwidth and Delay

QoSPolicyBandwidthAction allows specifying the minimal bandwidth that
should be reserved for a class of traffic. The Reference "Antecedent"

This property qpMinBandwidth
can be specified either in Kb/sec or in percentage of the total available
bandwidth. The property qpBandwidthUnits is inherited from Dependency.  Its type is and
cardinality are overridden used to provide determine whether
percentage or fixed values are used.

The property qpForwardingPriority is used whenever preemptive forwarding
is required. A policy rule that defines the semantics of EF PHB should indicate a variable
optionally having value constraints. This non-
zero forwarding priority. The qpForwardingPriority property itself is holds an object
reference
integer value to a policy variable (gpsPolicyVariable) enable multiple levels of preemptive forwarding where
higher values are used to specify higher priority.

The property qpMaxBandwidth specifies the maximum bandwidth that is optionally
constrained by one or more policy value should
be allocated to a class instances
(gpsPolicyValue).

8.7.2. The Reference "Dependent" of traffic. This property is inherited from Dependency, and overridden to become an
object reference 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 specify limits on the per-hop
delay and jitter in milliseconds for any given packet within a gpsPolicyValue that is used to constrain traffic
class. Enforcement of the maximum delay and jitter may require use of
preemptive forwarding as well as minimum and maximum bandwidth controls.
Enforcement of low max delay and jitter values that a particular gpsPolicyVariable can have. may also require
fragmentation and interleave mechanisms over low speed links.

The [0..n]
cardinality Boolean property qpFairness indicates that a given policy variable may whether flows should have 0, 1 a
fair chance to be forwarded without drop or
more gpsPolicyValues defined delay. A way to model the constraints on the
values that the policy variable can take.

8.8. The Association "PolicyMeterInAction"

This association links a gpsPolicyMeter object modeling enforce a specific
meter
bandwidth action with qpFairness set to TRUE would be to build a qosPolicyPRAction or a qosPolicyRSVPAction object.

The class definition queue
per flow for the association is as follows:

NAME			PolicyMeterInAction
DESCRIPTION     	A class representing of traffic specified in the association between rule's filter. In this
way, interactive flows like terminal access will not be queued behind a
                  gpsPolicyMeter object
bursty flow (like FTP) and therefore have a specific meter object.
DERIVED FROM     	Dependency
ABSTRACT         	FALSE
PROPERTIES  	Antecedent[ref PolicyAction[0..n]
                  Dependent[ref gpsPolicyMeter [0..n]

8.8.1. reasonable response time.

3.4.2  Congestion Control Actions

The QoSPolicyCongestionControlAction class controls queue length,
thresholds and congestion control algorithms.

A PEP should be able to keep in its queues qpQueueSize packets matching
the rule's condition. In order to provide a link-speed independent queue
size, the qpQueueSize can also be measured in milliseconds. The time
interval specifies the time needed to transmit all packets within the
queue if the link speed is dedicated entirely for transmission of packets
within this queue. The Reference "Antecedent"

This property qpQueueSizeUnit determines whether queue
size is inherited from Dependency.  It serves as an object
reference to measured in number of packets or in milliseconds.

The property qpDropAlgorithm selects either a qosPolicyPRAction tail-drop, head-drop or a qosPolicyRSVPAction.
random-drop algorithms. The
[0..n] cardinality indicates that a given meter may set of maximum and minimum threshold values
can be referenced by 0,
or 1 more policy actions.

8.8.2. The Reference "Dependent"

This property is inherited from Dependency, specified as well, using qpThresholdMin and is overridden to
become an object reference to a gpsPolicyMeter.
The [0..n] cardinality indicates that a given policy action may have 0 qpThresholdMax
properties, either in packets or more gpsPolicyMeter objects to which it applies. in percentage of the total available
queue size as specified by the qpThresholdUnits property.

Snir, Ramberg, Strassner, Cohen          expires May November 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         21

3.4.3  Using Hierarchical Policies  Examples for this association PHB actions

Hierarchical policy definition is a primary tool in the QoS Policy
Information model. Rule nesting introduced in [PCIMe] allows
specification of hierarchical policies controlling RSVP requests,
hierarchical shaping, policing and marking actions, as follows:

NAME			PolicyTrfcProfileInMeter
DESCRIPTION     	A class representing well as
hierarchical schedulers and definition of the association between differences in PHB groups.
An example of the use of hierarchical schedulers is provided in [PCIMe].

This example provides a
                  traffic profile set of rules that is used for provisioning and specify PHBs enforced within a
                  meter.
DERIVED FROM     	Dependency
ABSTRACT         	FALSE
PROPERTIES  	Antecedent[ref gpsPolicyMeter [0..n]]
                  Dependent[ref gpsPolicyTrfcProf [0..1]]

8.9.1.
Differentiated Service Domain. The Reference "Antecedent"

This property is inherited from Dependency.  It serves as an object
reference network administrator chose to a meter enforce
the EF, AF11 and AF13 and Best Effort PHBs. For simplicity, AF12 is not
differentiated. The set of rules takes the form:

  If (EF) then do EF actions
  If (AF1) then do AF1 actions
      If (AF13) then do AF13 actions
  If (default) then do Default actions.

EF, AF1 and AF13 are conditions that uses a filter traffic profile object according to provision
flows. The [0..n] cardinality indicates that a given meter may use zero
or more traffic profiles.

8.9.2. DSCP
values. The Reference "Dependent"

This property is inherited from Dependency, AF1 condition matches the entire AF1 PHB group including the
AF11, AF12 and overridden to become an
object reference to a traffic profile used by AF13 DSCP values. The default rule uses a meter. 'match all'
condition and specifies the Best Effort rules. The [0..n]
cardinality indicates nesting of the AF13
rule within the AF1 rule specifies that a given there are further refinements on
how AF13 traffic profile may should be used by 0 or
more meters.

8.10. treated relative to the entire AF1 PHB group.
The Weak Association " PolicyQueueInPHBAction "

This association links set of rules reside in a qosPolicyQueue object modeling PolicyGroup with a specific
queue decision strategy
property set to a QoSPolicyPHBAction object. 'MATCH FIRST'.

The class definition for this association is as follows:

NAME			PolicyQueueInPHBAction
DESCRIPTION     	A class representing instances below specify the association between a queue
                  and a PHB action.
DERIVED FROM     	Dependency
ABSTRACT         	FALSE
PROPERTIES  	Antecedent[ref qosPolicyPHBAction[0..n]]
                  Dependent[ref qosPolicyQueue [0..n]]

8.10.1. set of actions used to describe
each of the PHBs. Queue sizes are not specified, but can easily be added
to the example.

The Reference "Antecedent"

This property actions used to describe the Best Effort PHB are simple. No bandwidth
is inherited from Dependency.  It serves as an object
reference allocated to a qosPolicyPHBAction Best Effort traffic. The first action specifies that references a qosPolicyQueue. Best
Effort traffic class should have fairness.

QosPolicyBandwidthAction  BE-B:
  qpFairness: True

The
[0..n] cardinality indicates second action specifies that a given queue may the congestion algorithm for the Best
Effort traffic class should be referenced by 0
or more PHB actions. random, and specifies the thresholds in
percentage of the default queue size.

QoSPolicyCongestionControlAction  BE-C:
  qpDropAlgorithm: random
  qpDropThresholdUnits %
  qpDropMinThreshold:  10%
  qpDropMaxThreshold:  70%

Snir, Ramberg, Strassner, Cohen          expires May November 2001             82

8.10.2.         22

EF requires preemptive forwarding. The Reference "Dependent"

This property maximum bandwidth is inherited from Dependency, and overridden also
specified to become an
object reference make sure that the EF class does not starve the other
classes. EF PHB uses tail drop as the applications using EF are supposed
to be UDP-based and therefore would not benefit from a qosPolicyQueue defined random dropper.

QosPolicyBandwidthAction  EF-B:
  qpForwardingPriority: 1
  qpBandwidthUnits: %
  qpMaxBandwidth  50%
  qpFairness: False

QoSPolicyCongestionControlAction  EF-C:
  QpDropAlgorithm: tail-drop
  qpDropThresholdUnits packet
  qpDropMaxThreshold:  3 packets

The AF1 actions define the bandwidth allocations and thresholds for the
entire PHB group:

QosPolicyBandwidthAction  AF1-B:
  qpBandwidthUnits: %
  qpMinBandwidth: 30%

QoSPolicyCongestionControlAction  AF1-C:
  QpDropAlgorithm: random
  qpDropThresholdUnits packet
  qpDropMinThreshold:  4 packets
  qpDropMaxThreshold:  20 packets

The AF13 action specifies the differentiating refinement for the AF13 PHB
within the scope AF1 PHB group. The lower threshold values provide the higher
discard probability of the AF13 PHB.

QosPolicyCongestionControlAction  AF13-C:
  QpDropAlgorithm: random
  qpDropThresholdUnits packet
  qpDropMinThreshold:  2 packets
  qpDropMaxThreshold:  10 packets

4.  Traffic Profiles

Meters measure the temporal state of a
qosPolicyPHBAction. The [0..n] cardinality indicates that flow or a given PHB
action may be used set of flows against a
traffic profile. In this document, traffic profiles are modeled by zero or more qosPolicyQueues.

8.11. the
gpsPolicyTrfcProf class. The Association "PolicyConformNextAction"

This association links an
QoSPolicyTrfcProfileInAdmissionAction binds the traffic profile to the
admission action using it. Two traffic profiles are derived from the
abstract class gpsPolicyTrfcProf. The first is a meter with an object defining Token Bucket
Provisioning traffic profile carrying rate and burst parameters. The
second is an action RSVP traffic profile, which enables flows to be applied on the conforming traffic, as defined by the
relevant compared
with RSVP TSPEC and FLOWSPEC parameters.

Snir, Ramberg, Strassner, Cohen          expires November 2001         23

4.1  Provisioning Traffic Profiles

Provisioned Admission Actions including Shaping and policing are
specified using a two- or  three-parameter token bucket traffic profile.
The qosPolicyTokenBucketTrfcProf class definition for includes the following properties:

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

Rate determines the long-term average transmission rate. Traffic that
falls under this association rate is conforming, as long as follows:

NAME			PolicyConformNextAction
DESCRIPTION     	A class representing the association between two
                  action object in order to model action to be applied
                  on normal burst is not
exceeded at any time. Traffic exceeding the normal burst but still below
the excess burst is exceeding the traffic conforming profile. Traffic beyond the
excess burst is said to an associated be violating the 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

Excess burst size is inherited from Dependency.  It serves as an object
reference measured in bytes in addition to a qosPolicyPRAction object, which provides scoping for the
next action to be applied on conforming traffic. This next action is
modeled by a QoSPolicyPRAction object. The [0..1] cardinality means burst size. A
zero excess burst size indicates that a given qosPolicyPRAction may define 0 or 1 qosPolicyPRAction
objects to use as its conforming action.

8.11.2. The Reference "Dependent"

This property no excess burst is inherited from Dependency, and overridden allowed.

4.2  RSVP traffic profiles

RSVP admission policy can condition the decision whether to
become accept or
deny an object reference to a qosPolicyPRAction object that is
defined within RSVP request based on the scope another QoSPolicyPRAction. The [0..1]
cardinality indicates that a given conforming action (modeled using a
qosPolicyPRAction object) may be used by 0 traffic specification of the flow
(TSPEC) or 1 qosPolicyPRAction
objects.

Snir, Ramberg, Strassner, Cohen         expires May 2001             83

8.12. the amount of QoS resources requested (FLOWSPEC). The Association "PolicyExcessNextAction"

This association links another action using a meter with an object
defining an action to
admission decision can be applied based on excess traffic, as defined matching individual RSVP requests
against a traffic profile or by matching the
relevant traffic profile. aggregated sum of all
FLOWSPECs (TSPECs) currently admitted.  The QosPolicyIntesrvTrfcProf
class definition for this association is as follows:

NAME			PolicyExcessNextAction
DESCRIPTION     	A models both such traffic profiles. This class representing has the association between two
                  action objects following
properties:

1.	Token Rate (r) measured in order to model action to be applied
                  on traffic bits/sec
2.	Peak Rate (p) measured in excess to an associated traffic
                  profile.
DERIVED FROM     	Dependency
ABSTRACT         	FALSE
PROPERTIES  	Antecedent[ref QoSPolicyPRAction[0..1]]
                  Dependent[ref QoSPolicyPRAction [0..1]]

8.12.1. 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

The Reference "Antecedent"

This property is inherited from Dependency.  It serves as an object
reference first 5 parameters are the traffic specification parameters used in
the integrated service architecture. These parameters are used to define
a qosPolicyPRAction that provides a scope sender TSPEC as well as FLOWSPEC for the next
action applied on excess traffic, modeled by a qosPolicyPRAction
object. The [0..1] cardinality indicates that Controlled-Load service [CL].
For a given qosPolicyPRAction
object may have 0 or 1 qosPolicyPRAction objects defined definition and full explanation of their meaning, please refer to process
excess traffic.

8.12.2.
[RSVP-IS]. Parameters 6 and 7 are the additional parameters used for
specification of the Guaranteed Service FLOWSPEC [GS].

Snir, Ramberg, Strassner, Cohen          expires November 2001         24

A partial order is defined between TSPECs (and FLOWSPECs). The Reference "Dependent"

This property TSPEC A is inherited from Dependency,
larger than the TSPEC B if and overridden to
become an object reference to only if rA>rB, pA>pB, bA>bB, mA<mB and
MA>MB. A TSPEC (FLOWSPEC) measured against a qosPolicyPRAction that is handling the
excess traffic defined within profile uses the scope of another qosPolicyPRAction
object. The [0..1] cardinality indicates that a given excess action,
modeled as a qosPolicyPRAction object, may be used by 0
same ordering rule. An RSVP message is accepted only if its TSPEC
(FLOWSPEC) is either smaller or 1
qosPolicyPRAction objects.

8.13. The Association "PolicyViolateNextAction"

This association links an action using a meter with an object defining
an action equal to be applied on the violating traffic, as a defined by the
relevant traffic profile. Only
parameters specified in the traffic profile are compared.

The class definition for this association GS FLOWSPEC is as follows:

NAME			PolicyExcessNextAction
DESCRIPTION     	A class representing also compared against the association between two
                  action objects in order to model action to rate R and the slack term S.
R should not be applied
                  on larger than the traffic profile R parameter, while the
FLOWSPEC slack term should not be smaller than that specified in violation to 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
slack term.

TSPECs as well as FLOWSPECs can be added. The Reference "Antecedent"

This property sum of two TSPECs is inherited from Dependency.  It serves as an object
reference to a qosPolicyPRAction that provides a scope for
computed by summing the rate r, the peak rate p, the bucket size b, and
by taking the minimum value of the next
action to be applied on violating traffic, modeled minimum policed unit m and the maximum
value of the maximum packet size M. GS FLOWSPECs are summed by a
qosPolicyPRAction object. The [0..1] cardinality indicates that a given
qosPolicyPRAction object may have 0 or 1 qosPolicyPRAction objects
defined adding the
Resv rate and minimizing the slack term s. These rules are used to process violating traffic.

8.13.2. The Reference "Dependent"
compute the temporal state of admitted RSVP states matching the traffic
class defined by the rule condition. This property state is inherited from Dependency, and overridden compared with the
traffic profile to
become an object reference arrive to a qosPolicyPRAction defined within an admission decision when the scope of another qosPolicyPRAction object. The [0..1] cardinality
indicates that a given violating action, modeled as a qosPolicyPRAction
object, may be used by 0 or 1 QoSPolicyPRAction objects.

8.14. Class qosPolicyDomain

This class defines the root
QoSPolicyRSVPAdmissionAction is set to 'class'.

5.  Pre-Defined QoS-Related Variables

Pre-defined variables are necessary for ensuring interoperability among
policy servers and policy management tools from different vendors.
The purpose of a single administrative this section is to define frequently used variables in QoS
policy
domain, and contains domains.

Notice that this section only adds to the domain's policy rules variable classes as defined in
[PCIMe] and definitions. This
enables the administrator to partition reuses the set of mechanism defined there.

The QoS policy information into
different domains, where each domain has model specifies a potentially different set of
PHBs pre-defined variable
classes to support a set of fundamental QoS terms that are commonly used
to form conditions and policies, access rules, decision strategy or other application actions and are missing from the [PCIMe]. Examples
of these include RSVP related variables. All variable classes defined in
this document extend the PolicyImplictVariable class, defined in [PCIMe].
Subclasses specify the data type and semantics of the policy information organized in some fashion. The class
definition is as follows:

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

8.14.1. The Property qpDomainName variables.

This property provides a user-friendly name for Draft defines the QoS policy domain.
Its definition is as follows:

NAME		qpDomainName
SYNTAX	String following RSVP variable classes, for details see
class definition:

Snir, Ramberg, Strassner, Cohen          expires May November 2001             85

8.14.2.         25

RSVP related Variables:

1.	QoSPolicyRSVPSourceIPv4Variable - The Property qpPolicyRuleMatchMethod

This property defines the decision strategy to be applied on this set source IP address of QoS policy rules by policy servers. It is an enumerated integer that
defines two values, first match the RSVP
signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and match all. Please see section 5 RSVP
RESV FILTER_SPEC [RSVP] objects.
2.	QoSPolicyRSVPDestinationIPv4Variable - The destination port of
this document for more information on these decision strategies. Its
definition is the
RSVP signaled flow, 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 the RSVP PATH and RESV SESSION
[RSVP] objects.
3.	QoSPolicyRSVPSourceIPv6Variable - The source IP address of flow or device. Placing
these policies in a gpsPolicyGroup that resides the RSVP
signaled flow, as defied in a particular
qosPolicyDomain enables the administrator to group different sets of
policy rules that perform different types RSVP PATH SENDER_TEMPLATE and RSVP
RESV FILTER_SPEC [RSVP] objects.
4.	QoSPolicyRSVPDestinationIPv6Variable - The destination port of operations. It also
enables an organization to partition policies according to the
administrator (or other entity) that manages
RSVP signaled flow, as defined in the policies. RSVP PATH and RESV SESSION
[RSVP] objects.
5.	QoSPolicyRSVPSourcePortVariable - The class definition is source port of the RSVP signaled
flow, as follows:

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

8.15.1. The Property gpPriority

This property is a non-negative integer that defines the priority of a
named group RSVP PATH SENDER_TEMPLATE and RSVP RESV
FILTER_SPEC [RSVP] objects.
6.	QoSPolicyRSVPDestinationPortVariable - The destination port of rules. Conceptually, it is the priority of
RSVP signaled flow, as defined in the
gpsPolicyGroup, RSVP PATH and is used to determine when RESV SESSION
[RSVP] objects.
7.	QoSPolicyRSVPIPProtocolVariable - The IP Protocol of the policy rules that RSVP signaled
flow, as defined in the
gpsPolicyGroup contains are evaluated with respect to other policyRules RSVP PATH and gpsPolicyGroups.

If two or more gpsPolicyGroup objects have RESV SESSION [RSVP] objects.
8.	QoSPolicyRSVPIPVersionVariable - The IP version of the same priority, this
means that IP Addresses
carried the order between these objects is of no importance, but
that they MUST each be evaluated before other objects that have a
numerically lower priority. RSVP signaled flow, as defined in the RSVP PATH and RESV
SESSION [RSVP] objects.
9.	QoSPolicyRSVPDCLASSVariable - The attribute is DSCP value as defined in the RSVP
DCLASS [DCLASS] object.
10.	QoSPolicyRSVPStyleVariable - The reservation style (FF, SE, WF) as follows:

NAME		gpPriority
SYNTAX	Integer (must be non-negative)

Snir, Ramberg, Strassner, Cohen         expires May 2001             86

8.15.2.
   defined in the RSVP Resv message [RSVP].
11.	QoSPolicyRSVPIntServVariable - The Property gpNamedPolicyRuleMatchMethod

This property is an enumerated integer that defines integrated Service (CL, GS,
   NULL) requested in the decision
strategy to be applied on this set of QoS policy rules by policy
servers. Please see section 5 of this document for more information on
these decision strategies. See attribute definition of
qpPolicyRuleMatchMethod. RSVP Reservation message, as defined in the
   FLOWSPEC RSVP Object [RSVP].
12.	QoSPolicyRSVPMessageTypeVariable - The attribute is RSVP message type, either
   Path, Resv, PathErr or ResvErr [RSVP].
13.	QoSPolicyRSVPPreemptionPriorityVariable - The RSVP reservation
   priority as defined in [RFC2751].
14.	QoSPolicyRSVPPreemptionDefPriorityVariable - The RSVP preemption
   reservation defending priority as follows.

NAME		gpNamedPolicyRuleMatchMethod
SYNTAX	Integer (ENUM) defined in [RFC2751].
15.	QoSPolicyRSVPUserVariable - {"MATCH FIRST" = 0; "MATCH ALL" = 1 }

8.15.3 The Property gpPolicyRoles

This property represents ID of the roles and role combinations associated
with all policy rules contained user that initiated the
   flow as defined 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 the User Locator string in the Identity Policy
   Object [RFC2752].
16.	QoSPolicyRSVPApplicationVariable - The ID of the
form <RoleName>[&&<RoleName>]* where application that
   generated the individual role names appear flow as defined in alphabetical order (according to the collating sequence for UCS-2).
The property definition is as follows:

NAME             gpPolicyRoles
SYNTAX application locator string

8.16. Class qosPolicyPRAction

This class defines DiffServ actions to be applied on a flow or group of
flows, including in
   the marking of a DSCP value, dropping, policing and
shaping.

The association PolicyMeterInAction is used to associate a meter to
qosPolicyPRAction. Application policy object [RFC2872]
17.	QoSPolicyRSVPAuthMethodVariable - The associations PolicyConformNextAction,
PolicyExcessNextAction, PolicyViolateNextAction can be RSVP Authentication type used to link
other actions to be enforced on flows that either conform, exceed or
violate
   in the associated meter and traffic profile.

The Identity Policy Object [RFC2752].

Each class definition is as follows:

NAME		  qosPolicyPRAction
DERIVED FROM  policyAction (defined in [PCIM])
ABSTRACT      False
PROPERTIES	  qpDirection, qpMarkvalue, qpMarkValueType,
              qpExcessAction, qpExcessMarkValue, qpViolateAction,
              qpViolateMarkValue

8.16.1. The Property qpDirection

This property is an enumerated integer that defines whether restricts the action
should be applied to incoming or/and outgoing interfaces. Note that
certain repositories MAY implement this enumeration in possible value types associated with a different
form, as long as its semantics are preserved. specific
variable. For example, a directory the QoSPolicyRSVPSourcePortVariable class is used
to define the source port of the RSVP signaled flow. The value associated
with this variable is of type integer.

Snir, Ramberg, Strassner, Cohen          expires May November 2001             87

MAY implement this property as a multi-valued attribute, with         26

6.  QoS Related Values

Values are used in the
attribute having information model as building blocks for the values IN
policy conditions and OUT. The attribute is defined policy actions, as
follows:

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

8.16.2. The Property qpMarkValue described in [PCIM] and [PCIMe].
This property is an integer that section defines the value for the mark action.
The range a set of auxiliary values depend on the type defined in qpMarkValueType. If
qpMarkValueType property is not defined, qpMarkValue is assumed to
carry DSCP that are
used for QoS policies as well as other policy domains.

All value in classes extend the range of 0-63 inclusive.
defined as follows:

NAME		qpMarkValue
SYNTAX	Integer

8.16.3. PolicyImplicitValue class [PCIMe]. The Property qpMarkValueType

This property is an enumerated integer
subclasses specify specific data/value types that defines the type of marking
value used in this provisioning action.
The attribute is are not defined as follows:

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

8.16.4. The Property qpExcessAction in
[PCIMe].

This property is an enumerated integer that document defines the action to be
applied to out following two subclasses of profile, excess traffic, as defined in the qpTrfcProf
referenced traffic profile instance.
The attribute is defined as follows:

NAME		qpExcessAction
SYNTAX	Integer (ENUM)
PolicyImplicitValue class:

QoSPolicyDNValue - {SHAPE=0,DISCARD=1,REMARK=2}

8.16.5. The Property qpExcessMarkValue This property class is an integer used to represent a single or set of
Distinguished Name [DNDEF] values, including wildcards. A Distinguished
Name is a name that defines the marking value can be used as a key to retrieve an object from a
directory service. This value can be
applied used in comparison to excess out of profile packets if the qpExcessAction action
is defined reference
values carried in RSVP policy objects, as REMARK. Notice that the marking type is defined by the
Provisioning action qpMarkValueType property.
The attribute specified in [RFC2752]. This
class is defined as follows:

NAME		qpExcessMarkValue
SYNTAX	Integer

Snir, Ramberg, Strassner, Cohen         expires May 2001             88

8.16.6. The Property qpViolateAction in Section 8.31.

QoSPolicyAttributeValue - This class is used to represent a single or set
of property is values in an enumerated integer that defines the action to object. This value can be
applied to out of profile, violating traffic, as defined used in the
qpTrfcProf referenced traffic profile instance.
That entry contains conjunction
with reference values for each carried in RSVP objects, as specified in [RFC2752].
The property name is used to specify which of the four types of actions that
are present properties in this attribute: shaping, discarding or remarking.
The attribute the
object is defined being used as follows:

NAME		qpViolateAction
SYNTAX	Integer (ENUM) - {SHAPE=0,DISCARD=1,REMARK=2}

8.16.7. the condition. The Property qpViolateMarkValue

This value of this property will
then be retrieved, and a match (which is an integer that defines dependent on the marking value to property name)
will be
applied used to violating out of profile packets see if the qpViolateAction
action condition is defined as REMARK. Notice satisfied or not.

For example, suppose a User class has a multi-valued Property called
'member-of' that lists the marking type is defined
by the provisioning action qpMarkValueType property.
The attribute is defined as follows:

NAME		qpViolateMarkValue
SYNTAX	Integer

8.17. Class qosPolicyPHBAction

This class defines DiffServ actions to names of groups that this user belongs to.
Suppose this property uses caseIgnoreMatch matching. A simple condition
can be applied in order constructed to provide match the correct Per Hop Behavior across reference carried in an RSVP Identity
policy object to a gpsPolicyAttributeValue with the QoS domain. PHB actions control following
characteristics:

  gpAttributeName="member-of", gpAttributeValueList = "group-A".

A User Identity policy object carrying the bandwidth and buffer resources and congestion control across each
hop. following reference:

  "OU=Sales, CN=J. Smith, O=Widget Inc."

will match this simple condition only if J. Smith belongs to group-a.

Snir, Ramberg, Strassner, Cohen          expires November 2001         27

7.  Class Definitions: Association Hierarchy

The following sections define associations that are specified by QPIM.

7.1. The Association "QosPolicyTrfcProfInAdmissionAction"

This association PolicyQueueInPHBAction is used to associate links a
qosPolicyQueue gpsPolicyTrfcProf object with modeling a PHB action. specific
traffic profile to a QoSPolicyAdmissionAction object. The class
definition for this association is as follows:

NAME		  qosPolicyPHBAction			QosPolicyTrfcProfInAdmissionAction
DESCRIPTION     	A class representing the association between a
                  traffic profile used for admission decision
DERIVED FROM  policyAction (defined in [PCIM])     	Dependency
ABSTRACT      False         	FALSE
PROPERTIES	  qpPHBDirection, qpDropAlgorithm, pDropTreshholdValueType,
              qpDropMinTreshholdValue, qpDropMaxTreshholdValue,
              qpRandomDropInvWeight, qpRandomDropProbMax, qpPacketSize

8.17.1.  	Antecedent[ref QoSPolicyAdmissionAction [0..n]]
                  Dependent[ref QoSPolicyTrfcProf [0..n]]

7.1.1. The Property qpPHBDirection Reference "Antecedent"

This property is an enumerated integer that defines whether inherited from the action
should be applied to incoming or/and outgoing interfaces. Note that
certain repositories MAY implement this enumeration Dependency association, defined 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
[PCIM].  Its type is defined as
follows:

Snir, Ramberg, Strassner, Cohen         expires May 2001             89

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

8.17.2  The Property qpDropAlgorithm overridden to become an object reference to a
QoSPolicyAdmissionAction object. This property specifies represents the congestion control drop algorithm that
should be used for this type "independent" part
of traffic. the association. The attribute is defined as
follows.

NAME		qpDropAlgorithm
SYNTAX	Integer {ENUM} - {alwaysDrop=0,  tailDrop=1, headDrop=2,
            randomDrop=3}

8.17.3 [0..n] cardinality indicates that a given
QoSPolicyAdmissionAction object may have 0 or more traffic profiles that
it can use.

7.1.2. The Property qpDropTreshholdValueType Reference "Dependent"

This property specifies is inherited from the units in which qpDropMinThresholdValue Dependency association, and
qpDropMaxThresholdValue are measured. The attribute is defined as
follows.

NAME		qpDropThresholdValueType
SYNTAX	Integer {ENUM} - {numberOfPackets=0, numberOfBytes=1,
            percentageOfPackets=2, percentageOfBytes=3}

8.17.4  The Property qpDropMinThreshholdValue
overridden to become an object reference to a QoSPolicyTrfcProfile
object. This property specifies the minimal number of queuing and buffer
resources represents a specific traffic profile that should is used by a
given QoSPolicyAdmissionAction. The [0..n] cardinality means that a given
traffic profile may be reserved to this class of flows. used by 0 or more admission actions.

7.2  The threshold
can Association "PolicyConformAction"

This association links a policer action with an object defining
an action to be specified as either applied on conforming traffic relative or absolute value according to the
value of qpDropThresholdValueType property. If associated
traffic profile. The class definition for this property specifies association is as follows:

NAME			PolicyConformAction
DESCRIPTION     	A class representing the association between a value of 5 packets than enough buffer policer
                  action and queuing resources the action that should be
reserved applied on traffic
                  conforming to hold 5 packets before running the specified congestion
control drop algorithm. If this class of an associated traffic profile.
DERIVED FROM     	Dependency
ABSTRACT         	FALSE
PROPERTIES  	Antecedent[ref QoSPolicyPoliceAction[0..n]]
                  Dependent[ref PolicyAction [0..1]]

Snir, Ramberg, Strassner, Cohen          expires November 2001         28

7.2.1. The Reference "Antecedent"

This property is one member of a PHB
group and therefore shares a queue, the drop mechanism should not drop
any packet inherited from this class of traffic before the queue holds 5 packets Dependency association.  Its type is
overridden to become an object reference to a QoSPolicyPoliceAction
object. This represents the "independent" part of the entire PHB group:

NAME		qpDropMinThresholdValue
SYNTAX	Integer

8.17.5 association. The Property qpDropMaxTreshholdValue

This property specifies the maximal
[0..n] cardinality indicates that any number of queuing and buffer
resources that should  QoSPolicyPoliceAction
objects may be reserved given the same action to this class of flows. The threshold
can be specified executed as either relative or absolute value according to the
value of qpDropThresholdValueType property. Congestion Control droppers
should not keep more packets than conforming
action.

7.2.2. The Reference "Dependent"

This property is inherited from the value specified in this property.
Note however, Dependency association, and is
overridden to become an object reference to a PolicyAction object. This
represents a specific policy action that is used by a given
QoSPolicyPoliceAction. The [1..1] cardinality means that some dropper a given
conforming action may calculate queue occupancy averages,
and therefore the actual maximal queue resources should only be larger. used by a single QoSPolicyPoliceAction.

7.3.  The
attribute Association "PolicyExcessAction"

This association links a policer action with an object defining an
action to be applied on traffic exceeding the associated traffic
profile. The class definition for this association is defined as follows:

Snir, Ramberg, Strassner, Cohen         expires May 2001             90

NAME		qpDropMaxThresholdValue
SYNTAX	Integer

8.17.6			PolicyExcessAction
DESCRIPTION       A class representing the association between a
                  policer action and the action that should be applied
                  on traffic exceeding an associated traffic profile.
DERIVED FROM     	Dependency
ABSTRACT         	FALSE
PROPERTIES  	Antecedent[ref QoSPolicePoliceAction[0..n]]
                  Dependent[ref PolicyAction [0..1]]

7.3.1. The Property qpRandomDropInvWeight Reference "Antecedent"

This property specifies is inherited from the random dropper's weighting of past history
in affecting Dependency association.  Its type is
overridden to become an object reference to a QoSPolicyPoliceAction
object. This represents the calculation "independent" part of the current queue average. association. The moving
average of the queue depth uses the inverse
[0..n] cardinality indicates that any number of this value as the factor
for QoSPolicyPoliceAction
objects may be given the new queue depth, and one minus that inverse same action to be executed as the factor for
the historical average [DIFF-MIB]. The attribute is defined as follows:

NAME		qpRandomDropInvWeight
SYNTAX	Integer

8.17.7 exceeding
action.

7.3.2. The Property qpRandomDropProbMax Reference "Dependent"

This property specifies the random dropper's worst case random drop
probability, expressed in drops per thousand packets. The attribute is
defined as follows.

NAME		qpRandomDropProbMax
SYNTAX	Integer

8.17.8  The Property qpPacketSize

This property defines a typical packet size for this class of traffic.
This property inherited from the Dependency association, and is used
overridden to translate threshold values specified in
packets become an object reference to bytes and vice versa. The attribute is defined as follows.

NAME		qpPacketSize
SYNTAX	Integer

8.18. Class qosPolicyRSVPAction a PolicyAction object. This class defines
represents a specific policy action to be applied on an RSVP signaling
message that matches the rule condition. is used by a given
QoSPolicyPoliceAction. The association PolicyMeterInAction can [1..1] cardinality means that a given
exceeding action may only be used to associate by a meter
and single QoSPolicyPoliceAction.

Snir, Ramberg, Strassner, Cohen          expires November 2001         29

7.4.  The Association "PolicyViolateAction"

This association links a policer action with an RSVP traffic profile to object defining an RSVP
action object to enforce an
admission decision. be applied on traffic violating the associated traffic
profile. The class definition for this association is as follows:

NAME		  qosPolicyRSVPAction			PolicyViolateAction
DESCRIPTION       A class representing the association between a
                  policer action and the action that should be applied
                  on traffic violating an associated traffic profile.
DERIVED FROM  policyAction (defined in [PCIM])     	Dependency
ABSTRACT      False         	FALSE
PROPERTIES	  qpRSVPDirection, qpRSVPMessageType, qpRSVPService,
		  qpRSVPStyle,

Snir, Ramberg, Strassner, Cohen         expires May 2001             91

8.18.1.  	Antecedent[ref QoSPolicePoliceAction[0..n]]
                  Dependent[ref PolicyAction [0..1]]

7.4.1. The Property qpRSVPDirection Reference "Antecedent"

This property is inherited from the Dependency association.  Its type is
overridden to become an enumerated integer, and defines whether object reference to a QoSPolicyPoliceAction
object. This represents the "independent" part of the association. The
[0..n] cardinality indicates that any number of QoSPolicyPoliceAction
objects may be given the same action
is to be applied executed as the violating
action.

7.4.2. The Reference "Dependent"

This property is inherited from the Dependency association, and is
overridden to incoming or/and outgoing interfaces. Note become an object reference to a PolicyAction object. This
represents a specific policy action that
certain repositories MAY implement this enumeration in is used by a different
form, as long as its semantics are preserved. For example, given
QoSPolicyPoliceAction. The [1..1] cardinality means that a directory
MAY implement this property as given
violating action may only be used by a multi-valued attribute, with the
attribute having the values IN and OUT. single QoSPolicyPoliceAction.

Snir, Ramberg, Strassner, Cohen          expires November 2001         30

8. Class Definitions: Inheritance Hierarchy

The attribute is defined as
follows:

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

8.18.2. following sections define object classes that are specified by QPIM.

8.1. The Property qpRSVPMessageType Class QoSPolicyDiscardAction

This property class is an enumerated integer, and defines different values
that limit the scope of the action used to specify that packets should be enforced to specific types of
RSVP messages. The attribute is defined as follows:

NAME		qpRSVPMessageType
SYNTAX	Integer (ENUM) - {Path=0 Resv=1 ResvErr=2 PathErr=3}

8.18.3. The Property qpRSVPStyle discarded. This property is an enumerated integer, and defines different values
that limit the scope of
the action to same as stating that packets should be enforced to RSVP Requests with
the specified reservation style. denied forwarding. The attribute class
definition is defined as follows:
NAME		qpRSVPStyle
SYNTAX	Integer (ENUM) - {SE=0 FF=1 WF=2}

8.18.4. The Property qpRSVPServiceType         QoSPolicyDiscardAction
DESCRIPTION  This property is an enumerated integer, and defines different values
that limit the scope of the action to specify that packets should be enforced to RSVP Requests
asking for specified integrated service type. discarded.
DERIVED FROM PolicyAction
ABSTRACT     False
PROPERTIES   None

8.2. The attribute is defined
as follows:

NAME		qpRSVPServiceType
SYNTAX	Integer (ENUM) -
		  {ControlledLoad=0, GuaranteedService=1, NULL=2}

Snir, Ramberg, Strassner, Cohen         expires May 2001             92

8.19. Class qosPolicyRSVPSignalCtrlAction QoSPolicyAdmissionAction

This class extends the functionality of is the qosPolicyRSVPAction base class
by adding detailed control on the signaling protocol behavior itself.
The information carried in for performing admission decisions. It is
used to determine whether to accept or reject a given RSVP messages can be modified using this
action, as well as request. This
is done by comparing the RSVP forwarding behavior.

Since the purpose of this is to augment request's TSPEC or RSPEC parameters against
the behavior traffic profile (as specified by the
qosPolicyRSVPAction class, this class SHOULD be used with a
qosPolicyRSVPAction object, and SHOULD NOT be used by itself.

This class can be extended to support replacement of additional object in RSVP messages, beyond replacement of DCLASS and PREEMPTION object
replacement defined below. the QosPolicyIntServTrfcProf class).
The qpAdmissionScope property controls whether the comparison is done per
flow or per class (of flows). Only packets that conform to the traffic
profile are admitted for further processing; other packets are discarded.
The class definition is as follows:

NAME		  qosPolicyRSVPSignalCtrlAction         QoSPolicyAdmissionAction
DESCRIPTION  This action controls admission decisions based on comparison
             of a meter to a traffic profile.
DERIVED FROM  qosPolicyRSVPAction PolicyAction
ABSTRACT      False     True
PROPERTIES	  qpForwardingMode, qpSendError, qpReplaceDSCP,
              qpReplacePreemptionPriority, qpReplaceDefendingPriority

8.19.1.   qpAdmissionScope

8.2.1. The Property qpForwardingMode qpAdmissionScope

This property attribute specifies whether the admission decision is an enumerated integer that controls done per flow
or per the forwarding entire class of
RSVP messages. flows defined by the rule condition. If the
scope is per flow, the actual or requested rate of each flow is compared
against the traffic profile. If the mode scope is set to proxy, RSVP Path messages are not
forwarded and a Resv message is returned as if class, the Resv was returned by aggregate
actual or requested rate of all flows matching the receiver. Otherwise, RSVP Path messages are forwarded. rule condition is
measured against the traffic profile. The
attribute property is defined as follows:

NAME		qpForwardingMode         qpAdmissionScope
DESCRIPTION  This property specifies whether the admission decision is
             done per flow or per the entire class of flows
SYNTAX       Integer (ENUM) - {Forward=0 , Proxy=1}

8.19.2. The Property qpSendError
VALUE        This property is an enumerated integer and controls the generation integer. A value of
Resv-Err 0 specifies that
             admission is done on a per-flow basis, and Path-Err messages as defined in [COPSRSVP]. The attribute a value of 1
             specifies that admission is defined as follows:

NAME		qpSendError
SYNTAX	Integer {No=0, Yes=1}

8.19.3. done on a per-class basis.

Snir, Ramberg, Strassner, Cohen          expires November 2001         31

8.3. The Property qpReplaceDSCP Class QoSPolicyPoliceAction

This property is a non-negative integer the base class for defining policing actions (e.g., those actions
that allows restrict traffic in some way). Using the three associations
QoSPolicyConformAction, QoSPolicyExceedAction and QoSPolicyViolateAction,
it is possible to specify different actions to take based on whether the
traffic is conforming, exceeding, or violating a traffic profile. The
traffic profile is specified in the QosPolicyTokenBucketTrfcProf class.
The class definition is as follows:

NAME         QoSPolicyPoliceAction
DESCRIPTION  This action controls the replacement operation of policers. The measured
             rate of flows is measured against a DCLASS object carrying a DSCP value in an RSVP message. traffic profile. The attribute
specifies
             action the DSCP value needs to be replaces, performed on conforming, exceeding
             and violating traffic is defined as follows:

Snir, Ramberg, Strassner, Cohen         expires May 2001             93

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

8.19.4. conform, exceed
             and violate action associations.
DERIVED FROM QoSPolicyAdmissionAction
ABSTRACT     False
PROPERTIES   None

8.4. The Property qpReplacePreemptionPriority Class  QoSPolicyShapeAction

This property is a non-negative integer that class is the base class for defining shaping actions. Shapers are
used to replace delay some or add all of the packets in a preemption priority object (defined traffic stream in [RSVP_PREEMP]) order to RSVP
messages.
bring a particular traffic stream into compliance with a given traffic
profile. The attribute traffic profile is specified in the
QosPolicyTokenBucketTrfcProf class. The class definition is defined as follows:

NAME		qpReplacePreemptionPriority
SYNTAX	Integer (must         QoSPolicyShapeAction
DESCRIPTION  This action indicate that traffic should be non-negative)

8.19.5. shaped to be
             conforming with a traffic profile.
DERIVED FROM QoSPolicyAdmissionAction
ABSTRACT     False
PROPERTIES   None

Snir, Ramberg, Strassner, Cohen          expires November 2001         32

8.5. The Property qpReplaceDefendingPriority Class  QoSPolicyRSVPAdmissionAction

This property is a non-negative integer that is used class determines whether to replace accept or add reject a preemption priority object (defined in [RSVP_PREEMP]) to given RSVP
messages. It specifies request by
comparing the defending priority within RSVP request's TSPEC or RSPEC parameters against the preemption
object.
traffic profile. The attribute traffic profile is defined as follows:

NAME		qpReplaceDefendingPriority
SYNTAX	Integer (must be non-negative)

8.20. Class qosPolicyRSVPInstallAction specified in the
QosPolicyIntServTrfcProf class. This class extends the functionality of inherits the qosPolicyRSVPAction class
by adding detailed control for COPS Install decisions (defined in
[COPS]). This action allows assigning a preemption priority with an
RSVP request, to provide a device with information which RSVP requests
to accept in case of admission failures. qpAdmissionScope
property from its superclass. This action property specifies a DSCP
value (which provides an associated level of QoS) to set whether admission
should be done on a per-flow or per-class basis. If the flow
that RSVP traffic profile
is requesting.

Since not larger or equal to the purpose of this is requested reservation, or to augment the behavior specified by sum of the
qosPolicyRSVPAction class, this class SHOULD be used
admitted reservation merged with the requested reservation, the result is
a
qosPolicyRSVPAction object, and SHOULD NOT be used by itself.

This class can be extended to support additional install decisions deny decision. If no traffic profile is specified, the assumption is
that
need to all traffic can be controlled. admitted. The class definition is as follows:

NAME		  qosPolicyRSVPInstallAction         QoSPolicyRSVPAdmissionAction
DESCRIPTION  This action controls the admission of RSVP request.
             Depending on the scope, either a single RSVP request or the
             total admitted RSVP requests matching the conditions are
             compared against a traffic profile.
DERIVED FROM  policyAction (defined in [PCIM]) QoSPolicyAdmissionAction
ABSTRACT     False
PROPERTIES	  qpSetDSCPValue, qpSetPreemptionPriority,
		  qpSetDefendingPriority

Snir, Ramberg, Strassner, Cohen         expires May 2001             94

8.20.1.   qpRSVPWarnOnly, qpRSVPMaxSessions

8.5.1. The Property qpSetDSCPValue

This qpRSVPWarnOnly

When this property is a non-negative integer that defines set to True, the setting of RSVP request is admitted, but an
RSVP error message carrying a
DSCP value in the device. In other words, this attribute controls the
remarking (by the device) of warning is sent to the flow signaled by originator (sender
or receiver). This follows the COPS for RSVP request. The
attribute send error flag in the
Decision Flags object. This property is defined as follows:

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

8.20.2. The Property qpSetDefendingPriority  Boolean
Default False
VALUE   This property is a non-negative integer, and is used to set the
defending priority within the preemption object (defined in
[RSVP_PREEMP]) can have one of two values. The value 1 (TRUE)
        means that the request should be admitted AND an RSVP flows. error
        message should be sent to the originator. The attribute is defined as follows:

NAME		qpSetDefendingPriority
SYNTAX	Integer (must value of 0 (FALSE)
        means that the request should be non-negative)

8.20.3. admitted without sending an RSVP
        error message.

8.5.2. The Property qpSetPreemptionPriority qpRSVPMaxSessions

This property is a non-negative integer, and attribute is used to set limit the
preemption priority [RSVP_PREEMP] total number of RSVP flows. requests
admitted within the specified class of traffic. The attribute qpAdmissionScope
property must be set to class (it is not applicable if the
qpAdmissionScope property is set to "flow"). The definition of this
property is
defined as follows:

NAME		qpSetPreemptionPriority   qpRSVPMaxSessions
SYNTAX Integer (must
VALUE  Must be non-negative)

8.21 greater than 0.

Snir, Ramberg, Strassner, Cohen          expires November 2001         33

8.6. The Class gpsPolicyTrfcProf

An abstract QosPolicyPHBAction

This class that models a traffic profile. Traffic profile
specifies the
maximal rate parameters compared against is a meter. The association
PolicyTrfcProfileInMeter base class that is used to associate between define the two.

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

8.22. Class qosPolicyPRTrfcProf

A provisioning Traffic profile is a class per-hop behavior
that carries the policer or
shaper rate values is to be enforced on a flow or assigned to behavior aggregates. It defines a set of flows. common
property, qpPacketSize, for use by its subclasses
(QoSPolicyBandwidthAction and QoSPolicyCongestionControlAction). The
class definition is as follows:

NAME		  qosPolicyPRTrfcProf         QosPolicyPHBAction
DESCRIPTION  This action controls the Per-Hop-Behavor provided to
             behavior aggregates.
DERIVED FROM  gpsPolicyTrfcProf PolicyAction
ABSTRACT      False     True
PROPERTIES	  qpPRRate, qpPRNormalBurst, qpPRExcessBurst

Snir, Ramberg, Strassner, Cohen         expires May 2001             95

8.22.1.   qpPacketSize

8.6.1. The Property qpPRRate qpPacketSize

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

NAME		qpPRRate
SYNTAX	Integer (must be non-negative)

8.22.2. The Property qpPRNormalBurst
packet. This attribute is an integer that defines the normal size used in translation of QPIM attributes to QoS
mechanisms used within a burst PEP. For example, queue length may be measured
in bytes. The attribute is defined as follows:

NAME		qpPRNormalBurst
SYNTAX	Integer (must be non-negative)

8.22.3. The Property qpPRExcessBurst

This attribute is an integer that defines bytes while the excess size minimum number of packets that should be kept in a burst
measured PEP
is defined within QPIM in bytes.  The attribute number of packets. This property is defined as
follows:

NAME		qpPRExcessBurst   qpPacketSize
SYNTAX Integer (must
Value  Must be non-negative)

8.23. greater than 0

8.7. The Class qosPolicyRSVPTrfcProf QoSPolicyBandwidthAction

This class represents an IntServ RSVP Traffic profile. Values of RSVP
traffic profiles are compared against Traffic specification (TSPEC) is used to control the bandwidth, delay, and
QoS Reservation requests (FLOWSPEC) carried in RSVP requests. Traffic
profiles can be reusable objects or ad-hoc. The forwarding
behavior of a PHB. Its class definition is as follows:

NAME		  qosPolicyRSVPTrfcProf         QoSPolicyBandwidthAction
DESCRIPTION  This action controls the bandwidth, delay, and
             forwarding characteristics of the PHB.
DERIVED FROM  policy (defined in [PCIM]) QoSPolicyPBHAction
ABSTRACT     False
PROPERTIES	  qpRSVPTokenRate, qpRSVPPeakRate,
              qpRSVPBucketSize, qpRSVPResvRate, qpRSVPResvSlack,
              qpRSVPSessionNum, qpMinPolicedUnit, qpMaxPktSize

8.23.1. The Property qpRSVPTokenRate

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

NAME		qpRSVPTokenRate
SYNTAX	Integer (must be non-negative)   qpForwardingPriority, qpBandwidthUnits, qpMinBandwdith,
             qpMaxBandwidth, qpMaxDelay, qpMaxJitter, qpFairness

Snir, Ramberg, Strassner, Cohen          expires May November 2001             96

8.23.2.         34

8.7.1. The Property qpRSVPPeakRate qpForwardingPriority

This property is a non-negative integer that defines the peak rate
parameter, measured in kilo bits per second. The attribute forwarding priority for this set of flows. A
non-zero value indicates that pre-emptive forwarding is defined
as follows:

NAME		qpRSVPPeakRate
SYNTAX	Integer (must be non-negative)

8.23.3. The Property qpRSVPBucketSize required. Higher
values represent higher forwarding priority. This property is a non-negative integer that defines the token bucket
size parameter, measured in bytes. The attribute is defined as
follows:

NAME		qpRSVPBucketSize		qpForwardingPriority
SYNTAX	Integer (must
VALUE       Must be non-negative)

8.23.4. non-negative. The Property qpRSVPResvRate

This property is a non-negative integer value 0 means that defines the RSVP rate (R-
Spec) in the RSVP Guaranteed service reservation. It pre-emptive
            forwarding is measured in
Kilo bits per second. The attribute required. A positive value indicates the
            priority that is defined as follows:

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

8.23.5. assigned for this (set of) flow(s).

8.7.2  The Property qpRSVPResvSlack qpBandwidthUnits

This property is a non-negative integer that defines the RSVP slack
term in what units the RSVP Guaranteed service reservation. It is measured properties qpMinBandwidth and
qpMaxBandwidth are defined. Bandwidth can either be defined in
microseconds. The attribute bits/sec
or in percentage of the available bandwidth or scheduler resources. This
property is defined as follows: follows.

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

8.23.6.
VALUE       Two values are possible. The Property qpRSVPSessionNum

This property value of 0 is a non-negative integer that defines used to specify
            units of bits/sec, while the total number value of allowed RSVP sessions that can be active at any given time. The
attribute 1 is defined used to specify
            units as follows:

NAME		qpRSVPSessionNum
SYNTAX	Integer (must be non-negative)

Snir, Ramberg, Strassner, Cohen         expires May 2001             97

8.23.7. a percentage of the available bandwidth.

8.7.3. The Property qpMinPolicedUnit qpMinBandwidth

This property is a non-negative integer that defines the minimum RSVP
policed unit, measure in bytes. The attribute bandwidth that should be reserved for
this class of traffic. Both relative (i.e., a percentage of the
bandwidth) and absolute (i.e., bits/second) values can be specified
according to the value qpBandwidthUnits property. This property is
defined as follows: follows.

NAME		qpMinPolicedUnit		qpMinBandwidth
SYNTAX	Integer (must
VALUE       The value must be non-negative)

8.23.8. greater than 0.

8.7.4. The Property qpMaxPktSize qpMaxBandwidth

This property is a non-negative integer that defines the maximum
allowed packet size for RSVP messages, measure in bytes. The attribute
is defined as follows:

NAME		qpMaxPktSize
SYNTAX	Integer (must be non-negative)

8.24. Class gpsPolicySimpleCondition

A simple condition is composed of an ordered triplet:
   <Variable>  <Operator>  <Value>
The operator used in all condition definitions in this draft is
the 'match' operator. Such simple conditions are evaluated by answering
the question: Does <variable> match <value>? The operator property can bandwidth that should be extended allocated to support other relations between variable and values.

Simple conditions are building blocks for more complex Boolean
conditions. The gpsPolicySimpleCondition
this class is derived from of traffic. Both relative (i.e., a percentage of the
PolicyCondition class [PCIM]. Simple conditions
bandwidth)and absolute (i.e., bits/second) values can be kept in
repositories for reuse.

A variable and a value must be associated with a simple condition specified
according to
make it a meaningful condition, using the aggregations
PolicyVariableInPolicySimpleCondition and
PolicyValueInPolicySimpleCondition

The class definition value qpBandwidthUnits property. This
property is defined as follows: follows.

NAME		  gpsPolicySimpleCondition
DERIVED FROM  PolicyCondition (defined in [PCIM])
ABSTRACT      False
PROPERTIES	  gpOperator		qpMaxBandwidth
SYNTAX	Integer
VALUE       The value must be greater than 0

Snir, Ramberg, Strassner, Cohen          expires May November 2001             98

8.24.1.         35

8.7.5.  The Property gpOperator qpMaxDelay

This property is an enumerated integer that defines the relation
between a variable
and a value. The default value is match, which has the semantics maximal per-hop delay that traffic 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.
class should experience while being forwarded through this hop.
The attribute maximum delay is measured in milliseconds. This property is defined
as
follows: follows.

NAME		   gpOperator		qpMaxDelay
SYNTAX	Integer - ENUM {0=Match}
DEFAULT (milliseconds)
VALUE  'match'

8.25. Class gpsPolicyCompoundCondition       The gpsPolicyCompoundCondition class is used to represent a Boolean
expression consisting of a set of policyConditions. As such, it can value must be
used to define traffic filters. The gpsPolicyCompoundCondition class is
linked to either a PolicyRule or a PolicyRepository using the
PolicyConditionInPolicyRule and PolicyConditionInPolicyRepository
associations, respectively. Compound conditions are constructed using
the PolicyConditionInCompoundCondition association. The class
definition is as follows:

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

8.25.1. greater than 0

8.7.6.  The Property qpPolicyeConditionListType

The qpPolicyRuleConditionListType indicates whether qpMaxJitter

This property defines the list maximal per-hop delay variance that traffic
of policy
conditions associated with this policy rule class should experience while being forwarded through this hop.
The maximum jitter is measured in disjunctive normal
form (DNF) or conjunctive normal form (CNF). Defined values are DNF(1)
and CNF(2).

The attribute qpPolicyRuleConditionListType milliseconds. This property is defined to be identical
as the policyRuleConditionListType follows.

NAME		qpMaxJitter
SYNTAX	Integer (milliseconds)
VALUE       The value must be greater than 0

8.7.7.  The Property qpFairness

This property defines whether fair queuing is required for this class
of PolicyRule PCIM. The
attribute traffic. This property is defined as follows: follows.

NAME 'policyConditionListType'		qpFairness
SYNTAX INTEGER (ENUM) - {1=DNF, 2=CNF}
DEFAULT VALUE: 1 (DNF)

Snir, Ramberg, Strassner, Cohen         expires May 2001             99

8.26. Class gpsPolicyVariable

Variables are used for building individual conditions.	Integer
VALUE       The variable
specifies the property value of a flow 0 (FALSE) means that should be matched when evaluating
the condition. However, fair queuing is not every combination
            required for this class of a variable and a value
creates a meaningful condition. For example, a source IP address
variable can not be matched against a value that specifies a port
number. A given variable selects traffic, while the set of matchable value types.
A variable can have constraints that limit the set of values within a
particular value type 1
            (TRUE) means that can be matched against it in a condition.
For example, a source-port variable limits the set of values to
represent integers to the range of 0-65535. Integers outside fair queuing is required for this range
can not be matched class
            of traffic.

8.8. The Class QoSPolicyCongestionControlAction

This class is used to control the source-port variable, even though they are characteristics of the correct data type. Constraints for a given variable are indicated
through the PolicyValueConstraintsInVariable association. congestion
control algorithm being used. The class definition is as follows:

NAME		  gpsPolicyVariable         QoSPolicyCongestionControlAction
DESCRIPTION  This action control congestion control characteristics of
             the PHB.
DERIVED FROM  policy (defined in [PCIM]) QoSPolicyPBHAction
ABSTRACT     False
PROPERTIES	  gpVariableName, gpValueTypes, gpVariableDescription,

8.26.1.   qpQueueSizeUnits, qpQueueSize, qpDropAlgorithm,
             qpDropThresholdUnits, qpDropMinThresholdValue,
             qpDropMaxThresholdValue

Snir, Ramberg, Strassner, Cohen          expires November 2001         36

8.8.1. The Property gpVariableName

This property is a string that provides a unique name for the variable. qpQueueSizeUnits

This is very important, because property specifies the QPIM defines a correlation between
its pre-defined variable names and their logical bindings. This
correlation was defined earlier units in Table 2. The which the qpQueueSize attribute is defined as
follows:

NAME		gpVariableName
SYNTAX	String, whose values are defined in table 2

8.26.2
measured. The Property gpValueTypes

This property queue size is a string that specifies an unordered list measured either in number of possible
value types that can be used packets or in a simple condition together with
units of time. The time interval specifies the time needed to transmit
all packets within the queue if the link speed is dedicated entirely for
transmission of packets within this
variable. queue. The property definition is:
NAME		qpQueueSizeUnits
SYNTAX	IntegerVALUE       This property can have two values. If the
value types are specified by their class names. The list
of class names enables an application to search for a specific is set of
class names, as well as ensure that to 0,
            then the data type unit of measurement is number of packets. If the
            value is of set to 1, then the correct type. The list of class names was defined earlier in Table
2. The list unit of default qpValueTypes for each Variable measurement is defined
earlier in Table 3.
            milliseconds.

8.8.2. The attribute Property qpQueueSize

This property specifies the queue size in packets or in milliseconds,
depending on the value of the qpQueueSizeUnits (0 specifies packets, and
1 specifies milliseconds). This property is defined as follows:

NAME		gpValueTypes		qpQueueSize
SYNTAX	String

Snir, Ramberg, Strassner, Cohen         expires May 2001            100

8.26.2.	Integer
VALUE       This value must be greater than 0

8.8.3.  The Property gpVariableDescription qpDropAlgorithm

This property is a string specifies the congestion control drop algorithm that provides a textual description
should be used for this type of the
variable. The attribute traffic. This property is defined as follows:
follows.

NAME		gpVariableDescription		qpDropAlgorithm
SYNTAX	String

8.27. Class gpsPolicyValue

This is an abstract class that serves as the base class for all
subclasses that	Integer
VALUES      Three values are used to define currently defined. The value objects in 0 specifies a
            random drop algorithm, the QPIM. It is
used for defining values value 1 specifies a tail drop
            algorithm, and  constants used in policy conditions. the value 2 specifies a head drop algorithm.

8.8.4.  The
class definition is as follows:

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

8.28. Class gpsPolicyIPv4AddrValue Property qpDropThresholdUnits

This class is used to provide a list of IPv4Addresses, hostnames and
address range values to property specifies the units in which the two properties
qpDropMinThresholdValue and qpDropMaxThresholdValue are measured.
Thresholds can be matched against measured either in a policy condition. The
class definition packets or in percentage of the
available queue sizes. This property is defined as follows: follows.

NAME		  gpsPolicyIPv4AddrValue
DERIVED FROM  gpsPolicyValue
ABSTRACT      False
PROPERTIES	  gpIPv4AddrList

8.28.1.		qpDropThresholdUnits
SYNTAX	Integer
VALUES      Two values are defined. The Property gpIPv4AddrList

This Property provides an unordered list of strings, each specifying a
single IPv4 address, a hostname, or a range of IPv4 addresses,
according to value 0 defines the ABNF definition [ABNF] of an IPv4 address units as specified
below:

      IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
      IPv4prefix  = IPv4address "/" 1*2DIGIT
      IPv4range = IPv4address"-"IPv4address
      IPv4maskedaddress = IPv4address","IPv4address
      Hostname (as defined in [NAMES])

In
            number of packets, and the above definition, each string entry is either:

  1. A single Ipv4address in dot notation value 1 defines the units
            as defined above.
     Example: 121.1.1.2 a percentage of the queue size.

Snir, Ramberg, Strassner, Cohen          expires May November 2001            101
  2. A single Hostname. Hostname format follows         37

8.8.5.  The Property qpDropMinThresholdValue

This property specifies the guidelines minimum number of queuing and
     restrictions specified in [NAMES].
     Example: www.bigcompany.com

  3. An IPv4range address range defined above, buffer
resources that should be reserved for this class of flows. The threshold
can be specified by as either relative (i.e., a start
     address in dot notation and an end address in dot notation,
     separated by "-". The range includes all addresses between percentage) or absolute
(i.e., number of packets) value according to the
     range's start value of
qpDropThresholdUnits property. If this property specifies a value of 5
packets, then enough buffer and end addresses, including queuing resources should be reserved to
hold 5 packets before running the start and end
     addresses.
     Example: 1.1.22.1-1.1.22.5

  4. An IPv4maskedaddress address range defined above, specified by an
     address and mask. The address and mask are represented in dot
     notation separated by a comma ",".
     Example: 2.3.128.0,255.255.248.0.

  5. An IPv4prefix address range defined above specified by an address
     and a prefix length separated by "/".
     Example: 2.3.128.0/15

The class definition is as follows:

NAME		gpIPv4AddrList
SYNTAX	String
FORMAT       IPv4address | hostname | IPv4addressrange |
             IPv4maskedaddress | IPv4prefix

8.29. Class gpsPolicyIPv6AddrValue congestion control drop
algorithm. This class is used to define a list of IPv6 addresses, hostnames, and
address range values. The class definition property is defined as follows:

NAME		  gpsPolicyIPv6AddrValue
DERIVED FROM  gpsPolicyValue
ABSTRACT      False
PROPERTIES	  gpIPv6AddrList

8.29.1.		qpDropMinThresholdValue
SYNTAX	Integer
VALUE       This value must be greater than 0

8.8.6.  The Property gpIPv6AddrList qpDropMaxThresholdValue

This property provides an unordered list specifies the maximum number of strings, each specifying an
IPv6 address, a hostname, or a range queuing and buffer
resources that should be reserved for this class of IPv6 addresses. IPv6 address
format definition uses the standard address format defined in [IPv6]. flows. The ABNF definition [ABNF] as threshold
can be specified in [IPv6] is:

      IPv6address = hexpart [ ":" IPv4address ]
      IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
      IPv6prefix  = hexpart "/" 1*2DIGIT
      hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
      hexseq  = hex4 *( ":" hex4)
      hex4    = 1*4HEXDIG
      IPv6range = IPv6address"-"IPv6address

Snir, Ramberg, Strassner, Cohen         expires May 2001            102
      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 either relative (i.e., a start address in dot
     notation and an end address in dot notation, separated by "-".
     The range includes all addresses between percentage) or absolute
(i.e., number of packets) value according to the range's start and end
     addresses, including value of the start and end addresses.
  4. An IPv4maskedaddress address range defined above
qpDropThresholdUnits property. Congestion Control droppers should not
keep more packets than the value specified by an
     address and mask. The address and mask are represented in dot
     notation separated by a comma ",".
  5. A single IPv6prefix as this property. Note,
however, that some droppers may calculate queue occupancy averages,
and therefore the actual maximum queue resources should be larger. This
property is defined above. as follows:

NAME		gpIPv6AddrList		qpDropMaxThresholdValue
SYNTAX	String
FORMAT      IPv6address | hostname | IPv6addressrange |
            IPv6maskedaddress | IPv6prefix

8.30.	Integer
VALUE       This value must be greater than 0

8.9. Class gpsPolicyMACAddrValue QoSPolicyTrfcProf

This class is an abstract base class that models a traffic profile. Traffic
profiles specify the maximum rate parameters used within admission
decisions. The association QosPolicyTrfcProfInAdmissionAction binds the
admission decision to define a list of MAC addresses and MAC address
range values. the traffic profile. The class definition is as
follows:

NAME		  gpsPolicyMACAddrValue		  QoSPolicyTrfcProf
DERIVED FROM  gpsPolicyValue  Policy
ABSTRACT      False      True
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.    None

Snir, Ramberg, Strassner, Cohen          expires May November 2001            103

NAME		gpMACAddrList
SYNTAX	String
FORMAT      MACaddress | MACmaskedaddress

8.31.         38

8.10. Class gpsPolicyStringValue QosPolicyTokenBucketTrfcProf

This class is used models a two- or three-level Token Bucket traffic profile.
This traffic profile carries the policer or shaper rate values to represent be
enforced on a single flow or a set of string values. Each
can have wildcards. flows. The class definition is as follows:

NAME		  gpsPolicyStringValue	        QosPolicyTokenBucketTrfcProf
DERIVED FROM  gpsPolicyValue  QoSPolicyTrfcProf
ABSTRACT      False
PROPERTIES	  gpStringList

8.31.1.	  qpTBRate, qpTBNormalBurst, qpTBExcessBurst

8.10.1. The Property gpStringList qpTBRate

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 non-negative integer that defines the token rate in kilobits
per second. A rate of zero means that all packets will be out of
profile. This property is defined as follows:

NAME		qpTBRate
SYNTAX	Integer
VALUE       This value
"abc*def*" match "abcxxxdefyyyzzz". must be greater than 0

8.10.2. The syntax definition Property qpTBNormalBurst

This property is identical
to an integer that defines the substring assertion syntax defined normal size of a burst
measured in [LDAP_ATTR]. If the
asterisk character bytes. This property is required defined as part of the string follows:

NAME		qpTBNormalBurst
SYNTAX	Integer
VALUE       This value itself, it
MUST must be quoted as described in section 4.3 of [LDAP_ATTR]. greater than 0

8.10.3. The attribute definition Property qpTBExcessBurst

This property is an integer that defines the excess size of a burst
measured in bytes.  This property is defined as follows:

NAME			gpStringList		qpTBExcessBurst
SYNTAX		String

8.32	Integer
VALUE       This value must be greater than 0

Snir, Ramberg, Strassner, Cohen          expires November 2001         39

8.11. Class gpsPolicyBitStringValue qosPolicyIntServTrfcProf

This class is used to represent a single or set represents an IntServ traffic profile. Values of bit string values. IntServ
traffic profiles are compared against Traffic specification (TSPEC) and
QoS Reservation (FLOWSPEC) requests carried in RSVP requests. The class
definition is as follows:

NAME		  gpsPolicyBitStringValue		  qosPolicyIntServTrfcProf
DERIVED FROM  gpsPolicyValue  QosPolicyTrfcProf
ABSTRACT      False
PROPERTIES	  gpBitStringList

8.32.1.	  qpISTokenRate, qpISPeakRate, qpISBucketSize, qpISResvRate,
              qpISResvSlack, qpISMinPolicedUnit, qpISMaxPktSize

8.11.1. The Property gpBitStringList qpISTokenRate

This property provides an unordered list of strings, each representing
a single bit string or is a set of bit strings. The number of bits
specified SHOULD equal the number of bits of non-negative integer that defines the expected variable. For
example, for an 8-bit byte variable, 8 bits should token rate
parameter, measured in kilobits per second. This property is defined as
follows:

NAME		qpISTokenRate
SYNTAX	Integer
VALUE       This value must be specified. If the
variable does not have greater than 0

8.11.2. The Property qpISPeakRate

This property is a fixed length, non-negative integer that defines the bit string should peak rate
parameter, measured in kilobits per second. This property is defined as
follows:

NAME		qpISPeakRate
SYNTAX	Integer
VALUE       This value must be matched
against the variable most significant bit string. greater than 0

8.11.3. The formal
definition of a bit string is:

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

Each string entry Property qpISBucketSize

This property 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 non-negative integer that defines the significant bits token bucket
size parameter, measured in the bit string value. For example, 110110, 100110 and 110111
     would match the maskedBitString 100110,101110 but 100100 would
     not. bytes. This property is defined as follows:

NAME		gpBitStringList		qpISBucketSize
SYNTAX	String
FORMAT      bitString | maskedBitString

8.33. Class gpsPolicyDNValue	Integer
VALUE       This value must be greater than 0

Snir, Ramberg, Strassner, Cohen          expires November 2001         40

8.11.4. The Property qpISResvRate

This class property is used to represent a single or set of Distinguished
Name [DNDEF] values, including wildcards. non-negative integer that defines the reservation rate
(R-Spec) in the RSVP guaranteed service reservation. It is measured in
kilobits per second. This value type property 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. follows:

NAME		qpISResvRate
SYNTAX	Integer
VALUE       This value can must be
used in  comparison to reference values carried greater than 0

8.11.5. The Property qpISResvSlack

This property is a non-negative integer that defines the RSVP slack
term in the RSVP policy objects,
as specified guaranteed service reservation. It is measured in [IDENT].

The class definition
microseconds. This property is defined as follows:

NAME		  gpsPolicyDNValue
DERIVED FROM  gpsPolicyValue
ABSTRACT      False
PROPERTIES	  qpDNList

8.33.1.		qpISResvSlack
SYNTAX	Integer
VALUE       This value must be greater than 0

8.11.6. The Property qpDNList qpISMinPolicedUnit

This attribute provides an unordered list of strings, each representing
a Distinguished Name (DN) with wildcards. The format of a DN property is defined a non-negative integer that defines the minimum RSVP
policed unit, measured in [DNDEF]. The asterisk character ("*") bytes. This property is used defined as wildcard for either
a single attribute follows:

NAME		qpISMinPolicedUnit
SYNTAX	Integer
VALUE       This value or a wildcard for an RDN. must be greater than 0

8.11.7. The order of RDNs Property qpISMaxPktSize

This property is
significant. For example: A qpDNList attribute carrying a non-negative integer that defines the following
value: "OU=Sales, CN=*, O=Widget Inc., *, C=US"
matches: "OU=Sales, CN=J. Smith, O=Widget Inc, C=US" and also matches:
"OU=Sales, CN=J. Smith, O=Widget Inc, C=US, CN=CA".

The attribute maximum
allowed packet size for RSVP messages, measure in bytes. This property is
defined as follows:

NAME		qpISMaxPktSize
SYNTAX	Integer
VALUE       This value must be greater than 0

Snir, Ramberg, Strassner, Cohen          expires May November 2001            105

NAME		qpDNList
SYNTAX	List of Distinguished Names implemented as strings, each of
            which serves as a reference to another object.

8.34.         41

8.12. The Class gpsPolicyAttributeValue QosPolicyAttributeValue

This class is used to represent a single or set of property values in
an object. This value can be used in conjunction with reference values
carried in RSVP objects, as specified in [IDENT]. [RFC2751]. The property name is
used to specify which of the properties in the object is being used as
the condition. The value of this property will then be retrieved, and a
match (which is dependent on the property name) will be used to see if
the condition is satisfied or not.

For example, suppose a User The class has a multi-valued definition is as follows:

NAME         QosPolicyAttributeValue
DERIVED FROM PolicyImplicitValue
ABSTRACT     False
PROPERTIES   qpAttributeName, qpAttributeValueList

8.12.1. The Property called
'member-of' that lists qpAttributeName

This property defines the names name of groups the attribute that this user belongs to.
Suppose this property uses caseIgnoreMatch matching. A simple condition
can the list of values
should be constructed compared against. This property is defined as follows:

NAME     qpAttributeName
SYNTAX   String

8.12.2. The Property qpAttributeValueList

This property contains a list of attribute values. Each value is compared
to match a value of the reference carried in property specified by the qpAttributeName property.
This property is defined as follows:

NAME     qpAttributeValueList
SYNTAX   String

8.13. The Class "QoSPolicyRSVPVariable"

This is an abstract class that serves as the base class for all implicit
variables that have to do with RSVP Identity
policy object conditioning. The class definition is
as follows:

NAME         QoSPolicyRSVPVariable
DESCRIPTION  An abstract base class used to build other classes that
             specify different attributes of an RSVP request
DERIVED FROM PolicyImplicitVariable
ABSTRACT     TRUE
PROPERTIES   None

Snir, Ramberg, Strassner, Cohen          expires November 2001         42

8.14. The Class "QoSPolicyRSVPSourceIPv4Variable"

This is a gpsPolicyAttributeValue with concrete class that contains the following
characteristics:
  gpAttributeName="member-of",
  gpAttributeValueList = "group-A".

An Identity policy object carrying source IPv4 address of the following reference:
  "OU=Sales, CN=J. Smith, O=Widget Inc."
will match this simple condition only if J. Smith belongs to group-a.
RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP
RESV FILTER_SPEC [RSVP] objects. The class definition is as follows:

NAME		  gpsPolicyAttributeValue         QoSPolicyRSVPSourceIPv4Variable
DESCRIPTION  The source IPv4 address of the RSVP signaled flow, as
             defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV
             FILTER_SPEC [RSVP] objects.

             ALLOWED VALUE TYPES: PolicyIPv4AddrValue

DERIVED FROM  gpsPolicyValue QoSPolicyRSVPVariable
ABSTRACT      False     FALSE
PROPERTIES	  gpAttributeName, gpAttributeValueList

8.34.1.   None

8.15. The Property gpAttributeName Class "QoSPolicyRSVPDestinationIPv4Variable"

This attribute defines is a concrete class that contains the name destination IPv4 address of
the property that RSVP signaled flow, as defined in the list of values
should be compared against. RSVP PATH SENDER_TEMPLATE and
RSVP RESV FILTER_SPEC [RSVP] objects. The attribute class definition is defined as follows:

NAME		gpAttributeName
SYNTAX	String

8.34.2.         QoSPolicyRSVPDestinationIPv4Variable
DESCRIPTION  The Property gpAttributeValueList

This attribute contains a list destination IPv4 address of property values. Each value the RSVP signaled flow,
             as defined in the RSVP PATH and RESV SESSION [RSVP] objects.

             ALLOWED VALUE TYPES: PolicyIPv4AddrValue

DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT     FALSE
PROPERTIES   None

8.16. The Class "QoSPolicyRSVPSourceIPv6Variable"

This is
compared to a value concrete class that contains the source IPv6 address of the property specified by gpAttributeName.
RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP
RESV FILTER_SPEC [RSVP] objects. The
attribute class definition is defined as follows:

NAME		gpAttributeValueList
SYNTAX	String         QoSPolicyRSVPSourceIPv6Variable
DESCRIPTION  The source IPv6 address of the RSVP signaled flow, as
             defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV
             FILTER_SPEC [RSVP] objects.

             ALLOWED VALUE TYPES: PolicyIPv6AddrValue

DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT     FALSE
PROPERTIES   None

Snir, Ramberg, Strassner, Cohen          expires May November 2001            106

8.35.         43

8.17. The Class gpsPolicyIntegerValue "QoSPolicyRSVPDestinationIPv6Variable"

This class provides is a list concrete class that contains the destination IPv6 address of integer
the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and integer range values.
Integers
RSVP RESV FILTER_SPEC [RSVP] objects. The class definition is as follows:

NAME         QoSPolicyRSVPDestinationIPv6Variable
DESCRIPTION  The destination IPv6 address of arbitrary sizes can be represented. For a given variable, the set of possible ranges of integer values allowed RSVP signaled flow,
             as defined in the RSVP PATH and RESV SESSION [RSVP] objects.

             ALLOWED VALUE TYPES: PolicyIPv6AddrValue

DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT     FALSE
PROPERTIES   None

8.18. The Class "QoSPolicyRSVPSourcePortVariable"

This is specified via a concrete class that contains the source port of the RSVP
signaled flow, as defined in the variable's gpValueConstraints Property. RSVP PATH SENDER_TEMPLATE and RSVP RESV
FILTER_SPEC [RSVP] objects. The class definition is as follows:

NAME		  gpsPolicyIntegerValue         QoSPolicyRSVPSourcePortVariable
DESCRIPTION  The source port of the RSVP signaled flow, as defined in the
             RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP]
             objects.

             ALLOWED VALUE TYPES: Integer

DERIVED FROM  gpsPolicyValue QoSPolicyRSVPVariable
ABSTRACT      False     FALSE
PROPERTIES	  gpIntegerList

8.35.1.   None

8.19. The Property gpIntegerList Class "QoSPolicyRSVPDestinationPortVariable"

This property provides an unordered list of integers and integer range
values. The format of this property can take on of the following forms:

  1. An integer value.
  2. A range of integers. The range is specifies by a start integer and
     an end integer separated by "-". The range includes all integers
     between start and end integers, including concrete class that contains the start and end
     integers.

To represent a range destination port of integers that is not bounded, the reserved word
INFINITY can be used RSVP
signaled flow, as defined in the end range integer.

The ABNF definition [ABNF] is:

      integer = 1*DIGIT | "INFINITY"
      integerrange = integer"-"integer

Using ranges, the operators greater-than, greater-than-or-equal-to,
less-than RSVP PATH SENDER_TEMPLATE and less-than-or-equal-to can be expressed. This enables the
match condition semantics of the gpOperator property of the
gpsPolicySimpleCondition class to be kept simple (i.e., just the value
"match"). RSVP RESV
FILTER_SPEC [RSVP] objects. The attribute class definition is defined as follows. follows:

NAME		gpIntegerList
SYNTAX	String
FORMAT      integer | integerrange         QoSPolicyRSVPDestinationPortVariable
DESCRIPTION  The destination port of the RSVP signaled flow, as defined
             in the RSVP PATH and RESV SESSION [RSVP] objects.

             ALLOWED VALUE TYPES: Integer

DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT     FALSE
PROPERTIES   None

Snir, Ramberg, Strassner, Cohen          expires May November 2001            107

8.36 Class gpsPolicyMeter

This class models a meter. Within provisioning actions, meters measure
the temporal properties of the stream  of packets selected by a
classifier against a traffic profile. Within Signaling policies, meters
measure the temporal resource allocations for flows matching a rule's
condition. A traffic profile is associated to a meter using the
PolicyTrfcProfileInMeter association.
A meter can be shared between different policy rules. A meter shared by
more than one policy rule resides in a repository and is referenced by
all sharing rules. A meter         44

8.20. The Class "QoSPolicyRSVPIPProtocolVariable"

This is associated with an action using a concrete class that contains the
PolicyMeterInAction association. IP Protocol number of the RSVP
signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP]
objects. The class definition is defined as follows:

NAME		  gpsPolicyMeter         QoSPolicyRSVPIPProtocolVariable
DESCRIPTION  The IP Protocol number of the RSVP signaled flow, as defined
             in the RSVP PATH and RESV SESSION [RSVP] objects.

             ALLOWED VALUE TYPES: Integer

DERIVED FROM  policy (defined in [PCIM]) QoSPolicyRSVPVariable
ABSTRACT      True     FALSE
PROPERTIES    gpMeterScope, gpMeterTimeInterval

8.36.1.   None

8.21. The Property gpMeterScope Class "QoSPolicyRSVPIPVersionVariable"

This property is an enumerated integer that defines whether this
metering action should be applied on a per-flow, per-interface,
per-role within a device, per device or per role across all devices. concrete class that contains the IP Protocol version number of
the RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION
[RSVP] objects. The attribute well-known version numbers are 4 and 6. The class
definition is defined as follows:

NAME		gpMeterScope
SYNTAX         QoSPolicyRSVPIPVersionVariable
DESCRIPTION  The IP version number of the IP Addresses carried the RSVP
             signaled flow, as defined in the RSVP PATH and RESV SESSION
             [RSVP] objects.

             ALLOWED VALUE TYPES: Integer (ENUM) {flow=0,interface=1 role-in-device=2,
            device=3, role=4}

8.36.2.

DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT     FALSE
PROPERTIES   None

8.22. The Property gpMeterTimeInterval Class "QoSPolicyRSVPDCLASSVariable"

This optional property specifies is a concrete class that contains the time interval used to measure
traffic DSCP value as defined in microseconds. the
RSVP DCLASS [DCLASS] object. The attribute class definition is defined as follows:

NAME		gpMeterTimeInterval
SYNTAX	Integer         QoSPolicyRSVPDCLASSVariable
DESCRIPTION  The DSCP value as defined in the RSVP DCLASS [DCLASS]
             object.

             ALLOWED VALUE TYPES: Integer, BitString

DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT     FALSE
PROPERTIES   None

Snir, Ramberg, Strassner, Cohen          expires May November 2001            108

8.37         45

8.23. The Class qosPolicyQueue "QoSPolicyRSVPStyleVariable"

This class models is a sharable queue used by more than one policy rule.
A set of actions defining PHBs may be associated to concrete class that contains the reservation style as defined
in the RSVP STYLE object in the RESV message [RSVP]. The class definition
is as follows:

NAME         QoSPolicyRSVPStyleVariable
DESCRIPTION  The reservation style as defined in the same queue RSVP STYLE object using
             in the PolicyQueueInPHBAction association to indicate RESV message [RSVP].

             ALLOWED VALUE TYPES: BitString, Integer (Integer has an
                                  enumeration of { Fixed-Filter=1 ,
                                  Shared-Explicit=2,
                                  Wildcard-Filter=3}

DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT     FALSE
PROPERTIES   None

8.24. The Class "QoSPolicyIntServVariable"

This is a concrete class that
they belong to contains the same PHB group. Bandwidth and Delay attributes are
than managed for Integrated Service requested
in the entire PHB group RSVP Reservation message, as defined in a single place. the FLOWSPEC RSVP Object
[RSVP]. The class definition is defined as follows:

NAME		  qosPolicyQueue         QoSPolicyRSVPIntServVariable
DESCRIPTION  The integrated Service requested in the RSVP Reservation
             message, as defined in the FLOWSPEC RSVP Object [RSVP].

             ALLOWED VALUE TYPES: Integer (An enumerated value of
                                           { CL=1 , GS=2, NULL=3}

DERIVED FROM  policy (defined in [PCIM]) QoSPolicyRSVPVariable
ABSTRACT      True     FALSE
PROPERTIES    qpForwardingPriority, qpBandwidthValueType,
              qpMinBandwidth, qpMaxBandwidth, qpMaxDelay, qpMaxJitter,
              qpFairQueue

8.37.1.   None

8.25. The Property qpForwardingPriority Class "QoSPolicyRSVPMessageTypeVariable"

This property defines the forwarding priority that should be given to
this set of flows. A non zero value indicate is a concrete class that preemptive forwarding
should be provided to contains the class of traffic. Higher values represent
higher forwarding priority. RSVP message type, as defined
in the RSVP message common header [RSVP] object. The attribute class definition is defined
as follows. follows:

Snir, Ramberg, Strassner, Cohen          expires November 2001         46

NAME		qpForwardingPriority
SYNTAX         QoSPolicyRSVPMessageTypeVariable
DESCRIPTION  The RSVP message type, as defined in the RSVP message
             common header [RSVP] object.

             ALLOWED VALUE TYPES: Integer

8.37.2. (An enumerated value of
                                    { PATH=1 , PATHTEAR=2, RESV=3,
                                      RESVTEAR=4, ResvErr=5, CONF=6}

DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT     FALSE
PROPERTIES   None

8.26. The Property qpBandwidthValueType Class "QoSPolicyRSVPPreemptionPriorityVariable"

This property defines in what units is a concrete class that contains the properties qpMinBandwidth and
qpMaxBandwidth are defined. Bandwidth can either be RSVP reservation priority, as
defined in bits/sec
or in percentage of the available bandwidth or scheduler resources. [RSVP_PREEMP] object. The
attribute class definition is defined as follows. follows:

NAME		qpBandwidthValueType
SYNTAX         QoSPolicyRSVPPreemptionPriorityVariable
DESCRIPTION  The RSVP reservation priority as defined in [RSVP_PREEMP].

             ALLOWED VALUE TYPES: Integer {ENUM} - {bits/sec=0, percentage=1}

8.37.3.

DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT     FALSE
PROPERTIES   None

8.27. The Property qpMinBandwidth Class "QoSPolicyRSVPPreemptionDefPriorityVariable"

This property defines the minimal bandwidth that should be reserved to
this is a concrete class of traffic. Both relative and absolute values can be
specified according to that contains the value qpBandwidthValueType property. RSVP reservation defending
priority, as defined in [RSVP_PREEMP] object. The
attribute class definition is defined as follows.
follows:

NAME		qpMinBandwidth
SYNTAX         QoSPolicyRSVPPreemptionDefPriorityVariable
DESCRIPTION  The RSVP preemption reservation defending priority as
             defined in [RSVP_PREEMP].

             ALLOWED VALUE TYPES: Integer

DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT     FALSE
PROPERTIES   None

Snir, Ramberg, Strassner, Cohen          expires May November 2001            109

8.37.4.         47

8.28. The Property qpMaxBandwidth Class "QoSPolicyRSVPUserVariable"

This property defines the maximal bandwidth that should be allocated to
this is a concrete class that contains the ID of traffic. Both relative and absolute values can be
specified according to the value qpBandwidthValueType property. The
attribute is defined user that initiated
the flow as follows.

NAME		qpMaxBandwidth
SYNTAX	Integer

8.37.5  The Property qpMaxDelay

This property defines defined in the maximal per hop delay that traffic of this
class should experience while being forwarded through this hop.
The maximal delay is measured User Locator string in milliseconds. the Identity Policy
Object [RFC2752]. The attribute class definition is defined as follows. follows:

NAME		qpMaxDelay
SYNTAX	Integer (milliseconds)

8.37.6         QoSPolicyRSVPUserVariable
DESCRIPTION  The Property qpMaxJitter

This property defines ID of the maximal per hop delay variance user that traffic
of this class should experience while being forwarded through this hop.
The maximal jitter is measured in milliseconds. The attribute is
defined initiated the flow as follows.

NAME		qpMaxJitter
SYNTAX	Integer (milliseconds)

8.37.7  The Property qpPacketSize

This property defines a typical packet size for this class of traffic.
This property is used to translate threshold values specified defined in
packets to bytes and vice versa.

NAME		qpPacketSize
SYNTAX	Integer

8.37.8
             the User Locator string in the Identity Policy Object
             [RFC2752].

             ALLOWED VALUE TYPES: QoSPolicyDNValue, PolicyStringValue,
                                  QosPolicyAttributeValue

DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT     FALSE
PROPERTIES   None

8.29. The Property qpFairQueue Class "QoSPolicyRSVPApplicationVariable"

This property defines whether fair queuing is required for this a concrete class that contains the ID of traffic. the application that
generated the flow as defined in the application locator string in the
Application policy object [RFC2872]. The attribute class definition is defined as follows. follows:

NAME		qpFairQueue
SYNTAX	Integer {Boolean} - {FALSE=0, TRUE=1}         QoSPolicyRSVPApplicationVariable
DESCRIPTION  The ID of the application that generated the flow as
             defined in the application locator string in the
             Application policy object [RFC2872].

             ALLOWED VALUE TYPES: QoSPolicyDNValue, PolicyStringValue,
                                  QosPolicyAttributeValue

DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT     FALSE
PROPERTIES   None

Snir, Ramberg, Strassner, Cohen          expires May November 2001            110

9. Extending the QoS Policy Schema         48

8.30. The following subsections provide general guidance on how to create Class "QoSPolicyRSVPAuthMethodVariable"

This is a
domain-specific information model derived from the QPIM by extending
the QoS policy classes.

9.1. Extending gpsPolicyValue

The gpsPolicyValue concrete class and its subclasses describe that contains the common
value types type of authentication used in
the QPIM. When other specific types are required,
such Identity Policy Object [RFC2752]. The class definition is as a floating-point numbers, follows:

NAME         QoSPolicyRSVPAuthMethodVariable
DESCRIPTION  The RSVP Authentication type used in the required Identity Policy
             Object [RFC2752].

             ALLOWED VALUE TYPES: Integer (An enumeration of { NONE=0,
                                  PLAIN-TEXT=1, DIGITAL-SIG = 2,
                                  KERBEROS_TKT=3, X509_V3_CERT=4,
                                  PGP_CERT=5}

DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT     FALSE
PROPERTIES   None

8.31. The Class QoSPolicyDNValue

This class SHOULD is used to represent a single or set of Distinguished Name
[DNDEF] values, including wildcards. A Distinguished Name is a name that
can be derived used as a key to retrieve an object from the gpsPolicyValue class and properties that contain the
corresponding values SHOULD a directory service. This
value can be added.

Notice that used in many cases, using the gpsPolicyAttributeValue comparison to reference values carried in RSVP
policy objects, as specified in [RFC2752].

The class
allows the definition is as follows:

NAME          QoSPolicyDNValue
DERIVED FROM  PolicyImplicitValue
ABSTRACT      False
PROPERTIES    qpDNList

8.31.1. The Property qpDNList

This attribute provides an unordered list of strings, each representing
a Distinguished Name (DN) with wildcards. The format of non-standard policy atoms without extending
the gpsPolicyValue class.

9.2. Extending gpsPolicySimpleCondition a DN is defined
in [DNDEF]. The gpsPolicySimpleCondition class asterisk character ("*") is used to describe as wildcard for either
a single atomic
Boolean condition. For Boolean conditions that are not structured as
the ordered triple <variable - relation - value>, attribute value or a new type wildcard for an RDN. The order of
condition class SHOULD be defined. An example would be a unary
condition.

Subclassing could be done using either the policyCondition or
gpsPolicySimpleCondition classes as RDNs is
significant. For example: A qpDNList attribute carrying the superclass.

9.3. Extending qosPolicyAction following
value: "OU=Sales, CN=*, O=Widget Inc., *, C=US"
matches: "OU=Sales, CN=J. Smith, O=Widget Inc, C=US" and also matches:
"OU=Sales, CN=J. Smith, O=Widget Inc, C=US, CN=CA".

The Qos Policy actions classes attribute is defined in the QoS Policy Schema
Includes the following types as follows:

NAME    qpDNList
SYNTAX	List of actions:

  Provisioning actions:
    * Marking
    * Policing, shaping and remarking according to Distinguished Names implemented as strings, each of
        which serves as 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. reference to another object.

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.             49

8.32. The concept of conditions as building
blocks of filters, the basic condition structure of <variable operator
value>, Class QoSPolicyRSVPSimpleAction

This action controls the concept content of variable binding RSVP messages and the concept of variable to
value relationship way RSVP
requests are valuable to domains out side QoS policy. In
order to allow more natural usage of these concept in other domains, admitted. Depending on 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 value of its qpRSVPActionType
property, this action directly translates into either a class representing a filter COPS Replace
Decision or a Boolean expression
made of policy conditions, that could also serve COPS Stateless Decision, as a reusable filter
was added. The class gpsPolicyCompoundCondition allows the definition
of a flexible reusable filter, leveraging the mechanism defined in CPIM COPS 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 RSVP. Only
variables that are subclasses of the QoS policy model
required for definition of policies for a differential service domain.
References QoSPolicyRSVPVariable are allowed to external PHB definitions removed.
5. Alignment between policy
be associated with this action. The property definition of QPIM and low level PIB / MIB
Was illustrated.
6. Reuse of Policy groups and their QPIM extensions,
gpsPolicyGroups and Policy rules were explained and examples
were added.
7. Role usage in is as follows:

NAME         QoSPolicyRSVPSimpleAction
DESCRIPTION  This action controls the context content of QoS policy was explained. No new
concepts were introduced. Role were also defined per
gpsPolicyGroups.
8. Change gpsPolicyMeter to include a traffic profile RSVP messages and scope. The
previous way of binding the meter
             way RSVP requests are admitted.
DERIVED FROM SimplePolicyAction
ABSTRACT     False
PROPERTIES   qpRSVPActionType

Restricts the traffic profile and a scope using
a provisioning action could lead PolicyVariableInSimplePolicyAction aggregation to inconsistencies if not used
properly (Bob).
9. Clarification of the use of gpValueTypes
QoSPolicyRSVPVariable.

8.32.1. The Property qpRSVPActionType

This property of may contain one or two values and to denote the
meaning type of table 3 (Bob).
10. Rewriting the draft in RSVP
action. The value 'REPLACE' denotes a storage independent way. COPS Replace Decision action. The previous
draft was not general enough. Added appropriate association and
aggregations and removed references from objects. Changed text
appropriately.
11. qpsNamedPolicyContainer class name was changes
value 'STATELESS' denotes a COPS Stateless Decision action. Refer to gpsPolicyGroup
[COPS] for details. This property is multi-value, which means that both
action types are to
allow for usage outside be executed.
NAME         QpRSVPActionType
DESCRIPTION  This property specifies whether the scope action type is for COPS
             Replace or Stateless decision or both.
SYNTAX       Integer
VALUE        This is an enumerated integer. A value of QoS domain

Snir, Ramberg, Strassner, Cohen         expires May 2001            112

12. Acknowledgments 0 specifies a
             COPS Replace decision. A value 1 specifies a COPS Stateless
             Decision.

9. Acknowledgements

The authors wish to thank the input of the participants of the Policy
Framework working group, and especially Bob Moore and Alex Wang for
their helpful contributions.

13.

10. Security Considerations

The Policy Core Information Model (PCIM) [PCIM] describes the general
security considerations related to the general core policy model.  The
extensions defined in this document do not introduce any additional
considerations related to security.

Snir, Ramberg, Strassner, Cohen          expires November 2001         50

11. References

[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

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

[PFSCHEMA]  J. Strassner, E. Ellesson, Model -- Version 1 Specification",
       RFC 3060, February 2001.

[PCIMe] B. Moore, "Policy Framework LDAP
            Core Schema", Internet Draft
            <draft-ietf-policy-core-schema-06.txt>

[QOSSCHEMA] L. Rafalow, Y. Snir, Y Ramberg, Y. Snir, J. Strassner,
        A. Westerinen, R. Chadha, M. Brunner, R. Cohen, "QoS
            Policy Schema", Internet Draft
            <draft-ietf-policy-qos-schema-01.txt>

[DIFF-SERV-ARCH]
        "Policy Core Information Model Extensions",
        <draft-ietf-policy-pcim-ext-01.txt>

[TERMS] A. Westerinen, J. Schnizlein, J. Strassner, M. Scherling,
        B. Quinn, J. Perry, S. Herzog, A. Huynh, M. Carlson,
        S. Waldbusser, "Terminology",
        <draft-ietf-policy-terminology-02.txt>

[QDDIM] J. Strassner, A. Westerinen, B. Moore, D. Durham, W. Weiss,
        "Information Model for Describing Network Device QoS Mechanisms
        for Differentiated Services",
        <draft-ietf-policy-qos-device-info-model-02.txt>

[DIFFSERV] S. Blake  et al, Blake, et. Al., "An Architecture for Differentiated
           Services", RFC2475

[EF] V. Jacobson, K. Nichols, K. Poduri, " An Expedited Forwarding
     PHB", RFC2598,  September 1999

[AF] RFC 2475

[UML]  Please see the following web page for the latest (1.3 as of this
       writing) UML specification:
       http://www.rational.com/uml/resources/documentation/index.jsp

[INTSERV]  R. Braden, D. Clark, S. Shenker, "Integrated Services in
           the Internet Architecture: an Overview", RFC 1633.

[RSVP]  R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin,
        "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
        Specification", RFC2205

[QoSSCHEMA]  Y. Snir, Y. Ramberg, J. Heinanen, F. Baker, W. Weiss, Strassner, R. Cohen, "Policy QoS
             LDAP Schema", <draft-ietf-policy-qos-schema-02.txt>

[RFC2749]  S . Herzog, Ed., J. Wroclawski,  "Assured
     Forwarding PHB Group",  RFC2597,  September 1999 Boyle, R. Cohen, D. Durham, R. Rajan,
           A. Sastry, "COPS usage for RSVP", RFC2749

[RFC2751]  S. Herzog, "Signaled Preemption Priority Policy Element",
           RFC2751

[DIFF-MIB]  F. Baker, K. Chan, A. Smith Smith, "Management Information Base
            for the Differentiated Services Architecture",
            draft-ietf-diffserv-mib-05.txt,
            <draft-ietf-diffserv-mib-09.txt>

Snir, Ramberg, Strassner, Cohen          expires November 2000

[PIB]       M. Fine, K. McCloghrie, 2001         51

[AF]  J. Seligson, K. Chan, S. Hahn, A.
            Smith, "Quality Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured Forwarding
      PHB Group", RFC2597

[CL]  J. Wroclawski, "Specification of Service Policy Information Base",
            Internet Draft <draft-mfine-cops-pib-01.txt>

[RSVP]      Braden, R. ed., "Resource ReSerVation Protocol (RSVP) -
            Functional Specification.", IETF RFC 2205,
            Proposed Standard, Sep. 1997. the Controlled-Load Network
      Element Service", RFC2211

[RSVP-IS]  J. Wroclawski, "The Use of RSVP with IETF Integrated
           Services", RFC2210, September 1997 RFC2210

[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 RFC2212

[DCLASS]  Y. Bernet, "Format of the Controlled-Load
            Network Element Service", RFC2211, September 1997

[RSVP_PREEMP] Shai Herzog, "Signaled Preemption Priority Policy
              Element",  RFC2751

[IDNET] RSVP DCLASS Object", RFC2996

[RFC2752]  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, RFC2752

[RFC2872]  Y. Bernet, R. Rajan, A.
            Sastry, "The COPS (Common Open Pabbati, "Application and Sub Application
           Identity Policy Service) Protocol",
            RFC2748

[COPSRSVP]  S. Herzog, J. Boyle, R . Cohen, D. Durham, R. Rajan, A.
            Sastry, "COPS Usage Element for Use with 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. RFC2872

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

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

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

[TERMS]     S. Bradner, "Key words for use in RFCs to Indicate
            Requirement Levels", Internet RFC 2119, March 1997.

Snir, Ramberg, Strassner, Cohen         expires May 2001            114

14. Author's RFC2253

12. Authors' Addresses

   Yoram Snir Ramberg
       Cisco Systems
       4 Maskit Street
       Herzliya Pituach, Israel  46766
       Phone:  +972-9-970-0085  +972-9-970-0081
       Fax:    +972-9-970-0366    +972-9-970-0219
       E-mail:  ysnir@cisco.com  yramberg@cisco.com

   Yoram Ramberg Snir
       Cisco Systems
       4 Maskit Street
       Herzliya Pituach, Israel  46766
       Phone:  +972-9-970-0081  +972-9-970-0085
       Fax:    +972-9-970-0219    +972-9-970-0366
       E-mail:  yramberg@cisco.com  ysnir@cisco.com

   John Strassner
       Cisco Systems
    Bldg 15
    170 West Tasman Drive
    San Jose,
       725 Alder Drive, , Building 20
       Milpitas, CA 95134  95035
       Phone:  +1-408-527-1069
       Fax:    +1-408-527-2477
       E-mail:  johns@cisco.com

Snir, Ramberg, Strassner, Cohen          expires November 2001         52
   Ron Cohen
    Cisco Systems
    4 Maskit Street
    Herzliya Pituach, Israel  46766
       Ntear   LLC
       Phone:  +972-9-970-0064
       Fax:    +972-9-970-0219
       E-mail:  ronc@cisco.com

15. ronc@ntear.com

13. Full Copyright Statement

Copyright (C) The Internet Society (2001).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may 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
may 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 must be followed, or as required to translate it into
languages other than English.

Snir, Ramberg, Strassner, Cohen         expires 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 PURPOSE.

Snir, Ramberg, Strassner, Cohen          expires May November 2001            116         53