Policy Framework                                                Y. Snir
Internet Draft                                               Y. Ramberg
Expires April 2000                                         J. Strassner
draft-ietf-policy-qos-info-model-01.txt                        R. Cohen
                                                          Cisco Systems

             Policy Framework QoS Information Model


Status of this Memo

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

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

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

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

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

Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

This document presents an object-oriented information model for
representing network QoS policies. This document refines the core
policy information model presented in [PCIM]. Specifically, this draft
refines the concept of generic policy rules, conditions and actions to
cover extensions necessary for representing QoS policies. It also
provides refinement of additional concepts that are important for
building rule-specific as well as reusable QoS policy rules. This
information model covers Differentiated Services QoS enforcement, and
Integrated Service QoS enforcement via policy control on RSVP
admission. It is important to note that this document defines an
information model, which by definition is independent of any particular
repository and access protocol. A companion document [QoSSCHEMA]
defines the mapping of these classes to a directory that uses LDAPv3 as
its access protocol. A second companion document [QOSDEV] supplies low-
level definitions of QoS mechanisms that are controlled by this
document.



Snir, Ramberg, Strassner, Cohen     expires October 2000                    1
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

Table of Contents

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

2. Information Model Hierarchy                                        6
2.1  Interaction Between the PCIM and This Document                   7
2.1.1  Extension of Concepts in the PCIM                              7
2.1.2  Addition of New Concepts Not in the PCIM                       7
2.2  High-Level Class Hierarchy                                       8

3. Containment Hierarchy                                             11
3.1. Containment Model                                               11
3.2. QoS Domain Containment Hierarchy                                12
3.2.1. Domain Grouping and Nesting                                   13
3.2.2. Resource Sharing                                              15
3.2.3. Placement                                                     15
3.2.4. Named Policy Containers                                       16
3.2.5. Policy Rules                                                  17
3.2.6. Conditions and Actions                                        18
3.2.7. Data Tree Example                                             19
3.3. Reusable-Object Repositories                                    19
3.4. Relationships Between QoS Domains and Repositories              20

4. Constructing a QoS Policy Rule                                    21
4.1 Policy Rule Structure                                            21
4.2 QoS Policy Conditions                                            22
4.2.1 Reusable vs. Ad-Hoc Conditions                                 23
4.2.2. Using Simple Conditions                                       24
4.2.3. Composing Complex Conditions                                  24
4.3 Simple Condition Operator                                        25
4.4. QoS Policy Variables                                            25
4.4.1 Variable Binding                                               26
4.4.2. Pre-Defined Variables                                         26
4.5 QoS Policy Values                                                30
4.6. PolicyTimePeriodCondition                                       30
4.7. Actions                                                         30
4.7.1 Provisioning Actions                                           31
4.7.1.1  Meters                                                      32
4.7.1.2  Markers                                                     32
4.7.1.3  Shapers                                                     32
4.7.1.4  Droppers                                                    33
4.7.1.5  Examples                                                    33
4.7.2 Signaling Actions                                              34
4.8 Traffic Profiles                                                 37
4.8.1 Provisioning Traffic Profiles                                  37
4.8.1 RSVP Traffic Profiles                                          38

5. Decision strategy                                                 39
5.1. First match                                                     39
5.2. Match All                                                       39


Snir, Ramberg, Strassner, Cohen     expires October 2000                    2
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

5.3. Decision Strategy example                                       40
5.3.1 Default Operation using First Match Everywhere                 40
5.3.2 Operation Using Other Decision Strategies                      41

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

7. QoS Policy Class Inheritance                                      43

8. Class Definitions                                                 45
8.1. Class qosPolicyDomain                                           45
8.1.1. The Property qpDomainName                                     45
8.1.2. The Property qpPHBSet                                         45
8.1.3. The Property qpPolicyRuleMatchMethod                          45
8.2. Class qosNamedPolicyContainer                                   46
8.2.1. The Property qpPriority                                       46
8.2.2. The Property qpNamedPolicyRuleMatchMethod                     46
8.3. Class qosPolicyPRAction                                         47
8.3.1. The Property qpDirection                                      47
8.3.2. The Property qpSetDSCPvalue                                   47
8.3.3. The Property qpMeter                                          47
8.3.4. The Property qpMeterScope                                     48
8.3.5. The Property qpTrfcProf                                       48
8.3.6. The Property qpOutOfProfileAction                             48
8.3.7. The Property qpOutofProfileRemarkValue                        48
8.4. Class qosPolicyRSVPAction                                       48
8.4.1. The Property qpRSVPDirection                                  49
8.4.2. The Property qpRSVPMessageType                                49
8.4.3. The Property qpRSVPStyle                                      49
8.4.4. The Property qpRSVPServiceType                                49
8.4.5. The Property qpRSVPInstallAction                              50
8.4.6. The Property qpRSVPCtrlAction                                 50
8.4.7. The Property qpRSVPMeter                                      50
8.4.8. The Property qpRSVPMeterScope                                 50
8.4.9. The Property qpRSVPTrfcProf                                   51
8.5. Class qosPolicyPRTrfcProf                                       51
8.5.1. The Property qpPRRate                                         51
8.5.2. The Property qpPRNormalBurst                                  51
8.5.3. The Property qpPRExcessBurst                                  51
8.6.  Class qosPolicyRSVPTrfcProf                                    52
8.6.1. The Property qpRSVPTokenRate                                  52
8.6.2. The Property qpRSVPPeakRate                                   52
8.6.3. The Property qpRSVPBucketSize                                 52
8.6.4. The Property qpRSVPResvRate                                   53
8.6.5. The Property qpRSVPResvSlack                                  53
8.6.6. The Property qpRSVPSessionNum                                 53
8.6.7. The Property qpMinPolicedUnit                                 53
8.6.8. The Property qpMaxPktSize                                     53
8.7. Class qosPolicyRSVPSignalCtrlAction                             54
8.7.1. The Property qpForwardingMode                                 54
8.7.2. The Property qpSendError                                      54


Snir, Ramberg, Strassner, Cohen     expires October 2000                    3
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

8.7.3. The Property qpReplaceDSCP                                    55
8.7.4. The Property qpReplacePreemptionPriority                      55
8.7.5. The Property qpReplaceDefendingPriority                       55
8.8. Class qosPolicyRSVPInstallAction                                55
8.8.1. The Property qpSetDSCPValue                                   56
8.8.2. The Property qpSetDefendingPriority                           56
8.8.3. The Property qpSetPreemptionPriority                          56
8.9. Class qosPolicySimpleCondition                                  56
8.9.1. The Property qpOperator                                       57
8.9.2. The Property qpVariableAtom                                   57
8.9.3. The Property qpValueAtom                                      57
8.10. Class qosPolicyVariable                                        57
8.10.1. The Property qpVariableName                                  58
8.10.2   The Property qpValueTypes                                   58
8.10.3.  The Property qpVariableDescription                          58
8.10.4. The Property qpValueConstraints                              59
8.11. Class qosPolicyValue                                           59
8.12. Class qosPolicyIPv4AddrValue                                   59
8.12.1. The Property qpIPv4AddrList                                  59
8.13. Class qosPolicyIPv6AddrValue                                   60
8.13.1. The Property qpIPv6AddrList                                  60
8.14. Class qosPolicyMACAddrValue                                    61
8.14.1. The Property qpMACAddrList                                   61
8.15. Class qosPolicyStringValue                                     62
8.15.1. The Property qpStringList                                    62
8.16 Class qosPolicyBitStringValue                                   62
8.16.1. The Property qpBitStringList                                 62
8.17. Class qosPolicyDNValue                                         63
8.17.1. The Property qpDNList                                        63
8.18. Class qosPolicyAttributeValue                                  63
8.18.1. The Property qpAttributeName                                 64
8.18.2. The Property qpAttributeValueList                            64
8.19. Class qosPolicyIntegerValue                                    64
8.19.1. The Property qpIntegerList                                   65
8.20. Class qosPolicyPHBSet                                          65
8.21. Class qosPolicyPHB                                             65
8.21.1. The Property qpDSCP                                          66
8.22. Class qosPolicyMeter                                           66

9. Extending the QoS Policy Schema                                   67
9.1. Extending qosPolicyValue                                        67
9.2. Extending qosPolicySimpleCondition                              67
9.3. Extending qosPolicyAction                                       67

10. Security Considerations                                          68

11. Acknowledgments                                                  68

12. References                                                       68

13. Author's Addresses                                               69

14. Full Copyright Statement                                         70

Snir, Ramberg, Strassner, Cohen     expires October 2000                    4
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

1. Introduction

This document presents an object-oriented information model for
representing network QoS policies. As such, it is independent of any
specific repository type and access protocol. This document refines the
core policy information model presented in [PCIM]. Specifically, this
draft refines the concept of generic policy rules, conditions and
actions to cover extensions necessary for representing QoS policies.
This information model covers Differentiated Service QoS enforcement,
and Integrated Service QoS enforcement via policy control on RSVP
admission. A companion document [QoSSCHEMA] defines the mapping
of these classes to a directory that uses LDAPv3 as its access
protocol. A second companion document [QOSDEV] supplies low-level
definitions of QoS mechanisms that are controlled by this document.


1.1  Goals

This document presents high level QoS policies that can be used to
enforce consistent behavior across a network, regardless of the actual
vendor-specific implementation details. The purpose of introducing a
standard information model is to allow interoperability between Policy
Servers, Policy Management Applications, and Network devices.

This document solves two problems. First, different devices have
different capabilities, and may respond differently to the same high-
level policy rule. This document solves this by defining a set of
common abstractions that can be used to build high-level QoS policies.
This enables different devices to use the same low-level abstractions
of mechanisms to implement QoS services, which are controlled by the
QoS policy rules defined in this document. The companion document
[QOSDEV] defines an information model for representing low-level QoS
mechanisms.

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


1.2 Approach and Related Documents

The information model presented in this document contains information
that can be shared by other network policy managers (e.g., Security
managers, IP address managers, and others). Examples include sharing of
the same definition of well-known application port numbers, IP
addresses of servers and other network attributes. It allows checking
of consistent behaviors of the interaction between the different
managers by comparing, for example, the set of QoS and security actions
enforced on the same set of flows.



Snir, Ramberg, Strassner, Cohen     expires October 2000                    5
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

Representation of the inherent QoS mechanisms of devices is described
in a companion draft [QOSDEV]. It provides a standard information model
for representing low-level QoS mechanisms that exist in devices in a
vendor-independent way. This document, augmented with the information
provided in [QOSDEV], together provide a set of enforceable policies
that control the QoS mechanisms on network devices.

The concept of PHBs is central to Differentiated Services. An
additional information model for representation of PHBs is defined in
[PHBSET], and a corresponding LDAP representation is provided in
[PHBLDAP]. This document is also intended to work with [PHBSET].

The remainder of this document presents, describes and defines the
concepts of the QoS Policy Information Model (QPIM). Relationships to
the Core schema and issues related to correct usage of the schema are
defined in [QOSSCHEMA].


2. Information Model Hierarchy

This section discusses the relationships between the Policy Core
Information Model ([PCIM]), the QoS Policy Information Model (QPIM,
which is this document) and future extensions of the QPIM.

The [PCIM] models high-level policy concepts and introduces structural
conventions and nomenclature common to all types of policies. The
fundamental purpose of the [PCIM] is to provide a generic
representation of the structure of a policy rule, along with a set of
classes and relationships that can serve as a common representation of
policy groups, rules, conditions, and actions. This enables derived
information models and schemata to all use a common set of terminology,
classes, and approaches, thus facilitating interoperability.

The QPIM refines the concepts of the [PCIM] and introduces a framework
of classes and relationships dedicated to model QoS Policies. This set
of classes and relationships can be used to configure and manage
devices that are IntServ- and DiffServ-compliant. The QPIM provides
building blocks to control most of the policy aspects required by
IntServ and DiffServ, but it is clear that not all functions are
provided.

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



Snir, Ramberg, Strassner, Cohen     expires October 2000                    6
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

The PCIM and QPIM are both inherently extensible. Furthermore, they are
designed to fit together to produce one virtual information model. As
such, both are independent of any particular repository and access
protocol. However, mappings can be defined to translate the data from
this single "virtual information model" to a form that can be
implemented in a specific type of repository that uses one or more
specific access protocols. Examples of mapping the concepts of the
[PCIM] and this document to a form that can be implemented in a
directory that uses LDAP as its access protocol are provided in
[PFSCHEMA] and [QOSSCHEMA], respectively.

This document specifies an extensible information model. While this
document defines facilities for building policy rules, conditions and
actions to build QoS policies, it is recognized that not all required
functionality can or should be defined in this document. Therefore, any
implementation-specific schema that is derived from this information
model should further concretize the QoS concepts of the QoS Policy
schema to suit its own application-specific needs.


2.1  Interaction Between the PCIM and This Document

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

2.1.1  Extension of Concepts in the PCIM

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

Similarly, the concepts of reusable- objects vs. rule-specific objects
have been moved from an earlier version of this document to the [PCIM].
Equally similarly, this document defines specific extensions to
guide the implementation of reusable- vs. rule-specific QoS objects.

This document also extends the concept of a policy rule, along with
conditions and actions that are specific to QoS. It further defines
different types of actions that target DiffServ and IntServ actions.

2.1.2  Addition of New Concepts Not in the PCIM

There are several notable new concepts that are not part of the [PCIM].
These include rule nesting, rule decision strategy, pre-defined
variables and constants, and PHBs.




Snir, Ramberg, Strassner, Cohen     expires October 2000                    7
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

The [PCIM] defines the ability to group policy rules by defining the
policyGroup class. This class has the following semantics: it can
either be used to contain a set of policyRules, or a set of
policyGroups, but not both. However, this simply gathers policy rules
together in a common container. It does not nest policy rules.

This document adds the concept of nesting one or more policy rules
within a policy rule. For example, one could think of a policy rule
that controls how a user logs onto the network as consisting of the
high-level rule itself. This high-level rule could consist of a set of
lower-level rules that are invoked at various stages of processing
(e.g., how the user is authenticated, how the IP Address is assigned,
etc.).

Since there is no concept of nested rules in the [PCIM], there is no
need for a decision strategy to be used to define the order of
processing of these rules. However, such a decision strategy must be
defined in this document because it does define nested rules. This
strategy defines an ordering that can be applied to a set of policyRule
and policyGroup objects within a larger context (e.g., a policy
domain). This in turn controls the execution of different policy
actions.

This document also defines a set of variable and constant definitions
for use with QoS policies. This concept is not present in the [PCIM]
because the purpose of the [PCIM] is to provide a general structure for
representing policy rules, conditions and actions. Variable and
constant definitions represent specific concepts that have pre-defined
semantics.

Finally, this document adds a general structure for accommodating PHBs.
PHBs are a concept that is specific to DiffServ, and thus are not
defined in the [PCIM].


2.2  High-Level Class Hierarchy

The following diagram shows how the classes in this document relate to
the classes defined in the PCIM.















Snir, Ramberg, Strassner, Cohen     expires October 2000                    8
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

(continued from previous page)

[unrooted]
   |
   +--Policy (abstract, defined in PCIM)
   |  |
   |  +---PolicyGroup (PCIM)
   |  |     |
   |  |     +---qosPolicyDomain (this document)
   |  |     |
   |  |     +---qosNamedPolicyContainer (this document)
   |  |
   |  +---PolicyRule (PCIM)
   |  |
   |  +---PolicyCondition (PCIM)
   |  |     |
   |  |     +---PolicyTimePeriodCondition (PCIM)
   |  |     |
   |  |     +---VendorPolicyCondition (PCIM)
   |  |     |
   |  |     +---qosPolicySimpleCondition (this document)
   |  |
   |  +---PolicyAction (PCIM)
   |  |     |
   |  |     +---VendorPolicyAction (PCIM)
   |  |     |
   |  |     +---qosPolicyPRAction (this document)
   |  |     |
   |  |     +---qosPolicyRSVPAction (this document)
   |  |     |
   |  |     +---qosPolicyRSVPSignalCtrlAction (this document)
   |  |     |
   |  |     +---qosPolicyRSVPInstallAction (this document)
   |  |     |
   |  +---qosPolicyPRTrfcProf (this document)
   |  |
   |  +---qosPolicyRSVPTrfcProf (this document)
   |  |
   |  +---qosPolicyVariable (this document)
   |  |
   |  +---qosPolicyValue (this document)
   |  |     |
   |  |     +---qosPolicyIPv4AddrValue (this document)
   |  |     |
   |  |     +---qosPolicyIPv6AddrValue (this document)
   |  |     |
   |  |     +---qosPolicyMACAddrValue (this document)
   |  |     |
   |  |     +---qosPolicyStringValue (this document)
   |  |     |

(continued on next page)


Snir, Ramberg, Strassner, Cohen     expires October 2000                    9
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

(continued from previous page)

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























Snir, Ramberg, Strassner, Cohen     expires October 2000                   10
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

3. Containment Hierarchy

In this section, we describe the organization and structure of the QPIM
hierarchy.

The QPIM consists of two hierarchies: A policy
definition hierarchy and a reusable objects repository hierarchy. A
particular data tree may contain any number of instances of each
hierarchy. Section 3.1 explains the containment and reference model
used in the construction of QoS Policy data trees. Section 3.2
describes the particular containment hierarchy of the policy definition
entity, which is modeled by the qosPolicyDomain class. Section 3.3
describes the structure of the reusable objects repository. Further
down (section 3.4) we explain the relationships between those entities.


3.1. Containment Model

The QPIM uses and extends the containment model of [PCIM]. The
following paragraphs summarize this containment model. For more detail,
please refer to [PCIM].

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

The basic mechanism used for expressing containment is placement of the
objects in the data tree. To express the relationship of "container -
contained" between a container object and the objects it contains, the
contained objects are placed below the container object.

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




Snir, Ramberg, Strassner, Cohen     expires October 2000                   11
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

To support a unified mechanism for containment of "local" and "remote"
objects, [PCIM] introduces the notion of association and aggregation
classes. These classes denote some type of dependency relationship that
exists between the classes that they are connecting. One type of
dependency that can be represented is, of course, containment.

[PCIM] recommends that associations and aggregations are also
implemented as classes. With respect to containment, an association
class represents the act of containment itself. For example, the
PolicyConditionInPolicyRule aggregation (defined in [PCIM]) defines
that zero or more policy conditions are contained in a given policy
rule.

In general, containment may be direct or indirect. Direct containment
means that when the association or aggregation is instantiated in a
repository, the child object will be directly scoped by the container
object. Indirect containment means that when the association or
aggregation is instantiated in a repository, the child object will
instead be referenced by the container object. As an example, if the
target repository is a directory, then direct containment is
implemented by instantiating the child object as a child node of a
container. Similarly, indirect containment would be implemented using
an attribute that is a DN (i.e., the DN points to another object).

The association classes can (and do) carry the added semantics needed
by the information model. For example, internal order of contained
objects is information that can be carried on the association objects
themselves. This makes the containment model more flexible, since the
same object may be used by two containers in different parts of the
containment tree.

Containment is implemented differently in different data stores.
Therefore, the containment tree that is being described is not
expressed directly in the information model. Rather, the information
model specifies classes and relationships that are used to model
entities and relationships between entities that are represented in the
containment data model. A mapping of the data specified in an
information model to a form that is repository-dependent must also be
specified. This is what [PFSCHEMA] and [QOSSCHEMA] do for the [PCIM]
and this document, respectively. Please refer to [PCIM] for more
information on the details of the association and aggregation class
mechanisms.


3.2. QoS Domain Containment Hierarchy

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





Snir, Ramberg, Strassner, Cohen     expires October 2000                   12
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

Figure 1 shows a summary view of the QoS domain containment hierarchy.
The text in parenthesis denotes object containment style: either
through placement in the data tree (i.e., using a class to form a
container in a specific place in the data tree) or indirectly through
association or aggregation classes.

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

           Figure 1: Qos Domain containment hierarchy


3.2.1. Domain Grouping and Nesting

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

One way to group QoS policy domains is by creating a common root for
several QoS policy domain data tree instances. This can be done by
using the PolicyGroup (defined in [PCIM]) class as a root for the
multi-domain tree. In this case, all that is needed is to place the
appropriate number of qosPolicyDomain (defined in this document)
instances under the appropriate policyGroup instance.






Snir, Ramberg, Strassner, Cohen     expires October 2000                   13
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

Figure 2 is an example that depicts the ability to provide different
classes of service to different organizations within a single
enterprise. In this example, the enterprise is represented by an
instance of the policyGroup class. The different organizations are each
represented by a separate QoS policy domain (which is an instance of
the qosPolicyDomain class). Each qosPolicyDomain class is used as a
container to hold all of the policies for a given portion of the
organization. In Figure 2, this level is represented by the nesting of
qosPolicyDomain classes.

Each qosPolicyDomain instance serves as a container that contains an
ordered list of related QoS policy rules that apply to a different part
or function of the domain (e.g., Eastern Sales vs. Western Sales). This
grouping is done using instances of the qosNamedPolicyContainer clas.
The qosNamedPolicyContainer class would in turn contain either a set of
policyRule instances, a set of policyGroup instances (to provide
further grouping of policy rules that are scoped by a given
qosNamedPolicyContainer), or both.

+-------------+
|policyGroup  | <------------------- QoS policies for an enterprise
+-------------+
   |
   |   +---------------+
    -->|qosPolicyDomain| <----------- QoS policies for the Sales group
       +---------------+
         |
         |   +---------------+
         |-->|qosPolicyDomain| <-------- QoS policies for Western Sales
         |   +---------------+
         |     |
         |     |   +-----------------------+
         |     |-->|qosNamedPolicyContainer| <--Qos Policies for group
         |     |   +-----------------------+    A within Western Region
         |     |
         |     |   +-----------------------+
         |      -->|qosNamedPolicyContainer| <--Qos Policies for group
         |         +-----------------------+    B within Western Region
         |
         |   +---------------+
          -->|qosPolicyDomain|  <--------QoS policies for Eastern Sales
             +---------------+
               |
               |   +-----------------------+
               |-->|qosNamedPolicyContainer| <--Qos Policies for group
               |   +-----------------------+    C within Eastern Region
               |
               |   +-----------------------+
                -->|qosNamedPolicyContainer| <--Qos Policies for group
                   +-----------------------+    D within Eastern Region

       Figure 2: Top-level policy data tree example


Snir, Ramberg, Strassner, Cohen     expires October 2000                   14
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

The modeling approach used in the previous example is but one possible
strategy among many. The information model allows for arbitrary nesting
of groups, thus providing the means for modeling both wide and deep
hierarchies.


3.2.2. Resource Sharing

Object instances residing in different parts of the containment tree
are independent to each other. That is, there is no cross-referencing
among objects located in different QoS policy domains. However,
multiple QoS policy domains may still share data by means of
referencing reusable objects. These are objects that are placed in a
special portion of the repository dedicated to this purpose. In fact,
there may be multiple such repositories, each used for collecting a set
of related reusable objects. In this document, we will call such
repositories reusable-objects repositories.

The sharing of global or common objects enhances the interoperability
of various policy agents, thus serving the primary goal of this
information model. Such commonly used building blocks as important
conditions (policyCondition and its subclasses ) and actions
(policyAction and its subclasses) can be placed in the reusable-object
repository and used by multiple policy rules from multiple domains.
Both the [PCIM] and the QPIM do not restrict the number of reusable-
object repositories that can be referenced from a single domain. Even a
single instance of a policy rule may contain references to objects
residing in more than one repository. It is important to note that the
QPIM does not dictate a QoS domain-wide scope for reusable objects, so
as to keep this concept as general as possible.


3.2.3. Placement

The purpose of the QPIM is to define a flexible structure of
information that does not pre-impose harsh restrictions on building the
data tree. Therefore, the QPIM must not contain any hidden assumptions
about the placement of particular QoS policy domain hierarchies
(including, for that matter, placement of reusable-object repositories
as explained in section 3.3 below). Consequently, the QPIM does not
require any pre-defined locations for the portion of the data tree that
is dedicated to policy. An instance of the global data tree (a
corporate directory, for example) may in fact contain several QoS
policy domains that exist within the global date tree in various
places. Zero or more reusable object-repositories may also be present
in the global data tree.

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



Snir, Ramberg, Strassner, Cohen     expires October 2000                   15
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

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

   Each QoS policy domain must contain complete policy information,
   either by containment of objects or by containment of association
   and/or aggregation objects, that is necessary to describe that
   policy domain. Reusable objects SHOULD be placed in one or more
   reusable-object repositories and referenced by one or more objects
   that exist in the QoS policy domain, as appropriate.


3.2.4. Named Policy Containers

A QoS policy domain is a container of (named) QoS Policy Containers, as
explained above. The information model class representing named QoS
policy containers is the qosNamedPolicyContainer class. This class
extends the policyGroup class, which is defined in [PCIM].

A (non-empty) qosNamedPolicyContainer holds an unordered list of
policyRules. There are two levels of priority that the QPIM specifies
that can be used to determine the order of execution of QoS policy
rules. At the highest level, we can define an unordered set of policy
containers, each of which has a priority attribute (called qpPriority).
This property is used to order the top level of the containment
hierarchy. Within a given containment level, we can then use the
Priority attribute of the policyRule class to establish an order of
which policy rule in a given container executes next. Figure 3 shows a
simple example of the ordering process. Section 4 describes policy
rules in more detail.

  +---------------+
  |qosPolicyDomain|
  +---------------+
     |
     |   +--------------+
     |-->|policyRule A  |
     |   |  Priority=19 |
     |   +--------------+
     |
     |   +-----------------------+    +-------------+
     |-->|qosNamedPolicyContainer|--->|policyRule C |
     |   |  qpPriority=5         | |  |  Priority=7 |
     |   +-----------------------+ |  +-------------+
     |                             |
     |   +-------------+           |  +-------------+
      -->|policyRule B |            ->|policyRule D |
         |  Priority=3 |              |  Priority=2 |
         +-------------+              +-------------+

  Figure 3. Example Ordering for a QoS Policy Decision

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

Snir, Ramberg, Strassner, Cohen     expires October 2000                   16
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

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

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

While this strategy should meet most needs, taking a slightly different
approach can provide additional flexibility. This approach is
illustrated by looking at how PHBs are modeled (see section 6). In this
approach, a different set of PHBs can be assigned to different policy
containers. This has the effect of modifying the interpretation of the
same PHBs by each policy container.

Each policy container is assigned a "match strategy". This is defined
in the qpNamedPolicyRuleMatchMethod attribute of the
qosPolicyNamedContainer class. This attribute defines how to interpret
the order of the QoS policy rules that it contains. For example, a
FirstMatch strategy means that the rules will be "matched" according to
ascending order of their Priority attribute. Decision strategies are
explained in section 5.

Policy container can be nested. A policy container may contain policy
rules (PolicyRule [PCIM]) or named policy containers. A particular
data tree, then, can be constructed as a deep hierarchy, if the
designers of the policy system deem it desirable.


3.2.5. Policy Rules

Each qosNamedPolicyContainer holds a set of policy rules (or possibly
additional policy containers, which could be policyGroups or
qosNamedPolicyContainers, that contain policy rules). QoS policy rules
are modeled by the [PCIM] class policyRule.

The semantics of a policy rule is, in essence, a conditional imperative
statement in the form 'if <condition> then <action>'. Applying a rule
means evaluating its condition and, depending on the truth value of
the condition, to execute the action or do nothing. Evaluating a
condition is known as 'matching the rule', an expression we'll be using
in later sections of this document.




Snir, Ramberg, Strassner, Cohen     expires October 2000                   17
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

A given policy rule MUST belong to one (and only one)
qosNamedPolicyContainer. This restriction is necessary because the
units of reusability are, in reality, the policy condition and action
terms that comprise a policy rule (as opposed to the policy rule
itself). This is because a policy rule is a composite object, made up
of several objects, but SHOULD be viewed as a coherent statement. It is
believed that allowing a policy rule to belong to more than one policy
container would decrease or even destroy its coherence. For example,
the rule itself is "aware" of its position inside its policy container,
so if we wanted to share a rule among many containers we'd have to
remove this knowledge from the rule. The notion of ordering of rules is
so essential to the concept of policy that removing it from the rule
also renders the rule less expressive, making policy modeling a more
difficult job. Furthermore, there are other important attributes that
are unique to the rule's specific placement inside a policy group
and/or a policy domain. For example, the DSCP values (section 6) that
define how a flow is colored (which in turn define the set of QoS
policy actions that should be invoked by the rule) may be interpreted
differently in different QoS policy domains (or policy containers).
These examples show that the modeling of shared rules is inappropriate
for the QPIM.

The order of the policy rules inside a container is based on the
relative values of the Priority attribute of each of the policyRules
(please see [PCIM] for more information). The enforcement of policy
rules also depends on particular settings belonging to the group. The
match strategy to be applied to the policy rules contained in a given
container is defined in the policyRuleMatchMethod attribute of the
qosNamedPolicyContainer object. Note that actions taken on packets may
use a different mechanism. For example, a DSCP value can be set
directly using the qpSetDSCPValue attribute of the qosPolicyPRAction
class. However, this class could also define a set of token bucket
parameters using the qpTrfcProf attribute. This references a traffic
profile (represented by the qosPolicyPRTrfcProf class) that carries the
policer or shaper rate values to be enforced on a flow or a set of
flows.


3.2.6. Conditions and Actions

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







Snir, Ramberg, Strassner, Cohen     expires October 2000                   18
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

3.2.7. Data Tree Example

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

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

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

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

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

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

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

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

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


3.3. Reusable-Object Repositories

Reusable objects are objects that can be referred by (hence "used by")
other objects. For example, the reference could be accomplished by
allocating an attribute on the referencing object that contains the
location of the referenced object.





Snir, Ramberg, Strassner, Cohen     expires October 2000                   19
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

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

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

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

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

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

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

  - qosPolicyVariable
  - qosPolicyValue
  - qosPolicySimpleCondition
  - policyAction
  - qosPolicyMeter, QoSPolicyPRTrfcProf and QoSPolicyRSVPTrfcProf
  - QoSPolicyPHBSet

Throughout this document, we point out the possible use of repository
and repository objects, wherever this is appropriate.


3.4. Relationships Between QoS Domains and Repositories

As explained above, a QoS policy domain contains within it groups of
policy rules. A policy rule can contain ordered lists of conditions and
actions. The conditions and actions may be reusable object that reside
in reusable objects repositories.

Many references to reusable objects may be made from the rules of a
given QoS policy domain. Those references need not be all pointing to
the same reusable-object repository; even e single rule may contain
references to reusable objects that reside in different repositories.




Snir, Ramberg, Strassner, Cohen     expires October 2000                   20
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

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


4. Constructing a QoS Policy Rule

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

The following sections describe these characteristics in more detail.


4.1 Policy Rule Structure

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

  1. An Enable flag that indicates whether a policy rule is
     administratively enabled, administratively disabled, or enabled
     for debug mode.
  2. A set of conditions (defined in either the
     PolicyConditionInPolicyRule or PolicyConditionInPolicyRepository
     aggregation)
  3. A flag indicating whether this condition is in disjunctive or
     conjunctive normal form
  4. An (optionally ordered) list of actions (defined in either the
     PolicyActionInPolicyRule or PolicyActionInPolicyRepository
     Aggregation)
  5. A priority value, defining the priority of this rule relative to
     other rules in the same container
  6. The attribute named ômandatoryö, which is used to define whether
     the evaluation of conditions (and the subsequent execution of
     actions if the conditions evaluate to TRUE) is mandatory or not
  7. A SequencedActions attribute that defines how to execute the
     actions if the condition is TRUE
  8. An array of PolicyRoles attributes, that define the roles or
     role-combinations that are used in this rule
  9. A RuleUsage attribute, that contains a description of how this
     rule should be used


Snir, Ramberg, Strassner, Cohen     expires October 2000                   21
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

The Boolean condition is used to evaluate if the set of actions should
be performed on a network flow by matching the network flow attributes
against the condition. QoS-specific conditions SHOULD be formed from
using either the qosPolicySimpleCondition class defined in this
document and/or the policyTimePeriodCondition class defined in [PCIM]
(or their subclasses, of course). Note that QoS-specific conditions MAY
be mixed with more generic conditions that are not derived from either
of these classes. However, these non-QoS-specific conditions SHOULD be
derived from the policyCondition class (defined in [PCIM]). The
combination of individual conditions in a policy rule is defined in
[PCIM] using the ConditionInPolicyRule class.

Each action in the list is modeled by an action derived from the
PolicyAction class. The ActionInPolicyRule class defines the order in
which policy actions are performed.

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

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

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


4.2 QoS Policy Conditions

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

Many conditions in policy rules, from a networking perspective, can be
modeled as Filters. Filters are not modeled directly in either the QPIM
or the PCIM (i.e., no Filter class is defined). However, the filter
concept is central in the QoS Policy data model, and is modeled in the
Network Model of DEN and used in the companion QoS Device information
model draft [QOSDEV].

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





Snir, Ramberg, Strassner, Cohen     expires October 2000                   22
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

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

The variable specifies the attribute of a flow that should be matched
when evaluating the condition. A set of predefined variables that cover
the basic network attribute are introduced to foster interoperability.
The list cover layer 3 IP attribute such as IP network addresses,
protocols and ports, as well as a set of layer 2 attributes and higher
level attributes such as application and user identity.

The variable is matched against a value to produce the Boolean result.
In the first example above, a source IP address variable is matched
against a 10.1.x.x subnet value. The operator specifies the type of
relation between the variable and the value evaluated in the condition.
Operators should model the 'belong to' and 'equal' relations in the
examples above. In many cases, a generic 'match' operator can be used,
and the interpretation of the relation between the variable and value
is implied by the value itself. For example, the variable source IP
address can be matched to an IP address, where the 'equal' relation is
implied, to a hostname in which the 'resolve to' relation is implied,
or to a subnet address in which 'belongs to' relation is implied.


4.2.1 Reusable vs. Ad-Hoc Conditions

This schema enables the reuse of simple conditions by placing them in a
common portion of the policy information tree (called the reusable-
object repository). In order for a simple condition to be a member of
this repository, it must carry a unique name.

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

Simple condition composition must enforce the following type
conformance rule: The qpValueTypes property of the variable must be
compatible with the value class name.

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

Variable representation

1. The class qosPolicyVariable may be contained in the
   qosPolicySimpleCondition instance.

2. The class qosPolicyVariable may be referenced from the
   qosPolicySimpleCondition instance (Reusable variable)


Snir, Ramberg, Strassner, Cohen     expires October 2000                   23
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

Value representation

1. The qosPolicyValue class may be contained in the
   qosPolicySimpleCondition class.

2. The qosPolicyValue class may be referenced from the
   qosPolicySimpleCondition instance. This allows reusing the
   qosPolicyValue object, which could be named and considered a named
   constant.


4.2.2. Using Simple Conditions

In most cases, the use of the qosPolicySimpleCondition class is
sufficient for the definition of a condition for a policyRule. A simple
condition can be added to a policyRule in two ways:

1. A direct attachment of an instance of the condition to the
   ConditionInPolicyRule instance. In this case, we call this an
   "ad-hoc" simple condition. This method allows the creation of a
   "private" simple condition, meaning that this instance of the
   condition can't be referenced by any other policy rule, and
   therefore is not reusable. However, since it embeds the condition
   directly in the ConditionInPolicyRule instance, it eliminates the
   extra access(es) required to fetch each of the condition elements
   that are refernced by pointers.

2. An indirect reference to an instance of a condition that resides in
   a reusable-object repository. This is called a reusable condition.
   This method allows the sharing of conditions by multiple policy
   rules.


4.2.3. Composing Complex Conditions

A complex condition consists of groups of simple conditions (i.e.,
instances of either the policyCondition and/or the
qosPolicySimpleCondition classes) that are combined in either
conjunctive or disjunctive normal form (as defined in [PCIM]).

A complex condition is modeled by the mechanisms supplied in the
following PCIM attributes:

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



Snir, Ramberg, Strassner, Cohen     expires October 2000            24
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

4.3 Simple Condition Operator

The QoS policy simple condition includes the qpOperator property,
Which specifies the type of relation between the variable and the value
evaluated in the condition. In many cases, a generic 'match' operator
can be used, and the interpretation of the relation between the
variable and value is implied by the value itself. For example, the
variable source IP address can be matched to an IP address, where the
'equal' relation is implied, to a hostname in which the 'resolve to'
relation is implied, or to a subnet address in which 'belongs to'
relation is implied.

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


4.4 QoS Policy Variables

QoS Policy Variables are used for building individual conditions, as
defined in section 4.2. The variable specifies the attribute of a flow
that should be matched when evaluating the condition.

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

A variable may also limit, or constrain, the set of values within a
particular value type that can be matched against it in a condition.
This may be viewed as a second level of integrity checking. For
example, a variable representing the source-port must limit the set of
values that it can assume to the valid range of integers that
correspond to legal source-port values (which is 0-65535). Integers
outside this range can not be matched to this variable. Thus, it is not
enough to say that the data type of the source-port variable is an
integer û we also need to ensure that the value to be tested is within
a valid range of integers.

The QPIM defines three important attributes that characterize each of
the variables that it defines:

  1. The property qpVariableName of the QosPolicyVariable class defines
     the well-known name used for logical binding of all variables that
     are defined in this document.
  2. The qpValueTypes is the list of value classes that could be
     matched to this variable.
  3. The qpValueConstraints defines a list of constraint on the
     variable (i.e., values that the Variable must match).


Snir, Ramberg, Strassner, Cohen     expires October 2000                   25
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

The combination of these three attributes provide a consistent and
extensible set of meta-data that define the semantics of variables that
are used to form QoS conditions. For example:

  - The qpVariableName can be used to identify common processing rules
    for a variable having a specific name.
  - The qpValueTypes attribute can be used to ensure that only proper
    classes are used as operators. For example, the source-port
    variable will not include the QosPolicyIPv4AddrValue class, since
    source ports have different semantics than IP addresses. However,
    it will include the QosPolicyIntegerValue class name.
  û The qpValueConstraints attribute ensures that variable-specific
    semantics are enforced (e.g., the source-port variable may include
    a constraint reference to a value object defining the integer range
    0..63535).


4.4.1. Variable Binding

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

Each variable defined in the QoS policy repository must be bound to a
logical entity such as a specific field in the IP header, application
unique identifier or an application-specific parameter.

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

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


4.4.2. Pre-Defined Variables

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



Snir, Ramberg, Strassner, Cohen     expires October 2000                   26
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

For example, different policy servers may have to evaluate the same
policy rule. If each policy server uses a common set of variables, this
helps to abstract the condition term such that its evaluation can be
performed in the same way.

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

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

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

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

+-----------------+---------------------------------------------------+
|Variable name    |                Logical binding                    |
+-----------------+---------------------------------------------------+
| SourceIP        | The source IP address of the flow. Compared to the|
|                 | source IP header field, or the sender address in  |
|                 | the RSVP Filter spec object [RSVP].               |
+-----------------+---------------------------------------------------+
| SourcePort      | The source Port of a UDP/TCP flow. Compared to the|
|                 | source port field in the TCP/UDP header, or the   |
|                 | sender port in the RSVP Filter spec object [RSVP].|
+-----------------+---------------------------------------------------+
| DestinationIP   | The destination IP address of the flow. Compared  |
|                 | to the destination IP header field, or the session|
|                 | address in the RSVP SESSION object [RSVP].        |
+-----------------+---------------------------------------------------+
| DestinationPort | The destination Port of a UDP/TCP flow. Compared  |
|                 | to the destination port field in the TCP/UDP      |
|                 | header, or the session port in the RSVP SESSION   |
|                 | object [RSVP].                                    |
+-----------------+---------------------------------------------------+

(Table continued in next page)



Snir, Ramberg, Strassner, Cohen     expires October 2000                   27
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

(Table continued from the previous page)

+-----------------+---------------------------------------------------+
|Variable name    |                Logical binding                    |
+-----------------+---------------------------------------------------+
| IPProtocol      | The IP protocol number. Compared to the protocol  |
|                 | number in the IP header field or to the IP        |
|                 | protocol in the RSVP SESSION object [RSVP].       |
+-----------------+---------------------------------------------------+
| ToS             | The ToS variable is bound to the IP header ToS    |
|                 | byte.                                             |
+-----------------+---------------------------------------------------+
| DSCP            | The DSCP variable is bound to the IP header DSCP  |
|                 | byte or to DCLASS RSVP object.                    |
+-----------------+---------------------------------------------------+
| DestinationMAC  | The destination MAC address variable is bound the |
|                 | frame destination MAC address.                    |
+-----------------+---------------------------------------------------+
| SourceMAC       | The source MAC address variable is bound the frame|
|                 | source MAC address.                               |
+-----------------+---------------------------------------------------+
| 8021QID         | The VLAN ID as represented in the 802.1Q field of |
|                 | the header.                                       |
+-----------------+---------------------------------------------------+
| Snap            | The snap protocol variable is bound to protocol   |
|                 | type carried over SNAP encapsulation.             |
+-----------------+---------------------------------------------------+
| Ethertype       | The ethertype variable is bound to the frame      |
|                 | header ethertype value.                           |
+-----------------+---------------------------------------------------+
| Ssap            | The source sap variable is bound the frame header |
|                 | field containing the source SAP.                  |
+-----------------+---------------------------------------------------+
| Dsap            | The destination sap variable is bound the frame   |
|                 | header field containing the destination SAP.      |
+-----------------+---------------------------------------------------+
| Application     | The ID of the application that generated the flow.|
+-----------------+---------------------------------------------------+
| User            | The ID of the user that initiated the flow, or is |
|                 | designated as the flow owner.                     |
+-----------------+---------------------------------------------------+

        Table 2. Pre-defined Variable Names and Their Bindings

The definition of each predefined variable includes a standard name and
the allowed value types, i.e. the variable's qpValueTypes property.

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






Snir, Ramberg, Strassner, Cohen     expires October 2000                   28
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

+-----------------+---------------------------------------------------+
|Variable name    |                Allowed class types                |
+-----------------+---------------------------------------------------+
| SourceIP        | qosPolicyIPv4AddrValue, qosPolicyIPv6AddrValue    |
+-----------------+---------------------------------------------------+
| SourcePort      | qosPolicyIntegerValue                             |
+-----------------+---------------------------------------------------+
| DestinationIP   | qosPolicyIPv4AddrValue, qosPolicyIPv6AddrValue    |
+-----------------+---------------------------------------------------+
| DestinationPort | qosPolicyIntegerValue                             |
+-----------------+---------------------------------------------------+
| IPProtocol      | qosPolicyIntegerValue                             |
+-----------------+---------------------------------------------------+
| ToS             | qosPolicyIntegerValue, qosPolicyBitStringValue    |
+-----------------+---------------------------------------------------+
| DSCP            | qosPolicyIntegerValue, qosPolicyBitStringValue    |
+-----------------+---------------------------------------------------+
| DestinationMAC  | qosPolicyMACAddrValue                             |
+-----------------+---------------------------------------------------+
| SourceMAC       | qosPolicyMACAddrValue                             |
+-----------------+---------------------------------------------------+
| 8021QID         | qosPolicyIntegerValue, qosPolicyBitStringValue    |
+-----------------+---------------------------------------------------+
| Snap            | qosPolicyIntegerValue                             |
+-----------------+---------------------------------------------------+
| Ethertype       | qosPolicyIntegerValue                             |
+-----------------+---------------------------------------------------+
| Ssap            | qosPolicyIntegerValue                             |
+-----------------+---------------------------------------------------+
| Dsap            | qosPolicyIntegerValue                             |
+-----------------+---------------------------------------------------+
| Application     | qosPolicyDNValue, qosPolicyStringValue,           |
|                 | qosPolicyAttributeValue                           |
+-----------------+---------------------------------------------------+
| User            | qosPolicyDNValue, qosPolicyStringValue,           |
|                 | qosPolicyAttributeValue                           |
+-----------------+---------------------------------------------------+

       Table 3. Allowed Variable Names and Their Default Class Types

Note: For Value type definition, check the QoS Policy Value section.













Snir, Ramberg, Strassner, Cohen     expires October 2000                   29
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

4.5 QoS Policy Value

This abstract class qosPolicyValue is used for defining values and
constants used in policy conditions. Different value types are derived
from this class and represent the various attributes required.
Extensions of the qosPolicValue class, defined in this document
provide a list of values for representing the basic network attribute.
Values can be used to represent constants as named values. Named values
could be kept in a repository to be reused by multiple conditions.
Examples of constants include well-known ports, well-known protocol,
server addresses, and other similar concepts.

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

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

General:
  qosPolicyStringValue
  qosPolicyIntegerValue,
  qosPolicyBitStringValue,
  qosPolicyDNValue,
  qosPolicyAttributeValue.

Layer 3 Network values:
  qosPolicyIPv4AddrValue,
  qosPolicyIPv6AddrValue.

Layer 2 Network values:
  qosPolicyMACAddrValue.

For details, please see the class definition section of each value.


4.6. PolicyTimePeriodCondition

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


4.7. Actions

The QoS Policy schema defines actions to control QoS enforcement in
both the Integrated-Service model as well as the Differential service
model. Two types of actions are provided: Signaling and Provisioning
actions.



Snir, Ramberg, Strassner, Cohen     expires October 2000                   30
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

Signaling actions are used to provide policy control on RSVP
requests. Provisioning actions are used to directly control the data
traffic, regardless of any out-of-band signaling.

A policy rule may aggregate zero or more policy actions. A QoS policy
rule extends this definition to include 0..n provisioning actions and
0..m signaling actions, each defined by an object or objects describing
the action(s) to perform. Actions are ordered (as opposed to rules,
which are prioritized). The order of actions is specified in [PCIM].

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

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

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

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

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


4.7.1 Provisioning Actions

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




Snir, Ramberg, Strassner, Cohen     expires October 2000                   31
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

4.7.1.1  Meters

Meters measure the temporal properties of the stream of packets
selected by a classifier against a traffic profile. Meters are modeled
by the QosPolicyMeter class. A meter can be shared between different
policy rules. If this is desired, then the meter SHOULD reside in a
reusable-object repository. This enables it to be referenced by all
policy rules that want to share it.

The property qpMeter is used to hold a reference to a (reusable) meter
that is kept in a reusable-object repository. The qpMeterScope property
specifies whether the meter should measure flows matching the rule
condition per interface, per device or per flow. A per flow meter
conceptually creates a new meter for each flow, measuring each flow
against the profile. A per interface meter measures the aggregate set
of flows matching the rule condition forwarded via a single interface.

Meters are measured against traffic profile modeled by the
qosPolicyPRTrfcProf object. The property qpTrfcProf holds a reference
to a traffic profile that resides in a reusable-object repository.


4.7.1.2  Markers

Markers are used to set the DS field of a packet to a particular DS
codepoint (DSCP), adding the marked packet to a particular DS behavior
aggregate. The marker may be configured to mark all packets steered to
it 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. When the marker changes the DSCP in a packet, it is
said to have "re-marked" the packet.

Marking is modeled by the property qpSetDSCPValue, which specifies the
DSCP to set. Remarking out-of-profile packets is modeled by the
qpOutofProfileRemarkValue property. The property qpOutOfProfileAction
should be set to 'remark' when the remark DSCP value is used.


4.7.1.3  Shapers

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

If the value of the property qpOutOfProfileAction is set to 'shape',
then this specifies that packets measured by a meter should be shaped
according to the traffic profile specified by a qosPolicyPRTrfcProf
object.




Snir, Ramberg, Strassner, Cohen     expires October 2000                   32
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

4.7.1.4. Droppers

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

If the value of the property qpOutOfProfileAction is set to 'drop',
then it specifies that packets measured by a meter should be policed
according to the traffic-profile specified by a qosPolicyPRTrfcProf
object.


4.7.1.5 Examples

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

Example 1: Set up a rule enforcing QoS provisioning actions:

LetÆs define a policy rule, P, as follows:

   If (<condition>) THEN, on outgoing traffic,
        mark with <DS Value> AND
      activate a per-flow policer <FLOWP> AND
      activate a per policy rule policer <CLASSP>

Rule P is represented using 3 qosPolicyPRAction objects:

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

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


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







Snir, Ramberg, Strassner, Cohen     expires October 2000                   33
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

Example 2: Conditioning traffic

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

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

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

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


4.7.2 Signaling Action

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

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

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





Snir, Ramberg, Strassner, Cohen     expires October 2000                   34
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

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

The qosPolicyRSVPAction action includes a specification of the subset
of RSVP flows on which the action should be taken. The following
parameters can be specified:

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

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

The basic decision modeled by this class is whether to admit or reject
the RSVP request. The decision can be based on comparison of the
request TSPEC or FLOWSPEC to a traffic profile and a meter. A meter can
be used to track the temporal resources allocation of RSVP requests
matching a network condition. Such meters allow enforcement of policies
of the form: "Allow allocation of resource via RSVP for flows coming
from subnet x up to a total aggregated rate of 256kb/sec". Use of
meters and meter scope is identical to their use in provisioning
policies. The following properties are used:

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

Both traffic profile and meter specifications can be directly included
within the action as well.

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

The qosPolicyRSVPInstallAction adds the following actions:

   1. Set the DSCP value
   2. Set the preemption priority of the RSVP request.

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







Snir, Ramberg, Strassner, Cohen     expires October 2000                   35
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

An RSVP node is responsible for deciding whether to admit flows or not,
based on its available resources. Setting the preemption priority
[RSVP_PREEMP] allows the RSVP node to decide which of its reservations
should be admitted, and when to make room for a newer reservation by
preempting an already installed one.

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

The qosPolicyRSVPSignalCtrlAction adds the following controls:

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

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

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

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

The following is an example for a rule enforcing QoS signaling actions:

  Rule S:
    If <condition> THEN, for all WF and SE style Resv messages,
         accept RSVP request requesting less than <64kb/sec> AND
       make sure that the total number of admitted active reservations
       is restricted to <5>.

The actions for Rule S are represented using two qosPolicyRSVPAction
objects, as follows:

Object 1:
  qpRSVPDirection: OUT
  qpRSVPMessageType: Resv
  qpRSVPStyle: SE, WF
  qpRSVPTrfcProf : DN {8Kb} (repository reference)
  qpRSVPMeterScope: flow





Snir, Ramberg, Strassner, Cohen     expires October 2000                   36
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

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

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


4.8. Traffic Profiles

The QoS Policy schema defines two categories of traffic profiles.
Provisioning traffic profiles carry rate and burst parameters to be
compared with flow meters. RSVP traffic profiles are compared with RSVP
TSPEC and FLOWSPEC parameters, and with meters aggregating the temporal
state of admitted RSVP reservations and states.

Traffic profiles can be kept in a repository for reusability. Traffic
profiles can also be directly attached to actions.


4.8.1. Provisioning traffic profiles

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

The qosPolicyPRTrfcProf class includes the following properties:

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

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

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


Snir, Ramberg, Strassner, Cohen     expires October 2000                   37
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

4.8.2.  RSVP traffic profiles

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

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

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

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

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

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


Snir, Ramberg, Strassner, Cohen     expires October 2000                   38
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

5. Decision strategy

The decision strategy to be used by policy servers and other policy
decision points in the network on a set of policies is defined by
grouping policies into various qosNamedPolicyContainer groups, and
using these groups to partition behavior in different QoS policy
domains. In order to get a consistent behavior of different policy
servers using the same group of policy rules, the priority of the
policy rules must be pre-defined and the decision strategy implemented
by each different policy server must be defined explicitly.

The decision strategy is defined per domain and can be overridden per
qosNamedPolicyContainer. When a policy decision point evaluates a set
of rules, it implements the decision strategy defined in each container
of rules. Nested containers can override the decision strategy of their
containers.

The order of decision making of nested rules is defined by the
combination of their internal priority, the priority of the policy rule
containing the nested rule and the priority of their containers.
Nested rules have a higher priority than their containing rule.
Priority is compared between rules and qosNamedPolicyContainers, as
Defined in [PCIM]. The rule priority of PCIM is extended by introducing
the qpPriority (group priority) property of qosNamedPolicyContainer.

Two decision strategies are defined:

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


5.1. First match

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


5.2. Match All

The match all decision strategy is defined as first scanning the
complete set of rules according to their defined order of priority and
then applying the actions of each rule that the flow meets with the
rule's conditions. This matching strategy may in many cases mean that a
number of rules may meet the flow's parameters and all of their actions
will be applied.

A Match All strategy may result in applying conflicting rules. Handling
conflicts is outside the scope of this draft. The implementers of QoS
systems must provide proprietary conflict detection and avoidance or
resolution mechanisms.

Snir, Ramberg, Strassner, Cohen     expires October 2000                   39
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

5.3. Decision Strategy example

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

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


       Figure 4: Decision Strategy example

NOTE: rule nesting is not defined in PCIM, but rather is defined in
this document


5.3.1  Default Operation using First Match Everywhere

For simplicity we assume that a Policy Decision Point needs to enforce
all rules described above. Therefore, the rules will be evaluated in
the following order:

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

If the decision strategy of the domain is first match and it is not
overridden by NamedContainer1, the decision process will stop once a
rule's condition is matched.

Note: this equates priority with order. This is very different than how
this same example would work using priority as defined in [PCIM] (in
fact, this could not even be represented in [PCIM]). This is because of
the following two reasons:

- PCIM does not provide the ability to assign an order to a named
    container. It therefore has no concept of ordering containers among
    its policy rules
  - PCIM has no concept of nested rules



Snir, Ramberg, Strassner, Cohen     expires October 2000                   40
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

5.3.2  Operation Using Other Decision Strategies

However, if the decision strategy of the domain is match all and it is
not overridden by NamedContainer1, the match all decision process will
run over all rules according to the order above.

If the decision strategy of the domain is first match and the decision
process of NamedContainer1 is match all, Rule1 will be evaluated
first. If its condition matches, the decision process stops. Else,
both Rules 1.1 and 1.2 will be evaluated and executed if their
conditions match. If one of NamedContainer1 rule match, the decision
process stops. Else Rules 3 and 4 will be evaluated using first match
decision strategy.

If the decision strategy of the domain is match all and the decision
process of NamedContainer1 is first match, the decision process will
evaluate Rule1 and continue to evaluate NamedContainer1 rules. Rules
1.1 and 1.2 will be evaluated using first match strategy. The decision
process continues to evaluate rules 3 and 4 according to match-all
decision strategy.


































Snir, Ramberg, Strassner, Cohen     expires October 2000                   41
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

6. Per Hop Behavior

A per-hop behavior (PHB) is a description of the externally observable
forwarding behavior of a DS node applied to a particular DS behavior
aggregate. A PHB is selected at a node by the DSCP in a received
packet. A set of PHBs is enforced on a QoS domain. The set of PHBs
share buffer and scheduler resources among them. The QPIM provides
abstract placeholders for PHBs and for a set of PHBs enforced together
on a QoS domain. Further specification of PHBs and PHB sets are outside
the scope of this document; please refer to [PHBSET] for more
information.


6.1. PHBs

The qosPolicyPHB abstract class models a single PHB. The qosPolicyPHB
class includes a single property, the DSCP value, which is an integer
with allowed values in the range of 0 to 63, inclusive. The
qosPolicyPHB name will be defined using the cn property belonging
to the Policy class [PCIM].


6.1. PHB Sets

The qosPolicyPHBSet abstract class serves as a named container for
instances of qosPolicyPHB classes. It models the set of PHBs enforced
together on a QoS domain. Different PHB sets can be kept in a
repository. A PHB set enforced on the domain is specified by either a
reference from the qosPolicyDomain class to one of the PHB sets that
are located in the reusable-object repository, or by directly including
the PHB set in the domain (the method for doing this is repository-
specific; for example, attachment could be used if the repository is a
directory).

To fine tune PHB parameters and to further restrict the namespace in
which a particular PHB is used, PHB sets can be referenced or augment
the semantics of qosNamedPolicyContainers. However, in order to
maintain an end-to-end consistent behavior, overriding the domain's PHB
set should be done only to fine tune the parameters of each PHBs, and
not to use a different set of PHBs altogether.

Markers coloring packets of flows on domain ingress edges should pick a
DSCP selecting one of the PHBs enforced on the QoS domain.











Snir, Ramberg, Strassner, Cohen     expires October 2000                   42
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

7. QoS Policy Class Inheritance

The following diagram illustrates the class hierarchy for the QPIM.
Relevant classes from the PCIM are also included for completeness:

     top
      |
      +--policy (abstract, [PCIM])
      |   |
      |   +--policyGroup ([PCIM])
      |   |    |
      |   |    +--qosPolicyDomain
      |   |    |
      |   |    +--qosNamedPolicyContainer
      |   |
      |   +--policyRule ([PCIM])
      |   |
      |   +--policyCondition ([PCIM])
      |   |    |
      |   |    +--policyTimePeriodCondition ([PCIM])
      |   |    |
      |   |    +--vendorPolicyCondition ([PCIM])
      |   |    |
      |   |    +--qosPolicySimpleCondition
      |   |
      |   +--policyAction
      |   |    |
      |   |    +--vendorPolicyAction ([PCIM])
      |   |    |
      |   |    +-- qosPolicyPRAction
      |   |    |
      |   |    +-- qosPolicyRSVPAction
      |   |    |
      |   |    +-- qosPolicyRSVPSignalCtrlAction
      |   |    |
      |   |    +-- qosPolicyRSVPInstallAction
      |   |
      |   +--qosPolicyVariable
      |   |
      |   +--qosPolicyValue(abstract)
      |   |   |
      |   |   +--qosPolicyIPv4AddrValue
      |   |   |
      |   |   +--qosPolicyIPv6AddrValue
      |   |   |
      |   |   +--qosPolicyMACAddrValue
      |   |   |
      |   |   +--qosPolicyStringValue
      |   |   |
      |   |   +--qosPolicyBitStringValue
      |   |   |

(Diagram continued in next page)

Snir, Ramberg, Strassner, Cohen     expires October 2000                   43
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

(Diagram continued from previous page)

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

  Figure 5. Class Inheritance Hierarchy for the QPIM

The reader is encouraged to read section 7 of [PCIM] in its entirety,
which defines the concepts of associations and aggregations. Ten
associations and aggregations are defined in the [PCIM]; note that the
QPIM does not define any new associations or aggregations:

  the Aggregation PolicyGroupInPolicyGroup
  the Aggregation PolicyRuleInPolicyGroup
  the Aggregation PolicyConditionInPolicyRule
  the Aggregation PolicyRuleValidityPeriod
  the Aggregation PolicyActionInPolicyRule
  the Association PolicyConditionInPolicyRepository
  the Association PolicyActionInPolicyRepository
  the Weak Aggregation PolicyGroupInSystem
  the Weak Aggregation PolicyRuleInSystem
  the Aggregation PolicyRepositoryInPolicyRepository



Snir, Ramberg, Strassner, Cohen     expires October 2000                   44
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

8. Class Definitions

8.1. Class qosPolicyDomain

This class defines the root of a single administrative QoS policy
domain, and contains the domain's policy rules and definitions. This
enables the administrator to partition the set of QoS information into
different domains, where each domain has a potentially different set of
PHBs and policies, access rules, decision strategy or other application
of the policy information organized in some fashion. The class
definition is as follows:

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


8.1.1. The Property qpDomainName

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

NAME            qpDomainName
SYNTAX  String


8.1.2. The Property qpPHBSet

This property contains a reference to the PHB set defined for this
domain. Its definition is as follows:

NAME            qpPHBSet
SYNTAX  Reference to a PHBSet object


8.1.3. The Property qpPolicyRuleMatchMethod

This property defines the decision strategy to be applied on this set
of QoS policy rules by policy servers. It is an enumerated integer that
defines two values, first match and match all. Please see section 5 of
this document for more information on these decision strategies. Its
definition is as follows:

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








Snir, Ramberg, Strassner, Cohen     expires October 2000                   45
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

8.2. Class qosNamedPolicyContainer

This class represents an administratively-defined policy rule
container. All policies that are commonly administered are defined in a
particular qosNamedPolicyContainer. For example, an administrator could
define a set of policies that serve a certain goal, or service a
certain type of application, or that handle a certain type of flow or
device. Placing these policies in a qosNamedPolicyContainer that
resides in a particular qosPolicyDomain enables the administrator to
group different sets of policy rules that perform different types of
operations. It also enables an organization to partition policies
according to the administrator (or other entity) that manages the
policies. The class definition is as follows:

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


8.2.1. The Property qpPriority

This property is a non-negative integer that defines the priority of a
named group of rules. Conceptually, it is the priority of the
qosNamedPolicyContainer, and is used to determine when the policy rules
that the qosNamedPolicyContainer contains are evaluated with respect to
other policyRules, policyGroups, and other qosNamedPolicyContainters.

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

NAME            qpPriority
SYNTAX  Integer (must be non-negative)


8.2.2. The Property qpNamedPolicyRuleMatchMethod

This property is an enumerated integer that defines the decision
strategy to be applied on this set of QoS policy rules by policy
servers. Please see section 5 of this document for more information on
these decision strategies. The attribute is defined as follows:

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








Snir, Ramberg, Strassner, Cohen     expires October 2000                   46
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

8.3. Class qosPolicyPRAction

This class defines DiffServ actions to be applied on a flow or group of
flows, including the marking of a DSCP value, dropping, policing and
shaping. The class definition is as follows:

NAME              qosPolicyPRAction
DERIVED FROM  policyAction (defined in [PCIM])
ABSTRACT      False
PROPERTIES        qpDirection, qpSetDSCPvalue, qpMeter, qpMeterScope,
                  qpTrfcProf, qpOutOfProfileAction,
                  qpOutOfProfileRemarkValue


8.3.1. The Property qpDirection

This property is an enumerated integer that defines whether the action
should be applied to incoming or/and outgoing interfaces. Note that
certain repositories MAY implement this enumeration in a different
form, as long as its semantics are preserved. For example, a directory
MAY implement this property as a multi-valued attribute, with the
attribute having the values IN and OUT. The attribute is defined as
follows:

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


8.3.2. The Property qpSetDSCPvalue

This property is an integer (constrained to the range 0-63, inclusive)
that defines the DSCP value of the (re)mark action. The attribute is
defined as follows:

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


8.3.3. The Property qpMeter

This property defines a reference to a qosPolicyMeter object used in
this provisioning action. The attribute is defined as follows:

NAME            qpMeter
SYNTAX  Reference to a qosPolicyMeter object









Snir, Ramberg, Strassner, Cohen     expires October 2000                   47
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

8.3.4. The Property qpMeterScope

This property is an enumerated integer that defines whether this
metering action should be applied on a per-flow, per-interface, or per-
device basis. The attribute is defined as follows:

NAME            qpMeterScope
SYNTAX  Integer (ENUM) û {flow=0,interface=1 device=2}


8.3.5. The Property qpTrfcProf

This property contains a reference to an object that defines the
DiffServ provisioning policing instruction value, defined as a
reference to a qosPolicyPRTrfcProf instance. The attribute is defined
as follows:

NAME            qpTrfcProf
SYNTAX  Reference to a qosPolicyPRTrfcProf object


8.3.6. The Property qpOutOfProfileAction

This property is an enumerated integer that defines the action to be
applied to out of profile packets, as defined in the DiffServTrfcProf
entry. That entry contains values for each of the three types of
actions that are present in this attribute: shaping, discarding, or
remarking. The attribute is defined as follows:

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


8.3.7. The Property qpOutofProfileRemarkValue

This property is an integer that defines the DSCP value to be applied
to out of profile packets if the qpOutofProfile action is defined as
REMARK. The attribute is defined as follows:

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


8.4. Class qosPolicyRSVPAction

This class defines a policy action to be applied on an RSVP signaling
message that matches the rule condition. The class definition is as
follows:






Snir, Ramberg, Strassner, Cohen     expires October 2000                   48
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

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


8.4.1. The Property qpRSVPDirection

This property is an enumerated integer, and defines whether the action
is to be applied to incoming or/and outgoing interfaces. Note that
certain repositories MAY implement this enumeration in a different
form, as long as its semantics are preserved. For example, a directory
MAY implement this property as a multi-valued attribute, with the
attribute having the values IN and OUT. The attribute is defined as
follows:

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


8.4.2. The Property qpRSVPMessageType

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

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


8.4.3. The Property qpRSVPStyle

This property is an enumerated integer, and defines different values
that limit the scope of the action to be enforced to RSVP Requests with
the specified reservation style. The attribute is defined as follows:

NAME            qpRSVPStyle
SYNTAX  Integer (ENUM) - {SE=0 FF=1 WF=2}


8.4.4. The Property qpRSVPServiceType

This property is an enumerated integer, and defines different values
that limit the scope of the action to be enforced to RSVP Requests
asking for specified integrated service type. The attribute is defined
as follows:

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


Snir, Ramberg, Strassner, Cohen     expires October 2000                   49
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

8.4.5. The Property qpRSVPInstallAction

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

NAME            qpRSVPInstallAction
SYNTAX  Reference to a qosPolicyRSVPInstallAction object


8.4.6. The Property qpRSVPCtrlAction

This property is a reference to a qosPolicyRSVPSignalCtrlAction object.
This object is used in conjunction with the RSVP reservation, and
defines detailed control on the signaling protocol behavior itself.
The information carried in RSVP messages can be modified using this
action, as well as the RSVP forwarding behavior. The attribute is
defined as follows:

NAME            qpRSVPCtrlAction
SYNTAX  Reference to a qosPolicyRSVPSignalCtrlAction object


8.4.7. The Property qpRSVPMeter

This property is a reference to a qosPolicyMeter object. This object is
used in conjunction with the RSVP reservation, and defines the detailed
definition of the meter characteristics. The attribute is defined as
follows:

NAME            qpRSVPMeter
SYNTAX  Reference to a qosPolicyMeter object


8.4.8. The Property qpRSVPMeterScope

This property is an enumerated integer that defines the scope of the
metering action to be on a per-flow, per-interface, or per-device
basis. The attribute is defined as follows:

NAME            qpRSVPMeterScope
SYNTAX  Integer (ENUM) û {flow=0,interface=1 device=2}











Snir, Ramberg, Strassner, Cohen     expires October 2000                   50
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

8.4.9. The Property qpRSVPTrfcProf

This property is a reference to a qosPolicyRSVPTrfcProf object, which
defines an IntServ RSVP Traffic profile. Values of RSVP traffic
profiles are compared against Traffic specification (TSPEC) and QoS
Reservation requests (FLOWSPEC) carried in RSVP requests. The attribute
is defined as follows:

NAME            qpRSVPTrfcProf
SYNTAX  Reference to a qosPolicyRSVPTrfcProf object


8.5. Class qosPolicyPRTrfcProf

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

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


8.5.1. The Property qpPRRate

This is a non-negative integer that defines the token rate in bits per
second. A rate of zero means that all packets will be out of profile.
The attribute is defined as follows:

NAME            qpPRRate
SYNTAX  Integer (must be non-negative)


8.5.2. The Property qpPRNormalBurst

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

NAME            qpPRNormalBurst
SYNTAX  Integer (must be non-negative)


8.5.3. The Property qpPRExcessBurst

This attribute is an integer that defines the excess size of a burst
measured in bytes.  The attribute is defined as follows:
NAME            qpPRExcessBurst
SYNTAX  Integer (must be non-negative)





Snir, Ramberg, Strassner, Cohen     expires October 2000                   51
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

8.6.  Class qosPolicyRSVPTrfcProf

This class represents an IntServ RSVP Traffic profile. Values of RSVP
traffic profiles are compared against Traffic specification (TSPEC) and
QoS Reservation requests (FLOWSPEC) carried in RSVP requests. Traffic
profiles can be reusable objects or ad-hoc. The class definition is as
follows:

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


8.6.1. The Property qpRSVPTokenRate

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

NAME            qpRSVPTokenRate
SYNTAX  Integer (must be non-negative)


8.6.2. The Property qpRSVPPeakRate

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

NAME            qpRSVPPeakRate
SYNTAX  Integer (must be non-negative)


8.6.3. The Property qpRSVPBucketSize

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

NAME            qpRSVPBucketSize
SYNTAX  Integer (must be non-negative)










Snir, Ramberg, Strassner, Cohen     expires October 2000                   52
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

8.6.4. The Property qpRSVPResvRate

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

NAME            qpRSVPResvRate
SYNTAX  Integer (must be non-negative)


8.6.5. The Property qpRSVPResvSlack

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

NAME            qpRSVPResvSlack
SYNTAX  Integer (must be non-negative)


8.6.6. The Property qpRSVPSessionNum

This property is a non-negative integer that defines the total number
of allowed RSVP sessions that can be active at any given time. The
attribute is defined as follows:

NAME            qpRSVPSessionNum
SYNTAX  Integer (must be non-negative)


8.6.7. The Property qpMinPolicedUnit

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

NAME            qpMinPolicedUnit
SYNTAX  Integer (must be non-negative)


8.6.8. The Property qpMaxPktSize

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

NAME            qpMaxPktSize
SYNTAX  Integer (must be non-negative)







Snir, Ramberg, Strassner, Cohen     expires October 2000                   53
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

8.7. Class qosPolicyRSVPSignalCtrlAction

This class extends the functionality of the qosPolicyRSVPAction class
by adding detailed control on the signaling protocol behavior itself.
The information carried in RSVP messages can be modified using this
action, as well as the RSVP forwarding behavior.

Since the purpose of this is to augment the behavior specified by the
qosPolicyRSVPAction class, this class SHOULD be used with a
qosPolicyRSVPAction object, and SHOULD NOT be used by itself.

This class can be extended to support replacement of additional object
in RSVP messages, beyond replacement of DCLASS and PREEMPTION object
replacement defined below.

The class definition is as follows:

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


8.7.1. The Property qpForwardingMode

This property is an enumerated integer that controls the forwarding of
RSVP messages. If the mode is set to proxy, RSVP Path messages are not
forwarded and a Resv message is returned as if the Resv was returned by
the receiver. Otherwise, RSVP Path messages are forwarded. The
attribute is defined as follows:

NAME            qpForwardingMode
SYNTAX  Integer (ENUM) - {Forward=0 , Proxy=1}


8.7.2. The Property qpSendError

This property is an enumerated integer and controls the generation of
Resv-Err and Path-Err messages as defined in [COPSRSVP]. The attribute
is defined as follows:

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










Snir, Ramberg, Strassner, Cohen     expires October 2000                   54
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

8.7.3. The Property qpReplaceDSCP

This property is a non-negative integer that allows the replacement of
a DCLASS object carrying a DSCP value in an RSVP message. The attribute
specifies the DSCP value to be replaces, and is defined as follows:

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


8.7.4. The Property qpReplacePreemptionPriority

This property is a non-negative integer that is used to replace or add
a preemption priority object (defined in [RSVP_PREEMP]) to RSVP
messages. The attribute is defined as follows:

NAME            qpReplacePreemptionPriority
SYNTAX  Integer (must be non-negative)


8.7.5. The Property qpReplaceDefendingPriority

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

NAME            qpReplaceDefendingPriority
SYNTAX  Integer (must be non-negative)


8.8. Class qosPolicyRSVPInstallAction

This class extends the functionality of the qosPolicyRSVPAction class
by adding detailed control for COPS Install decisions (defined in
[COPS]). This action allows assigning a preemption priority with an
RSVP request, to provide a device with information which RSVP requests
to accept in case of admission failures. This action specifies a DSCP
value (which provides an associated level of QoS) to set on the flow
that RSVP is requesting.

Since the purpose of this is to augment the behavior specified by the
qosPolicyRSVPAction class, this class SHOULD be used with a
qosPolicyRSVPAction object, and SHOULD NOT be used by itself.

This class can be extended to support additional install decisions that
need to be controlled.

The class definition is as follows:





Snir, Ramberg, Strassner, Cohen     expires October 2000                   55
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

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


8.8.1. The Property qpSetDSCPValue

This property is a non-negative integer that defines the setting of a
DSCP value in the device. In other words, this attribute controls the
remarking (by the device) of the flow signaled by the RSVP request. The
attribute is defined as follows:

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


8.8.2. The Property qpSetDefendingPriority

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

NAME            qpSetDefendingPriority
SYNTAX  Integer (must be non-negative)


8.8.3. The Property qpSetPreemptionPriority

This property is a non-negative integer, and is used to set the
preemption priority [RSVP_PREEMP] of RSVP flows. The attribute is
defined as follows:

NAME            qpSetPreemptionPriority
SYNTAX  Integer (must be non-negative)


8.9. Class qosPolicySimpleCondition (Aux)

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

Simple conditions are building blocks for more complex Boolean
conditions. The qosPolicySimpleCondition class is derived from the
policyCondition class in [PCIM]. Simple conditions can be kept in
repositories for reuse.



Snir, Ramberg, Strassner, Cohen     expires October 2000                   56
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

The class definition is as follows:

NAME              qosPolicySimpleCondition
DERIVED FROM  policyCondition (defined in [PCIM])
ABSTRACT      False
PROPERTIES        qpOperator, qpVariableAtom, qpValueAtom


8.9.1. The Property qpOperator

This property is a string that defines the relation between a variable
and a value. The default value is ômatchö, which has the semantics of
'belong to' or 'equal'. The attribute is defined as follows:

NAME               qpOperator
SYNTAX     String
DEFAULT VALUE  'match'


8.9.2. The Property qpVariableAtom

This property is a reference to an object that defines the variable to
be used in a QoS policy condition. The referenced object SHOULD be a
subclass of the qosPolicyVariable class. The attribute is defined as
follows:

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


8.9.3. The Property qpValueAtom

This property is a reference to an object that defines the value to be
used in a QoS policy condition. The referenced object SHOULD be a
subclass of the qosPolicyValue class. The attribute is defined as
follows:

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


8.10. Class qosPolicyVariable

Variables are used for building individual conditions. The variable
specifies the property of a flow that should be matched when evaluating
the condition. However, not every combination of a variable and a value
creates a meaningful condition. A source IP address variable can not be
matched against a value that specifies a port number. A given variable
selects the set of matchable value types.



Snir, Ramberg, Strassner, Cohen     expires October 2000                   57
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

A variable also limits the set of values within a particular value type
that can be matched against it in a condition. For example, a source-
port variable limits the set of values to represent integers to the
range of 0-65535. Integers outside this range can not be matched to the
16 bits port entity.

The class definition is as follows:

NAME              qosPolicyVariable
DERIVED FROM  policy (defined in [PCIM])
ABSTRACT      False
PROPERTIES        qpVariableName, qpValueTypes, qpVariableDescription,
                  QpValueConstraints


8.10.1. The Property qpVariableName

This property is a string that is a unique name for the variable. This
is very important, because the QPIM defines a correlation between its
pre-defined variable names and their logical bindings. This correlation
was defined earlier in Table 2. The attribute is defined as follows:

NAME            qpVariableName
SYNTAX  String, defined in the following table:


8.10.2   The Property qpValueTypes

This property is a string that specifies an unordered list of possible
value types that can be used in a simple condition together with this
variable. The value types are specified by their class names. The list
of class names allows efficient retrieval of the possible set of
relevant values from a repository, and was defined earlier in Table 3.
The attribute is defined as follows:

NAME            qpValueTypes
SYNTAX  String


8.10.3.  The Property qpVariableDescription

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

NAME            qpVariableDescription
SYNTAX  String








Snir, Ramberg, Strassner, Cohen     expires October 2000                   58
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

8.10.4. The Property qpValueConstraints

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

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


8.11. Class qosPolicyValue

This is an abstract class that serves as the base class for all
subclasses that are used to define value objects in the QPIM. It is
used for defining values and  constants used in policy conditions. The
class definition is as follows:

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


8.12. Class qosPolicyIPv4AddrValue

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

NAME              qosPolicyIPv4AddrValue
DERIVED FROM  qosPolicyValue
ABSTRACT      False
PROPERTIES        qpIPv4AddrList


8.12.1. The Property qpIPv4AddrList

This Property provides an unordered list of strings, each specifying a
single IPv4 address, a hostname, or a range of IPv4 addresses. The ABNF
definition [ABNF] of an IPv4 address is:

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

Each string entry is either:
  1. A single Ipv4address in dot notation as defined above.
       Example: 121.1.1.2
  2. A single Hostname. Hostname format follows the guidelines and
     restrictions specified in [NAMES].
       Example: www.bigcompany.com



Snir, Ramberg, Strassner, Cohen     expires October 2000                   59
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

  3. An IPv4range address range defined above, specified by a start
     address in dot notation and an end address in dot notation,
     separated by "-". The range includes all addresses between the
     range's start and end addresses, including the start and end
     addresses.
       Example: 1.1.22.1-1.1.22.5
  4. An IPv4maskedaddress address range defined above, specified by an
     address and mask. The address and mask are represented in dot
     notation separated by a comma ",".
       Example: 2.3.128.0,255.255.248.0.
  5. An IPv4prefix address range defined above specified by an address
     and a prefix length separated by "/".
       Example: 2.3.128.0/15

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


8.13. Class qosPolicyIPv6AddrValue

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

NAME              qosPolicyIPv6AddrValue
DERIVED FROM  qosPolicyValue
ABSTRACT      False
PROPERTIES        qpIPv6AddrList


8.13.1. The Property qpIPv6AddrList

This property provides an unordered list of strings, each specifying an
IPv6 address, a hostname, or a range of IPv6 addresses. IPv6 address
format definition uses the standard address format defined in [IPv6].
The ABNF definition [ABNF] as specified in [IPv6] is:

      IPv6address = hexpart [ ":" IPv4address ]
      IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
      IPv6prefix  = hexpart "/" 1*2DIGIT
      hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
      hexseq  = hex4 *( ":" hex4)
      hex4    = 1*4HEXDIG
      IPv6range = IPv6address"-"IPv6address
      IPv6maskedaddress = IPv6address","IPv6address
      Hostname (as defines in [NAMES])







Snir, Ramberg, Strassner, Cohen     expires October 2000                   60
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

Each string entry is either:

  1. A single IPv6address as defined above.
  2. A single Hostname. Hostname format follows guidelines and
     restrictions specified in [NAMES].
  3. An IPv6range address range, specified by a start address in dot
     notation and an end address in dot notation, separated by "-".
     The range includes all addresses between the range's start and end
     addresses, including the start and end addresses.
  4. An IPv4maskedaddress address range defined above specified by an
     address and mask. The address and mask are represented in dot
     notation separated by a comma ",".
  5. A single IPv6prefix as defined above.

NAME            qpIPv6AddrList
SYNTAX  String
FORMAT      IPv6address | hostname | IPv6addressrange |
            IPv6maskedaddress | IPv6prefix


8.14. Class qosPolicyMACAddrValue

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

NAME              qosPolicyMACAddrValue
DERIVED FROM  qosPolicyValue
ABSTRACT      False
PROPERTIES    qpMACAddrList


8.14.1. The Property qpMACAddrList

This property provides an unordered list of strings, each specifying a
MAC address or a range of MAC addresses. The 802 MAC address canonical
format is used. The ABNF definition [ABNF] is:

      MACaddress  = 1*4HEXDIG ":" 1*4HEXDIG ":" 1*4HEXDIG
      MACmaskedaddress = MACaddress","MACaddress

Each string entry is either:

  1. A single MAC address. Example: 0000:00A5:0000
  2. A MACmaskedaddress address range defined specified by an address
     and mask. The mask specifies the relevant bits in the address.
     Example: 0000:00A5:0000, FFFF:FFFF:0000 defines a range of MAC
     addresses in which the first 4 8-bit bytes are equal to 0000:00A5.

NAME            qpMACAddrList
SYNTAX  String
FORMAT      MACaddress | MACmaskedaddress



Snir, Ramberg, Strassner, Cohen     expires October 2000                   61
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

8.15. Class qosPolicyStringValue

This class is used to represent a single or set of string values. Each
can have wildcards. The class definition is as follows:

NAME              qosPolicyStringValue
DERIVED FROM  qosPolicyValue
ABSTRACT      False
PROPERTIES        qpStringList


8.15.1. The Property qpStringList

This property provides an unordered list of strings, each representing
a single string with wildcards. The asterisk character "*" is used as a
wildcard, and represents an arbitrary sub-string replacement. For
example, the value "abc*def" match "abcxyzdef", and the value
"abc*def*" match "abcxxxdefyyyzzz". The syntax definition is identical
to the substring assertion syntax defined in [LDAP_ATTR]. If the
asterisk character is required as part of the string value itself, it
MUST be quoted as described in section 4.3 of [LDAP_ATTR].

The attribute definition is as follows:

NAME                    qpStringList
SYNTAX          String


8.16 Class qosPolicyBitStringValue

This class is used to represent a single or set of bit string values.
The class definition is as follows:

NAME              qosPolicyBitStringValue
DERIVED FROM  qosPolicyValue
ABSTRACT      False
PROPERTIES        qpBitStringList


8.16.1. The Property qpBitStringList

This property provides an unordered list of strings, each representing
a single bit string or a set of bit strings. The number of bits
specified SHOULD equal the number of bits of the expected variable. For
example, for an 8-bit byte variable, 8 bits should be specified. If the
variable does not have a fixed length, the bit string should be matched
against the variable most significant bit string. The formal
definitions are:

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


Snir, Ramberg, Strassner, Cohen     expires October 2000                   62
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

Each string entry is either:

  1. A single bit string. Example: 00111010
  2. A range of bit strings specifies using a bit string and a bit
     mask. The bit string and mask properties have the same number of
     bits specified. The mask bit string specifies the significant bits
     in the bit string value. For example, 110110, 100110 and 110111
     would match the maskedBitString 100110,101110 but 100100 would
     not.

NAME            qpBitStringList
SYNTAX  String
FORMAT      bitString | maskedBitString


8.17. Class qosPolicyDNValue

This class is used to represent a single or set of Distinguished Name
values, including wildcards. A Distinguished Name is a name that can be
used as a key to retrieve an object. This value can be used in
comparison to reference values carried in RSVP policy objects, as
specified in [IDENT].

The class definition is as follows:

NAME              qosPolicyDNValue
DERIVED FROM  qosPolicyValue
ABSTRACT      False
PROPERTIES        qpDNList


8.17.1. The Property qpDNList

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

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


8.18. 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 [IDENT]. The property name is
used to specify which of the properties in the object is being used as
the condition. The value of this property will then be retrieved, and a
match (which is dependent on the property name) will be used to see if
the condition is satisfied or not.




Snir, Ramberg, Strassner, Cohen     expires October 2000                   63
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

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 qosPolicyAttributeValue with the following
characteristics:
  qpAttributeName="member-of",
  qpAttributeValueList = "group-A".

An Identity policy object carrying the following reference:
  "OU=Sales, CN=J. Smith, O=Widget Inc."
will match this simple condition only if J. Smith belongs to group-a.

The class definition is as follows:

NAME              qosPolicyAttributeValue
DERIVED FROM  qosPolicyValue
ABSTRACT      False
PROPERTIES        qpAttributeName, qpAttributeValueList


8.18.1. The Property qpAttributeName

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

NAME            qpAttributeName
SYNTAX  String


8.18.2. The Property qpAttributeValueList

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

NAME            qpAttributeValueList
SYNTAX  String


8.19. Class qosPolicyIntegerValue

This class provides a list of integer and integer range values.
Integers of arbitrary sizes can be represented. For a given variable,
the set of possible ranges of integer values allowed is specified via
the variable's qpValueConstraints Property. The class definition is as
follows:

NAME              qosPolicyIntegerValue
DERIVED FROM  qosPolicyValue
ABSTRACT      False
PROPERTIES        qpIntegerList


Snir, Ramberg, Strassner, Cohen     expires October 2000                   64
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

8.19.1. The Property qpIntegerList

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

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

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

The ABNF definition [ABNF] is:

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

Using ranges the operators greater-than, greater-than-or-equal-to,
less-than and less-than-or-equal-to can be expressed.

NAME            qpIntegerList
SYNTAX  String
FORMAT      integer | integerrange


8.20. Class qosPolicyPHBSet

The qosPolicyPHBSet is a class that serves as a named container for
qosPolicyPHB objects. A single PHB set is associated with a QoS domain
using the domain property defined in the qosPolicyDomain object.
Instances of the qosNamedPolicyContainer class can override the
domain's PHB set by referencing another PHB set via the qosPolicyPHBSet
Property or by aggregation of a qosPolicyPHBSet object.

The class is defined as follows:

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


8.21. Class qosPolicyPHB

The qosPolicyPHB Class is an abstract class that extends the policy
class (defined in the [PCIM]) with the information required to model
a PHB service class. The PHB service class is an abstraction over
device-specific parameters.




Snir, Ramberg, Strassner, Cohen     expires October 2000                   65
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

The class is defined as follows:

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


8.21.1. The Property qpDSCP

This property is an integer, constrained to have a value in the range
0..63 inclusive, for representing the service classes in the QoS policy
domain that are used for traffic classification. The attribute is
defined as follows:

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


8.22 Class qosPolicyMeter

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

A meter can be shared between different policy rules. A meter shared by
more than one policy rule resides in a repository and is referenced by
all sharing rules.

The class is defined as follows:

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



















Snir, Ramberg, Strassner, Cohen     expires October 2000                   66
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

9. Extending the QoS Policy Schema

The following subsections provide general guidance on how to create a
domain-specific information model derived from the QPIM by extending
the QoS policy classes.


9.1. Extending qosPolicyValue

The qosPolicyValue class and its subclasses describe the common
value types used in the QPIM. When other specific types are required,
such as a floating-point numbers, the required class SHOULD be derived
from the qosPolicyValue class and properties that contain the
corresponding values SHOULD be added.

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


9.2. Extending qosPolicySimpleCondition

The qosPolicySimpleCondition class is used to describe a single atomic
Boolean condition. For Boolean conditions that are not structured as
the ordered triple <variable - relation - value>, a new type of
condition class SHOULD be defined. An example would be a unary
condition.

Subclassing could be done using either the policyCondition or
qosPolicySimpleCondition classes as the superclass.


9.3. Extending qosPolicyAction

The Qos Policy actions classes defined in the QoS Policy Schema
Includes the following types of actions:

  Provisioning actions:
    * Marking
    * Policing, shaping and remarking according to a traffic profile

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

Additional actions could be associated with QoS policy rules by
extending the policyAction class with the appropriate properties.






Snir, Ramberg, Strassner, Cohen     expires October 2000                   67
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

10. Security Considerations

The security considerations for this document are the same as those of
the [PCIM].


11. Acknowledgments

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


12. References

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

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

[COPS]  D. Durham, J. Boyle, R . Cohen, S. Herzog, R. Rajan, A.
            Sastry, "The COPS (Common Open Policy Service) Protocol",
            RFC2748

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

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

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

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

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

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

[IPv6]      R. Hinden, S. Deering, "IP Version 6 Addressing
            Architecture", RFC2373, July 1998



Snir, Ramberg, Strassner, Cohen     expires October 2000                   68
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

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

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

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

[PHBLDAP]   R. Cohen, Y. Snir, J. Strassner, ôLDAP schema for Domain
            Per Hop Behavior Setö, Internet Draft
            <draft-ronc-domain-phb-set-ldap-rep-00.txt>

[PHBSET]    R. Cohen, A. Zavalkovsky, N. Elfassy, ôDomain Per Hop
            Behavior Set Specificationö, Internet Draft
            <draft-ronc-domain-phb-set-specification-00.txt>

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

[PIB]       M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, A.
            Smith, "Quality of Service Policy Information Base",
            Internet Draft <draft-mfine-cops-pib-01.txt>

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

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

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

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

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

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







Snir, Ramberg, Strassner, Cohen     expires October 2000                   69
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

13. Author's Addresses

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

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


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

Ron Cohen
    Cisco Systems
    4 Maskit Street
    Herzliya Pituach, Israel  46766
    Phone:  +972-9-970-0064
    Fax:    +972-9-970-0219
    E-mail:  ronc@cisco.com


14. Full Copyright Statement


This document and translations of it be copied and furnished to others,
and derivative works that comment on or otherwise explain it or assist
in its implementation  be prepared, copied, published and distributed,
in whole or in part, without restriction of any kind, provided that the
above copyright notice and this paragraph are included on all such
copies and derivative works.  However, this document itself  not be
modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process PROPERTIES be followed, or as required to translate
it into languages other than English.


Snir, Ramberg, Strassner, Cohen     expires October 2000                   70
Draft-ietf-policy-qos-info-model-01.txt                      April 2000

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

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








Snir, Ramberg, Strassner, Cohen     expires October 2000                   71