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

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