[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 rfc3644                                     
Policy Framework Working Group                                   Y. Snir
INTERNET-DRAFT                                                Y. Ramberg
Category: Standards Track                                   J. Strassner
                                                           Cisco Systems
                                                                R. Cohen
                                                               Ntear LLC
                                                              April 2001

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

Status of this Memo

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

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

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

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

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

Copyright Notice

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

Abstract

This document presents an object-oriented information model for
representing network QoS policies. This document is based on the IETF
Policy Core Information Model and its extensions as specified by [PCIM]
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          expires November 2001          1


draft-ietf-policy-qos-info-model-03.txt                        April 2001

Table of Contents

1.  Introduction                                                        5
1.1.  Goals                                                             5
1.1.1.  Modeling Abstract QoS Policies                                  5
1.1.2.  Enhancing Interoperability                                      6
1.1.3.  Intended Audiences                                              7
1.2.  QPIM Characteristics                                              8
1.3.  QPIM and Other Published Standards                               10

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

3.  QoS Actions                                                        14
3.1.  Overview                                                         14
3.2.  RSVP Policy Actions                                              15
3.3.  Provisioning Policy Actions                                      16
3.3.1.  Admission Actions: Controlling Policers and Shapers            17
3.3.2.  Controlling Markers                                            18
3.3.3.  Controlling Edge Policies ‚Çô Examples                           18
3.4.  Per-Hop Behavior Actions                                         20
3.4.1.  Controlling Bandwidth and Delay                                21
3.4.2.  Congestion Control Actions                                     21
3.4.3.  Using Hierarchical Policies ‚Çô Examples for PHB Actions         22

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

5.  Pre-Defined QoS-Related Variables                                  25

6.  QoS Related Values                                                 27

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







Snir, Ramberg, Strassner, Cohen          expires November 2001          2


draft-ietf-policy-qos-info-model-03.txt                       April 2001

Table of Contents (continued)

8.  Class Definitions: Inheritance Hierarchy                           31
8.1.  The Class QoSPolicyDiscardAction                                 31
8.2.  The Class QoSPolicyAdmissionAction                               31
8.2.1.  The Property qpAdmissionScope                                  31
8.3.  The Class QoSPolicyPoliceAction                                  32
8.4.  The Class QoSPolicyShapeAction                                   32
8.5.  The Class QoSPolicyRSVPAdmissionAction                           33
8.5.1.  The Property qpRSVPWarnOnly                                    33
8.5.2.  The Property qpRSVPMaxSessions                                 33
8.6.  The Class QoSPolicyPHBAction                                     34
8.6.1.  The Property qpPacketSize                                      34
8.7.  The Class QoSPolicyBandwidthAction                               34
8.7.1.  The Property qpForwardingPriority                              35
8.7.2.  The Property qpBandwidthUnits                                  35
8.7.3.  The Property qpMinBandwidth                                    35
8.7.4.  The Property qpMaxBandwidth                                    35
8.7.5.  The Property qpMaxDelay                                        36
8.7.6.  The Property qpMaxJitter                                       36
8.7.7.  The Property qpFairness                                        36
8.8.  The Class QoSPolicyCongestionControlAction                       36
8.8.1.  The Property qpSizeUnits                                       37
8.8.2.  The Property qpQueueSize                                       37
8.8.3.  The Property qpDropAlgorithm                                   37
8.8.4.  The Property qpDropThresholdUnits                              37
8.8.5.  The Property qpDropMinThresholdValue                           38
8.8.6.  The Property qpDropMaxThresholdValue                           38
8.9.  The Class QoSPolicyTrfcProf                                      38
8.10.  The Class QoSPolicyTokenBucketTrfcProf                          39
8.10.1.  The Property qpTBRate                                         39
8.10.2.  The Property qpTBNormalBurst                                  39
8.10.3.  The Property qpTBExcessBurst                                  39
8.11.  The Class QoSPolicyIntServTrfcProf                              40
8.11.1.  The Property qpISTokenRate                                    40
8.11.2.  The Property qpISPeakRate                                     40
8.11.3.  The Property qpISBucketSize                                   40
8.11.4.  The Property qpISResvRate                                     41
8.11.5.  The Property qpISResvSlack                                    41
8.11.6.  The Property qpISMinPolicedUnit                               41
8.11.7.  The Property qpISMaxPktSize                                   41
8.12.  The Class QoSPolicyAttributeValue                               42
8.12.1.  The Property qpAttributeName                                  42
8.12.2.  The Property qpAttributeValueList                             42
8.13.  The Class QoSPolicyRSVPVariable                                 42
8.14.  The Class QoSPolicyRSVPSourceIPv4Variable                       43
8.15.  The Class QoSPolicyRSVPDestinationIPv4Variable                  43
8.16.  The Class QoSPolicyRSVPSourceIPv6Variable                       43
8.17.  The Class QoSPolicyRSVPDestinationIPv6Variable                  44
8.18.  The Class QoSPolicyRSVPSourcePortVariable                       44
8.19.  The Class QoSPolicyRSVPDestinationPortVariable                  44



Snir, Ramberg, Strassner, Cohen          expires November 2001          3


draft-ietf-policy-qos-info-model-03.txt                       April 2001

Table of Contents (continued)

8.20.  The Class QoSPolicyRSVPIPProtocolVariable                       45
8.21.  The Class QoSPolicyRSVPIPVersionVariable                        45
8.22.  The Class QoSPolicyRSVPDCLASSVariable                           45
8.23.  The Class QoSPolicyRSVPStyleVariable                            46
8.24.  The Class QoSPolicyRSVPIntServVariable                          46
8.25.  The Class QoSPolicyRSVPMessageTypeVariable                      46
8.26.  The Class QoSPolicyRSVPPreemptionPriorityVariable               47
8.27.  The Class QoSPolicyRSVPPreemptionDefPriorityVariable            47
8.28.  The Class QoSPolicyRSVPUserVariable                             48
8.29.  The Class QoSPolicyRSVPApplicationVariable                      48
8.30.  The Class QoSPolicyRSVPAuthMethodVariable                       49
8.31.  The Class QosPolicyDNValue                                      49
8.31.1.  The Property qpDNList                                         49
8.32.  The Class QoSPolicyRSVPSimpleAction                             50
8.32.1.  The Property qpRSVPActionType                                 50


9.  Acknowledgements                                                   50

10.  Security Considerations                                           50

11.  References                                                        51

12.  Authors' Addresses                                                52

13.  Full Copyright Statement                                          53


























Snir, Ramberg, Strassner, Cohen          expires November 2001          4


draft-ietf-policy-qos-info-model-03.txt                       April 2001

1.  Introduction

This document presents an object-oriented information model for
representing network QoS policies. This document is based on the IETF
Policy Core Information Model and its extensions as specified by [PCIM]
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.

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

1.1  Goals

This section explains the goals for creating QPIM.

1.1.1.  Modeling Abstract QoS Policies

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. QPIM facilitates a formal representation of network QoS business
rules, thus providing the first concretization level: formally
representing humanly expressed QoS policy.

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: "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, the network itself cannot enforce it. Translation
to "network terms and language" is required.

On the other end 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 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 business policy.


Snir, Ramberg, Strassner, Cohen          expires November 2001          5


draft-ietf-policy-qos-info-model-03.txt                       April 2001

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 is vastly
different.

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

1.      Informal business QoS policy is expressed by a human policy maker
(e.g. "All executives' WEB requests should be prioritized")
2.      A network administrator models the informal policy by using QPIM
constructs, thus creating a 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 to the packet header").
Note that the administrator is very likely to use a particular data
model (e.g., LDAP schema) that is mapped to QPIM.
3.      The network administrator maps the abstract, formal policy to PEPs
(most likely by using roles, as specified in  [PCIMe, sections 2.2.4
and 4.6]).
4.      A configuration/distribution agent (or a PDP ‚Çô see [TERMS] for its
definition) consults a device capability model to determine how to
translate the policy into device configuration. An example for a
standards-based capability model is [QDDIM]. Note that one or more
such translations are possible, depending on the particular
capabilities of a given PEP and the implementation of the system.
5.      For each PEP in the network, the configuration/distribution agent
configures the appropriate instructions to enforce the policy.

QPIM is intended to be the bridging mechanism between step #1 and step #2
in the methodology just described.

1.1.2.  Enhancing Interoperability

Another goal of QPIM is to facilitate interoperability among policy
systems, PDPs in particular. QPIM accomplishes its interoperability goal
by standardizing a representation of policy. Producers and consumers of
QoS policy need only rely on QPIM-based schemata (or 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 an LDAP schema that maps from QPIM
to a directory implementation.A separately built PDP from vendor B may
then read this policy and "understand" it as both the management
application and the PDP were architected to comply with the QPIM
standard.





Snir, Ramberg, Strassner, Cohen          expires November 2001          6


draft-ietf-policy-qos-info-model-03.txt                       April 2001

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 the
capabilities of the PEPs that are being controlled by the PDP. Finally,
the same policy may be interpreted slightly differently depending on
various factors. For example, a QPIM policy rule that reads "If packet's
protocol is HTTP then assign 7 to IPP", may result in different
configurations depending on how that rule is implemented. For example, an
application recognition mechanism can be used to enforce the policy. If
the device does not supports this particular mechanism, then an alternate
mechanism must be used. For example, the packets could be classified
based on their destination TCP port.

Therefore, we define interoperability of QoS policies as the ability to
specify a policy rule in a standard format. The advantage is that such a
policy can be understood by PDPs and PEPs manufactured from different
vendors having different capabilities and functionality, as well as
policy-based applications. We specifically do not require a policy to be
translated into exactly the same configuration in different PEPs. This is
why we view the above two systems that differ in the interpretation of
recognizing WEB traffic as interoperable with regard to policy. The
advantage of using QPIM policies is that incompatible device capabilities
may still be employed and controlled using the QPIM policy.

1.1.3.  Intended Audiences

QPIM is intended for several audiences. The following lists some of the
intended audiences and their respective uses:

1.      Application vendors who build QoS policy management applications can
use this model as an extensible framework for defining policies to
control PEPs and PDPs in an interoperable manner
2.      Developers of Policy Decision Point (PDP) systems can use this
framework to develop interoperable policies
3.      QoS policy makers who seek a standardized model for expressing a
formal representation of QoS policy can use this model to control PEPs
of varying capabilities and functionality
4.      Builders of large organization data and knowledge bases who decide to
combine QoS policy information with other networking policy
information, assuming all modeling is based on [PCIM] and [PCIMe]
5.      Authors of various standards may use constructs introduced in this
document 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


draft-ietf-policy-qos-info-model-03.txt                       April 2001

1.2.  QPIM Characteristics

First, a general statement that characterizes QPIM:

"The QoS Policy Information Model (QPIM) establishes a standard framework
and constructs for specifying and representing business QoS policies.
This framework consists of a set of classes and relationships, organized
in an object-oriented information model. It is agnostic of any specific
PDP or PEP implementation and independent of any particular QoS
technology mechanism.  It is intended to be used to control the
provisioning of end-to-end network services."

In the rest of this section, we itemize and expand the general statement
presented above.

1.      QPIM, as the name implies, is a QoS Policy Information Model. This
means that it only models QoS concepts. These concepts are either
derived in this document, or adapted for use in modelingQoS from other
documents.

2.      QPIM is an information model. As such, it is independent of any
specific data storage mechanism and access protocol. QPIM's constructs
may be mapped to various storage and data organization technologies. A
data model mapped to QPIM can be created in a relational database, an
object oriented database, an LDAP directory and more. Because QPIM is
not a schema, the reader is encouraged to focus on the conceptual
level and not on the data organization methodology. Clearly a mapped
schema would include enhancements and optimizations not appropriate in
the information-modeling realm. For example, a given association
between two classes is always modeled as an association class in QPIM.
A given schema may find it useful and efficient to model such a
relationship using a reference object attribute in a directory or a
key‚Çôforeign key relationship in a relational database.

3.      QPIM is standard. The model standardizes the process of specifying
business QoS policies. It is an interpretation and extension of the
core policy information model as defined in [PCIM] and [PCIMe]. It
references other IETF standards (e.g. [TERMS], [DIFFSERV] and others)
and is meant to enhance interoperability of QoS systems from different
vendors.

QPIM establishes a conceptual framework by fully and closely following
the core policy framework 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 is a ubiquitous modeling method
that is easy to understand and read. In addition, UML-based models
lend themselves to further extensions and natural progression toward
detailed data models.



Snir, Ramberg, Strassner, Cohen          expires November 2001          8


draft-ietf-policy-qos-info-model-03.txt                       April 2001

5.      QPIM is a formal model. It expresses its concepts by describing and
defining classes and inter-class associations. Classes are formal
definitions of major concepts. For example, the concept of a traffic
profile is represented by the QosPolicyTrfcProf (abstract) class. A
derivative of this class provides several attributes to describe the
traffic in terms of average rate 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 the QoSPolicyPoliceAction class) to an
action to be taken when the restriction is violated.

6.      QPIM is abstract. The model is aimed at the formalization of humanly
expressed business QoS policies. For example, QPIM provides the means
of expressing formally a business policy that states: "In our network,
IP telephony should receive the same service quality as that of our
legacy phone systems". QPIM provides the topmost link from the
abstract business policy to the concrete device implementation by
expressing the abstract business policy in high-level networking
terms. QPIM compliant tools can be built to further concretize the
high-level QoS policies defined in QPIM terms so that actual network
elements (PEPs) can be configured to enforce the abstract business
policy.

7.      QPIM is QoS technology-agnostic, as it assumes no particular mechanism
(e.g., class-based weighted fair queuing) for policy enforcement. For
example, a certain policy may require that traffic adhere to a given
traffic profile. The traffic profile itself can be represented by an
instance of the QosPolicyTrfcProf class. The properties of the profile
class may include an attribute representing the average rate of
traffic in units of bits per second. However, QPIM neither describes
nor mandates a mechanism to perform the measuring mechanism itself.
Specifying such mechanisms is in the realm of network modeling, not
policy modeling.

Though a particular QoS mechanism (e.g., class-based weighted fair
queuing) is generic to many types of devices, individual devices may
implement this generic mechanism differently. This necessitates a
device-independent view of controlling QoS mechanisms, which is
precisely what QPIM is intended for. A single QPIM policy can be
translated into different configurations of different devices. For
example, a network interface card that can be configured to implement
several output queues and assign size and bandwidth allocation
parameters to each of them is a concrete element whose configuration
can be controlled with QPIM policies.









Snir, Ramberg, Strassner, Cohen          expires November 2001          9


 draft-ietf-policy-qos-info-model-03.txt                       April 2001


8.      QPIM adheres to and interprets the two predominant QoS paradigms:
Differentiated (DiffServ) Services and Integrated Services (IntServ).
While both DiffServ and IntServ inherently model technology, the
mechanisms implementing those technologies are not specified and are
left to the implementer's interpretation. DiffServ and IntServ are
described in [DIFFSERV] and [INTSERV], respectively. The term RSVP
refers to a protocol developed to implement IntServ [RSVP]. The terms
IntServ and RSVP are sometime used interchangeably.

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

1.3.  QPIM and Other Published Standards

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

By modeling the 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 of QPIM's
classes to specific data models (schemata). For example, [QoSSCHEMA]
defines how to map the data in this information model to a form that can
be stored in a directory that uses LDAPv3 as its access protocol.

QPIM adheres to terminology as defined in [TERMS].

QPIM intentionally avoids references 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 document that models QoS device data path and capabilities.









Snir, Ramberg, Strassner, Cohen          expires November 2001         10


draft-ietf-policy-qos-info-model-03.txt                       April 2001

2.  Class Hierarchies

2.1.  Inheritance Hierarchy

QPIM's inheritance hierarchy is rooted in [PCIM] and [PCIMe]. Figures 1
and 2 depict the QPIM inheritance hierarchy while noting its
relationships to [PCIM] and [PCIMe] classes. Figure 1 shows the QPIM
inheritance hierarchy,.

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

(continued on the next page)











Snir, Ramberg, Strassner, Cohen          expires November 2001         11


draft-ietf-policy-qos-info-model-03.txt                       April 2001

(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 Inheritance Hierarchy

Snir, Ramberg, Strassner, Cohen          expires November 2001         12


draft-ietf-policy-qos-info-model-03.txt                       April 2001

2.2.  Relationship Hierarchy

Figure 2 shows the QPIM association hierarchy.

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

Figure 2.  The QPIM Association Hierarchy





































Snir, Ramberg, Strassner, Cohen          expires November 2001         13


draft-ietf-policy-qos-info-model-03.txt                       April 2001

3.  QoS Actions

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

3.1  Overview

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

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

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

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, associating it with
variables and values of the appropriate type.



Snir, Ramberg, Strassner, Cohen          expires November 2001         14


draft-ietf-policy-qos-info-model-03.txt                       April 2001

3.2  RSVP Policy Actions

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

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

The COPS for RSVP [RFC2749] specification uses different Decision object
types to model each of these decisions. QPIM follows the COPS
specification and models each decision using a different action class.
The QoSPolicyRSVPAdmissionAction with its associated
QosPolicyIntServTrfcProf 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 a set of RSVP requests will be accepted yet a warning
message would be sent to the RSVP end points. The
QoSPolicyRSVPAdmissionAction controls the Decision Command and Decision
Flags objects used within COPS for RSVP.

The class QoSPolicyRSVPSimpleAction, which is derived from the
PolicySimpleAction class [PCIMe], can be used to specify RSVP decisions.

The property qpRSVPActionType designates the instance of the class to be
either of type 'REPLACE', 'STATELESS', or both. 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 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          expires November 2001         15


draft-ietf-policy-qos-info-model-03.txt                       April 2001

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

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 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 before the sender starts sending information,
the QoS mechanisms should be setup in advance. This usually means that
PEPs need to be provisioned with the set of policy rules in advance.
Policing and Shaping actions are modeled as sub-classes of the QoS
admission action. DSCP and CoS marking are modeled as sub-classes of the
simplePolicyAction class. Bandwidth allocation, scheduling and congestion
control actions are modeled as sub-classes of the QoS PHB action.







Snir, Ramberg, Strassner, Cohen          expires November 2001         16


draft-ietf-policy-qos-info-model-03.txt                       April 2001

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 the rate parameters of each flow or against the
aggregate rate of all flows that match the rule's condition. For example,
using two provisioned policer actions the following policies can be
enforced:

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

Both policies are modeled using the same QoSPolicyPoliceAction. 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 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 and QoSPolicyViolateAction.
The policer action is associated with a three-level token bucket traffic
profile carrying rate, burst and excess-burst parameters. Traffic
measured by a meter can be classified as conforming traffic when the
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 traffic profile is defined. This allows construction of both two-
level meters as well as providing an easier definition for three-level
meters needed for creating AF [AF] provisioning actions.

A policer action with a non-specified conform action implies that
conforming traffic should not be modified. A policer action with an
associated three-level traffic profile that does not specify an excess
action implies that the excess traffic should be treated as either
violating or conforming traffic according to some algorithm suitable for
the enforcement of the rule. For example, the final enforcement of such a
rule may be the use of a random function similar to RED to determine
whether traffic is conforming or violating. A policer action with a
three-level traffic profile that specifies an exceed action but does not
specify a violate action implies that violate action is identical to the
specified exceed action.





Snir, Ramberg, Strassner, Cohen          expires November 2001         17


draft-ietf-policy-qos-info-model-03.txt                       April 2001

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


3.3.2  Controlling Markers

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

DSCP markers set 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 to mark all packets that it
receives to a single DSCP, or may be configured to mark a packet to one
of a set of DSCPs used to select a PHB in a PHB group according to the
state of a meter. This can be achieved by associating a marking action
with a policer action using the conform, exceed and violate action
associations. The semantics of the DSCP marker is encapsulated in the
pairing of a DSCP variable and a DSCP value within a single
SimplePolicyAction instance via the appropriate associations.

IPP markers set the IPP field of a packet header to a particular IPP
value (0 through 7). The semantics of the IPP marker is encapsulated in
the pairing of a DSCP variable masked to IPP sub-field and a DSCP value
masked to IPP sub-field within a single SimplePolicyAction instance via
the appropriate associations.

CoS markers 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
user priority value can be specified using a rule with a condition
describing the set of DSCP values, and a CoS marking action that
specifies the required mapping to the given user ‚Çôpriority value. The
semantics of the CoS marker is encapsulated in the pairing of a CoS
variable and a CoS value (integer in the range of 0 through 7) within a
single SimplePolicyAction instance via the appropriate associations.


3.3.3  Controlling Edge Policies - Examples

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




Snir, Ramberg, Strassner, Cohen          expires November 2001         18


draft-ietf-policy-qos-info-model-03.txt                       April 2001


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

   Association and Aggregation Legend:

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

   Figure 3.    AF Policing and Marking

The marker is made of an instance of the SimplePolicyAction class. The
aggregation PolicyVariableInSimplePolicyAction (which is defined in
[PCIMe]) is used to associate the value to mark (contained in the
PolicyDSCPValue) with the appropriate traffic action. This aggregation is
not shown in this figure for simplicity. AF11 is marked on conforming
traffic; AF12 is marked on exceeding action and AF13 on violating
traffic.

The second example, shown in Figure 4, is the simplest policing action.
Traffic below a two-parameter traffic profile is unmodified, while
traffic exceeding the traffic profile is discarded.












Snir, Ramberg, Strassner, Cohen          expires November 2001         19


draft-ietf-policy-qos-info-model-03.txt                       April 2001


     +-----------------------+    +------------------------------+
     | 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., 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 as well as the maximum buffer resources. PHB
actions can therefore be used to both represent the final requirements
from PHBs as well as provide enough detail to be able to map the PHB
actions into a set of configuration parameters to 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 property of the PHB action specifies the packet size in
bytes, and is needed when translating the actions into actual
implementation configurations. For example, implementation measuring
queue length in bytes will need to use this property to map the
qpQueueSize property into queue length in bytes.








Snir, Ramberg, Strassner, Cohen          expires November 2001         20


draft-ietf-policy-qos-info-model-03.txt                       April 2001


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 percentage of the total available
bandwidth. The property qpBandwidthUnits is used to determine whether
percentage 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 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 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.

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

Snir, Ramberg, Strassner, Cohen          expires November 2001         21


draft-ietf-policy-qos-info-model-03.txt                       April 2001


3.4.3  Using Hierarchical Policies ‚Çô Examples for PHB actions

Hierarchical policy definition is a primary tool in the QoS Policy
Information model. Rule nesting introduced in [PCIMe] allows
specification of hierarchical policies controlling RSVP requests,
hierarchical shaping, policing and marking actions, as 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. 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 (AF13) then do AF13 actions
  If (default) then do Default actions.

EF, AF1 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 within the AF1 rule specifies that there are further refinements on
how AF13 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'.

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  BE-B:
  qpFairness: True

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: random
  qpDropThresholdUnits %
  qpDropMinThreshold:  10%
  qpDropMaxThreshold:  70%





Snir, Ramberg, Strassner, Cohen          expires November 2001         22


draft-ietf-policy-qos-info-model-03.txt                       April 2001


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  EF-B:
  qpForwardingPriority: 1
  qpBandwidthUnits: %
  qpMaxBandwidth  50%
  qpFairness: False

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

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

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

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

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

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


4.  Traffic Profiles

Meters measure the temporal state of a flow or a set of flows against a
traffic profile. In this document, traffic profiles are modeled by the
gpsPolicyTrfcProf class. The association
QoSPolicyTrfcProfileInAdmissionAction binds the traffic profile to the
admission action using it. Two traffic profiles are derived from the
abstract class gpsPolicyTrfcProf. The first is a Token Bucket
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


draft-ietf-policy-qos-info-model-03.txt                       April 2001


4.1  Provisioning Traffic Profiles

Provisioned Admission Actions including Shaping and policing are
specified using a two- or  three-parameter token bucket traffic profile.
The qosPolicyTokenBucketTrfcProf class 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.  The QosPolicyIntesrvTrfcProf
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 parameters are the traffic specification parameters used in
the integrated service architecture. These parameters are used to define
a sender TSPEC as well as FLOWSPEC for the Controlled-Load service [CL].
For a definition and full explanation of their meaning, please refer to
[RSVP-IS]. Parameters 6 and 7 are the additional parameters used for
specification of the Guaranteed Service FLOWSPEC [GS].








Snir, Ramberg, Strassner, Cohen          expires November 2001         24


draft-ietf-policy-qos-info-model-03.txt                       April 2001


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.
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 an admission decision when the scope of the
QoSPolicyRSVPAdmissionAction is set to 'class'.


5.  Pre-Defined QoS-Related Variables

Pre-defined variables are necessary for ensuring interoperability among
policy servers and policy management tools from different vendors.
The purpose of 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 PolicyImplictVariable class, defined in [PCIMe].
Subclasses specify the data type and semantics of the policy variables.

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











Snir, Ramberg, Strassner, Cohen          expires November 2001         25


draft-ietf-policy-qos-info-model-03.txt                       April 2001


RSVP related Variables:

1.      QoSPolicyRSVPSourceIPv4Variable - The source IP 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.
3.      QoSPolicyRSVPSourceIPv6Variable - The source IP 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.
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 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].
11.     QoSPolicyRSVPIntServVariable - The 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]
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.


Snir, Ramberg, Strassner, Cohen          expires November 2001         26


draft-ietf-policy-qos-info-model-03.txt                       April 2001

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

For example, suppose a User class has a multi-valued Property called
'member-of' that lists the names of groups that this user belongs to.
Suppose this property uses caseIgnoreMatch matching. A simple condition
can be constructed to match the reference carried in an RSVP Identity
policy object to a gpsPolicyAttributeValue with the following
characteristics:

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

A User Identity policy object carrying the following reference:

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

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











Snir, Ramberg, Strassner, Cohen          expires November 2001         27


draft-ietf-policy-qos-info-model-03.txt                       April 2001


7.  Class Definitions: Association Hierarchy

The following sections define associations that are specified by QPIM.

7.1. The Association "QosPolicyTrfcProfInAdmissionAction"

This association links a gpsPolicyTrfcProf object modeling a specific
traffic profile to a QoSPolicyAdmissionAction object. The class
definition for this association is as follows:

NAME                    QosPolicyTrfcProfInAdmissionAction
DESCRIPTION             A class representing the association between a
                  traffic profile used for admission decision
DERIVED FROM            Dependency
ABSTRACT                FALSE
PROPERTIES      Antecedent[ref QoSPolicyAdmissionAction [0..n]]
                  Dependent[ref QoSPolicyTrfcProf [0..n]]

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 a given
QoSPolicyAdmissionAction object may have 0 or more traffic profiles that
it can use.

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 a
given QoSPolicyAdmissionAction. The [0..n] cardinality means that a given
traffic profile may be used by 0 or more admission actions.


7.2  The Association "PolicyConformAction"

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

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



Snir, Ramberg, Strassner, Cohen          expires November 2001         28


draft-ietf-policy-qos-info-model-03.txt                       April 2001


7.2.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
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 PolicyAction object. This
represents a specific policy action that is used by a given
QoSPolicyPoliceAction. The [1..1] cardinality means that a given
conforming action may only be used by a single QoSPolicyPoliceAction.


7.3.  The Association "PolicyExcessAction"

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

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

7.3.1. The 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
action.

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
exceeding action may only be used by a single QoSPolicyPoliceAction.




Snir, Ramberg, Strassner, Cohen          expires November 2001         29


draft-ietf-policy-qos-info-model-03.txt                       April 2001


7.4.  The Association "PolicyViolateAction"

This association links a policer action with an object defining an
action to be applied on traffic violating the associated traffic
profile. The class definition for this association 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.
DERIVED FROM            Dependency
ABSTRACT                FALSE
PROPERTIES      Antecedent[ref QoSPolicePoliceAction[0..n]]
                  Dependent[ref PolicyAction [0..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 violating
action.

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
violating action may only be used by a single QoSPolicyPoliceAction.






















Snir, Ramberg, Strassner, Cohen          expires November 2001         30


draft-ietf-policy-qos-info-model-03.txt                       April 2001

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 that packets should be discarded.
DERIVED FROM PolicyAction
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 a given RSVP request. This
is done by comparing the RSVP request's TSPEC or RSPEC parameters against
the traffic profile (as specified in the QosPolicyIntServTrfcProf class).
The qpAdmissionScope property controls whether the comparison is done per
flow or per class (of flows). Only packets that conform to the traffic
profile are admitted for further processing; other packets are discarded.
The class definition is as follows:

NAME         QoSPolicyAdmissionAction
DESCRIPTION  This action controls admission decisions based on comparison
             of a meter to a traffic profile.
DERIVED FROM PolicyAction
ABSTRACT     True
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, the actual or requested rate of each flow is compared
against the traffic profile. If the scope is set to 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          expires November 2001         31


draft-ietf-policy-qos-info-model-03.txt                       April 2001

8.3. The Class QoSPolicyPoliceAction

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

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


8.4. The Class  QoSPolicyShapeAction

This class is the base class 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 the
QosPolicyTokenBucketTrfcProf 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
ABSTRACT     False
PROPERTIES   None



















Snir, Ramberg, Strassner, Cohen          expires November 2001         32


draft-ietf-policy-qos-info-model-03.txt                       April 2001

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
traffic profile. The traffic profile is specified in the
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 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. The class definition is as follows:

NAME         QoSPolicyRSVPAdmissionAction
DESCRIPTION  This action controls the admission of RSVP request.
             Depending on the scope, either a single RSVP request or the
             total admitted RSVP requests matching the conditions are
             compared against a traffic profile.
DERIVED FROM QoSPolicyAdmissionAction
ABSTRACT     False
PROPERTIES   qpRSVPWarnOnly, qpRSVPMaxSessions


8.5.1. The Property qpRSVPWarnOnly

When this property is set to True, the RSVP request is admitted, but an
RSVP error message carrying a warning is sent to the originator (sender
or receiver). 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)
        means that the request should be admitted AND an RSVP error
        message should be sent to the originator. The value of 0 (FALSE)
        means that the request should be admitted without sending an RSVP
        error message.

8.5.2. The Property qpRSVPMaxSessions

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

NAME   qpRSVPMaxSessions
SYNTAX Integer
VALUE  Must be greater than 0.




Snir, Ramberg, Strassner, Cohen          expires November 2001         33


draft-ietf-policy-qos-info-model-03.txt                       April 2001

8.6. The Class 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, for use by its subclasses
(QoSPolicyBandwidthAction and QoSPolicyCongestionControlAction). The
class definition is as follows:

NAME         QosPolicyPHBAction
DESCRIPTION  This action controls the Per-Hop-Behavor provided to
             behavior aggregates.
DERIVED FROM PolicyAction
ABSTRACT     True
PROPERTIES   qpPacketSize


8.6.1. The Property qpPacketSize

This property specifies the maximum packet size in bytes of this class of
packet. 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 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
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
ABSTRACT     False
PROPERTIES   qpForwardingPriority, qpBandwidthUnits, qpMinBandwdith,
             qpMaxBandwidth, qpMaxDelay, qpMaxJitter, qpFairness












Snir, Ramberg, Strassner, Cohen          expires November 2001         34


draft-ietf-policy-qos-info-model-03.txt                       April 2001

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 required. A positive value indicates the
            priority that is to be assigned for this (set of) flow(s).


8.7.2  The Property qpBandwidthUnits

This property defines in what units the properties qpMinBandwidth and
qpMaxBandwidth are defined. Bandwidth can either be defined in bits/sec
or in percentage of the available bandwidth or scheduler resources. This
property is defined as 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.


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 qpBandwidthUnits property. This property is
defined as follows.


NAME            qpMinBandwidth
SYNTAX  Integer
VALUE       The value must be greater than 0.


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 qpBandwidthUnits property. This
property is defined as follows.

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

Snir, Ramberg, Strassner, Cohen          expires November 2001         35


draft-ietf-policy-qos-info-model-03.txt                       April 2001


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. This property is defined
as follows.

NAME            qpMaxDelay
SYNTAX  Integer (milliseconds)
VALUE       The value must be greater than 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 maximum jitter is measured in milliseconds. This property is defined
as follows.

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


8.7.7.  The Property qpFairness

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

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


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
ABSTRACT     False
PROPERTIES   qpQueueSizeUnits, qpQueueSize, qpDropAlgorithm,
             qpDropThresholdUnits, qpDropMinThresholdValue,
             qpDropMaxThresholdValue



Snir, Ramberg, Strassner, Cohen          expires November 2001         36


draft-ietf-policy-qos-info-model-03.txt                       April 2001

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
transmission of packets within this queue. The property definition is:
NAME            qpQueueSizeUnits
SYNTAX  IntegerVALUE       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 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


8.8.3.  The Property qpDropAlgorithm

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

NAME            qpDropAlgorithm
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 percentage of the
available queue sizes. This property is defined as follows.

NAME            qpDropThresholdUnits
SYNTAX  Integer
VALUES      Two 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


draft-ietf-policy-qos-info-model-03.txt                       April 2001

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) value according to the value of
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


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) 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 than 0


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 binds the
admission decision to the traffic profile. The class definition is as
follows:

NAME              QoSPolicyTrfcProf
DERIVED FROM  Policy
ABSTRACT      True
PROPERTIES    None









Snir, Ramberg, Strassner, Cohen          expires November 2001         38


draft-ietf-policy-qos-info-model-03.txt                       April 2001

8.10. Class QosPolicyTokenBucketTrfcProf

This class models a two- or three-level Token Bucket traffic profile.
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
DERIVED FROM  QoSPolicyTrfcProf
ABSTRACT      False
PROPERTIES        qpTBRate, qpTBNormalBurst, qpTBExcessBurst


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


8.10.3. The Property qpTBExcessBurst

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

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













Snir, Ramberg, Strassner, Cohen          expires November 2001         39


draft-ietf-policy-qos-info-model-03.txt                       April 2001

8.11. Class 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
DERIVED FROM  QosPolicyTrfcProf
ABSTRACT      False
PROPERTIES        qpISTokenRate, qpISPeakRate, qpISBucketSize, qpISResvRate,
              qpISResvSlack, qpISMinPolicedUnit, qpISMaxPktSize


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










Snir, Ramberg, Strassner, Cohen          expires November 2001         40


draft-ietf-policy-qos-info-model-03.txt                       April 2001

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


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 0


8.11.7. The Property qpISMaxPktSize

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

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













Snir, Ramberg, Strassner, Cohen          expires November 2001         41


draft-ietf-policy-qos-info-model-03.txt                       April 2001

8.12. The Class QosPolicyAttributeValue

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

NAME         QosPolicyAttributeValue
DERIVED FROM PolicyImplicitValue
ABSTRACT     False
PROPERTIES   qpAttributeName, qpAttributeValueList


8.12.1. The Property qpAttributeName

This property defines the name of the attribute that the list of values
should be compared against. This property is defined as follows:

NAME     qpAttributeName
SYNTAX   String


8.12.2. The Property qpAttributeValueList

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

NAME     qpAttributeValueList
SYNTAX   String


8.13. The Class "QoSPolicyRSVPVariable"

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

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







Snir, Ramberg, Strassner, Cohen          expires November 2001         42


draft-ietf-policy-qos-info-model-03.txt                       April 2001

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
ABSTRACT     FALSE
PROPERTIES   None


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
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
ABSTRACT     FALSE
PROPERTIES   None



Snir, Ramberg, Strassner, Cohen          expires November 2001         43


draft-ietf-policy-qos-info-model-03.txt                       April 2001

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:

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

DERIVED FROM QoSPolicyRSVPVariable
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

DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT     FALSE
PROPERTIES   None




Snir, Ramberg, Strassner, Cohen          expires November 2001         44


draft-ietf-policy-qos-info-model-03.txt                       April 2001

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

DERIVED FROM QoSPolicyRSVPVariable
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. 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

DERIVED FROM QoSPolicyRSVPVariable
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:

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

             ALLOWED VALUE TYPES: Integer, BitString

DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT     FALSE
PROPERTIES   None




Snir, Ramberg, Strassner, Cohen          expires November 2001         45


draft-ietf-policy-qos-info-model-03.txt                       April 2001

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 (Integer has an
                                  enumeration of { Fixed-Filter=1 ,
                                  Shared-Explicit=2,
                                  Wildcard-Filter=3}

DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT     FALSE
PROPERTIES   None


8.24. The Class "QoSPolicyIntServVariable"

This is a concrete class that 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 (An enumerated value of
                                           { CL=1 , GS=2, NULL=3}

DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT     FALSE
PROPERTIES   None


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


draft-ietf-policy-qos-info-model-03.txt                       April 2001

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 , PATHTEAR=2, RESV=3,
                                      RESVTEAR=4, ResvErr=5, CONF=6}

DERIVED FROM QoSPolicyRSVPVariable
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

DERIVED FROM QoSPolicyRSVPVariable
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

DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT     FALSE
PROPERTIES   None











Snir, Ramberg, Strassner, Cohen          expires November 2001         47


draft-ietf-policy-qos-info-model-03.txt                       April 2001

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

DERIVED FROM QoSPolicyRSVPVariable
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


DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT     FALSE
PROPERTIES   None

















Snir, Ramberg, Strassner, Cohen          expires November 2001         48


draft-ietf-policy-qos-info-model-03.txt                       April 2001

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 (An enumeration of { NONE=0,
                                  PLAIN-TEXT=1, DIGITAL-SIG = 2,
                                  KERBEROS_TKT=3, X509_V3_CERT=4,
                                  PGP_CERT=5}

DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT     FALSE
PROPERTIES   None


8.31. The Class QoSPolicyDNValue

This class 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
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=*, O=Widget Inc., *, C=US"
matches: "OU=Sales, CN=J. Smith, O=Widget Inc, C=US" and also matches:
"OU=Sales, CN=J. Smith, O=Widget Inc, C=US, CN=CA".

The attribute is defined as follows:

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


Draft-ietf-policy-qos-info-model-01.txt                   November 2000


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, 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
ABSTRACT     False
PROPERTIES   qpRSVPActionType

Restricts the PolicyVariableInSimplePolicyAction aggregation to
QoSPolicyRSVPVariable.


8.32.1. The Property qpRSVPActionType

This property may contain one or two values 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. Refer to
[COPS] for details. This property is multi-value, which means that both
action types are to be executed.
NAME         QpRSVPActionType
DESCRIPTION  This property specifies whether the action type is for COPS
             Replace or Stateless decision or both.
SYNTAX       Integer
VALUE        This is an enumerated integer. A value of 0 specifies a
             COPS Replace decision. A value 1 specifies a COPS Stateless
             Decision.


9. Acknowledgements

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


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


draft-ietf-policy-qos-info-model-03.txt                     November 2001

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>

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

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

[DIFFSERV] S. Blake, et. Al., "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

[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-policy-qos-info-model-03.txt                     November 2001


[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
       Phone:  +1-408-527-1069
       Fax:    +1-408-527-2477
       E-mail:  johns@cisco.com



Snir, Ramberg, Strassner, Cohen          expires November 2001         52


draft-ietf-policy-qos-info-model-03.txt                     November 2001


   Ron Cohen
       Ntear   LLC
       Phone:
       Fax:
       E-mail: ronc@ntear.com


13. Full Copyright Statement

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

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works.  However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process 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          expires November 2001         53