Policy Framework Working Group                                   Y. Snir
INTERNET-DRAFT                                                Y. Ramberg
                                                           Cisco Systems
Category: Standards Track                                   J. Strassner
                                                           Cisco Systems
                                                              Intelliden
                                                                R. Cohen
                                                               Ntear LLC
                                                                B. Moore
                                                                     IBM
                                                           November 2001

                           Policy QoS Information Model
                    <draft-ietf-policy-qos-info-model-03.txt>
                    <draft-ietf-policy-qos-info-model-04.txt>

Status of this Memo Document

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

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
  http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
  http://www.ietf.org/shadow.html

Copyright Notice

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

Abstract

This document presents an object-oriented information model for
representing policies that administer, manage, and control access to
network QoS policies. resources. This document is based on the IETF Policy Core
Information Model and its extensions as specified by [PCIM] and [PCIMe].
This draft builds upon these two documents to define an information
model for QoS enforcement 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.

Definition of 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 be interpreted as described in RFC 2119 [KEYWORDS].

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

Table of Contents

1.  Introduction                                                       5
1.1.  Goals  The Process of QoS Policy Definition                             5
1.1.1.
1.2.  Design Goals and Their Ramifications                             8
1.2.1.  Policy-Definition Oriented                                     8
1.2.1.1.  Rule-based Modeling                                          9
1.2.1.2.  Organize Information Hierarchically                          9
1.2.1.3.  Goal-Oriented Policy Definition                             10
1.2.2. Policy Domain Model                                            10
1.2.2.1.  Model QoS Policy in a Device- and Vendor-Independent Manner 11
1.2.2.2.  Use Roles for Mapping Policy to Network Devices             11
1.2.2.3.  Reusability                                                 11
1.2.3.  Enforceable Policy                                            12
1.2.4. QPIM Covers Both Signaled And Provisioned QoS                  13
1.2.5.  Interoperability for PDPs and Management Applications         14
1.3.  Modeling Abstract QoS Policies                                  5
1.1.2.  Enhancing Interoperability                                      6
1.1.3.                                  14
1.4.  Rule Hierarchy                                                  16
1.4.1.  Use of Hierarchy Within Bandwidth Allocation Policies         17
1.4.2.  Use of Rule Hierarchy to Describe Drop Threshold Policies     19
1.4.3.  Restrictions of the Use of Hierarchy Within QPIM              20
1.5.  Intended Audiences                                              7
1.2.  QPIM Characteristics                                              8
1.3.  QPIM and Other Published Standards                               10                                              21

2.  Class Hierarchies                                                  11                                                 22
2.1.  Inheritance Hierarchy                                            11                                           22
2.2.  Relationship Hierarchy                                           13                                          24

3.  QoS Actions                                                        14                                                       25
3.1.  Overview                                                         14                                                        25
3.2.  RSVP Policy Actions                                              15                                             26
3.2.1.  Example: Controlling COPS Stateless Decision                  27
3.2.2.  Example: Controlling the COPS Replace Decision                27
3.3.  Provisioning Policy Actions                                      16                                     27
3.3.1.  Admission Actions: Controlling Policers and Shapers            17           28
3.3.2.  Controlling Markers                                            18                                           30
3.3.3.  Controlling Edge Policies  - Examples                           18                          31
3.4.  Per-Hop Behavior Actions                                         20                                        32
3.4.1.  Controlling Bandwidth and Delay                                21                               33
3.4.2.  Congestion Control Actions                                     21                                    33
3.4.3.  Using Hierarchical Policies  Policies: Examples for PHB Actions         22         34

4.  Traffic Profiles                                                   23                                                  36
4.1.  Provisioning Traffic Profiles                                    24                                   36
4.2.  RSVP Traffic Profiles                                            24                                           36

5.  Pre-Defined QoS-Related Variables                                  25                                 38

6.  QoS Related Values                                                 27                                                40

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002          2

Table of Contents (continued)

7.  Class Definitions: Association Hierarchy                           28                          42
7.1.  The Association "QoSPolicyTrfcProfInAdmissionAction"             28            42
7.1.1.  The Reference "Antecedent"                                     28                                    42
7.1.2.  The Reference "Dependent"                                      28                                     42
7.2.  The Association "PolicyConformAction"                            28                           43
7.2.1.  The Reference "Antecedent"                                     29                                    43
7.2.2.  The Reference "Dependent"                                      29                                     43
7.3.  The Association "PolicyExcessAction"                             29 "QoSPolicyExceedAction"                         43
7.3.1.  The Reference "Antecedent"                                     29                                    44
7.3.2.  The Reference "Dependent"                                      29                                     44
7.4.  The Association "PolicyViolateAction"                            30                           44
7.4.1.  The Reference "Antecedent"                                     30                                    44
7.4.2.  The Reference "Dependent"                                      30

Snir, Ramberg, Strassner, Cohen          expires November 2001          2

Table of Contents (continued)                                     45
7.5   The Aggregation "QoSPolicyRSVPVariableInRSVPSimplePolicyAction" 45
7.5.1.  The Reference "GroupComponent"                                45
7.5.2.  The Reference "PartComponent"                                 45

8.  Class Definitions: Inheritance Hierarchy                           31                          46
8.1.  The Class QoSPolicyDiscardAction                                 31                                46
8.2.  The Class QoSPolicyAdmissionAction                               31                              46
8.2.1.  The Property qpAdmissionScope                                  31                                 46
8.3.  The Class QoSPolicyPoliceAction                                  32                                 47
8.4.  The Class QoSPolicyShapeAction                                   32                                  47
8.5.  The Class QoSPolicyRSVPAdmissionAction                           33                          47
8.5.1.  The Property qpRSVPWarnOnly                                    33                                   48
8.5.2.  The Property qpRSVPMaxSessions                                 33                                48
8.6.  The Class QoSPolicyPHBAction                                     34                                    49
8.6.1.  The Property qpPacketSize                                      34 qpMaxPacketSize                                  49
8.7.  The Class QoSPolicyBandwidthAction                               34                              49
8.7.1.  The Property qpForwardingPriority                              35                             50
8.7.2.  The Property qpBandwidthUnits                                  35                                 50
8.7.3.  The Property qpMinBandwidth                                    35                                   50
8.7.4.  The Property qpMaxBandwidth                                    35                                   51
8.7.5.  The Property qpMaxDelay                                        36                                       51
8.7.6.  The Property qpMaxJitter                                       36                                      51
8.7.7.  The Property qpFairness                                        36                                       51
8.8.  The Class QoSPolicyCongestionControlAction                       36                      52
8.8.1.  The Property qpSizeUnits                                       37 qpQueueSizeUnits                                 52
8.8.2.  The Property qpQueueSize                                       37                                      52
8.8.3.  The Property qpDropAlgorithm                                   37 qpDropMethod                                     53
8.8.4.  The Property qpDropThresholdUnits                              37                             53
8.8.5.  The Property qpDropMinThresholdValue                           38                          53
8.8.6.  The Property qpDropMaxThresholdValue                           38                          54
8.9.  The Class QoSPolicyTrfcProf                                      38                                     54
8.10.  The Class QoSPolicyTokenBucketTrfcProf                          39                         54
8.10.1.  The Property qpTBRate                                         39                                        55
8.10.2.  The Property qpTBNormalBurst                                  39                                 55
8.10.3.  The Property qpTBExcessBurst                                  39                                 55

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002          3

Table of Contents (continued)

8.11.  The Class QoSPolicyIntServTrfcProf                              40                             55
8.11.1.  The Property qpISTokenRate                                    40                                   56
8.11.2.  The Property qpISPeakRate                                     40                                    56
8.11.3.  The Property qpISBucketSize                                   40                                  56
8.11.4.  The Property qpISResvRate                                     41                                    56
8.11.5.  The Property qpISResvSlack                                    41                                   56
8.11.6.  The Property qpISMinPolicedUnit                               41                              57
8.11.7.  The Property qpISMaxPktSize                                   41                                  57
8.12.  The Class QoSPolicyAttributeValue                               42                              57
8.12.1.  The Property qpAttributeName                                  42                                 58
8.12.2.  The Property qpAttributeValueList                             42                            58
8.13.  The Class QoSPolicyRSVPVariable                                 42                                58
8.14.  The Class QoSPolicyRSVPSourceIPv4Variable                       43                      58
8.15.  The Class QoSPolicyRSVPDestinationIPv4Variable                  43                 59
8.16.  The Class QoSPolicyRSVPSourceIPv6Variable                       43                      59
8.17.  The Class QoSPolicyRSVPDestinationIPv6Variable                  44                 59
8.18.  The Class QoSPolicyRSVPSourcePortVariable                       44                      60
8.19.  The Class QoSPolicyRSVPDestinationPortVariable                  44

Snir, Ramberg, Strassner, Cohen          expires November 2001          3

Table of Contents (continued)                 60
8.20.  The Class QoSPolicyRSVPIPProtocolVariable                       45                      61
8.21.  The Class QoSPolicyRSVPIPVersionVariable                        45                       61
8.22.  The Class QoSPolicyRSVPDCLASSVariable                           45                          61
8.23.  The Class QoSPolicyRSVPStyleVariable                            46                           62
8.24.  The Class QoSPolicyRSVPIntServVariable                          46                         62
8.25.  The Class QoSPolicyRSVPMessageTypeVariable                      46                     63
8.26.  The Class QoSPolicyRSVPPreemptionPriorityVariable               47              63
8.27.  The Class QoSPolicyRSVPPreemptionDefPriorityVariable            47           63
8.28.  The Class QoSPolicyRSVPUserVariable                             48                            64
8.29.  The Class QoSPolicyRSVPApplicationVariable                      48                     64
8.30.  The Class QoSPolicyRSVPAuthMethodVariable                       49                      65
8.31.  The Class QosPolicyDNValue                                      49                                     65
8.31.1.  The Property qpDNList                                         49                                        65
8.32.  The Class QoSPolicyRSVPSimpleAction                             50                            66
8.32.1.  The Property qpRSVPActionType                                 50                                66

9.  Acknowledgements                                                   50                                                  67

10.  Security Considerations                                           50                                          67

11.  References                                                        51                                                       67

12.  Authors' Addresses                                                52                                               68

13.  Full Copyright Statement                                          53                                         69

Snir, Ramberg, Strassner, Cohen Cohen, Moore       expires November 2001 May 2002          4

1.  Introduction

This document presents

The QoS Policy Information Model (QPIM) establishes a standard framework
and constructs for specifying and representing policies that administer,
manage, and control access to network QoS resources. Such policies will
be referred to as "QoS policies" in this document. The framework
consists of a set of classes and relationships that are organized in an
object-oriented information model model. It is agnostic of any specific PDP or
PEP (see [TERMS] for
representing definitions) implementation, and independent of any
particular QoS implementation mechanism.

QPIM is designed to represent QoS policy information for large-scale
policy domains (the term "policy domain" is defined in [TERMS]). A
primary goal of this information model is to assist human administrators
in their definition of policies to control QoS resources (as opposed to
individual network element configuration). The process of creating QPIM
data instances is fed by business rules, network topology and QoS policies.
methodology (e.g. Differentiated Services).

This document is based on the IETF Policy Core Information Model and its
extensions as specified by [PCIM] and [PCIMe]. This draft QPIM builds upon these
two documents to define an information model for QoS enforcement for
differentiated and integrated services ([DIFFSERV] and [INTSERV],
respectively) 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.

The following subsections describe the goals This enables
various data models (e.g., directory schemata, relational database
schemata, and purposes SNMP MIBs) to be designed and implemented according to a
single uniform model.

1.1.  The Process of the QoS Policy Information Model (QPIM), its intended audience, and its
relationships to other published standards.

1.1  Goals Definition

This section explains describes the goals for creating QPIM.

1.1.1.  Modeling Abstract QoS Policies

The main goal process of the using QPIM is to create an information model that can be
used to help bridge part of for the conceptual gap between definition QoS
policy for a human policy
maker domain. Figure 1 illustrates information flow and a network element that is configured to enforce
not the policy.
Clearly this wide gap implies actual procedure, which has several translation levels, from the
abstract to the concrete. At the abstract end are the business loops and feedback not
depicted.

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002          5
 ----------        ----------       -----------
| Business |      | Topology |     |   QoS     |
| Policy   |      |          |     |Methodology|
 ----------        ----------       -----------
     |                  |               |
     |                  |               |
     ------------------------------------
                        |
                        V
                 ---------------
                |  QPIM/PCIM(e) |
                |   modeling    |
                 ---------------
                        |
                        |            --------------
                        |<----------| Device info, |
                        |           | capabilities |
                        |            --------------
                        V
                 (---------------)
                 (    device     )---)
                 ( configuration )   )---)
                 (---------------)   )   )
                      (--------------)   )
                           (-------------)

            Figure 1: The QoS definition information flow

The process of QoS policy
rules. QPIM facilitates a formal representation definition is dependent on three types of
information: the topology of the network devices under management, the
particular type of QoS methodology used (e.g., DiffServ) and the
business
rules, thus providing rules and requirements for specifying service(s) [TERMS]
delivered by the network. Both topology and business rules are outside
the scope of QPIM. However, important facets of both must be known and
understood for correctly specifying the first concretization level: formally
representing humanly expressed QoS policy.

When

Typically, the process of QoS policy definition relies on a human business executive defines network policy, it is usually
done using informal business terms and language. methodology
based on one or more QoS methodologies. For example, a human the DiffServ
methodology may
utter a be employed in the QoS policy statement definition process.

The topology of the network consists of an inventory of the network
elements that reads: "traffic generated by our human-
resources application should have higher priority for making it through
to its destination compared to traffic generated by people browsing the
WEB during their lunch breaks". While this statement clearly defines QoS
policy for the network, make up the network itself cannot enforce it. Translation
to "network terms and language" is required.

On the other end set of the scale, a network element functioning as a Policy
Enforcement Point (PEP, see [TERMS] for its definition), such as a
router, can be configured with specific commands paths that determine traffic may
take through the
operational parameters of its inner working QoS mechanisms. network. For example,
the (imaginary) command "output-queue-depth = 100" may be an instruction
to a network interface card of a router to allow up to 100 packets administrator may
decide to be
stored before subsequent packets are discarded (not forwarded). On a
different device within use the same network, DiffServ architectural model [DIFFSERV] and classify
network devices using the same instruction may take
another form, because a different vendor built that device or it has roles "boundary" and "core" (see [TERMS] for a
different set
definition of functions, role, and hence implementation, even though it is
from [PCIM] for an explanation of how they are used
in the same vendor. In addition, a particular PEP may policy framework). While this is not have a complete topological view
of the
ability to create queues that are longer than, say, 50 packets, which network, many times it may
result in a different instruction implementing suffice for the same business policy. purpose of QoS policy
definition.

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

The first example illustrates 'abstract policy', while May 2002          6

Business rules are informal sets of requirements for specifying 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 enforced by configuration
behavior of PEPs
in various parts types of traffic that may traverse the network, network. For
example, the information model of administrator may be instructed to implement policy and such
that
of the mechanisms VoIP traffic manifests behavior that a PEP uses is similar to implement legacy voice
traffic over telephone networks. Note that policy is vastly
different.

The translation process from abstract this business policy to concrete PEP
configuration is roughly expressed rule
(indirectly) prescribes specific behavior for this traffic type (VoIP),
for example in terms of minimal delay, jitter and loss. Other traffic
types, such as follows:

1.	Informal business QoS policy WEB buying transactions, system backup traffic, video
streaming, etc., will express their traffic conditioning requirements in
different terms. Again, this information is expressed required not by QPIM itself,
but by a human policy maker
(e.g. "All executives' WEB requests should be prioritized")
2.	A network administrator models the informal overall policy by using management system that uses QPIM. QPIM
constructs, thus creating a formal representation of the abstract
policy. (e.g. "If packet's protocol is HTTP and its destination is in
the 'EXECUTIVES' user group, then assign IPP 7 used
to help map the packet header").
Note that the administrator is very likely to use business rules into a particular data
model (e.g., LDAP schema) form that is mapped to QPIM.
3.	The network administrator maps defines the abstract, formal policy to PEPs
(most likely by using roles, as specified requirements
for conditioning different types of traffic in  [PCIMe, sections 2.2.4 the network.

The topology, QoS methodology, and 4.6]).
4.	A configuration/distribution agent (or a PDP  see [TERMS] for its
definition) consults business rules are necessary
prerequisites for defining traffic conditioning. QPIM enables a device capability model to determine how to
translate the policy into device configuration. An example set of
tools for specifying traffic conditioning policy in a
standards-based capability standard manner.
Using a standard QoS policy information model such as QPIM is [QDDIM]. Note needed
also because different devices can have markedly different capabilities.
Even the same model of equipment can have different functionality if the
network operating system and software running in those devices is
different. Therefore, a means is required to specify functionality in a
standard way that one or more
such translations are possible, depending on is independent of the particular capabilities of a given PEP and different
vendors' devices. This is the implementation role of QPIM.

In a typical scenario, the system.
5.	For administrator would first determine the
role(s) that each PEP interface of each network element plays in the network, overall
network topology. These roles define the configuration/distribution agent
configures functions supplied by a given
network element independent of vendor and device type. The [PCIM] and
[PCIMe] documents define the appropriate instructions concept of a role. Roles can be used to enforce
identify what parts of the policy.

QPIM is intended to network need which type of traffic
conditioning. For example, network interface cards that are categorized
as "core" interfaces can be assigned the bridging mechanism between step #1 and step #2
in role name "core-interface".
This enables the methodology just described.

1.1.2.  Enhancing Interoperability

Another goal administrator to design policies to configure all
interfaces having the role "core-interface" independent of the actual
physical devices themselves.  QPIM is uses roles to facilitate interoperability among policy
systems, PDPs in particular. QPIM accomplishes its interoperability goal
by standardizing help the administrator
map a representation given set of policy. Producers and consumers devices or interfaces to a given set of
QoS policy need only rely on QPIM-based schemata (or data models) to
ensure mutual understanding and agreement
constructs.

The policy constructs define the functionality required to perform the
desired traffic conditioning for particular traffic type(s). The
functions themselves depend on the semantics particular type of QoS policy. networking
technologies chosen. For example, suppose that a QoS policy management application, built the DiffServ methodology encourages us
to aggregate similar types of traffic by
vendor A, writes its policies based on an LDAP schema that maps from QPIM assigning to each traffic class
a directory implementation.A particular per-hop forwarding behavior on each node. RSVP enables
bandwidth to be reserved. These two methodologies can be used separately built PDP from vendor B may
then read this policy and "understand" it
or in conjunction, as both defined by the management
application appropriate business policy. QPIM
provides specific classes to enable DiffServ and the PDP were architected RSVP conditioning to comply with the QPIM
standard. be
modeled.

Snir, Ramberg, Strassner, Cohen Cohen, Moore       expires November 2001          6

Interoperability of May 2002          7

The QPIM producers/consumers is by definition at a high
level, class definitions are used to create instances of various
policy constructs such as QoS actions and does not guarantee conditions that the same policy will result may be
hierarchically organized in the
same PEP configuration. First, different PEPs will have different
capabilities rules and functions, which necessitate different individual
configurations even if the different PEPs groups (PolicyGroup and PolicyRule
as defined in [PCIM] and [PCIMe]). Examples of policy actions are controlled by rate
limiting, jitter control and bandwidth allocation. Policy conditions are
constructs that can select traffic according to a complex Boolean
expression.

A hierarchical organization was chosen for two reasons. First, it best
reflects the same way humans tend to think about complex policy. Second, different PDPs will also have different capabilities and
functions, and may choose it
enables policy to translate be easily mapped onto administrative organizations, as
the high-level QPIM hierarchical organization of policy
differently depending on mirrors most administrative
organizations. It is important to note that the functionality policy definition
process described here is done independent of any specific device
capabilities and configuration options. The policy definition is
completely independent from the details of the PDP implementation and the
configuration interface of individual network elements, as well as the
capabilities of
the PEPs mechanisms that a network element can use to condition traffic.

1.2.  Design Goals and Their Ramifications

This section explains the QPIM design goals and how these goals are being controlled by
addressed in this document. This section also describes the PDP. Finally,
ramifications of the same policy may be interpreted slightly differently depending on
various factors. For example, a design goals and the design decisions made in
developing QPIM.

1.2.1  Policy-Definition Oriented

The primary design goal of QPIM policy rule that reads "If packet's
protocol is HTTP then assign 7 to IPP", may result model policies controlling QoS
behavior in different
configurations depending on how a way that rule is implemented. For example, an
application recognition mechanism can be used to enforce as closely as possible reflects the way humans
tend to think about policy. If Therefore, QPIM is designed to address the device does
needs of policy definition and management, and not supports device/network
configuration.

There are several ramifications of this particular mechanism, then an alternate
mechanism must be used. For example, the packets could be classified design goal. First, QPIM uses
rules to define policies, based on their destination TCP port.

Therefore, we define interoperability [PCIM] and [PCIMe]. Second, QPIM uses
hierarchical organizations of QoS policies as and policy information
extensively. Third, QPIM does not force the ability policy writer to specify a policy rule in a standard format. The advantage is all
implementation details; rather, it assumes that such a
policy can be understood by PDPs and PEPs manufactured from different
vendors having different capabilities configuration agents
(PDPs) interpret the policies and functionality, as well as
policy-based applications. We specifically do not require a policy match them to be
translated into exactly the same configuration in different PEPs. This is
why we view the above two systems that differ in suit the interpretation of
recognizing WEB traffic as interoperable with regard to policy. The
advantage needs of using QPIM policies
device-specific configurations.

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002          8

1.2.1.1.  Rule-based Modeling

Policy is that incompatible device capabilities
may still be employed and controlled best described using the QPIM policy.

1.1.3.  Intended Audiences

QPIM is intended for several audiences. The following lists some of the
intended audiences rule-based modeling as explained and their respective uses:

1.	Application vendors who build
described in [PCIM] and [PCIMe]. A QoS policy management applications can
use this model rule is structured as an extensible framework for defining policies to
control PEPs a
condition clause and PDPs in an interoperable manner
2.	Developers of Policy Decision Point (PDP) systems can use this
framework action clause. The semantics are simple: if the
condition clause evaluates to develop interoperable policies
3.	QoS policy makers who seek a standardized model for expressing TRUE, then a
formal representation set of QoS policy actions (specified
in the action clause) can use this model to control PEPs
of varying capabilities and functionality
4.	Builders be executed. For example, the rule:

    "WEB traffic should receive at least 50% of large organization data the available
     bandwidth resources or more, when more is available"

can be formalized as:

    "<If protocol == HTTP> then <minimum BW = 50%>"

where the first angle bracketed clause is a traffic condition and knowledge bases who decide to
combine the
second angle bracketed clause is a QoS policy information with other networking policy
information, assuming all action.

This approach differs from data path modeling is based that describes the
mechanisms that operates on [PCIM] and [PCIMe]
5.	Authors of various standards may use constructs introduced in this
document the packet flows to enhance their work. Authors of data models wishing to map
a storage specific technology to QPIM must use this document as well.

Snir, Ramberg, Strassner, Cohen          expires November 2001          7

1.2.  QPIM Characteristics

First, a general statement achieve the desired
effect.

Note that characterizes QPIM:

"The QoS Policy Information Model (QPIM) establishes a standard framework
and constructs for specifying the approach taken in QPIM specifically did NOT subclass the
PolicyRule class. Rather, it uses the SimplePolicyCondition,
CompoundPolicyCondition, SimplePolicyAction, and representing business QoS policies.
This framework consists of a set of CompoundPolicyAction
classes and relationships, organized defined in an object-oriented information model. It is agnostic [PCIMe], as well as defining subclasses of any specific
PDP or PEP implementation the
following classes: Policy, PolicyAction, SimplePolicyAction,
PolicyImplicitVariable, and independent PolicyValue.  Subclassing the PolicyRule
class would have made it more difficult to combine actions and
conditions defined within different functional domains [PCIMe] within
the same rules.

1.2.1.2.  Organize Information Hierarchically

The organization of any particular QoS
technology mechanism.  It the information represented by QPIM is intended designed to
be used to control the
provisioning of end-to-end network services."

In hierarchical. To do this, QPIM utilizes the rest PolicySetComponent
aggregation [PCIMe] to provide an arbitrarily nested organization of this section, we itemize and expand the general statement
presented above.

1.	QPIM,
policy information. A policy group functions as the name implies, is a QoS Policy Information Model. This
means container of policy
rules and/or policy groups. A policy rule can also contain policy rules
and/or groups, enabling a rule/sub-rule relationship to be realized.

The hierarchical design decision is based on the realization that it only models QoS concepts. These concepts are either
derived in this document, or adapted is
natural for use humans to organize policy rules in modelingQoS from other
documents.

2.	QPIM groups. Breaking down a
complex policy into a set of simple rules is an information model. As such, it a process that follows the
way people tend to think and analyze systems. The complexity of the
abstract, business-oriented policy is independent simplified and made into a
hierarchy of any
specific data storage mechanism simple rules and access protocol. QPIM's constructs
may be mapped grouping of simple rules.

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002          9

The hierarchical information organization helps to various storage simplify the
definition and readability of data organization technologies. A
data model mapped instances based on QPIM. Hierarchies
can also serve to QPIM carry additional semantics for QoS actions in a given
context. An example, detailed in section 2.3, demonstrates how
hierarchical bandwidth allocation policies can be created specified in a relational database, an
object oriented database, an LDAP directory and more. Because
intuitive form, without the need to specify complex scheduler
structures.

1.2.1.3.  Goal-Oriented Policy Definition

QPIM is
not a schema, facilitates goal-oriented QoS policy definition. This means that
the reader process of defining QoS policy is encouraged to focus focused on the conceptual
level and not on desired effect of
policies, as opposed to the data organization methodology. Clearly a mapped
schema would include enhancements and optimizations not appropriate in means of implementing the information-modeling realm. For example, a given association
between two classes policy on network
elements.

QPIM is always modeled as an association class in QPIM.
A given schema may find it useful and efficient intended to model such a
relationship using define a reference object attribute minimal specification of desired network
behavior. It is the role of device-specific configuration agents to
interpret policy expressed in a directory or a
keyforeign key relationship standard way and fill in a relational database.

3.	QPIM is standard. The model standardizes the process necessary
configuration details that are required for their particular
application. The benefit of specifying
business QoS policies. It using QPIM is an that it provides a common
lingua franca that each of the device- and/or vendor-specific
configuration agents can use. This helps ensure a common interpretation and extension
of the
core general policy information model as defined well as aid the administrator in [PCIM] and [PCIMe]. It
references other IETF standards (e.g. [TERMS], [DIFFSERV] and others)
and is meant specifying a
common policy to enhance be implemented across different devices. This is
analogous to the fundamental object-oriented paradigm of separating
specification from implementation. Using QPIM, traffic conditioning can
be specified in a general manner that can help different implementations
satisfy a common goal.

For example, a valid policy may include only a single rule that
specifies that bandwidth should be reserved for a given set of traffic
flows. The rule does not need to include any of the various other
details that may be needed for implementing a scheduler that supports
this bandwidth allocation (e.g., the queue length required). It is
assumed that a PDP or the PEPs would fill in these details using (for
example) their default queue length settings. The policy writer need
only specify the main goal of the policy, making sure that the preferred
application receives enough bandwidth to operate adequately.

1.2.2.  Policy Domain Model

An important design goal of QPIM is to provide a means for defining
policies that span numerous devices. This goal differentiates QPIM from
device-level information models, which are designed for modeling policy
that controls a single device, its mechanisms and capabilities.

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         10

This design goal has several ramifications. First, roles [PCIM] are used
to define policies across multiple devices. Second, the use of abstract
policies frees the policy definition process from having to deal with
individual device peculiarities, and leaves interpretation and
configuration to be modeled by PDPs or other configuration agents.
Third, QPIM allows extensive reuse of all policy building blocks in
multiple rules used within different devices.

1.2.2.1.  Model QoS Policy in a Device- and Vendor-Independent Manner

QPIM models QoS policy in a way designed to be independent of any
particular device or vendor. This enables networks made up of different
devices that have different capabilities to be managed and controlled
using a single standard set of policies. Using such a single set of
policies is important because otherwise, the policy will itself reflect
the differences between different device implementations.

1.2.2.2.  Use Roles for Mapping Policy to Network Devices

The use of roles enables a policy definition to be targeted to the
network function of a network element, rather than to the element's type
and capabilities. The use of roles for mapping policy to network
elements provides an efficient and simple method for compact and
abstract policy definition. A given abstract policy may be mapped to a
group of network elements without the need to specify configuration for
each of those elements based on the capabilities of any one individual
element.

The policy definition is designed to allow aggregating multiple devices
within the same role, if desired. For example, if two core network
interfaces operate at different rates, one does not have to define two
separate policy rules to express the very same abstract policy (e.g.,
allocating 30% of the interface bandwidth to a given preferred set of
flows). The use of hierarchical context and relative QoS actions in QPIM
addresses this and other related problems.

1.2.2.3 Reusability

Reusable objects, as defined by [PCIM] and [PCIMe], are the means for
sharing policy building blocks, thus allowing central management of
global concepts. QPIM provides the ability to reuse all policy building
blocks: variables and values, conditions and actions, traffic profiles,
and policy groups and policy rules.  This provides the required
flexibility to manage large sets of policy rules over large policy
domains.

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         11

For example, the following rule makes use of centrally defined objects
being reused (referenced):

  If <DestinationAddress == FinanceSubNet> then <DSCP = MissionCritical>

In this rule, the condition refers to an object named FinanceSubNet,
which is a value (or possibly a set of values) defined and maintained in
a reusable objects container. The QoS action makes use of a value named
MissionCritical, which is also a reusable object. The advantage of
specifying a policy in this way is its inherent flexibility. Given the
above policy, whenever business needs require a change in the subnet
definition for the organization, all that's required is to change the
reusable value FinanceSubNet centrally. All referencing rules are
immediately affected, without the need to modify them individually.
Without this capability, the repository that is used to store the rules
would have to be searched for all rules that refer to the finance
subnet, and then each matching rule's condition would have to be
individually updated. This is not only much less efficient, but also is
more prone to error.

For a complete description of reusable objects, refer to [PCIM] and
[PCIMe].

1.2.3.  Enforceable Policy

Policy defined by QPIM should be enforceable. This means that a PDP can
use QPIM's policy definition in order to make the necessary decisions
and enforce the required policy rules. For example, RSVP admission
decisions should be made based on the policy definitions specified by
QPIM. A PDP should be able to map QPIM policy definitions into PEP
configurations, using either standard or proprietary protocols.

QPIM is designed to be agnostic of any particular, vendor-dependent
technology. However, QPIM's constructs SHOULD always be interpreted so
that policy-compliant behavior can be enforced on the network under
management. Therefore, there are three fundamental requirements that
QPIM must satisfy:

  1.  Policy specified by QPIM must be able to be mapped to actual
      network elements.
  2.  Policy specified by QPIM must be able to control QoS network
      functions without making reference to a specific type of device
      or vendor.
  3.  Policy specified by QPIM must be able to be translated into
      network element configuration.

QPIM satisfies requirements #1 and #2 above by using the concept of
roles (specifically, the PolicyRoles property, defined in PCIM). By
matching roles assigned to policy groups and to network elements, a PDP
(or other enforcement agent) can determine what policy should be applied
to a given device or devices.

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         12

The use of roles in mapping policy to network elements supports model
scalability. QPIM policy can be mapped to large-scale policy domains by
assigning a single role to a group of network elements. This can be done
even when the policy domain contains heterogeneous devices. So, a small
set of policies can be deployed to large networks without having to re-
specify the policy for each device separately. This QPIM property is
important for QoS policy management applications that strive to ease the
task of policy definition for large policy domains.

Requirement #2 is also satisfied by making QPIM domain-oriented (see
[TERMS] for a definition of "domain").  In other words, the target of
the policy is a domain, as opposed to a specific device or interface.

Requirement #3 is satisfied by modeling QoS conditions and actions that
are commonly configured on various devices. However, QPIM is extensible
to allow modeling of actions that are not included in QPIM.

It is important to note that different PEPs will have different
capabilities and functions, which necessitate different individual
configurations even if the different PEPs are controlled by the same
policy.

1.2.4. QPIM Covers Both Signaled And Provisioned QoS

The two predominant standards-based QoS methodologies developed so far
are Differentiated Services (DiffServ) and Integrated Services
(IntServ). The DiffServ provides a way to enforce policies that apply to
a large number of devices in a scalable manner. QPIM provides actions
and conditions that control the classification, policing and shaping
done within the differentiated service domain boundaries, as well as
actions that control the per-hop behavior within the core of the
DiffServ network. QPIM does not mandate the use of DiffServ as a policy
amethodology.

Integrated services, together with its signaling protocol (RSVP),
provides a way for end nodes (and edge nodes) to request QoS from the
network.  QPIM provides actions that control the reservation of such
requests within the network.

As both methodologies continue to evolve, QPIM does not attempt to
provide full coverage of all possible scenarios. Instead, QPIM aims to
provide policy control modeling for all major scenarios.  QPIM is
designed to be extensible to allow for incorporation of control over
newly developed QoS mechanisms.

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         13

1.2.5.  Interoperability for PDPs and Management Applications

Another design goal of QPIM is to facilitate interoperability among
policy systems such as PDPs and policy management applications. QPIM
accomplishes this interoperability goal by standardizing the
representation of policy. Producers and consumers of QoS policy need
only rely on QPIM-based schemata (and resulting data models) to ensure
mutual understanding and agreement on the semantics of QoS policy.

For example, suppose that a QoS policy management application, built by
vendor A writes its policies based on the standard LDAP schema that maps
from QPIM to a directory implementation using LDAP. Now assume that a
separately built PDP from vendor B also relies on this same LDAP schema
derived from QPIM.  Even though these are two vendors with two different
PDPs, each may read the schema of the other and "understand" it. This is
because both the management application and the PDP were architected to
comply with the QPIM standard. The same is true with two policy
management applications. For example, vendor B's policy application may
run a validation tool that computes whether there are conflicts within
rules specified by the other vendor's policy management application.

Interoperability of QPIM producers/consumers is by definition at a high
level, and does not guarantee that the same policy will result in the
same PEP configuration. First, different PEPs will have different
capabilities and functions, which necessitate different individual
configurations even if the different PEPs are controlled by the same
policy. Second, different PDPs will also have different capabilities and
functions, and may choose to translate the high-level QPIM policy
differently depending on the functionality of the PDP, as well as on the
capabilities of the PEPs that are being controlled by the PDP.  However,
the different configurations should still result in the same network
behavior as that specified by the policy rules.

1.3.  Modeling Abstract QoS Policies

This section provides a discussion of QoS policy abstraction and the way
QPIM addresses this issue.

As described above, the main goal of the QPIM is to create an
information model that can be used to help bridge part of the conceptual
gap between a human policy maker and a network element that is
configured to enforce the policy. Clearly this wide gap implies several
translation levels, from the abstract to the concrete. At the abstract
end are the business QoS policy rules. Once the business rules are
known, a network administrator must interpret them as network QoS policy
and represent this QoS policy by using QPIM constructs. QPIM facilitates
a formal representation of QoS rules, thus providing the first
concretization level: formally representing humanly expressed QoS
policy.

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         14

When a human business executive defines network policy, it is usually
done using informal business terms and language. For example, a human
may utter a policy statement that reads:

  "human resources applications should have better QoS than simple
   web applications"

This might be translated to a slightly more sophisticated form, such as:

  "traffic generated by our human resources applications should have a
   higher probability of communicating with its destinations
   than traffic generated by people browsing the WEB using
   non-mission-critical applications"

While this statement clearly defines QoS policy at the business level,
it isn't specific enough to be enforceable by network elements.
Translation to "network terms and language" is required.

On the other end of the scale, a network element functioning as a PEP,
such as a router, can be configured with specific commands that
determine the operational parameters of its inner working QoS
mechanisms. For example, the (imaginary) command "output-queue-depth =
100" may be an instruction to a network interface card of a router to
allow up to 100 packets to be stored before subsequent packets are
discarded (not forwarded). On a different device within the same
network, the same instruction may take another form, because a different
vendor built that device or it has a different set of functions, and
hence implementation, even though it is from the same vendor. In
addition, a particular PEP may not have the ability to create queues
that are longer than, say, 50 packets, which may result in a different
instruction implementing the same QoS policy.

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 enforced by configuration of
PEPs in various parts of the network, the information model of policy
and that of the mechanisms that a PEP uses to implement that policy are
vastly different.

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         15

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 human policy maker
     (e.g., "All executives' WEB requests should be prioritized ahead of
     other employees' WEB requests")
  2. A network administrator analyzes the policy domain's topology and
     determines the roles of particular device interfaces. A role may
     be assigned to a large group of elements, which will result in
     mapping a particular policy to a large group of device interfaces.
  3. The network administrator models the informal policy using QPIM
     constructs, thus creating a formal representation of the abstract
     policy. For example, "If a packet's protocol is HTTP and its
     destination is in  the 'EXECUTIVES' user group, then assign IPP 7
     to the packet header".
  4. The network administrator assigns roles to the policy groups
     created in the previous step matching the network elements' roles
     assigned in step #2 above.
  5. A PDP translates the abstract policy constructs created in step #3
     into device-specific configuration commands for all devices
     effected by the new policy (i.e., devices that have interfaces that
     are assigned a role matching the new policy constructs' roles). In
     this process, the PDP consults the particular devices' capabilities
     to determine the appropriate configuration commands implementing
     the policy.
  6. For each PEP in the network, the PDP (or an agent of the PDP)
     issues the appropriate device-specific instructions necessary to
     enforce the policy.

QPIM, PCIM and PCIMe are used in step #3 above.

1.4.  Rule Hierarchy

Policy is described by a set of policy rules that may be grouped into
subsets [PCIMe]. Policy rules and policy groups can be nested within
other policy rules, providing a hierarchical policy definition. Nested
rules are also called sub-rules, and we use both terms in this document
interchangeably.  The aggregation PolicySetComponent (defined in [PCIMe]
is used to represent the nesting of a policy rule or group in another
policy rule.

The hierarchical policy rule definition enhances policy readability and
reusability. Within the QoS policy information model, hierarchy is used
to model context or scope for the sub-rule actions. Within QPIM,
bandwidth allocation policy actions and drop threshold actions use this
hierarchal context. First we provide a detailed example of the use of
hierarchy in bandwidth allocation policies. The differences between flat
and hierarchical policy representation are discussed. The use of
hierarchy in drop threshold policies is described in a following
subsection.  Last but not least, the restrictions on the use of rule
hierarchies within QPIM are described.

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         16

1.4.1 Use of Hierarchy Within Bandwidth Allocation Policies

Consider the following example where the informal policy reads:

  On any interface on which these rules apply, guarantee at least 30%
  of the interface bandwidth to UDP flows, and at least 40% of the
  interface bandwidth to TCP flows.

The QoS Policy information model follows the Policy Core information
model by using roles as a way to specify the set of interfaces on which
this policy applies. The policy does not assume that all interfaces are
run at the same speed, or have any other property in common apart from
being able to forward packets. Bandwidth is allocated between UDP and
TCP flows using percentages of the available interface bandwidth. Assume
that we have an available interface bandwidth of 1 Mbits/sec. Then this
rule will guarantee 300Kbits/sec to UDP flows. However, if the interface
bandwidth was instead only 64kbits/sec, then this rule would
correspondingly guarantee 19.2kb/sec.

This policy is modeled within QPIM using two policy rules of the form:

     If (IP protocol is UDP) THEN (guarantee 30% of available BW) (1)
     If (IP protocol is TCP) THEN (guarantee 40% of available BW) (2)

Assume that these two rules are grouped within a PolicySet [PCIMe]
carrying the appropriate role combination. A possible implementation of
these rules within a PEP would be to use a Weighted-Round-Robin
scheduler with 3 queues. The first queue would be used for UDP traffic,
the second queue for TCP traffic and the third queue for the rest of the
traffic. The weights of the Weighted-Round-Robin scheduler would be 30%
for the first queue, 40% for the second queue and 30% for the last
queue.

The actions specifying the bandwidth guarantee implicitly assume that
the bandwidth resource being guaranteed is the bandwidth available at
the interface level. A PolicyRoleCollection is a class defined in
[PCIMe] whose purpose is to identify the set of resources (in this
example, interfaces) that are assigned to a particular role.  Thus, the
type of managed elements aggregated within the PolicyRoleCollection
defines the bandwidth resource being controlled. In our example,
interfaces are aggregated within the PolicyRoleCollection. Therefore,
the rules specify bandwidth allocation to all interfaces that match a
given role. Other behavior could be similarly defined by changing what
was aggregated within the PolicyRoleCollection.

Normally, a full specification of the rules would require indicating the
direction of the traffic for which bandwidth allocation is being made.
Using the direction variable defined in [PCIMe], the rules can be
specified in the following form:

    If (direction is out)
        If (IP protocol is UDP) THEN (guarantee 30% of available BW)
        If (IP protocol is TCP) THEN (guarantee 40% of available BW)

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         17

where indentation is used to indicate rule nesting. To save space, we
omit the direction condition from further discussion.

Rule nesting provides the ability to further refine the scope of
bandwidth allocation within a given traffic class forwarded via these
interfaces. The example below adds two nested rules to refine bandwidth
allocation for UDP and TCP applications.

   If (IP protocol is UDP) THEN (guarantee 30% of available BW) (1)
      If (protocol is TFTP) THEN (guarantee 10% of available BW) (1a)
      If (protocol is NFS) THEN (guarantee 40% of available BW) (1b)
   If (IP protocol is TCP) THEN (guarantee 40% of available BW) (2)
      If (protocol is HTTP) THEN guarantee 20% of available BW) (2a)
      If (protocol is FTP) THEN (guarantee 30% of available BW) (2b)

Subrules 1a and 1b specify bandwidth allocation for UDP applications.
The total bandwidth resource being partitioned among UDP applications is
the bandwidth available for the UDP traffic class (i.e., 30%), not the
total bandwidth available at the interface level. Furthermore, TFTP and
NFS are guaranteed to get at least 10% and 40% of the total available
bandwidth for UDP, while other UDP applications aren't guaranteed to
receive anything. Thus, TFTP and NFS are guaranteed to get at least 3%
and 12% of the total bandwidth. Similar logic applies to the TCP
applications.

The point of this section will be to show that a hierarchical policy
representation enables a finer level of granularity for bandwidth
allocation to be specified than is otherwise available using a non-
hierarchical policy representation. To see this, let's compare this set
of rules with a non-hierarchical (flat) rule representation. In the non-
hierarchical representation, the guaranteed bandwidth for TFTP flows is
calculated by taking 10% of the bandwidth guaranteed to UDP flows,
resulting in 3% of the total interface bandwidth guarantee.

   If (UDP AND TFTP) THEN (guarantee 3% of available BW) (1a)
   If (UDP AND NFS) THEN (guarantee 12% of available BW) (1b)
   If (other UDP APPs) THEN (guarantee 15% of available BW) (1c)
   If (TCP AND HTTP) THEN guarantee 8% of available BW) (2a)
   If (TCP AND FTP) THEN (guarantee 12% of available BW) (2b)
   If (other TCP APPs) THEN (guarantee 20% of available BW) (2c)

Are these two representations identical? No, bandwidth allocation is not
the same. For example, within the hierarchical representation, UDP
applications are guaranteed 30% of the bandwidth. Suppose a single UDP
flow of an application different from NFS or TFTP is running. This
application would be guaranteed 30% of the interface bandwidth in the
hierarchical representation but only 15% of the interface bandwidth in
the flat representation.

A two stage scheduler is best modeled by a hierarchical representation
whereas a flat representation may be realized by a non-hierarchical
scheduler.

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         18

A schematic hierarchical Weighted-Round-Robin scheduler implementation
that supports the hierarchical rule representation is described below.

   --UDP AND TFTP queue--10%
   --UDP AND NFS  queue--40%-Scheduler-30%--+
   --Other UDP    queue--50%     A1         |
                                            |
   --TCP AND HTTP queue--20%                |
   --TCP AND FTP  queue--30%-Scheduler-40%--Scheduler--Interface
   --Other TCP    queue--50%     A2         |   B
                                            |
   ------------Non UDP/TCP traffic-----30%--+

Scheduler A1 extracts packets from the 3 UDP queues according to the
weight specified by the UDP sub-rule policy. Scheduler A2 extracts
packets from the 3 TCP queues specified by the TCP sub-rule policy. The
second stage scheduler B schedules between UDP, TCP and all other
traffic according to the policy specified in the top most rule level.

Another difference between the flat and hierarchical rule representation
is the actual division of bandwidth above the minimal bandwidth
guarantee.  Suppose two high rate streams are being forwarded via this
interface: an HTTP stream and an NFS stream. Suppose that the rate of
each flow is far beyond the capacity of the interface. In the flat
scheduler implementation, the ratio between the weights is 8:12 (i.e.,
HTTP:NFS), and therefore HTTP stream would consume 40% of the bandwidth
while NFS would consume 60% of the bandwidth. In the hierarchical
scheduler implementation the only scheduler that has two queues filled
is scheduler B, therefore the ratio between the HTTP (TCP) stream and
the NFS (UDP) stream would be 30:40, and therefore the HTTP stream would
consume approximately 42% of the interface bandwidth while NFS would
consume 58% of the interface bandwidth. In both cases both HTTP and NFS
streams got more than the minimal guaranteed bandwidth, but the actual
rates forwarded via the interface differ.

The conclusion is that hierarchical policy representation provides
additional structure and context beyond the flat policy representation.
Furthermore, policies specifying bandwidth allocation using rule
hierarchies should be enforced using hierarchical schedulers where the
rule hierarchy level is mapped to the hierarchical scheduler level.

1.4.2.  Use of Rule Hierarchy to Describe Drop Threshold Policies

Two major resources govern the per hop behavior in each node.  The
bandwidth allocation resource governs the forwarding behavior of QoS systems from different
vendors.

QPIM establishes a conceptual framework by fully each
traffic class. A scheduler priority and closely following weights are controlled by the core policy framework
bandwidth allocation policies, as well as specified in [PCIM] and [PCIMe]. QPIM
inherits all of its constructs from the 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 (minimal) number of queues
needed for traffic separation. A second resource, which is a ubiquitous modeling method
that not
controlled by bandwidth allocation policies, is easy to understand the queuing length and read. In addition, UML-based models
lend themselves to further extensions
drop behavior. For this purpose, queue length and natural progression toward
detailed data models. threshold policies are
used.

Snir, Ramberg, Strassner, Cohen Cohen, Moore       expires November 2001          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 May 2002         19

Rule hierarchy is represented by the QosPolicyTrfcProf (abstract) class. A
derivative of this class provides several attributes used to describe the context on which thresholds act.
The policy rule's condition describes the traffic in terms of average rate class and other characteristics.
Associations represent relationships among instances of different
classes or the same class. For example, the association
QoSPolicyViolateAction links a certain restriction on traffic
(represented by an instance of rule's
actions describe the QoSPolicyPoliceAction class) to an
action to be taken when bandwidth allocation, the restriction is violated.

6.	QPIM is abstract. The model is aimed at forwarding priority and
the formalization of humanly
expressed business QoS policies. For example, QPIM provides queue length. If the means
of expressing formally a business policy traffic class contains different drop
precedence sub-classes that states: "In our network,
IP telephony should receive require different thresholds within the same service quality as that
queue, the sub-rules actions describe these thresholds.

Below is an example of our
legacy phone systems". QPIM provides the topmost link use of rule nesting for threshold control
purposes. Let's look at the following rules:

      If (protocol is FTP) THEN (guarantee 10% of available BW)
                                (queue length equals 40 packets)
                                (drop technique is random)

         if (src-ip is from net 2.x.x.x) THEN min threshold = 30%
                                              max threshold = 70%

         if (src-ip is from net 3.x.x.x) THEN min threshold = 40%
                                              max threshold = 90%

         if (all other)                  THEN min threshold = 20%
                                              max threshold = 60%

The rule describes the
abstract business policy to bandwidth allocation, the concrete device implementation by
expressing queue length and the abstract business policy in high-level networking
terms. QPIM compliant tools can be built
drop technique assigned to further concretize FTP flows. The sub-rules describe the
high-level QoS policies defined in QPIM terms so that actual network
elements (PEPs) can be configured to enforce drop
threshold priorities within those FTP flows. FTP packets received from
all networks apart from networks 2.x.x.x and 3.x.x.x are randomly
dropped when the abstract business
policy.

7.	QPIM is QoS technology-agnostic, as it assumes no particular mechanism
(e.g., class-based weighted fair queuing) queue threshold for policy enforcement. For
example, a certain policy may require that traffic adhere FTP flows accumulates to a given
traffic profile. The traffic profile itself can be represented by an
instance of the QosPolicyTrfcProf class. The properties 20% of the profile
class may include an attribute representing
queue length. Once the average rate of
traffic in units of bits per second. However, QPIM neither describes
nor mandates a mechanism queue fills to perform 60%, all these packets are dropped
before queuing. The two other sub rules provide other thresholds for FTP
packets coming from the measuring mechanism itself.
Specifying such mechanisms specified two subnets. The Assured Forwarding
per hop behavior (AF) is in another good example of the realm use of network modeling, not
policy modeling.

Though a particular QoS mechanism (e.g., class-based weighted fair
queuing) is generic hierarchy to many types of devices, individual devices may
implement this generic mechanism differently.
describe the different drop preferences within a traffic class. This necessitates
example is provided in a
device-independent view later section.

1.4.3. Restrictions of controlling QoS mechanisms, which is
precisely what the Use of Hierarchy Within QPIM

Rule nesting is intended for. A single used within QPIM policy can be
translated into different configurations of different devices. For
example, a network interface card that can be configured for two important purposes:

  1) Enhance clarity, readability and reusability.
  2) Provide hierarchical context for actions.

The second point captures the ability to implement
several output queues and assign size and specify context for bandwidth allocation
parameters to each of them is a concrete element whose configuration
can be controlled with QPIM
allocation, as well as providing context for drop threshold policies.

Snir, Ramberg, Strassner, Cohen Cohen, Moore       expires November 2001          9

8.	QPIM adheres May 2002         20

When is a hierarchy level supposed to and interprets specify the two predominant QoS paradigms:
Differentiated (DiffServ) Services and Integrated Services (IntServ).
While both DiffServ and IntServ inherently model technology, bandwidth allocation
context, when is the
mechanisms implementing those technologies are not specified and are
left to hierarchy used for specifying the implementer's interpretation. DiffServ drop threshold
context, and IntServ are
described in [DIFFSERV] when is it used merely for clarity and [INTSERV], respectively. reusability? The term RSVP
refers to
answer depends entirely on the actions. Bandwidth control actions within
a protocol developed sub-rule specify how the bandwidth allocated to implement IntServ [RSVP]. the traffic class
determined by the rule's condition clause should be further divided
among the sub-rules. Drop threshold actions control the traffic class's
queue drop behavior for each of the sub-rules. The terms
IntServ and RSVP bandwidth control
actions have an implicit pointer saying: the bandwidth allocation is
relative to the bandwidth resources defined by the higher level rule.
Drop threshold actions have an implicit pointer saying: the thresholds
are sometime used interchangeably.

9.	QPIM taken from the queue resources defined by the higher level rule.
Other actions do not have such an implicit pointer, and for these
actions hierarchy is used only for reusability and readability purposes.

Each rule that includes a network-end-to-end model. This means bandwidth allocation action implies that QPIM policies can
describe the QoS a
queue should be allocated to the traffic throughout class defined by the network. QPIM
does not represent explicitly network topological concepts. Section
4.6 rule's
condition clause. Therefore, once a bandwidth allocation action exists
within the actions of [PCIMe] explains a role based mechanism that can be used for
mapping policies to PEPs. Neither [PCIM], [PCIMe] nor [QPIM] require sub-rule, a
particular topological view threshold action within this sub-
rule cannot refer to thresholds of the network parent rule's queue. Instead, it
must refer to the queue of the sub-rule itself. Therefore, in order to express
abstract policy.

1.3.  QPIM
have a clear and Other Published Standards

QPIM makes extensive use unambiguous definition, refinement of the concepts thresholds and constructs that
refinements of bandwidth allocations within sub-rules should be avoided.
If both refinements are
introduced by [PCIM] needed for the same rule, threshold refinements
and [PCIMe]. The entire bandwidth refinements rules should each be aggregated to a separate
group, and these groups should be aggregated under the policy rule,
using the PolicySetComponent aggregation.

1.5.  Intended Audiences

QPIM class hierarchy is
derived from [PCIM] and [PCIMe] classes. intended for several audiences. The concepts following lists some of policy, policy
groups, the
intended audiences and their respective uses:

  1.  Developers of QoS policy conditions, reusable objects values management applications can use this
      model as an extensible framework for defining policies to
      control PEPs and variables are used PDPs in QPIM directly. QPIM only introduces extensions where an interoperable manner.
  2.  Developers of Policy Decision Point (PDP) systems built to
      control resource allocation signaled by RSVP requests.
  3.  Developers of Policy Decision Points (PDP) systems built to create
      QoS actions,
values configuration for PEPs.
  4.  Builders of large organization data and variables are necessary knowledge bases who decide
      to add combine QoS specific semantics to the
framework defined by policy information with other networking policy
      information, assuming all modeling is based on [PCIM] and [PCIMe].

By modeling the information of both predominant QoS paradigms, DiffServ
and IntServ, QPIM unifies the two methodologies using a single class
inheritance tree, thus allowing a single context for thinking about QoS
policy.

Companion documents (e.g., [QoSSCHEMA]) define the mapping
  5.  Authors of QPIM's
classes various standards may use constructs introduced in this
      document to specific enhance their work. Authors of data models (schemata). For example, [QoSSCHEMA]
defines how wishing 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.

QPIM adheres to terminology as defined in [TERMS].

QPIM intentionally avoids references storage specific technology to 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
model the actual network. An example for network modeling is available in
[QDDIM], a must use this document that models QoS device data path and capabilities.
      as well.

Snir, Ramberg, Strassner, Cohen Cohen, Moore       expires November 2001         10 May 2002         21

2.  Class Hierarchies

2.1.  Inheritance Hierarchy

QPIM's class and association inheritance hierarchy is hierarchies are rooted in
[PCIM] and [PCIMe].  Figures 1 and 2 depict the these QPIM inheritance hierarchy
hierarchies, while noting its their relationships to [PCIM] and [PCIMe] classes. Figure 1 shows
[PCIMe]classes. Note that many other classes used to form QPIM policies,
such as SimplePolicyCondition, are defined in [PCIM] and [PCIMe]. Thus,
the following figures do NOT represent ALL necessary classes and
relationships for defining QPIM
inheritance hierarchy,. policies. Rather, the designer using
QPIM should use appropriate classes and relationships from [PCIM] and
[PCIMe] in conjunction with those defined below.

 [ManagedElement] (abstract, PCIM)
   |
   +--Policy (abstract, PCIM)
   |  |
   |  +---PolicyAction (abstract, PCIM)
   |  |     |
   |  |     +---SimplePolicyAction (PCIMe)
   |  |     |   |
   |  |     |   +---QoSPolicyRSVPSimpleAction (QPIM)
   |  |     |
   |  |     +---QoSPolicyDiscardAction (QPIM)
   |  |     |
   |  |     +---QoSPolicyAdmissionAction (abstract, QPIM)
   |  |     |   |
   |  |     |   +---QoSPolicyPoliceAction (QPIM)
   |  |     |   |
   |  |     |   +---QoSPolicyShapeActionAction   +---QoSPolicyShapeAction (QPIM)
   |  |     |   |
   |  |     |   +---QoSPolicyRSVPAdmissionAction (QPIM)
   |  |     |
   |  |     +---QosPolicyPHBAction     +---QoSPolicyPHBAction (abstract, QPIM)
   |  |         |
   |  |         +---QoSPolicyBandwidthAction (QPIM)
   |  |         |
   |  |         +---QoSPolicyCongestionControlAction (QPIM)
   |  |
   |  +---QosPolicyTrfcProf  +---QoSPolicyTrfcProf (abstract, QPIM)
   |  |   |
   |  |   +---QosPolicyTokenBucketTrfcProf   +---QoSPolicyTokenBucketTrfcProf (QPIM)
   |  |   |
   |  |   +---QosPolicyIntServTrfcProf   +---QoSPolicyIntServTrfcProf (QPIM)
   |  |

(continued on the next page)

Snir, Ramberg, Strassner, Cohen Cohen, Moore       expires November 2001         11 May 2002         22

(continued from the previous page)

[ManagedElement] (abstract, PCIM, repeated for convenience)
   |
   +--Policy (abstract, PCIM, repeated for convenience)
   |  |
   |  +---PolicyVariable (abstract, PCIMe)
   |  |   |
   |  |   +---PolicyImplicitVariable (abstract, PCIMe)
   |  |       |
   |  |       +---QoSPolicyRSVPVariable (abstract, QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPSourceIPv4Variable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPDestinationIPv4Variable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPSourceIPv6Variable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPDestinationIPv6Variable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPSourcePortVariable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPDestinationPortVariable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPIPProtocolVariable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPIPVersionVariable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPDCLASSVariable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPStyleVariable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPDIntServVariable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPMessageTypeVariable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPPreemptionPriorityVariable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPPreemptionDefPriorityVariable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPUserVariable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPApplicationVariable (QPIM)
   |  |           |
   |  |           +---QoSPolicyRSVPAuthMethodVariable (QPIM)
   |  |
   |  +---PolicyValue (abstract, PCIMe)
   |  |     |
   |  |     +---QoSPolicyDNValue (QPIM)
   |  |     |
   |  |     +---QoSPolicyAttributeValue (QPIM)

           Figure 1.  The QPIM Class Inheritance Hierarchy

Snir, Ramberg, Strassner, Cohen          expires November 2001         12 Cohen, Moore       expires May 2002         23

2.2.  Relationship Hierarchy

Figure 2 shows the QPIM association relationship hierarchy.

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

    Figure 2.  The QPIM Association Class Inheritance Hierarchy

Snir, Ramberg, Strassner, Cohen Cohen, Moore       expires November 2001         13 May 2002         24

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). that are
derived from both of these classes, which are described below.

Note that there is no discussion of PolicyRule, PolicyGroup, or
different types of PolicyCondition classes in this document. This is
because these classes are fully specified in [PCIM] and [PCIMe].

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 enable controlling environments in which RSVP signaling
is used to request different forwarding treatment for different traffic
types from the network network, as well as environments where no signaling is
used, but preferred treatment is desired for some (not (but not all) traffic. traffic
types. QoS policy rules also allow controlling environments where strict
QoS guarantees are provided to individual flows flows, as well as environments
where QoS is provided to flow aggregates. QoS actions allow a PDP or a
PEP to determine which RSVP requests should be admitted because they satisfy a
given policy, before network
resources are allocated. They QoS actions allow control of the RSVP signaling
content itself, as well as differentiation between priorities of RSVP
requests. QoS actions also allow specification of controlling the
Differential Differentiated Service edge
enforcement including policing, shaping and marking, as well as the per-hop per-
hop behaviors used in the network core. Finally, QoS actions can be used
to control mapping of RSVP request requests at the edge of a differential differentiated
service cloud into per hop behaviors.

Four groups of actions are derived from action classes defined in [PCIM]
and [PCIMe]. The first QoS action group contains a single action,
QoSPolicyRSVPSimpleAction. This action is used for both RSVP signal
control and install actions depending on a type attribute. actions. 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 profile using the QoSPolicyTrfcProf
class and its subclasses. This set of actions are called also includes QoS
admission actions. control actions, which use the QoSPolicyAdmissionAction class
and its subclasses.  The third group of actions control bandwidth
allocation and congestion control differentiations, which together
specify the per-hop behavior forwarding treatment. This group of actions
includes the QoSPolicyPHBAction class and its subclasses. The
forth fourth QoS
action is an unconditional packet discard action. action, which uses the
QoSPolicyDiscardAction class. This action is used either by itself or as
a building block of the QoSPolicyPoliceAction.

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         25

Note that some QoS actions are not directly modeled. Instead, they are
modeled by using the class SimplePolicyAction with the appropriate
associations. For example, the three marking actions (DSCP, IPP and CoS)
are modeled by using the SimplePolicyAction class, and associating it that
class with variables and values of the appropriate type.

Snir, Ramberg, Strassner, Cohen          expires November 2001         14 type defined in
[PCIMe].

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  Add or modify the request or
not
3.	Use signaling admission parameters to decide how to modify
  3.  Modify the RSVP signaling
messages content

The COPS for RSVP [RFC2749] specification uses different Decision object
types to model each of these decisions. QPIM follows the COPS for RSVP
specification and models each decision using a different action class.

The QoSPolicyRSVPAdmissionAction controls the Decision Command and
Decision Flags objects used within COPS for RSVP. The
QoSPolicyRSVPAdmissionAction class, with its associated
QosPolicyIntServTrfcProf
QoSPolicyIntServTrfcProf class, is used to determine whether to accept
or reject a given RSVP request by comparing the RSVP request's TSPEC or
RSPEC parameters against the traffic profile. For a full description of the comparison
method, see section 4, which describes traffic profiles in more detail.

Using the QoSPolicyRSVPAdmissionAction, a limit on the number of admitted
reservations can be enforced as well. The QoSPolicyRSVPAdmissionAction
can specify that the traffic profile specified by the
QoSPolicyIntServTrfcProf. For a set full description of the comparison
method, see section 4. Following the COPS for RSVP requests will be accepted yet specification, the
admission decision has an option to both accept the request and send a
warning
message would be sent to the RSVP end points. requester. The QoSPolicyRSVPAdmissionAction controls the Decision Command and Decision
Flags objects can be used within COPS for RSVP.
to limit the number of admitted reservations as well.

The class QoSPolicyRSVPSimpleAction, which is derived from the
PolicySimpleAction class [PCIMe], can be used to specify control the two other
COPS RSVP decisions. decision types.  The property qpRSVPActionType designates the
instance of the class to be either of type 'REPLACE', 'STATELESS', or both.
both ('REPLACEANDSTATELESS'). For instances carrying a qpRSVPActionType
property value of 'REPLACE', the action is interpreted as a COPS Replace
Decision, controlling the contents of the RSVP message. For instances
carrying a qpRSVPActionType property value of 'STATELESS', the action is
interpreted as a COPS Stateless Decision, controlling the admission
parameters. If both of these actions are required, this can be done by
assigning both of the two value REPLACEANDSTATELESS to the qpRSVPActionType values, since it is a
multi-valued
property.

This class is 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 only
required extension might be the definition of a new RSVP variable.

Snir, Ramberg, Strassner, Cohen Cohen, Moore       expires November 2001         15 May 2002         26

3.2.1.  Example: Controlling COPS Stateless Decision

The QoSPolicyRSVPSimpleAction allows the specification of admission
parameters. It allows specification of the preemption priority [RFC2751]
of a given RSVP Reservation request. Using the preemption priority
value, the PEP can determine the importance of a Reservation compared
with already admitted reservations, and if necessary can preempt lower
priority reservations to make room for the higher priority one. This
class can also be used to control mapping of RSVP requests to a
differentiated services domain by setting the QoSPolicyRSVPDSCPVariable
QoSPolicyRSVPDCLASSVariable to the required value. This instructs the
PEP to mark traffic matching the Session and Sender specifications
carried in an RSVP request to a given DSCP value.

3.2.2.  Example: Controlling the COPS Replace Decision

A Policy system should be able to control the information carried in the
RSVP messages. The QoSPolicyRSVPSimpleAction allows control of the
content of RSVP signaling messages. An RSVP message can carry a
preemption policy object [RFC2751] specifying the priority of the
reservation request in comparison to other requests. An RSVP message can
also carry a policy object for authentication purposes. An RSVP message
can carry a DCLASS [DCLASS] object that specifies to the receiver or
sender the particular DSCP value that should be set on the data traffic.
A COPS for RSVP Replacement Data Decision controls the content of the
RSVP message by specifying a set of RSVP objects replacing or removing
the existing ones.

3.3  Provisioning Policy Actions

The differentiated Service Architecture [DIFFSERV] was designed to
provide a scalable QoS differentiation without requiring any signaling
protocols running between the hosts and the network. The QoS actions
modeled in QPIM can be used to control all of the building blocks of the
Differentiated Service architecture, including per-hop behaviors, edge
classification, and policing and shaping, without a need to specify the
datapath mechanisms used by PEP implementations. This provides an
abstraction level hiding the unnecessary details and allowing the
network administrator to write rules that express the network
requirements in a more natural form. In this architecture, as no
signaling between the end host and the network occur occurs before the sender
starts sending information, the QoS mechanisms should be setup set up in
advance. This usually means that PEPs need to be provisioned with the
set of policy rules in advance.
Policing policy rules in advance.

Policing and Shaping actions are modeled as subclasses of the QoS
admission action. DSCP and CoS marking are modeled by using the
SimplePolicyAction ([PCIMe]) class associated with the appropriate
variables and values. Bandwidth allocation and congestion control
actions are modeled as subclasses of the QpQPolicyPHBAction, which is
itself a subclass PolicyAction class ([PCIM])

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         27

3.3.1.  Admission Actions: Controlling Policers and Shapers

Admission Actions (QoSPolicyAdmissionAction and its subclasses) are used
to police and/or shape traffic.

Each Admission Action is bound to a traffic profile (QoSPolicyTrfcProf)
via the QoSPolicyTrfcProfInAdmissionAction association. The traffic
profile is used to meter traffic for purposes of policing or shaping.

An Admission Action carries a scope property (qpAdmissionScope) that is
used to determine whether the action controls individual traffic flows
or aggregate traffic classes. The concepts of "flow" and "traffic class"
are explained in [DIFFSERV] using the terms 'microflow' and 'traffic
stream'. Roughly speaking, a flow is a set of packets carrying an IP
header that has the same values for source IP, destination IP, protocol
and layer 4 source and destination ports. A traffic class is a set of
flows. In QPIM, simple and Shaping actions are modeled as sub-classes compound conditions can identify flows and/or
traffic classes by using Boolean terms over the values of IP header
fields, including the QoS
admission action. DSCP and CoS marking are modeled as sub-classes value of the
simplePolicyAction class. Bandwidth allocation, scheduling and congestion
control actions are modeled as sub-classes ToS byte.

Thus, the interpretation of the QoS PHB action.

Snir, Ramberg, Strassner, Cohen          expires November 2001         16

3.3.1.  Admission Actions: Controlling Policers and Shapers

All Admission Actions have in common an association to a traffic profile
and a scope property that determines whether the traffic profile is
compared against as follows: If the rate parameters
value of the scope property is 0 (per-flow), each (micro) flow or against that can
be positively matched with the
aggregate rate rule's condition is metered and policed
individually. If the value of the scope property is 1 (per-class), all
flows that match matched with the rule's condition. For example,
using condition are metered as a single
aggregate and policed together.

The following example illustrates the use of the scope property. Using
two provisioned policer actions policing 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 same QoSPolicyPoliceAction. class QoSPolicyPoliceAction
(derived from QoSPolicyAdmissionAction). The first policy has its scope
property set to 'flow', while the second policy has its scope property
set to 'class'. The two policies are modeled using a rule with two
police actions that, in a pseudo formal definition, looks
like 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 provisioned policing action QoSPolicyPoliceAction has three
associations, QoSPolicyConformAction, QoSPolicyExceedAction and
QoSPolicyViolateAction.

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         28

To accomplish the desired result stated above, two possible modeling
techniques may be used: The two actions can be part of a single policy
rule using two PolicyActionInPolicyRule [PCIM] associations. In this
case the ExecutionStrategy property of the PolicyRule class [PCIMe]
SHOULD be set to "Do All" so that both individual flows and aggregate
streams are policed.

Alternatively, Action1 and Action2 could be aggregated in a
CompundPolicyAction instance using the following:

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

The provisioned policer action QoSPolicyPoliceAction has 3 associations,
QoSPolicyConformAction, QoSPolicyExceedAction PolicyActionInPolicyAction
aggregations [PCIMe]. In this case, in order for both individual flows
and QoSPolicyViolateAction. aggregate traffic classes to be policed, the ExecutionStrategy
property of the CompoundPolicyAction class [PCIMe] SHOULD be set to "Do
All".

The policer policing action is associated with a three-level token bucket
traffic profile carrying rate, burst and excess-burst parameters.
Traffic measured by a meter can be classified as conforming traffic when
the metered rate is below the rate defined by the traffic profile, as
excess traffic when the metered traffic is above the normal burst and
below the excess burst size, and violating traffic when rate is above
the maximum excess burst.

The [DIFF-MIB] defines a two-level meter, and provides a means to
combine two-level meters into more complex meters. In this document, a three-
level
three-level traffic profile is defined. This allows construction of both two-
level
two-level meters as well as providing an easier definition for three-level three-
level meters needed for creating AF [AF] provisioning actions.

A policer action with a non-specified conform policing action implies that
conforming traffic should not be modified. A policer action models three-level policing MUST associate three
separate actions with an
associated a three-level traffic profile that does not specify profile. These actions are a
conforming action, an excess exceeding action implies that the excess traffic should be treated as either
violating or conforming traffic according to some algorithm suitable for
the enforcement of the rule. For example, the final enforcement of such and a
rule may be the use of violating action. A
policing action that models two-level policing uses a random function similar to RED to determine
whether two-level traffic is
profile and associates only conforming or violating. and exceeding actions. A policer policing
action with a three-level traffic profile that specifies an exceed
action but does not specify a violate action implies that violate the action
taken when the traffic is above the maximum excess burst is identical to
the
specified exceed action.

Snir, Ramberg, Strassner, Cohen          expires November 2001         17 action taken when the traffic is above the normal burst. A policer
determines whether the profile is being met, while the actions to be
performed are determined by the associations QoSPolicyXXXAction.

Shapers are used to delay some or all of the packets in a traffic stream
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. Shaping is controlled by the QoSPolicyShapeAction class.  The
only required association is a traffic profile that specifies the rate
and burst parameters that the outgoing flows should conform with.

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         29

3.3.2  Controlling Markers

Three types of markers marking control actions are modeled in QPIM:
Differentiated Services Code Point (DSCP), (DSCP) assignment, IP Precedence
(IPP) assignment and layer-2 Class of Service (CoS). The
marking action itself is (CoS) assignment. These
assignment actions themselves are modeled by using the
SimplePolicyAction class associated with the appropriate variables and
values.

DSCP markers set assignment sets ("marks" or "colors") the DS field of a packet
header to a particular DS Code Point (DSCP), adding the marked packet to
a particular DS behavior aggregate. The marker may be configured

When used in the basic form, "If <condition> then 'DCSP = ds1'", the
assignment action assigns a DSCP value (ds1) to mark all packets that it
receives to a single DSCP, or may be configured result
in the condition being evaluated to mark true.

When used in combination with a packet to one
of policing action, a set different assignment
action can be issued via each of DSCPs used to the 'conform', 'exceed' and 'violate'
action associations. This way, one may 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 assignment is encapsulated in the pairing of a
DSCP variable and a DSCP value within a single SimplePolicyAction
instance via the appropriate associations.

IPP markers set assignment sets the IPP field of a packet header to a particular IPP
value (0 through 7). The semantics of the IPP marker assignment is encapsulated
in the pairing of a DSCP ToS variable masked to IPP sub-field (PolicyIPTosVariable) and a DSCP bit string value
masked to IPP sub-field
() (defined in [PCIMe]) within a single SimplePolicyAction instance via the
appropriate associations. The bit string value is used in its masked bit string
format. The mask indicates the relevant 3 bits of the IPP sub field within the
ToS byte, while the bit string indicates the IPP value to be set.

CoS markers assignments control the mapping of a per-hop behavior to a layer-2
Class of Service. For example, mapping of a set of DSCP values into a 802.1q
802.1p user priority value can be specified using a rule with a
condition describing the set of DSCP values, and a CoS marking assignment action
that specifies the required mapping to the given user priority priority value.
The semantics of the CoS marker assignment is encapsulated in the pairing of a
CoS variable and a CoS value (integer in the range of 0 through 7)
within a single SimplePolicyAction instance via the appropriate
associations.

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         30

3.3.3  Controlling Edge Policies - Examples

Assuming that the AF1 behavior aggregate is enforced within a DS domain,
policy rules on the edge boundaries of the network should mark packets to one
of the AF1x DSCPs DSCPs, depending on the conformance of the traffic to a
predetermined three-parameter traffic profile. QPIM models such AF1
policing action as defined in Figure 3.

Snir, Ramberg, Strassner, Cohen          expires November 2001         18

     +-----------------------+    +------------------------------+
     | QoSPolicyPoliceAction |====| QoSPolicyTokenBucketTrfcProf |
     | scope = class         |    | rate = x, bc = y, be = z     |
     +-----------------------+    +------------------------------+
       *     @     #
       *     @     #
       *     @  +-------------------------+  +--------------------+   +--------------------------+
       *     @  | SimplePolicyAction |---| PolicyIntegerValue -AF13 |
       *     @  +-------------------------+   |        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 marker AF policing action is made composed of an instance a police action, a token bucket
traffic profile and three instances of the SimplePolicyAction class. The
Each of the simple policy action instances models a different marking
action. Each SimplePolicyAction uses the aggregation
PolicyVariableInSimplePolicyAction (which is defined in
[PCIMe]) is used to associate specify that the value associated
PolicyDSCPVariable is set to mark (contained in the
PolicyDSCPValue) with the appropriate traffic action. integer value.  This aggregation is
done using the PolicyValueInSimplePolicyAction aggregation. The three
PolicyVariableInSimplePolicyAction aggregations which connect the
appropriate SimplePolicyActions with the appropriate DSCP Variables, are
not shown in this figure for simplicity. AF11 is marked on detecting
conforming traffic; AF12 is marked on detecting exceeding action traffic, and
AF13 on detecting violating traffic.

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         31

The second example, shown in Figure 4, is the simplest policing action.
Traffic below a two-parameter traffic profile is unmodified, while
traffic exceeding the traffic profile is 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 a description of the externally observable
forwarding behavior of a DS node applied to a particular DS behavior
aggregate [DIFFSERV]. The approach taken here is that a PHB action
specifies both observable forwarding behavior (i.e., (e.g., loss, delay,
jitter) as well as specifying the buffer and bandwidth resources that
need to be allocated to each of the behavior aggregates in order to
achieve this behavior. 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 EF packets need to be treated
with preemptive forwarding (e.g., with priority queuing), and specify
the maximum bandwidth for this class class, as well as the maximum buffer
resources. PHB actions can therefore be used to both to represent the final
requirements from PHBs as well as and to provide enough detail to be able to map
the PHB actions into a set of configuration parameters to configure
queues, schedulers, droppers and other mechanisms.

The QoSPolicyPHBAction abstract class has two subclasses. The
QoSPolicyBandwidthAction class is used to control bandwidth, delay and
forwarding behavior, while the QoSPolicyCongestionControlAction class is
used to control queue size, thresholds and congestion algorithms. The
qpPacketSize
qpMaxPacketSize property of the PHB action QoSPolicyPHBAction class specifies the
packet size in bytes, and is needed when translating the bandwidth and
congestion control actions into actual implementation configurations.
For example, an implementation measuring queue length in bytes will need
to use this property to map the qpQueueSize property into the desired
queue length in bytes.

Snir, Ramberg, Strassner, Cohen Cohen, Moore       expires November 2001         20 May 2002         32

3.4.1  Controlling Bandwidth and Delay

QoSPolicyBandwidthAction 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 as a percentage of the total
available bandwidth. The property qpBandwidthUnits is used to determine
whether
percentage percentages or fixed values are used.

The property qpForwardingPriority is used whenever preemptive forwarding
is required. A policy rule that defines the EF PHB should indicate a non-
zero
non-zero forwarding priority. The qpForwardingPriority property holds an
integer value to enable multiple levels of preemptive forwarding where
higher values are used to specify higher priority.

The property qpMaxBandwidth specifies the maximum bandwidth that should
be allocated to a class of traffic. This property may be specified in
PHB actions with non-zero forwarding priority in order to guard against
starvation of other PHBs.

The properties qpMaxDelay and qpMaxJitter specify limits on the per-hop
delay and jitter in milliseconds for any given packet within a 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 may also require
fragmentation and interleave mechanisms over low speed links.

The Boolean property qpFairness indicates whether flows should have a
fair chance to be forwarded without drop or delay. A way to enforce a
bandwidth action with qpFairness set to TRUE would be to build a queue
per flow for the class of traffic specified in the rule's filter. In
this way, interactive flows like terminal access will not be queued
behind a bursty flow (like FTP) and therefore have a reasonable response
time.

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 property 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 property qpQueueSizeUnit determines
whether queue size is measured in number of packets or in milliseconds.

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         33

The property qpDropAlgorithm qpDropMethod selects either tail-drop, head-drop or
random-drop random-
drop algorithms. The set of maximum and minimum threshold values can be
specified as well, using qpThresholdMin qpDropMinThresholdValue and qpThresholdMax
qpDropMaxThresholdValue properties, either in packets or in percentage
of the total available queue size as specified by the qpThresholdUnits
qpDropThresholdUnits property.

Snir, Ramberg, Strassner, Cohen          expires November 2001         21

3.4.3  Using Hierarchical Policies  Policies: Examples for PHB actions Actions

Hierarchical policy definition is a primary tool in the QoS Policy
Information
information model. Rule nesting introduced in [PCIMe] allows
specification of hierarchical policies controlling RSVP requests,
hierarchical shaping, policing and marking actions, as well as
hierarchical schedulers and definition of the differences in PHB groups.
An example of the use of hierarchical schedulers is provided in [PCIMe].

This example provides a set of rules that specify PHBs enforced within a
Differentiated Service Domain. domain. The network administrator chose to
enforce the EF, AF11 and AF13 and Best Effort PHBs. For simplicity, AF12
is not differentiated. The set of rules takes the form:

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

EF, AF1 AF1, AF11, AF12 and AF13 are conditions that filter traffic
according to DSCP values. The AF1 condition matches the entire AF1 PHB
group including the AF11, AF12 and AF13 DSCP values. The default rule uses a 'match all'
condition and
specifies the Best Effort rules. The nesting of the AF13
rule AF1x rules within
the AF1 rule specifies that there are further refinements on how AF13 AF1x
traffic should be treated relative to the entire AF1 PHB group. The set
of rules reside in a PolicyGroup with a decision strategy property set
to 'MATCH FIRST'. 'FirstMatching'.

The class instances below specify the set of actions used to describe
each of the PHBs. Queue sizes are not specified, but can easily be added
to the example.

The actions used to describe the Best Effort PHB are simple. No
bandwidth is allocated to Best Effort traffic. The first action
specifies that Best Effort traffic class should have fairness.

QosPolicyBandwidthAction

QoSPolicyBandwidthAction  BE-B:
  qpFairness: True

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         34

The second action specifies that the congestion algorithm for the Best
Effort traffic class should be random, and specifies the thresholds in
percentage of the default queue size.

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

Snir, Ramberg, Strassner, Cohen          expires November 2001         22

EF requires preemptive forwarding. The maximum bandwidth is also
specified to 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 random dropper.

QosPolicyBandwidthAction

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

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

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

QosPolicyBandwidthAction

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

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

The AF13 action AF1i actions specifies the differentiating refinement for the AF13 PHB AF1x
PHBs within the AF1 PHB group. The lower different threshold values provide
the higher difference in discard probability of the AF13 PHB.

QosPolicyCongestionControlAction AF1x PHBs within the AF1
PHB group.

QoSPolicyCongestionControlAction  AF11-C:
  qpDropMethod: random
  qpDropThresholdUnits packet
  qpDropMinThreshold:  6 packets
  qpDropMaxThreshold:  16 packets

QoSPolicyCongestionControlAction  AF12-C:
  qpDropMethod: random
  qpDropThresholdUnits packet
  qpDropMinThreshold:  4 packets
  qpDropMaxThreshold:  13 packets

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         35

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

4.  Traffic Profiles

Meters measure the temporal state of a flow or a set of flows against a
traffic profile. In this document, traffic profiles are modeled by the
gpsPolicyTrfcProf
QoSPolicyTrfcProf class. The association
QoSPolicyTrfcProfileInAdmissionAction binds the traffic profile to the
admission action using it. Two traffic profiles are derived from the
abstract class gpsPolicyTrfcProf. QoSPolicyTrfcProf. The first is a Token Bucket
Provisioning
provisioning traffic profile carrying rate and burst parameters. The
second is an RSVP traffic profile, which enables flows to be compared
with RSVP TSPEC and FLOWSPEC parameters.

Snir, Ramberg, Strassner, Cohen          expires November 2001         23

4.1  Provisioning Traffic Profiles

Provisioned Admission Actions Actions, including Shaping shaping and policing policing, are
specified using a two- or three-parameter token bucket traffic profile.
The qosPolicyTokenBucketTrfcProf QoSPolicyTokenBucketTrfcProf 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 is conforming, as long as the normal burst is not
exceeded at any time. Traffic exceeding the normal burst but still below
the excess burst is exceeding the traffic profile. Traffic beyond the
excess burst is said to be violating the traffic profile.

Excess burst size is measured in bytes in addition to the burst size. A
zero excess burst size indicates that no excess burst is allowed.

4.2  RSVP traffic profiles

RSVP admission 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
admission decision can be based on matching individual RSVP requests
against a traffic profile or by matching the aggregated sum of all
FLOWSPECs (TSPECs) currently admitted. admitted, as determined by the
qpAdmissionScope property in an associated QoSPolicyRSVPAdmissionAction.

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         36

The QosPolicyIntesrvTrfcProf QoSPolicyIntservTrfcProf class models both such traffic profiles.
This 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

The first 5 five parameters are the traffic specification parameters used
in the integrated service architecture. Integrated Service architecture ([INTSERV]). These parameters are
used to define a sender TSPEC as well as a FLOWSPEC for the Controlled-Load Controlled-
Load service [CL]. For a definition and full explanation of their meaning,
meanings, please refer to [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 TSPEC A
is larger than the TSPEC B if and only if rA>rB, pA>pB, bA>bB, mA<mB and
MA>MB. A TSPEC (FLOWSPEC) 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. s. The
term 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 value of the minimum policed unit m and the
maximum value of the maximum packet size M. GS FLOWSPECs are summed by
adding the Resv rate and minimizing the slack term s. These rules are
used to compute the temporal state of admitted RSVP states matching the
traffic class defined by the rule condition. This state is compared with
the traffic profile to arrive to at an admission decision when the scope of
the QoSPolicyRSVPAdmissionAction is set to 'class'.

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         37

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 this section is to define frequently used variables in QoS
policy domains.

Notice that this section only adds to the variable classes as defined in
[PCIMe] and reuses the mechanism defined there.

The QoS policy information model specifies a set of pre-defined variable
classes to support a set of fundamental QoS terms that are commonly used
to form conditions and actions and are missing from the [PCIMe].
Examples of these include RSVP related variables. All variable classes
defined in this document extend the QoSPolicyRSVPVariable class (defined
in this document), which itself extends the PolicyImplictVariable class,
defined in [PCIMe]. Subclasses specify the data type and semantics of
the policy variables.

This Draft draft defines the following RSVP variable classes, classes; for details details, see
their class definition:

Snir, Ramberg, Strassner, Cohen          expires November 2001         25 definitions:

RSVP related Variables:

  1.  QoSPolicyRSVPSourceIPv4Variable - The source IP IPv4 address of the
      RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE
      and RSVP RESV FILTER_SPEC [RSVP] objects.
  2.  QoSPolicyRSVPDestinationIPv4Variable - The destination port of the
      RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION
      [RSVP] objects. objects (for IPv4 traffic).
  3.  QoSPolicyRSVPSourceIPv6Variable - The source IP IPv6 address of the
      RSVP signaled flow, as defied in the RSVP PATH SENDER_TEMPLATE and
      RSVP RESV FILTER_SPEC [RSVP] objects.
  4.  QoSPolicyRSVPDestinationIPv6Variable - The destination port of the
      RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION
      [RSVP] objects. objects (for IPv6 traffic).
  5.  QoSPolicyRSVPSourcePortVariable - The source port of the RSVP
      signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and
      RSVP RESV FILTER_SPEC [RSVP] objects.
  6.  QoSPolicyRSVPDestinationPortVariable - The destination port of the
      RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION
      [RSVP] objects.
  7.  QoSPolicyRSVPIPProtocolVariable - The IP Protocol of the RSVP
      signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP]
      objects.
  8.  QoSPolicyRSVPIPVersionVariable - The IP version of the IP Addresses
carried addresses
      carrying the RSVP signaled flow, as defined in the RSVP PATH and
      RESV SESSION [RSVP] objects.
  9.  QoSPolicyRSVPDCLASSVariable - The DSCP value as defined in the
      RSVP DCLASS [DCLASS] object.
 10.  QoSPolicyRSVPStyleVariable - The reservation style (FF, SE, WF) as
      defined in the RSVP Resv message [RSVP].

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         38
 11.  QoSPolicyRSVPIntServVariable - The integrated type of Integrated Service (CL,
      GS, NULL) requested in the RSVP Reservation message, as defined in
      the FLOWSPEC RSVP Object [RSVP].
 12.  QoSPolicyRSVPMessageTypeVariable - The 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 defined in [RFC2751].
 15.  QoSPolicyRSVPUserVariable - The ID of the user that initiated the
      flow as defined in the User Locator string in the Identity Policy
      Object [RFC2752].
 16.  QoSPolicyRSVPApplicationVariable - The ID of the application that
      generated the flow as defined in the application locator string in
      the Application policy object [RFC2872] [RFC2872].
 17.  QoSPolicyRSVPAuthMethodVariable - The RSVP Authentication type
      used in the Identity Policy Object [RFC2752].

Each class restricts the possible value types associated with a specific
variable. For example, 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. PolicyIntegerValue.

Snir, Ramberg, Strassner, Cohen Cohen, Moore       expires November 2001         26 May 2002         39

6.  QoS Related Values

Values are used in the information model as building blocks for the
policy conditions and policy actions, as described in [PCIM] and
[PCIMe]. This section defines a set of auxiliary values that are used
for QoS policies as well as other policy domains.

All value classes extend the PolicyImplicitValue PolicyValue class [PCIMe]. The subclasses
specify specific data/value types that are not defined in [PCIMe].

This document defines the following two subclasses of the
PolicyImplicitValue PolicyValue
class:

  QoSPolicyDNValue - This class is used to represent a single or set of
                     Distinguished Name [DNDEF] values, including
                     wildcards. A Distinguished Name is a name that can
                     be used as a key to retrieve an object from a
                     directory service. This value can be used in
                     comparison to reference values carried in RSVP
                     policy objects, as specified in [RFC2752]. This
                     class is defined in Section 8.31.

  QoSPolicyAttributeValue - A condition term uses the form "Variable
                            matches Value", and an action term uses
                            the form "set Variable to Value" ([PCIMe]).
                            This class is used to represent a single or
                            set of property values for the "Value" term
                            in either a condition or an object. action.
                            This value can be used in conjunction with
                            reference values carried in RSVP objects, as
                            specified in [RFC2752]. This class is
                            defined in section 8.12.

The property name is used to specify which of the properties in the
object
QoSPolicyAttributeValue class instance is being used as in the condition. condition or
action term. The value of this property or properties will then be retrieved, and
retrieved. In the case of a condition, a match (which is dependent on
the property name) will be used to see if the condition is satisfied or
not. In the case of an action, the semantics are instead "set the
variable to this value".

For example, suppose the "user" objects in the organization include
several properties, among them:

   - First Name
   - Last Name
   - Login Name
   - Department
   - Title

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         40

A simple condition could be constructed to identify flows by their RSVP
user carried policy object. The simple condition: Last Name = "Smith" to
identify a User class has user named Bill would be constructed in the following way:

    A SimplePolicyCondition [PCIMe] would aggregate a multi-valued Property called
'member-of' that lists
    QoSPolicyRSVPUserVariable [QPIM] object, via the names of groups that this user belongs to.
Suppose
    PolicyVariableInSimplePolicyCondition [PCIMe] aggregation.

The implicit value associated with this property uses caseIgnoreMatch matching. condition is created in the
following way:

 A QoSPolicyAttributeValue object would be aggregated to the simple
 condition object via a PolicyValueInSimplePolicyCondition [PCIMe].
 The QoSPolicyAttributeValue attribute qpAttributeName would be set
 to "last name" and the qpAttributeValueList would be set to "Smith".

Another example is a condition that has to do with the user's
organizational department. It can be constructed in the exact same way,
by changing the QoSPolicyAttributeValue attribute qpAttributeName to match
"Department" and the reference carried in an RSVP Identity
policy object qpAttributeValueList would be set to the particular
value that is to be matched (e.g., "engineering" or "customer support").
The logical condition would than be evaluated to true if the user belong
to a gpsPolicyAttributeValue with either the following
characteristics:

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

A User Identity policy object carrying engineering department or the following reference:

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

will match this simple condition only if J. Smith belongs customer support.

Notice that many multiple-attribute objects require the use of the
QoSPolicyAttributeValue class to group-a. specify exactly which of its attributes
should be used in the condition match operation.

Snir, Ramberg, Strassner, Cohen Cohen, Moore       expires November 2001         27 May 2002         41

7.  Class Definitions: Association Hierarchy

The following sections define associations that are specified by QPIM.

7.1. The Association "QosPolicyTrfcProfInAdmissionAction" "QoSPolicyTrfcProfInAdmissionAction"

This association links a gpsPolicyTrfcProf QoSPolicyTrfcProf object (defined in section
8.9), modeling a specific traffic profile profile, to a QoSPolicyAdmissionAction
object (defined in section 8.2). The class definition for this
association is as follows:

NAME              QoSPolicyTrfcProfInAdmissionAction
DESCRIPTION       A class representing the association between a
                  QoS admission action and its traffic profile.
DERIVED FROM      Dependency (See [PCIM])
ABSTRACT          FALSE
PROPERTIES        Antecedent[ref QoSPolicyAdmissionAction [0..n]]
                  Dependent[ref QoSPolicyTrfcProf [1..1]]

7.1.1. The Reference "Antecedent"

This property is inherited from the Dependency association, defined in
[PCIM].  Its type is overridden to become an object reference to a
QoSPolicyAdmissionAction object. This represents the "independent" part
of the association. The [0..n] cardinality indicates that any number of
QoSPolicyAdmissionAction object(s) may use a given QoSPolicyTrfcProfile.

7.1.2. The Reference "Dependent"

This property is inherited from the Dependency association, and is
overridden to become an object reference to a QoSPolicyTrfcProfile
object. This represents a specific traffic profile that is used by any
number of QoSPolicyAdmissionAction objects. The [1..1] cardinality means
that exactly one object of the QoSPolicyTrfcProfile can be used by a
given QoSPolicyAddmissionAction.

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         42

7.2  The Association "PolicyConformAction"

This association links a policing action with an object defining an
action to be applied to conforming traffic relative to the associated
traffic profile. The class definition for this association is as
follows:

NAME			QosPolicyTrfcProfInAdmissionAction              PolicyConformAction
DESCRIPTION       A class representing the association between a
                  policing action and the action that should be applied
                  to traffic conforming to an associated traffic profile used for admission decision
                  profile.
DERIVED FROM      Dependency (see [PCIM])
ABSTRACT          FALSE
PROPERTIES        Antecedent[ref QoSPolicyAdmissionAction [0..n]] QoSPolicyPoliceAction[0..n]]
                  Dependent[ref QoSPolicyTrfcProf [0..n]]

7.1.1. PolicyAction [1..1]]

7.2.1. The Reference "Antecedent"

This property is inherited from the Dependency association, defined in
[PCIM]. association.  Its type is
overridden to become an object reference to a
QoSPolicyAdmissionAction QoSPolicyPoliceAction
object. This represents the "independent" part of the association. The
[0..n] cardinality indicates that a given
QoSPolicyAdmissionAction object any number of QoSPolicyPoliceAction
objects may have 0 or more traffic profiles that
it can use.

7.1.2. be given the same action to be executed as the conforming
action.

7.2.2. The Reference "Dependent"

This property is inherited from the Dependency association, and is
overridden to become an object reference to a QoSPolicyTrfcProfile PolicyAction object. This
represents a specific traffic profile policy action that is used by a given QoSPolicyAdmissionAction.
QoSPolicyPoliceAction. The [0..n] [1..1] cardinality means that a given
traffic profile may exactly one
policy action  can be used by 0 or as the "conform" action for a
QoSPolicyPoliceAction. To execute more admission actions.

7.2 than one conforming action, use
the PolicyCompoundAction class to model the conforming action.

7.3.  The Association "PolicyConformAction" "QoSPolicyExceedAction"

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

NAME			PolicyConformAction              QoSPolicyExceedAction
DESCRIPTION       A class representing the association between a policer
                  policing action and the action that should be applied on traffic
                  conforming
                  to traffic exceeding an associated traffic profile.
DERIVED FROM      Dependency (see [PCIM])
ABSTRACT          FALSE
PROPERTIES        Antecedent[ref QoSPolicyPoliceAction[0..n]] QoSPolicePoliceAction[0..n]]
                  Dependent[ref PolicyAction [0..1]] [1..1]]

Snir, Ramberg, Strassner, Cohen Cohen, Moore       expires November 2001         28

7.2.1. May 2002         43

7.3.1. The Reference "Antecedent"

This property is inherited from the Dependency association.  Its type is
overridden to become an 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 to be executed as the conforming exceeding
action.

7.2.2.

7.3.2. The Reference "Dependent"

This property is inherited from the 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 a given
conforming exactly one
policy action may only can be used as the "exceed" action by a single
QoSPolicyPoliceAction.

7.3. To execute more than one conforming action, use
the PolicyCompoundAction class to model the exceeding action.

7.4.  The Association "PolicyExcessAction" "PolicyViolateAction"

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

NAME			PolicyExcessAction              PolicyViolateAction
DESCRIPTION       A class representing the association between a
                  policer
                  policing action and the action that should be applied
                  on
                  to traffic exceeding violating an associated traffic profile.
DERIVED FROM      Dependency (see [PCIM])
ABSTRACT          FALSE
PROPERTIES        Antecedent[ref QoSPolicePoliceAction[0..n]]
                  Dependent[ref PolicyAction [0..1]]

7.3.1. [1..1]]

7.4.1. The Reference "Antecedent"

This property is inherited from the Dependency association.  Its type is
overridden to become an 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 to be executed as the exceeding violating
action.

7.3.2.

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         44

7.4.2. The Reference "Dependent"

This property is inherited from the 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 a given
exceeding exactly one
policy action may only can be used as the "violate" action by a single
QoSPolicyPoliceAction.

Snir, Ramberg, Strassner, Cohen          expires November 2001         29

7.4. To execute more than one violating action, use
the PolicyCompoundAction class to model the conforming action.

7.5 The Association "PolicyViolateAction"

This association links a policer action with an object defining an Aggregation "QoSPolicyRSVPVariableInRSVPSimplePolicyAction"

A simple RSVP policy action to be applied on traffic violating is represented as a pair {variable, value}.
This aggregation provides the associated traffic
profile. linkage between a
QoSPolicyRSVPSimpleAction instance and a single QoSPolicyRSVPVariable.
The aggregation PolicyValueInSimplePolicyAction links the
QoSPolicyRSVPSimpleAction to a single PolicyValue.

The class definition for this association aggregation is as follows:

     NAME			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.             QoSPolicyRSVPVariableInRSVPSimplePolicyAction
     DERIVED FROM     	Dependency     PolicyVariableInSimplePolicyAction
     ABSTRACT         	FALSE         False
     PROPERTIES  	Antecedent[ref QoSPolicePoliceAction[0..n]]
                  Dependent[ref PolicyAction [0..1]]

7.4.1.       GroupComponent[ref QoSPolicyRSVPSimpleAction
                        [0..n]]
                      PartComponent[ref QoSPolicyRSVPVariable [1..1] ]

7.5.1.  The Reference "Antecedent"

This "GroupComponent"

The reference property "GroupComponent" is inherited from the Dependency association.  Its type is
PolicyComponent, and overridden to become an object reference to a QoSPolicyPoliceAction
object. This represents the "independent" part
QoSPolicyRSVPSimpleAction that contains exactly one
QoSPolicyRSVPVariable.  Note that for any single instance of the association.
aggregation class QoSPolicyRSVPVariableInRSVPSimplePolicyAction, this
property is single-valued.  The [0..n] cardinality indicates that any number of QoSPolicyPoliceAction
objects there
may be 0, 1, or more QoSPolicyRSVPSimpleAction objects that contain any
given the same action to be executed as the violating
action.

7.4.2. RSVP variable object.

7.5.2.  The Reference "Dependent"

This "PartComponent"

The reference property "PartComponent" is inherited from the Dependency association,
PolicyComponent, and is overridden to become an object reference to a PolicyAction object. This
represents a specific policy action
QoSPolicyRSVPVariable that is used by defined within the scope of a given
QoSPolicyPoliceAction.
QoSPolicyRSVPSimpleAction.  Note that for any single instance of the
association class QoSPolicyRSVPVariableInRSVPSimplePolicyAction, this
property (like all reference properties) is single-valued.  The [1..1]
cardinality means indicates that a given
violating action may only
QoSPolicyRSVPVariableInRSVPSimplePolicyAction must have exactly one RSVP
variable defined within its scope in order to be used by a single QoSPolicyPoliceAction. meaningful.

Snir, Ramberg, Strassner, Cohen Cohen, Moore       expires November 2001         30 May 2002         45

8. Class Definitions: Inheritance Hierarchy

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

8.1. The Class QoSPolicyDiscardAction

This class is used to specify that packets should be discarded. This is
the same as stating that packets should be denied forwarding. The class
definition is as follows:

NAME           QoSPolicyDiscardAction
DESCRIPTION    This action specify specifies that packets should be discarded.
DERIVED FROM   PolicyAction (defined in [PCIM])
ABSTRACT       False
PROPERTIES     None

8.2. The Class QoSPolicyAdmissionAction

This class is the base class for performing admission decisions. It is
used to determine whether to accept or reject decisions based on
a given RSVP request. This
is done by comparing comparison of a meter measuring the RSVP request's TSPEC temporal behavior of a flow or RSPEC parameters against
the a
set of flow with a traffic profile (as specified in the QosPolicyIntServTrfcProf class). profile.  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           QoSPolicyAdmissionAction
DESCRIPTION    This action controls admission decisions based on
               comparison of a meter to a traffic profile.
DERIVED FROM   PolicyAction (defined in [PCIM])
ABSTRACT     True       False
PROPERTIES     qpAdmissionScope

8.2.1. The Property qpAdmissionScope

This attribute specifies whether the admission decision is done per flow
or per the entire class of flows defined by the rule condition. If the
scope is per flow, "flow", the actual or requested rate of each flow is compared
against the traffic profile. If the scope is set to class, "class", the
aggregate actual or requested rate of all flows matching the rule
condition is measured against the traffic profile. The property is
defined as follows:

NAME         qpAdmissionScope
DESCRIPTION  This property specifies whether the admission decision is
             done per flow or per the entire class of flows
SYNTAX       Integer
VALUE        This is an enumerated integer. A value of 0 specifies that
             admission is done on a per-flow basis, and a value of 1
             specifies that admission is done on a per-class basis.

Snir, Ramberg, Strassner, Cohen Cohen, Moore       expires November 2001         31 May 2002         46

8.3. The Class QoSPolicyPoliceAction

This is the base class used for defining policing actions (e.g., (i.e., those actions that
restrict traffic in some way). based on a comparison with a traffic profile). 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 a subclass of the QosPolicyTokenBucketTrfcProf
QoSPolicyTrfcProf class.  The class definition is as follows:

NAME         QoSPolicyPoliceAction
DESCRIPTION  This action controls the operation of policers. The measured rate of
             flows is measured against a traffic profile. The
             action the needs actions
             that need to be performed on conforming, exceeding and
             violating traffic is are indicated using the conform, exceed
             and violate action associations.
DERIVED FROM QoSPolicyAdmissionAction (defined in this document)
ABSTRACT     False
PROPERTIES   None

8.4. The Class  QoSPolicyShapeAction

This class is the base class used for defining shaping actions. Shapers are used to
delay some or all of the packets in a traffic stream in order to bring a
particular traffic stream into compliance with a given traffic profile.
The traffic profile is specified in a subclass of the
QosPolicyTokenBucketTrfcProf QoSPolicyTrfcProf
class.  The class definition is as follows:

NAME         QoSPolicyShapeAction
DESCRIPTION  This action indicate that traffic should be shaped to be
             conforming with a traffic profile.
DERIVED FROM QoSPolicyAdmissionAction (defined in this document)
ABSTRACT     False
PROPERTIES   None

Snir, Ramberg, Strassner, Cohen          expires November 2001         32

8.5. The Class QoSPolicyRSVPAdmissionAction

This class determines whether to accept or reject a given RSVP request
by comparing the RSVP request's TSPEC or RSPEC parameters against the
associated traffic profile. profile and/or by enforcing the pre-set maximum
sessions limit. The traffic profile is specified in the
QosPolicyIntServTrfcProf
QoSPolicyIntServTrfcProf class.  This class inherits the
qpAdmissionScope property from its superclass. This property specifies
whether admission should be done on a per-flow or per-class basis. If
the traffic profile is not larger than or equal to the requested
reservation, or to the sum of the admitted reservation merged with the
requested reservation, the result is a deny decision. If no traffic
profile is specified, the assumption is that all traffic can be
admitted.

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         47

The class definition is as follows:

NAME         QoSPolicyRSVPAdmissionAction
DESCRIPTION  This action controls the admission of RSVP request. requests.
             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 QoSPolicyAdmissionAction (defined in this document)
ABSTRACT     False
PROPERTIES   qpRSVPWarnOnly, qpRSVPMaxSessions

8.5.1. The Property qpRSVPWarnOnly

This property is applicable when fulfilling ("admitting") an RSVP
request would violate the policer (traffic profile) limits or when the
maximum number session would be exceeded (or both).

When this property is set to True, the RSVP request is admitted, admitted in spite
of the violation, but an RSVP error message carrying a warning is sent
to the originator (sender or receiver). When set to False, the request
would be denied and an error message would be sent back to the
originator. So the meaning of the qpWarnOnly flag is: Based on
property's value (True or False), determine whether to admit but warn
the originator that the request is in violation or to deny the request
altogether (and send back an error).

Specifically, a PathErr (in response to a Path message) or a ResvErr (in
response of a Resv message) will be sent. This follows the COPS for RSVP
send error flag in the Decision Flags object. This property is defined
as follows:

NAME      qpRSVPWarnOnly
SYNTAX    Boolean
Default   False
VALUE   This property can have one of two values.     The value 1 (TRUE) TRUE means that the request should be admitted AND
          an RSVP error warning message should be sent to the originator. The
          value of 0 (FALSE) FALSE means that the request should be not admitted without sending
          and an RSVP appropriate error message. message should be sent back to the
          originator of the request.

8.5.2. The Property qpRSVPMaxSessions

This attribute is used to limit the total number of RSVP requests
admitted within for the specified class of traffic. The qpAdmissionScope For this property must be set to class (it is not applicable if be
meaningful, the qpAdmissionScope property is must be set to "flow"). class. The
definition of this property is as follows:

NAME     qpRSVPMaxSessions
SYNTAX   Integer
VALUE    Must be greater than 0.

Snir, Ramberg, Strassner, Cohen Cohen, Moore       expires November 2001         33 May 2002         48

8.6. The Class QosPolicyPHBAction QoSPolicyPHBAction

This class is a base class that is used to define the per-hop behavior
that is to be assigned to behavior aggregates. It defines a common
property, qpPacketSize, qpMaxPacketSize, for use by its subclasses
(QoSPolicyBandwidthAction and QoSPolicyCongestionControlAction). The
class definition is as follows:

NAME         QosPolicyPHBAction           QoSPolicyPHBAction
DESCRIPTION    This action controls the Per-Hop-Behavor Per-Hop-Behavior provided to
               behavior aggregates.
DERIVED FROM   PolicyAction  (defined in [PCIM])
ABSTRACT       True
PROPERTIES   qpPacketSize     qpMaxPacketSize

8.6.1. The Property qpPacketSize qpMaxPacketSize

This property specifies the maximum packet size in bytes of this class bytes, of
packet. packets in
the designated flow. This attribute is used in translation of QPIM
attributes to QoS mechanisms used within a PEP.  For example, queue
length may be measured in bytes bytes, while the minimum number of packets
that should be kept in a PEP is defined within QPIM in number of
packets. This property is defined as follows:

NAME   qpPacketSize       qpMaxPacketSize
SYNTAX     Integer
Value      Must be greater than 0

8.7. The Class QoSPolicyBandwidthAction

This class is used to control the bandwidth, delay, and forwarding
behavior of a PHB. Its class definition is as follows:

NAME           QoSPolicyBandwidthAction
DESCRIPTION    This action controls the bandwidth, delay, and
               forwarding characteristics of the PHB.
DERIVED FROM   QoSPolicyPBHAction (defined in this document)
ABSTRACT       False
PROPERTIES     qpForwardingPriority, qpBandwidthUnits, qpMinBandwdith,
               qpMaxBandwidth, qpMaxDelay, qpMaxJitter, qpFairness

Snir, Ramberg, Strassner, Cohen Cohen, Moore       expires November 2001         34 May 2002         49

8.7.1. The Property qpForwardingPriority

This property defines the forwarding priority for this set of flows. A
non-zero value indicates that pre-emptive forwarding is required. Higher
values represent higher forwarding priority. This property is defined as
follows:

NAME        qpForwardingPriority
SYNTAX      Integer
VALUE       Must be non-negative. The value 0 means that pre-emptive
            forwarding is not required. A positive value indicates the
priority that is to be assigned for this (set of) flow(s).
Larger values represent higher priorities.

8.7.2  The Property qpBandwidthUnits

This property defines in what the units that the properties qpMinBandwidth and
qpMaxBandwidth are defined. have. Bandwidth can either be defined in bits/sec or in as a
percentage of the available bandwidth or scheduler resources. This
property is defined as follows. follows:

NAME        qpBandwidthUnits
SYNTAX      Integer
VALUE       Two values are possible. The value of 0 is used to specify
            units of bits/sec, while the value of 1 is used to specify
            units as a percentage of the available bandwidth.  If this
            property indicates that the bandwidth units are percentages,
            then each of the bandwidth properties expresses a whole-
            number percentage, and hence its maximum value is 100.

8.7.3. The Property qpMinBandwidth

This property defines the minimum 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 of the qpBandwidthUnits property. This property
is defined as follows. follows:

NAME        qpMinBandwidth
SYNTAX      Integer
VALUE       The value must be greater than 0. If the property
            qpMaxBandwidth is defined, then the value of qpMinBandwidth
            must be less than or equal to the value of qpMaxBandwidth.

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         50

8.7.4. The Property qpMaxBandwidth

This property defines the maximum bandwidth that should be allocated to
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 of the qpBandwidthUnits property. This property
is defined as follows. follows:

NAME        qpMaxBandwidth
SYNTAX      Integer
VALUE       The value must be greater than 0

Snir, Ramberg, Strassner, Cohen          expires November 2001         35 0. If the property
            qpMaxBandwidth is defined, then the value of qpMinBandwidth
            must be less than or equal to the value of qpMaxBandwidth.

8.7.5.  The Property qpMaxDelay

This property defines the maximal per-hop delay that traffic of this
class should experience while being forwarded through this hop. The
maximum delay is measured in milliseconds. microseconds. This property is defined as follows.
follows:

NAME        qpMaxDelay
SYNTAX      Integer (milliseconds) (microseconds)
VALUE       The value must be greater than 0 0.

8.7.6.  The Property qpMaxJitter

This property defines the maximal per-hop delay variance that traffic of
this class should experience while being forwarded through this hop.
The hop.The
maximum jitter is measured in milliseconds. microseconds. This property is defined as follows.
follows:

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

8.7.7.  The Property qpFairness

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

NAME        qpFairness
SYNTAX	Integer      Boolean
VALUE       The value of 0 (FALSE) FALSE means that fair queuing is not required
            for this class of traffic, while the value of 1
            (TRUE) TRUE means
            that fair queuing is required for this class of traffic.

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         51

8.8. The Class QoSPolicyCongestionControlAction

This class is used to control the characteristics of the congestion
control algorithm being used. The class definition is as follows:

NAME         QoSPolicyCongestionControlAction
DESCRIPTION  This action control congestion control characteristics of
             the PHB.
DERIVED FROM QoSPolicyPBHAction (defined in this document)
ABSTRACT     False
PROPERTIES   qpQueueSizeUnits, qpQueueSize, qpDropAlgorithm, qpDropMethod,
             qpDropThresholdUnits, qpDropMinThresholdValue,
             qpDropMaxThresholdValue

Snir, Ramberg, Strassner, Cohen          expires November 2001         36

8.8.1. The property qpQueueSizeUnits

This property specifies the units in which the qpQueueSize attribute is
measured. The queue size is measured either in number of packets or in
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 to
transmission of packets within this queue. The property definition is:

NAME        qpQueueSizeUnits
SYNTAX	IntegerVALUE      Integer
VALUE       This property can have two values. If the value is set to 0,
            then the unit of measurement is number of packets. If the
            value is set to 1, then the unit of measurement is
            milliseconds.

8.8.2. The Property qpQueueSize

This property specifies the maximum 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        qpQueueSize
SYNTAX      Integer
VALUE       This value must be greater than 0 0.

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         52

8.8.3.  The Property qpDropAlgorithm qpDropMethod

This property specifies the congestion control drop algorithm that
should be used for this type of traffic. This property is defined as
follows.
follows:

NAME		qpDropAlgorithm        qpDropMethod
SYNTAX      Integer
VALUES      Three values are currently defined. The value 0 specifies a
            random drop algorithm, the value 1 specifies a tail drop
            algorithm, and the value 2 specifies a head drop algorithm.

8.8.4.  The Property qpDropThresholdUnits

This property specifies the units in which the two properties
qpDropMinThresholdValue and qpDropMaxThresholdValue are measured.
Thresholds can be measured either in packets or in as a percentage of the
available queue sizes. This property is defined as follows. follows:

NAME        qpDropThresholdUnits
SYNTAX      Integer
VALUES      Two      Three values are defined. The value 0 defines the units as
            number of packets, and the value 1 defines the units as a
            percentage of the queue size.

Snir, Ramberg, Strassner, Cohen          expires November 2001         37 size and the value 2 defines the
            units in milliseconds. If this property indicates that the
            threshold units are percentages, then each of the threshold
            properties expresses a whole-number percentage, and hence
            its maximum value is 100.

8.8.5.  The Property qpDropMinThresholdValue

This property specifies the minimum number of queuing and buffer
resources that should be reserved for this class of flows. The threshold
can be specified as either relative (i.e., a percentage) or absolute
(i.e., number of packets) packets or millisecond) value according to the value of
the qpDropThresholdUnits property. If this property specifies a value of
5 packets, then enough buffer and queuing resources should be reserved
to hold 5 packets before running the specified congestion control drop
algorithm. This property is defined as follows:

NAME        qpDropMinThresholdValue
SYNTAX      Integer
VALUE       This value must be greater than 0 or equal to 0. If the
            property qpDropMaxThresholdValue is defined, then the value
            of the qpDropMinThresholdValue property must be less than or
            equal to the value of the qpDropMaxThresholdValue property

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         53

8.8.6.  The Property qpDropMaxThresholdValue

This property specifies the maximum number of queuing and buffer
resources that should be reserved for this class of flows. The threshold
can be specified as either relative (i.e., a percentage) or absolute
(i.e., number of packets) packets or milliseconds) value according to the value
of the qpDropThresholdUnits property. Congestion Control droppers should
not keep more packets than the value specified in 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 as follows:

NAME        qpDropMaxThresholdValue
SYNTAX      Integer
VALUE       This value must be greater greater than or equal to 0. If the
            property qpDropMinThresholdValue is defined, then the value
            of the qpDropMinThresholdValue property must be less than 0 or
            equal to the value of the qpDropMaxThresholdValue property

8.9. Class QoSPolicyTrfcProf

This is an abstract base class that models a traffic profile. Traffic
profiles specify the maximum rate parameters used within admission
decisions. The association QosPolicyTrfcProfInAdmissionAction QoSPolicyTrfcProfInAdmissionAction binds the
admission decision to the traffic profile. The class definition is as
follows:

NAME          QoSPolicyTrfcProf
DERIVED FROM  Policy (defined in [PCIM])
ABSTRACT      True
PROPERTIES    None

Snir, Ramberg, Strassner, Cohen          expires November 2001         38

8.10. Class QosPolicyTokenBucketTrfcProf QoSPolicyTokenBucketTrfcProf

This class models a two- or three-level Token Bucket traffic profile.
Additional profiles can be modeled by cascading multiple instances of
this class (e.g., by connecting the output of one instance to the input
of another instance). This traffic profile carries the policer or shaper
rate values to be enforced on a flow or a set of flows. The class
definition is as follows:

NAME	        QosPolicyTokenBucketTrfcProf          QoSPolicyTokenBucketTrfcProf
DERIVED FROM  QoSPolicyTrfcProf (defined in this document)
ABSTRACT      False
PROPERTIES    qpTBRate, qpTBNormalBurst, qpTBExcessBurst

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         54

8.10.1. The Property qpTBRate

This is a 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 must be greater than to 0

8.10.2. The Property qpTBNormalBurst

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

NAME        qpTBNormalBurst
SYNTAX      Integer
VALUE       This value must be greater than to 0

8.10.3. The Property qpTBExcessBurst

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

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

Snir, Ramberg, Strassner, Cohen          expires November 2001         39 or equal to qpTBNormalBurst

8.11. Class qosPolicyIntServTrfcProf QoSPolicyIntServTrfcProf

This class represents an IntServ traffic profile. Values of 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		  qosPolicyIntServTrfcProf          QoSPolicyIntServTrfcProf
DERIVED FROM  QosPolicyTrfcProf  QoSPolicyTrfcProf (defined in this document)
ABSTRACT      False
PROPERTIES    qpISTokenRate, qpISPeakRate, qpISBucketSize, qpISResvRate,
              qpISResvSlack, qpISMinPolicedUnit, qpISMaxPktSize

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         55

8.11.1. The Property qpISTokenRate

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

NAME        qpISTokenRate
SYNTAX      Integer
VALUE       This value must be greater than or equal to 0

8.11.2. The Property qpISPeakRate

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

NAME        qpISPeakRate
SYNTAX      Integer
VALUE       This value must be greater than or equal to 0

8.11.3. The Property qpISBucketSize

This property is a non-negative integer that defines the token bucket
size parameter, measured in bytes. This property is defined as follows:

NAME        qpISBucketSize
SYNTAX      Integer
VALUE       This value must be greater than or equal to 0

Snir, Ramberg, Strassner, Cohen          expires November 2001         40

8.11.4. The Property qpISResvRate

This property is a non-negative integer that defines the reservation
rate (R-Spec) in the RSVP guaranteed service reservation. It is measured
in kilobits per second. This property is defined as follows:

NAME        qpISResvRate
SYNTAX      Integer
VALUE       This value must be greater than or equal to 0

8.11.5. The Property qpISResvSlack

This property is a non-negative integer that defines the RSVP slack term
in the RSVP guaranteed service reservation. It is measured in
microseconds. This property is defined as follows:

NAME        qpISResvSlack
SYNTAX      Integer
VALUE       This value must be greater than or equal to 0

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         56

8.11.6. The Property qpISMinPolicedUnit

This property is a non-negative integer that defines the minimum RSVP
policed unit, measured in bytes. This property is defined as follows:

NAME        qpISMinPolicedUnit
SYNTAX      Integer
VALUE       This value must be greater than or equal to 0

8.11.7. The Property qpISMaxPktSize

This property is a non-negative positive integer that defines the maximum allowed
packet size for RSVP messages, measure measured 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 November 2001         41

8.12. The Class QosPolicyAttributeValue

This class is used to represent a single or set positive integer, denoting the number
            of property values bytes in the largest payload packet of an object. RSVP signaled
            flow or class.

8.12. The Class QoSPolicyAttributeValue

This value class can be used for representing an indirection in conjunction with reference values
carried variable and
value references either in RSVP objects, a simple condition ("<x> match <y>") or a
simple action ("<x> = <y>"). In both cases, <x> and <y> are known as specified in [RFC2751]. the
variable and the value of either the condition or action. The property name is
used to specify which value of
the properties qpAttributeName and qpAttributeValueList are used to
substitute <x> and <y> in the object condition or action respectively.

The substitution is being used done as follows: The value of the property
qpAttributeName is used to substitute <x> and the condition. The value of this the property will then
qpAttributeValueList is used to substitute <y>.

Once the substitution is done, the condition can be retrieved, evaluated and a
match (which is dependent on the property name) will
action can be used performed.

For example, suppose we want to see if
the define a condition over a user name of
the form "user == 'Smith'", using the QoSPolicyRSVPUserVariable class.
The user information in the RSVP message provides a DN. The DN points to
a user objects holding many attributes. If the relevant attribute is satisfied or not.
"last name", we would use the QoSPolicyAttributeValue class with
qpAttributeName = "Last Name", qpAttributeValueList = {"Smith"}.

The class definition is as follows:

NAME         QosPolicyAttributeValue           QoSPolicyAttributeValue
DERIVED FROM PolicyImplicitValue   PolicyValue (defined in [PCIMe])
ABSTRACT       False
PROPERTIES     qpAttributeName, qpAttributeValueList

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         57

8.12.1. The Property qpAttributeName

This property defines carries the name of the attribute that the list of values
should is to be compared against. used to
substitute <x> in a simple condition or simple condition of the forms
"<x> match <y>" or "<x> = <y>" respectively. This property is defined as
follows:

NAME       qpAttributeName
SYNTAX     String

8.12.2. The Property qpAttributeValueList

This property contains carries a list of attribute values. Each value values that is compared to be used to substitute
<y> in a value simple condition or simple action of the property specified by the qpAttributeName property. forms "<x> match <y>"
or "<x> = <y>" respectively.

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 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 (defined in [PCIMe])
ABSTRACT       TRUE
PROPERTIES     None

Snir, Ramberg, Strassner, Cohen          expires November 2001         42

8.14. The Class "QoSPolicyRSVPSourceIPv4Variable"

This is a concrete class that contains the source IPv4 address of the
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           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   QoSPolicyRSVPVariable (defined in this document)
ABSTRACT       FALSE
PROPERTIES     None

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         58

8.15. The Class "QoSPolicyRSVPDestinationIPv4Variable"

This is a concrete class that contains the destination IPv4 address of
the 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           QoSPolicyRSVPDestinationIPv4Variable
DESCRIPTION    The destination IPv4 address of the RSVP signaled
               flow, as defined in the RSVP PATH and RESV SESSION
               [RSVP] objects.

               ALLOWED VALUE TYPES: PolicyIPv4AddrValue

DERIVED FROM   QoSPolicyRSVPVariable (defined in this document)
ABSTRACT       FALSE
PROPERTIES     None

8.16. The Class "QoSPolicyRSVPSourceIPv6Variable"

This is a concrete class that contains the source IPv6 address of the
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           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 (defined in this document)
ABSTRACT       FALSE
PROPERTIES     None

Snir, Ramberg, Strassner, Cohen          expires November 2001         43

8.17. The Class "QoSPolicyRSVPDestinationIPv6Variable"

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

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         59

NAME           QoSPolicyRSVPDestinationIPv6Variable
DESCRIPTION    The destination IPv6 address of the RSVP signaled
               flow, as defined in the RSVP PATH and RESV SESSION
               [RSVP] objects.

               ALLOWED VALUE TYPES: PolicyIPv6AddrValue

DERIVED FROM   QoSPolicyRSVPVariable (defined in this document)
ABSTRACT       FALSE
PROPERTIES     None

8.18. The Class "QoSPolicyRSVPSourcePortVariable"

This is a concrete class that contains the source port of the 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           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 PolicyIntegerValue (0..65535)

DERIVED FROM   QoSPolicyRSVPVariable (defined in this document)
ABSTRACT       FALSE
PROPERTIES     None

8.19. The Class "QoSPolicyRSVPDestinationPortVariable"

This is a concrete class that contains the destination port of the 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           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 PolicyIntegerValue (0..65535)

DERIVED FROM   QoSPolicyRSVPVariable (defined in this document)
ABSTRACT       FALSE
PROPERTIES     None

Snir, Ramberg, Strassner, Cohen Cohen, Moore       expires November 2001         44 May 2002         60

8.20. The Class "QoSPolicyRSVPIPProtocolVariable"

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

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

DERIVED FROM   QoSPolicyRSVPVariable (defined in this document)
ABSTRACT       FALSE
PROPERTIES     None

8.21. The Class "QoSPolicyRSVPIPVersionVariable"

This is a 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 well-known version numbers are 4 and 6. This
variable allows a policy definition of the type:

    "If IP version = IPv4 then ...".

The class definition is as follows:

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

DERIVED FROM   QoSPolicyRSVPVariable (defined in this document)
ABSTRACT       FALSE
PROPERTIES     None

8.22. The Class "QoSPolicyRSVPDCLASSVariable"

This is a concrete class that contains the DSCP value as defined in the
RSVP DCLASS [DCLASS] object. The class definition is as follows:

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         61

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

               ALLOWED VALUE TYPES: Integer, BitString PolicyIntegerValue,
                                    PolicyBitStringValue

DERIVED FROM   QoSPolicyRSVPVariable
ABSTRACT     FALSE
PROPERTIES   None

Snir, Ramberg, Strassner, Cohen          expires November 2001         45 (defined in this document)
ABSTRACT       FALSE
PROPERTIES     None

8.23. The Class "QoSPolicyRSVPStyleVariable"

This is a 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 RSVP STYLE object
               in the RESV message [RSVP].

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

DERIVED FROM   QoSPolicyRSVPVariable (defined in this document)
ABSTRACT       FALSE
PROPERTIES     None

8.24. The Class "QoSPolicyIntServVariable"

This is a concrete class that contains the Integrated Service requested
in the RSVP Reservation message, as defined in the FLOWSPEC RSVP Object
[RSVP]. The class definition is as follows:

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

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

DERIVED FROM   QoSPolicyRSVPVariable (defined in this document)
ABSTRACT       FALSE
PROPERTIES     None

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         62

8.25. The Class "QoSPolicyRSVPMessageTypeVariable"

This is a concrete class that contains the RSVP message type, as defined
in the RSVP message common header [RSVP] object. The class definition is
as follows:

Snir, Ramberg, Strassner, Cohen          expires November 2001         46

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

              ALLOWED VALUE TYPES: Integer (An enumerated value of
                                    { PATH=1
                                    {PATH=1 , PATHTEAR=2, RESV=3,
                                     RESVTEAR=4, ResvErr=5, CONF=6} CONF=6,
                                     PATHERR}

DERIVED FROM  QoSPolicyRSVPVariable (defined in this document)
ABSTRACT      FALSE
PROPERTIES    None

8.26. The Class "QoSPolicyRSVPPreemptionPriorityVariable"

This is a concrete class that contains the RSVP reservation priority, as
defined in [RSVP_PREEMP] object. The class definition is as follows:

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

              ALLOWED VALUE TYPES: Integer PolicyIntegerValue

DERIVED FROM  QoSPolicyRSVPVariable (defined in this document)
ABSTRACT      FALSE
PROPERTIES    None

8.27. The Class "QoSPolicyRSVPPreemptionDefPriorityVariable"

This is a concrete class that contains the RSVP reservation defending
priority, as defined in [RSVP_PREEMP] object. The class definition is as
follows:

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

              ALLOWED VALUE TYPES: Integer PolicyIntegerValue

DERIVED FROM  QoSPolicyRSVPVariable (defined in this document)
ABSTRACT      FALSE
PROPERTIES    None

Snir, Ramberg, Strassner, Cohen Cohen, Moore       expires November 2001         47 May 2002         63

8.28. The Class "QoSPolicyRSVPUserVariable"

This is a concrete class that contains the ID of the user that initiated
the flow as defined in the User Locator string in the Identity Policy
Object [RFC2752]. The class definition is as follows:

NAME          QoSPolicyRSVPUserVariable
DESCRIPTION   The ID of the user that initiated the flow as defined in
              the User Locator string in the Identity Policy Object
              [RFC2752].

              ALLOWED VALUE TYPES: QoSPolicyDNValue, PolicyStringValue,
                                  QosPolicyAttributeValue
                                   QoSPolicyAttributeValue

DERIVED FROM  QoSPolicyRSVPVariable (defined in this document)
ABSTRACT      FALSE
PROPERTIES    None

8.29. The Class "QoSPolicyRSVPApplicationVariable"

This is a concrete class that contains the ID of the application that
generated the flow as defined in the application locator string in the
Application policy object [RFC2872]. The class definition is as follows:

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

DERIVED FROM  QoSPolicyRSVPVariable (defined in this document)
ABSTRACT      FALSE
PROPERTIES    None

Snir, Ramberg, Strassner, Cohen Cohen, Moore       expires November 2001         48 May 2002         64

8.30. The Class "QoSPolicyRSVPAuthMethodVariable"

This is a concrete class that contains the type of authentication used
in the Identity Policy Object [RFC2752]. The class definition is as
follows:

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

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

DERIVED FROM  QoSPolicyRSVPVariable (defined in this document)
ABSTRACT      FALSE
PROPERTIES    None

8.31. The Class QoSPolicyDNValue

This class is used to represent a single or set of Distinguished Name
[DNDEF] values, including wildcards. A Distinguished Name is a name that
can be used as a key to retrieve an object from a directory service.
This value can be used in comparison to reference values carried in RSVP
policy objects, as specified in [RFC2752]. The class definition is as
follows:

NAME           QoSPolicyDNValue
DERIVED FROM  PolicyImplicitValue   PolicyValue
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 a DN is defined
in [DNDEF]. The asterisk character ("*") is used as wildcard for either
a single attribute value or a wildcard for an RDN. The order of RDNs is
significant. For example: A qpDNList attribute carrying the following
value: "OU=Sales, CN=*,

  "CN=*, OU=Sales, O=Widget Inc., *, C=US" matches: "OU=Sales, CN=J.

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

and also matches:
"OU=Sales, CN=J.

  "CN=J. Smith, OU=Sales, O=Widget Inc, C=US, CN=CA". L=CA, C=US".

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         65

The attribute is defined as follows:

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

Snir, Ramberg, Strassner, Cohen         expires May 2001             49

8.32. The Class QoSPolicyRSVPSimpleAction

This action controls the content of RSVP messages and the way RSVP
requests are admitted. Depending on the value of its qpRSVPActionType
property, this action directly translates into either a COPS Replace
Decision or a COPS Stateless Decision, or both as defined in COPS for
RSVP. Only variables that are subclasses of the QoSPolicyRSVPVariable
are allowed to be associated with this action. The property definition
is as follows:

NAME          QoSPolicyRSVPSimpleAction
DESCRIPTION   This action controls the content of RSVP messages and the
              way RSVP requests are admitted.
DERIVED FROM  SimplePolicyAction (defined in [PCIMe])
ABSTRACT      False
PROPERTIES    qpRSVPActionType

Restricts the PolicyVariableInSimplePolicyAction aggregation to
QoSPolicyRSVPVariable.

8.32.1. The Property qpRSVPActionType

This is a multi-valued property that may contain one or two values value to denote the
type of RSVP action. The value 'REPLACE' denotes a COPS Replace Decision
action. The value 'STATELESS' denotes a COPS Stateless Decision action.
The value REPLACEANDSTATELESS denotes both decision actions. Refer to
[COPS] for details. This property is multi-value, which means that both
action types are to be executed. single-valued enumerated attribute.

NAME         QpRSVPActionType          qpRSVPActionType
DESCRIPTION   This property specifies whether the action type is for
              COPS
             Replace Replace, Stateless, or Stateless decision or both. both types of decisions.
SYNTAX        Integer
VALUE         This is an enumerated integer. A value of 0 specifies a
              COPS Replace decision. A value of 1 specifies a COPS
              Stateless Decision. A value of 2 specifies both COPS
              Replace and COPS Stateless decisions.

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         66

9. Acknowledgements

The authors wish to thank the input of the participants of the Policy
Framework working group, and especially Bob Moore the combined group of the PCIMe
coauthors, Lee Rafalow, Andrea Westerinen, Ritu Chadha and Marcus
Brunner. In addition we'd like to acknowledge the valuable contribution
from Ed Ellesson, Joel Halpern and Alex Wang Mircea Pana. Thank you all for
their helpful contributions. your
comments, critique, ideas and general contribution.

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] Strassner, J., and E. Ellesson, B. Moore, A. Westerinen,
       "Policy Core Information Model -- Version 1 Specification",
       RFC 3060, February 2001.

[PCIMe] B. Moore, L. Rafalow, Y. Ramberg, Y. Snir, J. Strassner,
        A. Westerinen, R. Chadha, M. Brunner, R. Cohen,
        "Policy Core Information Model Extensions",
        <draft-ietf-policy-pcim-ext-01.txt>
        <draft-ietf-policy-pcim-ext-06.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>
        <draft-ietf-policy-terminology-04.txt>

[DIFFSERV] S. Blake, et. Al., "An Architecture for Differentiated
           Services", 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. Strassner, R. Cohen, "Policy QoS
             LDAP Schema", <draft-ietf-policy-qos-schema-02.txt>

[RFC2749]  S . Herzog, Ed., J. Boyle, R. Cohen, D. Durham, R. Rajan,
           A. Sastry, "COPS usage for RSVP", RFC2749

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

Snir, Ramberg, Strassner, Cohen, Moore       expires May 2002         67

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

Snir, Ramberg, Strassner, Cohen          expires November 2001         51
            <draft-ietf-diffserv-mib-16.txt>

[AF]  J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured
      Forwarding PHB Group", RFC2597

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

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

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

[DCLASS]  Y. Bernet, "Format of the RSVP DCLASS Object", RFC2996

[RFC2752]  S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore,
           S. Herzog, "Identity Representation for RSVP", RFC2752

[RFC2872]  Y. Bernet, R. Pabbati, "Application and Sub Application
           Identity Policy Element for Use with RSVP", RFC2872

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

12. Authors' Addresses

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

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

   John Strassner
       Cisco Systems
       725 Alder Drive, , Building 20
       Milpitas, CA  95035
       Intelliden Corporation
       90 South Cascade Avenue
       Colorado Springs, Colorado  80903
       Phone:  +1-408-527-1069  +1-719-785-0648
       Fax:    +1-408-527-2477    +1-719-785-0644
       E-mail:  johns@cisco.com john.strassner@intelliden.com

Snir, Ramberg, Strassner, Cohen Cohen, Moore       expires November 2001         52 May 2002         68
   Ron Cohen
       Ntear LLC
       Phone: +972-8-9402586
       Fax:   +972-9-9717798
       E-mail: ronc@ntear.com

   Bob Moore
       IBM Corporation
       P. O. Box 12195, BRQA/502/G106
       3039 Cornwallis Rd.
       Research Triangle Park, NC 27709-2195
       Phone:   +1 919-254-4436
       Fax:     +1 919-254-6243
       E-mail: remoore@us.ibm.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 must be followed, or as required to translate it into
languages other than English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.

Snir, Ramberg, Strassner, Cohen Cohen, Moore       expires November 2001         53 May 2002         69