One document matched: draft-ietf-policy-qos-info-model-01.txt
Differences from draft-ietf-policy-qos-info-model-00.txt
Policy Framework Y. Snir
Internet Draft Y. Ramberg
Expires April 2000 J. Strassner
draft-ietf-policy-qos-info-model-01.txt R. Cohen
Cisco Systems
Policy Framework QoS Information Model
Status of this Memo
This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
This document presents an object-oriented information model for
representing network QoS policies. This document refines the core
policy information model presented in [PCIM]. Specifically, this draft
refines the concept of generic policy rules, conditions and actions to
cover extensions necessary for representing QoS policies. It also
provides refinement of additional concepts that are important for
building rule-specific as well as reusable QoS policy rules. This
information model covers Differentiated Services QoS enforcement, and
Integrated Service QoS enforcement via policy control on RSVP
admission. It is important to note that this document defines an
information model, which by definition is independent of any particular
repository and access protocol. A companion document [QoSSCHEMA]
defines the mapping of these classes to a directory that uses LDAPv3 as
its access protocol. A second companion document [QOSDEV] supplies low-
level definitions of QoS mechanisms that are controlled by this
document.
Snir, Ramberg, Strassner, Cohen expires October 2000 1
Draft-ietf-policy-qos-info-model-01.txt April 2000
Table of Contents
1. Introduction 5
1.1 Goals 5
1.2 Approach and Related Documents 5
2. Information Model Hierarchy 6
2.1 Interaction Between the PCIM and This Document 7
2.1.1 Extension of Concepts in the PCIM 7
2.1.2 Addition of New Concepts Not in the PCIM 7
2.2 High-Level Class Hierarchy 8
3. Containment Hierarchy 11
3.1. Containment Model 11
3.2. QoS Domain Containment Hierarchy 12
3.2.1. Domain Grouping and Nesting 13
3.2.2. Resource Sharing 15
3.2.3. Placement 15
3.2.4. Named Policy Containers 16
3.2.5. Policy Rules 17
3.2.6. Conditions and Actions 18
3.2.7. Data Tree Example 19
3.3. Reusable-Object Repositories 19
3.4. Relationships Between QoS Domains and Repositories 20
4. Constructing a QoS Policy Rule 21
4.1 Policy Rule Structure 21
4.2 QoS Policy Conditions 22
4.2.1 Reusable vs. Ad-Hoc Conditions 23
4.2.2. Using Simple Conditions 24
4.2.3. Composing Complex Conditions 24
4.3 Simple Condition Operator 25
4.4. QoS Policy Variables 25
4.4.1 Variable Binding 26
4.4.2. Pre-Defined Variables 26
4.5 QoS Policy Values 30
4.6. PolicyTimePeriodCondition 30
4.7. Actions 30
4.7.1 Provisioning Actions 31
4.7.1.1 Meters 32
4.7.1.2 Markers 32
4.7.1.3 Shapers 32
4.7.1.4 Droppers 33
4.7.1.5 Examples 33
4.7.2 Signaling Actions 34
4.8 Traffic Profiles 37
4.8.1 Provisioning Traffic Profiles 37
4.8.1 RSVP Traffic Profiles 38
5. Decision strategy 39
5.1. First match 39
5.2. Match All 39
Snir, Ramberg, Strassner, Cohen expires October 2000 2
Draft-ietf-policy-qos-info-model-01.txt April 2000
5.3. Decision Strategy example 40
5.3.1 Default Operation using First Match Everywhere 40
5.3.2 Operation Using Other Decision Strategies 41
6. Per Hop Behavior 42
6.1. PHBs 42
6.2. PHB Sets 42
7. QoS Policy Class Inheritance 43
8. Class Definitions 45
8.1. Class qosPolicyDomain 45
8.1.1. The Property qpDomainName 45
8.1.2. The Property qpPHBSet 45
8.1.3. The Property qpPolicyRuleMatchMethod 45
8.2. Class qosNamedPolicyContainer 46
8.2.1. The Property qpPriority 46
8.2.2. The Property qpNamedPolicyRuleMatchMethod 46
8.3. Class qosPolicyPRAction 47
8.3.1. The Property qpDirection 47
8.3.2. The Property qpSetDSCPvalue 47
8.3.3. The Property qpMeter 47
8.3.4. The Property qpMeterScope 48
8.3.5. The Property qpTrfcProf 48
8.3.6. The Property qpOutOfProfileAction 48
8.3.7. The Property qpOutofProfileRemarkValue 48
8.4. Class qosPolicyRSVPAction 48
8.4.1. The Property qpRSVPDirection 49
8.4.2. The Property qpRSVPMessageType 49
8.4.3. The Property qpRSVPStyle 49
8.4.4. The Property qpRSVPServiceType 49
8.4.5. The Property qpRSVPInstallAction 50
8.4.6. The Property qpRSVPCtrlAction 50
8.4.7. The Property qpRSVPMeter 50
8.4.8. The Property qpRSVPMeterScope 50
8.4.9. The Property qpRSVPTrfcProf 51
8.5. Class qosPolicyPRTrfcProf 51
8.5.1. The Property qpPRRate 51
8.5.2. The Property qpPRNormalBurst 51
8.5.3. The Property qpPRExcessBurst 51
8.6. Class qosPolicyRSVPTrfcProf 52
8.6.1. The Property qpRSVPTokenRate 52
8.6.2. The Property qpRSVPPeakRate 52
8.6.3. The Property qpRSVPBucketSize 52
8.6.4. The Property qpRSVPResvRate 53
8.6.5. The Property qpRSVPResvSlack 53
8.6.6. The Property qpRSVPSessionNum 53
8.6.7. The Property qpMinPolicedUnit 53
8.6.8. The Property qpMaxPktSize 53
8.7. Class qosPolicyRSVPSignalCtrlAction 54
8.7.1. The Property qpForwardingMode 54
8.7.2. The Property qpSendError 54
Snir, Ramberg, Strassner, Cohen expires October 2000 3
Draft-ietf-policy-qos-info-model-01.txt April 2000
8.7.3. The Property qpReplaceDSCP 55
8.7.4. The Property qpReplacePreemptionPriority 55
8.7.5. The Property qpReplaceDefendingPriority 55
8.8. Class qosPolicyRSVPInstallAction 55
8.8.1. The Property qpSetDSCPValue 56
8.8.2. The Property qpSetDefendingPriority 56
8.8.3. The Property qpSetPreemptionPriority 56
8.9. Class qosPolicySimpleCondition 56
8.9.1. The Property qpOperator 57
8.9.2. The Property qpVariableAtom 57
8.9.3. The Property qpValueAtom 57
8.10. Class qosPolicyVariable 57
8.10.1. The Property qpVariableName 58
8.10.2 The Property qpValueTypes 58
8.10.3. The Property qpVariableDescription 58
8.10.4. The Property qpValueConstraints 59
8.11. Class qosPolicyValue 59
8.12. Class qosPolicyIPv4AddrValue 59
8.12.1. The Property qpIPv4AddrList 59
8.13. Class qosPolicyIPv6AddrValue 60
8.13.1. The Property qpIPv6AddrList 60
8.14. Class qosPolicyMACAddrValue 61
8.14.1. The Property qpMACAddrList 61
8.15. Class qosPolicyStringValue 62
8.15.1. The Property qpStringList 62
8.16 Class qosPolicyBitStringValue 62
8.16.1. The Property qpBitStringList 62
8.17. Class qosPolicyDNValue 63
8.17.1. The Property qpDNList 63
8.18. Class qosPolicyAttributeValue 63
8.18.1. The Property qpAttributeName 64
8.18.2. The Property qpAttributeValueList 64
8.19. Class qosPolicyIntegerValue 64
8.19.1. The Property qpIntegerList 65
8.20. Class qosPolicyPHBSet 65
8.21. Class qosPolicyPHB 65
8.21.1. The Property qpDSCP 66
8.22. Class qosPolicyMeter 66
9. Extending the QoS Policy Schema 67
9.1. Extending qosPolicyValue 67
9.2. Extending qosPolicySimpleCondition 67
9.3. Extending qosPolicyAction 67
10. Security Considerations 68
11. Acknowledgments 68
12. References 68
13. Author's Addresses 69
14. Full Copyright Statement 70
Snir, Ramberg, Strassner, Cohen expires October 2000 4
Draft-ietf-policy-qos-info-model-01.txt April 2000
1. Introduction
This document presents an object-oriented information model for
representing network QoS policies. As such, it is independent of any
specific repository type and access protocol. This document refines the
core policy information model presented in [PCIM]. Specifically, this
draft refines the concept of generic policy rules, conditions and
actions to cover extensions necessary for representing QoS policies.
This information model covers Differentiated Service QoS enforcement,
and Integrated Service QoS enforcement via policy control on RSVP
admission. A companion document [QoSSCHEMA] defines the mapping
of these classes to a directory that uses LDAPv3 as its access
protocol. A second companion document [QOSDEV] supplies low-level
definitions of QoS mechanisms that are controlled by this document.
1.1 Goals
This document presents high level QoS policies that can be used to
enforce consistent behavior across a network, regardless of the actual
vendor-specific implementation details. The purpose of introducing a
standard information model is to allow interoperability between Policy
Servers, Policy Management Applications, and Network devices.
This document solves two problems. First, different devices have
different capabilities, and may respond differently to the same high-
level policy rule. This document solves this by defining a set of
common abstractions that can be used to build high-level QoS policies.
This enables different devices to use the same low-level abstractions
of mechanisms to implement QoS services, which are controlled by the
QoS policy rules defined in this document. The companion document
[QOSDEV] defines an information model for representing low-level QoS
mechanisms.
Second, different policy servers and applications may provision parts
of the network differently if no common high-level policy description
exists. This document defines a standard information model that
provides common definitions and semantics to be assigned to build,
interpret and enforce high-level policy rules.
1.2 Approach and Related Documents
The information model presented in this document contains information
that can be shared by other network policy managers (e.g., Security
managers, IP address managers, and others). Examples include sharing of
the same definition of well-known application port numbers, IP
addresses of servers and other network attributes. It allows checking
of consistent behaviors of the interaction between the different
managers by comparing, for example, the set of QoS and security actions
enforced on the same set of flows.
Snir, Ramberg, Strassner, Cohen expires October 2000 5
Draft-ietf-policy-qos-info-model-01.txt April 2000
Representation of the inherent QoS mechanisms of devices is described
in a companion draft [QOSDEV]. It provides a standard information model
for representing low-level QoS mechanisms that exist in devices in a
vendor-independent way. This document, augmented with the information
provided in [QOSDEV], together provide a set of enforceable policies
that control the QoS mechanisms on network devices.
The concept of PHBs is central to Differentiated Services. An
additional information model for representation of PHBs is defined in
[PHBSET], and a corresponding LDAP representation is provided in
[PHBLDAP]. This document is also intended to work with [PHBSET].
The remainder of this document presents, describes and defines the
concepts of the QoS Policy Information Model (QPIM). Relationships to
the Core schema and issues related to correct usage of the schema are
defined in [QOSSCHEMA].
2. Information Model Hierarchy
This section discusses the relationships between the Policy Core
Information Model ([PCIM]), the QoS Policy Information Model (QPIM,
which is this document) and future extensions of the QPIM.
The [PCIM] models high-level policy concepts and introduces structural
conventions and nomenclature common to all types of policies. The
fundamental purpose of the [PCIM] is to provide a generic
representation of the structure of a policy rule, along with a set of
classes and relationships that can serve as a common representation of
policy groups, rules, conditions, and actions. This enables derived
information models and schemata to all use a common set of terminology,
classes, and approaches, thus facilitating interoperability.
The QPIM refines the concepts of the [PCIM] and introduces a framework
of classes and relationships dedicated to model QoS Policies. This set
of classes and relationships can be used to configure and manage
devices that are IntServ- and DiffServ-compliant. The QPIM provides
building blocks to control most of the policy aspects required by
IntServ and DiffServ, but it is clear that not all functions are
provided.
It is also clear that other information models and their derived
schemata can use some of the concepts in this document. For example,
the concept of representing IP Addresses, as well as variables and
constants, are not specific to QoS. However, this is the first
information model that is derived from the [PCIM], and it is not clear
that other working groups will be satisfied with these representations.
These concepts will be socialized to other working groups and, if they
agree with the representation in this document (or if a suitable
compromise can be developed), then these concepts will be moved into a
separate document.
Snir, Ramberg, Strassner, Cohen expires October 2000 6
Draft-ietf-policy-qos-info-model-01.txt April 2000
The PCIM and QPIM are both inherently extensible. Furthermore, they are
designed to fit together to produce one virtual information model. As
such, both are independent of any particular repository and access
protocol. However, mappings can be defined to translate the data from
this single "virtual information model" to a form that can be
implemented in a specific type of repository that uses one or more
specific access protocols. Examples of mapping the concepts of the
[PCIM] and this document to a form that can be implemented in a
directory that uses LDAP as its access protocol are provided in
[PFSCHEMA] and [QOSSCHEMA], respectively.
This document specifies an extensible information model. While this
document defines facilities for building policy rules, conditions and
actions to build QoS policies, it is recognized that not all required
functionality can or should be defined in this document. Therefore, any
implementation-specific schema that is derived from this information
model should further concretize the QoS concepts of the QoS Policy
schema to suit its own application-specific needs.
2.1 Interaction Between the PCIM and This Document
This document both extends concepts that are part of the [PCIM] as well
as adds new functions that are not part of the [PCIM].
2.1.1 Extension of Concepts in the PCIM
The concept of a policy repository, that is embedded within another
repository that contains policy and non-policy information, was
originally defined in an earlier version of the QPIM. It has
subsequently been moved into the [PCIM], since it is a generic concept
that is not limited to QoS, and can be used by other applications. This
document defines specific refinements of the "embedded policy
repository" to accommodate the application-specific needs of QoS
provisioning.
Similarly, the concepts of reusable- objects vs. rule-specific objects
have been moved from an earlier version of this document to the [PCIM].
Equally similarly, this document defines specific extensions to
guide the implementation of reusable- vs. rule-specific QoS objects.
This document also extends the concept of a policy rule, along with
conditions and actions that are specific to QoS. It further defines
different types of actions that target DiffServ and IntServ actions.
2.1.2 Addition of New Concepts Not in the PCIM
There are several notable new concepts that are not part of the [PCIM].
These include rule nesting, rule decision strategy, pre-defined
variables and constants, and PHBs.
Snir, Ramberg, Strassner, Cohen expires October 2000 7
Draft-ietf-policy-qos-info-model-01.txt April 2000
The [PCIM] defines the ability to group policy rules by defining the
policyGroup class. This class has the following semantics: it can
either be used to contain a set of policyRules, or a set of
policyGroups, but not both. However, this simply gathers policy rules
together in a common container. It does not nest policy rules.
This document adds the concept of nesting one or more policy rules
within a policy rule. For example, one could think of a policy rule
that controls how a user logs onto the network as consisting of the
high-level rule itself. This high-level rule could consist of a set of
lower-level rules that are invoked at various stages of processing
(e.g., how the user is authenticated, how the IP Address is assigned,
etc.).
Since there is no concept of nested rules in the [PCIM], there is no
need for a decision strategy to be used to define the order of
processing of these rules. However, such a decision strategy must be
defined in this document because it does define nested rules. This
strategy defines an ordering that can be applied to a set of policyRule
and policyGroup objects within a larger context (e.g., a policy
domain). This in turn controls the execution of different policy
actions.
This document also defines a set of variable and constant definitions
for use with QoS policies. This concept is not present in the [PCIM]
because the purpose of the [PCIM] is to provide a general structure for
representing policy rules, conditions and actions. Variable and
constant definitions represent specific concepts that have pre-defined
semantics.
Finally, this document adds a general structure for accommodating PHBs.
PHBs are a concept that is specific to DiffServ, and thus are not
defined in the [PCIM].
2.2 High-Level Class Hierarchy
The following diagram shows how the classes in this document relate to
the classes defined in the PCIM.
Snir, Ramberg, Strassner, Cohen expires October 2000 8
Draft-ietf-policy-qos-info-model-01.txt April 2000
(continued from previous page)
[unrooted]
|
+--Policy (abstract, defined in PCIM)
| |
| +---PolicyGroup (PCIM)
| | |
| | +---qosPolicyDomain (this document)
| | |
| | +---qosNamedPolicyContainer (this document)
| |
| +---PolicyRule (PCIM)
| |
| +---PolicyCondition (PCIM)
| | |
| | +---PolicyTimePeriodCondition (PCIM)
| | |
| | +---VendorPolicyCondition (PCIM)
| | |
| | +---qosPolicySimpleCondition (this document)
| |
| +---PolicyAction (PCIM)
| | |
| | +---VendorPolicyAction (PCIM)
| | |
| | +---qosPolicyPRAction (this document)
| | |
| | +---qosPolicyRSVPAction (this document)
| | |
| | +---qosPolicyRSVPSignalCtrlAction (this document)
| | |
| | +---qosPolicyRSVPInstallAction (this document)
| | |
| +---qosPolicyPRTrfcProf (this document)
| |
| +---qosPolicyRSVPTrfcProf (this document)
| |
| +---qosPolicyVariable (this document)
| |
| +---qosPolicyValue (this document)
| | |
| | +---qosPolicyIPv4AddrValue (this document)
| | |
| | +---qosPolicyIPv6AddrValue (this document)
| | |
| | +---qosPolicyMACAddrValue (this document)
| | |
| | +---qosPolicyStringValue (this document)
| | |
(continued on next page)
Snir, Ramberg, Strassner, Cohen expires October 2000 9
Draft-ietf-policy-qos-info-model-01.txt April 2000
(continued from previous page)
[unrooted]
|
+--Policy (abstract, defined in PCIM, repeated for convenience)
| |
| +---qosPolicyValue (this document, repeated for convenience)
| | |
| | +---qosPolicyBitStringValue (this document)
| | |
| | +---qosPolicyDNValue (this document)
| | |
| | +---qosPolicyAttributeValue (this document)
| | |
| | +---qosPolicyIntegerValue (this document)
| |
| +---qosPolicyMeter
| |
| +---qosPolicyPHBSet (this document)
| |
| +---qosPolicyPHB (this document)
| |
+--CIM_ManagedSystemElement (abstract, defined in PCIM)
|
+--CIM_LogicalElement (abstract, defined in PCIM)
|
+--CIM_System (abstract, defined in PCIM)
|
+---CIM_AdminDomain (abstract, defined in PCIM)
|
+---PolicyRepository (PCIM)
Snir, Ramberg, Strassner, Cohen expires October 2000 10
Draft-ietf-policy-qos-info-model-01.txt April 2000
3. Containment Hierarchy
In this section, we describe the organization and structure of the QPIM
hierarchy.
The QPIM consists of two hierarchies: A policy
definition hierarchy and a reusable objects repository hierarchy. A
particular data tree may contain any number of instances of each
hierarchy. Section 3.1 explains the containment and reference model
used in the construction of QoS Policy data trees. Section 3.2
describes the particular containment hierarchy of the policy definition
entity, which is modeled by the qosPolicyDomain class. Section 3.3
describes the structure of the reusable objects repository. Further
down (section 3.4) we explain the relationships between those entities.
3.1. Containment Model
The QPIM uses and extends the containment model of [PCIM]. The
following paragraphs summarize this containment model. For more detail,
please refer to [PCIM].
Conceptually, the QPIM takes the form of a tree hierarchy. To describe
the hierarchy using actual instances of model data, we use the term
'data tree'. A data tree is simply an arrangement of objects in a tree
structure. The data tree starts from a root object node. The data tree
itself consists of leaf and non-leaf (i.e., container) nodes. The root
node has one or more branch nodes that are either leaf or non-leaf
nodes. The tree construction involves placing objects as leaves of
other objects while maintaining a strict tree structure.
The basic mechanism used for expressing containment is placement of the
objects in the data tree. To express the relationship of "container -
contained" between a container object and the objects it contains, the
contained objects are placed below the container object.
Certain elements of the QPIM need a mechanism for an entity to
reference objects in a different tree in the containment hierarchy than
the tree in which the referencing entity exists. For example, the class
policyRule (defined in [PCIM]) is a container of conditions and actions
(policyCondition and policyAction classes, defined in [PCIM], or their
subclasses, such as those defined in this document). However, the
information model should allow the formation of (complex) conditions
(and actions), where some of the condition's (and/or actionÆs)
components are referenced remotely. An example of such a remote
reference is a reusable condition or a reusable action. Such reusable
objects must be referenced remotely because they always reside in a
specialized portion of the tree (in this case, in the policyRepository
container) that is different from the one where the referencing rule
resides.
Snir, Ramberg, Strassner, Cohen expires October 2000 11
Draft-ietf-policy-qos-info-model-01.txt April 2000
To support a unified mechanism for containment of "local" and "remote"
objects, [PCIM] introduces the notion of association and aggregation
classes. These classes denote some type of dependency relationship that
exists between the classes that they are connecting. One type of
dependency that can be represented is, of course, containment.
[PCIM] recommends that associations and aggregations are also
implemented as classes. With respect to containment, an association
class represents the act of containment itself. For example, the
PolicyConditionInPolicyRule aggregation (defined in [PCIM]) defines
that zero or more policy conditions are contained in a given policy
rule.
In general, containment may be direct or indirect. Direct containment
means that when the association or aggregation is instantiated in a
repository, the child object will be directly scoped by the container
object. Indirect containment means that when the association or
aggregation is instantiated in a repository, the child object will
instead be referenced by the container object. As an example, if the
target repository is a directory, then direct containment is
implemented by instantiating the child object as a child node of a
container. Similarly, indirect containment would be implemented using
an attribute that is a DN (i.e., the DN points to another object).
The association classes can (and do) carry the added semantics needed
by the information model. For example, internal order of contained
objects is information that can be carried on the association objects
themselves. This makes the containment model more flexible, since the
same object may be used by two containers in different parts of the
containment tree.
Containment is implemented differently in different data stores.
Therefore, the containment tree that is being described is not
expressed directly in the information model. Rather, the information
model specifies classes and relationships that are used to model
entities and relationships between entities that are represented in the
containment data model. A mapping of the data specified in an
information model to a form that is repository-dependent must also be
specified. This is what [PFSCHEMA] and [QOSSCHEMA] do for the [PCIM]
and this document, respectively. Please refer to [PCIM] for more
information on the details of the association and aggregation class
mechanisms.
3.2. QoS Domain Containment Hierarchy
The entity that represents a single policy hierarchy is called QOS
Domain and is modeled by the qosDomain class, which is a derivative of
the PolicyGroup class in [PCIM].
Snir, Ramberg, Strassner, Cohen expires October 2000 12
Draft-ietf-policy-qos-info-model-01.txt April 2000
Figure 1 shows a summary view of the QoS domain containment hierarchy.
The text in parenthesis denotes object containment style: either
through placement in the data tree (i.e., using a class to form a
container in a specific place in the data tree) or indirectly through
association or aggregation classes.
+---------------+
|qosPolicyDomain| (root)
+---------------+
|
| +-----------------------+
-->|qosNamedPolicyContainer| (placement)
+-----------------------+
|
| +----------+
-->|policyRule| (placement)
+----------+
|
| +------------------------+
|-->|qosPolicySimpleCondition| (via association)
| +------------------------+
|
| +---------------+
-->|qosPolicyAction| (via association)
+---------------+
Figure 1: Qos Domain containment hierarchy
3.2.1. Domain Grouping and Nesting
QoS policy domains may be grouped together to model multi-domain
systems. Here, a domain is a contiguous set of nodes that operate under
a common system of administration and provide a common set of services.
Grouping may be desired to enhance various administrative tasks, or it
may be required by a particular policy application. The grouping
strategy (as well as all location-oriented strategies) is left for
users/vendors to model based on their unique situations and
requirements. This document presents guidelines and recommendations for
grouping QoS domains, but specific implementations may use other
techniques without violating the integrity and consistency of the QPIM.
One way to group QoS policy domains is by creating a common root for
several QoS policy domain data tree instances. This can be done by
using the PolicyGroup (defined in [PCIM]) class as a root for the
multi-domain tree. In this case, all that is needed is to place the
appropriate number of qosPolicyDomain (defined in this document)
instances under the appropriate policyGroup instance.
Snir, Ramberg, Strassner, Cohen expires October 2000 13
Draft-ietf-policy-qos-info-model-01.txt April 2000
Figure 2 is an example that depicts the ability to provide different
classes of service to different organizations within a single
enterprise. In this example, the enterprise is represented by an
instance of the policyGroup class. The different organizations are each
represented by a separate QoS policy domain (which is an instance of
the qosPolicyDomain class). Each qosPolicyDomain class is used as a
container to hold all of the policies for a given portion of the
organization. In Figure 2, this level is represented by the nesting of
qosPolicyDomain classes.
Each qosPolicyDomain instance serves as a container that contains an
ordered list of related QoS policy rules that apply to a different part
or function of the domain (e.g., Eastern Sales vs. Western Sales). This
grouping is done using instances of the qosNamedPolicyContainer clas.
The qosNamedPolicyContainer class would in turn contain either a set of
policyRule instances, a set of policyGroup instances (to provide
further grouping of policy rules that are scoped by a given
qosNamedPolicyContainer), or both.
+-------------+
|policyGroup | <------------------- QoS policies for an enterprise
+-------------+
|
| +---------------+
-->|qosPolicyDomain| <----------- QoS policies for the Sales group
+---------------+
|
| +---------------+
|-->|qosPolicyDomain| <-------- QoS policies for Western Sales
| +---------------+
| |
| | +-----------------------+
| |-->|qosNamedPolicyContainer| <--Qos Policies for group
| | +-----------------------+ A within Western Region
| |
| | +-----------------------+
| -->|qosNamedPolicyContainer| <--Qos Policies for group
| +-----------------------+ B within Western Region
|
| +---------------+
-->|qosPolicyDomain| <--------QoS policies for Eastern Sales
+---------------+
|
| +-----------------------+
|-->|qosNamedPolicyContainer| <--Qos Policies for group
| +-----------------------+ C within Eastern Region
|
| +-----------------------+
-->|qosNamedPolicyContainer| <--Qos Policies for group
+-----------------------+ D within Eastern Region
Figure 2: Top-level policy data tree example
Snir, Ramberg, Strassner, Cohen expires October 2000 14
Draft-ietf-policy-qos-info-model-01.txt April 2000
The modeling approach used in the previous example is but one possible
strategy among many. The information model allows for arbitrary nesting
of groups, thus providing the means for modeling both wide and deep
hierarchies.
3.2.2. Resource Sharing
Object instances residing in different parts of the containment tree
are independent to each other. That is, there is no cross-referencing
among objects located in different QoS policy domains. However,
multiple QoS policy domains may still share data by means of
referencing reusable objects. These are objects that are placed in a
special portion of the repository dedicated to this purpose. In fact,
there may be multiple such repositories, each used for collecting a set
of related reusable objects. In this document, we will call such
repositories reusable-objects repositories.
The sharing of global or common objects enhances the interoperability
of various policy agents, thus serving the primary goal of this
information model. Such commonly used building blocks as important
conditions (policyCondition and its subclasses ) and actions
(policyAction and its subclasses) can be placed in the reusable-object
repository and used by multiple policy rules from multiple domains.
Both the [PCIM] and the QPIM do not restrict the number of reusable-
object repositories that can be referenced from a single domain. Even a
single instance of a policy rule may contain references to objects
residing in more than one repository. It is important to note that the
QPIM does not dictate a QoS domain-wide scope for reusable objects, so
as to keep this concept as general as possible.
3.2.3. Placement
The purpose of the QPIM is to define a flexible structure of
information that does not pre-impose harsh restrictions on building the
data tree. Therefore, the QPIM must not contain any hidden assumptions
about the placement of particular QoS policy domain hierarchies
(including, for that matter, placement of reusable-object repositories
as explained in section 3.3 below). Consequently, the QPIM does not
require any pre-defined locations for the portion of the data tree that
is dedicated to policy. An instance of the global data tree (a
corporate directory, for example) may in fact contain several QoS
policy domains that exist within the global date tree in various
places. Zero or more reusable object-repositories may also be present
in the global data tree.
In addition, the QPIM does not dictate any standard organization of
objects to be controlled via policy, either for QoS policy classes and
relationships or for reusable-object repositories that are used by QoS
applications.
Snir, Ramberg, Strassner, Cohen expires October 2000 15
Draft-ietf-policy-qos-info-model-01.txt April 2000
The only location/organizational rule that must be followed is:
Each QoS policy domain must contain complete policy information,
either by containment of objects or by containment of association
and/or aggregation objects, that is necessary to describe that
policy domain. Reusable objects SHOULD be placed in one or more
reusable-object repositories and referenced by one or more objects
that exist in the QoS policy domain, as appropriate.
3.2.4. Named Policy Containers
A QoS policy domain is a container of (named) QoS Policy Containers, as
explained above. The information model class representing named QoS
policy containers is the qosNamedPolicyContainer class. This class
extends the policyGroup class, which is defined in [PCIM].
A (non-empty) qosNamedPolicyContainer holds an unordered list of
policyRules. There are two levels of priority that the QPIM specifies
that can be used to determine the order of execution of QoS policy
rules. At the highest level, we can define an unordered set of policy
containers, each of which has a priority attribute (called qpPriority).
This property is used to order the top level of the containment
hierarchy. Within a given containment level, we can then use the
Priority attribute of the policyRule class to establish an order of
which policy rule in a given container executes next. Figure 3 shows a
simple example of the ordering process. Section 4 describes policy
rules in more detail.
+---------------+
|qosPolicyDomain|
+---------------+
|
| +--------------+
|-->|policyRule A |
| | Priority=19 |
| +--------------+
|
| +-----------------------+ +-------------+
|-->|qosNamedPolicyContainer|--->|policyRule C |
| | qpPriority=5 | | | Priority=7 |
| +-----------------------+ | +-------------+
| |
| +-------------+ | +-------------+
-->|policyRule B | ->|policyRule D |
| Priority=3 | | Priority=2 |
+-------------+ +-------------+
Figure 3. Example Ordering for a QoS Policy Decision
Here, the ordering is A, then C, then D, then B. This is because the
qpPriority of the qosNamedPolicyContainer is higher than B, so each of
its contained rules are executed (in order) before B.
Snir, Ramberg, Strassner, Cohen expires October 2000 16
Draft-ietf-policy-qos-info-model-01.txt April 2000
As implied by the class name, each instance of the
qosPolicyNamedContainer class MUST be assigned a name that is unique
within its given QoS policy domain. A given policy container must
belong to (i.e.: contained in) a single QoS policy domain. Sharing of
policy containers among QoS policy domains is not possible because of
the dependency of the decision strategy on the relative priority within
each QoS policy domain.
The ability to "divide" a given QoS policy domain's policy rules among
a set of policy containers provides a flexible framework to realize a
fine-grained administrative (or functional) structure. As the example
in figure 2 illustrates, it makes sense to divide policies for the
sales organization into two regional containers: Western and Eastern.
This enables a change in policies for one region to not affect the
policies currently in place for the other region.
While this strategy should meet most needs, taking a slightly different
approach can provide additional flexibility. This approach is
illustrated by looking at how PHBs are modeled (see section 6). In this
approach, a different set of PHBs can be assigned to different policy
containers. This has the effect of modifying the interpretation of the
same PHBs by each policy container.
Each policy container is assigned a "match strategy". This is defined
in the qpNamedPolicyRuleMatchMethod attribute of the
qosPolicyNamedContainer class. This attribute defines how to interpret
the order of the QoS policy rules that it contains. For example, a
FirstMatch strategy means that the rules will be "matched" according to
ascending order of their Priority attribute. Decision strategies are
explained in section 5.
Policy container can be nested. A policy container may contain policy
rules (PolicyRule [PCIM]) or named policy containers. A particular
data tree, then, can be constructed as a deep hierarchy, if the
designers of the policy system deem it desirable.
3.2.5. Policy Rules
Each qosNamedPolicyContainer holds a set of policy rules (or possibly
additional policy containers, which could be policyGroups or
qosNamedPolicyContainers, that contain policy rules). QoS policy rules
are modeled by the [PCIM] class policyRule.
The semantics of a policy rule is, in essence, a conditional imperative
statement in the form 'if <condition> then <action>'. Applying a rule
means evaluating its condition and, depending on the truth value of
the condition, to execute the action or do nothing. Evaluating a
condition is known as 'matching the rule', an expression we'll be using
in later sections of this document.
Snir, Ramberg, Strassner, Cohen expires October 2000 17
Draft-ietf-policy-qos-info-model-01.txt April 2000
A given policy rule MUST belong to one (and only one)
qosNamedPolicyContainer. This restriction is necessary because the
units of reusability are, in reality, the policy condition and action
terms that comprise a policy rule (as opposed to the policy rule
itself). This is because a policy rule is a composite object, made up
of several objects, but SHOULD be viewed as a coherent statement. It is
believed that allowing a policy rule to belong to more than one policy
container would decrease or even destroy its coherence. For example,
the rule itself is "aware" of its position inside its policy container,
so if we wanted to share a rule among many containers we'd have to
remove this knowledge from the rule. The notion of ordering of rules is
so essential to the concept of policy that removing it from the rule
also renders the rule less expressive, making policy modeling a more
difficult job. Furthermore, there are other important attributes that
are unique to the rule's specific placement inside a policy group
and/or a policy domain. For example, the DSCP values (section 6) that
define how a flow is colored (which in turn define the set of QoS
policy actions that should be invoked by the rule) may be interpreted
differently in different QoS policy domains (or policy containers).
These examples show that the modeling of shared rules is inappropriate
for the QPIM.
The order of the policy rules inside a container is based on the
relative values of the Priority attribute of each of the policyRules
(please see [PCIM] for more information). The enforcement of policy
rules also depends on particular settings belonging to the group. The
match strategy to be applied to the policy rules contained in a given
container is defined in the policyRuleMatchMethod attribute of the
qosNamedPolicyContainer object. Note that actions taken on packets may
use a different mechanism. For example, a DSCP value can be set
directly using the qpSetDSCPValue attribute of the qosPolicyPRAction
class. However, this class could also define a set of token bucket
parameters using the qpTrfcProf attribute. This references a traffic
profile (represented by the qosPolicyPRTrfcProf class) that carries the
policer or shaper rate values to be enforced on a flow or a set of
flows.
3.2.6. Conditions and Actions
A policy rule is a composite object, as mentioned above. The most
important components of a rule are the conditions and actions it
contains. A condition is a Boolean expression that is evaluated to see
if the rule should be applied. An action is a specification of one or
more QoS operations enforced on the designated set of flows that MUST
be done if the given policy rule is to be applied. Actions are applied
if the condition is TRUE (see [PCIM] for more details).
Snir, Ramberg, Strassner, Cohen expires October 2000 18
Draft-ietf-policy-qos-info-model-01.txt April 2000
3.2.7. Data Tree Example
The following example illustrates the hierarchical nature of the QoS
Policy data tree. Each organizational entity is related to a specific
type of class, which is shown in parentheses.
There are two QoS policy domains in this example, grouped together
under the same root (domain grouping). The QoS policy domains are:
1. EastCoast (qosPolicyDomain)
2. WestCost (qosPolicyDomain)
Each of these two QoS policy domains has its own PHB set. The EastCoast
domain has 2 named policy containers. The first deals only with ERP
traffic and the second handles all other traffic:
1. EastCoast (qosPolicyDomain)
1.1. ERP (qosNamedPolicyContainer)
1.2. General (qosNamedPolicyContainer)
The WestCoast domain has 3 named policy container. The first deals only
With ERP flows, the second deals with VoIP, and the third with all
other traffic:
2. WestCoast
2.1. ERP (qosNamedPolicyContainer)
2.2. VoIP (qosNamedPolicyContainer)
2.3. General (qosNamedPolicyContainer).
Each one of the qosNamedPolicyContainer entries can contain a
prioritized rule set. For example, the WestCoast ERP group contains the
rules relevant to ERP applications administrated by the west coast
domain administrator.
We see from the above structure that this structure provides the
administrator with a great deal of flexibility. For example, similarly
named containers, represented by the ERP and General
qosNamedPolicyContainers, can reuse common policy conditions and
actions. However, they are implemented as physically different
containers to enable the administrator to administrate them
according to their own domain-specific needs.
3.3. Reusable-Object Repositories
Reusable objects are objects that can be referred by (hence "used by")
other objects. For example, the reference could be accomplished by
allocating an attribute on the referencing object that contains the
location of the referenced object.
Snir, Ramberg, Strassner, Cohen expires October 2000 19
Draft-ietf-policy-qos-info-model-01.txt April 2000
The concept of reusable-object repositories is introduced by [PCIM] for
the purpose of allowing data tree constructors to share data among many
users. This document enhances this concept to model the needs of QoS
policy rules.
A reusable-object repository hierarchy is rooted in an instance of the
policyRepository class (defined in [PCIM]). Individual reusable-object
repositories are named containers for reusable objects. Note that
[PCIM] allows arbitrary nesting of reusable-object repositories. This
can be conceptually thought of as a repository of repositories.
Each named reusable-object repository is a container of "reusable
objects" that can be used for a common purpose, and/or are administered
in a common way. A reusable object MUST have a unique name within the
the container that it resides in.
The complete containment model for the reusable-object repositories,
as well as detailed description of the various mechanisms for
constructing and maintaining such repositories, is described in detail
in [PCIM].
Anywhere in the QoS Policy information model, where a reference to an
object can be made (a 'reference' type attribute), this reference
SHOULD point to a reusable object in a reusable-object repository.
Common candidates for reusability are named instances of these classes
and their derivatives:
- qosPolicyVariable
- qosPolicyValue
- qosPolicySimpleCondition
- policyAction
- qosPolicyMeter, QoSPolicyPRTrfcProf and QoSPolicyRSVPTrfcProf
- QoSPolicyPHBSet
Throughout this document, we point out the possible use of repository
and repository objects, wherever this is appropriate.
3.4. Relationships Between QoS Domains and Repositories
As explained above, a QoS policy domain contains within it groups of
policy rules. A policy rule can contain ordered lists of conditions and
actions. The conditions and actions may be reusable object that reside
in reusable objects repositories.
Many references to reusable objects may be made from the rules of a
given QoS policy domain. Those references need not be all pointing to
the same reusable-object repository; even e single rule may contain
references to reusable objects that reside in different repositories.
Snir, Ramberg, Strassner, Cohen expires October 2000 20
Draft-ietf-policy-qos-info-model-01.txt April 2000
The maintenance of the policy system is made somewhat more complicated
due to the flexibility of the reference model. For example, it is more
difficult to prevent "dangling" references to repositories that are no
longer present. Schema designers are encouraged to pay extra attention
to this problem and exercise any technique available from their
implementation platform to maintain integrity of their data trees.
[PCIM] discusses this issue as well.
4. Constructing a QoS Policy Rule
A policy rule modeled in [PCIM] represents the "If Condition then
Action" semantics associated with a policy. The QPIM extends these
semantics by refining the type of policy conditions and actions that
can be represented, extending the use of containers, and providing
additional features (nesting of rules, defining extensible rule
decision strategies, linking to PHBs, and providing pre-defined
variables and constants that can be used to express the required
semantics of QoS policy rules in more detail.
The following sections describe these characteristics in more detail.
4.1 Policy Rule Structure
A policy rule has the following attributes (defined in [PCIM]) that can
be used to provide important semantics for QoS policy applications;
these are in addition to the attributes which serve as a key and
provide its name:
1. An Enable flag that indicates whether a policy rule is
administratively enabled, administratively disabled, or enabled
for debug mode.
2. A set of conditions (defined in either the
PolicyConditionInPolicyRule or PolicyConditionInPolicyRepository
aggregation)
3. A flag indicating whether this condition is in disjunctive or
conjunctive normal form
4. An (optionally ordered) list of actions (defined in either the
PolicyActionInPolicyRule or PolicyActionInPolicyRepository
Aggregation)
5. A priority value, defining the priority of this rule relative to
other rules in the same container
6. The attribute named ômandatoryö, which is used to define whether
the evaluation of conditions (and the subsequent execution of
actions if the conditions evaluate to TRUE) is mandatory or not
7. A SequencedActions attribute that defines how to execute the
actions if the condition is TRUE
8. An array of PolicyRoles attributes, that define the roles or
role-combinations that are used in this rule
9. A RuleUsage attribute, that contains a description of how this
rule should be used
Snir, Ramberg, Strassner, Cohen expires October 2000 21
Draft-ietf-policy-qos-info-model-01.txt April 2000
The Boolean condition is used to evaluate if the set of actions should
be performed on a network flow by matching the network flow attributes
against the condition. QoS-specific conditions SHOULD be formed from
using either the qosPolicySimpleCondition class defined in this
document and/or the policyTimePeriodCondition class defined in [PCIM]
(or their subclasses, of course). Note that QoS-specific conditions MAY
be mixed with more generic conditions that are not derived from either
of these classes. However, these non-QoS-specific conditions SHOULD be
derived from the policyCondition class (defined in [PCIM]). The
combination of individual conditions in a policy rule is defined in
[PCIM] using the ConditionInPolicyRule class.
Each action in the list is modeled by an action derived from the
PolicyAction class. The ActionInPolicyRule class defines the order in
which policy actions are performed.
The interpretation of a policy rule in regard to a given network flow
may be expressed as follows:
If the rule is enabled and the Boolean expression is evaluated to
TRUE, then use the Action list to extract the prescribed treatment
for this flow.
The rest of this section describes the components of the policyRule
class and their relationships to the other classes defined in this
schema.
4.2 QoS Policy Conditions
A policy rule modeled in [PCIM] represents the "If Condition then
Action" semantics associated with a policy. A condition is represented
as either an ORed set of ANDed conditions or an ANDed set of ORed
conditions. Individual conditions may either be negated (NOT C) or
not negated (C). The actions specified by a policy rule are to be
performed if and only if the policy rule condition evaluates to TRUE.
Many conditions in policy rules, from a networking perspective, can be
modeled as Filters. Filters are not modeled directly in either the QPIM
or the PCIM (i.e., no Filter class is defined). However, the filter
concept is central in the QoS Policy data model, and is modeled in the
Network Model of DEN and used in the companion QoS Device information
model draft [QOSDEV].
The semantics of an individual condition is not specified in [PCIM].
This document provides semantics for common QoS policy conditions. For
example, conditions such as: "If the source IP address of the flow
belongs to 10.1.x.x subnet" as well as "If the IP protocol number of
the flow equals the TCP protocol number" are modeled in this document.
Snir, Ramberg, Strassner, Cohen expires October 2000 22
Draft-ietf-policy-qos-info-model-01.txt April 2000
The qosPolicySimpleCondition class models individual conditions. This
class refines the basic structure of the policyCondition class defined
in [PCIM] by using the triplet <variable>, <operator> and <value> to
form a condition.
The variable specifies the attribute of a flow that should be matched
when evaluating the condition. A set of predefined variables that cover
the basic network attribute are introduced to foster interoperability.
The list cover layer 3 IP attribute such as IP network addresses,
protocols and ports, as well as a set of layer 2 attributes and higher
level attributes such as application and user identity.
The variable is matched against a value to produce the Boolean result.
In the first example above, a source IP address variable is matched
against a 10.1.x.x subnet value. The operator specifies the type of
relation between the variable and the value evaluated in the condition.
Operators should model the 'belong to' and 'equal' relations in the
examples above. In many cases, a generic 'match' operator can be used,
and the interpretation of the relation between the variable and value
is implied by the value itself. For example, the variable source IP
address can be matched to an IP address, where the 'equal' relation is
implied, to a hostname in which the 'resolve to' relation is implied,
or to a subnet address in which 'belongs to' relation is implied.
4.2.1 Reusable vs. Ad-Hoc Conditions
This schema enables the reuse of simple conditions by placing them in a
common portion of the policy information tree (called the reusable-
object repository). In order for a simple condition to be a member of
this repository, it must carry a unique name.
A qosPolicySimpleCondition can either directly contain a value and a
variable, or can reference either one or both of them if they are kept
in a reusable-object repository.
Simple condition composition must enforce the following type
conformance rule: The qpValueTypes property of the variable must be
compatible with the value class name.
The QPIM defines four different ways to compose a simple condition
through the combination of representations of variables and values. The
following combinations of representing a simple condition by references
and containment are possible:
Variable representation
1. The class qosPolicyVariable may be contained in the
qosPolicySimpleCondition instance.
2. The class qosPolicyVariable may be referenced from the
qosPolicySimpleCondition instance (Reusable variable)
Snir, Ramberg, Strassner, Cohen expires October 2000 23
Draft-ietf-policy-qos-info-model-01.txt April 2000
Value representation
1. The qosPolicyValue class may be contained in the
qosPolicySimpleCondition class.
2. The qosPolicyValue class may be referenced from the
qosPolicySimpleCondition instance. This allows reusing the
qosPolicyValue object, which could be named and considered a named
constant.
4.2.2. Using Simple Conditions
In most cases, the use of the qosPolicySimpleCondition class is
sufficient for the definition of a condition for a policyRule. A simple
condition can be added to a policyRule in two ways:
1. A direct attachment of an instance of the condition to the
ConditionInPolicyRule instance. In this case, we call this an
"ad-hoc" simple condition. This method allows the creation of a
"private" simple condition, meaning that this instance of the
condition can't be referenced by any other policy rule, and
therefore is not reusable. However, since it embeds the condition
directly in the ConditionInPolicyRule instance, it eliminates the
extra access(es) required to fetch each of the condition elements
that are refernced by pointers.
2. An indirect reference to an instance of a condition that resides in
a reusable-object repository. This is called a reusable condition.
This method allows the sharing of conditions by multiple policy
rules.
4.2.3. Composing Complex Conditions
A complex condition consists of groups of simple conditions (i.e.,
instances of either the policyCondition and/or the
qosPolicySimpleCondition classes) that are combined in either
conjunctive or disjunctive normal form (as defined in [PCIM]).
A complex condition is modeled by the mechanisms supplied in the
following PCIM attributes:
1. The ConditionListType attribute of the policyRule, which
is a boolean expression type that defines whether the simple
condition is in conjunctive or disjunctive normal form.
2. The PolicyConditionInPolicyRule aggregation class that does three
things: associates conditions to a particular policy rule, defines
whether the condition is negated or not, and partitions the
referenced conditions into one or more groups. For more details,
please see [PCIM], section 6.3.
Snir, Ramberg, Strassner, Cohen expires October 2000 24
Draft-ietf-policy-qos-info-model-01.txt April 2000
4.3 Simple Condition Operator
The QoS policy simple condition includes the qpOperator property,
Which specifies the type of relation between the variable and the value
evaluated in the condition. In many cases, a generic 'match' operator
can be used, and the interpretation of the relation between the
variable and value is implied by the value itself. For example, the
variable source IP address can be matched to an IP address, where the
'equal' relation is implied, to a hostname in which the 'resolve to'
relation is implied, or to a subnet address in which 'belongs to'
relation is implied.
The QPIM defines a single operator, "match", that models the most
generic relation: that of being equal or belonging to.
4.4 QoS Policy Variables
QoS Policy Variables are used for building individual conditions, as
defined in section 4.2. The variable specifies the attribute of a flow
that should be matched when evaluating the condition.
Not every combination of a variable and a value creates a meaningful
condition. For example, a source IP address variable can not be matched
against a value that specifies a port number. The QPIM defines a set of
variables that can be used to model common QoS policy conditions, and
assigns appropriate semantics for each. Each type of variable
inherently selects the set of value types that it can be matched
against (i.e. a value that could be compared and evaluated to a Boolean
expression).
A variable may also limit, or constrain, the set of values within a
particular value type that can be matched against it in a condition.
This may be viewed as a second level of integrity checking. For
example, a variable representing the source-port must limit the set of
values that it can assume to the valid range of integers that
correspond to legal source-port values (which is 0-65535). Integers
outside this range can not be matched to this variable. Thus, it is not
enough to say that the data type of the source-port variable is an
integer û we also need to ensure that the value to be tested is within
a valid range of integers.
The QPIM defines three important attributes that characterize each of
the variables that it defines:
1. The property qpVariableName of the QosPolicyVariable class defines
the well-known name used for logical binding of all variables that
are defined in this document.
2. The qpValueTypes is the list of value classes that could be
matched to this variable.
3. The qpValueConstraints defines a list of constraint on the
variable (i.e., values that the Variable must match).
Snir, Ramberg, Strassner, Cohen expires October 2000 25
Draft-ietf-policy-qos-info-model-01.txt April 2000
The combination of these three attributes provide a consistent and
extensible set of meta-data that define the semantics of variables that
are used to form QoS conditions. For example:
- The qpVariableName can be used to identify common processing rules
for a variable having a specific name.
- The qpValueTypes attribute can be used to ensure that only proper
classes are used as operators. For example, the source-port
variable will not include the QosPolicyIPv4AddrValue class, since
source ports have different semantics than IP addresses. However,
it will include the QosPolicyIntegerValue class name.
û The qpValueConstraints attribute ensures that variable-specific
semantics are enforced (e.g., the source-port variable may include
a constraint reference to a value object defining the integer range
0..63535).
4.4.1. Variable Binding
For the QoS Policy schema to be interoperable, different policy
management systems and policy servers must instantiate the same
variables with identical values (in the same evaluation operation).
While different policy servers may use a different binding mechanism,
the binding logic must result in an identical instantiation.
Each variable defined in the QoS policy repository must be bound to a
logical entity such as a specific field in the IP header, application
unique identifier or an application-specific parameter.
When a policy server attempts to evaluate an expression containing
variables, it must instantiate the variables. To instantiate a
variable, that variable must be bound to a specific value (or values,
depending on its type category) and associated with a logical entity.
For example, in the expression 'source-port == 80', the variable
'source-port' must be instantiated to a value and logically associated
with the packet header field containing the source port number, for the
expression to be evaluated.
If, in this example, the variable source-port is bound to a value of
'80', then the expression is evaluated to TRUE for each packet that the
source port number in the IP header field equals 80. Otherwise it is
evaluated to FALSE.
4.4.2. Pre-Defined Variables
The purpose of this section is to explain the need and define the
relationship of standard, frequently used variables with their logical
entities. Pre-defined variables are necessary for ensuring
interoperability among policy servers and policy management tools from
different vendors.
Snir, Ramberg, Strassner, Cohen expires October 2000 26
Draft-ietf-policy-qos-info-model-01.txt April 2000
For example, different policy servers may have to evaluate the same
policy rule. If each policy server uses a common set of variables, this
helps to abstract the condition term such that its evaluation can be
performed in the same way.
The QoS Policy information model specifies a set of pre-defined
variables to support a set of fundamental QoS terms that are commonly
used to form conditions. Examples of these include IP header field
values, user information, applications, and others. A pre-defined
variable MUST always have the same name and binding semantics. For
example, a given pre-defined variable should be bound to the same
logical entity by all client systems (typically policy devices).
Similarly, the pre-defined variable should be stored in the reusable-
object repository to enable reuse and sharing of the pre-defined
variable.
All standard variable names are case insensitive and do not include
spaces or other non-standard characters to promote ease of use.
The implementers of client systems that map the QPIM to a specific
repository-based implementation MUST provide binding methods to bind
pre-defined variables according to the semantics specified in this
section.
Following is a table that defines the predefined variable names and
their binding. The table indicates which fields are checked in actual
filters used in provisioning policies as well as in RSVP signaling
messages.
+-----------------+---------------------------------------------------+
|Variable name | Logical binding |
+-----------------+---------------------------------------------------+
| SourceIP | The source IP address of the flow. Compared to the|
| | source IP header field, or the sender address in |
| | the RSVP Filter spec object [RSVP]. |
+-----------------+---------------------------------------------------+
| SourcePort | The source Port of a UDP/TCP flow. Compared to the|
| | source port field in the TCP/UDP header, or the |
| | sender port in the RSVP Filter spec object [RSVP].|
+-----------------+---------------------------------------------------+
| DestinationIP | The destination IP address of the flow. Compared |
| | to the destination IP header field, or the session|
| | address in the RSVP SESSION object [RSVP]. |
+-----------------+---------------------------------------------------+
| DestinationPort | The destination Port of a UDP/TCP flow. Compared |
| | to the destination port field in the TCP/UDP |
| | header, or the session port in the RSVP SESSION |
| | object [RSVP]. |
+-----------------+---------------------------------------------------+
(Table continued in next page)
Snir, Ramberg, Strassner, Cohen expires October 2000 27
Draft-ietf-policy-qos-info-model-01.txt April 2000
(Table continued from the previous page)
+-----------------+---------------------------------------------------+
|Variable name | Logical binding |
+-----------------+---------------------------------------------------+
| IPProtocol | The IP protocol number. Compared to the protocol |
| | number in the IP header field or to the IP |
| | protocol in the RSVP SESSION object [RSVP]. |
+-----------------+---------------------------------------------------+
| ToS | The ToS variable is bound to the IP header ToS |
| | byte. |
+-----------------+---------------------------------------------------+
| DSCP | The DSCP variable is bound to the IP header DSCP |
| | byte or to DCLASS RSVP object. |
+-----------------+---------------------------------------------------+
| DestinationMAC | The destination MAC address variable is bound the |
| | frame destination MAC address. |
+-----------------+---------------------------------------------------+
| SourceMAC | The source MAC address variable is bound the frame|
| | source MAC address. |
+-----------------+---------------------------------------------------+
| 8021QID | The VLAN ID as represented in the 802.1Q field of |
| | the header. |
+-----------------+---------------------------------------------------+
| Snap | The snap protocol variable is bound to protocol |
| | type carried over SNAP encapsulation. |
+-----------------+---------------------------------------------------+
| Ethertype | The ethertype variable is bound to the frame |
| | header ethertype value. |
+-----------------+---------------------------------------------------+
| Ssap | The source sap variable is bound the frame header |
| | field containing the source SAP. |
+-----------------+---------------------------------------------------+
| Dsap | The destination sap variable is bound the frame |
| | header field containing the destination SAP. |
+-----------------+---------------------------------------------------+
| Application | The ID of the application that generated the flow.|
+-----------------+---------------------------------------------------+
| User | The ID of the user that initiated the flow, or is |
| | designated as the flow owner. |
+-----------------+---------------------------------------------------+
Table 2. Pre-defined Variable Names and Their Bindings
The definition of each predefined variable includes a standard name and
the allowed value types, i.e. the variable's qpValueTypes property.
Following is a table of variable names and their allowed class types.
Snir, Ramberg, Strassner, Cohen expires October 2000 28
Draft-ietf-policy-qos-info-model-01.txt April 2000
+-----------------+---------------------------------------------------+
|Variable name | Allowed class types |
+-----------------+---------------------------------------------------+
| SourceIP | qosPolicyIPv4AddrValue, qosPolicyIPv6AddrValue |
+-----------------+---------------------------------------------------+
| SourcePort | qosPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| DestinationIP | qosPolicyIPv4AddrValue, qosPolicyIPv6AddrValue |
+-----------------+---------------------------------------------------+
| DestinationPort | qosPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| IPProtocol | qosPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| ToS | qosPolicyIntegerValue, qosPolicyBitStringValue |
+-----------------+---------------------------------------------------+
| DSCP | qosPolicyIntegerValue, qosPolicyBitStringValue |
+-----------------+---------------------------------------------------+
| DestinationMAC | qosPolicyMACAddrValue |
+-----------------+---------------------------------------------------+
| SourceMAC | qosPolicyMACAddrValue |
+-----------------+---------------------------------------------------+
| 8021QID | qosPolicyIntegerValue, qosPolicyBitStringValue |
+-----------------+---------------------------------------------------+
| Snap | qosPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| Ethertype | qosPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| Ssap | qosPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| Dsap | qosPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| Application | qosPolicyDNValue, qosPolicyStringValue, |
| | qosPolicyAttributeValue |
+-----------------+---------------------------------------------------+
| User | qosPolicyDNValue, qosPolicyStringValue, |
| | qosPolicyAttributeValue |
+-----------------+---------------------------------------------------+
Table 3. Allowed Variable Names and Their Default Class Types
Note: For Value type definition, check the QoS Policy Value section.
Snir, Ramberg, Strassner, Cohen expires October 2000 29
Draft-ietf-policy-qos-info-model-01.txt April 2000
4.5 QoS Policy Value
This abstract class qosPolicyValue is used for defining values and
constants used in policy conditions. Different value types are derived
from this class and represent the various attributes required.
Extensions of the qosPolicValue class, defined in this document
provide a list of values for representing the basic network attribute.
Values can be used to represent constants as named values. Named values
could be kept in a repository to be reused by multiple conditions.
Examples of constants include well-known ports, well-known protocol,
server addresses, and other similar concepts.
The QoS Policy value classes define 3 types of basic values: scalars,
ranges and sets. For example, a well-known port number could be defined
using the qosPolicyIntegerValue, defining a single value (80 for HTTP)
a range (80-88) or a set (80, 82, 8080). For details, please see the
class definition for each value type.
The QoS policy information model provide the following classes, all of
them extending the QoSPolicyvalue:
General:
qosPolicyStringValue
qosPolicyIntegerValue,
qosPolicyBitStringValue,
qosPolicyDNValue,
qosPolicyAttributeValue.
Layer 3 Network values:
qosPolicyIPv4AddrValue,
qosPolicyIPv6AddrValue.
Layer 2 Network values:
qosPolicyMACAddrValue.
For details, please see the class definition section of each value.
4.6. PolicyTimePeriodCondition
The QoS Policy Information model uses the policyTimePeriodCondition
class (defined in [PCIM]) to define time based QoS policy rules. For
details, please see [PCIM], section 6.5.
4.7. Actions
The QoS Policy schema defines actions to control QoS enforcement in
both the Integrated-Service model as well as the Differential service
model. Two types of actions are provided: Signaling and Provisioning
actions.
Snir, Ramberg, Strassner, Cohen expires October 2000 30
Draft-ietf-policy-qos-info-model-01.txt April 2000
Signaling actions are used to provide policy control on RSVP
requests. Provisioning actions are used to directly control the data
traffic, regardless of any out-of-band signaling.
A policy rule may aggregate zero or more policy actions. A QoS policy
rule extends this definition to include 0..n provisioning actions and
0..m signaling actions, each defined by an object or objects describing
the action(s) to perform. Actions are ordered (as opposed to rules,
which are prioritized). The order of actions is specified in [PCIM].
The property SequencedActions in the aggregating instance of defines
whether a specified action order is required, recommended, or of no
significance.
Ordering semantics depend on how actions are represented. If actions
are represented as separate objects, the PolicyActionInPolicyRule
aggregation can be used to express an order. In this case, three
attributes are used:
- ContainingRule, which contains a reference to a policyRule that
contains one or more policyActions
- ContainedAction, which contains an object reference to a
policyAction contained by one or more policyRules
- ActionOrder, which is an unsigned integer 'n' that indicates the
relative position of an action in the sequence of actions that are
associated with a given policy rule. When 'n' is a positive
integer, it indicates a place in the sequence of actions to be
performed, with smaller integers indicating earlier positions in
the sequence. The special value '0' indicates "don't care". If
two or more actions have the same non-zero sequence number, they
may be performed in any order, but they must all be performed at
the appropriate place in the overall action sequence.
For actions defined explicitly in a subclass of policyRule, the
ordering mechanism must be specified in the subclass definition. Note
that QPIM does not define any policyRule subclasses. Instead, the QPIM
defines subclasses of policyCondition and policyAction to extend the
semantics of these classes.
Provisioning and signaling actions can be intermixed in a QoS policy
rule. Policy consumers (such as PDPs) MAY separate the actions into
separate lists, but MUST respect the internal order of the specified
actions.
4.7.1 Provisioning Actions
QoS Policy provisioning actions model traffic conditioner elements, as
specified in [DIFF-SERV-ARCH]. Actions model meters, markers, shapers
and droppers.
Snir, Ramberg, Strassner, Cohen expires October 2000 31
Draft-ietf-policy-qos-info-model-01.txt April 2000
4.7.1.1 Meters
Meters measure the temporal properties of the stream of packets
selected by a classifier against a traffic profile. Meters are modeled
by the QosPolicyMeter class. A meter can be shared between different
policy rules. If this is desired, then the meter SHOULD reside in a
reusable-object repository. This enables it to be referenced by all
policy rules that want to share it.
The property qpMeter is used to hold a reference to a (reusable) meter
that is kept in a reusable-object repository. The qpMeterScope property
specifies whether the meter should measure flows matching the rule
condition per interface, per device or per flow. A per flow meter
conceptually creates a new meter for each flow, measuring each flow
against the profile. A per interface meter measures the aggregate set
of flows matching the rule condition forwarded via a single interface.
Meters are measured against traffic profile modeled by the
qosPolicyPRTrfcProf object. The property qpTrfcProf holds a reference
to a traffic profile that resides in a reusable-object repository.
4.7.1.2 Markers
Markers are used to set the DS field of a packet to a particular DS
codepoint (DSCP), adding the marked packet to a particular DS behavior
aggregate. The marker may be configured to mark all packets steered to
it to a single DSCP, or may be configured to mark a packet to one of a
set of DSCPs used to select a PHB in a PHB group, according to the
state of a meter. When the marker changes the DSCP in a packet, it is
said to have "re-marked" the packet.
Marking is modeled by the property qpSetDSCPValue, which specifies the
DSCP to set. Remarking out-of-profile packets is modeled by the
qpOutofProfileRemarkValue property. The property qpOutOfProfileAction
should be set to 'remark' when the remark DSCP value is used.
4.7.1.3 Shapers
Shapers are used to delay some or all of the packets in a traffic
stream in order to bring the stream into compliance with a traffic
profile. A shaper usually has a finite-sized buffer, and packets may
be discarded if there is not sufficient buffer space to hold the
delayed packets.
If the value of the property qpOutOfProfileAction is set to 'shape',
then this specifies that packets measured by a meter should be shaped
according to the traffic profile specified by a qosPolicyPRTrfcProf
object.
Snir, Ramberg, Strassner, Cohen expires October 2000 32
Draft-ietf-policy-qos-info-model-01.txt April 2000
4.7.1.4. Droppers
Droppers are used to discard some or all of the packets in a traffic
stream in order to bring the stream into compliance with a traffic
profile. This process is also known as "policing" the stream.
If the value of the property qpOutOfProfileAction is set to 'drop',
then it specifies that packets measured by a meter should be policed
according to the traffic-profile specified by a qosPolicyPRTrfcProf
object.
4.7.1.5 Examples
The following examples will help to show how these classes can be used
to perform general provisioning actions.
Example 1: Set up a rule enforcing QoS provisioning actions:
LetÆs define a policy rule, P, as follows:
If (<condition>) THEN, on outgoing traffic,
mark with <DS Value> AND
activate a per-flow policer <FLOWP> AND
activate a per policy rule policer <CLASSP>
Rule P is represented using 3 qosPolicyPRAction objects:
Object 1:
qpDirection: OUT
qpSetDSCPValue: <DS Value>
Object 2:
qpDirection: OUT
qpMeterScope: flow
qpTrfcProf: <FLOWP> (this is a repository-specific reference to a
per-flow policer object)
qpOutOfProfileAction: discard
Object 3:
qpDirection: OUT
qpMeterScope: Interface
qpTrfcProf: <CLASSP> (this is a repository-specific reference to a
per-policyRule policer object)
qpOutOfProfileAction: discard
qpMeter: <Meter>
Snir, Ramberg, Strassner, Cohen expires October 2000 33
Draft-ietf-policy-qos-info-model-01.txt April 2000
Example 2: Conditioning traffic
Some PHBs require the successive application of a set of traffic
conditioners to properly process the traffic. An example of a policy
with two levels of traffic conditioning is the following:
Mark packets to DSCP=24 if the rate is within profile x=<64Kb/s>,
else mark packets with DSCP=25 if rate is within profile y=<128kb/s>,
else drop out-of-profile packets.
This policy rule can be modeled by using two actions. The first action
measures the traffic against the first profile. If the traffic is
within this profile, then the traffic is (re)marked with a DSCP of 24.
If the traffic is out of profile, then the subsequent action measures
the traffic against the second higher profile. If the traffic is within
this profile, then the traffic is (re)marked with a DSCP of 25.
Otherwise, the traffic is out of profile, and it will be dropped.
In this way, an arbitrary cascading of traffic conditioners can be
constructed, where each action measures traffic against a higher
traffic profile and change only the out-of-profile action as required.
4.7.2 Signaling Action
RSVP is the standard protocol used for requesting QoS resources from
the network. The QoS policy signaling actions defined in this document
can be used to control whether to admit or reject an RSVP request based
on the request's attributes and the specified policy. The QoS policy
signaling actions allow modifying the content and forwarding behavior
of RSVP requests.
The signaling policies control the admission priority of resources and
provide preemption support. Mapping of integrated services signaled by
RSVP to differential services in a core network is controlled by
signaling policies as well, by assigning appropriate DSCPs to flows on
the boundary of the differential service core.
The set of policies specified allow a policy server (policy decision
point) to instruct an RSVP node (policy enforcement point) to enforce
all set of controls defined in the COPS protocol specification. The
actions defined here follow the different decision types of the COPS
protocol [COPS] and the guidelines for its use in an RSVP environment
[COPS-RSVP]. The basic decision to accept or deny a reservation is
modeled by the qosPolicyRSVPAction class. Additional control is
provided through the use of two classes. The content and forwarding
behavior of RSVP flows is defined by the qosPolicyRSVPSignalCtrlAction
class. The qosPolicyRSVPInstallAction class controls the processing of
RSVP requests and accompanying flows within the RSVP node itself.
Snir, Ramberg, Strassner, Cohen expires October 2000 34
Draft-ietf-policy-qos-info-model-01.txt April 2000
QoS signaling policies does not require a policy server for decision
making. A local policy module can use signaling policies for making
local decisions, as well as if other outsourcing policy protocol beside
COPS is used.
The qosPolicyRSVPAction action includes a specification of the subset
of RSVP flows on which the action should be taken. The following
parameters can be specified:
1. Direction - in/out
2. Message type - Path/Resv/PathErr/ResvErr
3. Service type - Guaranteed Service / Controlled Load / Null
4. Service style - SE, WF, FF
The direction refers to the direction of the flow, hence the direction
of the RSVP Path messages. Therefore, out-direction policies control
outgoing Path messages as well as incoming Resv messages.
The basic decision modeled by this class is whether to admit or reject
the RSVP request. The decision can be based on comparison of the
request TSPEC or FLOWSPEC to a traffic profile and a meter. A meter can
be used to track the temporal resources allocation of RSVP requests
matching a network condition. Such meters allow enforcement of policies
of the form: "Allow allocation of resource via RSVP for flows coming
from subnet x up to a total aggregated rate of 256kb/sec". Use of
meters and meter scope is identical to their use in provisioning
policies. The following properties are used:
1. Traffic Profile - referencing a traffic profile.
2. Meter - referencing a meter.
Both traffic profile and meter specifications can be directly included
within the action as well.
Note that if a traffic profile is not provided, it is implicitly
assumed that the RSVP request should be accepted. Rejecting all RSVP
requests matching the condition is specified by a zero valued traffic
profile.
The qosPolicyRSVPInstallAction adds the following actions:
1. Set the DSCP value
2. Set the preemption priority of the RSVP request.
Setting the DSCP of the flow on the edge of a differential service core
allow provisioning of QoS, end-to-end, over mixed integrated and
differential service clouds.
Snir, Ramberg, Strassner, Cohen expires October 2000 35
Draft-ietf-policy-qos-info-model-01.txt April 2000
An RSVP node is responsible for deciding whether to admit flows or not,
based on its available resources. Setting the preemption priority
[RSVP_PREEMP] allows the RSVP node to decide which of its reservations
should be admitted, and when to make room for a newer reservation by
preempting an already installed one.
This class should be extended to cover other COPS install decisions if
required.
The qosPolicyRSVPSignalCtrlAction adds the following controls:
1. Replace/add DCLASS object in RSVP message.
2. Replace/add Preemption priority object in RSVP message.
3. Trigger an error/warning RSVP message.
4. Instruct the RSVP node to proxy RSVP message as if sent by
the RSVP end nodes.
Modifying the content of messages can be enforced using a COPS
replacement decision. This class should be extended to cover other
object replacements and, in particular, replacement of policy objects.
Triggering errors and warnings is important in scenarios when there is
a need to notify the end nodes that their reservation is about to
expire and various other information.
There are scenarios in which it makes sense not to carry RSVP requests
end-to-end. An RSVP node on the boundary of a differential service core
may map the RSVP request to specific PHB by setting the DSCP on the
flow packets, without forwarding the Path message downstream. Still,
this RSVP node may send back an RSVP Resv message as if the receiver
has sent it, to complete the RSVP cycle.
The following is an example for a rule enforcing QoS signaling actions:
Rule S:
If <condition> THEN, for all WF and SE style Resv messages,
accept RSVP request requesting less than <64kb/sec> AND
make sure that the total number of admitted active reservations
is restricted to <5>.
The actions for Rule S are represented using two qosPolicyRSVPAction
objects, as follows:
Object 1:
qpRSVPDirection: OUT
qpRSVPMessageType: Resv
qpRSVPStyle: SE, WF
qpRSVPTrfcProf : DN {8Kb} (repository reference)
qpRSVPMeterScope: flow
Snir, Ramberg, Strassner, Cohen expires October 2000 36
Draft-ietf-policy-qos-info-model-01.txt April 2000
Object 2:
qpRSVPDirection: OUT
qpRSVPMessageType: Resv
qpRSVPStyle: SE, WF
qpRSVPTrfcProf : {6 session Max} (repository reference)
qpRSVPMeter: Meter (repository reference)
qpRSVPMeterScope: interface
The various attributes of RSVP traffic profiles are described in the
next section.
4.8. Traffic Profiles
The QoS Policy schema defines two categories of traffic profiles.
Provisioning traffic profiles carry rate and burst parameters to be
compared with flow meters. RSVP traffic profiles are compared with RSVP
TSPEC and FLOWSPEC parameters, and with meters aggregating the temporal
state of admitted RSVP reservations and states.
Traffic profiles can be kept in a repository for reusability. Traffic
profiles can also be directly attached to actions.
4.8.1. Provisioning traffic profiles
Shaping, policing and remarking provisioning actions compare a
provisioning traffic profile against a meter. The provisioning traffic
profile is a template containing rate and burst values, modeled by the
qosPolicyPRTrfcProf class.
The qosPolicyPRTrfcProf class includes the following properties:
1. Rate measured in bits/sec.
2. Normal burst measured in bytes.
3. Excess burst measured in bytes.
Rate determines the long-term average transmission rate. Traffic that
falls under this rate will always conform. The normal burst size
determines how large traffic bursts can be before some traffic exceeds
the traffic profile. The Excess Burst size determines how large traffic
bursts can be before all traffic exceeds the rate limit. Traffic that
falls between the normal burst size and the Excess Burst size exceeds
the traffic profile with a probability that increases as the burst size
increases. This provides a Random Discard mechanism for policers,
markers and shapers.
Excess burst size SHOULD be greater than or equal to the normal burst
size. If the excess burst size is not specified, it is assumed that
excess burst size is equal to the normal burst size. In this case,
burst larger than the normal burst size will always be counted as out-
of-profile packets.
Snir, Ramberg, Strassner, Cohen expires October 2000 37
Draft-ietf-policy-qos-info-model-01.txt April 2000
4.8.2. RSVP traffic profiles
RSVP signaling QoS policy can condition the decision whether to accept
or deny an RSVP request based on the traffic specification of the flow
(TSPEC) or the amount of QoS resources requested (FLOWSPEC). The TSPEC
and FLOWSPEC objects are either compared directly with a traffic
profile, or aggregated to a meter that measures the temporal admitted
RSVP states and than compared to the traffic specification. The
qosPolicyRSVPTrfcProf class models such a traffic profile. The
qosPolicyRSVPTrfcProf class has the following properties:
1. Token Rate (r) measured in bits/sec.
2. Peak Rate (p) measured in bits/sec.
3. Bucket Size (b) measured in bytes.
4. Min Policed unit (m) measured in bytes.
5. Max packet size (M) measured in bytes.
6. Resv Rate (R) measured in bits/sec.
7. Slack term (s) measured in microseconds.
8. Number of sessions.
The first 5 parameters are the traffic specification parameters used in
the integrated service architecture. These parameters are used to
define a sender TSPEC as well as FLOWSPEC for the Controlled Load
service [CL]. For a definition and full explanation of their meaning,
please refer to [RSVP-IS]. Parameters 6 and 7 are the additional
parameters used for specification of the Guaranteed Service FLOWSPEC
[GS]. The last parameter is used to specify the maximum number of
allowed RSVP sessions. This provides an easy way to limit the number of
admitted RSVP requests without requiring pre-knowledge of the
aggregated rates requested.
A partial order is defined between TSPECs (and FLOWSPECs). A TSPEC A is
larger than TSPEC B if and only if rA>rB, pA>pB, bA>bB, mA<mB and
MA>MB. A TSPEC measured against a traffic profile uses the same
ordering rule. An RSVP message is accepted only if its TSPEC (FLOWSPEC)
is either smaller or equal to the traffic profile. Only parameters
specified in the traffic profile are compared.
The GS FLOWSPEC is also compared against the rate R and the slack term
S. R should not be larger than the traffic profile R parameter, while
the FLOWSPEC slack term should not be smaller than that specified in
the slack term.
TSPECs as well as FLOWSPECs can be added. The sum of two TSPECs is
computed by summing the rate r, the peak rate p, the bucket size b, and
by taking the minimum of min policed unit m and the maximum of the max
packet size M. GS FLOWSPECs are summed by adding the Resv rate and
minimizing the slack term s. These rules are used to compute a meter
that measures the temporal state of admitted RSVP states. The meter is
than compared with the traffic profile specified in the signaling
policy using the same rules for comparison of TSPECs (FLOWSPECs) to a
traffic profile.
Snir, Ramberg, Strassner, Cohen expires October 2000 38
Draft-ietf-policy-qos-info-model-01.txt April 2000
5. Decision strategy
The decision strategy to be used by policy servers and other policy
decision points in the network on a set of policies is defined by
grouping policies into various qosNamedPolicyContainer groups, and
using these groups to partition behavior in different QoS policy
domains. In order to get a consistent behavior of different policy
servers using the same group of policy rules, the priority of the
policy rules must be pre-defined and the decision strategy implemented
by each different policy server must be defined explicitly.
The decision strategy is defined per domain and can be overridden per
qosNamedPolicyContainer. When a policy decision point evaluates a set
of rules, it implements the decision strategy defined in each container
of rules. Nested containers can override the decision strategy of their
containers.
The order of decision making of nested rules is defined by the
combination of their internal priority, the priority of the policy rule
containing the nested rule and the priority of their containers.
Nested rules have a higher priority than their containing rule.
Priority is compared between rules and qosNamedPolicyContainers, as
Defined in [PCIM]. The rule priority of PCIM is extended by introducing
the qpPriority (group priority) property of qosNamedPolicyContainer.
Two decision strategies are defined:
1. "FIRST MATCH"
2. "MATCH ALL"
5.1. First match
The first match decision strategy is defined as a process that
evaluates the policy rules in the defined order, evaluating the
conditions of each rule, until a condition is evaluated to TRUE. The
rule's actions are then applied and the process of decision-making is
terminated.
5.2. Match All
The match all decision strategy is defined as first scanning the
complete set of rules according to their defined order of priority and
then applying the actions of each rule that the flow meets with the
rule's conditions. This matching strategy may in many cases mean that a
number of rules may meet the flow's parameters and all of their actions
will be applied.
A Match All strategy may result in applying conflicting rules. Handling
conflicts is outside the scope of this draft. The implementers of QoS
systems must provide proprietary conflict detection and avoidance or
resolution mechanisms.
Snir, Ramberg, Strassner, Cohen expires October 2000 39
Draft-ietf-policy-qos-info-model-01.txt April 2000
5.3. Decision Strategy example
This section demonstrates both decision strategies and rule
prioritization. The rules to be evaluated are shown in Figure 4 below.
Domain
|
+--Rule1 (priority 19)
|
+--NamedContainer1 (priority 5)
| |
| +--Rule 1.1 (priority 3)
| |
| +--Rule 1.2 (priority 33)
|
+--Rule3 (priority 4)
|
+--Rule4 (priority 2)
Figure 4: Decision Strategy example
NOTE: rule nesting is not defined in PCIM, but rather is defined in
this document
5.3.1 Default Operation using First Match Everywhere
For simplicity we assume that a Policy Decision Point needs to enforce
all rules described above. Therefore, the rules will be evaluated in
the following order:
1. Rule1 (higher priority between Rule1, namedContainer1 and Rule3
2. Rule1.2 (higher priority between Rule1.1 and Rule1.2)
3. Rule1.1 (because its container has a higher priority than Rule3
4. Rule4 (because it is nested in Rule 3)
5. Rule3
If the decision strategy of the domain is first match and it is not
overridden by NamedContainer1, the decision process will stop once a
rule's condition is matched.
Note: this equates priority with order. This is very different than how
this same example would work using priority as defined in [PCIM] (in
fact, this could not even be represented in [PCIM]). This is because of
the following two reasons:
- PCIM does not provide the ability to assign an order to a named
container. It therefore has no concept of ordering containers among
its policy rules
- PCIM has no concept of nested rules
Snir, Ramberg, Strassner, Cohen expires October 2000 40
Draft-ietf-policy-qos-info-model-01.txt April 2000
5.3.2 Operation Using Other Decision Strategies
However, if the decision strategy of the domain is match all and it is
not overridden by NamedContainer1, the match all decision process will
run over all rules according to the order above.
If the decision strategy of the domain is first match and the decision
process of NamedContainer1 is match all, Rule1 will be evaluated
first. If its condition matches, the decision process stops. Else,
both Rules 1.1 and 1.2 will be evaluated and executed if their
conditions match. If one of NamedContainer1 rule match, the decision
process stops. Else Rules 3 and 4 will be evaluated using first match
decision strategy.
If the decision strategy of the domain is match all and the decision
process of NamedContainer1 is first match, the decision process will
evaluate Rule1 and continue to evaluate NamedContainer1 rules. Rules
1.1 and 1.2 will be evaluated using first match strategy. The decision
process continues to evaluate rules 3 and 4 according to match-all
decision strategy.
Snir, Ramberg, Strassner, Cohen expires October 2000 41
Draft-ietf-policy-qos-info-model-01.txt April 2000
6. Per Hop Behavior
A per-hop behavior (PHB) is a description of the externally observable
forwarding behavior of a DS node applied to a particular DS behavior
aggregate. A PHB is selected at a node by the DSCP in a received
packet. A set of PHBs is enforced on a QoS domain. The set of PHBs
share buffer and scheduler resources among them. The QPIM provides
abstract placeholders for PHBs and for a set of PHBs enforced together
on a QoS domain. Further specification of PHBs and PHB sets are outside
the scope of this document; please refer to [PHBSET] for more
information.
6.1. PHBs
The qosPolicyPHB abstract class models a single PHB. The qosPolicyPHB
class includes a single property, the DSCP value, which is an integer
with allowed values in the range of 0 to 63, inclusive. The
qosPolicyPHB name will be defined using the cn property belonging
to the Policy class [PCIM].
6.1. PHB Sets
The qosPolicyPHBSet abstract class serves as a named container for
instances of qosPolicyPHB classes. It models the set of PHBs enforced
together on a QoS domain. Different PHB sets can be kept in a
repository. A PHB set enforced on the domain is specified by either a
reference from the qosPolicyDomain class to one of the PHB sets that
are located in the reusable-object repository, or by directly including
the PHB set in the domain (the method for doing this is repository-
specific; for example, attachment could be used if the repository is a
directory).
To fine tune PHB parameters and to further restrict the namespace in
which a particular PHB is used, PHB sets can be referenced or augment
the semantics of qosNamedPolicyContainers. However, in order to
maintain an end-to-end consistent behavior, overriding the domain's PHB
set should be done only to fine tune the parameters of each PHBs, and
not to use a different set of PHBs altogether.
Markers coloring packets of flows on domain ingress edges should pick a
DSCP selecting one of the PHBs enforced on the QoS domain.
Snir, Ramberg, Strassner, Cohen expires October 2000 42
Draft-ietf-policy-qos-info-model-01.txt April 2000
7. QoS Policy Class Inheritance
The following diagram illustrates the class hierarchy for the QPIM.
Relevant classes from the PCIM are also included for completeness:
top
|
+--policy (abstract, [PCIM])
| |
| +--policyGroup ([PCIM])
| | |
| | +--qosPolicyDomain
| | |
| | +--qosNamedPolicyContainer
| |
| +--policyRule ([PCIM])
| |
| +--policyCondition ([PCIM])
| | |
| | +--policyTimePeriodCondition ([PCIM])
| | |
| | +--vendorPolicyCondition ([PCIM])
| | |
| | +--qosPolicySimpleCondition
| |
| +--policyAction
| | |
| | +--vendorPolicyAction ([PCIM])
| | |
| | +-- qosPolicyPRAction
| | |
| | +-- qosPolicyRSVPAction
| | |
| | +-- qosPolicyRSVPSignalCtrlAction
| | |
| | +-- qosPolicyRSVPInstallAction
| |
| +--qosPolicyVariable
| |
| +--qosPolicyValue(abstract)
| | |
| | +--qosPolicyIPv4AddrValue
| | |
| | +--qosPolicyIPv6AddrValue
| | |
| | +--qosPolicyMACAddrValue
| | |
| | +--qosPolicyStringValue
| | |
| | +--qosPolicyBitStringValue
| | |
(Diagram continued in next page)
Snir, Ramberg, Strassner, Cohen expires October 2000 43
Draft-ietf-policy-qos-info-model-01.txt April 2000
(Diagram continued from previous page)
top
|
+--policy (abstract, [PCIM])
| |
| +--qosPolicyValue(abstract, continued from previous page)
| | |
| | +--qosPolicyDNValue
| | |
| | +--qosPolicyAttributeValue
| | |
| | +--qosPolicyIntegerValue
| |
| +-- qosPolicyMeter
| |
| +-- qosPolicyPRTrfcProf
| |
| +-- qosPolicyRSVPTrfcProf
| |
| +-- qosPolicyPHBSet (abstract)
| |
| +-- qosPHB (abstract)
|
+--CIM_ManagedSystemElement (abstract)
|
+--CIM_LogicalElement (abstract)
|
+--CIM_System (abstract)
|
+---CIM_AdminDomain (abstract)
|
+---PolicyRepository
Figure 5. Class Inheritance Hierarchy for the QPIM
The reader is encouraged to read section 7 of [PCIM] in its entirety,
which defines the concepts of associations and aggregations. Ten
associations and aggregations are defined in the [PCIM]; note that the
QPIM does not define any new associations or aggregations:
the Aggregation PolicyGroupInPolicyGroup
the Aggregation PolicyRuleInPolicyGroup
the Aggregation PolicyConditionInPolicyRule
the Aggregation PolicyRuleValidityPeriod
the Aggregation PolicyActionInPolicyRule
the Association PolicyConditionInPolicyRepository
the Association PolicyActionInPolicyRepository
the Weak Aggregation PolicyGroupInSystem
the Weak Aggregation PolicyRuleInSystem
the Aggregation PolicyRepositoryInPolicyRepository
Snir, Ramberg, Strassner, Cohen expires October 2000 44
Draft-ietf-policy-qos-info-model-01.txt April 2000
8. Class Definitions
8.1. Class qosPolicyDomain
This class defines the root of a single administrative QoS policy
domain, and contains the domain's policy rules and definitions. This
enables the administrator to partition the set of QoS information into
different domains, where each domain has a potentially different set of
PHBs and policies, access rules, decision strategy or other application
of the policy information organized in some fashion. The class
definition is as follows:
NAME qosPolicyDomain
DERIVED FROM policyGroup (defined in [PCIM])
ABSTRACT False
PROPERTIES qpDomainName, qpPHBSet, qpPolicyRuleMatchMethod
8.1.1. The Property qpDomainName
This property provides a user-friendly name for the QoS policy domain.
Its definition is as follows:
NAME qpDomainName
SYNTAX String
8.1.2. The Property qpPHBSet
This property contains a reference to the PHB set defined for this
domain. Its definition is as follows:
NAME qpPHBSet
SYNTAX Reference to a PHBSet object
8.1.3. The Property qpPolicyRuleMatchMethod
This property defines the decision strategy to be applied on this set
of QoS policy rules by policy servers. It is an enumerated integer that
defines two values, first match and match all. Please see section 5 of
this document for more information on these decision strategies. Its
definition is as follows:
NAME qpPolicyRuleMatchMethod
SYNTAX Integer (ENUM) - {"FIRST MATCH " = 0; "MATCH ALL " = 1 }
Snir, Ramberg, Strassner, Cohen expires October 2000 45
Draft-ietf-policy-qos-info-model-01.txt April 2000
8.2. Class qosNamedPolicyContainer
This class represents an administratively-defined policy rule
container. All policies that are commonly administered are defined in a
particular qosNamedPolicyContainer. For example, an administrator could
define a set of policies that serve a certain goal, or service a
certain type of application, or that handle a certain type of flow or
device. Placing these policies in a qosNamedPolicyContainer that
resides in a particular qosPolicyDomain enables the administrator to
group different sets of policy rules that perform different types of
operations. It also enables an organization to partition policies
according to the administrator (or other entity) that manages the
policies. The class definition is as follows:
NAME qosNamedPolicyContainer
DERIVED FROM policyGroup (defined in [PCIM])
ABSTRACT False
PROPERTIES qpPriority, qpNamedPolicyRuleMatchMethod
8.2.1. The Property qpPriority
This property is a non-negative integer that defines the priority of a
named group of rules. Conceptually, it is the priority of the
qosNamedPolicyContainer, and is used to determine when the policy rules
that the qosNamedPolicyContainer contains are evaluated with respect to
other policyRules, policyGroups, and other qosNamedPolicyContainters.
If two or more qosPolicyNamedContainer objects have the same priority,
this means that the order between these objects is of no importance,
but that they each be evaluated before other objects that have a
numerically lower priority. The attribute is defined as follows:
NAME qpPriority
SYNTAX Integer (must be non-negative)
8.2.2. The Property qpNamedPolicyRuleMatchMethod
This property is an enumerated integer that defines the decision
strategy to be applied on this set of QoS policy rules by policy
servers. Please see section 5 of this document for more information on
these decision strategies. The attribute is defined as follows:
NAME qpNamedPolicyRuleMatchMethod
SYNTAX Integer (ENUM) - {"FIRST MATCH " = 0; "MATCH ALL " = 1 }
Snir, Ramberg, Strassner, Cohen expires October 2000 46
Draft-ietf-policy-qos-info-model-01.txt April 2000
8.3. Class qosPolicyPRAction
This class defines DiffServ actions to be applied on a flow or group of
flows, including the marking of a DSCP value, dropping, policing and
shaping. The class definition is as follows:
NAME qosPolicyPRAction
DERIVED FROM policyAction (defined in [PCIM])
ABSTRACT False
PROPERTIES qpDirection, qpSetDSCPvalue, qpMeter, qpMeterScope,
qpTrfcProf, qpOutOfProfileAction,
qpOutOfProfileRemarkValue
8.3.1. The Property qpDirection
This property is an enumerated integer that defines whether the action
should be applied to incoming or/and outgoing interfaces. Note that
certain repositories MAY implement this enumeration in a different
form, as long as its semantics are preserved. For example, a directory
MAY implement this property as a multi-valued attribute, with the
attribute having the values IN and OUT. The attribute is defined as
follows:
NAME qpDirection
SYNTAX Integer (ENUM) - {IN=0, OUT=1, BOTH=2}
8.3.2. The Property qpSetDSCPvalue
This property is an integer (constrained to the range 0-63, inclusive)
that defines the DSCP value of the (re)mark action. The attribute is
defined as follows:
NAME qpSetDSCPvalue
SYNTAX Integer (must be in the range 0-63, inclusive)
8.3.3. The Property qpMeter
This property defines a reference to a qosPolicyMeter object used in
this provisioning action. The attribute is defined as follows:
NAME qpMeter
SYNTAX Reference to a qosPolicyMeter object
Snir, Ramberg, Strassner, Cohen expires October 2000 47
Draft-ietf-policy-qos-info-model-01.txt April 2000
8.3.4. The Property qpMeterScope
This property is an enumerated integer that defines whether this
metering action should be applied on a per-flow, per-interface, or per-
device basis. The attribute is defined as follows:
NAME qpMeterScope
SYNTAX Integer (ENUM) û {flow=0,interface=1 device=2}
8.3.5. The Property qpTrfcProf
This property contains a reference to an object that defines the
DiffServ provisioning policing instruction value, defined as a
reference to a qosPolicyPRTrfcProf instance. The attribute is defined
as follows:
NAME qpTrfcProf
SYNTAX Reference to a qosPolicyPRTrfcProf object
8.3.6. The Property qpOutOfProfileAction
This property is an enumerated integer that defines the action to be
applied to out of profile packets, as defined in the DiffServTrfcProf
entry. That entry contains values for each of the three types of
actions that are present in this attribute: shaping, discarding, or
remarking. The attribute is defined as follows:
NAME qpOutOfProfileAction
SYNTAX Integer (ENUM) - {SHAPE=0,DISCARD=1,REMARK=2}
8.3.7. The Property qpOutofProfileRemarkValue
This property is an integer that defines the DSCP value to be applied
to out of profile packets if the qpOutofProfile action is defined as
REMARK. The attribute is defined as follows:
NAME qpOutofProfileRemarkValue
SYNTAX Integer (constrained to the range 0-63, inclusive)
8.4. Class qosPolicyRSVPAction
This class defines a policy action to be applied on an RSVP signaling
message that matches the rule condition. The class definition is as
follows:
Snir, Ramberg, Strassner, Cohen expires October 2000 48
Draft-ietf-policy-qos-info-model-01.txt April 2000
NAME qosPolicyRSVPAction
DERIVED FROM policyAction (defined in [PCIM])
ABSTRACT False
PROPERTIES qpRSVPDirection, qpRSVPMessageType, qpRSVPService,
qpRSVPStyle, qpRSVPInstallAction, qpRSVPCtrlAction,
qpRSVPMeter, qpRSVPMeterScope, qpRSVPTrfcProf
8.4.1. The Property qpRSVPDirection
This property is an enumerated integer, and defines whether the action
is to be applied to incoming or/and outgoing interfaces. Note that
certain repositories MAY implement this enumeration in a different
form, as long as its semantics are preserved. For example, a directory
MAY implement this property as a multi-valued attribute, with the
attribute having the values IN and OUT. The attribute is defined as
follows:
NAME qpRSVPDirection
SYNTAX Integer (ENUM) - {IN=0,OUT=1,BOTH=2}
8.4.2. The Property qpRSVPMessageType
This property is an enumerated integer, and defines different values
that limit the scope of the action to be enforced to specific types of
RSVP messages. The attribute is defined as follows:
NAME qpRSVPMessageType
SYNTAX Integer (ENUM) - {Path=0 Resv=1 ResvErr=2 PathErr=3}
8.4.3. The Property qpRSVPStyle
This property is an enumerated integer, and defines different values
that limit the scope of the action to be enforced to RSVP Requests with
the specified reservation style. The attribute is defined as follows:
NAME qpRSVPStyle
SYNTAX Integer (ENUM) - {SE=0 FF=1 WF=2}
8.4.4. The Property qpRSVPServiceType
This property is an enumerated integer, and defines different values
that limit the scope of the action to be enforced to RSVP Requests
asking for specified integrated service type. The attribute is defined
as follows:
NAME qpRSVPServiceType
SYNTAX Integer (ENUM) -
{ControlledLoad=0, GuaranteedService=1, NULL=2}
Snir, Ramberg, Strassner, Cohen expires October 2000 49
Draft-ietf-policy-qos-info-model-01.txt April 2000
8.4.5. The Property qpRSVPInstallAction
This property is a reference to a qosPolicyRSVPInstallAction object.
This object is used in conjunction with the RSVP reservation, and
defines detailed control for COPS install decisions (defined in
[COPS]). The attribute is defined as follows:
NAME qpRSVPInstallAction
SYNTAX Reference to a qosPolicyRSVPInstallAction object
8.4.6. The Property qpRSVPCtrlAction
This property is a reference to a qosPolicyRSVPSignalCtrlAction object.
This object is used in conjunction with the RSVP reservation, and
defines detailed control on the signaling protocol behavior itself.
The information carried in RSVP messages can be modified using this
action, as well as the RSVP forwarding behavior. The attribute is
defined as follows:
NAME qpRSVPCtrlAction
SYNTAX Reference to a qosPolicyRSVPSignalCtrlAction object
8.4.7. The Property qpRSVPMeter
This property is a reference to a qosPolicyMeter object. This object is
used in conjunction with the RSVP reservation, and defines the detailed
definition of the meter characteristics. The attribute is defined as
follows:
NAME qpRSVPMeter
SYNTAX Reference to a qosPolicyMeter object
8.4.8. The Property qpRSVPMeterScope
This property is an enumerated integer that defines the scope of the
metering action to be on a per-flow, per-interface, or per-device
basis. The attribute is defined as follows:
NAME qpRSVPMeterScope
SYNTAX Integer (ENUM) û {flow=0,interface=1 device=2}
Snir, Ramberg, Strassner, Cohen expires October 2000 50
Draft-ietf-policy-qos-info-model-01.txt April 2000
8.4.9. The Property qpRSVPTrfcProf
This property is a reference to a qosPolicyRSVPTrfcProf object, which
defines an IntServ RSVP Traffic profile. Values of RSVP traffic
profiles are compared against Traffic specification (TSPEC) and QoS
Reservation requests (FLOWSPEC) carried in RSVP requests. The attribute
is defined as follows:
NAME qpRSVPTrfcProf
SYNTAX Reference to a qosPolicyRSVPTrfcProf object
8.5. Class qosPolicyPRTrfcProf
A provisioning Traffic profile is a class that carries the policer or
shaper rate values to be enforced on a flow or a set of flows. The
class definition is as follows:
NAME qosPolicyPRTrfcProf
DERIVED FROM policy (defined in [PCIM])
ABSTRACT False
PROPERTIES qpPRRate, qpPRNormalBurst, qpPRExcessBurst
8.5.1. The Property qpPRRate
This is a non-negative integer that defines the token rate in bits per
second. A rate of zero means that all packets will be out of profile.
The attribute is defined as follows:
NAME qpPRRate
SYNTAX Integer (must be non-negative)
8.5.2. The Property qpPRNormalBurst
This attribute is an integer that defines the normal size of a burst
measured in bytes. The attribute is defined as follows:
NAME qpPRNormalBurst
SYNTAX Integer (must be non-negative)
8.5.3. The Property qpPRExcessBurst
This attribute is an integer that defines the excess size of a burst
measured in bytes. The attribute is defined as follows:
NAME qpPRExcessBurst
SYNTAX Integer (must be non-negative)
Snir, Ramberg, Strassner, Cohen expires October 2000 51
Draft-ietf-policy-qos-info-model-01.txt April 2000
8.6. Class qosPolicyRSVPTrfcProf
This class represents an IntServ RSVP Traffic profile. Values of RSVP
traffic profiles are compared against Traffic specification (TSPEC) and
QoS Reservation requests (FLOWSPEC) carried in RSVP requests. Traffic
profiles can be reusable objects or ad-hoc. The class definition is as
follows:
NAME qosPolicyRSVPTrfcProf
DERIVED FROM policy (defined in [PCIM])
ABSTRACT False
PROPERTIES qpRSVPTokenRate, qpRSVPPeakRate,
qpRSVPBucketSize, qpRSVPResvRate, qpRSVPResvSlack,
qpRSVPSessionNum, qpMinPolicedUnit, qpMaxPktSize
8.6.1. The Property qpRSVPTokenRate
This property is a non-negative integer that defines the token rate
parameter, measured in bits per second. The attribute is defined as
follows:
NAME qpRSVPTokenRate
SYNTAX Integer (must be non-negative)
8.6.2. The Property qpRSVPPeakRate
This property is a non-negative integer that defines the peak rate
parameter, measured in bits per second. The attribute is defined as
follows:
NAME qpRSVPPeakRate
SYNTAX Integer (must be non-negative)
8.6.3. The Property qpRSVPBucketSize
This property is a non-negative integer that defines the token bucket
size parameter, measured in bits per second. The attribute is defined
as follows:
NAME qpRSVPBucketSize
SYNTAX Integer (must be non-negative)
Snir, Ramberg, Strassner, Cohen expires October 2000 52
Draft-ietf-policy-qos-info-model-01.txt April 2000
8.6.4. The Property qpRSVPResvRate
This property is a non-negative integer that defines the RSVP rate (R-
Spec) in the RSVP Guaranteed service reservation. It is measured in
bits per second. The attribute is defined as follows:
NAME qpRSVPResvRate
SYNTAX Integer (must be non-negative)
8.6.5. The Property qpRSVPResvSlack
This property is a non-negative integer that defines the RSVP slack
term in the RSVP Guaranteed service reservation. It is measured in
microseconds. The attribute is defined as follows:
NAME qpRSVPResvSlack
SYNTAX Integer (must be non-negative)
8.6.6. The Property qpRSVPSessionNum
This property is a non-negative integer that defines the total number
of allowed RSVP sessions that can be active at any given time. The
attribute is defined as follows:
NAME qpRSVPSessionNum
SYNTAX Integer (must be non-negative)
8.6.7. The Property qpMinPolicedUnit
This property is a non-negative integer that defines the minimum RSVP
policed unit, measure in bytes. The attribute is defined as follows:
NAME qpMinPolicedUnit
SYNTAX Integer (must be non-negative)
8.6.8. The Property qpMaxPktSize
This property is a non-negative integer that defines the maximum
allowed packet size for RSVP messages, measure in bytes. The attribute
is defined as follows:
NAME qpMaxPktSize
SYNTAX Integer (must be non-negative)
Snir, Ramberg, Strassner, Cohen expires October 2000 53
Draft-ietf-policy-qos-info-model-01.txt April 2000
8.7. Class qosPolicyRSVPSignalCtrlAction
This class extends the functionality of the qosPolicyRSVPAction class
by adding detailed control on the signaling protocol behavior itself.
The information carried in RSVP messages can be modified using this
action, as well as the RSVP forwarding behavior.
Since the purpose of this is to augment the behavior specified by the
qosPolicyRSVPAction class, this class SHOULD be used with a
qosPolicyRSVPAction object, and SHOULD NOT be used by itself.
This class can be extended to support replacement of additional object
in RSVP messages, beyond replacement of DCLASS and PREEMPTION object
replacement defined below.
The class definition is as follows:
NAME qosPolicyRSVPSignalCtrlAction
DERIVED FROM policyAction (defined in [PCIM])
ABSTRACT False
PROPERTIES qpForwardingMode, qpSendError, qpReplaceDSCP,
qpReplacePreemptionPriority, qpReplaceDefendingPriority
8.7.1. The Property qpForwardingMode
This property is an enumerated integer that controls the forwarding of
RSVP messages. If the mode is set to proxy, RSVP Path messages are not
forwarded and a Resv message is returned as if the Resv was returned by
the receiver. Otherwise, RSVP Path messages are forwarded. The
attribute is defined as follows:
NAME qpForwardingMode
SYNTAX Integer (ENUM) - {Forward=0 , Proxy=1}
8.7.2. The Property qpSendError
This property is an enumerated integer and controls the generation of
Resv-Err and Path-Err messages as defined in [COPSRSVP]. The attribute
is defined as follows:
NAME qpSendError
SYNTAX Integer {No=0, Yes=1}
Snir, Ramberg, Strassner, Cohen expires October 2000 54
Draft-ietf-policy-qos-info-model-01.txt April 2000
8.7.3. The Property qpReplaceDSCP
This property is a non-negative integer that allows the replacement of
a DCLASS object carrying a DSCP value in an RSVP message. The attribute
specifies the DSCP value to be replaces, and is defined as follows:
NAME qpReplaceDSCP
SYNTAX Integer (constrained to the range 0-63, inclusive)
8.7.4. The Property qpReplacePreemptionPriority
This property is a non-negative integer that is used to replace or add
a preemption priority object (defined in [RSVP_PREEMP]) to RSVP
messages. The attribute is defined as follows:
NAME qpReplacePreemptionPriority
SYNTAX Integer (must be non-negative)
8.7.5. The Property qpReplaceDefendingPriority
This property is a non-negative integer that is used to replace or add
a preemption priority object (defined in [RSVP_PREEMP]) to RSVP
messages. It specifies the defending priority within the preemption
object. The attribute is defined as follows:
NAME qpReplaceDefendingPriority
SYNTAX Integer (must be non-negative)
8.8. Class qosPolicyRSVPInstallAction
This class extends the functionality of the qosPolicyRSVPAction class
by adding detailed control for COPS Install decisions (defined in
[COPS]). This action allows assigning a preemption priority with an
RSVP request, to provide a device with information which RSVP requests
to accept in case of admission failures. This action specifies a DSCP
value (which provides an associated level of QoS) to set on the flow
that RSVP is requesting.
Since the purpose of this is to augment the behavior specified by the
qosPolicyRSVPAction class, this class SHOULD be used with a
qosPolicyRSVPAction object, and SHOULD NOT be used by itself.
This class can be extended to support additional install decisions that
need to be controlled.
The class definition is as follows:
Snir, Ramberg, Strassner, Cohen expires October 2000 55
Draft-ietf-policy-qos-info-model-01.txt April 2000
NAME qosPolicyRSVPInstallAction
DERIVED FROM policyAction (defined in [PCIM])
ABSTRACT False
PROPERTIES qpSetDSCPValue, qpSetPreemptionPriority,
qpSetDefendingPriority
8.8.1. The Property qpSetDSCPValue
This property is a non-negative integer that defines the setting of a
DSCP value in the device. In other words, this attribute controls the
remarking (by the device) of the flow signaled by the RSVP request. The
attribute is defined as follows:
NAME qpSetDSCPValue
SYNTAX Integer (constrained to the range 0-63, inclusive)
8.8.2. The Property qpSetDefendingPriority
This property is a non-negative integer, and is used to set the
defending priority within the preemption object (defined in
[RSVP_PREEMP]) of RSVP flows. The attribute is defined as follows:
NAME qpSetDefendingPriority
SYNTAX Integer (must be non-negative)
8.8.3. The Property qpSetPreemptionPriority
This property is a non-negative integer, and is used to set the
preemption priority [RSVP_PREEMP] of RSVP flows. The attribute is
defined as follows:
NAME qpSetPreemptionPriority
SYNTAX Integer (must be non-negative)
8.9. Class qosPolicySimpleCondition (Aux)
A simple condition is composed of an ordered triplet:
<Variable> <Operator> <Value>
The operator used in all condition definitions in this draft is
the 'match' operator. Such simple conditions are evaluated by answering
the question: Does <variable> match <value>? The operator property can
be extended to support other relations between variable and values.
Simple conditions are building blocks for more complex Boolean
conditions. The qosPolicySimpleCondition class is derived from the
policyCondition class in [PCIM]. Simple conditions can be kept in
repositories for reuse.
Snir, Ramberg, Strassner, Cohen expires October 2000 56
Draft-ietf-policy-qos-info-model-01.txt April 2000
The class definition is as follows:
NAME qosPolicySimpleCondition
DERIVED FROM policyCondition (defined in [PCIM])
ABSTRACT False
PROPERTIES qpOperator, qpVariableAtom, qpValueAtom
8.9.1. The Property qpOperator
This property is a string that defines the relation between a variable
and a value. The default value is ômatchö, which has the semantics of
'belong to' or 'equal'. The attribute is defined as follows:
NAME qpOperator
SYNTAX String
DEFAULT VALUE 'match'
8.9.2. The Property qpVariableAtom
This property is a reference to an object that defines the variable to
be used in a QoS policy condition. The referenced object SHOULD be a
subclass of the qosPolicyVariable class. The attribute is defined as
follows:
NAME qpVariableAtom
SYNTAX Reference to an object that is a subclass of the
qosPolicyVariable class
8.9.3. The Property qpValueAtom
This property is a reference to an object that defines the value to be
used in a QoS policy condition. The referenced object SHOULD be a
subclass of the qosPolicyValue class. The attribute is defined as
follows:
NAME qpValueAtom
SYNTAX Reference to an object that is a subclass of the
qosPolicyValue class
8.10. Class qosPolicyVariable
Variables are used for building individual conditions. The variable
specifies the property of a flow that should be matched when evaluating
the condition. However, not every combination of a variable and a value
creates a meaningful condition. A source IP address variable can not be
matched against a value that specifies a port number. A given variable
selects the set of matchable value types.
Snir, Ramberg, Strassner, Cohen expires October 2000 57
Draft-ietf-policy-qos-info-model-01.txt April 2000
A variable also limits the set of values within a particular value type
that can be matched against it in a condition. For example, a source-
port variable limits the set of values to represent integers to the
range of 0-65535. Integers outside this range can not be matched to the
16 bits port entity.
The class definition is as follows:
NAME qosPolicyVariable
DERIVED FROM policy (defined in [PCIM])
ABSTRACT False
PROPERTIES qpVariableName, qpValueTypes, qpVariableDescription,
QpValueConstraints
8.10.1. The Property qpVariableName
This property is a string that is a unique name for the variable. This
is very important, because the QPIM defines a correlation between its
pre-defined variable names and their logical bindings. This correlation
was defined earlier in Table 2. The attribute is defined as follows:
NAME qpVariableName
SYNTAX String, defined in the following table:
8.10.2 The Property qpValueTypes
This property is a string that specifies an unordered list of possible
value types that can be used in a simple condition together with this
variable. The value types are specified by their class names. The list
of class names allows efficient retrieval of the possible set of
relevant values from a repository, and was defined earlier in Table 3.
The attribute is defined as follows:
NAME qpValueTypes
SYNTAX String
8.10.3. The Property qpVariableDescription
This property is a string that provides a textual description of the
variable. The attribute is defined as follows:
NAME qpVariableDescription
SYNTAX String
Snir, Ramberg, Strassner, Cohen expires October 2000 58
Draft-ietf-policy-qos-info-model-01.txt April 2000
8.10.4. The Property qpValueConstraints
This property is a set of references to objects serving as constraints
for this variable. This attribute is defined as follows:
NAME qpValueConstraints
SYNTAX Set of references to objects that constrain this variable
8.11. Class qosPolicyValue
This is an abstract class that serves as the base class for all
subclasses that are used to define value objects in the QPIM. It is
used for defining values and constants used in policy conditions. The
class definition is as follows:
NAME qosPolicyValue
DERIVED FROM policy (defined in [PCIM])
ABSTRACT True
PROPERTIES
8.12. Class qosPolicyIPv4AddrValue
This class is used to provide a list of IPv4Addresses, hostnames and
address range values. The class definition is as follows:
NAME qosPolicyIPv4AddrValue
DERIVED FROM qosPolicyValue
ABSTRACT False
PROPERTIES qpIPv4AddrList
8.12.1. The Property qpIPv4AddrList
This Property provides an unordered list of strings, each specifying a
single IPv4 address, a hostname, or a range of IPv4 addresses. The ABNF
definition [ABNF] of an IPv4 address is:
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
IPv4prefix = IPv4address "/" 1*2DIGIT
IPv4range = IPv4address"-"IPv4address
IPv4maskedaddress = IPv4address","IPv4address
Hostname (as defined in [NAMES])
Each string entry is either:
1. A single Ipv4address in dot notation as defined above.
Example: 121.1.1.2
2. A single Hostname. Hostname format follows the guidelines and
restrictions specified in [NAMES].
Example: www.bigcompany.com
Snir, Ramberg, Strassner, Cohen expires October 2000 59
Draft-ietf-policy-qos-info-model-01.txt April 2000
3. An IPv4range address range defined above, specified by a start
address in dot notation and an end address in dot notation,
separated by "-". The range includes all addresses between the
range's start and end addresses, including the start and end
addresses.
Example: 1.1.22.1-1.1.22.5
4. An IPv4maskedaddress address range defined above, specified by an
address and mask. The address and mask are represented in dot
notation separated by a comma ",".
Example: 2.3.128.0,255.255.248.0.
5. An IPv4prefix address range defined above specified by an address
and a prefix length separated by "/".
Example: 2.3.128.0/15
NAME qpIPv4AddrList
SYNTAX String
FORMAT IPv4address | hostname | IPv4addressrange |
IPv4maskedaddress | IPv4prefix
8.13. Class qosPolicyIPv6AddrValue
This class is used to define a list of IPv6 addresses, hostnames, and
address range values. The class definition is as follows:
NAME qosPolicyIPv6AddrValue
DERIVED FROM qosPolicyValue
ABSTRACT False
PROPERTIES qpIPv6AddrList
8.13.1. The Property qpIPv6AddrList
This property provides an unordered list of strings, each specifying an
IPv6 address, a hostname, or a range of IPv6 addresses. IPv6 address
format definition uses the standard address format defined in [IPv6].
The ABNF definition [ABNF] as specified in [IPv6] is:
IPv6address = hexpart [ ":" IPv4address ]
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
IPv6prefix = hexpart "/" 1*2DIGIT
hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
IPv6range = IPv6address"-"IPv6address
IPv6maskedaddress = IPv6address","IPv6address
Hostname (as defines in [NAMES])
Snir, Ramberg, Strassner, Cohen expires October 2000 60
Draft-ietf-policy-qos-info-model-01.txt April 2000
Each string entry is either:
1. A single IPv6address as defined above.
2. A single Hostname. Hostname format follows guidelines and
restrictions specified in [NAMES].
3. An IPv6range address range, specified by a start address in dot
notation and an end address in dot notation, separated by "-".
The range includes all addresses between the range's start and end
addresses, including the start and end addresses.
4. An IPv4maskedaddress address range defined above specified by an
address and mask. The address and mask are represented in dot
notation separated by a comma ",".
5. A single IPv6prefix as defined above.
NAME qpIPv6AddrList
SYNTAX String
FORMAT IPv6address | hostname | IPv6addressrange |
IPv6maskedaddress | IPv6prefix
8.14. Class qosPolicyMACAddrValue
This class is used to define a list of MAC addresses and MAC address
range values. The class definition is as follows:
NAME qosPolicyMACAddrValue
DERIVED FROM qosPolicyValue
ABSTRACT False
PROPERTIES qpMACAddrList
8.14.1. The Property qpMACAddrList
This property provides an unordered list of strings, each specifying a
MAC address or a range of MAC addresses. The 802 MAC address canonical
format is used. The ABNF definition [ABNF] is:
MACaddress = 1*4HEXDIG ":" 1*4HEXDIG ":" 1*4HEXDIG
MACmaskedaddress = MACaddress","MACaddress
Each string entry is either:
1. A single MAC address. Example: 0000:00A5:0000
2. A MACmaskedaddress address range defined specified by an address
and mask. The mask specifies the relevant bits in the address.
Example: 0000:00A5:0000, FFFF:FFFF:0000 defines a range of MAC
addresses in which the first 4 8-bit bytes are equal to 0000:00A5.
NAME qpMACAddrList
SYNTAX String
FORMAT MACaddress | MACmaskedaddress
Snir, Ramberg, Strassner, Cohen expires October 2000 61
Draft-ietf-policy-qos-info-model-01.txt April 2000
8.15. Class qosPolicyStringValue
This class is used to represent a single or set of string values. Each
can have wildcards. The class definition is as follows:
NAME qosPolicyStringValue
DERIVED FROM qosPolicyValue
ABSTRACT False
PROPERTIES qpStringList
8.15.1. The Property qpStringList
This property provides an unordered list of strings, each representing
a single string with wildcards. The asterisk character "*" is used as a
wildcard, and represents an arbitrary sub-string replacement. For
example, the value "abc*def" match "abcxyzdef", and the value
"abc*def*" match "abcxxxdefyyyzzz". The syntax definition is identical
to the substring assertion syntax defined in [LDAP_ATTR]. If the
asterisk character is required as part of the string value itself, it
MUST be quoted as described in section 4.3 of [LDAP_ATTR].
The attribute definition is as follows:
NAME qpStringList
SYNTAX String
8.16 Class qosPolicyBitStringValue
This class is used to represent a single or set of bit string values.
The class definition is as follows:
NAME qosPolicyBitStringValue
DERIVED FROM qosPolicyValue
ABSTRACT False
PROPERTIES qpBitStringList
8.16.1. The Property qpBitStringList
This property provides an unordered list of strings, each representing
a single bit string or a set of bit strings. The number of bits
specified SHOULD equal the number of bits of the expected variable. For
example, for an 8-bit byte variable, 8 bits should be specified. If the
variable does not have a fixed length, the bit string should be matched
against the variable most significant bit string. The formal
definitions are:
binary-digit = "0" / "1"
bitstring = 1*binary-digit
maskedBitString = bitstring","bitstring
Snir, Ramberg, Strassner, Cohen expires October 2000 62
Draft-ietf-policy-qos-info-model-01.txt April 2000
Each string entry is either:
1. A single bit string. Example: 00111010
2. A range of bit strings specifies using a bit string and a bit
mask. The bit string and mask properties have the same number of
bits specified. The mask bit string specifies the significant bits
in the bit string value. For example, 110110, 100110 and 110111
would match the maskedBitString 100110,101110 but 100100 would
not.
NAME qpBitStringList
SYNTAX String
FORMAT bitString | maskedBitString
8.17. Class qosPolicyDNValue
This class is used to represent a single or set of Distinguished Name
values, including wildcards. A Distinguished Name is a name that can be
used as a key to retrieve an object. This value can be used in
comparison to reference values carried in RSVP policy objects, as
specified in [IDENT].
The class definition is as follows:
NAME qosPolicyDNValue
DERIVED FROM qosPolicyValue
ABSTRACT False
PROPERTIES qpDNList
8.17.1. The Property qpDNList
This property provides an unordered list of Distinguished Name
references to objects. The attribute is defined as follows:
NAME qpDNList
SYNTAX List of Distinguished Names, each of which serves as a
reference to another object.
8.18. Class qosPolicyAttributeValue
This class is used to represent a single or set of property values in
an object. This value can be used in conjunction with reference values
carried in RSVP objects, as specified in [IDENT]. The property name is
used to specify which of the properties in the object is being used as
the condition. The value of this property will then be retrieved, and a
match (which is dependent on the property name) will be used to see if
the condition is satisfied or not.
Snir, Ramberg, Strassner, Cohen expires October 2000 63
Draft-ietf-policy-qos-info-model-01.txt April 2000
For example, suppose a User class has a multi-valued Property called
'member-of' that lists the names of groups that this user belongs to.
Suppose this property uses caseIgnoreMatch matching. A simple condition
can be constructed to match the reference carried in an RSVP Identity
policy object to a qosPolicyAttributeValue with the following
characteristics:
qpAttributeName="member-of",
qpAttributeValueList = "group-A".
An Identity policy object carrying the following reference:
"OU=Sales, CN=J. Smith, O=Widget Inc."
will match this simple condition only if J. Smith belongs to group-a.
The class definition is as follows:
NAME qosPolicyAttributeValue
DERIVED FROM qosPolicyValue
ABSTRACT False
PROPERTIES qpAttributeName, qpAttributeValueList
8.18.1. The Property qpAttributeName
This attribute defines the name of the property that the list of values
should be compared against. The attribute is defined as follows:
NAME qpAttributeName
SYNTAX String
8.18.2. The Property qpAttributeValueList
This attribute contains a list of property values. Each value is
compared to a value of the property specified by qpAttributeName. The
attribute is defined as follows:
NAME qpAttributeValueList
SYNTAX String
8.19. Class qosPolicyIntegerValue
This class provides a list of integer and integer range values.
Integers of arbitrary sizes can be represented. For a given variable,
the set of possible ranges of integer values allowed is specified via
the variable's qpValueConstraints Property. The class definition is as
follows:
NAME qosPolicyIntegerValue
DERIVED FROM qosPolicyValue
ABSTRACT False
PROPERTIES qpIntegerList
Snir, Ramberg, Strassner, Cohen expires October 2000 64
Draft-ietf-policy-qos-info-model-01.txt April 2000
8.19.1. The Property qpIntegerList
This property provides an unordered list of integers and integer range
values. The format of this property can take on of the following forms:
1. An integer value.
2. A range of integers. The range is specifies by a start integer and
an end integer separated by "-". The range includes all integers
between start and end integers, including the start and end
integers.
To represent a range of integers that is not bounded, the reserved word
INFINITY can be used as the end range integer.
The ABNF definition [ABNF] is:
integer = 1*DIGIT | "INFINITY"
integerrange = integer"-"integer
Using ranges the operators greater-than, greater-than-or-equal-to,
less-than and less-than-or-equal-to can be expressed.
NAME qpIntegerList
SYNTAX String
FORMAT integer | integerrange
8.20. Class qosPolicyPHBSet
The qosPolicyPHBSet is a class that serves as a named container for
qosPolicyPHB objects. A single PHB set is associated with a QoS domain
using the domain property defined in the qosPolicyDomain object.
Instances of the qosNamedPolicyContainer class can override the
domain's PHB set by referencing another PHB set via the qosPolicyPHBSet
Property or by aggregation of a qosPolicyPHBSet object.
The class is defined as follows:
NAME qosPolicyPHBSet
DERIVED FROM policy (defined in [PCIM])
ABSTRACT False
PROPERTIES
8.21. Class qosPolicyPHB
The qosPolicyPHB Class is an abstract class that extends the policy
class (defined in the [PCIM]) with the information required to model
a PHB service class. The PHB service class is an abstraction over
device-specific parameters.
Snir, Ramberg, Strassner, Cohen expires October 2000 65
Draft-ietf-policy-qos-info-model-01.txt April 2000
The class is defined as follows:
NAME qosPolicyPHB
DERIVED FROM policy (defined in [PCIM])
ABSTRACT True
PROPERTIES qpDSCP
8.21.1. The Property qpDSCP
This property is an integer, constrained to have a value in the range
0..63 inclusive, for representing the service classes in the QoS policy
domain that are used for traffic classification. The attribute is
defined as follows:
NAME qpDSCP
SYNTAX Integer (must be in the range 0..63, inclusive)
8.22 Class qosPolicyMeter
This class models a meter, as defined in (for example)
[DIFF-SERV-ARCH]. Meters measure the temporal properties of the stream
of packets selected by a classifier against a traffic profile.
A meter can be shared between different policy rules. A meter shared by
more than one policy rule resides in a repository and is referenced by
all sharing rules.
The class is defined as follows:
NAME qosPolicyMeter
DERIVED FROM policy (defined in [PCIM])
ABSTRACT True
PROPERTIES
Snir, Ramberg, Strassner, Cohen expires October 2000 66
Draft-ietf-policy-qos-info-model-01.txt April 2000
9. Extending the QoS Policy Schema
The following subsections provide general guidance on how to create a
domain-specific information model derived from the QPIM by extending
the QoS policy classes.
9.1. Extending qosPolicyValue
The qosPolicyValue class and its subclasses describe the common
value types used in the QPIM. When other specific types are required,
such as a floating-point numbers, the required class SHOULD be derived
from the qosPolicyValue class and properties that contain the
corresponding values SHOULD be added.
Notice that in many cases, using the qosPolicyAttributeValue class
allows the definition of non-standard policy atoms without extending
the qosPolicyValue class.
9.2. Extending qosPolicySimpleCondition
The qosPolicySimpleCondition class is used to describe a single atomic
Boolean condition. For Boolean conditions that are not structured as
the ordered triple <variable - relation - value>, a new type of
condition class SHOULD be defined. An example would be a unary
condition.
Subclassing could be done using either the policyCondition or
qosPolicySimpleCondition classes as the superclass.
9.3. Extending qosPolicyAction
The Qos Policy actions classes defined in the QoS Policy Schema
Includes the following types of actions:
Provisioning actions:
* Marking
* Policing, shaping and remarking according to a traffic profile
Signaling RSVP action:
* RSVP policy admission
* RSVP signal control extensions
* RSVP flow control extensions
Additional actions could be associated with QoS policy rules by
extending the policyAction class with the appropriate properties.
Snir, Ramberg, Strassner, Cohen expires October 2000 67
Draft-ietf-policy-qos-info-model-01.txt April 2000
10. Security Considerations
The security considerations for this document are the same as those of
the [PCIM].
11. Acknowledgments
The authors wish to thank the input of the participants of the Policy
Framework working group, and especially Bob Moore and Alex Wang for
their helpful contributions.
12. References
[ABNF] Crocker, D., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, November
1997.
[CL] J. Wroclawski, "Specification of the Controlled-Load
Network Element Service", RFC2211, September 1997
[COPS] D. Durham, J. Boyle, R . Cohen, S. Herzog, R. Rajan, A.
Sastry, "The COPS (Common Open Policy Service) Protocol",
RFC2748
[COPSRSVP] S. Herzog, J. Boyle, R . Cohen, D. Durham, R. Rajan, A.
Sastry, "COPS Usage for RSVP", RFC2749
[DEREF] R. Moats, J. Maziarski, J. Strassner, "Extensible Match
Rules to Dereference Pointer", Internet Draft
<draft-moats-ldap-dereference-match-02.txt>
[DIFF-SERV-ARCH] S. Blake D. Blake, "An Architecture for
Differentiated Services", RFC2475
[DNDEF] Wahl, M., Kille, S., and T. Howes, "Lightweight
Directory Access Protocol (v3): UTF-8 String
Representation of Distinguished Names", RFC 2253,
December 1997.
[GS] S. Shenker, C. Partridge, R. Guerin, "Specification
of the Guaranteed Quality of Service", RFC2212,
September 1997
[IDNET] S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T.
Moore, S. Herzog, "Identity Representation for
RSVP", RFC 2752, January 2000
[IPv6] R. Hinden, S. Deering, "IP Version 6 Addressing
Architecture", RFC2373, July 1998
Snir, Ramberg, Strassner, Cohen expires October 2000 68
Draft-ietf-policy-qos-info-model-01.txt April 2000
[LDAP_ATTR] M. Wahl, A. Coulbeck, " Lightweight Directory Access
Protocol (v3): Attribute Syntax Definitions", RFC 2252
[NAME] P. Mockapetris, " Domain names - implementation and
specification", RFC1035
[PCIM] J. Strassner, E. Ellesson, B. Moore, "Policy Framework Core
Information Model", Internet Draft
<draft-ietf-policy-core-info-model-05.txt>
[PHBLDAP] R. Cohen, Y. Snir, J. Strassner, ôLDAP schema for Domain
Per Hop Behavior Setö, Internet Draft
<draft-ronc-domain-phb-set-ldap-rep-00.txt>
[PHBSET] R. Cohen, A. Zavalkovsky, N. Elfassy, ôDomain Per Hop
Behavior Set Specificationö, Internet Draft
<draft-ronc-domain-phb-set-specification-00.txt>
[PFSCHEMA] J. Strassner, E. Ellesson, B. Moore, "Policy Framework LDAP
Core Schema", Internet Draft
<draft-ietf-policy-core-schema-06.txt>
[PIB] M. Fine, K. McCloghrie, J. Seligson, K. Chan, S. Hahn, A.
Smith, "Quality of Service Policy Information Base",
Internet Draft <draft-mfine-cops-pib-01.txt>
[QOSDEV] J. Strassner, W. Weiss, D. Durham, A. Westerinen,
ôInformation Model for Describing Network Device QoS
Mechanismsö, Internet Draft
<draft-ietf-policy-qos-device-info-model-00.txt>
[QOSSCHEMA] Y. Snir, Y Ramberg, J. Strassner, R. Cohen, ôQoS
Policy Schemaö, Internet Draft
<draft-ietf-policy-qos-schema-01.txt>
[RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) -
Functional Specification.", IETF RFC 2205,
Proposed Standard, Sep. 1997.
[RSVP-IS] J. Wroclawski, "The Use of RSVP with IETF Integrated
Services", RFC2210, September 1997
[RSVP_PREEMP] Shai Herzog, "Signaled Preemption Priority Policy
Element", RFC2751
[TERMS] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", Internet RFC 2119, March 1997.
Snir, Ramberg, Strassner, Cohen expires October 2000 69
Draft-ietf-policy-qos-info-model-01.txt April 2000
13. Author's Addresses
Yoram Snir
Cisco Systems
4 Maskit Street
Herzliya Pituach, Israel 46766
Phone: +972-9-970-0085
Fax: +972-9-970-0219
E-mail: ysnir@cisco.com
Yoram Ramberg
Cisco Systems
4 Maskit Street
Herzliya Pituach, Israel 46766
Phone: +972-9-970-0081
Fax: +972-9-970-0219
E-mail: yramberg@cisco.com
John Strassner
Cisco Systems
Bldg 15
170 West Tasman Drive
San Jose, CA 95134
Phone: +1-408-527-1069
Fax: +1-408-527-2477
E-mail: johns@cisco.com
Ron Cohen
Cisco Systems
4 Maskit Street
Herzliya Pituach, Israel 46766
Phone: +972-9-970-0064
Fax: +972-9-970-0219
E-mail: ronc@cisco.com
14. Full Copyright Statement
This document and translations of it be copied and furnished to others,
and derivative works that comment on or otherwise explain it or assist
in its implementation be prepared, copied, published and distributed,
in whole or in part, without restriction of any kind, provided that the
above copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself not be
modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process PROPERTIES be followed, or as required to translate
it into languages other than English.
Snir, Ramberg, Strassner, Cohen expires October 2000 70
Draft-ietf-policy-qos-info-model-01.txt April 2000
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE
Snir, Ramberg, Strassner, Cohen expires October 2000 71
| PAFTECH AB 2003-2026 | 2026-04-24 02:12:42 |