Policy Framework Working Group Y. Snir
INTERNET-DRAFT Y. Ramberg
Category: Standards Track J. Strassner
Cisco Systems
R. Cohen
Ntear LLC
April 2001
Policy QoS Information Model
<draft-ietf-policy-qos-info-model-03.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and
may be updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use Internet-Drafts as reference material or to
cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document presents an object-oriented information model for
representing network QoS policies. This document is based on the IETF
Policy Core Information Model and its extensions as specified by [PCIM]
and [PCIMe]. This draft builds upon these two documents to define an
information model for QoS enforcement for differentiated and integrated
services using policy. It is important to note that this document defines
an information model, which by definition is independent of any
particular data storage mechanism and access protocol.
Definition of Key Word Usage
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [KEYWORDS].
Snir, Ramberg, Strassner, Cohen expires November 2001 1
draft-ietf-policy-qos-info-model-03.txt April 2001
Table of Contents
1. Introduction 5
1.1. Goals 5
1.1.1. Modeling Abstract QoS Policies 5
1.1.2. Enhancing Interoperability 6
1.1.3. Intended Audiences 7
1.2. QPIM Characteristics 8
1.3. QPIM and Other Published Standards 10
2. Class Hierarchies 11
2.1. Inheritance Hierarchy 11
2.2. Relationship Hierarchy 13
3. QoS Actions 14
3.1. Overview 14
3.2. RSVP Policy Actions 15
3.3. Provisioning Policy Actions 16
3.3.1. Admission Actions: Controlling Policers and Shapers 17
3.3.2. Controlling Markers 18
3.3.3. Controlling Edge Policies Çô Examples 18
3.4. Per-Hop Behavior Actions 20
3.4.1. Controlling Bandwidth and Delay 21
3.4.2. Congestion Control Actions 21
3.4.3. Using Hierarchical Policies Çô Examples for PHB Actions 22
4. Traffic Profiles 23
4.1. Provisioning Traffic Profiles 24
4.2. RSVP Traffic Profiles 24
5. Pre-Defined QoS-Related Variables 25
6. QoS Related Values 27
7. Class Definitions: Association Hierarchy 28
7.1. The Association "QoSPolicyTrfcProfInAdmissionAction" 28
7.1.1. The Reference "Antecedent" 28
7.1.2. The Reference "Dependent" 28
7.2. The Association "PolicyConformAction" 28
7.2.1. The Reference "Antecedent" 29
7.2.2. The Reference "Dependent" 29
7.3. The Association "PolicyExcessAction" 29
7.3.1. The Reference "Antecedent" 29
7.3.2. The Reference "Dependent" 29
7.4. The Association "PolicyViolateAction" 30
7.4.1. The Reference "Antecedent" 30
7.4.2. The Reference "Dependent" 30
Snir, Ramberg, Strassner, Cohen expires November 2001 2
draft-ietf-policy-qos-info-model-03.txt April 2001
Table of Contents (continued)
8. Class Definitions: Inheritance Hierarchy 31
8.1. The Class QoSPolicyDiscardAction 31
8.2. The Class QoSPolicyAdmissionAction 31
8.2.1. The Property qpAdmissionScope 31
8.3. The Class QoSPolicyPoliceAction 32
8.4. The Class QoSPolicyShapeAction 32
8.5. The Class QoSPolicyRSVPAdmissionAction 33
8.5.1. The Property qpRSVPWarnOnly 33
8.5.2. The Property qpRSVPMaxSessions 33
8.6. The Class QoSPolicyPHBAction 34
8.6.1. The Property qpPacketSize 34
8.7. The Class QoSPolicyBandwidthAction 34
8.7.1. The Property qpForwardingPriority 35
8.7.2. The Property qpBandwidthUnits 35
8.7.3. The Property qpMinBandwidth 35
8.7.4. The Property qpMaxBandwidth 35
8.7.5. The Property qpMaxDelay 36
8.7.6. The Property qpMaxJitter 36
8.7.7. The Property qpFairness 36
8.8. The Class QoSPolicyCongestionControlAction 36
8.8.1. The Property qpSizeUnits 37
8.8.2. The Property qpQueueSize 37
8.8.3. The Property qpDropAlgorithm 37
8.8.4. The Property qpDropThresholdUnits 37
8.8.5. The Property qpDropMinThresholdValue 38
8.8.6. The Property qpDropMaxThresholdValue 38
8.9. The Class QoSPolicyTrfcProf 38
8.10. The Class QoSPolicyTokenBucketTrfcProf 39
8.10.1. The Property qpTBRate 39
8.10.2. The Property qpTBNormalBurst 39
8.10.3. The Property qpTBExcessBurst 39
8.11. The Class QoSPolicyIntServTrfcProf 40
8.11.1. The Property qpISTokenRate 40
8.11.2. The Property qpISPeakRate 40
8.11.3. The Property qpISBucketSize 40
8.11.4. The Property qpISResvRate 41
8.11.5. The Property qpISResvSlack 41
8.11.6. The Property qpISMinPolicedUnit 41
8.11.7. The Property qpISMaxPktSize 41
8.12. The Class QoSPolicyAttributeValue 42
8.12.1. The Property qpAttributeName 42
8.12.2. The Property qpAttributeValueList 42
8.13. The Class QoSPolicyRSVPVariable 42
8.14. The Class QoSPolicyRSVPSourceIPv4Variable 43
8.15. The Class QoSPolicyRSVPDestinationIPv4Variable 43
8.16. The Class QoSPolicyRSVPSourceIPv6Variable 43
8.17. The Class QoSPolicyRSVPDestinationIPv6Variable 44
8.18. The Class QoSPolicyRSVPSourcePortVariable 44
8.19. The Class QoSPolicyRSVPDestinationPortVariable 44
Snir, Ramberg, Strassner, Cohen expires November 2001 3
draft-ietf-policy-qos-info-model-03.txt April 2001
Table of Contents (continued)
8.20. The Class QoSPolicyRSVPIPProtocolVariable 45
8.21. The Class QoSPolicyRSVPIPVersionVariable 45
8.22. The Class QoSPolicyRSVPDCLASSVariable 45
8.23. The Class QoSPolicyRSVPStyleVariable 46
8.24. The Class QoSPolicyRSVPIntServVariable 46
8.25. The Class QoSPolicyRSVPMessageTypeVariable 46
8.26. The Class QoSPolicyRSVPPreemptionPriorityVariable 47
8.27. The Class QoSPolicyRSVPPreemptionDefPriorityVariable 47
8.28. The Class QoSPolicyRSVPUserVariable 48
8.29. The Class QoSPolicyRSVPApplicationVariable 48
8.30. The Class QoSPolicyRSVPAuthMethodVariable 49
8.31. The Class QosPolicyDNValue 49
8.31.1. The Property qpDNList 49
8.32. The Class QoSPolicyRSVPSimpleAction 50
8.32.1. The Property qpRSVPActionType 50
9. Acknowledgements 50
10. Security Considerations 50
11. References 51
12. Authors' Addresses 52
13. Full Copyright Statement 53
Snir, Ramberg, Strassner, Cohen expires November 2001 4
draft-ietf-policy-qos-info-model-03.txt April 2001
1. Introduction
This document presents an object-oriented information model for
representing network QoS policies. This document is based on the IETF
Policy Core Information Model and its extensions as specified by [PCIM]
and [PCIMe]. This draft builds upon these two documents to define an
information model for QoS enforcement for differentiated and integrated
services using policy. It is important to note that this document defines
an information model, which by definition is independent of any
particular data storage mechanism and access protocol.
The following subsections describe the goals and purposes of the QoS
Policy Information Model (QPIM), its intended audience, and its
relationships to other published standards.
1.1 Goals
This section explains the goals for creating QPIM.
1.1.1. Modeling Abstract QoS Policies
The main goal of the QPIM is to create an information model that can be
used to help bridge part of the conceptual gap between a human policy
maker and a network element that is configured to enforce the policy.
Clearly this wide gap implies several translation levels, from the
abstract to the concrete. At the abstract end are the business QoS policy
rules. QPIM facilitates a formal representation of network QoS business
rules, thus providing the first concretization level: formally
representing humanly expressed QoS policy.
When a human business executive defines network policy, it is usually
done using informal business terms and language. For example, a human may
utter a policy statement that reads: "traffic generated by our human-
resources application should have higher priority for making it through
to its destination compared to traffic generated by people browsing the
WEB during their lunch breaks". While this statement clearly defines QoS
policy for the network, the network itself cannot enforce it. Translation
to "network terms and language" is required.
On the other end of the scale, a network element functioning as a Policy
Enforcement Point (PEP, see [TERMS] for its definition), such as a
router, can be configured with specific commands that determine the
operational parameters of its inner working QoS mechanisms. For example,
the (imaginary) command "output-queue-depth = 100" may be an instruction
to a network interface card of a router to allow up to 100 packets to be
stored before subsequent packets are discarded (not forwarded). On a
different device within the same network, the same instruction may take
another form, because a different vendor built that device or it has a
different set of functions, and hence implementation, even though it is
from the same vendor. In addition, a particular PEP may not have the
ability to create queues that are longer than, say, 50 packets, which may
result in a different instruction implementing the same business policy.
Snir, Ramberg, Strassner, Cohen expires November 2001 5
draft-ietf-policy-qos-info-model-03.txt April 2001
The first example illustrates 'abstract policy', while the second
illustrates 'concrete configuration'. Furthermore, the first example
illustrates end-to-end policy, which covers the conditioning of
application traffic throughout the network. The second example
illustrates configuration for a particular PEP or a set thereof. While an
end-to-end policy statement can only be enforced by configuration of PEPs
in various parts of the network, the information model of policy and that
of the mechanisms that a PEP uses to implement that policy is vastly
different.
The translation process from abstract business policy to concrete PEP
configuration is roughly expressed as follows:
1. Informal business QoS policy is expressed by a human policy maker
(e.g. "All executives' WEB requests should be prioritized")
2. A network administrator models the informal policy by using QPIM
constructs, thus creating a formal representation of the abstract
policy. (e.g. "If packet's protocol is HTTP and its destination is in
the 'EXECUTIVES' user group, then assign IPP 7 to the packet header").
Note that the administrator is very likely to use a particular data
model (e.g., LDAP schema) that is mapped to QPIM.
3. The network administrator maps the abstract, formal policy to PEPs
(most likely by using roles, as specified in [PCIMe, sections 2.2.4
and 4.6]).
4. A configuration/distribution agent (or a PDP Çô see [TERMS] for its
definition) consults a device capability model to determine how to
translate the policy into device configuration. An example for a
standards-based capability model is [QDDIM]. Note that one or more
such translations are possible, depending on the particular
capabilities of a given PEP and the implementation of the system.
5. For each PEP in the network, the configuration/distribution agent
configures the appropriate instructions to enforce the policy.
QPIM is intended to be the bridging mechanism between step #1 and step #2
in the methodology just described.
1.1.2. Enhancing Interoperability
Another goal of QPIM is to facilitate interoperability among policy
systems, PDPs in particular. QPIM accomplishes its interoperability goal
by standardizing a representation of policy. Producers and consumers of
QoS policy need only rely on QPIM-based schemata (or data models) to
ensure mutual understanding and agreement on the semantics of QoS policy.
For example, suppose that a QoS policy management application, built by
vendor A, writes its policies based on an LDAP schema that maps from QPIM
to a directory implementation.A separately built PDP from vendor B may
then read this policy and "understand" it as both the management
application and the PDP were architected to comply with the QPIM
standard.
Snir, Ramberg, Strassner, Cohen expires November 2001 6
draft-ietf-policy-qos-info-model-03.txt April 2001
Interoperability of QPIM producers/consumers is by definition at a high
level, and does not guarantee that the same policy will result in the
same PEP configuration. First, different PEPs will have different
capabilities and functions, which necessitate different individual
configurations even if the different PEPs are controlled by the same
policy. Second, different PDPs will also have different capabilities and
functions, and may choose to translate the high-level QPIM policy
differently depending on the functionality of the PDP as well as the
capabilities of the PEPs that are being controlled by the PDP. Finally,
the same policy may be interpreted slightly differently depending on
various factors. For example, a QPIM policy rule that reads "If packet's
protocol is HTTP then assign 7 to IPP", may result in different
configurations depending on how that rule is implemented. For example, an
application recognition mechanism can be used to enforce the policy. If
the device does not supports this particular mechanism, then an alternate
mechanism must be used. For example, the packets could be classified
based on their destination TCP port.
Therefore, we define interoperability of QoS policies as the ability to
specify a policy rule in a standard format. The advantage is that such a
policy can be understood by PDPs and PEPs manufactured from different
vendors having different capabilities and functionality, as well as
policy-based applications. We specifically do not require a policy to be
translated into exactly the same configuration in different PEPs. This is
why we view the above two systems that differ in the interpretation of
recognizing WEB traffic as interoperable with regard to policy. The
advantage of using QPIM policies is that incompatible device capabilities
may still be employed and controlled using the QPIM policy.
1.1.3. Intended Audiences
QPIM is intended for several audiences. The following lists some of the
intended audiences and their respective uses:
1. Application vendors who build QoS policy management applications can
use this model as an extensible framework for defining policies to
control PEPs and PDPs in an interoperable manner
2. Developers of Policy Decision Point (PDP) systems can use this
framework to develop interoperable policies
3. QoS policy makers who seek a standardized model for expressing a
formal representation of QoS policy can use this model to control PEPs
of varying capabilities and functionality
4. Builders of large organization data and knowledge bases who decide to
combine QoS policy information with other networking policy
information, assuming all modeling is based on [PCIM] and [PCIMe]
5. Authors of various standards may use constructs introduced in this
document to enhance their work. Authors of data models wishing to map
a storage specific technology to QPIM must use this document as well.
Snir, Ramberg, Strassner, Cohen expires November 2001 7
draft-ietf-policy-qos-info-model-03.txt April 2001
1.2. QPIM Characteristics
First, a general statement that characterizes QPIM:
"The QoS Policy Information Model (QPIM) establishes a standard framework
and constructs for specifying and representing business QoS policies.
This framework consists of a set of classes and relationships, organized
in an object-oriented information model. It is agnostic of any specific
PDP or PEP implementation and independent of any particular QoS
technology mechanism. It is intended to be used to control the
provisioning of end-to-end network services."
In the rest of this section, we itemize and expand the general statement
presented above.
1. QPIM, as the name implies, is a QoS Policy Information Model. This
means that it only models QoS concepts. These concepts are either
derived in this document, or adapted for use in modelingQoS from other
documents.
2. QPIM is an information model. As such, it is independent of any
specific data storage mechanism and access protocol. QPIM's constructs
may be mapped to various storage and data organization technologies. A
data model mapped to QPIM can be created in a relational database, an
object oriented database, an LDAP directory and more. Because QPIM is
not a schema, the reader is encouraged to focus on the conceptual
level and not on the data organization methodology. Clearly a mapped
schema would include enhancements and optimizations not appropriate in
the information-modeling realm. For example, a given association
between two classes is always modeled as an association class in QPIM.
A given schema may find it useful and efficient to model such a
relationship using a reference object attribute in a directory or a
keyÇôforeign key relationship in a relational database.
3. QPIM is standard. The model standardizes the process of specifying
business QoS policies. It is an interpretation and extension of the
core policy information model as defined in [PCIM] and [PCIMe]. It
references other IETF standards (e.g. [TERMS], [DIFFSERV] and others)
and is meant to enhance interoperability of QoS systems from different
vendors.
QPIM establishes a conceptual framework by fully and closely following
the core policy framework as specified in [PCIM] and [PCIMe]. QPIM
inherits all of its constructs from the core model, providing QoS
interpretation and extensions where necessary.
4. QPIM is object oriented. The modeling methodology is based on UML
(Unified Modeling Language [UML]. This is a ubiquitous modeling method
that is easy to understand and read. In addition, UML-based models
lend themselves to further extensions and natural progression toward
detailed data models.
Snir, Ramberg, Strassner, Cohen expires November 2001 8
draft-ietf-policy-qos-info-model-03.txt April 2001
5. QPIM is a formal model. It expresses its concepts by describing and
defining classes and inter-class associations. Classes are formal
definitions of major concepts. For example, the concept of a traffic
profile is represented by the QosPolicyTrfcProf (abstract) class. A
derivative of this class provides several attributes to describe the
traffic in terms of average rate and other characteristics.
Associations represent relationships among instances of different
classes or the same class. For example, the association
QoSPolicyViolateAction links a certain restriction on traffic
(represented by an instance of the QoSPolicyPoliceAction class) to an
action to be taken when the restriction is violated.
6. QPIM is abstract. The model is aimed at the formalization of humanly
expressed business QoS policies. For example, QPIM provides the means
of expressing formally a business policy that states: "In our network,
IP telephony should receive the same service quality as that of our
legacy phone systems". QPIM provides the topmost link from the
abstract business policy to the concrete device implementation by
expressing the abstract business policy in high-level networking
terms. QPIM compliant tools can be built to further concretize the
high-level QoS policies defined in QPIM terms so that actual network
elements (PEPs) can be configured to enforce the abstract business
policy.
7. QPIM is QoS technology-agnostic, as it assumes no particular mechanism
(e.g., class-based weighted fair queuing) for policy enforcement. For
example, a certain policy may require that traffic adhere to a given
traffic profile. The traffic profile itself can be represented by an
instance of the QosPolicyTrfcProf class. The properties of the profile
class may include an attribute representing the average rate of
traffic in units of bits per second. However, QPIM neither describes
nor mandates a mechanism to perform the measuring mechanism itself.
Specifying such mechanisms is in the realm of network modeling, not
policy modeling.
Though a particular QoS mechanism (e.g., class-based weighted fair
queuing) is generic to many types of devices, individual devices may
implement this generic mechanism differently. This necessitates a
device-independent view of controlling QoS mechanisms, which is
precisely what QPIM is intended for. A single QPIM policy can be
translated into different configurations of different devices. For
example, a network interface card that can be configured to implement
several output queues and assign size and bandwidth allocation
parameters to each of them is a concrete element whose configuration
can be controlled with QPIM policies.
Snir, Ramberg, Strassner, Cohen expires November 2001 9
draft-ietf-policy-qos-info-model-03.txt April 2001
8. QPIM adheres to and interprets the two predominant QoS paradigms:
Differentiated (DiffServ) Services and Integrated Services (IntServ).
While both DiffServ and IntServ inherently model technology, the
mechanisms implementing those technologies are not specified and are
left to the implementer's interpretation. DiffServ and IntServ are
described in [DIFFSERV] and [INTSERV], respectively. The term RSVP
refers to a protocol developed to implement IntServ [RSVP]. The terms
IntServ and RSVP are sometime used interchangeably.
9. QPIM is a network-end-to-end model. This means that QPIM policies can
describe the QoS allocated to traffic throughout the network. QPIM
does not represent explicitly network topological concepts. Section
4.6 of [PCIMe] explains a role based mechanism that can be used for
mapping policies to PEPs. Neither [PCIM], [PCIMe] nor [QPIM] require a
particular topological view of the network in order to express
abstract policy.
1.3. QPIM and Other Published Standards
QPIM makes extensive use of the concepts and constructs that are
introduced by [PCIM] and [PCIMe]. The entire QPIM class hierarchy is
derived from [PCIM] and [PCIMe] classes. The concepts of policy, policy
groups, policy conditions, reusable objects values and variables are used
in QPIM directly. QPIM only introduces extensions where QoS actions,
values and variables are necessary to add QoS specific semantics to the
framework defined by [PCIM] and [PCIMe].
By modeling the information of both predominant QoS paradigms, DiffServ
and IntServ, QPIM unifies the two methodologies using a single class
inheritance tree, thus allowing a single context for thinking about QoS
policy.
Companion documents (e.g., [QoSSCHEMA]) define the mapping of QPIM's
classes to specific data models (schemata). For example, [QoSSCHEMA]
defines how to map the data in this information model to a form that can
be stored in a directory that uses LDAPv3 as its access protocol.
QPIM adheres to terminology as defined in [TERMS].
QPIM intentionally avoids references to documents that present network
models. A network model is the OBJECT of policy. QPIM models the SUBJECT
of policy. The latter distinction makes it inappropriate for QPIM to
model the actual network. An example for network modeling is available in
[QDDIM], a document that models QoS device data path and capabilities.
Snir, Ramberg, Strassner, Cohen expires November 2001 10
draft-ietf-policy-qos-info-model-03.txt April 2001
2. Class Hierarchies
2.1. Inheritance Hierarchy
QPIM's inheritance hierarchy is rooted in [PCIM] and [PCIMe]. Figures 1
and 2 depict the QPIM inheritance hierarchy while noting its
relationships to [PCIM] and [PCIMe] classes. Figure 1 shows the QPIM
inheritance hierarchy,.
[ManagedElement] (abstract, PCIM)
|
+--Policy (abstract, PCIM)
| |
| +---PolicyAction (abstract, PCIM)
| | |
| | +---SimplePolicyAction (PCIMe)
| | | |
| | | +---QoSPolicyRSVPSimpleAction (QPIM)
| | |
| | +---QoSPolicyDiscardAction (QPIM)
| | |
| | +---QoSPolicyAdmissionAction (abstract, QPIM)
| | | |
| | | +---QoSPolicyPoliceAction (QPIM)
| | | |
| | | +---QoSPolicyShapeActionAction (QPIM)
| | | |
| | | +---QoSPolicyRSVPAdmissionAction (QPIM)
| | |
| | +---QosPolicyPHBAction (abstract, QPIM)
| | |
| | +---QoSPolicyBandwidthAction (QPIM)
| | |
| | +---QoSPolicyCongestionControlAction (QPIM)
| |
| +---QosPolicyTrfcProf (abstract, QPIM)
| | |
| | +---QosPolicyTokenBucketTrfcProf (QPIM)
| | |
| | +---QosPolicyIntServTrfcProf (QPIM)
| |
(continued on the next page)
Snir, Ramberg, Strassner, Cohen expires November 2001 11
draft-ietf-policy-qos-info-model-03.txt April 2001
(continued from the previous page)
[ManagedElement] (abstract, PCIM, repeated for convenience)
|
+--Policy (abstract, PCIM, repeated for convenience)
| |
| +---PolicyVariable (abstract, PCIMe)
| | |
| | +---PolicyImplicitVariable (abstract, PCIMe)
| | |
| | +---QoSPolicyRSVPVariable (abstract, QPIM)
| | |
| | +---QoSPolicyRSVPSourceIPv4Variable (QPIM)
| | |
| | +---QoSPolicyRSVPDestinationIPv4Variable (QPIM)
| | |
| | +---QoSPolicyRSVPSourceIPv6Variable (QPIM)
| | |
| | +---QoSPolicyRSVPDestinationIPv6Variable (QPIM)
| | |
| | +---QoSPolicyRSVPSourcePortVariable (QPIM)
| | |
| | +---QoSPolicyRSVPDestinationPortVariable (QPIM)
| | |
| | +---QoSPolicyRSVPIPProtocolVariable (QPIM)
| | |
| | +---QoSPolicyRSVPIPVersionVariable (QPIM)
| | |
| | +---QoSPolicyRSVPDCLASSVariable (QPIM)
| | |
| | +---QoSPolicyRSVPStyleVariable (QPIM)
| | |
| | +---QoSPolicyRSVPDIntServVariable (QPIM)
| | |
| | +---QoSPolicyRSVPMessageTypeVariable (QPIM)
| | |
| | +---QoSPolicyRSVPPreemptionPriorityVariable (QPIM)
| | |
| | +---QoSPolicyRSVPPreemptionDefPriorityVariable (QPIM)
| | |
| | +---QoSPolicyRSVPUserVariable (QPIM)
| | |
| | +---QoSPolicyRSVPApplicationVariable (QPIM)
| | |
| | +---QoSPolicyRSVPAuthMethodVariable (QPIM)
| |
| +---PolicyValue (abstract, PCIMe)
| | |
| | +---QoSPolicyDNValue (QPIM)
| | |
| | +---QoSPolicyAttributeValue (QPIM)
Figure 1. The QPIM Inheritance Hierarchy
Snir, Ramberg, Strassner, Cohen expires November 2001 12
draft-ietf-policy-qos-info-model-03.txt April 2001
2.2. Relationship Hierarchy
Figure 2 shows the QPIM association hierarchy.
[unrooted] (abstract, PCIM)
|
+---Dependency (abstract)
| |
| +--- QosPolicyTrfcProfInAdmissionAction (QPIM)
| |
| +--- QoSPolicyConformAction (QPIM)
| |
| +--- QoSPolicyExceedAction (QPIM)
| |
| +--- QoSPolicyViolateAction (QPIM)
Figure 2. The QPIM Association Hierarchy
Snir, Ramberg, Strassner, Cohen expires November 2001 13
draft-ietf-policy-qos-info-model-03.txt April 2001
3. QoS Actions
This section describes the QoS actions that are modeled by QPIM. QoS
actions are policy enforced network behaviors that are specified for
traffic selected by QoS conditions. QoS actions are modeled using the
classes PolicyAction (defined in [PCIM]), SimplePolicyAction (defined in
[PCIMe]) and several QoS actions defined in this document (described
below).
3.1 Overview
QoS policy based systems allow the network administrator to specify a set
of rules that control both the selection of the flows that need to be
provided with a preferred forwarding treatment, as well as specifying the
specific set of preferred forwarding behaviors. QPIM provides an
information model for specifying such a set of rules.
QoS policy rules allow controlling environments in which RSVP signaling
is used to request different forwarding treatment for different traffic
types from the network as well as environments where no signaling is
used, but preferred treatment is desired for some (not all) traffic. QoS
policy rules allow controlling environments where strict QoS guarantees
are provided to individual flows as well as environments where QoS is
provided to flow aggregates. QoS actions allow a PDP or a PEP to
determine which RSVP requests should be admitted because they satisfy a
given policy, before network resources are allocated. They allow control
of the RSVP signaling content itself, as well as differentiation between
priorities of requests. QoS actions also allow specification of the
Differential Service edge enforcement including policing, shaping and
marking, as well as the per-hop behaviors used in the network core.
Finally, QoS actions can be used to control mapping of RSVP request at
the edge of a differential service cloud into per hop behaviors.
Four groups of actions are derived from action classes defined in [PCIM]
and [PCIMe]. The first QoS action group contains a single action,
QoSPolicyRSVPSimpleAction. This action is used for both signal control
and install actions depending on a type attribute. The second QoS action
group determines whether a flow or class of flows should be admitted.
This is done by specifying an appropriate traffic profile. These set of
actions are called QoS admission actions. The third group of actions
control bandwidth allocation and congestion control differentiations,
which together specify the per-hop behavior forwarding treatment. The
forth QoS action is unconditional packet discard action. This action is
used either by itself or as a building block of the
QoSPolicyPoliceAction.
Note that some QoS actions are not directly modeled. Instead, they are
modeled by using the class SimplePolicyAction with the appropriate
associations. For example, the three marking actions (DSCP, IPP and CoS)
are modeled by using the SimplePolicyAction class, associating it with
variables and values of the appropriate type.
Snir, Ramberg, Strassner, Cohen expires November 2001 14
draft-ietf-policy-qos-info-model-03.txt April 2001
3.2 RSVP Policy Actions
There are three types of decisions a PDP (either remote or within a PEP)
can make when it evaluates an RSVP request:
1. Admit or reject the request
2. Use admission parameters to decide whether to admit the request or
not
3. Use signaling parameters to decide how to modify the RSVP signaling
messages
The COPS for RSVP [RFC2749] specification uses different Decision object
types to model each of these decisions. QPIM follows the COPS
specification and models each decision using a different action class.
The QoSPolicyRSVPAdmissionAction with its associated
QosPolicyIntServTrfcProf determine whether to accept or reject a given
RSVP request by comparing the RSVP request's TSPEC or RSPEC parameters
against the traffic profile. For a full description of the comparison
method, see section 4, which describes traffic profiles in more detail.
Using the QoSPolicyRSVPAdmissionAction, a limit on the number of admitted
reservations can be enforced as well. The QoSPolicyRSVPAdmissionAction
can specify that a set of RSVP requests will be accepted yet a warning
message would be sent to the RSVP end points. The
QoSPolicyRSVPAdmissionAction controls the Decision Command and Decision
Flags objects used within COPS for RSVP.
The class QoSPolicyRSVPSimpleAction, which is derived from the
PolicySimpleAction class [PCIMe], can be used to specify RSVP decisions.
The property qpRSVPActionType designates the instance of the class to be
either of type 'REPLACE', 'STATELESS', or both. For instances carrying a
qpRSVPActionType property value of 'REPLACE', the action is interpreted
as a COPS Replace Decision, controlling the contents of the RSVP message.
For instances carrying a qpRSVPActionType property value of 'STATELESS',
the action is interpreted as a COPS Stateless Decision, controlling the
admission parameters. If both of these actions are required, this can be
done by assigning both of the two qpRSVPActionType values, since it is a
multi-valued property.
This class is modeled to represent the COPS for RSVP Replace and
Stateless decisions. This similarity allows future use of these COPS
decisions to be directly controlled by a QoSPolicySimpleAction. The only
required extension might be the definition of a new RSVP variable.
Snir, Ramberg, Strassner, Cohen expires November 2001 15
draft-ietf-policy-qos-info-model-03.txt April 2001
Example: Controlling COPS Stateless Decision
The QoSPolicyRSVPSimpleAction allows the specification of admission
parameters. It allows specification of the preemption priority [RFC2751]
of a given RSVP Reservation request. Using the preemption priority value,
the PEP can determine the importance of a Reservation compared with
already admitted reservations, and if necessary can preempt lower
priority reservations to make room for the higher priority one. This
class can also be used to control mapping of RSVP requests to a
differentiated services domain by setting the QoSPolicyRSVPDSCPVariable
to the required value. This instructs the PEP to mark traffic matching
the Session and Sender specifications carried in an RSVP request to a
given DSCP value.
Example: Controlling the COPS Replace Decision
A Policy system should be able to control the information carried in the
RSVP messages. The QoSPolicyRSVPSimpleAction allows control of the
content of RSVP signaling messages. An RSVP message can carry a
preemption policy object [RFC2751] specifying the priority of the
reservation request in comparison to other requests. An RSVP message can
also carry a policy object for authentication purposes. An RSVP message
can carry a DCLASS [DCLASS] object that specifies to the receiver or
sender the particular DSCP value that should be set on the data traffic.
A COPS for RSVP Replacement Data Decision controls the content of the
RSVP message by specifying a set of RSVP objects replacing or removing
the existing ones.
3.3 Provisioning Policy Actions
The differentiated Service Architecture [DIFFSERV] was designed to
provide a scalable QoS differentiation without requiring any signaling
protocols running between the hosts and the network. The QoS actions
modeled in QPIM can be used to control all the building blocks of the
Differentiated Service architecture, including per-hop behaviors, edge
classification, and policing and shaping, without a need to specify the
datapath mechanisms used by PEP implementations. This provides an
abstraction level hiding the unnecessary details and allowing the network
administrator to write rules that express the network requirements in a
more natural form. In this architecture, as no signaling between the end
host and the network occur before the sender starts sending information,
the QoS mechanisms should be setup in advance. This usually means that
PEPs need to be provisioned with the set of policy rules in advance.
Policing and Shaping actions are modeled as sub-classes of the QoS
admission action. DSCP and CoS marking are modeled as sub-classes of the
simplePolicyAction class. Bandwidth allocation, scheduling and congestion
control actions are modeled as sub-classes of the QoS PHB action.
Snir, Ramberg, Strassner, Cohen expires November 2001 16
draft-ietf-policy-qos-info-model-03.txt April 2001
3.3.1. Admission Actions: Controlling Policers and Shapers
All Admission Actions have in common an association to a traffic profile
and a scope property that determines whether the traffic profile is
compared against the rate parameters of each flow or against the
aggregate rate of all flows that match the rule's condition. For example,
using two provisioned policer actions the following policies can be
enforced:
- Make sure that each HTTP flow will not exceed 64kb/s
- Make sure that the aggregate rate of all HTTP flows will not
exceed 512Kb/s
Both policies are modeled using the same QoSPolicyPoliceAction. The first
policy has its scope property set to 'flow', while the second policy has
its scope property set to 'class'. The two policies are modeled using a
rule with two police actions that, in a pseudo formal definition, looks
like the following:
If (HTTP) Action1=police, Traffic Profile1=64kb/s, Scope1=flow
Action2=police, Traffic Profile2=512kb/s, Scope2=class
The provisioned policer action QoSPolicyPoliceAction has 3 associations,
QoSPolicyConformAction, QoSPolicyExceedAction and QoSPolicyViolateAction.
The policer action is associated with a three-level token bucket traffic
profile carrying rate, burst and excess-burst parameters. Traffic
measured by a meter can be classified as conforming traffic when the
metered rate is below the rate defined by the traffic profile, as excess
traffic when the metered traffic is above the normal burst and below the
excess burst size, and violating traffic when rate is above the maximum
excess burst.
The [DIFF-MIB] defines a two-level meter, and provides a means to combine
two-level meters into more complex meters. In this document, a three-
level traffic profile is defined. This allows construction of both two-
level meters as well as providing an easier definition for three-level
meters needed for creating AF [AF] provisioning actions.
A policer action with a non-specified conform action implies that
conforming traffic should not be modified. A policer action with an
associated three-level traffic profile that does not specify an excess
action implies that the excess traffic should be treated as either
violating or conforming traffic according to some algorithm suitable for
the enforcement of the rule. For example, the final enforcement of such a
rule may be the use of a random function similar to RED to determine
whether traffic is conforming or violating. A policer action with a
three-level traffic profile that specifies an exceed action but does not
specify a violate action implies that violate action is identical to the
specified exceed action.
Snir, Ramberg, Strassner, Cohen expires November 2001 17
draft-ietf-policy-qos-info-model-03.txt April 2001
Shapers are used to delay some or all of the packets in a traffic stream
in order to bring the stream into compliance with a traffic profile. A
shaper usually has a finite-sized buffer, and packets may be discarded if
there is not sufficient buffer space to hold the delayed packets. Shaping
is controlled by the QoSPolicyShapeAction class. The only required
association is a traffic profile that specifies the rate and burst
parameters that the outgoing flows should conform with.
3.3.2 Controlling Markers
Three types of markers are modeled in QPIM: Differentiated Services Code
Point (DSCP), IP Precedence (IPP) and layer-2 Class of Service (CoS). The
marking action itself is modeled by using the SimplePolicyAction class
associated with the appropriate variables and values.
DSCP markers set the DS field of a packet header to a particular DS Code
Point (DSCP), adding the marked packet to a particular DS behavior
aggregate. The marker may be configured to mark all packets that it
receives to a single DSCP, or may be configured to mark a packet to one
of a set of DSCPs used to select a PHB in a PHB group according to the
state of a meter. This can be achieved by associating a marking action
with a policer action using the conform, exceed and violate action
associations. The semantics of the DSCP marker is encapsulated in the
pairing of a DSCP variable and a DSCP value within a single
SimplePolicyAction instance via the appropriate associations.
IPP markers set the IPP field of a packet header to a particular IPP
value (0 through 7). The semantics of the IPP marker is encapsulated in
the pairing of a DSCP variable masked to IPP sub-field and a DSCP value
masked to IPP sub-field within a single SimplePolicyAction instance via
the appropriate associations.
CoS markers control the mapping of a per-hop behavior to a layer-2 Class
of Service. For example, mapping of a set of DSCP values into a 802.1q
user priority value can be specified using a rule with a condition
describing the set of DSCP values, and a CoS marking action that
specifies the required mapping to the given user Çôpriority value. The
semantics of the CoS marker is encapsulated in the pairing of a CoS
variable and a CoS value (integer in the range of 0 through 7) within a
single SimplePolicyAction instance via the appropriate associations.
3.3.3 Controlling Edge Policies - Examples
Assuming that the AF1 behavior aggregate is enforced within a DS domain,
policy rules on the edge of the network should mark packets to one of the
AF1x DSCPs depending on conformance to a predetermined three-parameter
traffic profile. QPIM models such AF1 policing action as defined in
Figure 3.
Snir, Ramberg, Strassner, Cohen expires November 2001 18
draft-ietf-policy-qos-info-model-03.txt April 2001
+-----------------------+ +------------------------------+
| QoSPolicyPoliceAction |====| QoSPolicyTokenBucketTrfcProf |
| scope = class | | rate = x, bc = y, be = z |
+-----------------------+ +------------------------------+
* @ #
* @ #
* @ +-------------------------+ +--------------------+
* @ | SimplePolicyAction |---| PolicyIntegerValue |
* @ +-------------------------+ | AF13 |
* @ +--------------------+
* +-------------------------+ +--------------------+
* | SimplePolicyAction |---| PolicyIntegerValue |
* +-------------------------+ | AF12 |
* +--------------------+
+-------------------------+ +--------------------+
| SimplePolicyAction |---| PolicyIntegerValue |
+-------------------------+ | AF11 |
+--------------------+
Association and Aggregation Legend:
**** QoSPolicyConformAction
@@@@ QoSPolicyExceedAction
#### QoSPolicyViolateAction
==== QoSTrfcProfInAdmissionAction
---- PolicyValueInSimplePolicyAction ([PCIMe])
&&&& PolicyVariableInSimplePolicyAction ([PCIMe], not shown)
Figure 3. AF Policing and Marking
The marker is made of an instance of the SimplePolicyAction class. The
aggregation PolicyVariableInSimplePolicyAction (which is defined in
[PCIMe]) is used to associate the value to mark (contained in the
PolicyDSCPValue) with the appropriate traffic action. This aggregation is
not shown in this figure for simplicity. AF11 is marked on conforming
traffic; AF12 is marked on exceeding action and AF13 on violating
traffic.
The second example, shown in Figure 4, is the simplest policing action.
Traffic below a two-parameter traffic profile is unmodified, while
traffic exceeding the traffic profile is discarded.
Snir, Ramberg, Strassner, Cohen expires November 2001 19
draft-ietf-policy-qos-info-model-03.txt April 2001
+-----------------------+ +------------------------------+
| QoSPolicyPoliceAction |====| QoSPolicyTokenBucketTrfcProf |
| scope = class | | rate = x, bc = y |
+-----------------------+ +------------------------------+
@
@
+-------------------------+
| QoSPolicyDiscardAction |
+-------------------------+
Association and Aggregation Legend:
**** QoSPolicyConformAction (not used)
@@@@ QoSPolicyExceedAction
#### QoSPolicyViolateAction (not used)
==== QoSTrfcProfInAdmissionAction
Figure 4. A Simple Policing Action
3.4 Per-Hop Behavior Actions
A Per-Hop Behavior (PHB) is a description of the externally observable
forwarding behavior of a DS node applied to a particular DS behavior
aggregate [DIFFSERV]. The approach taken here is that a PHB action
specifies both observable forwarding behavior (i.e., loss, delay, jitter)
as well as specifying the buffer and bandwidth resources that need to be
allocated to each of the behavior aggregates in order to achieve this
behavior. That is, a rule with a set of PHB actions can specify that an
EF packet must not be delayed more than 20 msec in each hop. The same
rule may also specify that EF packets need to be treated with preemptive
forwarding (e.g., with priority queuing), and specify the maximum
bandwidth for this class as well as the maximum buffer resources. PHB
actions can therefore be used to both represent the final requirements
from PHBs as well as provide enough detail to be able to map the PHB
actions into a set of configuration parameters to configure queues,
schedulers, droppers and other mechanisms.
The QoSPolicyPHBAction abstract class has two subclasses. The
QoSPolicyBandwidthAction class is used to control bandwidth, delay and
forwarding behavior, while the QoSPolicyCongestionControlAction class is
used to control queue size, thresholds and congestion algorithms. The
qpPacketSize property of the PHB action specifies the packet size in
bytes, and is needed when translating the actions into actual
implementation configurations. For example, implementation measuring
queue length in bytes will need to use this property to map the
qpQueueSize property into queue length in bytes.
Snir, Ramberg, Strassner, Cohen expires November 2001 20
draft-ietf-policy-qos-info-model-03.txt April 2001
3.4.1 Controlling Bandwidth and Delay
QoSPolicyBandwidthAction allows specifying the minimal bandwidth that
should be reserved for a class of traffic. The property qpMinBandwidth
can be specified either in Kb/sec or in percentage of the total available
bandwidth. The property qpBandwidthUnits is used to determine whether
percentage or fixed values are used.
The property qpForwardingPriority is used whenever preemptive forwarding
is required. A policy rule that defines the EF PHB should indicate a non-
zero forwarding priority. The qpForwardingPriority property holds an
integer value to enable multiple levels of preemptive forwarding where
higher values are used to specify higher priority.
The property qpMaxBandwidth specifies the maximum bandwidth that should
be allocated to a class of traffic. This property may be specified in PHB
actions with non-zero forwarding priority in order to guard against
starvation of other PHBs.
The properties qpMaxDelay and qpMaxJitter specify limits on the per-hop
delay and jitter in milliseconds for any given packet within a traffic
class. Enforcement of the maximum delay and jitter may require use of
preemptive forwarding as well as minimum and maximum bandwidth controls.
Enforcement of low max delay and jitter values may also require
fragmentation and interleave mechanisms over low speed links.
The Boolean property qpFairness indicates whether flows should have a
fair chance to be forwarded without drop or delay. A way to enforce a
bandwidth action with qpFairness set to TRUE would be to build a queue
per flow for the class of traffic specified in the rule's filter. In this
way, interactive flows like terminal access will not be queued behind a
bursty flow (like FTP) and therefore have a reasonable response time.
3.4.2 Congestion Control Actions
The QoSPolicyCongestionControlAction class controls queue length,
thresholds and congestion control algorithms.
A PEP should be able to keep in its queues qpQueueSize packets matching
the rule's condition. In order to provide a link-speed independent queue
size, the qpQueueSize can also be measured in milliseconds. The time
interval specifies the time needed to transmit all packets within the
queue if the link speed is dedicated entirely for transmission of packets
within this queue. The property qpQueueSizeUnit determines whether queue
size is measured in number of packets or in milliseconds.
The property qpDropAlgorithm selects either tail-drop, head-drop or
random-drop algorithms. The set of maximum and minimum threshold values
can be specified as well, using qpThresholdMin and qpThresholdMax
properties, either in packets or in percentage of the total available
queue size as specified by the qpThresholdUnits property.
Snir, Ramberg, Strassner, Cohen expires November 2001 21
draft-ietf-policy-qos-info-model-03.txt April 2001
3.4.3 Using Hierarchical Policies Çô Examples for PHB actions
Hierarchical policy definition is a primary tool in the QoS Policy
Information model. Rule nesting introduced in [PCIMe] allows
specification of hierarchical policies controlling RSVP requests,
hierarchical shaping, policing and marking actions, as well as
hierarchical schedulers and definition of the differences in PHB groups.
An example of the use of hierarchical schedulers is provided in [PCIMe].
This example provides a set of rules that specify PHBs enforced within a
Differentiated Service Domain. The network administrator chose to enforce
the EF, AF11 and AF13 and Best Effort PHBs. For simplicity, AF12 is not
differentiated. The set of rules takes the form:
If (EF) then do EF actions
If (AF1) then do AF1 actions
If (AF13) then do AF13 actions
If (default) then do Default actions.
EF, AF1 and AF13 are conditions that filter traffic according to DSCP
values. The AF1 condition matches the entire AF1 PHB group including the
AF11, AF12 and AF13 DSCP values. The default rule uses a 'match all'
condition and specifies the Best Effort rules. The nesting of the AF13
rule within the AF1 rule specifies that there are further refinements on
how AF13 traffic should be treated relative to the entire AF1 PHB group.
The set of rules reside in a PolicyGroup with a decision strategy
property set to 'MATCH FIRST'.
The class instances below specify the set of actions used to describe
each of the PHBs. Queue sizes are not specified, but can easily be added
to the example.
The actions used to describe the Best Effort PHB are simple. No bandwidth
is allocated to Best Effort traffic. The first action specifies that Best
Effort traffic class should have fairness.
QosPolicyBandwidthAction BE-B:
qpFairness: True
The second action specifies that the congestion algorithm for the Best
Effort traffic class should be random, and specifies the thresholds in
percentage of the default queue size.
QoSPolicyCongestionControlAction BE-C:
qpDropAlgorithm: random
qpDropThresholdUnits %
qpDropMinThreshold: 10%
qpDropMaxThreshold: 70%
Snir, Ramberg, Strassner, Cohen expires November 2001 22
draft-ietf-policy-qos-info-model-03.txt April 2001
EF requires preemptive forwarding. The maximum bandwidth is also
specified to make sure that the EF class does not starve the other
classes. EF PHB uses tail drop as the applications using EF are supposed
to be UDP-based and therefore would not benefit from a random dropper.
QosPolicyBandwidthAction EF-B:
qpForwardingPriority: 1
qpBandwidthUnits: %
qpMaxBandwidth 50%
qpFairness: False
QoSPolicyCongestionControlAction EF-C:
QpDropAlgorithm: tail-drop
qpDropThresholdUnits packet
qpDropMaxThreshold: 3 packets
The AF1 actions define the bandwidth allocations and thresholds for the
entire PHB group:
QosPolicyBandwidthAction AF1-B:
qpBandwidthUnits: %
qpMinBandwidth: 30%
QoSPolicyCongestionControlAction AF1-C:
QpDropAlgorithm: random
qpDropThresholdUnits packet
qpDropMinThreshold: 4 packets
qpDropMaxThreshold: 20 packets
The AF13 action specifies the differentiating refinement for the AF13 PHB
within the AF1 PHB group. The lower threshold values provide the higher
discard probability of the AF13 PHB.
QosPolicyCongestionControlAction AF13-C:
QpDropAlgorithm: random
qpDropThresholdUnits packet
qpDropMinThreshold: 2 packets
qpDropMaxThreshold: 10 packets
4. Traffic Profiles
Meters measure the temporal state of a flow or a set of flows against a
traffic profile. In this document, traffic profiles are modeled by the
gpsPolicyTrfcProf class. The association
QoSPolicyTrfcProfileInAdmissionAction binds the traffic profile to the
admission action using it. Two traffic profiles are derived from the
abstract class gpsPolicyTrfcProf. The first is a Token Bucket
Provisioning traffic profile carrying rate and burst parameters. The
second is an RSVP traffic profile, which enables flows to be compared
with RSVP TSPEC and FLOWSPEC parameters.
Snir, Ramberg, Strassner, Cohen expires November 2001 23
draft-ietf-policy-qos-info-model-03.txt April 2001
4.1 Provisioning Traffic Profiles
Provisioned Admission Actions including Shaping and policing are
specified using a two- or three-parameter token bucket traffic profile.
The qosPolicyTokenBucketTrfcProf class includes the following properties:
1. Rate measured in kbits/sec
2. Normal burst measured in bytes
3. Excess burst measured in bytes
Rate determines the long-term average transmission rate. Traffic that
falls under this rate is conforming, as long as the normal burst is not
exceeded at any time. Traffic exceeding the normal burst but still below
the excess burst is exceeding the traffic profile. Traffic beyond the
excess burst is said to be violating the traffic profile.
Excess burst size is measured in bytes in addition to the burst size. A
zero excess burst size indicates that no excess burst is allowed.
4.2 RSVP traffic profiles
RSVP admission policy can condition the decision whether to accept or
deny an RSVP request based on the traffic specification of the flow
(TSPEC) or the amount of QoS resources requested (FLOWSPEC). The
admission decision can be based on matching individual RSVP requests
against a traffic profile or by matching the aggregated sum of all
FLOWSPECs (TSPECs) currently admitted. The QosPolicyIntesrvTrfcProf
class models both such traffic profiles. This class has the following
properties:
1. Token Rate (r) measured in bits/sec
2. Peak Rate (p) measured in bits/sec
3. Bucket Size (b) measured in bytes
4. Min Policed unit (m) measured in bytes
5. Max packet size (M) measured in bytes
6. Resv Rate (R) measured in bits/sec
7. Slack term (s) measured in microseconds
The first 5 parameters are the traffic specification parameters used in
the integrated service architecture. These parameters are used to define
a sender TSPEC as well as FLOWSPEC for the Controlled-Load service [CL].
For a definition and full explanation of their meaning, please refer to
[RSVP-IS]. Parameters 6 and 7 are the additional parameters used for
specification of the Guaranteed Service FLOWSPEC [GS].
Snir, Ramberg, Strassner, Cohen expires November 2001 24
draft-ietf-policy-qos-info-model-03.txt April 2001
A partial order is defined between TSPECs (and FLOWSPECs). The TSPEC A is
larger than the TSPEC B if and only if rA>rB, pA>pB, bA>bB, mA<mB and
MA>MB. A TSPEC (FLOWSPEC) measured against a traffic profile uses the
same ordering rule. An RSVP message is accepted only if its TSPEC
(FLOWSPEC) is either smaller or equal to the traffic profile. Only
parameters specified in the traffic profile are compared.
The GS FLOWSPEC is also compared against the rate R and the slack term S.
R should not be larger than the traffic profile R parameter, while the
FLOWSPEC slack term should not be smaller than that specified in the
slack term.
TSPECs as well as FLOWSPECs can be added. The sum of two TSPECs is
computed by summing the rate r, the peak rate p, the bucket size b, and
by taking the minimum value of the minimum policed unit m and the maximum
value of the maximum packet size M. GS FLOWSPECs are summed by adding the
Resv rate and minimizing the slack term s. These rules are used to
compute the temporal state of admitted RSVP states matching the traffic
class defined by the rule condition. This state is compared with the
traffic profile to arrive to an admission decision when the scope of the
QoSPolicyRSVPAdmissionAction is set to 'class'.
5. Pre-Defined QoS-Related Variables
Pre-defined variables are necessary for ensuring interoperability among
policy servers and policy management tools from different vendors.
The purpose of this section is to define frequently used variables in QoS
policy domains.
Notice that this section only adds to the variable classes as defined in
[PCIMe] and reuses the mechanism defined there.
The QoS policy information model specifies a set of pre-defined variable
classes to support a set of fundamental QoS terms that are commonly used
to form conditions and actions and are missing from the [PCIMe]. Examples
of these include RSVP related variables. All variable classes defined in
this document extend the PolicyImplictVariable class, defined in [PCIMe].
Subclasses specify the data type and semantics of the policy variables.
This Draft defines the following RSVP variable classes, for details see
class definition:
Snir, Ramberg, Strassner, Cohen expires November 2001 25
draft-ietf-policy-qos-info-model-03.txt April 2001
RSVP related Variables:
1. QoSPolicyRSVPSourceIPv4Variable - The source IP address of the RSVP
signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP
RESV FILTER_SPEC [RSVP] objects.
2. QoSPolicyRSVPDestinationIPv4Variable - The destination port of the
RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION
[RSVP] objects.
3. QoSPolicyRSVPSourceIPv6Variable - The source IP address of the RSVP
signaled flow, as defied in the RSVP PATH SENDER_TEMPLATE and RSVP
RESV FILTER_SPEC [RSVP] objects.
4. QoSPolicyRSVPDestinationIPv6Variable - The destination port of the
RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION
[RSVP] objects.
5. QoSPolicyRSVPSourcePortVariable - The source port of the RSVP signaled
flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV
FILTER_SPEC [RSVP] objects.
6. QoSPolicyRSVPDestinationPortVariable - The destination port of the
RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION
[RSVP] objects.
7. QoSPolicyRSVPIPProtocolVariable - The IP Protocol of the RSVP signaled
flow, as defined in the RSVP PATH and RESV SESSION [RSVP] objects.
8. QoSPolicyRSVPIPVersionVariable - The IP version of the IP Addresses
carried the RSVP signaled flow, as defined in the RSVP PATH and RESV
SESSION [RSVP] objects.
9. QoSPolicyRSVPDCLASSVariable - The DSCP value as defined in the RSVP
DCLASS [DCLASS] object.
10. QoSPolicyRSVPStyleVariable - The reservation style (FF, SE, WF) as
defined in the RSVP Resv message [RSVP].
11. QoSPolicyRSVPIntServVariable - The integrated Service (CL, GS,
NULL) requested in the RSVP Reservation message, as defined in the
FLOWSPEC RSVP Object [RSVP].
12. QoSPolicyRSVPMessageTypeVariable - The RSVP message type, either
Path, Resv, PathErr or ResvErr [RSVP].
13. QoSPolicyRSVPPreemptionPriorityVariable - The RSVP reservation
priority as defined in [RFC2751].
14. QoSPolicyRSVPPreemptionDefPriorityVariable - The RSVP preemption
reservation defending priority as defined in [RFC2751].
15. QoSPolicyRSVPUserVariable - The ID of the user that initiated the
flow as defined in the User Locator string in the Identity Policy
Object [RFC2752].
16. QoSPolicyRSVPApplicationVariable - The ID of the application that
generated the flow as defined in the application locator string in
the Application policy object [RFC2872]
17. QoSPolicyRSVPAuthMethodVariable - The RSVP Authentication type used
in the Identity Policy Object [RFC2752].
Each class restricts the possible value types associated with a specific
variable. For example, the QoSPolicyRSVPSourcePortVariable class is used
to define the source port of the RSVP signaled flow. The value associated
with this variable is of type integer.
Snir, Ramberg, Strassner, Cohen expires November 2001 26
draft-ietf-policy-qos-info-model-03.txt April 2001
6. QoS Related Values
Values are used in the information model as building blocks for the
policy conditions and policy actions, as described in [PCIM] and [PCIMe].
This section defines a set of auxiliary values that are
used for QoS policies as well as other policy domains.
All value classes extend the PolicyImplicitValue class [PCIMe]. The
subclasses specify specific data/value types that are not defined in
[PCIMe].
This document defines the following two subclasses of the
PolicyImplicitValue class:
QoSPolicyDNValue - This class is used to represent a single or set of
Distinguished Name [DNDEF] values, including wildcards. A Distinguished
Name is a name that can be used as a key to retrieve an object from a
directory service. This value can be used in comparison to reference
values carried in RSVP policy objects, as specified in [RFC2752]. This
class is defined in Section 8.31.
QoSPolicyAttributeValue - This class is used to represent a single or set
of property values in an object. This value can be used in conjunction
with reference values carried in RSVP objects, as specified in [RFC2752].
The property name is used to specify which of the properties in the
object is being used as the condition. The value of this property will
then be retrieved, and a match (which is dependent on the property name)
will be used to see if the condition is satisfied or not.
For example, suppose a User class has a multi-valued Property called
'member-of' that lists the names of groups that this user belongs to.
Suppose this property uses caseIgnoreMatch matching. A simple condition
can be constructed to match the reference carried in an RSVP Identity
policy object to a gpsPolicyAttributeValue with the following
characteristics:
gpAttributeName="member-of", gpAttributeValueList = "group-A".
A User Identity policy object carrying the following reference:
"OU=Sales, CN=J. Smith, O=Widget Inc."
will match this simple condition only if J. Smith belongs to group-a.
Snir, Ramberg, Strassner, Cohen expires November 2001 27
draft-ietf-policy-qos-info-model-03.txt April 2001
7. Class Definitions: Association Hierarchy
The following sections define associations that are specified by QPIM.
7.1. The Association "QosPolicyTrfcProfInAdmissionAction"
This association links a gpsPolicyTrfcProf object modeling a specific
traffic profile to a QoSPolicyAdmissionAction object. The class
definition for this association is as follows:
NAME QosPolicyTrfcProfInAdmissionAction
DESCRIPTION A class representing the association between a
traffic profile used for admission decision
DERIVED FROM Dependency
ABSTRACT FALSE
PROPERTIES Antecedent[ref QoSPolicyAdmissionAction [0..n]]
Dependent[ref QoSPolicyTrfcProf [0..n]]
7.1.1. The Reference "Antecedent"
This property is inherited from the Dependency association, defined in
[PCIM]. Its type is overridden to become an object reference to a
QoSPolicyAdmissionAction object. This represents the "independent" part
of the association. The [0..n] cardinality indicates that a given
QoSPolicyAdmissionAction object may have 0 or more traffic profiles that
it can use.
7.1.2. The Reference "Dependent"
This property is inherited from the Dependency association, and is
overridden to become an object reference to a QoSPolicyTrfcProfile
object. This represents a specific traffic profile that is used by a
given QoSPolicyAdmissionAction. The [0..n] cardinality means that a given
traffic profile may be used by 0 or more admission actions.
7.2 The Association "PolicyConformAction"
This association links a policer action with an object defining
an action to be applied on conforming traffic relative to the associated
traffic profile. The class definition for this association is as follows:
NAME PolicyConformAction
DESCRIPTION A class representing the association between a policer
action and the action that should be applied on traffic
conforming to an associated traffic profile.
DERIVED FROM Dependency
ABSTRACT FALSE
PROPERTIES Antecedent[ref QoSPolicyPoliceAction[0..n]]
Dependent[ref PolicyAction [0..1]]
Snir, Ramberg, Strassner, Cohen expires November 2001 28
draft-ietf-policy-qos-info-model-03.txt April 2001
7.2.1. The Reference "Antecedent"
This property is inherited from the Dependency association. Its type is
overridden to become an object reference to a QoSPolicyPoliceAction
object. This represents the "independent" part of the association. The
[0..n] cardinality indicates that any number of QoSPolicyPoliceAction
objects may be given the same action to be executed as the conforming
action.
7.2.2. The Reference "Dependent"
This property is inherited from the Dependency association, and is
overridden to become an object reference to a PolicyAction object. This
represents a specific policy action that is used by a given
QoSPolicyPoliceAction. The [1..1] cardinality means that a given
conforming action may only be used by a single QoSPolicyPoliceAction.
7.3. The Association "PolicyExcessAction"
This association links a policer action with an object defining an
action to be applied on traffic exceeding the associated traffic
profile. The class definition for this association is as follows:
NAME PolicyExcessAction
DESCRIPTION A class representing the association between a
policer action and the action that should be applied
on traffic exceeding an associated traffic profile.
DERIVED FROM Dependency
ABSTRACT FALSE
PROPERTIES Antecedent[ref QoSPolicePoliceAction[0..n]]
Dependent[ref PolicyAction [0..1]]
7.3.1. The Reference "Antecedent"
This property is inherited from the Dependency association. Its type is
overridden to become an object reference to a QoSPolicyPoliceAction
object. This represents the "independent" part of the association. The
[0..n] cardinality indicates that any number of QoSPolicyPoliceAction
objects may be given the same action to be executed as the exceeding
action.
7.3.2. The Reference "Dependent"
This property is inherited from the Dependency association, and is
overridden to become an object reference to a PolicyAction object. This
represents a specific policy action that is used by a given
QoSPolicyPoliceAction. The [1..1] cardinality means that a given
exceeding action may only be used by a single QoSPolicyPoliceAction.
Snir, Ramberg, Strassner, Cohen expires November 2001 29
draft-ietf-policy-qos-info-model-03.txt April 2001
7.4. The Association "PolicyViolateAction"
This association links a policer action with an object defining an
action to be applied on traffic violating the associated traffic
profile. The class definition for this association is as follows:
NAME PolicyViolateAction
DESCRIPTION A class representing the association between a
policer action and the action that should be applied
on traffic violating an associated traffic profile.
DERIVED FROM Dependency
ABSTRACT FALSE
PROPERTIES Antecedent[ref QoSPolicePoliceAction[0..n]]
Dependent[ref PolicyAction [0..1]]
7.4.1. The Reference "Antecedent"
This property is inherited from the Dependency association. Its type is
overridden to become an object reference to a QoSPolicyPoliceAction
object. This represents the "independent" part of the association. The
[0..n] cardinality indicates that any number of QoSPolicyPoliceAction
objects may be given the same action to be executed as the violating
action.
7.4.2. The Reference "Dependent"
This property is inherited from the Dependency association, and is
overridden to become an object reference to a PolicyAction object. This
represents a specific policy action that is used by a given
QoSPolicyPoliceAction. The [1..1] cardinality means that a given
violating action may only be used by a single QoSPolicyPoliceAction.
Snir, Ramberg, Strassner, Cohen expires November 2001 30
draft-ietf-policy-qos-info-model-03.txt April 2001
8. Class Definitions: Inheritance Hierarchy
The following sections define object classes that are specified by QPIM.
8.1. The Class QoSPolicyDiscardAction
This class is used to specify that packets should be discarded. This is
the same as stating that packets should be denied forwarding. The class
definition is as follows:
NAME QoSPolicyDiscardAction
DESCRIPTION This action specify that packets should be discarded.
DERIVED FROM PolicyAction
ABSTRACT False
PROPERTIES None
8.2. The Class QoSPolicyAdmissionAction
This class is the base class for performing admission decisions. It is
used to determine whether to accept or reject a given RSVP request. This
is done by comparing the RSVP request's TSPEC or RSPEC parameters against
the traffic profile (as specified in the QosPolicyIntServTrfcProf class).
The qpAdmissionScope property controls whether the comparison is done per
flow or per class (of flows). Only packets that conform to the traffic
profile are admitted for further processing; other packets are discarded.
The class definition is as follows:
NAME QoSPolicyAdmissionAction
DESCRIPTION This action controls admission decisions based on comparison
of a meter to a traffic profile.
DERIVED FROM PolicyAction
ABSTRACT True
PROPERTIES qpAdmissionScope
8.2.1. The Property qpAdmissionScope
This attribute specifies whether the admission decision is done per flow
or per the entire class of flows defined by the rule condition. If the
scope is per flow, the actual or requested rate of each flow is compared
against the traffic profile. If the scope is set to class, the aggregate
actual or requested rate of all flows matching the rule condition is
measured against the traffic profile. The property is defined as follows:
NAME qpAdmissionScope
DESCRIPTION This property specifies whether the admission decision is
done per flow or per the entire class of flows
SYNTAX Integer
VALUE This is an enumerated integer. A value of 0 specifies that
admission is done on a per-flow basis, and a value of 1
specifies that admission is done on a per-class basis.
Snir, Ramberg, Strassner, Cohen expires November 2001 31
draft-ietf-policy-qos-info-model-03.txt April 2001
8.3. The Class QoSPolicyPoliceAction
This is the base class for defining policing actions (e.g., those actions
that restrict traffic in some way). Using the three associations
QoSPolicyConformAction, QoSPolicyExceedAction and QoSPolicyViolateAction,
it is possible to specify different actions to take based on whether the
traffic is conforming, exceeding, or violating a traffic profile. The
traffic profile is specified in the QosPolicyTokenBucketTrfcProf class.
The class definition is as follows:
NAME QoSPolicyPoliceAction
DESCRIPTION This action controls the operation of policers. The measured
rate of flows is measured against a traffic profile. The
action the needs to be performed on conforming, exceeding
and violating traffic is indicated using the conform, exceed
and violate action associations.
DERIVED FROM QoSPolicyAdmissionAction
ABSTRACT False
PROPERTIES None
8.4. The Class QoSPolicyShapeAction
This class is the base class for defining shaping actions. Shapers are
used to delay some or all of the packets in a traffic stream in order to
bring a particular traffic stream into compliance with a given traffic
profile. The traffic profile is specified in the
QosPolicyTokenBucketTrfcProf class. The class definition is as follows:
NAME QoSPolicyShapeAction
DESCRIPTION This action indicate that traffic should be shaped to be
conforming with a traffic profile.
DERIVED FROM QoSPolicyAdmissionAction
ABSTRACT False
PROPERTIES None
Snir, Ramberg, Strassner, Cohen expires November 2001 32
draft-ietf-policy-qos-info-model-03.txt April 2001
8.5. The Class QoSPolicyRSVPAdmissionAction
This class determines whether to accept or reject a given RSVP request by
comparing the RSVP request's TSPEC or RSPEC parameters against the
traffic profile. The traffic profile is specified in the
QosPolicyIntServTrfcProf class. This class inherits the qpAdmissionScope
property from its superclass. This property specifies whether admission
should be done on a per-flow or per-class basis. If the traffic profile
is not larger or equal to the requested reservation, or to the sum of the
admitted reservation merged with the requested reservation, the result is
a deny decision. If no traffic profile is specified, the assumption is
that all traffic can be admitted. The class definition is as follows:
NAME QoSPolicyRSVPAdmissionAction
DESCRIPTION This action controls the admission of RSVP request.
Depending on the scope, either a single RSVP request or the
total admitted RSVP requests matching the conditions are
compared against a traffic profile.
DERIVED FROM QoSPolicyAdmissionAction
ABSTRACT False
PROPERTIES qpRSVPWarnOnly, qpRSVPMaxSessions
8.5.1. The Property qpRSVPWarnOnly
When this property is set to True, the RSVP request is admitted, but an
RSVP error message carrying a warning is sent to the originator (sender
or receiver). This follows the COPS for RSVP send error flag in the
Decision Flags object. This property is defined as follows:
NAME qpRSVPWarnOnly
SYNTAX Boolean
Default False
VALUE This property can have one of two values. The value 1 (TRUE)
means that the request should be admitted AND an RSVP error
message should be sent to the originator. The value of 0 (FALSE)
means that the request should be admitted without sending an RSVP
error message.
8.5.2. The Property qpRSVPMaxSessions
This attribute is used to limit the total number of RSVP requests
admitted within the specified class of traffic. The qpAdmissionScope
property must be set to class (it is not applicable if the
qpAdmissionScope property is set to "flow"). The definition of this
property is as follows:
NAME qpRSVPMaxSessions
SYNTAX Integer
VALUE Must be greater than 0.
Snir, Ramberg, Strassner, Cohen expires November 2001 33
draft-ietf-policy-qos-info-model-03.txt April 2001
8.6. The Class QosPolicyPHBAction
This class is a base class that is used to define the per-hop behavior
that is to be assigned to behavior aggregates. It defines a common
property, qpPacketSize, for use by its subclasses
(QoSPolicyBandwidthAction and QoSPolicyCongestionControlAction). The
class definition is as follows:
NAME QosPolicyPHBAction
DESCRIPTION This action controls the Per-Hop-Behavor provided to
behavior aggregates.
DERIVED FROM PolicyAction
ABSTRACT True
PROPERTIES qpPacketSize
8.6.1. The Property qpPacketSize
This property specifies the maximum packet size in bytes of this class of
packet. This attribute is used in translation of QPIM attributes to QoS
mechanisms used within a PEP. For example, queue length may be measured
in bytes while the minimum number of packets that should be kept in a PEP
is defined within QPIM in number of packets. This property is defined as
follows:
NAME qpPacketSize
SYNTAX Integer
Value Must be greater than 0
8.7. The Class QoSPolicyBandwidthAction
This class is used to control the bandwidth, delay, and forwarding
behavior of a PHB. Its class definition is as follows:
NAME QoSPolicyBandwidthAction
DESCRIPTION This action controls the bandwidth, delay, and
forwarding characteristics of the PHB.
DERIVED FROM QoSPolicyPBHAction
ABSTRACT False
PROPERTIES qpForwardingPriority, qpBandwidthUnits, qpMinBandwdith,
qpMaxBandwidth, qpMaxDelay, qpMaxJitter, qpFairness
Snir, Ramberg, Strassner, Cohen expires November 2001 34
draft-ietf-policy-qos-info-model-03.txt April 2001
8.7.1. The Property qpForwardingPriority
This property defines the forwarding priority for this set of flows. A
non-zero value indicates that pre-emptive forwarding is required. Higher
values represent higher forwarding priority. This property is defined as
follows:
NAME qpForwardingPriority
SYNTAX Integer
VALUE Must be non-negative. The value 0 means that pre-emptive
forwarding is required. A positive value indicates the
priority that is to be assigned for this (set of) flow(s).
8.7.2 The Property qpBandwidthUnits
This property defines in what units the properties qpMinBandwidth and
qpMaxBandwidth are defined. Bandwidth can either be defined in bits/sec
or in percentage of the available bandwidth or scheduler resources. This
property is defined as follows.
NAME qpBandwidthUnits
SYNTAX Integer
VALUE Two values are possible. The value of 0 is used to specify
units of bits/sec, while the value of 1 is used to specify
units as a percentage of the available bandwidth.
8.7.3. The Property qpMinBandwidth
This property defines the minimum bandwidth that should be reserved for
this class of traffic. Both relative (i.e., a percentage of the
bandwidth) and absolute (i.e., bits/second) values can be specified
according to the value qpBandwidthUnits property. This property is
defined as follows.
NAME qpMinBandwidth
SYNTAX Integer
VALUE The value must be greater than 0.
8.7.4. The Property qpMaxBandwidth
This property defines the maximum bandwidth that should be allocated to
this class of traffic. Both relative (i.e., a percentage of the
bandwidth)and absolute (i.e., bits/second) values can be specified
according to the value qpBandwidthUnits property. This
property is defined as follows.
NAME qpMaxBandwidth
SYNTAX Integer
VALUE The value must be greater than 0
Snir, Ramberg, Strassner, Cohen expires November 2001 35
draft-ietf-policy-qos-info-model-03.txt April 2001
8.7.5. The Property qpMaxDelay
This property defines the maximal per-hop delay that traffic of this
class should experience while being forwarded through this hop.
The maximum delay is measured in milliseconds. This property is defined
as follows.
NAME qpMaxDelay
SYNTAX Integer (milliseconds)
VALUE The value must be greater than 0
8.7.6. The Property qpMaxJitter
This property defines the maximal per-hop delay variance that traffic
of this class should experience while being forwarded through this hop.
The maximum jitter is measured in milliseconds. This property is defined
as follows.
NAME qpMaxJitter
SYNTAX Integer (milliseconds)
VALUE The value must be greater than 0
8.7.7. The Property qpFairness
This property defines whether fair queuing is required for this class
of traffic. This property is defined as follows.
NAME qpFairness
SYNTAX Integer
VALUE The value of 0 (FALSE) means that fair queuing is not
required for this class of traffic, while the value of 1
(TRUE) means that fair queuing is required for this class
of traffic.
8.8. The Class QoSPolicyCongestionControlAction
This class is used to control the characteristics of the congestion
control algorithm being used. The class definition is as follows:
NAME QoSPolicyCongestionControlAction
DESCRIPTION This action control congestion control characteristics of
the PHB.
DERIVED FROM QoSPolicyPBHAction
ABSTRACT False
PROPERTIES qpQueueSizeUnits, qpQueueSize, qpDropAlgorithm,
qpDropThresholdUnits, qpDropMinThresholdValue,
qpDropMaxThresholdValue
Snir, Ramberg, Strassner, Cohen expires November 2001 36
draft-ietf-policy-qos-info-model-03.txt April 2001
8.8.1. The property qpQueueSizeUnits
This property specifies the units in which the qpQueueSize attribute is
measured. The queue size is measured either in number of packets or in
units of time. The time interval specifies the time needed to transmit
all packets within the queue if the link speed is dedicated entirely for
transmission of packets within this queue. The property definition is:
NAME qpQueueSizeUnits
SYNTAX IntegerVALUE This property can have two values. If the
value is set to 0,
then the unit of measurement is number of packets. If the
value is set to 1, then the unit of measurement is
milliseconds.
8.8.2. The Property qpQueueSize
This property specifies the queue size in packets or in milliseconds,
depending on the value of the qpQueueSizeUnits (0 specifies packets, and
1 specifies milliseconds). This property is defined as follows:
NAME qpQueueSize
SYNTAX Integer
VALUE This value must be greater than 0
8.8.3. The Property qpDropAlgorithm
This property specifies the congestion control drop algorithm that
should be used for this type of traffic. This property is defined as
follows.
NAME qpDropAlgorithm
SYNTAX Integer
VALUES Three values are currently defined. The value 0 specifies a
random drop algorithm, the value 1 specifies a tail drop
algorithm, and the value 2 specifies a head drop algorithm.
8.8.4. The Property qpDropThresholdUnits
This property specifies the units in which the two properties
qpDropMinThresholdValue and qpDropMaxThresholdValue are measured.
Thresholds can be measured either in packets or in percentage of the
available queue sizes. This property is defined as follows.
NAME qpDropThresholdUnits
SYNTAX Integer
VALUES Two values are defined. The value 0 defines the units as
number of packets, and the value 1 defines the units
as a percentage of the queue size.
Snir, Ramberg, Strassner, Cohen expires November 2001 37
draft-ietf-policy-qos-info-model-03.txt April 2001
8.8.5. The Property qpDropMinThresholdValue
This property specifies the minimum number of queuing and buffer
resources that should be reserved for this class of flows. The threshold
can be specified as either relative (i.e., a percentage) or absolute
(i.e., number of packets) value according to the value of
qpDropThresholdUnits property. If this property specifies a value of 5
packets, then enough buffer and queuing resources should be reserved to
hold 5 packets before running the specified congestion control drop
algorithm. This property is defined as follows:
NAME qpDropMinThresholdValue
SYNTAX Integer
VALUE This value must be greater than 0
8.8.6. The Property qpDropMaxThresholdValue
This property specifies the maximum number of queuing and buffer
resources that should be reserved for this class of flows. The threshold
can be specified as either relative (i.e., a percentage) or absolute
(i.e., number of packets) value according to the value of the
qpDropThresholdUnits property. Congestion Control droppers should not
keep more packets than the value specified in this property. Note,
however, that some droppers may calculate queue occupancy averages,
and therefore the actual maximum queue resources should be larger. This
property is defined as follows:
NAME qpDropMaxThresholdValue
SYNTAX Integer
VALUE This value must be greater than 0
8.9. Class QoSPolicyTrfcProf
This is an abstract base class that models a traffic profile. Traffic
profiles specify the maximum rate parameters used within admission
decisions. The association QosPolicyTrfcProfInAdmissionAction binds the
admission decision to the traffic profile. The class definition is as
follows:
NAME QoSPolicyTrfcProf
DERIVED FROM Policy
ABSTRACT True
PROPERTIES None
Snir, Ramberg, Strassner, Cohen expires November 2001 38
draft-ietf-policy-qos-info-model-03.txt April 2001
8.10. Class QosPolicyTokenBucketTrfcProf
This class models a two- or three-level Token Bucket traffic profile.
This traffic profile carries the policer or shaper rate values to be
enforced on a flow or a set of flows. The class definition is as follows:
NAME QosPolicyTokenBucketTrfcProf
DERIVED FROM QoSPolicyTrfcProf
ABSTRACT False
PROPERTIES qpTBRate, qpTBNormalBurst, qpTBExcessBurst
8.10.1. The Property qpTBRate
This is a non-negative integer that defines the token rate in kilobits
per second. A rate of zero means that all packets will be out of
profile. This property is defined as follows:
NAME qpTBRate
SYNTAX Integer
VALUE This value must be greater than 0
8.10.2. The Property qpTBNormalBurst
This property is an integer that defines the normal size of a burst
measured in bytes. This property is defined as follows:
NAME qpTBNormalBurst
SYNTAX Integer
VALUE This value must be greater than 0
8.10.3. The Property qpTBExcessBurst
This property is an integer that defines the excess size of a burst
measured in bytes. This property is defined as follows:
NAME qpTBExcessBurst
SYNTAX Integer
VALUE This value must be greater than 0
Snir, Ramberg, Strassner, Cohen expires November 2001 39
draft-ietf-policy-qos-info-model-03.txt April 2001
8.11. Class qosPolicyIntServTrfcProf
This class represents an IntServ traffic profile. Values of IntServ
traffic profiles are compared against Traffic specification (TSPEC) and
QoS Reservation (FLOWSPEC) requests carried in RSVP requests. The class
definition is as follows:
NAME qosPolicyIntServTrfcProf
DERIVED FROM QosPolicyTrfcProf
ABSTRACT False
PROPERTIES qpISTokenRate, qpISPeakRate, qpISBucketSize, qpISResvRate,
qpISResvSlack, qpISMinPolicedUnit, qpISMaxPktSize
8.11.1. The Property qpISTokenRate
This property is a non-negative integer that defines the token rate
parameter, measured in kilobits per second. This property is defined as
follows:
NAME qpISTokenRate
SYNTAX Integer
VALUE This value must be greater than 0
8.11.2. The Property qpISPeakRate
This property is a non-negative integer that defines the peak rate
parameter, measured in kilobits per second. This property is defined as
follows:
NAME qpISPeakRate
SYNTAX Integer
VALUE This value must be greater than 0
8.11.3. The Property qpISBucketSize
This property is a non-negative integer that defines the token bucket
size parameter, measured in bytes. This property is defined as follows:
NAME qpISBucketSize
SYNTAX Integer
VALUE This value must be greater than 0
Snir, Ramberg, Strassner, Cohen expires November 2001 40
draft-ietf-policy-qos-info-model-03.txt April 2001
8.11.4. The Property qpISResvRate
This property is a non-negative integer that defines the reservation rate
(R-Spec) in the RSVP guaranteed service reservation. It is measured in
kilobits per second. This property is defined as follows:
NAME qpISResvRate
SYNTAX Integer
VALUE This value must be greater than 0
8.11.5. The Property qpISResvSlack
This property is a non-negative integer that defines the RSVP slack
term in the RSVP guaranteed service reservation. It is measured in
microseconds. This property is defined as follows:
NAME qpISResvSlack
SYNTAX Integer
VALUE This value must be greater than 0
8.11.6. The Property qpISMinPolicedUnit
This property is a non-negative integer that defines the minimum RSVP
policed unit, measured in bytes. This property is defined as follows:
NAME qpISMinPolicedUnit
SYNTAX Integer
VALUE This value must be greater than 0
8.11.7. The Property qpISMaxPktSize
This property is a non-negative integer that defines the maximum
allowed packet size for RSVP messages, measure in bytes. This property is
defined as follows:
NAME qpISMaxPktSize
SYNTAX Integer
VALUE This value must be greater than 0
Snir, Ramberg, Strassner, Cohen expires November 2001 41
draft-ietf-policy-qos-info-model-03.txt April 2001
8.12. The Class QosPolicyAttributeValue
This class is used to represent a single or set of property values in
an object. This value can be used in conjunction with reference values
carried in RSVP objects, as specified in [RFC2751]. The property name is
used to specify which of the properties in the object is being used as
the condition. The value of this property will then be retrieved, and a
match (which is dependent on the property name) will be used to see if
the condition is satisfied or not. The class definition is as follows:
NAME QosPolicyAttributeValue
DERIVED FROM PolicyImplicitValue
ABSTRACT False
PROPERTIES qpAttributeName, qpAttributeValueList
8.12.1. The Property qpAttributeName
This property defines the name of the attribute that the list of values
should be compared against. This property is defined as follows:
NAME qpAttributeName
SYNTAX String
8.12.2. The Property qpAttributeValueList
This property contains a list of attribute values. Each value is compared
to a value of the property specified by the qpAttributeName property.
This property is defined as follows:
NAME qpAttributeValueList
SYNTAX String
8.13. The Class "QoSPolicyRSVPVariable"
This is an abstract class that serves as the base class for all implicit
variables that have to do with RSVP conditioning. The class definition is
as follows:
NAME QoSPolicyRSVPVariable
DESCRIPTION An abstract base class used to build other classes that
specify different attributes of an RSVP request
DERIVED FROM PolicyImplicitVariable
ABSTRACT TRUE
PROPERTIES None
Snir, Ramberg, Strassner, Cohen expires November 2001 42
draft-ietf-policy-qos-info-model-03.txt April 2001
8.14. The Class "QoSPolicyRSVPSourceIPv4Variable"
This is a concrete class that contains the source IPv4 address of the
RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP
RESV FILTER_SPEC [RSVP] objects. The class definition is as follows:
NAME QoSPolicyRSVPSourceIPv4Variable
DESCRIPTION The source IPv4 address of the RSVP signaled flow, as
defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV
FILTER_SPEC [RSVP] objects.
ALLOWED VALUE TYPES: PolicyIPv4AddrValue
DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT FALSE
PROPERTIES None
8.15. The Class "QoSPolicyRSVPDestinationIPv4Variable"
This is a concrete class that contains the destination IPv4 address of
the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and
RSVP RESV FILTER_SPEC [RSVP] objects. The class definition is as follows:
NAME QoSPolicyRSVPDestinationIPv4Variable
DESCRIPTION The destination IPv4 address of the RSVP signaled flow,
as defined in the RSVP PATH and RESV SESSION [RSVP] objects.
ALLOWED VALUE TYPES: PolicyIPv4AddrValue
DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT FALSE
PROPERTIES None
8.16. The Class "QoSPolicyRSVPSourceIPv6Variable"
This is a concrete class that contains the source IPv6 address of the
RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP
RESV FILTER_SPEC [RSVP] objects. The class definition is as follows:
NAME QoSPolicyRSVPSourceIPv6Variable
DESCRIPTION The source IPv6 address of the RSVP signaled flow, as
defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV
FILTER_SPEC [RSVP] objects.
ALLOWED VALUE TYPES: PolicyIPv6AddrValue
DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT FALSE
PROPERTIES None
Snir, Ramberg, Strassner, Cohen expires November 2001 43
draft-ietf-policy-qos-info-model-03.txt April 2001
8.17. The Class "QoSPolicyRSVPDestinationIPv6Variable"
This is a concrete class that contains the destination IPv6 address of
the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and
RSVP RESV FILTER_SPEC [RSVP] objects. The class definition is as follows:
NAME QoSPolicyRSVPDestinationIPv6Variable
DESCRIPTION The destination IPv6 address of the RSVP signaled flow,
as defined in the RSVP PATH and RESV SESSION [RSVP] objects.
ALLOWED VALUE TYPES: PolicyIPv6AddrValue
DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT FALSE
PROPERTIES None
8.18. The Class "QoSPolicyRSVPSourcePortVariable"
This is a concrete class that contains the source port of the RSVP
signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV
FILTER_SPEC [RSVP] objects. The class definition is as follows:
NAME QoSPolicyRSVPSourcePortVariable
DESCRIPTION The source port of the RSVP signaled flow, as defined in the
RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP]
objects.
ALLOWED VALUE TYPES: Integer
DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT FALSE
PROPERTIES None
8.19. The Class "QoSPolicyRSVPDestinationPortVariable"
This is a concrete class that contains the destination port of the RSVP
signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV
FILTER_SPEC [RSVP] objects. The class definition is as follows:
NAME QoSPolicyRSVPDestinationPortVariable
DESCRIPTION The destination port of the RSVP signaled flow, as defined
in the RSVP PATH and RESV SESSION [RSVP] objects.
ALLOWED VALUE TYPES: Integer
DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT FALSE
PROPERTIES None
Snir, Ramberg, Strassner, Cohen expires November 2001 44
draft-ietf-policy-qos-info-model-03.txt April 2001
8.20. The Class "QoSPolicyRSVPIPProtocolVariable"
This is a concrete class that contains the IP Protocol number of the RSVP
signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP]
objects. The class definition is as follows:
NAME QoSPolicyRSVPIPProtocolVariable
DESCRIPTION The IP Protocol number of the RSVP signaled flow, as defined
in the RSVP PATH and RESV SESSION [RSVP] objects.
ALLOWED VALUE TYPES: Integer
DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT FALSE
PROPERTIES None
8.21. The Class "QoSPolicyRSVPIPVersionVariable"
This is a concrete class that contains the IP Protocol version number of
the RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION
[RSVP] objects. The well-known version numbers are 4 and 6. The class
definition is as follows:
NAME QoSPolicyRSVPIPVersionVariable
DESCRIPTION The IP version number of the IP Addresses carried the RSVP
signaled flow, as defined in the RSVP PATH and RESV SESSION
[RSVP] objects.
ALLOWED VALUE TYPES: Integer
DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT FALSE
PROPERTIES None
8.22. The Class "QoSPolicyRSVPDCLASSVariable"
This is a concrete class that contains the DSCP value as defined in the
RSVP DCLASS [DCLASS] object. The class definition is as follows:
NAME QoSPolicyRSVPDCLASSVariable
DESCRIPTION The DSCP value as defined in the RSVP DCLASS [DCLASS]
object.
ALLOWED VALUE TYPES: Integer, BitString
DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT FALSE
PROPERTIES None
Snir, Ramberg, Strassner, Cohen expires November 2001 45
draft-ietf-policy-qos-info-model-03.txt April 2001
8.23. The Class "QoSPolicyRSVPStyleVariable"
This is a concrete class that contains the reservation style as defined
in the RSVP STYLE object in the RESV message [RSVP]. The class definition
is as follows:
NAME QoSPolicyRSVPStyleVariable
DESCRIPTION The reservation style as defined in the RSVP STYLE object
in the RESV message [RSVP].
ALLOWED VALUE TYPES: BitString, Integer (Integer has an
enumeration of { Fixed-Filter=1 ,
Shared-Explicit=2,
Wildcard-Filter=3}
DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT FALSE
PROPERTIES None
8.24. The Class "QoSPolicyIntServVariable"
This is a concrete class that contains the Integrated Service requested
in the RSVP Reservation message, as defined in the FLOWSPEC RSVP Object
[RSVP]. The class definition is as follows:
NAME QoSPolicyRSVPIntServVariable
DESCRIPTION The integrated Service requested in the RSVP Reservation
message, as defined in the FLOWSPEC RSVP Object [RSVP].
ALLOWED VALUE TYPES: Integer (An enumerated value of
{ CL=1 , GS=2, NULL=3}
DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT FALSE
PROPERTIES None
8.25. The Class "QoSPolicyRSVPMessageTypeVariable"
This is a concrete class that contains the RSVP message type, as defined
in the RSVP message common header [RSVP] object. The class definition is
as follows:
Snir, Ramberg, Strassner, Cohen expires November 2001 46
draft-ietf-policy-qos-info-model-03.txt April 2001
NAME QoSPolicyRSVPMessageTypeVariable
DESCRIPTION The RSVP message type, as defined in the RSVP message
common header [RSVP] object.
ALLOWED VALUE TYPES: Integer (An enumerated value of
{ PATH=1 , PATHTEAR=2, RESV=3,
RESVTEAR=4, ResvErr=5, CONF=6}
DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT FALSE
PROPERTIES None
8.26. The Class "QoSPolicyRSVPPreemptionPriorityVariable"
This is a concrete class that contains the RSVP reservation priority, as
defined in [RSVP_PREEMP] object. The class definition is as follows:
NAME QoSPolicyRSVPPreemptionPriorityVariable
DESCRIPTION The RSVP reservation priority as defined in [RSVP_PREEMP].
ALLOWED VALUE TYPES: Integer
DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT FALSE
PROPERTIES None
8.27. The Class "QoSPolicyRSVPPreemptionDefPriorityVariable"
This is a concrete class that contains the RSVP reservation defending
priority, as defined in [RSVP_PREEMP] object. The class definition is as
follows:
NAME QoSPolicyRSVPPreemptionDefPriorityVariable
DESCRIPTION The RSVP preemption reservation defending priority as
defined in [RSVP_PREEMP].
ALLOWED VALUE TYPES: Integer
DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT FALSE
PROPERTIES None
Snir, Ramberg, Strassner, Cohen expires November 2001 47
draft-ietf-policy-qos-info-model-03.txt April 2001
8.28. The Class "QoSPolicyRSVPUserVariable"
This is a concrete class that contains the ID of the user that initiated
the flow as defined in the User Locator string in the Identity Policy
Object [RFC2752]. The class definition is as follows:
NAME QoSPolicyRSVPUserVariable
DESCRIPTION The ID of the user that initiated the flow as defined in
the User Locator string in the Identity Policy Object
[RFC2752].
ALLOWED VALUE TYPES: QoSPolicyDNValue, PolicyStringValue,
QosPolicyAttributeValue
DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT FALSE
PROPERTIES None
8.29. The Class "QoSPolicyRSVPApplicationVariable"
This is a concrete class that contains the ID of the application that
generated the flow as defined in the application locator string in the
Application policy object [RFC2872]. The class definition is as follows:
NAME QoSPolicyRSVPApplicationVariable
DESCRIPTION The ID of the application that generated the flow as
defined in the application locator string in the
Application policy object [RFC2872].
ALLOWED VALUE TYPES: QoSPolicyDNValue, PolicyStringValue,
QosPolicyAttributeValue
DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT FALSE
PROPERTIES None
Snir, Ramberg, Strassner, Cohen expires November 2001 48
draft-ietf-policy-qos-info-model-03.txt April 2001
8.30. The Class "QoSPolicyRSVPAuthMethodVariable"
This is a concrete class that contains the type of authentication used in
the Identity Policy Object [RFC2752]. The class definition is as follows:
NAME QoSPolicyRSVPAuthMethodVariable
DESCRIPTION The RSVP Authentication type used in the Identity Policy
Object [RFC2752].
ALLOWED VALUE TYPES: Integer (An enumeration of { NONE=0,
PLAIN-TEXT=1, DIGITAL-SIG = 2,
KERBEROS_TKT=3, X509_V3_CERT=4,
PGP_CERT=5}
DERIVED FROM QoSPolicyRSVPVariable
ABSTRACT FALSE
PROPERTIES None
8.31. The Class QoSPolicyDNValue
This class is used to represent a single or set of Distinguished Name
[DNDEF] values, including wildcards. A Distinguished Name is a name that
can be used as a key to retrieve an object from a directory service. This
value can be used in comparison to reference values carried in RSVP
policy objects, as specified in [RFC2752].
The class definition is as follows:
NAME QoSPolicyDNValue
DERIVED FROM PolicyImplicitValue
ABSTRACT False
PROPERTIES qpDNList
8.31.1. The Property qpDNList
This attribute provides an unordered list of strings, each representing
a Distinguished Name (DN) with wildcards. The format of a DN is defined
in [DNDEF]. The asterisk character ("*") is used as wildcard for either
a single attribute value or a wildcard for an RDN. The order of RDNs is
significant. For example: A qpDNList attribute carrying the following
value: "OU=Sales, CN=*, O=Widget Inc., *, C=US"
matches: "OU=Sales, CN=J. Smith, O=Widget Inc, C=US" and also matches:
"OU=Sales, CN=J. Smith, O=Widget Inc, C=US, CN=CA".
The attribute is defined as follows:
NAME qpDNList
SYNTAX List of Distinguished Names implemented as strings, each of
which serves as a reference to another object.
Snir, Ramberg, Strassner, Cohen expires May 2001 49
Draft-ietf-policy-qos-info-model-01.txt November 2000
8.32. The Class QoSPolicyRSVPSimpleAction
This action controls the content of RSVP messages and the way RSVP
requests are admitted. Depending on the value of its qpRSVPActionType
property, this action directly translates into either a COPS Replace
Decision or a COPS Stateless Decision, as defined in COPS for RSVP. Only
variables that are subclasses of the QoSPolicyRSVPVariable are allowed to
be associated with this action. The property definition is as follows:
NAME QoSPolicyRSVPSimpleAction
DESCRIPTION This action controls the content of RSVP messages and the
way RSVP requests are admitted.
DERIVED FROM SimplePolicyAction
ABSTRACT False
PROPERTIES qpRSVPActionType
Restricts the PolicyVariableInSimplePolicyAction aggregation to
QoSPolicyRSVPVariable.
8.32.1. The Property qpRSVPActionType
This property may contain one or two values to denote the type of RSVP
action. The value 'REPLACE' denotes a COPS Replace Decision action. The
value 'STATELESS' denotes a COPS Stateless Decision action. Refer to
[COPS] for details. This property is multi-value, which means that both
action types are to be executed.
NAME QpRSVPActionType
DESCRIPTION This property specifies whether the action type is for COPS
Replace or Stateless decision or both.
SYNTAX Integer
VALUE This is an enumerated integer. A value of 0 specifies a
COPS Replace decision. A value 1 specifies a COPS Stateless
Decision.
9. Acknowledgements
The authors wish to thank the input of the participants of the Policy
Framework working group, and especially Bob Moore and Alex Wang for
their helpful contributions.
10. Security Considerations
The Policy Core Information Model (PCIM) [PCIM] describes the general
security considerations related to the general core policy model. The
extensions defined in this document do not introduce any additional
considerations related to security.
Snir, Ramberg, Strassner, Cohen expires November 2001 50
draft-ietf-policy-qos-info-model-03.txt November 2001
11. References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[PCIM] Strassner, J., and E. Ellesson, B. Moore, A. Westerinen,
"Policy Core Information Model -- Version 1 Specification",
RFC 3060, February 2001.
[PCIMe] B. Moore, L. Rafalow, Y. Ramberg, Y. Snir, J. Strassner,
A. Westerinen, R. Chadha, M. Brunner, R. Cohen,
"Policy Core Information Model Extensions",
<draft-ietf-policy-pcim-ext-01.txt>
[TERMS] A. Westerinen, J. Schnizlein, J. Strassner, M. Scherling,
B. Quinn, J. Perry, S. Herzog, A. Huynh, M. Carlson,
S. Waldbusser, "Terminology",
<draft-ietf-policy-terminology-02.txt>
[QDDIM] J. Strassner, A. Westerinen, B. Moore, D. Durham, W. Weiss,
"Information Model for Describing Network Device QoS Mechanisms
for Differentiated Services",
<draft-ietf-policy-qos-device-info-model-02.txt>
[DIFFSERV] S. Blake, et. Al., "An Architecture for Differentiated
Services", RFC 2475
[UML] Please see the following web page for the latest (1.3 as of this
writing) UML specification:
http://www.rational.com/uml/resources/documentation/index.jsp
[INTSERV] R. Braden, D. Clark, S. Shenker, "Integrated Services in
the Internet Architecture: an Overview", RFC 1633.
[RSVP] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC2205
[QoSSCHEMA] Y. Snir, Y. Ramberg, J. Strassner, R. Cohen, "Policy QoS
LDAP Schema", <draft-ietf-policy-qos-schema-02.txt>
[RFC2749] S . Herzog, Ed., J. Boyle, R. Cohen, D. Durham, R. Rajan,
A. Sastry, "COPS usage for RSVP", RFC2749
[RFC2751] S. Herzog, "Signaled Preemption Priority Policy Element",
RFC2751
[DIFF-MIB] F. Baker, K. Chan, A. Smith, "Management Information Base
for the Differentiated Services Architecture",
<draft-ietf-diffserv-mib-09.txt>
Snir, Ramberg, Strassner, Cohen expires November 2001 51
draft-ietf-policy-qos-info-model-03.txt November 2001
[AF] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured Forwarding
PHB Group", RFC2597
[CL] J. Wroclawski, "Specification of the Controlled-Load Network
Element Service", RFC2211
[RSVP-IS] J. Wroclawski, "The Use of RSVP with IETF Integrated
Services", RFC2210
[GS] S. Shenker, C. Partridge, R. Guerin, "Specification of the
Guaranteed Quality of Service", RFC2212
[DCLASS] Y. Bernet, "Format of the RSVP DCLASS Object", RFC2996
[RFC2752] S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore,
S. Herzog, "Identity Representation for RSVP", RFC2752
[RFC2872] Y. Bernet, R. Pabbati, "Application and Sub Application
Identity Policy Element for Use with RSVP", RFC2872
[DNDEF] M. Wahl, S. Kille, and T. Howes, "Lightweight Directory
Access Protocol (v3): UTF-8 String Representation of
Distinguished Names", RFC2253
12. Authors' Addresses
Yoram Ramberg
Cisco Systems
4 Maskit Street
Herzliya Pituach, Israel 46766
Phone: +972-9-970-0081
Fax: +972-9-970-0219
E-mail: yramberg@cisco.com
Yoram Snir
Cisco Systems
4 Maskit Street
Herzliya Pituach, Israel 46766
Phone: +972-9-970-0085
Fax: +972-9-970-0366
E-mail: ysnir@cisco.com
John Strassner
Cisco Systems
725 Alder Drive, , Building 20
Milpitas, CA 95035
Phone: +1-408-527-1069
Fax: +1-408-527-2477
E-mail: johns@cisco.com
Snir, Ramberg, Strassner, Cohen expires November 2001 52
draft-ietf-policy-qos-info-model-03.txt November 2001
Ron Cohen
Ntear LLC
Phone:
Fax:
E-mail: ronc@ntear.com
13. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
Snir, Ramberg, Strassner, Cohen expires November 2001 53
Datatracker
Report a datatracker bug
draft-ietf-policy-qos-info-model-03
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 3644.
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |