draft-ietf-policy-qos-info-model-03.txt   draft-ietf-policy-qos-info-model-04.txt 
Policy Framework Working Group Y. Snir Policy Framework Working Group Y. Snir
INTERNET-DRAFT Y. Ramberg INTERNET-DRAFT Y. Ramberg
Category: Standards Track J. Strassner
Cisco Systems Cisco Systems
Category: Standards Track J. Strassner
Intelliden
R. Cohen R. Cohen
Ntear LLC Ntear LLC
B. Moore
IBM
November 2001
Policy QoS Information Model Policy QoS Information Model
<draft-ietf-policy-qos-info-model-03.txt> <draft-ietf-policy-qos-info-model-04.txt>
Status of this Memo Status of this Document
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and Internet-Drafts are draft documents valid for a maximum of six months
may be updated, replaced, or obsoleted by other documents at any time. and may be updated, replaced, or obsoleted by other documents at any
It is inappropriate to use Internet-Drafts as reference material or to time. It is inappropriate to use Internet-Drafts as reference material
cite them other than as "work in progress." or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
This document presents an object-oriented information model for This document presents an object-oriented information model for
representing network QoS policies. This document is based on the IETF representing policies that administer, manage, and control access to
Policy Core Information Model and its extensions as specified by [PCIM] network QoS resources. This document is based on the IETF Policy Core
and [PCIMe]. This draft builds upon these two documents to define an Information Model and its extensions as specified by [PCIM] and [PCIMe].
information model for QoS enforcement for differentiated and integrated This draft builds upon these two documents to define an information
services using policy. It is important to note that this document defines model for QoS enforcement for differentiated and integrated services
an information model, which by definition is independent of any using policy. It is important to note that this document defines an
particular data storage mechanism and access protocol. information model, which by definition is independent of any particular
data storage mechanism and access protocol.
Definition of Key Word Usage Definition of Key Word Usage
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [KEYWORDS]. document are to be interpreted as described in RFC 2119 [KEYWORDS].
Snir, Ramberg, Strassner, Cohen expires November 2001 1 Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 1
Table of Contents Table of Contents
1. Introduction 5 1. Introduction 5
1.1. Goals 5 1.1. The Process of QoS Policy Definition 5
1.1.1. Modeling Abstract QoS Policies 5 1.2. Design Goals and Their Ramifications 8
1.1.2. Enhancing Interoperability 6 1.2.1. Policy-Definition Oriented 8
1.1.3. Intended Audiences 7 1.2.1.1. Rule-based Modeling 9
1.2. QPIM Characteristics 8 1.2.1.2. Organize Information Hierarchically 9
1.3. QPIM and Other Published Standards 10 1.2.1.3. Goal-Oriented Policy Definition 10
1.2.2. Policy Domain Model 10
2. Class Hierarchies 11 1.2.2.1. Model QoS Policy in a Device- and Vendor-Independent Manner 11
2.1. Inheritance Hierarchy 11 1.2.2.2. Use Roles for Mapping Policy to Network Devices 11
2.2. Relationship Hierarchy 13 1.2.2.3. Reusability 11
1.2.3. Enforceable Policy 12
1.2.4. QPIM Covers Both Signaled And Provisioned QoS 13
1.2.5. Interoperability for PDPs and Management Applications 14
1.3. Modeling Abstract QoS Policies 14
1.4. Rule Hierarchy 16
1.4.1. Use of Hierarchy Within Bandwidth Allocation Policies 17
1.4.2. Use of Rule Hierarchy to Describe Drop Threshold Policies 19
1.4.3. Restrictions of the Use of Hierarchy Within QPIM 20
1.5. Intended Audiences 21
3. QoS Actions 14 2. Class Hierarchies 22
3.1. Overview 14 2.1. Inheritance Hierarchy 22
3.2. RSVP Policy Actions 15 2.2. Relationship Hierarchy 24
3.3. Provisioning Policy Actions 16
3.3.1. Admission Actions: Controlling Policers and Shapers 17
3.3.2. Controlling Markers 18
3.3.3. Controlling Edge Policies Examples 18
3.4. Per-Hop Behavior Actions 20
3.4.1. Controlling Bandwidth and Delay 21
3.4.2. Congestion Control Actions 21
3.4.3. Using Hierarchical Policies Examples for PHB Actions 22
4. Traffic Profiles 23 3. QoS Actions 25
4.1. Provisioning Traffic Profiles 24 3.1. Overview 25
4.2. RSVP Traffic Profiles 24 3.2. RSVP Policy Actions 26
3.2.1. Example: Controlling COPS Stateless Decision 27
3.2.2. Example: Controlling the COPS Replace Decision 27
3.3. Provisioning Policy Actions 27
3.3.1. Admission Actions: Controlling Policers and Shapers 28
3.3.2. Controlling Markers 30
3.3.3. Controlling Edge Policies - Examples 31
3.4. Per-Hop Behavior Actions 32
3.4.1. Controlling Bandwidth and Delay 33
3.4.2. Congestion Control Actions 33
3.4.3. Using Hierarchical Policies: Examples for PHB Actions 34
5. Pre-Defined QoS-Related Variables 25 4. Traffic Profiles 36
4.1. Provisioning Traffic Profiles 36
4.2. RSVP Traffic Profiles 36
6. QoS Related Values 27 5. Pre-Defined QoS-Related Variables 38
7. Class Definitions: Association Hierarchy 28 6. QoS Related Values 40
7.1. The Association "QoSPolicyTrfcProfInAdmissionAction" 28
7.1.1. The Reference "Antecedent" 28
7.1.2. The Reference "Dependent" 28
7.2. The Association "PolicyConformAction" 28
7.2.1. The Reference "Antecedent" 29
7.2.2. The Reference "Dependent" 29
7.3. The Association "PolicyExcessAction" 29
7.3.1. The Reference "Antecedent" 29
7.3.2. The Reference "Dependent" 29
7.4. The Association "PolicyViolateAction" 30
7.4.1. The Reference "Antecedent" 30
7.4.2. The Reference "Dependent" 30
Snir, Ramberg, Strassner, Cohen expires November 2001 2 Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 2
Table of Contents (continued) Table of Contents (continued)
8. Class Definitions: Inheritance Hierarchy 31 7. Class Definitions: Association Hierarchy 42
8.1. The Class QoSPolicyDiscardAction 31 7.1. The Association "QoSPolicyTrfcProfInAdmissionAction" 42
8.2. The Class QoSPolicyAdmissionAction 31 7.1.1. The Reference "Antecedent" 42
8.2.1. The Property qpAdmissionScope 31 7.1.2. The Reference "Dependent" 42
8.3. The Class QoSPolicyPoliceAction 32 7.2. The Association "PolicyConformAction" 43
8.4. The Class QoSPolicyShapeAction 32 7.2.1. The Reference "Antecedent" 43
8.5. The Class QoSPolicyRSVPAdmissionAction 33 7.2.2. The Reference "Dependent" 43
8.5.1. The Property qpRSVPWarnOnly 33 7.3. The Association "QoSPolicyExceedAction" 43
8.5.2. The Property qpRSVPMaxSessions 33 7.3.1. The Reference "Antecedent" 44
8.6. The Class QoSPolicyPHBAction 34 7.3.2. The Reference "Dependent" 44
8.6.1. The Property qpPacketSize 34 7.4. The Association "PolicyViolateAction" 44
8.7. The Class QoSPolicyBandwidthAction 34 7.4.1. The Reference "Antecedent" 44
8.7.1. The Property qpForwardingPriority 35 7.4.2. The Reference "Dependent" 45
8.7.2. The Property qpBandwidthUnits 35 7.5 The Aggregation "QoSPolicyRSVPVariableInRSVPSimplePolicyAction" 45
8.7.3. The Property qpMinBandwidth 35 7.5.1. The Reference "GroupComponent" 45
8.7.4. The Property qpMaxBandwidth 35 7.5.2. The Reference "PartComponent" 45
8.7.5. The Property qpMaxDelay 36
8.7.6. The Property qpMaxJitter 36
8.7.7. The Property qpFairness 36
8.8. The Class QoSPolicyCongestionControlAction 36
8.8.1. The Property qpSizeUnits 37
8.8.2. The Property qpQueueSize 37
8.8.3. The Property qpDropAlgorithm 37
8.8.4. The Property qpDropThresholdUnits 37
8.8.5. The Property qpDropMinThresholdValue 38
8.8.6. The Property qpDropMaxThresholdValue 38
8.9. The Class QoSPolicyTrfcProf 38
8.10. The Class QoSPolicyTokenBucketTrfcProf 39
8.10.1. The Property qpTBRate 39
8.10.2. The Property qpTBNormalBurst 39
8.10.3. The Property qpTBExcessBurst 39
8.11. The Class QoSPolicyIntServTrfcProf 40
8.11.1. The Property qpISTokenRate 40
8.11.2. The Property qpISPeakRate 40
8.11.3. The Property qpISBucketSize 40
8.11.4. The Property qpISResvRate 41
8.11.5. The Property qpISResvSlack 41
8.11.6. The Property qpISMinPolicedUnit 41
8.11.7. The Property qpISMaxPktSize 41
8.12. The Class QoSPolicyAttributeValue 42
8.12.1. The Property qpAttributeName 42
8.12.2. The Property qpAttributeValueList 42
8.13. The Class QoSPolicyRSVPVariable 42
8.14. The Class QoSPolicyRSVPSourceIPv4Variable 43
8.15. The Class QoSPolicyRSVPDestinationIPv4Variable 43
8.16. The Class QoSPolicyRSVPSourceIPv6Variable 43
8.17. The Class QoSPolicyRSVPDestinationIPv6Variable 44
8.18. The Class QoSPolicyRSVPSourcePortVariable 44
8.19. The Class QoSPolicyRSVPDestinationPortVariable 44
Snir, Ramberg, Strassner, Cohen expires November 2001 3 8. Class Definitions: Inheritance Hierarchy 46
8.1. The Class QoSPolicyDiscardAction 46
8.2. The Class QoSPolicyAdmissionAction 46
8.2.1. The Property qpAdmissionScope 46
8.3. The Class QoSPolicyPoliceAction 47
8.4. The Class QoSPolicyShapeAction 47
8.5. The Class QoSPolicyRSVPAdmissionAction 47
8.5.1. The Property qpRSVPWarnOnly 48
8.5.2. The Property qpRSVPMaxSessions 48
8.6. The Class QoSPolicyPHBAction 49
8.6.1. The Property qpMaxPacketSize 49
8.7. The Class QoSPolicyBandwidthAction 49
8.7.1. The Property qpForwardingPriority 50
8.7.2. The Property qpBandwidthUnits 50
8.7.3. The Property qpMinBandwidth 50
8.7.4. The Property qpMaxBandwidth 51
8.7.5. The Property qpMaxDelay 51
8.7.6. The Property qpMaxJitter 51
8.7.7. The Property qpFairness 51
8.8. The Class QoSPolicyCongestionControlAction 52
8.8.1. The Property qpQueueSizeUnits 52
8.8.2. The Property qpQueueSize 52
8.8.3. The Property qpDropMethod 53
8.8.4. The Property qpDropThresholdUnits 53
8.8.5. The Property qpDropMinThresholdValue 53
8.8.6. The Property qpDropMaxThresholdValue 54
8.9. The Class QoSPolicyTrfcProf 54
8.10. The Class QoSPolicyTokenBucketTrfcProf 54
8.10.1. The Property qpTBRate 55
8.10.2. The Property qpTBNormalBurst 55
8.10.3. The Property qpTBExcessBurst 55
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 3
Table of Contents (continued) Table of Contents (continued)
8.20. The Class QoSPolicyRSVPIPProtocolVariable 45 8.11. The Class QoSPolicyIntServTrfcProf 55
8.21. The Class QoSPolicyRSVPIPVersionVariable 45 8.11.1. The Property qpISTokenRate 56
8.22. The Class QoSPolicyRSVPDCLASSVariable 45 8.11.2. The Property qpISPeakRate 56
8.23. The Class QoSPolicyRSVPStyleVariable 46 8.11.3. The Property qpISBucketSize 56
8.24. The Class QoSPolicyRSVPIntServVariable 46 8.11.4. The Property qpISResvRate 56
8.25. The Class QoSPolicyRSVPMessageTypeVariable 46 8.11.5. The Property qpISResvSlack 56
8.26. The Class QoSPolicyRSVPPreemptionPriorityVariable 47 8.11.6. The Property qpISMinPolicedUnit 57
8.27. The Class QoSPolicyRSVPPreemptionDefPriorityVariable 47 8.11.7. The Property qpISMaxPktSize 57
8.28. The Class QoSPolicyRSVPUserVariable 48 8.12. The Class QoSPolicyAttributeValue 57
8.29. The Class QoSPolicyRSVPApplicationVariable 48 8.12.1. The Property qpAttributeName 58
8.30. The Class QoSPolicyRSVPAuthMethodVariable 49 8.12.2. The Property qpAttributeValueList 58
8.31. The Class QosPolicyDNValue 49 8.13. The Class QoSPolicyRSVPVariable 58
8.31.1. The Property qpDNList 49 8.14. The Class QoSPolicyRSVPSourceIPv4Variable 58
8.32. The Class QoSPolicyRSVPSimpleAction 50 8.15. The Class QoSPolicyRSVPDestinationIPv4Variable 59
8.32.1. The Property qpRSVPActionType 50 8.16. The Class QoSPolicyRSVPSourceIPv6Variable 59
8.17. The Class QoSPolicyRSVPDestinationIPv6Variable 59
8.18. The Class QoSPolicyRSVPSourcePortVariable 60
8.19. The Class QoSPolicyRSVPDestinationPortVariable 60
8.20. The Class QoSPolicyRSVPIPProtocolVariable 61
8.21. The Class QoSPolicyRSVPIPVersionVariable 61
8.22. The Class QoSPolicyRSVPDCLASSVariable 61
8.23. The Class QoSPolicyRSVPStyleVariable 62
8.24. The Class QoSPolicyRSVPIntServVariable 62
8.25. The Class QoSPolicyRSVPMessageTypeVariable 63
8.26. The Class QoSPolicyRSVPPreemptionPriorityVariable 63
8.27. The Class QoSPolicyRSVPPreemptionDefPriorityVariable 63
8.28. The Class QoSPolicyRSVPUserVariable 64
8.29. The Class QoSPolicyRSVPApplicationVariable 64
8.30. The Class QoSPolicyRSVPAuthMethodVariable 65
8.31. The Class QosPolicyDNValue 65
8.31.1. The Property qpDNList 65
8.32. The Class QoSPolicyRSVPSimpleAction 66
8.32.1. The Property qpRSVPActionType 66
9. Acknowledgements 50 9. Acknowledgements 67
10. Security Considerations 50 10. Security Considerations 67
11. References 51 11. References 67
12. Authors' Addresses 52 12. Authors' Addresses 68
13. Full Copyright Statement 53 13. Full Copyright Statement 69
Snir, Ramberg, Strassner, Cohen expires November 2001 4 Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 4
1. Introduction 1. Introduction
This document presents an object-oriented information model for The QoS Policy Information Model (QPIM) establishes a standard framework
representing network QoS policies. This document is based on the IETF and constructs for specifying and representing policies that administer,
Policy Core Information Model and its extensions as specified by [PCIM] manage, and control access to network QoS resources. Such policies will
and [PCIMe]. This draft builds upon these two documents to define an be referred to as "QoS policies" in this document. The framework
information model for QoS enforcement for differentiated and integrated consists of a set of classes and relationships that are organized in an
services using policy. It is important to note that this document defines object-oriented information model. It is agnostic of any specific PDP or
an information model, which by definition is independent of any PEP (see [TERMS] for definitions) implementation, and independent of any
particular data storage mechanism and access protocol. particular QoS implementation mechanism.
The following subsections describe the goals and purposes of the QoS QPIM is designed to represent QoS policy information for large-scale
Policy Information Model (QPIM), its intended audience, and its policy domains (the term "policy domain" is defined in [TERMS]). A
relationships to other published standards. primary goal of this information model is to assist human administrators
in their definition of policies to control QoS resources (as opposed to
individual network element configuration). The process of creating QPIM
data instances is fed by business rules, network topology and QoS
methodology (e.g. Differentiated Services).
1.1 Goals This document is based on the IETF Policy Core Information Model and its
extensions as specified by [PCIM] and [PCIMe]. QPIM builds upon these
two documents to define an information model for QoS enforcement for
differentiated and integrated services ([DIFFSERV] and [INTSERV],
respectively) using policy. It is important to note that this document
defines an information model, which by definition is independent of any
particular data storage mechanism and access protocol. This enables
various data models (e.g., directory schemata, relational database
schemata, and SNMP MIBs) to be designed and implemented according to a
single uniform model.
This section explains the goals for creating QPIM. 1.1. The Process of QoS Policy Definition
1.1.1. Modeling Abstract QoS Policies This section describes the process of using QPIM for the definition QoS
policy for a policy domain. Figure 1 illustrates information flow and
not the actual procedure, which has several loops and feedback not
depicted.
The main goal of the QPIM is to create an information model that can be Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 5
used to help bridge part of the conceptual gap between a human policy ---------- ---------- -----------
maker and a network element that is configured to enforce the policy. | Business | | Topology | | QoS |
Clearly this wide gap implies several translation levels, from the | Policy | | | |Methodology|
abstract to the concrete. At the abstract end are the business QoS policy ---------- ---------- -----------
rules. QPIM facilitates a formal representation of network QoS business | | |
rules, thus providing the first concretization level: formally | | |
representing humanly expressed QoS policy. ------------------------------------
|
V
---------------
| QPIM/PCIM(e) |
| modeling |
---------------
|
| --------------
|<----------| Device info, |
| | capabilities |
| --------------
V
(---------------)
( device )---)
( configuration ) )---)
(---------------) ) )
(--------------) )
(-------------)
Figure 1: The QoS definition information flow
The process of QoS policy definition is dependent on three types of
information: the topology of the network devices under management, the
particular type of QoS methodology used (e.g., DiffServ) and the
business rules and requirements for specifying service(s) [TERMS]
delivered by the network. Both topology and business rules are outside
the scope of QPIM. However, important facets of both must be known and
understood for correctly specifying the QoS policy.
Typically, the process of QoS policy definition relies on a methodology
based on one or more QoS methodologies. For example, the DiffServ
methodology may be employed in the QoS policy definition process.
The topology of the network consists of an inventory of the network
elements that make up the network and the set of paths that traffic may
take through the network. For example, a network administrator may
decide to use the DiffServ architectural model [DIFFSERV] and classify
network devices using the roles "boundary" and "core" (see [TERMS] for a
definition of role, and [PCIM] for an explanation of how they are used
in the policy framework). While this is not a complete topological view
of the network, many times it may suffice for the purpose of QoS policy
definition.
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 6
Business rules are informal sets of requirements for specifying the
behavior of various types of traffic that may traverse the network. For
example, the administrator may be instructed to implement policy such
that VoIP traffic manifests behavior that is similar to legacy voice
traffic over telephone networks. Note that this business rule
(indirectly) prescribes specific behavior for this traffic type (VoIP),
for example in terms of minimal delay, jitter and loss. Other traffic
types, such as WEB buying transactions, system backup traffic, video
streaming, etc., will express their traffic conditioning requirements in
different terms. Again, this information is required not by QPIM itself,
but by the overall policy management system that uses QPIM. QPIM is used
to help map the business rules into a form that defines the requirements
for conditioning different types of traffic in the network.
The topology, QoS methodology, and business rules are necessary
prerequisites for defining traffic conditioning. QPIM enables a set of
tools for specifying traffic conditioning policy in a standard manner.
Using a standard QoS policy information model such as QPIM is needed
also because different devices can have markedly different capabilities.
Even the same model of equipment can have different functionality if the
network operating system and software running in those devices is
different. Therefore, a means is required to specify functionality in a
standard way that is independent of the capabilities of different
vendors' devices. This is the role of QPIM.
In a typical scenario, the administrator would first determine the
role(s) that each interface of each network element plays in the overall
network topology. These roles define the functions supplied by a given
network element independent of vendor and device type. The [PCIM] and
[PCIMe] documents define the concept of a role. Roles can be used to
identify what parts of the network need which type of traffic
conditioning. For example, network interface cards that are categorized
as "core" interfaces can be assigned the role name "core-interface".
This enables the administrator to design policies to configure all
interfaces having the role "core-interface" independent of the actual
physical devices themselves. QPIM uses roles to help the administrator
map a given set of devices or interfaces to a given set of policy
constructs.
The policy constructs define the functionality required to perform the
desired traffic conditioning for particular traffic type(s). The
functions themselves depend on the particular type of networking
technologies chosen. For example, the DiffServ methodology encourages us
to aggregate similar types of traffic by assigning to each traffic class
a particular per-hop forwarding behavior on each node. RSVP enables
bandwidth to be reserved. These two methodologies can be used separately
or in conjunction, as defined by the appropriate business policy. QPIM
provides specific classes to enable DiffServ and RSVP conditioning to be
modeled.
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 7
The QPIM class definitions are used to create instances of various
policy constructs such as QoS actions and conditions that may be
hierarchically organized in rules and groups (PolicyGroup and PolicyRule
as defined in [PCIM] and [PCIMe]). Examples of policy actions are rate
limiting, jitter control and bandwidth allocation. Policy conditions are
constructs that can select traffic according to a complex Boolean
expression.
A hierarchical organization was chosen for two reasons. First, it best
reflects the way humans tend to think about complex policy. Second, it
enables policy to be easily mapped onto administrative organizations, as
the hierarchical organization of policy mirrors most administrative
organizations. It is important to note that the policy definition
process described here is done independent of any specific device
capabilities and configuration options. The policy definition is
completely independent from the details of the implementation and the
configuration interface of individual network elements, as well as of
the mechanisms that a network element can use to condition traffic.
1.2. Design Goals and Their Ramifications
This section explains the QPIM design goals and how these goals are
addressed in this document. This section also describes the
ramifications of the design goals and the design decisions made in
developing QPIM.
1.2.1 Policy-Definition Oriented
The primary design goal of QPIM is to model policies controlling QoS
behavior in a way that as closely as possible reflects the way humans
tend to think about policy. Therefore, QPIM is designed to address the
needs of policy definition and management, and not device/network
configuration.
There are several ramifications of this design goal. First, QPIM uses
rules to define policies, based on [PCIM] and [PCIMe]. Second, QPIM uses
hierarchical organizations of policies and policy information
extensively. Third, QPIM does not force the policy writer to specify all
implementation details; rather, it assumes that configuration agents
(PDPs) interpret the policies and match them to suit the needs of
device-specific configurations.
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 8
1.2.1.1. Rule-based Modeling
Policy is best described using rule-based modeling as explained and
described in [PCIM] and [PCIMe]. A QoS policy rule is structured as a
condition clause and an action clause. The semantics are simple: if the
condition clause evaluates to TRUE, then a set of QoS actions (specified
in the action clause) can be executed. For example, the rule:
"WEB traffic should receive at least 50% of the available
bandwidth resources or more, when more is available"
can be formalized as:
"<If protocol == HTTP> then <minimum BW = 50%>"
where the first angle bracketed clause is a traffic condition and the
second angle bracketed clause is a QoS action.
This approach differs from data path modeling that describes the
mechanisms that operates on the packet flows to achieve the desired
effect.
Note that the approach taken in QPIM specifically did NOT subclass the
PolicyRule class. Rather, it uses the SimplePolicyCondition,
CompoundPolicyCondition, SimplePolicyAction, and CompoundPolicyAction
classes defined in [PCIMe], as well as defining subclasses of the
following classes: Policy, PolicyAction, SimplePolicyAction,
PolicyImplicitVariable, and PolicyValue. Subclassing the PolicyRule
class would have made it more difficult to combine actions and
conditions defined within different functional domains [PCIMe] within
the same rules.
1.2.1.2. Organize Information Hierarchically
The organization of the information represented by QPIM is designed to
be hierarchical. To do this, QPIM utilizes the PolicySetComponent
aggregation [PCIMe] to provide an arbitrarily nested organization of
policy information. A policy group functions as a container of policy
rules and/or policy groups. A policy rule can also contain policy rules
and/or groups, enabling a rule/sub-rule relationship to be realized.
The hierarchical design decision is based on the realization that it is
natural for humans to organize policy rules in groups. Breaking down a
complex policy into a set of simple rules is a process that follows the
way people tend to think and analyze systems. The complexity of the
abstract, business-oriented policy is simplified and made into a
hierarchy of simple rules and grouping of simple rules.
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 9
The hierarchical information organization helps to simplify the
definition and readability of data instances based on QPIM. Hierarchies
can also serve to carry additional semantics for QoS actions in a given
context. An example, detailed in section 2.3, demonstrates how
hierarchical bandwidth allocation policies can be specified in an
intuitive form, without the need to specify complex scheduler
structures.
1.2.1.3. Goal-Oriented Policy Definition
QPIM facilitates goal-oriented QoS policy definition. This means that
the process of defining QoS policy is focused on the desired effect of
policies, as opposed to the means of implementing the policy on network
elements.
QPIM is intended to define a minimal specification of desired network
behavior. It is the role of device-specific configuration agents to
interpret policy expressed in a standard way and fill in the necessary
configuration details that are required for their particular
application. The benefit of using QPIM is that it provides a common
lingua franca that each of the device- and/or vendor-specific
configuration agents can use. This helps ensure a common interpretation
of the general policy as well as aid the administrator in specifying a
common policy to be implemented across different devices. This is
analogous to the fundamental object-oriented paradigm of separating
specification from implementation. Using QPIM, traffic conditioning can
be specified in a general manner that can help different implementations
satisfy a common goal.
For example, a valid policy may include only a single rule that
specifies that bandwidth should be reserved for a given set of traffic
flows. The rule does not need to include any of the various other
details that may be needed for implementing a scheduler that supports
this bandwidth allocation (e.g., the queue length required). It is
assumed that a PDP or the PEPs would fill in these details using (for
example) their default queue length settings. The policy writer need
only specify the main goal of the policy, making sure that the preferred
application receives enough bandwidth to operate adequately.
1.2.2. Policy Domain Model
An important design goal of QPIM is to provide a means for defining
policies that span numerous devices. This goal differentiates QPIM from
device-level information models, which are designed for modeling policy
that controls a single device, its mechanisms and capabilities.
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 10
This design goal has several ramifications. First, roles [PCIM] are used
to define policies across multiple devices. Second, the use of abstract
policies frees the policy definition process from having to deal with
individual device peculiarities, and leaves interpretation and
configuration to be modeled by PDPs or other configuration agents.
Third, QPIM allows extensive reuse of all policy building blocks in
multiple rules used within different devices.
1.2.2.1. Model QoS Policy in a Device- and Vendor-Independent Manner
QPIM models QoS policy in a way designed to be independent of any
particular device or vendor. This enables networks made up of different
devices that have different capabilities to be managed and controlled
using a single standard set of policies. Using such a single set of
policies is important because otherwise, the policy will itself reflect
the differences between different device implementations.
1.2.2.2. Use Roles for Mapping Policy to Network Devices
The use of roles enables a policy definition to be targeted to the
network function of a network element, rather than to the element's type
and capabilities. The use of roles for mapping policy to network
elements provides an efficient and simple method for compact and
abstract policy definition. A given abstract policy may be mapped to a
group of network elements without the need to specify configuration for
each of those elements based on the capabilities of any one individual
element.
The policy definition is designed to allow aggregating multiple devices
within the same role, if desired. For example, if two core network
interfaces operate at different rates, one does not have to define two
separate policy rules to express the very same abstract policy (e.g.,
allocating 30% of the interface bandwidth to a given preferred set of
flows). The use of hierarchical context and relative QoS actions in QPIM
addresses this and other related problems.
1.2.2.3 Reusability
Reusable objects, as defined by [PCIM] and [PCIMe], are the means for
sharing policy building blocks, thus allowing central management of
global concepts. QPIM provides the ability to reuse all policy building
blocks: variables and values, conditions and actions, traffic profiles,
and policy groups and policy rules. This provides the required
flexibility to manage large sets of policy rules over large policy
domains.
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 11
For example, the following rule makes use of centrally defined objects
being reused (referenced):
If <DestinationAddress == FinanceSubNet> then <DSCP = MissionCritical>
In this rule, the condition refers to an object named FinanceSubNet,
which is a value (or possibly a set of values) defined and maintained in
a reusable objects container. The QoS action makes use of a value named
MissionCritical, which is also a reusable object. The advantage of
specifying a policy in this way is its inherent flexibility. Given the
above policy, whenever business needs require a change in the subnet
definition for the organization, all that's required is to change the
reusable value FinanceSubNet centrally. All referencing rules are
immediately affected, without the need to modify them individually.
Without this capability, the repository that is used to store the rules
would have to be searched for all rules that refer to the finance
subnet, and then each matching rule's condition would have to be
individually updated. This is not only much less efficient, but also is
more prone to error.
For a complete description of reusable objects, refer to [PCIM] and
[PCIMe].
1.2.3. Enforceable Policy
Policy defined by QPIM should be enforceable. This means that a PDP can
use QPIM's policy definition in order to make the necessary decisions
and enforce the required policy rules. For example, RSVP admission
decisions should be made based on the policy definitions specified by
QPIM. A PDP should be able to map QPIM policy definitions into PEP
configurations, using either standard or proprietary protocols.
QPIM is designed to be agnostic of any particular, vendor-dependent
technology. However, QPIM's constructs SHOULD always be interpreted so
that policy-compliant behavior can be enforced on the network under
management. Therefore, there are three fundamental requirements that
QPIM must satisfy:
1. Policy specified by QPIM must be able to be mapped to actual
network elements.
2. Policy specified by QPIM must be able to control QoS network
functions without making reference to a specific type of device
or vendor.
3. Policy specified by QPIM must be able to be translated into
network element configuration.
QPIM satisfies requirements #1 and #2 above by using the concept of
roles (specifically, the PolicyRoles property, defined in PCIM). By
matching roles assigned to policy groups and to network elements, a PDP
(or other enforcement agent) can determine what policy should be applied
to a given device or devices.
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 12
The use of roles in mapping policy to network elements supports model
scalability. QPIM policy can be mapped to large-scale policy domains by
assigning a single role to a group of network elements. This can be done
even when the policy domain contains heterogeneous devices. So, a small
set of policies can be deployed to large networks without having to re-
specify the policy for each device separately. This QPIM property is
important for QoS policy management applications that strive to ease the
task of policy definition for large policy domains.
Requirement #2 is also satisfied by making QPIM domain-oriented (see
[TERMS] for a definition of "domain"). In other words, the target of
the policy is a domain, as opposed to a specific device or interface.
Requirement #3 is satisfied by modeling QoS conditions and actions that
are commonly configured on various devices. However, QPIM is extensible
to allow modeling of actions that are not included in QPIM.
It is important to note that different PEPs will have different
capabilities and functions, which necessitate different individual
configurations even if the different PEPs are controlled by the same
policy.
1.2.4. QPIM Covers Both Signaled And Provisioned QoS
The two predominant standards-based QoS methodologies developed so far
are Differentiated Services (DiffServ) and Integrated Services
(IntServ). The DiffServ provides a way to enforce policies that apply to
a large number of devices in a scalable manner. QPIM provides actions
and conditions that control the classification, policing and shaping
done within the differentiated service domain boundaries, as well as
actions that control the per-hop behavior within the core of the
DiffServ network. QPIM does not mandate the use of DiffServ as a policy
amethodology.
Integrated services, together with its signaling protocol (RSVP),
provides a way for end nodes (and edge nodes) to request QoS from the
network. QPIM provides actions that control the reservation of such
requests within the network.
As both methodologies continue to evolve, QPIM does not attempt to
provide full coverage of all possible scenarios. Instead, QPIM aims to
provide policy control modeling for all major scenarios. QPIM is
designed to be extensible to allow for incorporation of control over
newly developed QoS mechanisms.
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 13
1.2.5. Interoperability for PDPs and Management Applications
Another design goal of QPIM is to facilitate interoperability among
policy systems such as PDPs and policy management applications. QPIM
accomplishes this interoperability goal by standardizing the
representation of policy. Producers and consumers of QoS policy need
only rely on QPIM-based schemata (and resulting data models) to ensure
mutual understanding and agreement on the semantics of QoS policy.
For example, suppose that a QoS policy management application, built by
vendor A writes its policies based on the standard LDAP schema that maps
from QPIM to a directory implementation using LDAP. Now assume that a
separately built PDP from vendor B also relies on this same LDAP schema
derived from QPIM. Even though these are two vendors with two different
PDPs, each may read the schema of the other and "understand" it. This is
because both the management application and the PDP were architected to
comply with the QPIM standard. The same is true with two policy
management applications. For example, vendor B's policy application may
run a validation tool that computes whether there are conflicts within
rules specified by the other vendor's policy management application.
Interoperability of QPIM producers/consumers is by definition at a high
level, and does not guarantee that the same policy will result in the
same PEP configuration. First, different PEPs will have different
capabilities and functions, which necessitate different individual
configurations even if the different PEPs are controlled by the same
policy. Second, different PDPs will also have different capabilities and
functions, and may choose to translate the high-level QPIM policy
differently depending on the functionality of the PDP, as well as on the
capabilities of the PEPs that are being controlled by the PDP. However,
the different configurations should still result in the same network
behavior as that specified by the policy rules.
1.3. Modeling Abstract QoS Policies
This section provides a discussion of QoS policy abstraction and the way
QPIM addresses this issue.
As described above, the main goal of the QPIM is to create an
information model that can be used to help bridge part of the conceptual
gap between a human policy maker and a network element that is
configured to enforce the policy. Clearly this wide gap implies several
translation levels, from the abstract to the concrete. At the abstract
end are the business QoS policy rules. Once the business rules are
known, a network administrator must interpret them as network QoS policy
and represent this QoS policy by using QPIM constructs. QPIM facilitates
a formal representation of QoS rules, thus providing the first
concretization level: formally representing humanly expressed QoS
policy.
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 14
When a human business executive defines network policy, it is usually When a human business executive defines network policy, it is usually
done using informal business terms and language. For example, a human may done using informal business terms and language. For example, a human
utter a policy statement that reads: "traffic generated by our human- may utter a policy statement that reads:
resources application should have higher priority for making it through
to its destination compared to traffic generated by people browsing the
WEB during their lunch breaks". While this statement clearly defines QoS
policy for the network, the network itself cannot enforce it. Translation
to "network terms and language" is required.
On the other end of the scale, a network element functioning as a Policy "human resources applications should have better QoS than simple
Enforcement Point (PEP, see [TERMS] for its definition), such as a web applications"
router, can be configured with specific commands that determine the
operational parameters of its inner working QoS mechanisms. For example,
the (imaginary) command "output-queue-depth = 100" may be an instruction
to a network interface card of a router to allow up to 100 packets to be
stored before subsequent packets are discarded (not forwarded). On a
different device within the same network, the same instruction may take
another form, because a different vendor built that device or it has a
different set of functions, and hence implementation, even though it is
from the same vendor. In addition, a particular PEP may not have the
ability to create queues that are longer than, say, 50 packets, which may
result in a different instruction implementing the same business policy.
Snir, Ramberg, Strassner, Cohen expires November 2001 5 This might be translated to a slightly more sophisticated form, such as:
"traffic generated by our human resources applications should have a
higher probability of communicating with its destinations
than traffic generated by people browsing the WEB using
non-mission-critical applications"
While this statement clearly defines QoS policy at the business level,
it isn't specific enough to be enforceable by network elements.
Translation to "network terms and language" is required.
On the other end of the scale, a network element functioning as a PEP,
such as a router, can be configured with specific commands that
determine the operational parameters of its inner working QoS
mechanisms. For example, the (imaginary) command "output-queue-depth =
100" may be an instruction to a network interface card of a router to
allow up to 100 packets to be stored before subsequent packets are
discarded (not forwarded). On a different device within the same
network, the same instruction may take another form, because a different
vendor built that device or it has a different set of functions, and
hence implementation, even though it is from the same vendor. In
addition, a particular PEP may not have the ability to create queues
that are longer than, say, 50 packets, which may result in a different
instruction implementing the same QoS policy.
The first example illustrates 'abstract policy', while the second The first example illustrates 'abstract policy', while the second
illustrates 'concrete configuration'. Furthermore, the first example illustrates 'concrete configuration'. Furthermore, the first example
illustrates end-to-end policy, which covers the conditioning of illustrates end-to-end policy, which covers the conditioning of
application traffic throughout the network. The second example application traffic throughout the network. The second example
illustrates configuration for a particular PEP or a set thereof. While an illustrates configuration for a particular PEP or a set thereof. While
end-to-end policy statement can only be enforced by configuration of PEPs an end-to-end policy statement can only be enforced by configuration of
in various parts of the network, the information model of policy and that PEPs in various parts of the network, the information model of policy
of the mechanisms that a PEP uses to implement that policy is vastly and that of the mechanisms that a PEP uses to implement that policy are
different. vastly different.
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 15
The translation process from abstract business policy to concrete PEP The translation process from abstract business policy to concrete PEP
configuration is roughly expressed as follows: configuration is roughly expressed as follows:
1. Informal business QoS policy is expressed by a human policy maker 1. Informal business QoS policy is expressed by a human policy maker
(e.g. "All executives' WEB requests should be prioritized") (e.g., "All executives' WEB requests should be prioritized ahead of
2. A network administrator models the informal policy by using QPIM other employees' WEB requests")
2. A network administrator analyzes the policy domain's topology and
determines the roles of particular device interfaces. A role may
be assigned to a large group of elements, which will result in
mapping a particular policy to a large group of device interfaces.
3. The network administrator models the informal policy using QPIM
constructs, thus creating a formal representation of the abstract constructs, thus creating a formal representation of the abstract
policy. (e.g. "If packet's protocol is HTTP and its destination is in policy. For example, "If a packet's protocol is HTTP and its
the 'EXECUTIVES' user group, then assign IPP 7 to the packet header"). destination is in the 'EXECUTIVES' user group, then assign IPP 7
Note that the administrator is very likely to use a particular data to the packet header".
model (e.g., LDAP schema) that is mapped to QPIM. 4. The network administrator assigns roles to the policy groups
3. The network administrator maps the abstract, formal policy to PEPs created in the previous step matching the network elements' roles
(most likely by using roles, as specified in [PCIMe, sections 2.2.4 assigned in step #2 above.
and 4.6]). 5. A PDP translates the abstract policy constructs created in step #3
4. A configuration/distribution agent (or a PDP see [TERMS] for its into device-specific configuration commands for all devices
definition) consults a device capability model to determine how to effected by the new policy (i.e., devices that have interfaces that
translate the policy into device configuration. An example for a are assigned a role matching the new policy constructs' roles). In
standards-based capability model is [QDDIM]. Note that one or more this process, the PDP consults the particular devices' capabilities
such translations are possible, depending on the particular to determine the appropriate configuration commands implementing
capabilities of a given PEP and the implementation of the system. the policy.
5. For each PEP in the network, the configuration/distribution agent 6. For each PEP in the network, the PDP (or an agent of the PDP)
configures the appropriate instructions to enforce the policy. issues the appropriate device-specific instructions necessary to
enforce the policy.
QPIM is intended to be the bridging mechanism between step #1 and step #2 QPIM, PCIM and PCIMe are used in step #3 above.
in the methodology just described.
1.1.2. Enhancing Interoperability 1.4. Rule Hierarchy
Another goal of QPIM is to facilitate interoperability among policy Policy is described by a set of policy rules that may be grouped into
systems, PDPs in particular. QPIM accomplishes its interoperability goal subsets [PCIMe]. Policy rules and policy groups can be nested within
by standardizing a representation of policy. Producers and consumers of other policy rules, providing a hierarchical policy definition. Nested
QoS policy need only rely on QPIM-based schemata (or data models) to rules are also called sub-rules, and we use both terms in this document
ensure mutual understanding and agreement on the semantics of QoS policy. interchangeably. The aggregation PolicySetComponent (defined in [PCIMe]
For example, suppose that a QoS policy management application, built by is used to represent the nesting of a policy rule or group in another
vendor A, writes its policies based on an LDAP schema that maps from QPIM policy rule.
to a directory implementation.A separately built PDP from vendor B may
then read this policy and "understand" it as both the management
application and the PDP were architected to comply with the QPIM
standard.
Snir, Ramberg, Strassner, Cohen expires November 2001 6 The hierarchical policy rule definition enhances policy readability and
reusability. Within the QoS policy information model, hierarchy is used
to model context or scope for the sub-rule actions. Within QPIM,
bandwidth allocation policy actions and drop threshold actions use this
hierarchal context. First we provide a detailed example of the use of
hierarchy in bandwidth allocation policies. The differences between flat
and hierarchical policy representation are discussed. The use of
hierarchy in drop threshold policies is described in a following
subsection. Last but not least, the restrictions on the use of rule
hierarchies within QPIM are described.
Interoperability of QPIM producers/consumers is by definition at a high Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 16
level, and does not guarantee that the same policy will result in the
same PEP configuration. First, different PEPs will have different
capabilities and functions, which necessitate different individual
configurations even if the different PEPs are controlled by the same
policy. Second, different PDPs will also have different capabilities and
functions, and may choose to translate the high-level QPIM policy
differently depending on the functionality of the PDP as well as the
capabilities of the PEPs that are being controlled by the PDP. Finally,
the same policy may be interpreted slightly differently depending on
various factors. For example, a QPIM policy rule that reads "If packet's
protocol is HTTP then assign 7 to IPP", may result in different
configurations depending on how that rule is implemented. For example, an
application recognition mechanism can be used to enforce the policy. If
the device does not supports this particular mechanism, then an alternate
mechanism must be used. For example, the packets could be classified
based on their destination TCP port.
Therefore, we define interoperability of QoS policies as the ability to 1.4.1 Use of Hierarchy Within Bandwidth Allocation Policies
specify a policy rule in a standard format. The advantage is that such a
policy can be understood by PDPs and PEPs manufactured from different
vendors having different capabilities and functionality, as well as
policy-based applications. We specifically do not require a policy to be
translated into exactly the same configuration in different PEPs. This is
why we view the above two systems that differ in the interpretation of
recognizing WEB traffic as interoperable with regard to policy. The
advantage of using QPIM policies is that incompatible device capabilities
may still be employed and controlled using the QPIM policy.
1.1.3. Intended Audiences Consider the following example where the informal policy reads:
QPIM is intended for several audiences. The following lists some of the On any interface on which these rules apply, guarantee at least 30%
intended audiences and their respective uses: of the interface bandwidth to UDP flows, and at least 40% of the
interface bandwidth to TCP flows.
1. Application vendors who build QoS policy management applications can The QoS Policy information model follows the Policy Core information
use this model as an extensible framework for defining policies to model by using roles as a way to specify the set of interfaces on which
control PEPs and PDPs in an interoperable manner this policy applies. The policy does not assume that all interfaces are
2. Developers of Policy Decision Point (PDP) systems can use this run at the same speed, or have any other property in common apart from
framework to develop interoperable policies being able to forward packets. Bandwidth is allocated between UDP and
3. QoS policy makers who seek a standardized model for expressing a TCP flows using percentages of the available interface bandwidth. Assume
formal representation of QoS policy can use this model to control PEPs that we have an available interface bandwidth of 1 Mbits/sec. Then this
of varying capabilities and functionality rule will guarantee 300Kbits/sec to UDP flows. However, if the interface
4. Builders of large organization data and knowledge bases who decide to bandwidth was instead only 64kbits/sec, then this rule would
combine QoS policy information with other networking policy correspondingly guarantee 19.2kb/sec.
information, assuming all modeling is based on [PCIM] and [PCIMe]
5. Authors of various standards may use constructs introduced in this
document to enhance their work. Authors of data models wishing to map
a storage specific technology to QPIM must use this document as well.
Snir, Ramberg, Strassner, Cohen expires November 2001 7 This policy is modeled within QPIM using two policy rules of the form:
1.2. QPIM Characteristics If (IP protocol is UDP) THEN (guarantee 30% of available BW) (1)
If (IP protocol is TCP) THEN (guarantee 40% of available BW) (2)
First, a general statement that characterizes QPIM: Assume that these two rules are grouped within a PolicySet [PCIMe]
carrying the appropriate role combination. A possible implementation of
these rules within a PEP would be to use a Weighted-Round-Robin
scheduler with 3 queues. The first queue would be used for UDP traffic,
the second queue for TCP traffic and the third queue for the rest of the
traffic. The weights of the Weighted-Round-Robin scheduler would be 30%
for the first queue, 40% for the second queue and 30% for the last
queue.
"The QoS Policy Information Model (QPIM) establishes a standard framework The actions specifying the bandwidth guarantee implicitly assume that
and constructs for specifying and representing business QoS policies. the bandwidth resource being guaranteed is the bandwidth available at
This framework consists of a set of classes and relationships, organized the interface level. A PolicyRoleCollection is a class defined in
in an object-oriented information model. It is agnostic of any specific [PCIMe] whose purpose is to identify the set of resources (in this
PDP or PEP implementation and independent of any particular QoS example, interfaces) that are assigned to a particular role. Thus, the
technology mechanism. It is intended to be used to control the type of managed elements aggregated within the PolicyRoleCollection
provisioning of end-to-end network services." defines the bandwidth resource being controlled. In our example,
interfaces are aggregated within the PolicyRoleCollection. Therefore,
the rules specify bandwidth allocation to all interfaces that match a
given role. Other behavior could be similarly defined by changing what
was aggregated within the PolicyRoleCollection.
In the rest of this section, we itemize and expand the general statement Normally, a full specification of the rules would require indicating the
presented above. direction of the traffic for which bandwidth allocation is being made.
Using the direction variable defined in [PCIMe], the rules can be
specified in the following form:
1. QPIM, as the name implies, is a QoS Policy Information Model. This If (direction is out)
means that it only models QoS concepts. These concepts are either If (IP protocol is UDP) THEN (guarantee 30% of available BW)
derived in this document, or adapted for use in modelingQoS from other If (IP protocol is TCP) THEN (guarantee 40% of available BW)
documents.
2. QPIM is an information model. As such, it is independent of any Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 17
specific data storage mechanism and access protocol. QPIM's constructs
may be mapped to various storage and data organization technologies. A
data model mapped to QPIM can be created in a relational database, an
object oriented database, an LDAP directory and more. Because QPIM is
not a schema, the reader is encouraged to focus on the conceptual
level and not on the data organization methodology. Clearly a mapped
schema would include enhancements and optimizations not appropriate in
the information-modeling realm. For example, a given association
between two classes is always modeled as an association class in QPIM.
A given schema may find it useful and efficient to model such a
relationship using a reference object attribute in a directory or a
keyforeign key relationship in a relational database.
3. QPIM is standard. The model standardizes the process of specifying where indentation is used to indicate rule nesting. To save space, we
business QoS policies. It is an interpretation and extension of the omit the direction condition from further discussion.
core policy information model as defined in [PCIM] and [PCIMe]. It
references other IETF standards (e.g. [TERMS], [DIFFSERV] and others)
and is meant to enhance interoperability of QoS systems from different
vendors.
QPIM establishes a conceptual framework by fully and closely following Rule nesting provides the ability to further refine the scope of
the core policy framework as specified in [PCIM] and [PCIMe]. QPIM bandwidth allocation within a given traffic class forwarded via these
inherits all of its constructs from the core model, providing QoS interfaces. The example below adds two nested rules to refine bandwidth
interpretation and extensions where necessary. allocation for UDP and TCP applications.
4. QPIM is object oriented. The modeling methodology is based on UML If (IP protocol is UDP) THEN (guarantee 30% of available BW) (1)
(Unified Modeling Language [UML]. This is a ubiquitous modeling method If (protocol is TFTP) THEN (guarantee 10% of available BW) (1a)
that is easy to understand and read. In addition, UML-based models If (protocol is NFS) THEN (guarantee 40% of available BW) (1b)
lend themselves to further extensions and natural progression toward If (IP protocol is TCP) THEN (guarantee 40% of available BW) (2)
detailed data models. If (protocol is HTTP) THEN guarantee 20% of available BW) (2a)
If (protocol is FTP) THEN (guarantee 30% of available BW) (2b)
Snir, Ramberg, Strassner, Cohen expires November 2001 8 Subrules 1a and 1b specify bandwidth allocation for UDP applications.
The total bandwidth resource being partitioned among UDP applications is
the bandwidth available for the UDP traffic class (i.e., 30%), not the
total bandwidth available at the interface level. Furthermore, TFTP and
NFS are guaranteed to get at least 10% and 40% of the total available
bandwidth for UDP, while other UDP applications aren't guaranteed to
receive anything. Thus, TFTP and NFS are guaranteed to get at least 3%
and 12% of the total bandwidth. Similar logic applies to the TCP
applications.
5. QPIM is a formal model. It expresses its concepts by describing and The point of this section will be to show that a hierarchical policy
defining classes and inter-class associations. Classes are formal representation enables a finer level of granularity for bandwidth
definitions of major concepts. For example, the concept of a traffic allocation to be specified than is otherwise available using a non-
profile is represented by the QosPolicyTrfcProf (abstract) class. A hierarchical policy representation. To see this, let's compare this set
derivative of this class provides several attributes to describe the of rules with a non-hierarchical (flat) rule representation. In the non-
traffic in terms of average rate and other characteristics. hierarchical representation, the guaranteed bandwidth for TFTP flows is
Associations represent relationships among instances of different calculated by taking 10% of the bandwidth guaranteed to UDP flows,
classes or the same class. For example, the association resulting in 3% of the total interface bandwidth guarantee.
QoSPolicyViolateAction links a certain restriction on traffic
(represented by an instance of the QoSPolicyPoliceAction class) to an
action to be taken when the restriction is violated.
6. QPIM is abstract. The model is aimed at the formalization of humanly If (UDP AND TFTP) THEN (guarantee 3% of available BW) (1a)
expressed business QoS policies. For example, QPIM provides the means If (UDP AND NFS) THEN (guarantee 12% of available BW) (1b)
of expressing formally a business policy that states: "In our network, If (other UDP APPs) THEN (guarantee 15% of available BW) (1c)
IP telephony should receive the same service quality as that of our If (TCP AND HTTP) THEN guarantee 8% of available BW) (2a)
legacy phone systems". QPIM provides the topmost link from the If (TCP AND FTP) THEN (guarantee 12% of available BW) (2b)
abstract business policy to the concrete device implementation by If (other TCP APPs) THEN (guarantee 20% of available BW) (2c)
expressing the abstract business policy in high-level networking
terms. QPIM compliant tools can be built to further concretize the
high-level QoS policies defined in QPIM terms so that actual network
elements (PEPs) can be configured to enforce the abstract business
policy.
7. QPIM is QoS technology-agnostic, as it assumes no particular mechanism Are these two representations identical? No, bandwidth allocation is not
(e.g., class-based weighted fair queuing) for policy enforcement. For the same. For example, within the hierarchical representation, UDP
example, a certain policy may require that traffic adhere to a given applications are guaranteed 30% of the bandwidth. Suppose a single UDP
traffic profile. The traffic profile itself can be represented by an flow of an application different from NFS or TFTP is running. This
instance of the QosPolicyTrfcProf class. The properties of the profile application would be guaranteed 30% of the interface bandwidth in the
class may include an attribute representing the average rate of hierarchical representation but only 15% of the interface bandwidth in
traffic in units of bits per second. However, QPIM neither describes the flat representation.
nor mandates a mechanism to perform the measuring mechanism itself.
Specifying such mechanisms is in the realm of network modeling, not
policy modeling.
Though a particular QoS mechanism (e.g., class-based weighted fair A two stage scheduler is best modeled by a hierarchical representation
queuing) is generic to many types of devices, individual devices may whereas a flat representation may be realized by a non-hierarchical
implement this generic mechanism differently. This necessitates a scheduler.
device-independent view of controlling QoS mechanisms, which is
precisely what QPIM is intended for. A single QPIM policy can be
translated into different configurations of different devices. For
example, a network interface card that can be configured to implement
several output queues and assign size and bandwidth allocation
parameters to each of them is a concrete element whose configuration
can be controlled with QPIM policies.
Snir, Ramberg, Strassner, Cohen expires November 2001 9 Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 18
8. QPIM adheres to and interprets the two predominant QoS paradigms: A schematic hierarchical Weighted-Round-Robin scheduler implementation
Differentiated (DiffServ) Services and Integrated Services (IntServ). that supports the hierarchical rule representation is described below.
While both DiffServ and IntServ inherently model technology, the
mechanisms implementing those technologies are not specified and are
left to the implementer's interpretation. DiffServ and IntServ are
described in [DIFFSERV] and [INTSERV], respectively. The term RSVP
refers to a protocol developed to implement IntServ [RSVP]. The terms
IntServ and RSVP are sometime used interchangeably.
9. QPIM is a network-end-to-end model. This means that QPIM policies can --UDP AND TFTP queue--10%
describe the QoS allocated to traffic throughout the network. QPIM --UDP AND NFS queue--40%-Scheduler-30%--+
does not represent explicitly network topological concepts. Section --Other UDP queue--50% A1 |
4.6 of [PCIMe] explains a role based mechanism that can be used for |
mapping policies to PEPs. Neither [PCIM], [PCIMe] nor [QPIM] require a --TCP AND HTTP queue--20% |
particular topological view of the network in order to express --TCP AND FTP queue--30%-Scheduler-40%--Scheduler--Interface
abstract policy. --Other TCP queue--50% A2 | B
|
------------Non UDP/TCP traffic-----30%--+
1.3. QPIM and Other Published Standards Scheduler A1 extracts packets from the 3 UDP queues according to the
weight specified by the UDP sub-rule policy. Scheduler A2 extracts
packets from the 3 TCP queues specified by the TCP sub-rule policy. The
second stage scheduler B schedules between UDP, TCP and all other
traffic according to the policy specified in the top most rule level.
QPIM makes extensive use of the concepts and constructs that are Another difference between the flat and hierarchical rule representation
introduced by [PCIM] and [PCIMe]. The entire QPIM class hierarchy is is the actual division of bandwidth above the minimal bandwidth
derived from [PCIM] and [PCIMe] classes. The concepts of policy, policy guarantee. Suppose two high rate streams are being forwarded via this
groups, policy conditions, reusable objects values and variables are used interface: an HTTP stream and an NFS stream. Suppose that the rate of
in QPIM directly. QPIM only introduces extensions where QoS actions, each flow is far beyond the capacity of the interface. In the flat
values and variables are necessary to add QoS specific semantics to the scheduler implementation, the ratio between the weights is 8:12 (i.e.,
framework defined by [PCIM] and [PCIMe]. HTTP:NFS), and therefore HTTP stream would consume 40% of the bandwidth
while NFS would consume 60% of the bandwidth. In the hierarchical
scheduler implementation the only scheduler that has two queues filled
is scheduler B, therefore the ratio between the HTTP (TCP) stream and
the NFS (UDP) stream would be 30:40, and therefore the HTTP stream would
consume approximately 42% of the interface bandwidth while NFS would
consume 58% of the interface bandwidth. In both cases both HTTP and NFS
streams got more than the minimal guaranteed bandwidth, but the actual
rates forwarded via the interface differ.
By modeling the information of both predominant QoS paradigms, DiffServ The conclusion is that hierarchical policy representation provides
and IntServ, QPIM unifies the two methodologies using a single class additional structure and context beyond the flat policy representation.
inheritance tree, thus allowing a single context for thinking about QoS Furthermore, policies specifying bandwidth allocation using rule
policy. hierarchies should be enforced using hierarchical schedulers where the
rule hierarchy level is mapped to the hierarchical scheduler level.
Companion documents (e.g., [QoSSCHEMA]) define the mapping of QPIM's 1.4.2. Use of Rule Hierarchy to Describe Drop Threshold Policies
classes to specific data models (schemata). For example, [QoSSCHEMA]
defines how to map the data in this information model to a form that can
be stored in a directory that uses LDAPv3 as its access protocol.
QPIM adheres to terminology as defined in [TERMS]. Two major resources govern the per hop behavior in each node. The
bandwidth allocation resource governs the forwarding behavior of each
traffic class. A scheduler priority and weights are controlled by the
bandwidth allocation policies, as well as the (minimal) number of queues
needed for traffic separation. A second resource, which is not
controlled by bandwidth allocation policies, is the queuing length and
drop behavior. For this purpose, queue length and threshold policies are
used.
QPIM intentionally avoids references to documents that present network Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 19
models. A network model is the OBJECT of policy. QPIM models the SUBJECT
of policy. The latter distinction makes it inappropriate for QPIM to
model the actual network. An example for network modeling is available in
[QDDIM], a document that models QoS device data path and capabilities.
Snir, Ramberg, Strassner, Cohen expires November 2001 10 Rule hierarchy is used to describe the context on which thresholds act.
The policy rule's condition describes the traffic class and the rule's
actions describe the bandwidth allocation, the forwarding priority and
the queue length. If the traffic class contains different drop
precedence sub-classes that require different thresholds within the same
queue, the sub-rules actions describe these thresholds.
Below is an example of the use of rule nesting for threshold control
purposes. Let's look at the following rules:
If (protocol is FTP) THEN (guarantee 10% of available BW)
(queue length equals 40 packets)
(drop technique is random)
if (src-ip is from net 2.x.x.x) THEN min threshold = 30%
max threshold = 70%
if (src-ip is from net 3.x.x.x) THEN min threshold = 40%
max threshold = 90%
if (all other) THEN min threshold = 20%
max threshold = 60%
The rule describes the bandwidth allocation, the queue length and the
drop technique assigned to FTP flows. The sub-rules describe the drop
threshold priorities within those FTP flows. FTP packets received from
all networks apart from networks 2.x.x.x and 3.x.x.x are randomly
dropped when the queue threshold for FTP flows accumulates to 20% of the
queue length. Once the queue fills to 60%, all these packets are dropped
before queuing. The two other sub rules provide other thresholds for FTP
packets coming from the specified two subnets. The Assured Forwarding
per hop behavior (AF) is another good example of the use of hierarchy to
describe the different drop preferences within a traffic class. This
example is provided in a later section.
1.4.3. Restrictions of the Use of Hierarchy Within QPIM
Rule nesting is used within QPIM for two important purposes:
1) Enhance clarity, readability and reusability.
2) Provide hierarchical context for actions.
The second point captures the ability to specify context for bandwidth
allocation, as well as providing context for drop threshold policies.
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 20
When is a hierarchy level supposed to specify the bandwidth allocation
context, when is the hierarchy used for specifying the drop threshold
context, and when is it used merely for clarity and reusability? The
answer depends entirely on the actions. Bandwidth control actions within
a sub-rule specify how the bandwidth allocated to the traffic class
determined by the rule's condition clause should be further divided
among the sub-rules. Drop threshold actions control the traffic class's
queue drop behavior for each of the sub-rules. The bandwidth control
actions have an implicit pointer saying: the bandwidth allocation is
relative to the bandwidth resources defined by the higher level rule.
Drop threshold actions have an implicit pointer saying: the thresholds
are taken from the queue resources defined by the higher level rule.
Other actions do not have such an implicit pointer, and for these
actions hierarchy is used only for reusability and readability purposes.
Each rule that includes a bandwidth allocation action implies that a
queue should be allocated to the traffic class defined by the rule's
condition clause. Therefore, once a bandwidth allocation action exists
within the actions of a sub-rule, a threshold action within this sub-
rule cannot refer to thresholds of the parent rule's queue. Instead, it
must refer to the queue of the sub-rule itself. Therefore, in order to
have a clear and unambiguous definition, refinement of thresholds and
refinements of bandwidth allocations within sub-rules should be avoided.
If both refinements are needed for the same rule, threshold refinements
and bandwidth refinements rules should each be aggregated to a separate
group, and these groups should be aggregated under the policy rule,
using the PolicySetComponent aggregation.
1.5. Intended Audiences
QPIM is intended for several audiences. The following lists some of the
intended audiences and their respective uses:
1. Developers of QoS policy management applications can use this
model as an extensible framework for defining policies to
control PEPs and PDPs in an interoperable manner.
2. Developers of Policy Decision Point (PDP) systems built to
control resource allocation signaled by RSVP requests.
3. Developers of Policy Decision Points (PDP) systems built to create
QoS configuration for PEPs.
4. Builders of large organization data and knowledge bases who decide
to combine QoS policy information with other networking policy
information, assuming all modeling is based on [PCIM] and [PCIMe].
5. Authors of various standards may use constructs introduced in this
document to enhance their work. Authors of data models wishing to
map a storage specific technology to QPIM must use this document
as well.
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 21
2. Class Hierarchies 2. Class Hierarchies
2.1. Inheritance Hierarchy 2.1. Inheritance Hierarchy
QPIM's inheritance hierarchy is rooted in [PCIM] and [PCIMe]. Figures 1 QPIM's class and association inheritance hierarchies are rooted in
and 2 depict the QPIM inheritance hierarchy while noting its [PCIM] and [PCIMe]. Figures 1 and 2 depict these QPIM inheritance
relationships to [PCIM] and [PCIMe] classes. Figure 1 shows the QPIM hierarchies, while noting their relationships to [PCIM] and
inheritance hierarchy,. [PCIMe]classes. Note that many other classes used to form QPIM policies,
such as SimplePolicyCondition, are defined in [PCIM] and [PCIMe]. Thus,
the following figures do NOT represent ALL necessary classes and
relationships for defining QPIM policies. Rather, the designer using
QPIM should use appropriate classes and relationships from [PCIM] and
[PCIMe] in conjunction with those defined below.
[ManagedElement] (abstract, PCIM) [ManagedElement] (abstract, PCIM)
| |
+--Policy (abstract, PCIM) +--Policy (abstract, PCIM)
| | | |
| +---PolicyAction (abstract, PCIM) | +---PolicyAction (abstract, PCIM)
| | | | | |
| | +---SimplePolicyAction (PCIMe) | | +---SimplePolicyAction (PCIMe)
| | | | | | | |
| | | +---QoSPolicyRSVPSimpleAction (QPIM) | | | +---QoSPolicyRSVPSimpleAction (QPIM)
| | | | | |
| | +---QoSPolicyDiscardAction (QPIM) | | +---QoSPolicyDiscardAction (QPIM)
| | | | | |
| | +---QoSPolicyAdmissionAction (abstract, QPIM) | | +---QoSPolicyAdmissionAction (abstract, QPIM)
| | | | | | | |
| | | +---QoSPolicyPoliceAction (QPIM) | | | +---QoSPolicyPoliceAction (QPIM)
| | | | | | | |
| | | +---QoSPolicyShapeActionAction (QPIM) | | | +---QoSPolicyShapeAction (QPIM)
| | | | | | | |
| | | +---QoSPolicyRSVPAdmissionAction (QPIM) | | | +---QoSPolicyRSVPAdmissionAction (QPIM)
| | | | | |
| | +---QosPolicyPHBAction (abstract, QPIM) | | +---QoSPolicyPHBAction (abstract, QPIM)
| | | | | |
| | +---QoSPolicyBandwidthAction (QPIM) | | +---QoSPolicyBandwidthAction (QPIM)
| | | | | |
| | +---QoSPolicyCongestionControlAction (QPIM) | | +---QoSPolicyCongestionControlAction (QPIM)
| | | |
| +---QosPolicyTrfcProf (abstract, QPIM) | +---QoSPolicyTrfcProf (abstract, QPIM)
| | | | | |
| | +---QosPolicyTokenBucketTrfcProf (QPIM) | | +---QoSPolicyTokenBucketTrfcProf (QPIM)
| | | | | |
| | +---QosPolicyIntServTrfcProf (QPIM) | | +---QoSPolicyIntServTrfcProf (QPIM)
| | | |
(continued on the next page) (continued on the next page)
Snir, Ramberg, Strassner, Cohen expires November 2001 11 Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 22
(continued from the previous page) (continued from the previous page)
[ManagedElement] (abstract, PCIM, repeated for convenience) [ManagedElement] (abstract, PCIM, repeated for convenience)
| |
+--Policy (abstract, PCIM, repeated for convenience) +--Policy (abstract, PCIM, repeated for convenience)
| | | |
| +---PolicyVariable (abstract, PCIMe) | +---PolicyVariable (abstract, PCIMe)
| | | | | |
| | +---PolicyImplicitVariable (abstract, PCIMe) | | +---PolicyImplicitVariable (abstract, PCIMe)
skipping to change at line 592 skipping to change at line 1159
| | +---QoSPolicyRSVPApplicationVariable (QPIM) | | +---QoSPolicyRSVPApplicationVariable (QPIM)
| | | | | |
| | +---QoSPolicyRSVPAuthMethodVariable (QPIM) | | +---QoSPolicyRSVPAuthMethodVariable (QPIM)
| | | |
| +---PolicyValue (abstract, PCIMe) | +---PolicyValue (abstract, PCIMe)
| | | | | |
| | +---QoSPolicyDNValue (QPIM) | | +---QoSPolicyDNValue (QPIM)
| | | | | |
| | +---QoSPolicyAttributeValue (QPIM) | | +---QoSPolicyAttributeValue (QPIM)
Figure 1. The QPIM Inheritance Hierarchy Figure 1. The QPIM Class Inheritance Hierarchy
Snir, Ramberg, Strassner, Cohen expires November 2001 12 Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 23
2.2. Relationship Hierarchy 2.2. Relationship Hierarchy
Figure 2 shows the QPIM association hierarchy. Figure 2 shows the QPIM relationship hierarchy.
[unrooted] (abstract, PCIM) [unrooted] (abstract, PCIM)
| |
+---Dependency (abstract) +---Dependency (abstract)
| | | |
| +--- QosPolicyTrfcProfInAdmissionAction (QPIM) | +--- QoSPolicyTrfcProfInAdmissionAction (QPIM)
| | | |
| +--- QoSPolicyConformAction (QPIM) | +--- QoSPolicyConformAction (QPIM)
| | | |
| +--- QoSPolicyExceedAction (QPIM) | +--- QoSPolicyExceedAction (QPIM)
| | | |
| +--- QoSPolicyViolateAction (QPIM) | +--- QoSPolicyViolateAction (QPIM)
| |
| +--- PolicyVariableInSimplePolicyAction
| | |
| | + QoSPolicyRSVPVariableInRSVPSimplePolicyAction
Figure 2. The QPIM Association Hierarchy Figure 2. The QPIM Association Class Inheritance Hierarchy
Snir, Ramberg, Strassner, Cohen expires November 2001 13 Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 24
3. QoS Actions 3. QoS Actions
This section describes the QoS actions that are modeled by QPIM. QoS This section describes the QoS actions that are modeled by QPIM. QoS
actions are policy enforced network behaviors that are specified for actions are policy enforced network behaviors that are specified for
traffic selected by QoS conditions. QoS actions are modeled using the traffic selected by QoS conditions. QoS actions are modeled using the
classes PolicyAction (defined in [PCIM]), SimplePolicyAction (defined in classes PolicyAction (defined in [PCIM]), SimplePolicyAction (defined in
[PCIMe]) and several QoS actions defined in this document (described [PCIMe]) and several QoS actions defined in this document that are
below). derived from both of these classes, which are described below.
Note that there is no discussion of PolicyRule, PolicyGroup, or
different types of PolicyCondition classes in this document. This is
because these classes are fully specified in [PCIM] and [PCIMe].
3.1 Overview 3.1 Overview
QoS policy based systems allow the network administrator to specify a set QoS policy based systems allow the network administrator to specify a
of rules that control both the selection of the flows that need to be set of rules that control both the selection of the flows that need to
provided with a preferred forwarding treatment, as well as specifying the be provided with a preferred forwarding treatment, as well as specifying
specific set of preferred forwarding behaviors. QPIM provides an the specific set of preferred forwarding behaviors. QPIM provides an
information model for specifying such a set of rules. information model for specifying such a set of rules.
QoS policy rules allow controlling environments in which RSVP signaling QoS policy rules enable controlling environments in which RSVP signaling
is used to request different forwarding treatment for different traffic is used to request different forwarding treatment for different traffic
types from the network as well as environments where no signaling is types from the network, as well as environments where no signaling is
used, but preferred treatment is desired for some (not all) traffic. QoS used, but preferred treatment is desired for some (but not all) traffic
policy rules allow controlling environments where strict QoS guarantees types. QoS policy rules also allow controlling environments where strict
are provided to individual flows as well as environments where QoS is QoS guarantees are provided to individual flows, as well as environments
provided to flow aggregates. QoS actions allow a PDP or a PEP to where QoS is provided to flow aggregates. QoS actions allow a PDP or a
determine which RSVP requests should be admitted because they satisfy a PEP to determine which RSVP requests should be admitted before network
given policy, before network resources are allocated. They allow control resources are allocated. QoS actions allow control of the RSVP signaling
of the RSVP signaling content itself, as well as differentiation between content itself, as well as differentiation between priorities of RSVP
priorities of requests. QoS actions also allow specification of the requests. QoS actions allow controlling the Differentiated Service edge
Differential Service edge enforcement including policing, shaping and enforcement including policing, shaping and marking, as well as the per-
marking, as well as the per-hop behaviors used in the network core. hop behaviors used in the network core. Finally, QoS actions can be used
Finally, QoS actions can be used to control mapping of RSVP request at to control mapping of RSVP requests at the edge of a differentiated
the edge of a differential service cloud into per hop behaviors. service cloud into per hop behaviors.
Four groups of actions are derived from action classes defined in [PCIM] Four groups of actions are derived from action classes defined in [PCIM]
and [PCIMe]. The first QoS action group contains a single action, and [PCIMe]. The first QoS action group contains a single action,
QoSPolicyRSVPSimpleAction. This action is used for both signal control QoSPolicyRSVPSimpleAction. This action is used for both RSVP signal
and install actions depending on a type attribute. The second QoS action control and install actions. The second QoS action group determines
group determines whether a flow or class of flows should be admitted. whether a flow or class of flows should be admitted. This is done by
This is done by specifying an appropriate traffic profile. These set of specifying an appropriate traffic profile using the QoSPolicyTrfcProf
actions are called QoS admission actions. The third group of actions class and its subclasses. This set of actions also includes QoS
control bandwidth allocation and congestion control differentiations, admission control actions, which use the QoSPolicyAdmissionAction class
which together specify the per-hop behavior forwarding treatment. The and its subclasses. The third group of actions control bandwidth
forth QoS action is unconditional packet discard action. This action is allocation and congestion control differentiations, which together
used either by itself or as a building block of the specify the per-hop behavior forwarding treatment. This group of actions
QoSPolicyPoliceAction. includes the QoSPolicyPHBAction class and its subclasses. The fourth QoS
action is an unconditional packet discard action, which uses the
QoSPolicyDiscardAction class. This action is used either by itself or as
a building block of the QoSPolicyPoliceAction.
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 25
Note that some QoS actions are not directly modeled. Instead, they are Note that some QoS actions are not directly modeled. Instead, they are
modeled by using the class SimplePolicyAction with the appropriate modeled by using the class SimplePolicyAction with the appropriate
associations. For example, the three marking actions (DSCP, IPP and CoS) associations. For example, the three marking actions (DSCP, IPP and CoS)
are modeled by using the SimplePolicyAction class, associating it with are modeled by using the SimplePolicyAction class, and associating that
variables and values of the appropriate type. class with variables and values of the appropriate type defined in
[PCIMe].
Snir, Ramberg, Strassner, Cohen expires November 2001 14
3.2 RSVP Policy Actions 3.2 RSVP Policy Actions
There are three types of decisions a PDP (either remote or within a PEP) There are three types of decisions a PDP (either remote or within a PEP)
can make when it evaluates an RSVP request: can make when it evaluates an RSVP request:
1. Admit or reject the request 1. Admit or reject the request
2. Use admission parameters to decide whether to admit the request or 2. Add or modify the request admission parameters
not 3. Modify the RSVP signaling content
3. Use signaling parameters to decide how to modify the RSVP signaling
messages
The COPS for RSVP [RFC2749] specification uses different Decision object The COPS for RSVP [RFC2749] specification uses different Decision object
types to model each of these decisions. QPIM follows the COPS types to model each of these decisions. QPIM follows the COPS for RSVP
specification and models each decision using a different action class. specification and models each decision using a different action class.
The QoSPolicyRSVPAdmissionAction with its associated
QosPolicyIntServTrfcProf determine whether to accept or reject a given
RSVP request by comparing the RSVP request's TSPEC or RSPEC parameters
against the traffic profile. For a full description of the comparison
method, see section 4, which describes traffic profiles in more detail.
Using the QoSPolicyRSVPAdmissionAction, a limit on the number of admitted The QoSPolicyRSVPAdmissionAction controls the Decision Command and
reservations can be enforced as well. The QoSPolicyRSVPAdmissionAction Decision Flags objects used within COPS for RSVP. The
can specify that a set of RSVP requests will be accepted yet a warning QoSPolicyRSVPAdmissionAction class, with its associated
message would be sent to the RSVP end points. The QoSPolicyIntServTrfcProf class, is used to determine whether to accept
QoSPolicyRSVPAdmissionAction controls the Decision Command and Decision or reject a given RSVP request by comparing the RSVP request's TSPEC or
Flags objects used within COPS for RSVP. RSPEC parameters against the traffic profile specified by the
QoSPolicyIntServTrfcProf. For a full description of the comparison
method, see section 4. Following the COPS for RSVP specification, the
admission decision has an option to both accept the request and send a
warning to the requester. The QoSPolicyRSVPAdmissionAction can be used
to limit the number of admitted reservations as well.
The class QoSPolicyRSVPSimpleAction, which is derived from the The class QoSPolicyRSVPSimpleAction, which is derived from the
PolicySimpleAction class [PCIMe], can be used to specify RSVP decisions. PolicySimpleAction class [PCIMe], can be used to control the two other
COPS RSVP decision types. The property qpRSVPActionType designates the
The property qpRSVPActionType designates the instance of the class to be instance of the class to be either of type 'REPLACE', 'STATELESS', or
either of type 'REPLACE', 'STATELESS', or both. For instances carrying a both ('REPLACEANDSTATELESS'). For instances carrying a qpRSVPActionType
qpRSVPActionType property value of 'REPLACE', the action is interpreted property value of 'REPLACE', the action is interpreted as a COPS Replace
as a COPS Replace Decision, controlling the contents of the RSVP message. Decision, controlling the contents of the RSVP message. For instances
For instances carrying a qpRSVPActionType property value of 'STATELESS', carrying a qpRSVPActionType property value of 'STATELESS', the action is
the action is interpreted as a COPS Stateless Decision, controlling the interpreted as a COPS Stateless Decision, controlling the admission
admission parameters. If both of these actions are required, this can be parameters. If both of these actions are required, this can be done by
done by assigning both of the two qpRSVPActionType values, since it is a assigning the value REPLACEANDSTATELESS to the qpRSVPActionType
multi-valued property. property.
This class is modeled to represent the COPS for RSVP Replace and This class is modeled to represent the COPS for RSVP Replace and
Stateless decisions. This similarity allows future use of these COPS Stateless decisions. This similarity allows future use of these COPS
decisions to be directly controlled by a QoSPolicySimpleAction. The only decisions to be directly controlled by a QoSPolicySimpleAction. The only
required extension might be the definition of a new RSVP variable. required extension might be the definition of a new RSVP variable.
Snir, Ramberg, Strassner, Cohen expires November 2001 15 Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 26
Example: Controlling COPS Stateless Decision 3.2.1. Example: Controlling COPS Stateless Decision
The QoSPolicyRSVPSimpleAction allows the specification of admission The QoSPolicyRSVPSimpleAction allows the specification of admission
parameters. It allows specification of the preemption priority [RFC2751] parameters. It allows specification of the preemption priority [RFC2751]
of a given RSVP Reservation request. Using the preemption priority value, of a given RSVP Reservation request. Using the preemption priority
the PEP can determine the importance of a Reservation compared with value, the PEP can determine the importance of a Reservation compared
already admitted reservations, and if necessary can preempt lower with already admitted reservations, and if necessary can preempt lower
priority reservations to make room for the higher priority one. This priority reservations to make room for the higher priority one. This
class can also be used to control mapping of RSVP requests to a class can also be used to control mapping of RSVP requests to a
differentiated services domain by setting the QoSPolicyRSVPDSCPVariable differentiated services domain by setting the
to the required value. This instructs the PEP to mark traffic matching QoSPolicyRSVPDCLASSVariable to the required value. This instructs the
the Session and Sender specifications carried in an RSVP request to a PEP to mark traffic matching the Session and Sender specifications
given DSCP value. carried in an RSVP request to a given DSCP value.
Example: Controlling the COPS Replace Decision 3.2.2. Example: Controlling the COPS Replace Decision
A Policy system should be able to control the information carried in the A Policy system should be able to control the information carried in the
RSVP messages. The QoSPolicyRSVPSimpleAction allows control of the RSVP messages. The QoSPolicyRSVPSimpleAction allows control of the
content of RSVP signaling messages. An RSVP message can carry a content of RSVP signaling messages. An RSVP message can carry a
preemption policy object [RFC2751] specifying the priority of the preemption policy object [RFC2751] specifying the priority of the
reservation request in comparison to other requests. An RSVP message can reservation request in comparison to other requests. An RSVP message can
also carry a policy object for authentication purposes. An RSVP message also carry a policy object for authentication purposes. An RSVP message
can carry a DCLASS [DCLASS] object that specifies to the receiver or can carry a DCLASS [DCLASS] object that specifies to the receiver or
sender the particular DSCP value that should be set on the data traffic. sender the particular DSCP value that should be set on the data traffic.
A COPS for RSVP Replacement Data Decision controls the content of the A COPS for RSVP Replacement Data Decision controls the content of the
RSVP message by specifying a set of RSVP objects replacing or removing RSVP message by specifying a set of RSVP objects replacing or removing
the existing ones. the existing ones.
3.3 Provisioning Policy Actions 3.3 Provisioning Policy Actions
The differentiated Service Architecture [DIFFSERV] was designed to The differentiated Service Architecture [DIFFSERV] was designed to
provide a scalable QoS differentiation without requiring any signaling provide a scalable QoS differentiation without requiring any signaling
protocols running between the hosts and the network. The QoS actions protocols running between the hosts and the network. The QoS actions
modeled in QPIM can be used to control all the building blocks of the modeled in QPIM can be used to control all of the building blocks of the
Differentiated Service architecture, including per-hop behaviors, edge Differentiated Service architecture, including per-hop behaviors, edge
classification, and policing and shaping, without a need to specify the classification, and policing and shaping, without a need to specify the
datapath mechanisms used by PEP implementations. This provides an datapath mechanisms used by PEP implementations. This provides an
abstraction level hiding the unnecessary details and allowing the network abstraction level hiding the unnecessary details and allowing the
administrator to write rules that express the network requirements in a network administrator to write rules that express the network
more natural form. In this architecture, as no signaling between the end requirements in a more natural form. In this architecture, as no
host and the network occur before the sender starts sending information, signaling between the end host and the network occurs before the sender
the QoS mechanisms should be setup in advance. This usually means that starts sending information, the QoS mechanisms should be set up in
PEPs need to be provisioned with the set of policy rules in advance. advance. This usually means that PEPs need to be provisioned with the
Policing and Shaping actions are modeled as sub-classes of the QoS set of policy rules in advance.
admission action. DSCP and CoS marking are modeled as sub-classes of the
simplePolicyAction class. Bandwidth allocation, scheduling and congestion
control actions are modeled as sub-classes of the QoS PHB action.
Snir, Ramberg, Strassner, Cohen expires November 2001 16 Policing and Shaping actions are modeled as subclasses of the QoS
admission action. DSCP and CoS marking are modeled by using the
SimplePolicyAction ([PCIMe]) class associated with the appropriate
variables and values. Bandwidth allocation and congestion control
actions are modeled as subclasses of the QpQPolicyPHBAction, which is
itself a subclass PolicyAction class ([PCIM])
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 27
3.3.1. Admission Actions: Controlling Policers and Shapers 3.3.1. Admission Actions: Controlling Policers and Shapers
All Admission Actions have in common an association to a traffic profile Admission Actions (QoSPolicyAdmissionAction and its subclasses) are used
and a scope property that determines whether the traffic profile is to police and/or shape traffic.
compared against the rate parameters of each flow or against the
aggregate rate of all flows that match the rule's condition. For example, Each Admission Action is bound to a traffic profile (QoSPolicyTrfcProf)
using two provisioned policer actions the following policies can be via the QoSPolicyTrfcProfInAdmissionAction association. The traffic
profile is used to meter traffic for purposes of policing or shaping.
An Admission Action carries a scope property (qpAdmissionScope) that is
used to determine whether the action controls individual traffic flows
or aggregate traffic classes. The concepts of "flow" and "traffic class"
are explained in [DIFFSERV] using the terms 'microflow' and 'traffic
stream'. Roughly speaking, a flow is a set of packets carrying an IP
header that has the same values for source IP, destination IP, protocol
and layer 4 source and destination ports. A traffic class is a set of
flows. In QPIM, simple and compound conditions can identify flows and/or
traffic classes by using Boolean terms over the values of IP header
fields, including the value of the ToS byte.
Thus, the interpretation of the scope property is as follows: If the
value of the scope property is 0 (per-flow), each (micro) flow that can
be positively matched with the rule's condition is metered and policed
individually. If the value of the scope property is 1 (per-class), all
flows matched with the rule's condition are metered as a single
aggregate and policed together.
The following example illustrates the use of the scope property. Using
two provisioned policing actions, the following policies can be
enforced: enforced:
- Make sure that each HTTP flow will not exceed 64kb/s - Make sure that each HTTP flow will not exceed 64kb/s
- Make sure that the aggregate rate of all HTTP flows will not - Make sure that the aggregate rate of all HTTP flows will not
exceed 512Kb/s exceed 512Kb/s
Both policies are modeled using the same QoSPolicyPoliceAction. The first Both policies are modeled using the same class QoSPolicyPoliceAction
policy has its scope property set to 'flow', while the second policy has (derived from QoSPolicyAdmissionAction). The first policy has its scope
its scope property set to 'class'. The two policies are modeled using a property set to 'flow', while the second policy has its scope property
rule with two police actions that, in a pseudo formal definition, looks set to 'class'. The two policies are modeled using a rule with two
like the following: police actions that, in a pseudo-formal definition, looks like the
following:
If (HTTP) Action1=police, Traffic Profile1=64kb/s, Scope1=flow If (HTTP) Action1=police, Traffic Profile1=64kb/s, Scope1=flow
Action2=police, Traffic Profile2=512kb/s, Scope2=class Action2=police, Traffic Profile2=512kb/s, Scope2=class
The provisioned policer action QoSPolicyPoliceAction has 3 associations, The provisioned policing action QoSPolicyPoliceAction has three
QoSPolicyConformAction, QoSPolicyExceedAction and QoSPolicyViolateAction. associations, QoSPolicyConformAction, QoSPolicyExceedAction and
The policer action is associated with a three-level token bucket traffic QoSPolicyViolateAction.
profile carrying rate, burst and excess-burst parameters. Traffic
measured by a meter can be classified as conforming traffic when the
metered rate is below the rate defined by the traffic profile, as excess
traffic when the metered traffic is above the normal burst and below the
excess burst size, and violating traffic when rate is above the maximum
excess burst.
The [DIFF-MIB] defines a two-level meter, and provides a means to combine Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 28
two-level meters into more complex meters. In this document, a three-
level traffic profile is defined. This allows construction of both two-
level meters as well as providing an easier definition for three-level
meters needed for creating AF [AF] provisioning actions.
A policer action with a non-specified conform action implies that To accomplish the desired result stated above, two possible modeling
conforming traffic should not be modified. A policer action with an techniques may be used: The two actions can be part of a single policy
associated three-level traffic profile that does not specify an excess rule using two PolicyActionInPolicyRule [PCIM] associations. In this
action implies that the excess traffic should be treated as either case the ExecutionStrategy property of the PolicyRule class [PCIMe]
violating or conforming traffic according to some algorithm suitable for SHOULD be set to "Do All" so that both individual flows and aggregate
the enforcement of the rule. For example, the final enforcement of such a streams are policed.
rule may be the use of a random function similar to RED to determine
whether traffic is conforming or violating. A policer action with a
three-level traffic profile that specifies an exceed action but does not
specify a violate action implies that violate action is identical to the
specified exceed action.
Snir, Ramberg, Strassner, Cohen expires November 2001 17 Alternatively, Action1 and Action2 could be aggregated in a
CompundPolicyAction instance using the PolicyActionInPolicyAction
aggregations [PCIMe]. In this case, in order for both individual flows
and aggregate traffic classes to be policed, the ExecutionStrategy
property of the CompoundPolicyAction class [PCIMe] SHOULD be set to "Do
All".
Shapers are used to delay some or all of the packets in a traffic stream The policing action is associated with a three-level token bucket
in order to bring the stream into compliance with a traffic profile. A traffic profile carrying rate, burst and excess-burst parameters.
shaper usually has a finite-sized buffer, and packets may be discarded if Traffic measured by a meter can be classified as conforming traffic when
there is not sufficient buffer space to hold the delayed packets. Shaping the metered rate is below the rate defined by the traffic profile, as
is controlled by the QoSPolicyShapeAction class. The only required excess traffic when the metered traffic is above the normal burst and
association is a traffic profile that specifies the rate and burst below the excess burst size, and violating traffic when rate is above
parameters that the outgoing flows should conform with. the maximum excess burst.
The [DIFF-MIB] defines a two-level meter, and provides a means to
combine two-level meters into more complex meters. In this document, a
three-level traffic profile is defined. This allows construction of both
two-level meters as well as providing an easier definition for three-
level meters needed for creating AF [AF] provisioning actions.
A policing action that models three-level policing MUST associate three
separate actions with a three-level traffic profile. These actions are a
conforming action, an exceeding action and a violating action. A
policing action that models two-level policing uses a two-level traffic
profile and associates only conforming and exceeding actions. A policing
action with a three-level traffic profile that specifies an exceed
action but does not specify a violate action implies that the action
taken when the traffic is above the maximum excess burst is identical to
the action taken when the traffic is above the normal burst. A policer
determines whether the profile is being met, while the actions to be
performed are determined by the associations QoSPolicyXXXAction.
Shapers are used to delay some or all of the packets in a traffic
stream, in order to bring the stream into compliance with a traffic
profile. A shaper usually has a finite-sized buffer, and packets may be
discarded if there is not sufficient buffer space to hold the delayed
packets. Shaping is controlled by the QoSPolicyShapeAction class. The
only required association is a traffic profile that specifies the rate
and burst parameters that the outgoing flows should conform with.
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 29
3.3.2 Controlling Markers 3.3.2 Controlling Markers
Three types of markers are modeled in QPIM: Differentiated Services Code Three types of marking control actions are modeled in QPIM:
Point (DSCP), IP Precedence (IPP) and layer-2 Class of Service (CoS). The Differentiated Services Code Point (DSCP) assignment, IP Precedence
marking action itself is modeled by using the SimplePolicyAction class (IPP) assignment and layer-2 Class of Service (CoS) assignment. These
associated with the appropriate variables and values. assignment actions themselves are modeled by using the
SimplePolicyAction class associated with the appropriate variables and
values.
DSCP markers set the DS field of a packet header to a particular DS Code DSCP assignment sets ("marks" or "colors") the DS field of a packet
Point (DSCP), adding the marked packet to a particular DS behavior header to a particular DS Code Point (DSCP), adding the marked packet to
aggregate. The marker may be configured to mark all packets that it a particular DS behavior aggregate.
receives to a single DSCP, or may be configured to mark a packet to one
of a set of DSCPs used to select a PHB in a PHB group according to the
state of a meter. This can be achieved by associating a marking action
with a policer action using the conform, exceed and violate action
associations. The semantics of the DSCP marker is encapsulated in the
pairing of a DSCP variable and a DSCP value within a single
SimplePolicyAction instance via the appropriate associations.
IPP markers set the IPP field of a packet header to a particular IPP When used in the basic form, "If <condition> then 'DCSP = ds1'", the
value (0 through 7). The semantics of the IPP marker is encapsulated in assignment action assigns a DSCP value (ds1) to all packets that result
the pairing of a DSCP variable masked to IPP sub-field and a DSCP value in the condition being evaluated to true.
masked to IPP sub-field within a single SimplePolicyAction instance via
the appropriate associations.
CoS markers control the mapping of a per-hop behavior to a layer-2 Class When used in combination with a policing action, a different assignment
of Service. For example, mapping of a set of DSCP values into a 802.1q action can be issued via each of the 'conform', 'exceed' and 'violate'
user priority value can be specified using a rule with a condition action associations. This way, one may select a PHB in a PHB group
describing the set of DSCP values, and a CoS marking action that according to the state of a meter.
specifies the required mapping to the given user priority value. The
semantics of the CoS marker is encapsulated in the pairing of a CoS The semantics of the DSCP assignment is encapsulated in the pairing of a
variable and a CoS value (integer in the range of 0 through 7) within a DSCP variable and a DSCP value within a single SimplePolicyAction
single SimplePolicyAction instance via the appropriate associations. instance via the appropriate associations.
IPP assignment sets the IPP field of a packet header to a particular IPP
value (0 through 7). The semantics of the IPP assignment is encapsulated
in the pairing of a ToS variable (PolicyIPTosVariable) and a bit string value
() (defined in [PCIMe]) within a single SimplePolicyAction instance via the
appropriate associations. The bit string value is used in its masked bit string
format. The mask indicates the relevant 3 bits of the IPP sub field within the
ToS byte, while the bit string indicates the IPP value to be set.
CoS assignments control the mapping of a per-hop behavior to a layer-2
Class of Service. For example, mapping of a set of DSCP values into a
802.1p user priority value can be specified using a rule with a
condition describing the set of DSCP values, and a CoS assignment action
that specifies the required mapping to the given user priority value.
The semantics of the CoS assignment is encapsulated in the pairing of a
CoS variable and a CoS value (integer in the range of 0 through 7)
within a single SimplePolicyAction instance via the appropriate
associations.
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 30
3.3.3 Controlling Edge Policies - Examples 3.3.3 Controlling Edge Policies - Examples
Assuming that the AF1 behavior aggregate is enforced within a DS domain, Assuming that the AF1 behavior aggregate is enforced within a DS domain,
policy rules on the edge of the network should mark packets to one of the policy rules on the boundaries of the network should mark packets to one
AF1x DSCPs depending on conformance to a predetermined three-parameter of the AF1x DSCPs, depending on the conformance of the traffic to a
traffic profile. QPIM models such AF1 policing action as defined in predetermined three-parameter traffic profile. QPIM models such AF1
Figure 3. policing action as defined in Figure 3.
Snir, Ramberg, Strassner, Cohen expires November 2001 18
+-----------------------+ +------------------------------+ +-----------------------+ +------------------------------+
| QoSPolicyPoliceAction |====| QoSPolicyTokenBucketTrfcProf | | QoSPolicyPoliceAction |====| QoSPolicyTokenBucketTrfcProf |
| scope = class | | rate = x, bc = y, be = z | | scope = class | | rate = x, bc = y, be = z |
+-----------------------+ +------------------------------+ +-----------------------+ +------------------------------+
* @ # * @ #
* @ # * @ #
* @ +-------------------------+ +--------------------+ * @ +--------------------+ +--------------------------+
* @ | SimplePolicyAction |---| PolicyIntegerValue | * @ | SimplePolicyAction |---| PolicyIntegerValue -AF13 |
* @ +-------------------------+ | AF13 | * @ +--------------------+ +--------------------------+
* @ +--------------------+ * @
* +-------------------------+ +--------------------+ * +--------------------+ +---------------------------+
* | SimplePolicyAction |---| PolicyIntegerValue | * | SimplePolicyAction |---| PolicyIntegerValue - AF12 |
* +-------------------------+ | AF12 | * +--------------------+ +---------------------------+
* +--------------------+ *
+-------------------------+ +--------------------+ +--------------------+ +---------------------------+
| SimplePolicyAction |---| PolicyIntegerValue | | SimplePolicyAction |---| PolicyIntegerValue - AF11 |
+-------------------------+ | AF11 | +--------------------+ +---------------------------+
+--------------------+
Association and Aggregation Legend: Association and Aggregation Legend:
**** QoSPolicyConformAction **** QoSPolicyConformAction
@@@@ QoSPolicyExceedAction @@@@ QoSPolicyExceedAction
#### QoSPolicyViolateAction #### QoSPolicyViolateAction
==== QoSTrfcProfInAdmissionAction ==== QoSTrfcProfInAdmissionAction
---- PolicyValueInSimplePolicyAction ([PCIMe]) ---- PolicyValueInSimplePolicyAction ([PCIMe])
&&&& PolicyVariableInSimplePolicyAction ([PCIMe], not shown) &&&& PolicyVariableInSimplePolicyAction ([PCIMe], not shown)
Figure 3. AF Policing and Marking Figure 3. AF Policing and Marking
The marker is made of an instance of the SimplePolicyAction class. The The AF policing action is composed of a police action, a token bucket
aggregation PolicyVariableInSimplePolicyAction (which is defined in traffic profile and three instances of the SimplePolicyAction class.
[PCIMe]) is used to associate the value to mark (contained in the Each of the simple policy action instances models a different marking
PolicyDSCPValue) with the appropriate traffic action. This aggregation is action. Each SimplePolicyAction uses the aggregation
not shown in this figure for simplicity. AF11 is marked on conforming PolicyVariableInSimplePolicyAction to specify that the associated
traffic; AF12 is marked on exceeding action and AF13 on violating PolicyDSCPVariable is set to the appropriate integer value. This is
traffic. done using the PolicyValueInSimplePolicyAction aggregation. The three
PolicyVariableInSimplePolicyAction aggregations which connect the
appropriate SimplePolicyActions with the appropriate DSCP Variables, are
not shown in this figure for simplicity. AF11 is marked on detecting
conforming traffic; AF12 is marked on detecting exceeding traffic, and
AF13 on detecting violating traffic.
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 31
The second example, shown in Figure 4, is the simplest policing action. The second example, shown in Figure 4, is the simplest policing action.
Traffic below a two-parameter traffic profile is unmodified, while Traffic below a two-parameter traffic profile is unmodified, while
traffic exceeding the traffic profile is discarded. traffic exceeding the traffic profile is discarded.
Snir, Ramberg, Strassner, Cohen expires November 2001 19
+-----------------------+ +------------------------------+ +-----------------------+ +------------------------------+
| QoSPolicyPoliceAction |====| QoSPolicyTokenBucketTrfcProf | | QoSPolicyPoliceAction |====| QoSPolicyTokenBucketTrfcProf |
| scope = class | | rate = x, bc = y | | scope = class | | rate = x, bc = y |
+-----------------------+ +------------------------------+ +-----------------------+ +------------------------------+
@ @
@ @
+-------------------------+ +-------------------------+
| QoSPolicyDiscardAction | | QoSPolicyDiscardAction |
+-------------------------+ +-------------------------+
Association and Aggregation Legend: Association and Aggregation Legend:
**** QoSPolicyConformAction (not used) **** QoSPolicyConformAction (not used)
@@@@ QoSPolicyExceedAction @@@@ QoSPolicyExceedAction
#### QoSPolicyViolateAction (not used) #### QoSPolicyViolateAction (not used)
==== QoSTrfcProfInAdmissionAction ==== QoSTrfcProfInAdmissionAction
Figure 4. A Simple Policing Action Figure 4. A Simple Policing Action
3.4 Per-Hop Behavior Actions 3.4 Per-Hop Behavior Actions
skipping to change at line 934 skipping to change at line 1574
#### QoSPolicyViolateAction (not used) #### QoSPolicyViolateAction (not used)
==== QoSTrfcProfInAdmissionAction ==== QoSTrfcProfInAdmissionAction
Figure 4. A Simple Policing Action Figure 4. A Simple Policing Action
3.4 Per-Hop Behavior Actions 3.4 Per-Hop Behavior Actions
A Per-Hop Behavior (PHB) is a description of the externally observable A Per-Hop Behavior (PHB) is a description of the externally observable
forwarding behavior of a DS node applied to a particular DS behavior forwarding behavior of a DS node applied to a particular DS behavior
aggregate [DIFFSERV]. The approach taken here is that a PHB action aggregate [DIFFSERV]. The approach taken here is that a PHB action
specifies both observable forwarding behavior (i.e., loss, delay, jitter) specifies both observable forwarding behavior (e.g., loss, delay,
as well as specifying the buffer and bandwidth resources that need to be jitter) as well as specifying the buffer and bandwidth resources that
allocated to each of the behavior aggregates in order to achieve this need to be allocated to each of the behavior aggregates in order to
behavior. That is, a rule with a set of PHB actions can specify that an achieve this behavior. That is, a rule with a set of PHB actions can
EF packet must not be delayed more than 20 msec in each hop. The same specify that an EF packet must not be delayed more than 20 msec in each
rule may also specify that EF packets need to be treated with preemptive hop. The same rule may also specify that EF packets need to be treated
forwarding (e.g., with priority queuing), and specify the maximum with preemptive forwarding (e.g., with priority queuing), and specify
bandwidth for this class as well as the maximum buffer resources. PHB the maximum bandwidth for this class, as well as the maximum buffer
actions can therefore be used to both represent the final requirements resources. PHB actions can therefore be used both to represent the final
from PHBs as well as provide enough detail to be able to map the PHB requirements from PHBs and to provide enough detail to be able to map
actions into a set of configuration parameters to configure queues, the PHB actions into a set of configuration parameters to configure
schedulers, droppers and other mechanisms. queues, schedulers, droppers and other mechanisms.
The QoSPolicyPHBAction abstract class has two subclasses. The The QoSPolicyPHBAction abstract class has two subclasses. The
QoSPolicyBandwidthAction class is used to control bandwidth, delay and QoSPolicyBandwidthAction class is used to control bandwidth, delay and
forwarding behavior, while the QoSPolicyCongestionControlAction class is forwarding behavior, while the QoSPolicyCongestionControlAction class is
used to control queue size, thresholds and congestion algorithms. The used to control queue size, thresholds and congestion algorithms. The
qpPacketSize property of the PHB action specifies the packet size in qpMaxPacketSize property of the QoSPolicyPHBAction class specifies the
bytes, and is needed when translating the actions into actual packet size in bytes, and is needed when translating the bandwidth and
implementation configurations. For example, implementation measuring congestion control actions into actual implementation configurations.
queue length in bytes will need to use this property to map the For example, an implementation measuring queue length in bytes will need
qpQueueSize property into queue length in bytes. to use this property to map the qpQueueSize property into the desired
queue length in bytes.
Snir, Ramberg, Strassner, Cohen expires November 2001 20 Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 32
3.4.1 Controlling Bandwidth and Delay 3.4.1 Controlling Bandwidth and Delay
QoSPolicyBandwidthAction allows specifying the minimal bandwidth that QoSPolicyBandwidthAction allows specifying the minimal bandwidth that
should be reserved for a class of traffic. The property qpMinBandwidth should be reserved for a class of traffic. The property qpMinBandwidth
can be specified either in Kb/sec or in percentage of the total available can be specified either in Kb/sec or as a percentage of the total
bandwidth. The property qpBandwidthUnits is used to determine whether available bandwidth. The property qpBandwidthUnits is used to determine
percentage or fixed values are used. whether percentages or fixed values are used.
The property qpForwardingPriority is used whenever preemptive forwarding The property qpForwardingPriority is used whenever preemptive forwarding
is required. A policy rule that defines the EF PHB should indicate a non- is required. A policy rule that defines the EF PHB should indicate a
zero forwarding priority. The qpForwardingPriority property holds an non-zero forwarding priority. The qpForwardingPriority property holds an
integer value to enable multiple levels of preemptive forwarding where integer value to enable multiple levels of preemptive forwarding where
higher values are used to specify higher priority. higher values are used to specify higher priority.
The property qpMaxBandwidth specifies the maximum bandwidth that should The property qpMaxBandwidth specifies the maximum bandwidth that should
be allocated to a class of traffic. This property may be specified in PHB be allocated to a class of traffic. This property may be specified in
actions with non-zero forwarding priority in order to guard against PHB actions with non-zero forwarding priority in order to guard against
starvation of other PHBs. starvation of other PHBs.
The properties qpMaxDelay and qpMaxJitter specify limits on the per-hop The properties qpMaxDelay and qpMaxJitter specify limits on the per-hop
delay and jitter in milliseconds for any given packet within a traffic delay and jitter in milliseconds for any given packet within a traffic
class. Enforcement of the maximum delay and jitter may require use of class. Enforcement of the maximum delay and jitter may require use of
preemptive forwarding as well as minimum and maximum bandwidth controls. preemptive forwarding as well as minimum and maximum bandwidth controls.
Enforcement of low max delay and jitter values may also require Enforcement of low max delay and jitter values may also require
fragmentation and interleave mechanisms over low speed links. fragmentation and interleave mechanisms over low speed links.
The Boolean property qpFairness indicates whether flows should have a The Boolean property qpFairness indicates whether flows should have a
fair chance to be forwarded without drop or delay. A way to enforce a fair chance to be forwarded without drop or delay. A way to enforce a
bandwidth action with qpFairness set to TRUE would be to build a queue bandwidth action with qpFairness set to TRUE would be to build a queue
per flow for the class of traffic specified in the rule's filter. In this per flow for the class of traffic specified in the rule's filter. In
way, interactive flows like terminal access will not be queued behind a this way, interactive flows like terminal access will not be queued
bursty flow (like FTP) and therefore have a reasonable response time. behind a bursty flow (like FTP) and therefore have a reasonable response
time.
3.4.2 Congestion Control Actions 3.4.2 Congestion Control Actions
The QoSPolicyCongestionControlAction class controls queue length, The QoSPolicyCongestionControlAction class controls queue length,
thresholds and congestion control algorithms. thresholds and congestion control algorithms.
A PEP should be able to keep in its queues qpQueueSize packets matching A PEP should be able to keep in its queues qpQueueSize packets matching
the rule's condition. In order to provide a link-speed independent queue the rule's condition. In order to provide a link-speed independent queue
size, the qpQueueSize can also be measured in milliseconds. The time size, the qpQueueSize property can also be measured in milliseconds. The
interval specifies the time needed to transmit all packets within the time interval specifies the time needed to transmit all packets within
queue if the link speed is dedicated entirely for transmission of packets the queue if the link speed is dedicated entirely for transmission of
within this queue. The property qpQueueSizeUnit determines whether queue packets within this queue. The property qpQueueSizeUnit determines
size is measured in number of packets or in milliseconds. whether queue size is measured in number of packets or in milliseconds.
The property qpDropAlgorithm selects either tail-drop, head-drop or Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 33
random-drop algorithms. The set of maximum and minimum threshold values
can be specified as well, using qpThresholdMin and qpThresholdMax
properties, either in packets or in percentage of the total available
queue size as specified by the qpThresholdUnits property.
Snir, Ramberg, Strassner, Cohen expires November 2001 21 The property qpDropMethod selects either tail-drop, head-drop or random-
drop algorithms. The set of maximum and minimum threshold values can be
specified as well, using qpDropMinThresholdValue and
qpDropMaxThresholdValue properties, either in packets or in percentage
of the total available queue size as specified by the
qpDropThresholdUnits property.
3.4.3 Using Hierarchical Policies Examples for PHB actions 3.4.3 Using Hierarchical Policies: Examples for PHB Actions
Hierarchical policy definition is a primary tool in the QoS Policy Hierarchical policy definition is a primary tool in the QoS Policy
Information model. Rule nesting introduced in [PCIMe] allows information model. Rule nesting introduced in [PCIMe] allows
specification of hierarchical policies controlling RSVP requests, specification of hierarchical policies controlling RSVP requests,
hierarchical shaping, policing and marking actions, as well as hierarchical shaping, policing and marking actions, as well as
hierarchical schedulers and definition of the differences in PHB groups. hierarchical schedulers and definition of the differences in PHB groups.
An example of the use of hierarchical schedulers is provided in [PCIMe].
This example provides a set of rules that specify PHBs enforced within a This example provides a set of rules that specify PHBs enforced within a
Differentiated Service Domain. The network administrator chose to enforce Differentiated Service domain. The network administrator chose to
the EF, AF11 and AF13 and Best Effort PHBs. For simplicity, AF12 is not enforce the EF, AF11 and AF13 and Best Effort PHBs. For simplicity, AF12
differentiated. The set of rules takes the form: is not differentiated. The set of rules takes the form:
If (EF) then do EF actions If (EF) then do EF actions
If (AF1) then do AF1 actions If (AF1) then do AF1 actions
If (AF11) then do AF11 actions
If (AF12) then do AF12 actions
If (AF13) then do AF13 actions If (AF13) then do AF13 actions
If (default) then do Default actions. If (default) then do Default actions.
EF, AF1 and AF13 are conditions that filter traffic according to DSCP EF, AF1, AF11, AF12 and AF13 are conditions that filter traffic
values. The AF1 condition matches the entire AF1 PHB group including the according to DSCP values. The AF1 condition matches the entire AF1 PHB
AF11, AF12 and AF13 DSCP values. The default rule uses a 'match all' group including the AF11, AF12 and AF13 DSCP values. The default rule
condition and specifies the Best Effort rules. The nesting of the AF13 specifies the Best Effort rules. The nesting of the AF1x rules within
rule within the AF1 rule specifies that there are further refinements on the AF1 rule specifies that there are further refinements on how AF1x
how AF13 traffic should be treated relative to the entire AF1 PHB group. traffic should be treated relative to the entire AF1 PHB group. The set
The set of rules reside in a PolicyGroup with a decision strategy of rules reside in a PolicyGroup with a decision strategy property set
property set to 'MATCH FIRST'. to 'FirstMatching'.
The class instances below specify the set of actions used to describe The class instances below specify the set of actions used to describe
each of the PHBs. Queue sizes are not specified, but can easily be added each of the PHBs. Queue sizes are not specified, but can easily be added
to the example. to the example.
The actions used to describe the Best Effort PHB are simple. No bandwidth The actions used to describe the Best Effort PHB are simple. No
is allocated to Best Effort traffic. The first action specifies that Best bandwidth is allocated to Best Effort traffic. The first action
Effort traffic class should have fairness. specifies that Best Effort traffic class should have fairness.
QosPolicyBandwidthAction BE-B: QoSPolicyBandwidthAction BE-B:
qpFairness: True qpFairness: True
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 34
The second action specifies that the congestion algorithm for the Best The second action specifies that the congestion algorithm for the Best
Effort traffic class should be random, and specifies the thresholds in Effort traffic class should be random, and specifies the thresholds in
percentage of the default queue size. percentage of the default queue size.
QoSPolicyCongestionControlAction BE-C: QoSPolicyCongestionControlAction BE-C:
qpDropAlgorithm: random qpDropMethod: random
qpDropThresholdUnits % qpDropThresholdUnits %
qpDropMinThreshold: 10% qpDropMinThreshold: 10%
qpDropMaxThreshold: 70% qpDropMaxThreshold: 70%
Snir, Ramberg, Strassner, Cohen expires November 2001 22
EF requires preemptive forwarding. The maximum bandwidth is also EF requires preemptive forwarding. The maximum bandwidth is also
specified to make sure that the EF class does not starve the other specified to make sure that the EF class does not starve the other
classes. EF PHB uses tail drop as the applications using EF are supposed classes. EF PHB uses tail drop as the applications using EF are supposed
to be UDP-based and therefore would not benefit from a random dropper. to be UDP-based and therefore would not benefit from a random dropper.
QosPolicyBandwidthAction EF-B: QoSPolicyBandwidthAction EF-B:
qpForwardingPriority: 1 qpForwardingPriority: 1
qpBandwidthUnits: % qpBandwidthUnits: %
qpMaxBandwidth 50% qpMaxBandwidth 50%
qpFairness: False qpFairness: False
QoSPolicyCongestionControlAction EF-C: QoSPolicyCongestionControlAction EF-C:
QpDropAlgorithm: tail-drop qpDropMethod: tail-drop
qpDropThresholdUnits packet qpDropThresholdUnits packet
qpDropMaxThreshold: 3 packets qpDropMaxThreshold: 3 packets
The AF1 actions define the bandwidth allocations and thresholds for the The AF1 actions define the bandwidth allocations for the entire PHB
entire PHB group: group:
QosPolicyBandwidthAction AF1-B: QoSPolicyBandwidthAction AF1-B:
qpBandwidthUnits: % qpBandwidthUnits: %
qpMinBandwidth: 30% qpMinBandwidth: 30%
QoSPolicyCongestionControlAction AF1-C: The AF1i actions specifies the differentiating refinement for the AF1x
QpDropAlgorithm: random PHBs within the AF1 PHB group. The different threshold values provide
the difference in discard probability of the AF1x PHBs within the AF1
PHB group.
QoSPolicyCongestionControlAction AF11-C:
qpDropMethod: random
qpDropThresholdUnits packet
qpDropMinThreshold: 6 packets
qpDropMaxThreshold: 16 packets
QoSPolicyCongestionControlAction AF12-C:
qpDropMethod: random
qpDropThresholdUnits packet qpDropThresholdUnits packet
qpDropMinThreshold: 4 packets qpDropMinThreshold: 4 packets
qpDropMaxThreshold: 20 packets qpDropMaxThreshold: 13 packets
The AF13 action specifies the differentiating refinement for the AF13 PHB Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 35
within the AF1 PHB group. The lower threshold values provide the higher
discard probability of the AF13 PHB.
QosPolicyCongestionControlAction AF13-C: QoSPolicyCongestionControlAction AF13-C:
QpDropAlgorithm: random qpDropMethod: random
qpDropThresholdUnits packet qpDropThresholdUnits packet
qpDropMinThreshold: 2 packets qpDropMinThreshold: 2 packets
qpDropMaxThreshold: 10 packets qpDropMaxThreshold: 10 packets
4. Traffic Profiles 4. Traffic Profiles
Meters measure the temporal state of a flow or a set of flows against a Meters measure the temporal state of a flow or a set of flows against a
traffic profile. In this document, traffic profiles are modeled by the traffic profile. In this document, traffic profiles are modeled by the
gpsPolicyTrfcProf class. The association QoSPolicyTrfcProf class. The association
QoSPolicyTrfcProfileInAdmissionAction binds the traffic profile to the QoSPolicyTrfcProfileInAdmissionAction binds the traffic profile to the
admission action using it. Two traffic profiles are derived from the admission action using it. Two traffic profiles are derived from the
abstract class gpsPolicyTrfcProf. The first is a Token Bucket abstract class QoSPolicyTrfcProf. The first is a Token Bucket
Provisioning traffic profile carrying rate and burst parameters. The provisioning traffic profile carrying rate and burst parameters. The
second is an RSVP traffic profile, which enables flows to be compared second is an RSVP traffic profile, which enables flows to be compared
with RSVP TSPEC and FLOWSPEC parameters. with RSVP TSPEC and FLOWSPEC parameters.
Snir, Ramberg, Strassner, Cohen expires November 2001 23
4.1 Provisioning Traffic Profiles 4.1 Provisioning Traffic Profiles
Provisioned Admission Actions including Shaping and policing are Provisioned Admission Actions, including shaping and policing, are
specified using a two- or three-parameter token bucket traffic profile. specified using a two- or three-parameter token bucket traffic profile.
The qosPolicyTokenBucketTrfcProf class includes the following properties: The QoSPolicyTokenBucketTrfcProf class includes the following
properties:
1. Rate measured in kbits/sec 1. Rate measured in kbits/sec
2. Normal burst measured in bytes 2. Normal burst measured in bytes
3. Excess burst measured in bytes 3. Excess burst measured in bytes
Rate determines the long-term average transmission rate. Traffic that Rate determines the long-term average transmission rate. Traffic that
falls under this rate is conforming, as long as the normal burst is not falls under this rate is conforming, as long as the normal burst is not
exceeded at any time. Traffic exceeding the normal burst but still below exceeded at any time. Traffic exceeding the normal burst but still below
the excess burst is exceeding the traffic profile. Traffic beyond the the excess burst is exceeding the traffic profile. Traffic beyond the
excess burst is said to be violating the traffic profile. excess burst is said to be violating the traffic profile.
skipping to change at line 1143 skipping to change at line 1795
Excess burst size is measured in bytes in addition to the burst size. A Excess burst size is measured in bytes in addition to the burst size. A
zero excess burst size indicates that no excess burst is allowed. zero excess burst size indicates that no excess burst is allowed.
4.2 RSVP traffic profiles 4.2 RSVP traffic profiles
RSVP admission policy can condition the decision whether to accept or RSVP admission policy can condition the decision whether to accept or
deny an RSVP request based on the traffic specification of the flow deny an RSVP request based on the traffic specification of the flow
(TSPEC) or the amount of QoS resources requested (FLOWSPEC). The (TSPEC) or the amount of QoS resources requested (FLOWSPEC). The
admission decision can be based on matching individual RSVP requests admission decision can be based on matching individual RSVP requests
against a traffic profile or by matching the aggregated sum of all against a traffic profile or by matching the aggregated sum of all
FLOWSPECs (TSPECs) currently admitted. The QosPolicyIntesrvTrfcProf FLOWSPECs (TSPECs) currently admitted, as determined by the
class models both such traffic profiles. This class has the following qpAdmissionScope property in an associated QoSPolicyRSVPAdmissionAction.
properties:
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 36
The QoSPolicyIntservTrfcProf class models both such traffic profiles.
This class has the following properties:
1. Token Rate (r) measured in bits/sec 1. Token Rate (r) measured in bits/sec
2. Peak Rate (p) measured in bits/sec 2. Peak Rate (p) measured in bits/sec
3. Bucket Size (b) measured in bytes 3. Bucket Size (b) measured in bytes
4. Min Policed unit (m) measured in bytes 4. Min Policed unit (m) measured in bytes
5. Max packet size (M) measured in bytes 5. Max packet size (M) measured in bytes
6. Resv Rate (R) measured in bits/sec 6. Resv Rate (R) measured in bits/sec
7. Slack term (s) measured in microseconds 7. Slack term (s) measured in microseconds
The first 5 parameters are the traffic specification parameters used in The first five parameters are the traffic specification parameters used
the integrated service architecture. These parameters are used to define in the Integrated Service architecture ([INTSERV]). These parameters are
a sender TSPEC as well as FLOWSPEC for the Controlled-Load service [CL]. used to define a sender TSPEC as well as a FLOWSPEC for the Controlled-
For a definition and full explanation of their meaning, please refer to Load service [CL]. For a definition and full explanation of their
[RSVP-IS]. Parameters 6 and 7 are the additional parameters used for meanings, please refer to [RSVP-IS].
specification of the Guaranteed Service FLOWSPEC [GS].
Snir, Ramberg, Strassner, Cohen expires November 2001 24 Parameters 6 and 7 are the additional parameters used for specification
of the Guaranteed Service FLOWSPEC [GS].
A partial order is defined between TSPECs (and FLOWSPECs). The TSPEC A is A partial order is defined between TSPECs (and FLOWSPECs). The TSPEC A
larger than the TSPEC B if and only if rA>rB, pA>pB, bA>bB, mA<mB and is larger than the TSPEC B if and only if rA>rB, pA>pB, bA>bB, mA<mB and
MA>MB. A TSPEC (FLOWSPEC) measured against a traffic profile uses the MA>MB. A TSPEC (FLOWSPEC) measured against a traffic profile uses the
same ordering rule. An RSVP message is accepted only if its TSPEC same ordering rule. An RSVP message is accepted only if its TSPEC
(FLOWSPEC) is either smaller or equal to the traffic profile. Only (FLOWSPEC) is either smaller or equal to the traffic profile. Only
parameters specified in the traffic profile are compared. parameters specified in the traffic profile are compared.
The GS FLOWSPEC is also compared against the rate R and the slack term S. The GS FLOWSPEC is compared against the rate R and the slack term s. The
R should not be larger than the traffic profile R parameter, while the term R should not be larger than the traffic profile R parameter, while
FLOWSPEC slack term should not be smaller than that specified in the the FLOWSPEC slack term should not be smaller than that specified in the
slack term. slack term.
TSPECs as well as FLOWSPECs can be added. The sum of two TSPECs is 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 computed by summing the rate r, the peak rate p, the bucket size b, and
by taking the minimum value of the minimum policed unit m and the maximum by taking the minimum value of the minimum policed unit m and the
value of the maximum packet size M. GS FLOWSPECs are summed by adding the maximum value of the maximum packet size M. GS FLOWSPECs are summed by
Resv rate and minimizing the slack term s. These rules are used to adding the Resv rate and minimizing the slack term s. These rules are
compute the temporal state of admitted RSVP states matching the traffic used to compute the temporal state of admitted RSVP states matching the
class defined by the rule condition. This state is compared with the traffic class defined by the rule condition. This state is compared with
traffic profile to arrive to an admission decision when the scope of the the traffic profile to arrive at an admission decision when the scope of
QoSPolicyRSVPAdmissionAction is set to 'class'. the QoSPolicyRSVPAdmissionAction is set to 'class'.
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 37
5. Pre-Defined QoS-Related Variables 5. Pre-Defined QoS-Related Variables
Pre-defined variables are necessary for ensuring interoperability among Pre-defined variables are necessary for ensuring interoperability among
policy servers and policy management tools from different vendors. policy servers and policy management tools from different vendors. The
The purpose of this section is to define frequently used variables in QoS purpose of this section is to define frequently used variables in QoS
policy domains. policy domains.
Notice that this section only adds to the variable classes as defined in Notice that this section only adds to the variable classes as defined in
[PCIMe] and reuses the mechanism defined there. [PCIMe] and reuses the mechanism defined there.
The QoS policy information model specifies a set of pre-defined variable The QoS policy information model specifies a set of pre-defined variable
classes to support a set of fundamental QoS terms that are commonly used classes to support a set of fundamental QoS terms that are commonly used
to form conditions and actions and are missing from the [PCIMe]. Examples to form conditions and actions and are missing from the [PCIMe].
of these include RSVP related variables. All variable classes defined in Examples of these include RSVP related variables. All variable classes
this document extend the PolicyImplictVariable class, defined in [PCIMe]. defined in this document extend the QoSPolicyRSVPVariable class (defined
Subclasses specify the data type and semantics of the policy variables. in this document), which itself extends the PolicyImplictVariable class,
defined in [PCIMe]. Subclasses specify the data type and semantics of
This Draft defines the following RSVP variable classes, for details see the policy variables.
class definition:
Snir, Ramberg, Strassner, Cohen expires November 2001 25 This draft defines the following RSVP variable classes; for details, see
their class definitions:
RSVP related Variables: RSVP related Variables:
1. QoSPolicyRSVPSourceIPv4Variable - The source IP address of the RSVP 1. QoSPolicyRSVPSourceIPv4Variable - The source IPv4 address of the
signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE
RESV FILTER_SPEC [RSVP] objects. and RSVP RESV FILTER_SPEC [RSVP] objects.
2. QoSPolicyRSVPDestinationIPv4Variable - The destination port of the 2. QoSPolicyRSVPDestinationIPv4Variable - The destination port of the
RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION
[RSVP] objects. [RSVP] objects (for IPv4 traffic).
3. QoSPolicyRSVPSourceIPv6Variable - The source IP address of the RSVP 3. QoSPolicyRSVPSourceIPv6Variable - The source IPv6 address of the
signaled flow, as defied in the RSVP PATH SENDER_TEMPLATE and RSVP RSVP signaled flow, as defied in the RSVP PATH SENDER_TEMPLATE and
RESV FILTER_SPEC [RSVP] objects. RSVP RESV FILTER_SPEC [RSVP] objects.
4. QoSPolicyRSVPDestinationIPv6Variable - The destination port of the 4. QoSPolicyRSVPDestinationIPv6Variable - The destination port of the
RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION
[RSVP] objects. [RSVP] objects (for IPv6 traffic).
5. QoSPolicyRSVPSourcePortVariable - The source port of the RSVP signaled 5. QoSPolicyRSVPSourcePortVariable - The source port of the RSVP
flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and
FILTER_SPEC [RSVP] objects. RSVP RESV FILTER_SPEC [RSVP] objects.
6. QoSPolicyRSVPDestinationPortVariable - The destination port of the 6. QoSPolicyRSVPDestinationPortVariable - The destination port of the
RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION
[RSVP] objects. [RSVP] objects.
7. QoSPolicyRSVPIPProtocolVariable - The IP Protocol of the RSVP signaled 7. QoSPolicyRSVPIPProtocolVariable - The IP Protocol of the RSVP
flow, as defined in the RSVP PATH and RESV SESSION [RSVP] objects. signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP]
8. QoSPolicyRSVPIPVersionVariable - The IP version of the IP Addresses objects.
carried the RSVP signaled flow, as defined in the RSVP PATH and RESV 8. QoSPolicyRSVPIPVersionVariable - The version of the IP addresses
SESSION [RSVP] objects. carrying the RSVP signaled flow, as defined in the RSVP PATH and
9. QoSPolicyRSVPDCLASSVariable - The DSCP value as defined in the RSVP RESV SESSION [RSVP] objects.
DCLASS [DCLASS] object. 9. QoSPolicyRSVPDCLASSVariable - The DSCP value as defined in the
RSVP DCLASS [DCLASS] object.
10. QoSPolicyRSVPStyleVariable - The reservation style (FF, SE, WF) as 10. QoSPolicyRSVPStyleVariable - The reservation style (FF, SE, WF) as
defined in the RSVP Resv message [RSVP]. defined in the RSVP Resv message [RSVP].
11. QoSPolicyRSVPIntServVariable - The integrated Service (CL, GS,
NULL) requested in the RSVP Reservation message, as defined in the Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 38
FLOWSPEC RSVP Object [RSVP]. 11. QoSPolicyRSVPIntServVariable - The type of Integrated Service (CL,
GS, NULL) requested in the RSVP Reservation message, as defined in
the FLOWSPEC RSVP Object [RSVP].
12. QoSPolicyRSVPMessageTypeVariable - The RSVP message type, either 12. QoSPolicyRSVPMessageTypeVariable - The RSVP message type, either
Path, Resv, PathErr or ResvErr [RSVP]. Path, Resv, PathErr or ResvErr [RSVP].
13. QoSPolicyRSVPPreemptionPriorityVariable - The RSVP reservation 13. QoSPolicyRSVPPreemptionPriorityVariable - The RSVP reservation
priority as defined in [RFC2751]. priority as defined in [RFC2751].
14. QoSPolicyRSVPPreemptionDefPriorityVariable - The RSVP preemption 14. QoSPolicyRSVPPreemptionDefPriorityVariable - The RSVP preemption
reservation defending priority as defined in [RFC2751]. reservation defending priority as defined in [RFC2751].
15. QoSPolicyRSVPUserVariable - The ID of the user that initiated the 15. QoSPolicyRSVPUserVariable - The ID of the user that initiated the
flow as defined in the User Locator string in the Identity Policy flow as defined in the User Locator string in the Identity Policy
Object [RFC2752]. Object [RFC2752].
16. QoSPolicyRSVPApplicationVariable - The ID of the application that 16. QoSPolicyRSVPApplicationVariable - The ID of the application that
generated the flow as defined in the application locator string in generated the flow as defined in the application locator string in
the Application policy object [RFC2872] the Application policy object [RFC2872].
17. QoSPolicyRSVPAuthMethodVariable - The RSVP Authentication type used 17. QoSPolicyRSVPAuthMethodVariable - The RSVP Authentication type
in the Identity Policy Object [RFC2752]. used in the Identity Policy Object [RFC2752].
Each class restricts the possible value types associated with a specific Each class restricts the possible value types associated with a specific
variable. For example, the QoSPolicyRSVPSourcePortVariable class is used variable. For example, the QoSPolicyRSVPSourcePortVariable class is used
to define the source port of the RSVP signaled flow. The value associated to define the source port of the RSVP signaled flow. The value
with this variable is of type integer. associated with this variable is of type PolicyIntegerValue.
Snir, Ramberg, Strassner, Cohen expires November 2001 26 Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 39
6. QoS Related Values 6. QoS Related Values
Values are used in the information model as building blocks for the Values are used in the information model as building blocks for the
policy conditions and policy actions, as described in [PCIM] and [PCIMe]. policy conditions and policy actions, as described in [PCIM] and
This section defines a set of auxiliary values that are [PCIMe]. This section defines a set of auxiliary values that are used
used for QoS policies as well as other policy domains. for QoS policies as well as other policy domains.
All value classes extend the PolicyImplicitValue class [PCIMe]. The All value classes extend the PolicyValue class [PCIMe]. The subclasses
subclasses specify specific data/value types that are not defined in specify specific data/value types that are not defined in [PCIMe].
[PCIMe].
This document defines the following two subclasses of the This document defines the following two subclasses of the PolicyValue
PolicyImplicitValue class: class:
QoSPolicyDNValue - This class is used to represent a single or set of QoSPolicyDNValue - This class is used to represent a single or set of
Distinguished Name [DNDEF] values, including wildcards. A Distinguished Distinguished Name [DNDEF] values, including
Name is a name that can be used as a key to retrieve an object from a wildcards. A Distinguished Name is a name that can
directory service. This value can be used in comparison to reference be used as a key to retrieve an object from a
values carried in RSVP policy objects, as specified in [RFC2752]. This directory service. This value can be used in
comparison to reference values carried in RSVP
policy objects, as specified in [RFC2752]. This
class is defined in Section 8.31. class is defined in Section 8.31.
QoSPolicyAttributeValue - This class is used to represent a single or set QoSPolicyAttributeValue - A condition term uses the form "Variable
of property values in an object. This value can be used in conjunction matches Value", and an action term uses
with reference values carried in RSVP objects, as specified in [RFC2752]. the form "set Variable to Value" ([PCIMe]).
This class is used to represent a single or
set of property values for the "Value" term
in either a condition or an action.
This value can be used in conjunction with
reference values carried in RSVP objects, as
specified in [RFC2752]. This class is
defined in section 8.12.
The property name is used to specify which of the properties in the 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 QoSPolicyAttributeValue class instance is being used in the condition or
then be retrieved, and a match (which is dependent on the property name) action term. The value of this property or properties will then be
will be used to see if the condition is satisfied or not. retrieved. In the case of a condition, a match (which is dependent on
the property name) will be used to see if the condition is satisfied or
not. In the case of an action, the semantics are instead "set the
variable to this value".
For example, suppose a User class has a multi-valued Property called For example, suppose the "user" objects in the organization include
'member-of' that lists the names of groups that this user belongs to. several properties, among them:
Suppose this property uses caseIgnoreMatch matching. A simple condition
can be constructed to match the reference carried in an RSVP Identity
policy object to a gpsPolicyAttributeValue with the following
characteristics:
gpAttributeName="member-of", gpAttributeValueList = "group-A". - First Name
- Last Name
- Login Name
- Department
- Title
A User Identity policy object carrying the following reference: Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 40
"OU=Sales, CN=J. Smith, O=Widget Inc." A simple condition could be constructed to identify flows by their RSVP
user carried policy object. The simple condition: Last Name = "Smith" to
identify a user named Bill would be constructed in the following way:
will match this simple condition only if J. Smith belongs to group-a. A SimplePolicyCondition [PCIMe] would aggregate a
QoSPolicyRSVPUserVariable [QPIM] object, via the
PolicyVariableInSimplePolicyCondition [PCIMe] aggregation.
Snir, Ramberg, Strassner, Cohen expires November 2001 27 The implicit value associated with this condition is created in the
following way:
A QoSPolicyAttributeValue object would be aggregated to the simple
condition object via a PolicyValueInSimplePolicyCondition [PCIMe].
The QoSPolicyAttributeValue attribute qpAttributeName would be set
to "last name" and the qpAttributeValueList would be set to "Smith".
Another example is a condition that has to do with the user's
organizational department. It can be constructed in the exact same way,
by changing the QoSPolicyAttributeValue attribute qpAttributeName to
"Department" and the qpAttributeValueList would be set to the particular
value that is to be matched (e.g., "engineering" or "customer support").
The logical condition would than be evaluated to true if the user belong
to either the engineering department or the customer support.
Notice that many multiple-attribute objects require the use of the
QoSPolicyAttributeValue class to specify exactly which of its attributes
should be used in the condition match operation.
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 41
7. Class Definitions: Association Hierarchy 7. Class Definitions: Association Hierarchy
The following sections define associations that are specified by QPIM. The following sections define associations that are specified by QPIM.
7.1. The Association "QosPolicyTrfcProfInAdmissionAction" 7.1. The Association "QoSPolicyTrfcProfInAdmissionAction"
This association links a gpsPolicyTrfcProf object modeling a specific This association links a QoSPolicyTrfcProf object (defined in section
traffic profile to a QoSPolicyAdmissionAction object. The class 8.9), modeling a specific traffic profile, to a QoSPolicyAdmissionAction
definition for this association is as follows: object (defined in section 8.2). The class definition for this
association is as follows:
NAME QosPolicyTrfcProfInAdmissionAction NAME QoSPolicyTrfcProfInAdmissionAction
DESCRIPTION A class representing the association between a DESCRIPTION A class representing the association between a
traffic profile used for admission decision QoS admission action and its traffic profile.
DERIVED FROM Dependency DERIVED FROM Dependency (See [PCIM])
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES Antecedent[ref QoSPolicyAdmissionAction [0..n]] PROPERTIES Antecedent[ref QoSPolicyAdmissionAction [0..n]]
Dependent[ref QoSPolicyTrfcProf [0..n]] Dependent[ref QoSPolicyTrfcProf [1..1]]
7.1.1. The Reference "Antecedent" 7.1.1. The Reference "Antecedent"
This property is inherited from the Dependency association, defined in This property is inherited from the Dependency association, defined in
[PCIM]. Its type is overridden to become an object reference to a [PCIM]. Its type is overridden to become an object reference to a
QoSPolicyAdmissionAction object. This represents the "independent" part QoSPolicyAdmissionAction object. This represents the "independent" part
of the association. The [0..n] cardinality indicates that a given of the association. The [0..n] cardinality indicates that any number of
QoSPolicyAdmissionAction object may have 0 or more traffic profiles that QoSPolicyAdmissionAction object(s) may use a given QoSPolicyTrfcProfile.
it can use.
7.1.2. The Reference "Dependent" 7.1.2. The Reference "Dependent"
This property is inherited from the Dependency association, and is This property is inherited from the Dependency association, and is
overridden to become an object reference to a QoSPolicyTrfcProfile overridden to become an object reference to a QoSPolicyTrfcProfile
object. This represents a specific traffic profile that is used by a object. This represents a specific traffic profile that is used by any
given QoSPolicyAdmissionAction. The [0..n] cardinality means that a given number of QoSPolicyAdmissionAction objects. The [1..1] cardinality means
traffic profile may be used by 0 or more admission actions. that exactly one object of the QoSPolicyTrfcProfile can be used by a
given QoSPolicyAddmissionAction.
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 42
7.2 The Association "PolicyConformAction" 7.2 The Association "PolicyConformAction"
This association links a policer action with an object defining This association links a policing action with an object defining an
an action to be applied on conforming traffic relative to the associated action to be applied to conforming traffic relative to the associated
traffic profile. The class definition for this association is as follows: traffic profile. The class definition for this association is as
follows:
NAME PolicyConformAction NAME PolicyConformAction
DESCRIPTION A class representing the association between a policer DESCRIPTION A class representing the association between a
action and the action that should be applied on traffic policing action and the action that should be applied
conforming to an associated traffic profile. to traffic conforming to an associated traffic
DERIVED FROM Dependency profile.
DERIVED FROM Dependency (see [PCIM])
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES Antecedent[ref QoSPolicyPoliceAction[0..n]] PROPERTIES Antecedent[ref QoSPolicyPoliceAction[0..n]]
Dependent[ref PolicyAction [0..1]] Dependent[ref PolicyAction [1..1]]
Snir, Ramberg, Strassner, Cohen expires November 2001 28
7.2.1. The Reference "Antecedent" 7.2.1. The Reference "Antecedent"
This property is inherited from the Dependency association. Its type is This property is inherited from the Dependency association. Its type is
overridden to become an object reference to a QoSPolicyPoliceAction overridden to become an object reference to a QoSPolicyPoliceAction
object. This represents the "independent" part of the association. The object. This represents the "independent" part of the association. The
[0..n] cardinality indicates that any number of QoSPolicyPoliceAction [0..n] cardinality indicates that any number of QoSPolicyPoliceAction
objects may be given the same action to be executed as the conforming objects may be given the same action to be executed as the conforming
action. action.
7.2.2. The Reference "Dependent" 7.2.2. The Reference "Dependent"
This property is inherited from the Dependency association, and is This property is inherited from the Dependency association, and is
overridden to become an object reference to a PolicyAction object. This overridden to become an object reference to a PolicyAction object. This
represents a specific policy action that is used by a given represents a specific policy action that is used by a given
QoSPolicyPoliceAction. The [1..1] cardinality means that a given QoSPolicyPoliceAction. The [1..1] cardinality means that exactly one
conforming action may only be used by a single QoSPolicyPoliceAction. policy action can be used as the "conform" action for a
QoSPolicyPoliceAction. To execute more than one conforming action, use
the PolicyCompoundAction class to model the conforming action.
7.3. The Association "PolicyExcessAction" 7.3. The Association "QoSPolicyExceedAction"
This association links a policer action with an object defining an This association links a policing action with an object defining an
action to be applied on traffic exceeding the associated traffic action to be applied to traffic exceeding the associated traffic
profile. The class definition for this association is as follows: profile. The class definition for this association is as follows:
NAME PolicyExcessAction NAME QoSPolicyExceedAction
DESCRIPTION A class representing the association between a DESCRIPTION A class representing the association between a
policer action and the action that should be applied policing action and the action that should be applied
on traffic exceeding an associated traffic profile. to traffic exceeding an associated traffic profile.
DERIVED FROM Dependency DERIVED FROM Dependency (see [PCIM])
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES Antecedent[ref QoSPolicePoliceAction[0..n]] PROPERTIES Antecedent[ref QoSPolicePoliceAction[0..n]]
Dependent[ref PolicyAction [0..1]] Dependent[ref PolicyAction [1..1]]
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 43
7.3.1. The Reference "Antecedent" 7.3.1. The Reference "Antecedent"
This property is inherited from the Dependency association. Its type is This property is inherited from the Dependency association. Its type is
overridden to become an object reference to a QoSPolicyPoliceAction overridden to become an object reference to a QoSPolicyPoliceAction
object. This represents the "independent" part of the association. The object. This represents the "independent" part of the association. The
[0..n] cardinality indicates that any number of QoSPolicyPoliceAction [0..n] cardinality indicates that any number of QoSPolicyPoliceAction
objects may be given the same action to be executed as the exceeding objects may be given the same action to be executed as the exceeding
action. action.
7.3.2. The Reference "Dependent" 7.3.2. The Reference "Dependent"
This property is inherited from the Dependency association, and is This property is inherited from the Dependency association, and is
overridden to become an object reference to a PolicyAction object. This overridden to become an object reference to a PolicyAction object. This
represents a specific policy action that is used by a given represents a specific policy action that is used by a given
QoSPolicyPoliceAction. The [1..1] cardinality means that a given QoSPolicyPoliceAction. The [1..1] cardinality means that a exactly one
exceeding action may only be used by a single QoSPolicyPoliceAction. policy action can be used as the "exceed" action by a
QoSPolicyPoliceAction. To execute more than one conforming action, use
Snir, Ramberg, Strassner, Cohen expires November 2001 29 the PolicyCompoundAction class to model the exceeding action.
7.4. The Association "PolicyViolateAction" 7.4. The Association "PolicyViolateAction"
This association links a policer action with an object defining an This association links a policing action with an object defining an
action to be applied on traffic violating the associated traffic action to be applied to traffic violating the associated traffic
profile. The class definition for this association is as follows: profile. The class definition for this association is as follows:
NAME PolicyViolateAction NAME PolicyViolateAction
DESCRIPTION A class representing the association between a DESCRIPTION A class representing the association between a
policer action and the action that should be applied policing action and the action that should be applied
on traffic violating an associated traffic profile. to traffic violating an associated traffic profile.
DERIVED FROM Dependency DERIVED FROM Dependency (see [PCIM])
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES Antecedent[ref QoSPolicePoliceAction[0..n]] PROPERTIES Antecedent[ref QoSPolicePoliceAction[0..n]]
Dependent[ref PolicyAction [0..1]] Dependent[ref PolicyAction [1..1]]
7.4.1. The Reference "Antecedent" 7.4.1. The Reference "Antecedent"
This property is inherited from the Dependency association. Its type is This property is inherited from the Dependency association. Its type is
overridden to become an object reference to a QoSPolicyPoliceAction overridden to become an object reference to a QoSPolicyPoliceAction
object. This represents the "independent" part of the association. The object. This represents the "independent" part of the association. The
[0..n] cardinality indicates that any number of QoSPolicyPoliceAction [0..n] cardinality indicates that any number of QoSPolicyPoliceAction
objects may be given the same action to be executed as the violating objects may be given the same action to be executed as the violating
action. action.
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 44
7.4.2. The Reference "Dependent" 7.4.2. The Reference "Dependent"
This property is inherited from the Dependency association, and is This property is inherited from the Dependency association, and is
overridden to become an object reference to a PolicyAction object. This overridden to become an object reference to a PolicyAction object. This
represents a specific policy action that is used by a given represents a specific policy action that is used by a given
QoSPolicyPoliceAction. The [1..1] cardinality means that a given QoSPolicyPoliceAction. The [1..1] cardinality means that exactly one
violating action may only be used by a single QoSPolicyPoliceAction. policy action can be used as the "violate" action by a
QoSPolicyPoliceAction. To execute more than one violating action, use
the PolicyCompoundAction class to model the conforming action.
Snir, Ramberg, Strassner, Cohen expires November 2001 30 7.5 The Aggregation "QoSPolicyRSVPVariableInRSVPSimplePolicyAction"
A simple RSVP policy action is represented as a pair {variable, value}.
This aggregation provides the linkage between a
QoSPolicyRSVPSimpleAction instance and a single QoSPolicyRSVPVariable.
The aggregation PolicyValueInSimplePolicyAction links the
QoSPolicyRSVPSimpleAction to a single PolicyValue.
The class definition for this aggregation is as follows:
NAME QoSPolicyRSVPVariableInRSVPSimplePolicyAction
DERIVED FROM PolicyVariableInSimplePolicyAction
ABSTRACT False
PROPERTIES GroupComponent[ref QoSPolicyRSVPSimpleAction
[0..n]]
PartComponent[ref QoSPolicyRSVPVariable [1..1] ]
7.5.1. The Reference "GroupComponent"
The reference property "GroupComponent" is inherited from
PolicyComponent, and overridden to become an object reference to a
QoSPolicyRSVPSimpleAction that contains exactly one
QoSPolicyRSVPVariable. Note that for any single instance of the
aggregation class QoSPolicyRSVPVariableInRSVPSimplePolicyAction, this
property is single-valued. The [0..n] cardinality indicates that there
may be 0, 1, or more QoSPolicyRSVPSimpleAction objects that contain any
given RSVP variable object.
7.5.2. The Reference "PartComponent"
The reference property "PartComponent" is inherited from
PolicyComponent, and overridden to become an object reference to a
QoSPolicyRSVPVariable that is defined within the scope of a
QoSPolicyRSVPSimpleAction. Note that for any single instance of the
association class QoSPolicyRSVPVariableInRSVPSimplePolicyAction, this
property (like all reference properties) is single-valued. The [1..1]
cardinality indicates that a
QoSPolicyRSVPVariableInRSVPSimplePolicyAction must have exactly one RSVP
variable defined within its scope in order to be meaningful.
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 45
8. Class Definitions: Inheritance Hierarchy 8. Class Definitions: Inheritance Hierarchy
The following sections define object classes that are specified by QPIM. The following sections define object classes that are specified by QPIM.
8.1. The Class QoSPolicyDiscardAction 8.1. The Class QoSPolicyDiscardAction
This class is used to specify that packets should be discarded. This is This class is used to specify that packets should be discarded. This is
the same as stating that packets should be denied forwarding. The class the same as stating that packets should be denied forwarding. The class
definition is as follows: definition is as follows:
skipping to change at line 1454 skipping to change at line 2202
8. Class Definitions: Inheritance Hierarchy 8. Class Definitions: Inheritance Hierarchy
The following sections define object classes that are specified by QPIM. The following sections define object classes that are specified by QPIM.
8.1. The Class QoSPolicyDiscardAction 8.1. The Class QoSPolicyDiscardAction
This class is used to specify that packets should be discarded. This is This class is used to specify that packets should be discarded. This is
the same as stating that packets should be denied forwarding. The class the same as stating that packets should be denied forwarding. The class
definition is as follows: definition is as follows:
NAME QoSPolicyDiscardAction NAME QoSPolicyDiscardAction
DESCRIPTION This action specify that packets should be discarded. DESCRIPTION This action specifies that packets should be discarded.
DERIVED FROM PolicyAction DERIVED FROM PolicyAction (defined in [PCIM])
ABSTRACT False ABSTRACT False
PROPERTIES None PROPERTIES None
8.2. The Class QoSPolicyAdmissionAction 8.2. The Class QoSPolicyAdmissionAction
This class is the base class for performing admission decisions. It is This class is the base class for performing admission decisions based on
used to determine whether to accept or reject a given RSVP request. This a comparison of a meter measuring the temporal behavior of a flow or a
is done by comparing the RSVP request's TSPEC or RSPEC parameters against set of flow with a traffic profile. The qpAdmissionScope property
the traffic profile (as specified in the QosPolicyIntServTrfcProf class). controls whether the comparison is done per flow or per class (of
The qpAdmissionScope property controls whether the comparison is done per flows). Only packets that conform to the traffic profile are admitted
flow or per class (of flows). Only packets that conform to the traffic for further processing; other packets are discarded. The class
profile are admitted for further processing; other packets are discarded. definition is as follows:
The class definition is as follows:
NAME QoSPolicyAdmissionAction NAME QoSPolicyAdmissionAction
DESCRIPTION This action controls admission decisions based on comparison DESCRIPTION This action controls admission decisions based on
of a meter to a traffic profile. comparison of a meter to a traffic profile.
DERIVED FROM PolicyAction DERIVED FROM PolicyAction (defined in [PCIM])
ABSTRACT True ABSTRACT False
PROPERTIES qpAdmissionScope PROPERTIES qpAdmissionScope
8.2.1. The Property qpAdmissionScope 8.2.1. The Property qpAdmissionScope
This attribute specifies whether the admission decision is done per flow This attribute specifies whether the admission decision is done per flow
or per the entire class of flows defined by the rule condition. If the or per the entire class of flows defined by the rule condition. If the
scope is per flow, the actual or requested rate of each flow is compared scope is "flow", the actual or requested rate of each flow is compared
against the traffic profile. If the scope is set to class, the aggregate against the traffic profile. If the scope is set to "class", the
actual or requested rate of all flows matching the rule condition is aggregate actual or requested rate of all flows matching the rule
measured against the traffic profile. The property is defined as follows: condition is measured against the traffic profile. The property is
defined as follows:
NAME qpAdmissionScope NAME qpAdmissionScope
DESCRIPTION This property specifies whether the admission decision is DESCRIPTION This property specifies whether the admission decision is
done per flow or per the entire class of flows done per flow or per the entire class of flows
SYNTAX Integer SYNTAX Integer
VALUE This is an enumerated integer. A value of 0 specifies that VALUE This is an enumerated integer. A value of 0 specifies that
admission is done on a per-flow basis, and a value of 1 admission is done on a per-flow basis, and a value of 1
specifies that admission is done on a per-class basis. specifies that admission is done on a per-class basis.
Snir, Ramberg, Strassner, Cohen expires November 2001 31 Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 46
8.3. The Class QoSPolicyPoliceAction 8.3. The Class QoSPolicyPoliceAction
This is the base class for defining policing actions (e.g., those actions This is used for defining policing actions (i.e., those actions that
that restrict traffic in some way). Using the three associations restrict traffic based on a comparison with a traffic profile). Using
QoSPolicyConformAction, QoSPolicyExceedAction and QoSPolicyViolateAction, the three associations QoSPolicyConformAction, QoSPolicyExceedAction and
it is possible to specify different actions to take based on whether the QoSPolicyViolateAction, it is possible to specify different actions to
traffic is conforming, exceeding, or violating a traffic profile. The take based on whether the traffic is conforming, exceeding, or violating
traffic profile is specified in the QosPolicyTokenBucketTrfcProf class. a traffic profile. The traffic profile is specified in a subclass of the
The class definition is as follows: QoSPolicyTrfcProf class. The class definition is as follows:
NAME QoSPolicyPoliceAction NAME QoSPolicyPoliceAction
DESCRIPTION This action controls the operation of policers. The measured DESCRIPTION This action controls the operation of policers. The rate of
rate of flows is measured against a traffic profile. The flows is measured against a traffic profile. The actions
action the needs to be performed on conforming, exceeding that need to be performed on conforming, exceeding and
and violating traffic is indicated using the conform, exceed violating traffic are indicated using the conform, exceed
and violate action associations. and violate action associations.
DERIVED FROM QoSPolicyAdmissionAction DERIVED FROM QoSPolicyAdmissionAction (defined in this document)
ABSTRACT False ABSTRACT False
PROPERTIES None PROPERTIES None
8.4. The Class QoSPolicyShapeAction 8.4. The Class QoSPolicyShapeAction
This class is the base class for defining shaping actions. Shapers are This class is used for defining shaping actions. Shapers are used to
used to delay some or all of the packets in a traffic stream in order to delay some or all of the packets in a traffic stream in order to bring a
bring a particular traffic stream into compliance with a given traffic particular traffic stream into compliance with a given traffic profile.
profile. The traffic profile is specified in the The traffic profile is specified in a subclass of the QoSPolicyTrfcProf
QosPolicyTokenBucketTrfcProf class. The class definition is as follows: class. The class definition is as follows:
NAME QoSPolicyShapeAction NAME QoSPolicyShapeAction
DESCRIPTION This action indicate that traffic should be shaped to be DESCRIPTION This action indicate that traffic should be shaped to be
conforming with a traffic profile. conforming with a traffic profile.
DERIVED FROM QoSPolicyAdmissionAction DERIVED FROM QoSPolicyAdmissionAction (defined in this document)
ABSTRACT False ABSTRACT False
PROPERTIES None PROPERTIES None
Snir, Ramberg, Strassner, Cohen expires November 2001 32
8.5. The Class QoSPolicyRSVPAdmissionAction 8.5. The Class QoSPolicyRSVPAdmissionAction
This class determines whether to accept or reject a given RSVP request by This class determines whether to accept or reject a given RSVP request
comparing the RSVP request's TSPEC or RSPEC parameters against the by comparing the RSVP request's TSPEC or RSPEC parameters against the
traffic profile. The traffic profile is specified in the associated traffic profile and/or by enforcing the pre-set maximum
QosPolicyIntServTrfcProf class. This class inherits the qpAdmissionScope sessions limit. The traffic profile is specified in the
property from its superclass. This property specifies whether admission QoSPolicyIntServTrfcProf class. This class inherits the
should be done on a per-flow or per-class basis. If the traffic profile qpAdmissionScope property from its superclass. This property specifies
is not larger or equal to the requested reservation, or to the sum of the whether admission should be done on a per-flow or per-class basis. If
admitted reservation merged with the requested reservation, the result is the traffic profile is not larger than or equal to the requested
a deny decision. If no traffic profile is specified, the assumption is reservation, or to the sum of the admitted reservation merged with the
that all traffic can be admitted. The class definition is as follows: requested reservation, the result is a deny decision. If no traffic
profile is specified, the assumption is that all traffic can be
admitted.
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 47
The class definition is as follows:
NAME QoSPolicyRSVPAdmissionAction NAME QoSPolicyRSVPAdmissionAction
DESCRIPTION This action controls the admission of RSVP request. DESCRIPTION This action controls the admission of RSVP requests.
Depending on the scope, either a single RSVP request or the Depending on the scope, either a single RSVP request or the
total admitted RSVP requests matching the conditions are total admitted RSVP requests matching the conditions are
compared against a traffic profile. compared against a traffic profile.
DERIVED FROM QoSPolicyAdmissionAction DERIVED FROM QoSPolicyAdmissionAction (defined in this document)
ABSTRACT False ABSTRACT False
PROPERTIES qpRSVPWarnOnly, qpRSVPMaxSessions PROPERTIES qpRSVPWarnOnly, qpRSVPMaxSessions
8.5.1. The Property qpRSVPWarnOnly 8.5.1. The Property qpRSVPWarnOnly
When this property is set to True, the RSVP request is admitted, but an This property is applicable when fulfilling ("admitting") an RSVP
RSVP error message carrying a warning is sent to the originator (sender request would violate the policer (traffic profile) limits or when the
or receiver). This follows the COPS for RSVP send error flag in the maximum number session would be exceeded (or both).
Decision Flags object. This property is defined as follows:
When this property is set to True, the RSVP request is admitted in spite
of the violation, but an RSVP error message carrying a warning is sent
to the originator (sender or receiver). When set to False, the request
would be denied and an error message would be sent back to the
originator. So the meaning of the qpWarnOnly flag is: Based on
property's value (True or False), determine whether to admit but warn
the originator that the request is in violation or to deny the request
altogether (and send back an error).
Specifically, a PathErr (in response to a Path message) or a ResvErr (in
response of a Resv message) will be sent. This follows the COPS for RSVP
send error flag in the Decision Flags object. This property is defined
as follows:
NAME qpRSVPWarnOnly NAME qpRSVPWarnOnly
SYNTAX Boolean SYNTAX Boolean
Default False Default False
VALUE This property can have one of two values. The value 1 (TRUE) VALUE The value TRUE means that the request should be admitted AND
means that the request should be admitted AND an RSVP error an RSVP warning message should be sent to the originator. The
message should be sent to the originator. The value of 0 (FALSE) value of FALSE means that the request should be not admitted
means that the request should be admitted without sending an RSVP and an appropriate error message should be sent back to the
error message. originator of the request.
8.5.2. The Property qpRSVPMaxSessions 8.5.2. The Property qpRSVPMaxSessions
This attribute is used to limit the total number of RSVP requests This attribute is used to limit the total number of RSVP requests
admitted within the specified class of traffic. The qpAdmissionScope admitted for the specified class of traffic. For this property to be
property must be set to class (it is not applicable if the meaningful, the qpAdmissionScope property must be set to class. The
qpAdmissionScope property is set to "flow"). The definition of this definition of this property is as follows:
property is as follows:
NAME qpRSVPMaxSessions NAME qpRSVPMaxSessions
SYNTAX Integer SYNTAX Integer
VALUE Must be greater than 0. VALUE Must be greater than 0.
Snir, Ramberg, Strassner, Cohen expires November 2001 33 Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 48
8.6. The Class QosPolicyPHBAction 8.6. The Class QoSPolicyPHBAction
This class is a base class that is used to define the per-hop behavior This class is a base class that is used to define the per-hop behavior
that is to be assigned to behavior aggregates. It defines a common that is to be assigned to behavior aggregates. It defines a common
property, qpPacketSize, for use by its subclasses property, qpMaxPacketSize, for use by its subclasses
(QoSPolicyBandwidthAction and QoSPolicyCongestionControlAction). The (QoSPolicyBandwidthAction and QoSPolicyCongestionControlAction). The
class definition is as follows: class definition is as follows:
NAME QosPolicyPHBAction NAME QoSPolicyPHBAction
DESCRIPTION This action controls the Per-Hop-Behavor provided to DESCRIPTION This action controls the Per-Hop-Behavior provided to
behavior aggregates. behavior aggregates.
DERIVED FROM PolicyAction DERIVED FROM PolicyAction (defined in [PCIM])
ABSTRACT True ABSTRACT True
PROPERTIES qpPacketSize PROPERTIES qpMaxPacketSize
8.6.1. The Property qpPacketSize 8.6.1. The Property qpMaxPacketSize
This property specifies the maximum packet size in bytes of this class of This property specifies the maximum packet size in bytes, of packets in
packet. This attribute is used in translation of QPIM attributes to QoS the designated flow. This attribute is used in translation of QPIM
mechanisms used within a PEP. For example, queue length may be measured attributes to QoS mechanisms used within a PEP. For example, queue
in bytes while the minimum number of packets that should be kept in a PEP length may be measured in bytes, while the minimum number of packets
is defined within QPIM in number of packets. This property is defined as that should be kept in a PEP is defined within QPIM in number of
follows: packets. This property is defined as follows:
NAME qpPacketSize NAME qpMaxPacketSize
SYNTAX Integer SYNTAX Integer
Value Must be greater than 0 Value Must be greater than 0
8.7. The Class QoSPolicyBandwidthAction 8.7. The Class QoSPolicyBandwidthAction
This class is used to control the bandwidth, delay, and forwarding This class is used to control the bandwidth, delay, and forwarding
behavior of a PHB. Its class definition is as follows: behavior of a PHB. Its class definition is as follows:
NAME QoSPolicyBandwidthAction NAME QoSPolicyBandwidthAction
DESCRIPTION This action controls the bandwidth, delay, and DESCRIPTION This action controls the bandwidth, delay, and
forwarding characteristics of the PHB. forwarding characteristics of the PHB.
DERIVED FROM QoSPolicyPBHAction DERIVED FROM QoSPolicyPBHAction (defined in this document)
ABSTRACT False ABSTRACT False
PROPERTIES qpForwardingPriority, qpBandwidthUnits, qpMinBandwdith, PROPERTIES qpForwardingPriority, qpBandwidthUnits, qpMinBandwdith,
qpMaxBandwidth, qpMaxDelay, qpMaxJitter, qpFairness qpMaxBandwidth, qpMaxDelay, qpMaxJitter, qpFairness
Snir, Ramberg, Strassner, Cohen expires November 2001 34 Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 49
8.7.1. The Property qpForwardingPriority 8.7.1. The Property qpForwardingPriority
This property defines the forwarding priority for this set of flows. A This property defines the forwarding priority for this set of flows. A
non-zero value indicates that pre-emptive forwarding is required. Higher non-zero value indicates that pre-emptive forwarding is required. Higher
values represent higher forwarding priority. This property is defined as values represent higher forwarding priority. This property is defined as
follows: follows:
NAME qpForwardingPriority NAME qpForwardingPriority
SYNTAX Integer SYNTAX Integer
VALUE Must be non-negative. The value 0 means that pre-emptive VALUE Must be non-negative. The value 0 means that pre-emptive
forwarding is required. A positive value indicates the forwarding is not required. A positive value indicates the
priority that is to be assigned for this (set of) flow(s). priority that is to be assigned for this (set of) flow(s).
Larger values represent higher priorities.
8.7.2 The Property qpBandwidthUnits 8.7.2 The Property qpBandwidthUnits
This property defines in what units the properties qpMinBandwidth and This property defines the units that the properties qpMinBandwidth and
qpMaxBandwidth are defined. Bandwidth can either be defined in bits/sec qpMaxBandwidth have. Bandwidth can either be defined in bits/sec or as a
or in percentage of the available bandwidth or scheduler resources. This percentage of the available bandwidth or scheduler resources. This
property is defined as follows. property is defined as follows:
NAME qpBandwidthUnits NAME qpBandwidthUnits
SYNTAX Integer SYNTAX Integer
VALUE Two values are possible. The value of 0 is used to specify VALUE Two values are possible. The value of 0 is used to specify
units of bits/sec, while the value of 1 is used to specify units of bits/sec, while the value of 1 is used to specify
units as a percentage of the available bandwidth. units as a percentage of the available bandwidth. If this
property indicates that the bandwidth units are percentages,
then each of the bandwidth properties expresses a whole-
number percentage, and hence its maximum value is 100.
8.7.3. The Property qpMinBandwidth 8.7.3. The Property qpMinBandwidth
This property defines the minimum bandwidth that should be reserved for This property defines the minimum bandwidth that should be reserved for
this class of traffic. Both relative (i.e., a percentage of the this class of traffic. Both relative (i.e., a percentage of the
bandwidth) and absolute (i.e., bits/second) values can be specified bandwidth) and absolute (i.e., bits/second) values can be specified
according to the value qpBandwidthUnits property. This property is according to the value of the qpBandwidthUnits property. This property
defined as follows. is defined as follows:
NAME qpMinBandwidth NAME qpMinBandwidth
SYNTAX Integer SYNTAX Integer
VALUE The value must be greater than 0. VALUE The value must be greater than 0. If the property
qpMaxBandwidth is defined, then the value of qpMinBandwidth
must be less than or equal to the value of qpMaxBandwidth.
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 50
8.7.4. The Property qpMaxBandwidth 8.7.4. The Property qpMaxBandwidth
This property defines the maximum bandwidth that should be allocated to This property defines the maximum bandwidth that should be allocated to
this class of traffic. Both relative (i.e., a percentage of the this class of traffic. Both relative (i.e., a percentage of the
bandwidth)and absolute (i.e., bits/second) values can be specified bandwidth)and absolute (i.e., bits/second) values can be specified
according to the value qpBandwidthUnits property. This according to the value of the qpBandwidthUnits property. This property
property is defined as follows. is defined as follows:
NAME qpMaxBandwidth NAME qpMaxBandwidth
SYNTAX Integer SYNTAX Integer
VALUE The value must be greater than 0 VALUE The value must be greater than 0. If the property
qpMaxBandwidth is defined, then the value of qpMinBandwidth
Snir, Ramberg, Strassner, Cohen expires November 2001 35 must be less than or equal to the value of qpMaxBandwidth.
8.7.5. The Property qpMaxDelay 8.7.5. The Property qpMaxDelay
This property defines the maximal per-hop delay that traffic of this This property defines the maximal per-hop delay that traffic of this
class should experience while being forwarded through this hop. class should experience while being forwarded through this hop. The
The maximum delay is measured in milliseconds. This property is defined maximum delay is measured in microseconds. This property is defined as
as follows. follows:
NAME qpMaxDelay NAME qpMaxDelay
SYNTAX Integer (milliseconds) SYNTAX Integer (microseconds)
VALUE The value must be greater than 0 VALUE The value must be greater than 0.
8.7.6. The Property qpMaxJitter 8.7.6. The Property qpMaxJitter
This property defines the maximal per-hop delay variance that traffic This property defines the maximal per-hop delay variance that traffic of
of this class should experience while being forwarded through this hop. this class should experience while being forwarded through this hop.The
The maximum jitter is measured in milliseconds. This property is defined maximum jitter is measured in microseconds. This property is defined as
as follows. follows:
NAME qpMaxJitter NAME qpMaxJitter
SYNTAX Integer (milliseconds) SYNTAX Integer (microseconds)
VALUE The value must be greater than 0 VALUE The value must be greater than 0.
8.7.7. The Property qpFairness 8.7.7. The Property qpFairness
This property defines whether fair queuing is required for this class This property defines whether fair queuing is required for this class of
of traffic. This property is defined as follows. traffic. This property is defined as follows:
NAME qpFairness NAME qpFairness
SYNTAX Integer SYNTAX Boolean
VALUE The value of 0 (FALSE) means that fair queuing is not VALUE The value of FALSE means that fair queuing is not required
required for this class of traffic, while the value of 1 for this class of traffic, while the value of TRUE means
(TRUE) means that fair queuing is required for this class that fair queuing is required for this class of traffic.
of traffic.
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 51
8.8. The Class QoSPolicyCongestionControlAction 8.8. The Class QoSPolicyCongestionControlAction
This class is used to control the characteristics of the congestion This class is used to control the characteristics of the congestion
control algorithm being used. The class definition is as follows: control algorithm being used. The class definition is as follows:
NAME QoSPolicyCongestionControlAction NAME QoSPolicyCongestionControlAction
DESCRIPTION This action control congestion control characteristics of DESCRIPTION This action control congestion control characteristics of
the PHB. the PHB.
DERIVED FROM QoSPolicyPBHAction DERIVED FROM QoSPolicyPBHAction (defined in this document)
ABSTRACT False ABSTRACT False
PROPERTIES qpQueueSizeUnits, qpQueueSize, qpDropAlgorithm, PROPERTIES qpQueueSizeUnits, qpQueueSize, qpDropMethod,
qpDropThresholdUnits, qpDropMinThresholdValue, qpDropThresholdUnits, qpDropMinThresholdValue,
qpDropMaxThresholdValue qpDropMaxThresholdValue
Snir, Ramberg, Strassner, Cohen expires November 2001 36
8.8.1. The property qpQueueSizeUnits 8.8.1. The property qpQueueSizeUnits
This property specifies the units in which the qpQueueSize attribute is This property specifies the units in which the qpQueueSize attribute is
measured. The queue size is measured either in number of packets or in measured. The queue size is measured either in number of packets or in
units of time. The time interval specifies the time needed to transmit units of time. The time interval specifies the time needed to transmit
all packets within the queue if the link speed is dedicated entirely for all packets within the queue if the link speed is dedicated entirely to
transmission of packets within this queue. The property definition is: transmission of packets within this queue. The property definition is:
NAME qpQueueSizeUnits NAME qpQueueSizeUnits
SYNTAX IntegerVALUE This property can have two values. If the SYNTAX Integer
value is set to 0, VALUE This property can have two values. If the value is set to 0,
then the unit of measurement is number of packets. If the then the unit of measurement is number of packets. If the
value is set to 1, then the unit of measurement is value is set to 1, then the unit of measurement is
milliseconds. milliseconds.
8.8.2. The Property qpQueueSize 8.8.2. The Property qpQueueSize
This property specifies the queue size in packets or in milliseconds, This property specifies the maximum queue size in packets or in
depending on the value of the qpQueueSizeUnits (0 specifies packets, and milliseconds, depending on the value of the qpQueueSizeUnits (0
1 specifies milliseconds). This property is defined as follows: specifies packets, and 1 specifies milliseconds). This property is
defined as follows:
NAME qpQueueSize NAME qpQueueSize
SYNTAX Integer SYNTAX Integer
VALUE This value must be greater than 0 VALUE This value must be greater than 0.
8.8.3. The Property qpDropAlgorithm Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 52
8.8.3. The Property qpDropMethod
This property specifies the congestion control drop algorithm that This property specifies the congestion control drop algorithm that
should be used for this type of traffic. This property is defined as should be used for this type of traffic. This property is defined as
follows. follows:
NAME qpDropAlgorithm NAME qpDropMethod
SYNTAX Integer SYNTAX Integer
VALUES Three values are currently defined. The value 0 specifies a VALUES Three values are currently defined. The value 0 specifies a
random drop algorithm, the value 1 specifies a tail drop random drop algorithm, the value 1 specifies a tail drop
algorithm, and the value 2 specifies a head drop algorithm. algorithm, and the value 2 specifies a head drop algorithm.
8.8.4. The Property qpDropThresholdUnits 8.8.4. The Property qpDropThresholdUnits
This property specifies the units in which the two properties This property specifies the units in which the two properties
qpDropMinThresholdValue and qpDropMaxThresholdValue are measured. qpDropMinThresholdValue and qpDropMaxThresholdValue are measured.
Thresholds can be measured either in packets or in percentage of the Thresholds can be measured either in packets or as a percentage of the
available queue sizes. This property is defined as follows. available queue sizes. This property is defined as follows:
NAME qpDropThresholdUnits NAME qpDropThresholdUnits
SYNTAX Integer SYNTAX Integer
VALUES Two values are defined. The value 0 defines the units as VALUES Three values are defined. The value 0 defines the units as
number of packets, and the value 1 defines the units number of packets, the value 1 defines the units as a
as a percentage of the queue size. percentage of the queue size and the value 2 defines the
units in milliseconds. If this property indicates that the
Snir, Ramberg, Strassner, Cohen expires November 2001 37 threshold units are percentages, then each of the threshold
properties expresses a whole-number percentage, and hence
its maximum value is 100.
8.8.5. The Property qpDropMinThresholdValue 8.8.5. The Property qpDropMinThresholdValue
This property specifies the minimum number of queuing and buffer This property specifies the minimum number of queuing and buffer
resources that should be reserved for this class of flows. The threshold resources that should be reserved for this class of flows. The threshold
can be specified as either relative (i.e., a percentage) or absolute can be specified as either relative (i.e., a percentage) or absolute
(i.e., number of packets) value according to the value of (i.e., number of packets or millisecond) value according to the value of
qpDropThresholdUnits property. If this property specifies a value of 5 the qpDropThresholdUnits property. If this property specifies a value of
packets, then enough buffer and queuing resources should be reserved to 5 packets, then enough buffer and queuing resources should be reserved
hold 5 packets before running the specified congestion control drop to hold 5 packets before running the specified congestion control drop
algorithm. This property is defined as follows: algorithm. This property is defined as follows:
NAME qpDropMinThresholdValue NAME qpDropMinThresholdValue
SYNTAX Integer SYNTAX Integer
VALUE This value must be greater than 0 VALUE This value must be greater than or equal to 0. If the
property qpDropMaxThresholdValue is defined, then the value
of the qpDropMinThresholdValue property must be less than or
equal to the value of the qpDropMaxThresholdValue property
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 53
8.8.6. The Property qpDropMaxThresholdValue 8.8.6. The Property qpDropMaxThresholdValue
This property specifies the maximum number of queuing and buffer This property specifies the maximum number of queuing and buffer
resources that should be reserved for this class of flows. The threshold resources that should be reserved for this class of flows. The threshold
can be specified as either relative (i.e., a percentage) or absolute can be specified as either relative (i.e., a percentage) or absolute
(i.e., number of packets) value according to the value of the (i.e., number of packets or milliseconds) value according to the value
qpDropThresholdUnits property. Congestion Control droppers should not of the qpDropThresholdUnits property. Congestion Control droppers should
keep more packets than the value specified in this property. Note, not keep more packets than the value specified in this property. Note,
however, that some droppers may calculate queue occupancy averages, however, that some droppers may calculate queue occupancy averages, and
and therefore the actual maximum queue resources should be larger. This therefore the actual maximum queue resources should be larger. This
property is defined as follows: property is defined as follows:
NAME qpDropMaxThresholdValue NAME qpDropMaxThresholdValue
SYNTAX Integer SYNTAX Integer
VALUE This value must be greater than 0 VALUE This value must be greater than or equal to 0. If the
property qpDropMinThresholdValue is defined, then the value
of the qpDropMinThresholdValue property must be less than or
equal to the value of the qpDropMaxThresholdValue property
8.9. Class QoSPolicyTrfcProf 8.9. Class QoSPolicyTrfcProf
This is an abstract base class that models a traffic profile. Traffic This is an abstract base class that models a traffic profile. Traffic
profiles specify the maximum rate parameters used within admission profiles specify the maximum rate parameters used within admission
decisions. The association QosPolicyTrfcProfInAdmissionAction binds the decisions. The association QoSPolicyTrfcProfInAdmissionAction binds the
admission decision to the traffic profile. The class definition is as admission decision to the traffic profile. The class definition is as
follows: follows:
NAME QoSPolicyTrfcProf NAME QoSPolicyTrfcProf
DERIVED FROM Policy DERIVED FROM Policy (defined in [PCIM])
ABSTRACT True ABSTRACT True
PROPERTIES None PROPERTIES None
Snir, Ramberg, Strassner, Cohen expires November 2001 38 8.10. Class QoSPolicyTokenBucketTrfcProf
8.10. Class QosPolicyTokenBucketTrfcProf
This class models a two- or three-level Token Bucket traffic profile. This class models a two- or three-level Token Bucket traffic profile.
This traffic profile carries the policer or shaper rate values to be Additional profiles can be modeled by cascading multiple instances of
enforced on a flow or a set of flows. The class definition is as follows: this class (e.g., by connecting the output of one instance to the input
of another instance). This traffic profile carries the policer or shaper
rate values to be enforced on a flow or a set of flows. The class
definition is as follows:
NAME QosPolicyTokenBucketTrfcProf NAME QoSPolicyTokenBucketTrfcProf
DERIVED FROM QoSPolicyTrfcProf DERIVED FROM QoSPolicyTrfcProf (defined in this document)
ABSTRACT False ABSTRACT False
PROPERTIES qpTBRate, qpTBNormalBurst, qpTBExcessBurst PROPERTIES qpTBRate, qpTBNormalBurst, qpTBExcessBurst
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 54
8.10.1. The Property qpTBRate 8.10.1. The Property qpTBRate
This is a non-negative integer that defines the token rate in kilobits This is a non-negative integer that defines the token rate in kilobits
per second. A rate of zero means that all packets will be out of per second. A rate of zero means that all packets will be out of
profile. This property is defined as follows: profile. This property is defined as follows:
NAME qpTBRate NAME qpTBRate
SYNTAX Integer SYNTAX Integer
VALUE This value must be greater than 0 VALUE This value must be greater than to 0
8.10.2. The Property qpTBNormalBurst 8.10.2. The Property qpTBNormalBurst
This property is an integer that defines the normal size of a burst This property is an integer that defines the normal size of a burst
measured in bytes. This property is defined as follows: measured in bytes. This property is defined as follows:
NAME qpTBNormalBurst NAME qpTBNormalBurst
SYNTAX Integer SYNTAX Integer
VALUE This value must be greater than 0 VALUE This value must be greater than to 0
8.10.3. The Property qpTBExcessBurst 8.10.3. The Property qpTBExcessBurst
This property is an integer that defines the excess size of a burst This property is an integer that defines the excess burst size measured
measured in bytes. This property is defined as follows: in bytes. This property is defined as follows:
NAME qpTBExcessBurst NAME qpTBExcessBurst
SYNTAX Integer SYNTAX Integer
VALUE This value must be greater than 0 VALUE This value must be greater than or equal to qpTBNormalBurst
Snir, Ramberg, Strassner, Cohen expires November 2001 39
8.11. Class qosPolicyIntServTrfcProf 8.11. Class QoSPolicyIntServTrfcProf
This class represents an IntServ traffic profile. Values of IntServ This class represents an IntServ traffic profile. Values of IntServ
traffic profiles are compared against Traffic specification (TSPEC) and traffic profiles are compared against Traffic specification (TSPEC) and
QoS Reservation (FLOWSPEC) requests carried in RSVP requests. The class QoS Reservation (FLOWSPEC) requests carried in RSVP requests. The class
definition is as follows: definition is as follows:
NAME qosPolicyIntServTrfcProf NAME QoSPolicyIntServTrfcProf
DERIVED FROM QosPolicyTrfcProf DERIVED FROM QoSPolicyTrfcProf (defined in this document)
ABSTRACT False ABSTRACT False
PROPERTIES qpISTokenRate, qpISPeakRate, qpISBucketSize, qpISResvRate, PROPERTIES qpISTokenRate, qpISPeakRate, qpISBucketSize, qpISResvRate,
qpISResvSlack, qpISMinPolicedUnit, qpISMaxPktSize qpISResvSlack, qpISMinPolicedUnit, qpISMaxPktSize
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 55
8.11.1. The Property qpISTokenRate 8.11.1. The Property qpISTokenRate
This property is a non-negative integer that defines the token rate This property is a non-negative integer that defines the token rate
parameter, measured in kilobits per second. This property is defined as parameter, measured in kilobits per second. This property is defined as
follows: follows:
NAME qpISTokenRate NAME qpISTokenRate
SYNTAX Integer SYNTAX Integer
VALUE This value must be greater than 0 VALUE This value must be greater than or equal to 0
8.11.2. The Property qpISPeakRate 8.11.2. The Property qpISPeakRate
This property is a non-negative integer that defines the peak rate This property is a non-negative integer that defines the peak rate
parameter, measured in kilobits per second. This property is defined as parameter, measured in kilobits per second. This property is defined as
follows: follows:
NAME qpISPeakRate NAME qpISPeakRate
SYNTAX Integer SYNTAX Integer
VALUE This value must be greater than 0 VALUE This value must be greater than or equal to 0
8.11.3. The Property qpISBucketSize 8.11.3. The Property qpISBucketSize
This property is a non-negative integer that defines the token bucket This property is a non-negative integer that defines the token bucket
size parameter, measured in bytes. This property is defined as follows: size parameter, measured in bytes. This property is defined as follows:
NAME qpISBucketSize NAME qpISBucketSize
SYNTAX Integer SYNTAX Integer
VALUE This value must be greater than 0 VALUE This value must be greater than or equal to 0
Snir, Ramberg, Strassner, Cohen expires November 2001 40
8.11.4. The Property qpISResvRate 8.11.4. The Property qpISResvRate
This property is a non-negative integer that defines the reservation rate This property is a non-negative integer that defines the reservation
(R-Spec) in the RSVP guaranteed service reservation. It is measured in rate (R-Spec) in the RSVP guaranteed service reservation. It is measured
kilobits per second. This property is defined as follows: in kilobits per second. This property is defined as follows:
NAME qpISResvRate NAME qpISResvRate
SYNTAX Integer SYNTAX Integer
VALUE This value must be greater than 0 VALUE This value must be greater than or equal to 0
8.11.5. The Property qpISResvSlack 8.11.5. The Property qpISResvSlack
This property is a non-negative integer that defines the RSVP slack This property is a non-negative integer that defines the RSVP slack term
term in the RSVP guaranteed service reservation. It is measured in in the RSVP guaranteed service reservation. It is measured in
microseconds. This property is defined as follows: microseconds. This property is defined as follows:
NAME qpISResvSlack NAME qpISResvSlack
SYNTAX Integer SYNTAX Integer
VALUE This value must be greater than 0 VALUE This value must be greater than or equal to 0
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 56
8.11.6. The Property qpISMinPolicedUnit 8.11.6. The Property qpISMinPolicedUnit
This property is a non-negative integer that defines the minimum RSVP This property is a non-negative integer that defines the minimum RSVP
policed unit, measured in bytes. This property is defined as follows: policed unit, measured in bytes. This property is defined as follows:
NAME qpISMinPolicedUnit NAME qpISMinPolicedUnit
SYNTAX Integer SYNTAX Integer
VALUE This value must be greater than 0 VALUE This value must be greater than or equal to 0
8.11.7. The Property qpISMaxPktSize 8.11.7. The Property qpISMaxPktSize
This property is a non-negative integer that defines the maximum This property is a positive integer that defines the maximum allowed
allowed packet size for RSVP messages, measure in bytes. This property is packet size for RSVP messages, measured in bytes. This property is
defined as follows: defined as follows:
NAME qpISMaxPktSize NAME qpISMaxPktSize
SYNTAX Integer SYNTAX Integer
VALUE This value must be greater than 0 VALUE This value must be a positive integer, denoting the number
of bytes in the largest payload packet of an RSVP signaled
flow or class.
Snir, Ramberg, Strassner, Cohen expires November 2001 41 8.12. The Class QoSPolicyAttributeValue
8.12. The Class QosPolicyAttributeValue This class can be used for representing an indirection in variable and
value references either in a simple condition ("<x> match <y>") or a
simple action ("<x> = <y>"). In both cases, <x> and <y> are known as the
variable and the value of either the condition or action. The value of
the properties qpAttributeName and qpAttributeValueList are used to
substitute <x> and <y> in the condition or action respectively.
This class is used to represent a single or set of property values in The substitution is done as follows: The value of the property
an object. This value can be used in conjunction with reference values qpAttributeName is used to substitute <x> and the value of the property
carried in RSVP objects, as specified in [RFC2751]. The property name is qpAttributeValueList is used to substitute <y>.
used to specify which of the properties in the object is being used as
the condition. The value of this property will then be retrieved, and a
match (which is dependent on the property name) will be used to see if
the condition is satisfied or not. The class definition is as follows:
NAME QosPolicyAttributeValue Once the substitution is done, the condition can be evaluated and the
DERIVED FROM PolicyImplicitValue action can be performed.
For example, suppose we want to define a condition over a user name of
the form "user == 'Smith'", using the QoSPolicyRSVPUserVariable class.
The user information in the RSVP message provides a DN. The DN points to
a user objects holding many attributes. If the relevant attribute is
"last name", we would use the QoSPolicyAttributeValue class with
qpAttributeName = "Last Name", qpAttributeValueList = {"Smith"}.
The class definition is as follows:
NAME QoSPolicyAttributeValue
DERIVED FROM PolicyValue (defined in [PCIMe])
ABSTRACT False ABSTRACT False
PROPERTIES qpAttributeName, qpAttributeValueList PROPERTIES qpAttributeName, qpAttributeValueList
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 57
8.12.1. The Property qpAttributeName 8.12.1. The Property qpAttributeName
This property defines the name of the attribute that the list of values This property carries the name of the attribute that is to be used to
should be compared against. This property is defined as follows: substitute <x> in a simple condition or simple condition of the forms
"<x> match <y>" or "<x> = <y>" respectively. This property is defined as
follows:
NAME qpAttributeName NAME qpAttributeName
SYNTAX String SYNTAX String
8.12.2. The Property qpAttributeValueList 8.12.2. The Property qpAttributeValueList
This property contains a list of attribute values. Each value is compared This property carries a list of values that is to be used to substitute
to a value of the property specified by the qpAttributeName property. <y> in a simple condition or simple action of the forms "<x> match <y>"
or "<x> = <y>" respectively.
This property is defined as follows: This property is defined as follows:
NAME qpAttributeValueList NAME qpAttributeValueList
SYNTAX String SYNTAX String
8.13. The Class "QoSPolicyRSVPVariable" 8.13. The Class "QoSPolicyRSVPVariable"
This is an abstract class that serves as the base class for all implicit This is an abstract class that serves as the base class for all implicit
variables that have to do with RSVP conditioning. The class definition is variables that have to do with RSVP conditioning. The class definition
as follows: is as follows:
NAME QoSPolicyRSVPVariable NAME QoSPolicyRSVPVariable
DESCRIPTION An abstract base class used to build other classes that DESCRIPTION An abstract base class used to build other classes that
specify different attributes of an RSVP request specify different attributes of an RSVP request
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable (defined in [PCIMe])
ABSTRACT TRUE ABSTRACT TRUE
PROPERTIES None PROPERTIES None
Snir, Ramberg, Strassner, Cohen expires November 2001 42
8.14. The Class "QoSPolicyRSVPSourceIPv4Variable" 8.14. The Class "QoSPolicyRSVPSourceIPv4Variable"
This is a concrete class that contains the source IPv4 address of the This is a concrete class that contains the source IPv4 address of the
RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP
RESV FILTER_SPEC [RSVP] objects. The class definition is as follows: RESV FILTER_SPEC [RSVP] objects. The class definition is as follows:
NAME QoSPolicyRSVPSourceIPv4Variable NAME QoSPolicyRSVPSourceIPv4Variable
DESCRIPTION The source IPv4 address of the RSVP signaled flow, as DESCRIPTION The source IPv4 address of the RSVP signaled flow, as
defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV
FILTER_SPEC [RSVP] objects. FILTER_SPEC [RSVP] objects.
ALLOWED VALUE TYPES: PolicyIPv4AddrValue ALLOWED VALUE TYPES: PolicyIPv4AddrValue
DERIVED FROM QoSPolicyRSVPVariable DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES None PROPERTIES None
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 58
8.15. The Class "QoSPolicyRSVPDestinationIPv4Variable" 8.15. The Class "QoSPolicyRSVPDestinationIPv4Variable"
This is a concrete class that contains the destination IPv4 address of This is a concrete class that contains the destination IPv4 address of
the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and
RSVP RESV FILTER_SPEC [RSVP] objects. The class definition is as follows: RSVP RESV FILTER_SPEC [RSVP] objects. The class definition is as
follows:
NAME QoSPolicyRSVPDestinationIPv4Variable NAME QoSPolicyRSVPDestinationIPv4Variable
DESCRIPTION The destination IPv4 address of the RSVP signaled flow, DESCRIPTION The destination IPv4 address of the RSVP signaled
as defined in the RSVP PATH and RESV SESSION [RSVP] objects. flow, as defined in the RSVP PATH and RESV SESSION
[RSVP] objects.
ALLOWED VALUE TYPES: PolicyIPv4AddrValue ALLOWED VALUE TYPES: PolicyIPv4AddrValue
DERIVED FROM QoSPolicyRSVPVariable DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES None PROPERTIES None
8.16. The Class "QoSPolicyRSVPSourceIPv6Variable" 8.16. The Class "QoSPolicyRSVPSourceIPv6Variable"
This is a concrete class that contains the source IPv6 address of the This is a concrete class that contains the source IPv6 address of the
RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP
RESV FILTER_SPEC [RSVP] objects. The class definition is as follows: RESV FILTER_SPEC [RSVP] objects. The class definition is as follows:
NAME QoSPolicyRSVPSourceIPv6Variable NAME QoSPolicyRSVPSourceIPv6Variable
DESCRIPTION The source IPv6 address of the RSVP signaled flow, as DESCRIPTION The source IPv6 address of the RSVP signaled flow, as
defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV
FILTER_SPEC [RSVP] objects. FILTER_SPEC [RSVP] objects.
ALLOWED VALUE TYPES: PolicyIPv6AddrValue ALLOWED VALUE TYPES: PolicyIPv6AddrValue
DERIVED FROM QoSPolicyRSVPVariable DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES None PROPERTIES None
Snir, Ramberg, Strassner, Cohen expires November 2001 43
8.17. The Class "QoSPolicyRSVPDestinationIPv6Variable" 8.17. The Class "QoSPolicyRSVPDestinationIPv6Variable"
This is a concrete class that contains the destination IPv6 address of This is a concrete class that contains the destination IPv6 address of
the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and
RSVP RESV FILTER_SPEC [RSVP] objects. The class definition is as follows: RSVP RESV FILTER_SPEC [RSVP] objects. The class definition is as
follows:
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 59
NAME QoSPolicyRSVPDestinationIPv6Variable NAME QoSPolicyRSVPDestinationIPv6Variable
DESCRIPTION The destination IPv6 address of the RSVP signaled flow, DESCRIPTION The destination IPv6 address of the RSVP signaled
as defined in the RSVP PATH and RESV SESSION [RSVP] objects. flow, as defined in the RSVP PATH and RESV SESSION
[RSVP] objects.
ALLOWED VALUE TYPES: PolicyIPv6AddrValue ALLOWED VALUE TYPES: PolicyIPv6AddrValue
DERIVED FROM QoSPolicyRSVPVariable DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES None PROPERTIES None
8.18. The Class "QoSPolicyRSVPSourcePortVariable" 8.18. The Class "QoSPolicyRSVPSourcePortVariable"
This is a concrete class that contains the source port of the RSVP This class contains the source port of the RSVP signaled flow, as
signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC
FILTER_SPEC [RSVP] objects. The class definition is as follows: [RSVP] objects. The class definition is as follows:
NAME QoSPolicyRSVPSourcePortVariable NAME QoSPolicyRSVPSourcePortVariable
DESCRIPTION The source port of the RSVP signaled flow, as defined in the DESCRIPTION The source port of the RSVP signaled flow, as defined in
RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP] the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC
objects. [RSVP] objects.
ALLOWED VALUE TYPES: Integer ALLOWED VALUE TYPES: PolicyIntegerValue (0..65535)
DERIVED FROM QoSPolicyRSVPVariable DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES None PROPERTIES None
8.19. The Class "QoSPolicyRSVPDestinationPortVariable" 8.19. The Class "QoSPolicyRSVPDestinationPortVariable"
This is a concrete class that contains the destination port of the RSVP This is a concrete class that contains the destination port of the RSVP
signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV
FILTER_SPEC [RSVP] objects. The class definition is as follows: FILTER_SPEC [RSVP] objects. The class definition is as follows:
NAME QoSPolicyRSVPDestinationPortVariable NAME QoSPolicyRSVPDestinationPortVariable
DESCRIPTION The destination port of the RSVP signaled flow, as defined DESCRIPTION The destination port of the RSVP signaled flow, as
in the RSVP PATH and RESV SESSION [RSVP] objects. defined in the RSVP PATH and RESV SESSION [RSVP] objects.
ALLOWED VALUE TYPES: Integer ALLOWED VALUE TYPES: PolicyIntegerValue (0..65535)
DERIVED FROM QoSPolicyRSVPVariable DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES None PROPERTIES None
Snir, Ramberg, Strassner, Cohen expires November 2001 44 Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 60
8.20. The Class "QoSPolicyRSVPIPProtocolVariable" 8.20. The Class "QoSPolicyRSVPIPProtocolVariable"
This is a concrete class that contains the IP Protocol number of the RSVP This is a concrete class that contains the IP Protocol number of the
signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP] RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP]
objects. The class definition is as follows: objects. The class definition is as follows:
NAME QoSPolicyRSVPIPProtocolVariable NAME QoSPolicyRSVPIPProtocolVariable
DESCRIPTION The IP Protocol number of the RSVP signaled flow, as defined DESCRIPTION The IP Protocol number of the RSVP signaled flow, as
in the RSVP PATH and RESV SESSION [RSVP] objects. defined in the RSVP PATH and RESV SESSION [RSVP] objects.
ALLOWED VALUE TYPES: Integer ALLOWED VALUE TYPES: PolicyIntegerValue
DERIVED FROM QoSPolicyRSVPVariable DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES None PROPERTIES None
8.21. The Class "QoSPolicyRSVPIPVersionVariable" 8.21. The Class "QoSPolicyRSVPIPVersionVariable"
This is a concrete class that contains the IP Protocol version number of This is a concrete class that contains the IP Protocol version number of
the RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION the RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION
[RSVP] objects. The well-known version numbers are 4 and 6. The class [RSVP] objects. The well-known version numbers are 4 and 6. This
definition is as follows: variable allows a policy definition of the type:
"If IP version = IPv4 then ...".
The class definition is as follows:
NAME QoSPolicyRSVPIPVersionVariable NAME QoSPolicyRSVPIPVersionVariable
DESCRIPTION The IP version number of the IP Addresses carried the RSVP DESCRIPTION The IP version number of the IP Addresses carried the
signaled flow, as defined in the RSVP PATH and RESV SESSION RSVP signaled flow, as defined in the RSVP PATH and RESV
[RSVP] objects. SESSION [RSVP] objects.
ALLOWED VALUE TYPES: Integer ALLOWED VALUE TYPES: PolciIntegerValue
DERIVED FROM QoSPolicyRSVPVariable DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES None PROPERTIES None
8.22. The Class "QoSPolicyRSVPDCLASSVariable" 8.22. The Class "QoSPolicyRSVPDCLASSVariable"
This is a concrete class that contains the DSCP value as defined in the This is a concrete class that contains the DSCP value as defined in the
RSVP DCLASS [DCLASS] object. The class definition is as follows: RSVP DCLASS [DCLASS] object. The class definition is as follows:
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 61
NAME QoSPolicyRSVPDCLASSVariable NAME QoSPolicyRSVPDCLASSVariable
DESCRIPTION The DSCP value as defined in the RSVP DCLASS [DCLASS] DESCRIPTION The DSCP value as defined in the RSVP DCLASS [DCLASS]
object. object.
ALLOWED VALUE TYPES: Integer, BitString ALLOWED VALUE TYPES: PolicyIntegerValue,
PolicyBitStringValue
DERIVED FROM QoSPolicyRSVPVariable DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES None PROPERTIES None
Snir, Ramberg, Strassner, Cohen expires November 2001 45
8.23. The Class "QoSPolicyRSVPStyleVariable" 8.23. The Class "QoSPolicyRSVPStyleVariable"
This is a concrete class that contains the reservation style as defined This is a concrete class that contains the reservation style as defined
in the RSVP STYLE object in the RESV message [RSVP]. The class definition in the RSVP STYLE object in the RESV message [RSVP]. The class
is as follows: definition is as follows:
NAME QoSPolicyRSVPStyleVariable NAME QoSPolicyRSVPStyleVariable
DESCRIPTION The reservation style as defined in the RSVP STYLE object DESCRIPTION The reservation style as defined in the RSVP STYLE object
in the RESV message [RSVP]. in the RESV message [RSVP].
ALLOWED VALUE TYPES: BitString, Integer (Integer has an ALLOWED VALUE TYPES: PolicyBitStringValue,
PolicyIntegerValue (Integer has an
enumeration of { Fixed-Filter=1 , enumeration of { Fixed-Filter=1 ,
Shared-Explicit=2, Shared-Explicit=2,
Wildcard-Filter=3} Wildcard-Filter=3}
DERIVED FROM QoSPolicyRSVPVariable DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES None PROPERTIES None
8.24. The Class "QoSPolicyIntServVariable" 8.24. The Class "QoSPolicyIntServVariable"
This is a concrete class that contains the Integrated Service requested This is a concrete class that contains the Integrated Service requested
in the RSVP Reservation message, as defined in the FLOWSPEC RSVP Object in the RSVP Reservation message, as defined in the FLOWSPEC RSVP Object
[RSVP]. The class definition is as follows: [RSVP]. The class definition is as follows:
NAME QoSPolicyRSVPIntServVariable NAME QoSPolicyRSVPIntServVariable
DESCRIPTION The integrated Service requested in the RSVP Reservation DESCRIPTION The integrated Service requested in the RSVP Reservation
message, as defined in the FLOWSPEC RSVP Object [RSVP]. message, as defined in the FLOWSPEC RSVP Object [RSVP].
ALLOWED VALUE TYPES: Integer (An enumerated value of ALLOWED VALUE TYPES: PolicyIntegerValue (An enumerated
{ CL=1 , GS=2, NULL=3} value of { CL=1 , GS=2, NULL=3}
DERIVED FROM QoSPolicyRSVPVariable DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES None PROPERTIES None
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 62
8.25. The Class "QoSPolicyRSVPMessageTypeVariable" 8.25. The Class "QoSPolicyRSVPMessageTypeVariable"
This is a concrete class that contains the RSVP message type, as defined This is a concrete class that contains the RSVP message type, as defined
in the RSVP message common header [RSVP] object. The class definition is in the RSVP message common header [RSVP] object. The class definition is
as follows: as follows:
Snir, Ramberg, Strassner, Cohen expires November 2001 46
NAME QoSPolicyRSVPMessageTypeVariable NAME QoSPolicyRSVPMessageTypeVariable
DESCRIPTION The RSVP message type, as defined in the RSVP message DESCRIPTION The RSVP message type, as defined in the RSVP message
common header [RSVP] object. common header [RSVP] object.
ALLOWED VALUE TYPES: Integer (An enumerated value of ALLOWED VALUE TYPES: Integer (An enumerated value of
{ PATH=1 , PATHTEAR=2, RESV=3, { PATH=1 , PATHTEAR=2, RESV=3,
RESVTEAR=4, ResvErr=5, CONF=6} RESVTEAR=4, ResvErr=5, CONF=6,
PATHERR}
DERIVED FROM QoSPolicyRSVPVariable DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES None PROPERTIES None
8.26. The Class "QoSPolicyRSVPPreemptionPriorityVariable" 8.26. The Class "QoSPolicyRSVPPreemptionPriorityVariable"
This is a concrete class that contains the RSVP reservation priority, as This is a concrete class that contains the RSVP reservation priority, as
defined in [RSVP_PREEMP] object. The class definition is as follows: defined in [RSVP_PREEMP] object. The class definition is as follows:
NAME QoSPolicyRSVPPreemptionPriorityVariable NAME QoSPolicyRSVPPreemptionPriorityVariable
DESCRIPTION The RSVP reservation priority as defined in [RSVP_PREEMP]. DESCRIPTION The RSVP reservation priority as defined in [RSVP_PREEMP].
ALLOWED VALUE TYPES: Integer ALLOWED VALUE TYPES: PolicyIntegerValue
DERIVED FROM QoSPolicyRSVPVariable DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES None PROPERTIES None
8.27. The Class "QoSPolicyRSVPPreemptionDefPriorityVariable" 8.27. The Class "QoSPolicyRSVPPreemptionDefPriorityVariable"
This is a concrete class that contains the RSVP reservation defending This is a concrete class that contains the RSVP reservation defending
priority, as defined in [RSVP_PREEMP] object. The class definition is as priority, as defined in [RSVP_PREEMP] object. The class definition is as
follows: follows:
NAME QoSPolicyRSVPPreemptionDefPriorityVariable NAME QoSPolicyRSVPPreemptionDefPriorityVariable
DESCRIPTION The RSVP preemption reservation defending priority as DESCRIPTION The RSVP preemption reservation defending priority as
defined in [RSVP_PREEMP]. defined in [RSVP_PREEMP].
ALLOWED VALUE TYPES: Integer ALLOWED VALUE TYPES: PolicyIntegerValue
DERIVED FROM QoSPolicyRSVPVariable DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES None PROPERTIES None
Snir, Ramberg, Strassner, Cohen expires November 2001 47 Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 63
8.28. The Class "QoSPolicyRSVPUserVariable" 8.28. The Class "QoSPolicyRSVPUserVariable"
This is a concrete class that contains the ID of the user that initiated This is a concrete class that contains the ID of the user that initiated
the flow as defined in the User Locator string in the Identity Policy the flow as defined in the User Locator string in the Identity Policy
Object [RFC2752]. The class definition is as follows: Object [RFC2752]. The class definition is as follows:
NAME QoSPolicyRSVPUserVariable NAME QoSPolicyRSVPUserVariable
DESCRIPTION The ID of the user that initiated the flow as defined in DESCRIPTION The ID of the user that initiated the flow as defined in
the User Locator string in the Identity Policy Object the User Locator string in the Identity Policy Object
[RFC2752]. [RFC2752].
ALLOWED VALUE TYPES: QoSPolicyDNValue, PolicyStringValue, ALLOWED VALUE TYPES: QoSPolicyDNValue, PolicyStringValue,
QosPolicyAttributeValue QoSPolicyAttributeValue
DERIVED FROM QoSPolicyRSVPVariable DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES None PROPERTIES None
8.29. The Class "QoSPolicyRSVPApplicationVariable" 8.29. The Class "QoSPolicyRSVPApplicationVariable"
This is a concrete class that contains the ID of the application that This is a concrete class that contains the ID of the application that
generated the flow as defined in the application locator string in the generated the flow as defined in the application locator string in the
Application policy object [RFC2872]. The class definition is as follows: Application policy object [RFC2872]. The class definition is as follows:
NAME QoSPolicyRSVPApplicationVariable NAME QoSPolicyRSVPApplicationVariable
DESCRIPTION The ID of the application that generated the flow as DESCRIPTION The ID of the application that generated the flow as
defined in the application locator string in the defined in the application locator string in the
Application policy object [RFC2872]. Application policy object [RFC2872].
ALLOWED VALUE TYPES: QoSPolicyDNValue, PolicyStringValue, ALLOWED VALUE TYPES: QoSPolicyDNValue, PolicyStringValue,
QosPolicyAttributeValue QoSPolicyAttributeValue
DERIVED FROM QoSPolicyRSVPVariable DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES None PROPERTIES None
Snir, Ramberg, Strassner, Cohen expires November 2001 48 Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 64
8.30. The Class "QoSPolicyRSVPAuthMethodVariable" 8.30. The Class "QoSPolicyRSVPAuthMethodVariable"
This is a concrete class that contains the type of authentication used in This is a concrete class that contains the type of authentication used
the Identity Policy Object [RFC2752]. The class definition is as follows: in the Identity Policy Object [RFC2752]. The class definition is as
follows:
NAME QoSPolicyRSVPAuthMethodVariable NAME QoSPolicyRSVPAuthMethodVariable
DESCRIPTION The RSVP Authentication type used in the Identity Policy DESCRIPTION The RSVP Authentication type used in the Identity Policy
Object [RFC2752]. Object [RFC2752].
ALLOWED VALUE TYPES: Integer (An enumeration of { NONE=0, ALLOWED VALUE TYPES: PolicyIntegerValue (An enumeration of
PLAIN-TEXT=1, DIGITAL-SIG = 2, { NONE=0, PLAIN-TEXT=1,
KERBEROS_TKT=3, X509_V3_CERT=4, DIGITAL-SIG = 2, KERBEROS_TKT=3,
PGP_CERT=5} X509_V3_CERT=4, PGP_CERT=5}
DERIVED FROM QoSPolicyRSVPVariable DERIVED FROM QoSPolicyRSVPVariable (defined in this document)
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES None PROPERTIES None
8.31. The Class QoSPolicyDNValue 8.31. The Class QoSPolicyDNValue
This class is used to represent a single or set of Distinguished Name This class is used to represent a single or set of Distinguished Name
[DNDEF] values, including wildcards. A Distinguished Name is a name that [DNDEF] values, including wildcards. A Distinguished Name is a name that
can be used as a key to retrieve an object from a directory service. This can be used as a key to retrieve an object from a directory service.
value can be used in comparison to reference values carried in RSVP This value can be used in comparison to reference values carried in RSVP
policy objects, as specified in [RFC2752]. policy objects, as specified in [RFC2752]. The class definition is as
follows:
The class definition is as follows:
NAME QoSPolicyDNValue NAME QoSPolicyDNValue
DERIVED FROM PolicyImplicitValue DERIVED FROM PolicyValue
ABSTRACT False ABSTRACT False
PROPERTIES qpDNList PROPERTIES qpDNList
8.31.1. The Property qpDNList 8.31.1. The Property qpDNList
This attribute provides an unordered list of strings, each representing This attribute provides an unordered list of strings, each representing
a Distinguished Name (DN) with wildcards. The format of a DN is defined a Distinguished Name (DN) with wildcards. The format of a DN is defined
in [DNDEF]. The asterisk character ("*") is used as wildcard for either in [DNDEF]. The asterisk character ("*") is used as wildcard for either
a single attribute value or a wildcard for an RDN. The order of RDNs is a single attribute value or a wildcard for an RDN. The order of RDNs is
significant. For example: A qpDNList attribute carrying the following significant. For example: A qpDNList attribute carrying the following
value: "OU=Sales, CN=*, O=Widget Inc., *, C=US" value:
matches: "OU=Sales, CN=J. Smith, O=Widget Inc, C=US" and also matches:
"OU=Sales, CN=J. Smith, O=Widget Inc, C=US, CN=CA". "CN=*, OU=Sales, O=Widget Inc., *, C=US" matches:
"CN=J. Smith, OU=Sales, O=Widget Inc, C=US"
and also matches:
"CN=J. Smith, OU=Sales, O=Widget Inc, L=CA, C=US".
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 65
The attribute is defined as follows: The attribute is defined as follows:
NAME qpDNList NAME qpDNList
SYNTAX List of Distinguished Names implemented as strings, each of SYNTAX List of Distinguished Names implemented as strings, each of
which serves as a reference to another object. which serves as a reference to another object.
Snir, Ramberg, Strassner, Cohen expires May 2001 49
8.32. The Class QoSPolicyRSVPSimpleAction 8.32. The Class QoSPolicyRSVPSimpleAction
This action controls the content of RSVP messages and the way RSVP This action controls the content of RSVP messages and the way RSVP
requests are admitted. Depending on the value of its qpRSVPActionType requests are admitted. Depending on the value of its qpRSVPActionType
property, this action directly translates into either a COPS Replace property, this action directly translates into either a COPS Replace
Decision or a COPS Stateless Decision, as defined in COPS for RSVP. Only Decision or a COPS Stateless Decision, or both as defined in COPS for
variables that are subclasses of the QoSPolicyRSVPVariable are allowed to RSVP. Only variables that are subclasses of the QoSPolicyRSVPVariable
be associated with this action. The property definition is as follows: are allowed to be associated with this action. The property definition
is as follows:
NAME QoSPolicyRSVPSimpleAction NAME QoSPolicyRSVPSimpleAction
DESCRIPTION This action controls the content of RSVP messages and the DESCRIPTION This action controls the content of RSVP messages and the
way RSVP requests are admitted. way RSVP requests are admitted.
DERIVED FROM SimplePolicyAction DERIVED FROM SimplePolicyAction (defined in [PCIMe])
ABSTRACT False ABSTRACT False
PROPERTIES qpRSVPActionType PROPERTIES qpRSVPActionType
Restricts the PolicyVariableInSimplePolicyAction aggregation to
QoSPolicyRSVPVariable.
8.32.1. The Property qpRSVPActionType 8.32.1. The Property qpRSVPActionType
This property may contain one or two values to denote the type of RSVP This is a multi-valued property that may contain one value to denote the
action. The value 'REPLACE' denotes a COPS Replace Decision action. The type of RSVP action. The value 'REPLACE' denotes a COPS Replace Decision
value 'STATELESS' denotes a COPS Stateless Decision action. Refer to action. The value 'STATELESS' denotes a COPS Stateless Decision action.
[COPS] for details. This property is multi-value, which means that both The value REPLACEANDSTATELESS denotes both decision actions. Refer to
action types are to be executed. [COPS] for details. This property is single-valued enumerated attribute.
NAME QpRSVPActionType
DESCRIPTION This property specifies whether the action type is for COPS NAME qpRSVPActionType
Replace or Stateless decision or both. DESCRIPTION This property specifies whether the action type is for
COPS Replace, Stateless, or both types of decisions.
SYNTAX Integer SYNTAX Integer
VALUE This is an enumerated integer. A value of 0 specifies a VALUE This is an enumerated integer. A value of 0 specifies a
COPS Replace decision. A value 1 specifies a COPS Stateless COPS Replace decision. A value of 1 specifies a COPS
Decision. Stateless Decision. A value of 2 specifies both COPS
Replace and COPS Stateless decisions.
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 66
9. Acknowledgements 9. Acknowledgements
The authors wish to thank the input of the participants of the Policy The authors wish to thank the input of the participants of the Policy
Framework working group, and especially Bob Moore and Alex Wang for Framework working group, and especially the combined group of the PCIMe
their helpful contributions. coauthors, Lee Rafalow, Andrea Westerinen, Ritu Chadha and Marcus
Brunner. In addition we'd like to acknowledge the valuable contribution
from Ed Ellesson, Joel Halpern and Mircea Pana. Thank you all for your
comments, critique, ideas and general contribution.
10. Security Considerations 10. Security Considerations
The Policy Core Information Model (PCIM) [PCIM] describes the general The Policy Core Information Model [PCIM] describes the general security
security considerations related to the general core policy model. The considerations related to the general core policy model. The extensions
extensions defined in this document do not introduce any additional defined in this document do not introduce any additional considerations
considerations related to security. related to security.
Snir, Ramberg, Strassner, Cohen expires November 2001 50
11. References 11. References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[PCIM] Strassner, J., and E. Ellesson, B. Moore, A. Westerinen, [PCIM] Strassner, J., and E. Ellesson, B. Moore, A. Westerinen,
"Policy Core Information Model -- Version 1 Specification", "Policy Core Information Model -- Version 1 Specification",
RFC 3060, February 2001. RFC 3060, February 2001.
[PCIMe] B. Moore, L. Rafalow, Y. Ramberg, Y. Snir, J. Strassner, [PCIMe] B. Moore, L. Rafalow, Y. Ramberg, Y. Snir, J. Strassner,
A. Westerinen, R. Chadha, M. Brunner, R. Cohen, A. Westerinen, R. Chadha, M. Brunner, R. Cohen,
"Policy Core Information Model Extensions", "Policy Core Information Model Extensions",
<draft-ietf-policy-pcim-ext-01.txt> <draft-ietf-policy-pcim-ext-06.txt>
[TERMS] A. Westerinen, J. Schnizlein, J. Strassner, M. Scherling, [TERMS] A. Westerinen, J. Schnizlein, J. Strassner, M. Scherling,
B. Quinn, J. Perry, S. Herzog, A. Huynh, M. Carlson, B. Quinn, J. Perry, S. Herzog, A. Huynh, M. Carlson,
S. Waldbusser, "Terminology", S. Waldbusser, "Terminology",
<draft-ietf-policy-terminology-02.txt> <draft-ietf-policy-terminology-04.txt>
[QDDIM] J. Strassner, A. Westerinen, B. Moore, D. Durham, W. Weiss,
"Information Model for Describing Network Device QoS Mechanisms
for Differentiated Services",
<draft-ietf-policy-qos-device-info-model-02.txt>
[DIFFSERV] S. Blake, et. Al., "An Architecture for Differentiated [DIFFSERV] S. Blake, et. Al., "An Architecture for Differentiated
Services", RFC 2475 Services", RFC 2475
[UML] Please see the following web page for the latest (1.3 as of this
writing) UML specification:
http://www.rational.com/uml/resources/documentation/index.jsp
[INTSERV] R. Braden, D. Clark, S. Shenker, "Integrated Services in [INTSERV] R. Braden, D. Clark, S. Shenker, "Integrated Services in
the Internet Architecture: an Overview", RFC 1633. the Internet Architecture: an Overview", RFC 1633.
[RSVP] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, [RSVP] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC2205 Specification", RFC2205
[QoSSCHEMA] Y. Snir, Y. Ramberg, J. Strassner, R. Cohen, "Policy QoS
LDAP Schema", <draft-ietf-policy-qos-schema-02.txt>
[RFC2749] S . Herzog, Ed., J. Boyle, R. Cohen, D. Durham, R. Rajan, [RFC2749] S . Herzog, Ed., J. Boyle, R. Cohen, D. Durham, R. Rajan,
A. Sastry, "COPS usage for RSVP", RFC2749 A. Sastry, "COPS usage for RSVP", RFC2749
[RFC2751] S. Herzog, "Signaled Preemption Priority Policy Element", [RFC2751] S. Herzog, "Signaled Preemption Priority Policy Element",
RFC2751 RFC2751
Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 67
[DIFF-MIB] F. Baker, K. Chan, A. Smith, "Management Information Base [DIFF-MIB] F. Baker, K. Chan, A. Smith, "Management Information Base
for the Differentiated Services Architecture", for the Differentiated Services Architecture",
<draft-ietf-diffserv-mib-09.txt> <draft-ietf-diffserv-mib-16.txt>
Snir, Ramberg, Strassner, Cohen expires November 2001 51
[AF] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured Forwarding [AF] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured
PHB Group", RFC2597 Forwarding PHB Group", RFC2597
[CL] J. Wroclawski, "Specification of the Controlled-Load Network [CL] J. Wroclawski, "Specification of the Controlled-Load Network
Element Service", RFC2211 Element Service", RFC2211
[RSVP-IS] J. Wroclawski, "The Use of RSVP with IETF Integrated [RSVP-IS] J. Wroclawski, "The Use of RSVP with IETF Integrated
Services", RFC2210 Services", RFC2210
[GS] S. Shenker, C. Partridge, R. Guerin, "Specification of the [GS] S. Shenker, C. Partridge, R. Guerin, "Specification of the
Guaranteed Quality of Service", RFC2212 Guaranteed Quality of Service", RFC2212
skipping to change at line 2478 skipping to change at line 3296
Yoram Snir Yoram Snir
Cisco Systems Cisco Systems
4 Maskit Street 4 Maskit Street
Herzliya Pituach, Israel 46766 Herzliya Pituach, Israel 46766
Phone: +972-9-970-0085 Phone: +972-9-970-0085
Fax: +972-9-970-0366 Fax: +972-9-970-0366
E-mail: ysnir@cisco.com E-mail: ysnir@cisco.com
John Strassner John Strassner
Cisco Systems Intelliden Corporation
725 Alder Drive, , Building 20 90 South Cascade Avenue
Milpitas, CA 95035 Colorado Springs, Colorado 80903
Phone: +1-408-527-1069 Phone: +1-719-785-0648
Fax: +1-408-527-2477 Fax: +1-719-785-0644
E-mail: johns@cisco.com E-mail: john.strassner@intelliden.com
Snir, Ramberg, Strassner, Cohen expires November 2001 52 Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 68
Ron Cohen Ron Cohen
Ntear LLC Ntear LLC
Phone: Phone: +972-8-9402586
Fax: Fax: +972-9-9717798
E-mail: ronc@ntear.com E-mail: ronc@ntear.com
Bob Moore
IBM Corporation
P. O. Box 12195, BRQA/502/G106
3039 Cornwallis Rd.
Research Triangle Park, NC 27709-2195
Phone: +1 919-254-4436
Fax: +1 919-254-6243
E-mail: remoore@us.ibm.com
13. Full Copyright Statement 13. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself on all such copies and derivative works. However, this document itself
skipping to change at line 2519 skipping to change at line 3346
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE. FITNESS FOR A PARTICULAR PURPOSE.
Snir, Ramberg, Strassner, Cohen expires November 2001 53 Snir, Ramberg, Strassner, Cohen, Moore expires May 2002 69
 End of changes. 374 change blocks. 
1119 lines changed or deleted 1946 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/