One document matched: draft-ietf-policy-qos-schema-00.txt
QoS Policy Schema
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 takes as its starting point the object-oriented
information model for representing QoS policy information currently
under development in the IETF's Policy Framework working group.
The IETF document defining this information model is the "QoS Policy
Information Model" [QOSIM].
This document defines the LDAP representation of the classes as defined
in [QOSIM] and discusses LDAP related issues regarding the
implementation of such a schema.
The QoS Policy schema refines the concepts in the Policy Framework Core
Information Model [PCIM] and Schema [PFSCHEMA] documents in order to
extend the generalized policy model to represent network Quality of
Service (QoS) policy information. Specifically, this draft refines the
concept of generic policy rules, conditions and actions to cover
extensions necessary for representing policies to control the
configuration and management of RSVP and Differentiated Services.
This information is typically used by QoS Policy Servers to configure
network devices according to prescribed QoS Policies.
Snir, Ramberg, Strassner, Cohen expires September 2000 1
Draft-ietf-policy-qos-schema-00.txt March 2000
Table of Contents
1. Introduction 5
2. The QoS Policy Information Model 6
3. Inheritance Hierarchy for the LDAP QoS Policy Schema 7
3.1 Containment Hierarchy 9
4. General Discussion of Mapping the Information Model to LDAP 11
4.1. Use of Distinguished Name in the Schema 11
4.2. QoS Policy Auxiliary Classes 11
4.2.1. Using Attachment of Auxiliary Classes vs. DNs 11
4.2.2. Multiple Attachment 11
4.2.3. Auxiliary Classes - When and How They Should Be Used 12
4.2.3.1. Attach to policyInstance, policyConditionInstance and
policyActionInstance Class 12
4.2.3.2. Attach Specific Containers to Root Objects 12
4.2.3.3. Attach to an Object for Efficient LDAP Retrieval 12
4.2.3.3.1. Attaching qosPolicySimpleCondition to
policyRuleConditionAssociation 12
4.2.3.3.2. Attaching QoS Policy Action Classes to
policyRuleAssociation 12
4.2.3.3.3. Attaching qosPolicyVariable and qosPolicyValue
Extensions to qosPolicySimpleCondition 13
4.2.3.3.2. Attaching QoS Policy Action classes to
policyRuleActionAssociation 13
4.2.3.3.3. Attaching qosPolicyVariable and
qosPolicyValue objects to qosPolicySimpleCondition 13
4.2.3.3.4 Extensions for Complex Policy Rules 13
5. LDAP Search Efficiency 13
5.1. Reusable Objects 13
5.2. NamedGroupContainer Location 13
5.3. QoS Policy Rules Location 14
5.4. Qos Policy SubRules Location 14
5.5. Condition and Action Object Location 14
5.6. Searching for QoS Policy Objects 14
6. Data Integrity 15
6.1. Order of Insertion of Objects into the Directory Service 15
6.2. Distinguishing between Reusable Objects in the Repository and
Rule-Specific Objects 16
6.3. Versioning of Objects 16
6.4. Transaction Support 16
6.5. Data Integrity in Replicated Directories 16
7. Summary of QoS Policy Class Relationships 17
Snir, Ramberg, Strassner, Cohen expires September 2000 2
Draft-ietf-policy-qos-schema-00.txt March 2000
8. Class Definitions 19
8.1. Class policyGroup 19
8.2 Class policyRepository 19
8.3 Class qosRepositoryContainmentAuxClass 19
8.4 Class qosPolicyDomain 20
8.4.1. The Attribute qpDomainName 20
8.4.2. The Attribute qpPHBSet 20
8.5. Class qosNamedPolicyContainer 21
8.5.1. The Attribute qpPriority 21
8.5.2. The Attribute qpPolicyRuleMatchMethod 21
8.6. Class qosPolicyPRAction 22
8.6.1. The Attribute qpDirection 22
8.6.2. The Attribute qpSetDSCPvalue 22
8.6.3. The Attribute qpMeter 22
8.6.4. The Attribute qpMeterScope 23
8.6.5. The Attribute qpTrfcProf 23
8.6.6. The Attribute qpOutOfProfileAction 23
8.6.8. The Attribute qpOutofProfileRemarkValue 24
8.7. Class qosPolicyRSVPAction 24
8.7.1. The Attribute qpDirection 24
8.7.2. The Attribute qpRSVPMessageType 24
8.7.3. The Attribute qpRSVPStyle 25
8.7.4. The Attribute qpRSVPServiceType 25
8.7.5. The Attribute qpRSVPInstallAction 25
8.7.6. The Attribute qpRSVPCtrlAction 25
8.7.7. The Attribute qpMeter 25
8.7.8. The Attribute qpMeterScope 26
8.7.9. The Attribute qpTrfcProf 26
8.8. Class qosPolicyPRTrfcProf 26
8.8.1. The Attribute qpPRRate 26
8.8.2. The Attribute qpPRNormalBurst 27
8.8.3. The Attribute qpPRExcessBurst 27
8.9. Class qosPolicyRSVPTrfcProf 27
8.9.1. The Attribute qpRSVPTokenRate 27
8.9.2. The Attribute qpRSVPPeakRate 28
8.9.3. The Attribute qpRSVPBucketSize 28
8.9.4. The Attribute qpRSVPResvRate 28
8.9.5. The Attribute qpRSVPResvSlack 28
8.9.6. The Attribute qpRSVPSessionNum 28
8.9.7. The Attribute qpMinPolicedUnit 29
8.9.8. The Attribute qpMaxPktSize 29
8.10. Class qosPolicyRSVPSignalCtrlAction 29
8.10.1. The Attribute qpForwardingMode 30
8.10.2. The Attribute qpSendError 30
8.10.3. The Attribute qpReplaceDSCP 30
8.10.4. The Attribute qpPreemptionPriority 30
8.10.5. The Attribute qpDefendingPriority 31
8.11. Class qosPolicyRSVPInstallAction 31
8.11.1. The Attribute qpSetDSCPValue 32
8.11.2. The Attribute qpSetDefendingPriority 32
8.11.3. The Attribute qpSetPreemptionPriority 32
Snir, Ramberg, Strassner, Cohen expires September 2000 3
Draft-ietf-policy-qos-schema-00.txt March 2000
8.12. Class qosPolicySimpleCondition (Aux) 33
8.12.1 The Attribute qpOperator 33
8.12.2. The Attribute qpVariableAtom 34
8.12.3. The Attribute qpValueAtom 34
8.13. Class qosPolicyVariable 34
8.13.1. The Attribute qpVariableName 35
8.13.2 The Attribute qpValueTypes 36
8.13.3. The Attribute qpVariableDescription 37
8.13.4. The Attribute qpValueConstraints 37
8.14. Class qosPolicyValue 38
8.15. Class qosPolicyIPv4AddrValue 38
8.15.1. The Attribute qpIPv4AddrList 38
8.16. Class qosPolicyIPv6AddrValue 39
8.16.1. The Attribute qpIPv6AddrList 40
8.17. Class qosPolicyMACAddrValue 41
8.17.1. The Attribute qpMACAddrList 41
8.18. Class qosPolicyStringValue 42
8.18.1. The Attribute qpStringList 42
8.19 Class qosPolicyBitStringValue 42
8.19.1. The Attribute qpBitStringList 43
8.20. Class qosPolicyDNValue 43
8.20.1. The Attribute qpDNList 44
8.21. Class qosPolicyAttributeValue 44
8.21.1. The Attribute qpAttributeName 45
8.21.2. The Attribute qpAttributeValueList 45
8.22. Class qosPolicyIntegerValue 45
8.22.1. The Attribute qpIntegerList 45
8.23. Class qosPolicyPHBSet 46
8.24. Class qosPolicyPHB 46
8.24.1. The attribute qpDSCP 47
8.25. Class qosPolicyElementAuxClass 47
9. Extending the QoS Policy Schema 48
9.1. Extending qosPolicyValue 48
9.2. Extending qosPolicySimpleCondition 48
9.3. Extending qosPolicyAction 48
10. Security Considerations 49
11. Acknowledgments 49
12. References 49
13. Author's Addresses 50
14. Full Copyright Statement 51
Snir, Ramberg, Strassner, Cohen expires September 2000 4
Draft-ietf-policy-qos-schema-00.txt March 2000
1. Introduction
This document takes as its starting point the object-oriented
information model for representing QoS policy information currently
under development in the IETF's Policy Framework working group.
The IETF document defining this information model is the "QoS Policy
Information Model" [QOSIM]. This model defines the structural and
auxiliary object classes needed to represent QoS policy information.
In general, these object classes extend the Core Policy object classes
as defined in the Policy Core Schema document [PFSCHEMA]. In addition,
the QoS policy schema uses the association and aggregation mechanisms
as defined in the [PFSCHEMA].
Specifically, the Policy Core Information Model [PCIM] defines the
generic structure of a policy, and provides a framework for describing
specific conditions and actions that are used to construct application
and domain-specific policies. The QoS Policy Information model [QOSIM]
then refines this information to describe policy rules, conditions and
actions, as well as other data, that are needed to represent network
QoS policies.
Information models are by definition repository-independent. That is,
one needs to build a mapping of the data contained in the information
model to a form that can be implemented in the target repository. To
ensure that this can be done, two parallel drafts are being defined.
The first, the Policy Core Schema (PFSCHEMA), is a mapping of the
information in the PCIM to a form suitable for implementation in a
directory. The second, this document, is a mapping of the information
in the QOSIM to a form suitable for implementation in a directory.
This document also necessarily derives from the PFSCHEMA.
This draft defines the mapping of these information model classes to a
directory that uses LDAPv3 as its access protocol. In particular, this
draft refines the concept of generic policy rules, conditions and
actions to cover extensions necessary for representing policies to
control the configuration and management of RSVP and Differentiated
Services. This information is typically used by QoS Policy Servers to
configure network devices according to prescribed QoS Policies. In
general this class hierarchy will need to be mapped to a particular
data store. This is due to the differences in LDAP implementations.
For the classes in the information model, the mapping is basically
one-for-one: information model classes map to LDAP classes, and
information model properties map to LDAP attributes.
Implementations that use an LDAP directory as their policy repository
SHALL use the LDAP policy schema defined in [PFSCHEMA] and the QoS
extensions defined in this document.
Snir, Ramberg, Strassner, Cohen expires September 2000 5
Draft-ietf-policy-qos-schema-00.txt March 2000
The use of the QoS Policy information model defined in reference
[QOSIM] as the starting point enables the schema and the relationship
class hierarchy to be extensible, such that other types of policy
repositories, such as relational databases, can also use this
information.
This document fits into the overall framework for representing,
deploying, and managing policies being developed by the Policy
Framework Working Group. It also draws on the work done for the
Directory-enabled Networks (DEN) specification, reference [4].
Finally, this draft is also meant to interoperate with a companion
draft that defines the QoS capabilities of network devices. Again, two
versions of the QoS capabilities draft are planned. The first defines
the information model that represents QoS capabilities of network
devices. This draft is specified in [QOSCAP]. A second draft will be
published soon that defines the mapping of the data in [QOSCAP] to a
form that can stored in a directory.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119, reference [5].
2. The QoS Policy Information Model
This document contains an LDAP schema representing the QoS Policy
Information Model, which is defined in the companion document "QoS
Policy Information Model" [QOSIM]. Other documents may subsequently be
produced, with mappings of this same QoS Policy Information Model to
other storage technologies. Since the detailed semantics of the QoS
Policy classes appear only in reference [QOSIM], that document is a
prerequisite for reading and understanding this document.
The QoS Policy schema by itself may be insufficient to model a
particular set of QoS services and systems. In general, one may have to
derive implementation-specific classes from this schema in order to
model a specific QoS system in sufficient detail. In fact, the QoS
Policy schema is a middle layer in a three-level hierarchy of schemata:
Core Policy Schema is extended by
QoS Policy Schema is extended by
Implementation-specific schemata that also use the QoS capabilities
draft and extensions of that draft
Snir, Ramberg, Strassner, Cohen expires September 2000 6
Draft-ietf-policy-qos-schema-00.txt March 2000
3. Inheritance Hierarchy for the LDAP QoS Policy Schema
The following diagram illustrates the class hierarchy for the LDAP QoS
Policy schema classes (these classes will be defined in section 8 of
this document, except for the core classes, which are defined in
[PFSCHEMA]; note that only the [PFSCHEMA] classes required by this
draft are shown):
top (the root of the directory)
|
+--policy (abstract) ([PFSCHEMA])
| |
| +--policyGroup (structural) ([PFSCHEMA])
| | |
| | +--qosPolicyDomain (structural)
| | |
| | +--qosNamedPolicyContainer (structural)
| |
| +--policyRule (structural) ([PFSCHEMA])
| |
| +--policyRuleConditionAssociation (structural) ([PFSCHEMA])
| |
| +--policyRuleActionAssociation (structural) ([PFSCHEMA])
| |
| +--policyConditionInstance (structural) ([PFSCHEMA])
| |
| +--policyActionInstance (structural) ([PFSCHEMA])
| |
| +--policyInstance (structural) ([PFSCHEMA])
| |
| +--policyElementAuxClass (auxiliary) ([PFSCHEMA])
| |
| +--policyConditionAuxClass (auxiliary) ([PFSCHEMA])
| | |
| | +--qosPolicySimpleCondition (auxiliary)
| |
| +-- qosPolicyMeter (auxiliary)
| |
| +-- qosPolicyPRTrfcProf (auxiliary)
| |
| +-- qosPolicyRSVPTrfcProf (auxiliary)
| |
| +-- qosPolicyPHBSet (abstract)
| |
| +-- qosPHB (abstract)
| |
| +--qosPolicyVariable(auxiliary)
| |
(Figure 1 is continued on next page)
Snir, Ramberg, Strassner, Cohen expires September 2000 7
Draft-ietf-policy-qos-schema-00.txt March 2000
(Figure 1 is continued from the previous page)
top (root of the directory)
|
+--policy (abstract) ([PFSCHEMA])
| |
| +--qosPolicyValue(abstract)
| | |
| | +--qosPolicyIPv4AddrValue(auxiliary)
| | |
| | +--qosPolicyIPv6AddrValue(auxiliary)
| | |
| | +--qosPolicyMACAddrValue(auxiliary)
| | |
| | +--qosPolicyStringValue(auxiliary)
| | |
| | +--qosPolicyBitStringValue(auxiliary)
| | |
| | +--qosPolicyDNValue(auxiliary)
| | |
| | +--qosPolicyAttributeValue(auxiliary)
| | |
| | +--qosPolicyIntegerValue(auxiliary)
| |
| +--policyActionAuxClass (auxiliary) ([PFSCHEMA])
| |
| +-- qosPolicyPRAction (auxiliary)
| |
| +-- qosPolicyRSVPAction (auxiliary)
| |
| +-- qosPolicyRSVPSignalCtrlAction (auxiliary)
| |
| +-- qosPolicyRSVPInstallAction (auxiliary)
|
|
+--policyRepository (structural) ([PFSCHEMA])
|
+--policyGroupContainmentAuxClass (auxiliary) ([PFSCHEMA])
|
+--policyRuleContainmentAuxClass (auxiliary) ([PFSCHEMA])
Figure 1. QoS Policy Schema Inheritance Hierarchy
Note: classes with a "qos" prefix are QoS Policy Schema classes.
Snir, Ramberg, Strassner, Cohen expires September 2000 8
draft-ietf-policy-qos-schema-00.txt March 2000
3.1. Containment Hierarchy
The fundamental data model of the QoS Policy schema is defined by the
mapping of the inheritance and aggregation hierarchies defined in the
QoS Policy Information Model [QOSIM]. This mapping, for a directory,
forms a strict tree hierarchy (note that other mappings for other types
of repositories may be different in their resulting structure, but they
will still use the information in [QOSIM]). Containment is a critical
feature of directories. Therefore, Figure 2 shows a summary view of the
class containment hierarchy.
-------------- ----------------
|qosPolicyGroup| -.-.-.->|policyRepository|
-------------- ----------------
| |
--------------+---------- ----+-------------------
| Scope for | | | | ---------- |
| Policy | | | |-->|Conditions| |
| Admin V | | | ---------- |
| --------------- | | | -------- |
| |qosPolicyDomain| | | |-->|Actions | |
| ----------------- | | | -------- |
| |qosPolicyDomain| | | | -------- |
| ----------------- | | |-->|Profiles | |
| |qosPolicyDomain| | | | -------- |
| --------------- | | | -------- |
| | | |-->| PHBs | |
| | | | -------- |
------------------------ | | ------- |
| -->| Atoms | |
| ------- |
------------------------
------> Containment.
-.-.-.> Implied containment. That is, the qosPolicyGroup class
would not contain an instance of the Repository class, but
would rather contain instances of the subclasses of the
Repository class.
Figure 2: QoS Policy class containment - major classes
The hierarchy is structured as a set of containment relationships.
These consist of container objects that include sets of DNs of
contained objects model the branch-to-leaf relationships and
containment by placement, i.e, placing the contained objects as leafs
of the container. For example, a named policy container includes a list
of DNs of the contained
rules.
Snir, Ramberg, Strassner, Cohen expires September 2000 9
Draft-ietf-policy-qos-schema-00.txt March 2000
With respect to the Policy Framework core schema specifications
[PFSCHEMA], containers are usually based on auxiliary classes.
A container, then, may be attached to a branch level class so that
leaves specific to sub-domains, applications, or other units of scoping
may be added underneath the branch level class.
In addition, an entity may refer (by means of a DN) to a reusable
object. Reusable objects reside in repositories (i.e., a special
area within the DIT) and can be referenced by multiple users.
Reusable object references cross the containment hierarchy and are not
considered part of the policy tree structure. Section 5.1 describes the
reusable object repositories.
Policy applications do not own the DIT; rather, they must work within
an existing DIT. Consequently, this means that there is no standard
organization of objects to be controlled via policy. This makes it hard
to associate policy objects with other objects in the DIT efficiently.
One solution to this problem is to extend the DIT structure and build a
special portion in the DIT that is reserved for policy objects. This
avoids needless replication of policy objects, and promotes reusability
of policy objects. The root of the policy portion of the DIT is a
single-instance object of type qosPolicyGroup, derived from the
policyGroup class in the Policy Core Schema [PCIM]. The qosPolicyGroup
object that serves as the root of the policy schema provides scoping
for two main branches of the policy schema: reusable-objects
repositories and a policy tree that contains policy rules and their
building blocks. This can be thought of as dividing the DIT into two
major sections: a section containing reusable-object repositories and a
policy definition section.
Figure 2 shows that multiple qosPolicyDomain containers can be used to
provide scoping for a set of policyGroup and/or policyRule classes
(defined in [PCIM]). Each qosPolicyDomain can contain its own set of
policyRules and groups of rules. However, each qosPolicyDomain
contains policies that are specific to a particular administrative
domain.
The second branch is the reusable-objects repository section. This is
information that every qosPolicyDomain can use, and is divided into
different categories of information (conditions, actions, etc.). This
lets multiple policy servers in different policy domains share and
reuse common information.
These concepts are explained in more detail in the QoS Policy
Information Model [QOSIM].
Snir, Ramberg, Strassner, Cohen expires September 2000 10
Draft-ietf-policy-qos-schema-00.txt March 2000
4. General Discussion of Mapping the Information Model to LDAP
4.1. Use of Distinguished Name in the Schema
Distinguished names are object primary keys in LDAP. The QoS Policy
schema makes ample use of DNs in various places according to the
concepts defined in the Core Schema. Here are the major uses of DNs:
* Object containers - throughout the schema, the relationships of a
container to the set of objects that it contains are prevalent.
Containers hold lists of DNs of contained objects. A container may
be attached to a node on the tree, thus adding another level of
scoping to the hierarchy.
* Static branches - leaves of the tree can be pointed to by DNs to
incorporate information specific to a particular branch of the tree
* Cross hierarchy reference - references from a given entity to
another entity (e.g., a repository object ) can be
referenced by means of a DN
4.2. QoS Policy Auxiliary Classes
4.2.1. Using Attachment of Auxiliary Classes vs. DNs
For a general discussion of attachment of auxiliary classes and the
pros and cons of doing so, see [PCIM]. QoS policy reusable objects
should be stored in the appropriate repository. These objects will be
referred to by DNs. Objects that are not reusable should, if possible,
be attached to other classes for efficiency.
Attachment allows a more efficient LDAP data retrieval operation. See
[PCIM].
4.2.2. Multiple Attachment
Attaching more than one auxiliary class to a single structural object
is allowed. This type of usage is recommended when defining efficient
conditions and actions as part of the policy rule itself. For example,
a ondition that includes a simple condition, variable and one or more
values can be attached to the policyRuleConditionAssociation entry.
In this example, this method enables the various components that make
up the condition to be retrieved in a single operation.
Snir, Ramberg, Strassner, Cohen expires September 2000 11
Draft-ietf-policy-qos-schema-00.txt March 2000
4.2.3. Auxiliary Classes - When and How They Should Be Used
Auxiliary objects must be attached to a structural class to be
instantiated. There are 3 ways of using these objects.
4.2.3.1. Attach to policyInstance, policyConditionInstance and
policyActionInstance Class
Whenever an auxiliary class should be instantiated so that it can be
reused, it must be attached to a policyInstance, a
policyConditionInstance or a policyActionInstance object. These classes
not only allow instantiation of an auxiliary class but also make it a
named instance that could be placed under a policy repository namespace
and reused. For example, a reusable qosPolicySimpleCondition is
attached to an instance of the policyConditionInstance which is placed
in the repository.
4.2.3.2. Attach Specific Containers to Root Objects
Some auxiliary classes are attached to the appropriate structural
classes defined in the Core Policy Schema. Among such classes are the
PolicyGroupContainmentAuxClass, which is used to associate
qosPolicyDomain objects to, for example, other objects extending the
PolicyGroup class. This type of association is to be used when general
aggregation by DIT location can't be used. For example a PolicyGroup
object that serves as a policy root could contain two qosPolicyDomain
objects as direct children and one which is not located as a child of
the PolicGroup object. This is referenced using the
PolicyGroupContainmentAuxClass. This structure defines 3 domains under
the policy root.
4.2.3.3. Attach to an Object for Efficient LDAP Retrieval
4.2.3.3.1. Attaching qosPolicySimpleCondition to
policyRuleConditionAssociation
A policyRuleConditionAssociation includes a single condition, either by
attachment or by DN reference. Using attachment allows the retrieval of
the association class and the condition itself in a single LDAP search.
4.2.3.3.2. Attaching QoS Policy Action Classes to
policyRuleActionAssociation
A policyRuleActionAssociation includes a single action, either by
attachment or by DN reference. Using attachment allows the retrieval of
the association class and the action itself in a single LDAP search
Snir, Ramberg, Strassner, Cohen expires September 2000 12
Draft-ietf-policy-qos-schema-00.txt March 2000
4.2.3.3.3. Attaching qosPolicyVariable and qosPolicyValue Extensions to
qosPolicySimpleCondition
A qosPolicySimpleCondition includes a single qosPolicyValue and a
single qosPolicyVariable. Each can either be attached or referenced by
a DN. Using attachment allows the retrieval of the association class
and the condition itself in a single LDAP search
4.2.3.3.4 Extensions for Complex Policy Rules
Construction of a complex policy rule is done by building on the
techiques used to assemble simple policy rules. A complex policy can
consist of multiple condition and/or action terms. Each of these terms
can be built using the techniques described in the previous sections.
For example, it is recommended that a qosPolicySimpleCondition object
be constructed through the attachment of qosPolicyVariable and
qosPolicyValue auxiliary classes. This can then be used to build
conditions that are part of the complex policy.
The exception to this rule is when one or more of these objects are
reusable (e.g., not specific to a single policy, and therefor are
resident in the reusable-objects repository). In this case, the object
should not be attached, but a DN reference to the object should be used
instead.
5. LDAP Search Efficiency
The ability to efficiently search for policy rules is important.
Writers of policy elements should follow a few basic rules in order to
allow readers of policy to do this efficiently, with a minimum of LDAP
queries.
5.1. Reusable Objects
Reusable objects are located in the repository sub-trees. Each reusable
object is a child of the parent folder it belongs to. The parent folder
defines a namespace that the objects that it contains are bound to.
5.2. NamedGroupContainer Location
NamedGroupContainers are defined as direct children of their domain
entry. These containers enable more specific behavior to be applied to
a set of policies that are of a particular type. For example, a policy
domain can define general traffic conditioning policy rules, which can
then be specialized (e.g., subclassed) to suit the needs of particular
users or applications.
Snir, Ramberg, Strassner, Cohen expires September 2000 13
Draft-ietf-policy-qos-schema-00.txt March 2000
5.3. QoS Policy Rules Location
QoS policy rules are defined as children of a particular
qosNamedPolicyContainer entry. This class is used to contain different
administrative policies for a specific set of applications or users.
For example, a qosNamedPolicyContainer can be used to define common
handling for a particular type of flow.
5.4. Qos Policy SubRules Location
A QoS policy SubRule is a rule that is contained in another rule. This
concept is not defined in the core schema, and is specific to this QoS
schema. SubRule entries are defined as children of a particular policy
rule that is more general in usage and/or scope.
5.5. Condition and Action Object Location
Condition and action objects are either located in the
relevant repository (if they are reusable objects) or are defined as
children of the specific policy rule that uses them.
5.6. Searching for QoS Policy Objects
Readers of policies will assume that the above rules of entry location
are implemented by applications that write these results. Readers will
most likely perform LDAP sub-tree searches. The readers are responsible
for validating the completeness and consistency of the policy retrieved
by checking that every entry exists, as specified by the relevant
container values.
The Policy Core Schema [PFSCHEMA] has been constructed in such a way as
to enable the efficient location of policy information. This is done in
two ways. First, by designating a special section of the DIT as the
repository for policy information, two important benefits are gained.
First, efficient search and retrieval of policy information is enabled
by searching in a specific subtree.
Second, this enables reusable policy elements (e.g., conditions and
actions) to be stored in a single location in the DIT. So, instead of
having to find instances of a policy class throughout the DIT without
any knowledge of where those instances can be located, one can instead
use the policy repository to define a common location.
The second method of organizing policy information is through the use
of auxiliary classes to "tag" an object as being related to policy.
Both of these methods are described in more detail in [PFSCHEMA].
Snir, Ramberg, Strassner, Cohen expires September 2000 14
Draft-ietf-policy-qos-schema-00.txt March 2000
6. Data Integrity
LDAP provides little if any support for data integrity protection. The
only guarantee provided by LDAP-based systems is that operations on a
single object instance are "atomic". This means that complex schemata
such as the QoS Policy schema can't guarantee atomicity of multi-step
operations. Note that even reading is not safe: no read consistency is
guaranteed whatsoever.
While there are various tactical solutions, a general schema may not
rely on the guarantees of any particular directory product that are
beyond the LDAP protocol standard specification, as such guarantees are
proprietary and not supported by all products.
This section discuss the problems associated with data integrity,
consistency, concurrency control and transaction handling involved in
using the QoS Policy Schema classes, and suggests several approaches to
tactical solutions. However, no attempt is made to provide a general
strategy to the inherent weaknesses in LDAP.
6.1. Order of Insertion of Objects into the Directory Service
Objects should be placed in the directory server in a particular order
to minimize risks of lost updates due to client or server abnormal
termination. In general, referred objects should be placed in the DIT
prior to the placement of its DN in the referring object. For example,
a policy action object (e.g., an instance of the qosPolicyAction class)
should be fully initialized and placed in the DIT before its DN is
added to the policyActionDN attribute of the instance of the
policyRuleActionAssociation class. Doing it in the opposite order (i.e.
, inserting a DN of the qosPolicyAction instance in the
policyRuleActionList attribute before placing the action object in the
DIT) may result in a "dangling" DN (i.e., a DN that points to nothing).
A failure in the modify process may happen if the client machine fails
to complete its modify operations because it crashes before the second
operation completes successfully. The result of this is that the DN
doesn't point at a real instance.
The insertion ordering tactics comes at a price. For example, the
semantics necessary for an object that refers to another object require
that the referring and referred objects be placed in the directory such
that the referring object is the parent of the referred object.
Obviously, no child DN exists before the parent is placed in the DIT.
In such a case, one is tempted to write the parent object, thus
creating the node in the DIT, and then write the child object. However
, an abnormal termination of either the client or the LDAP server
before the operation of placing the child in the DIT results in a
dangling child DN reference in the parent. To prevent this, one must
pay the price of an extra write operation: First, write the parent with
no reference to the child. Next, write the child to the correct DIT
placement. Finally, modify the parent to point to the child. It is the
responsibility of the writing client to eliminate cases of dangling
references.
Snir, Ramberg, Strassner, Cohen expires September 2000 15
Draft-ietf-policy-qos-schema-00.txt March 2000
6.2. Distinguishing between Reusable Objects in the Repository and Rule
-Specific Objects
Reusable objects SHOULD be instantiated in the repository part of
the DIT. Data integrity of the DIT relies on the location of the
objects. When a change is made to a reusable object, located in the
repository, no other action is required to insure that the modification
is reflected in all referring objects (policies). If a reusable object
is not placed in the repository, each change made to that object
requires a complete scan of the DIT to make the change to each copy.
6.3. Versioning of Objects
Adding meta information to objects, such as creation / modification
time, version and other application-specific information will allow
implementation of application-specific validation, data integrity
checking and enforcement. Discussion of these techniques is beyond the
scope of this document.
6.4. Transaction Support
No transaction support is defined in LDAPv3. Implementation of the QoS
Policy Schema SHOULD assume that none is available and define their use
of the DIT by relying solely on the single entry atomic operation LDAP
supplies.
6.5. Data Integrity in Replicated Directories
Replication of information brings up data integrity, referential
integrity, and concurrency control issues. These issues are not related
specifically to the QoS Policy Schema (e.g., the QoS Policy Schema does
not make things worse) and are beyond the scope of this document.
When updating a DN to a referred object, that object version should be
checked to make sure that it exists and the object is of the right
version. It is also recommend that schema checking be turned on in the
server.
Snir, Ramberg, Strassner, Cohen expires September 2000 16
Draft-ietf-policy-qos-schema-00.txt March 2000
7. Summary of QoS Policy Class Relationships
All of the classes in the LDAP QoS Policy Schema map directly to
corresponding classes in the QoS Policy Information Model [QOSIM]. The
following table summarizes these relationships:
+--------------------------------+-------------------------------+
| Information Model Relationship | LDAP Attribute / Class |
+--------------------------------+-------------------------------+
| qosPolicyDomain to | DIT containment |
| policyRepository | |
+--------------------------------+-------------------------------+
| qosPolicyDomain to | DIT containment or |
| qosNamedPolicyContainer to | policyGroupsAuxContainedSet |
| policyGroup | property of |
| | policyGroupContainmentAuxClass|
+--------------------------------+-------------------------------+
| qosNamedPolicyContainer to | DIT containment or |
| policyRule | policyRulesAuxContainedSet |
| | property of |
| | PolicyRuleContainmentAuxClass |
+--------------------------------+-------------------------------+
| policyRule to | |
| policyRuleConditionAssociation | DIT containment |
+--------------------------------+-------------------------------+
| policyRuleConditionAssociation | Attachment or |
| to qosPolicySimpleCondition | policyConditionDN property of |
| | policyRuleConditionAssociation|
+--------------------------------+-------------------------------+
| qosPolicySimpleCondition to | Attachment or |
| qosPolicyIPv4AddrValue | qpValueAtom property of |
| | qosPolicySimpleCondition |
+--------------------------------+-------------------------------+
| qosPolicySimpleCondition to | Attachment or |
| qosPolicyIPv6AddrValue | qpValueAtom property of |
| | qosPolicySimpleCondition |
+--------------------------------+-------------------------------+
| qosPolicySimpleCondition to | Attachment or |
| qosPolicyMACAddrValue | qpValueAtom property of |
| | qosPolicySimpleCondition |
+--------------------------------+-------------------------------+
| qosPolicySimpleCondition to | Attachment or |
| qosPolicyStringValue | qpValueAtom property of |
| | qosPolicySimpleCondition |
+--------------------------------+-------------------------------+
| qosPolicySimpleCondition to | Attachment or |
| qosPolicyBitStringValue | qpValueAtom property of |
| | qosPolicySimpleCondition |
+--------------------------------+-------------------------------+
(table is continued on the next page)
Snir, Ramberg, Strassner, Cohen expires September 2000 17
Draft-ietf-policy-qos-schema-00.txt March 2000
(table is continued from the previous page)
+--------------------------------+-------------------------------+
| qosPolicySimpleCondition to | Attachment or |
| qosPolicyDNValue | qpValueAtom property of |
| | qosPolicySimpleCondition |
+--------------------------------+-------------------------------+
| qosPolicySimpleCondition to | Attachment or |
| qosPolicyAttributeValue | qpValueAtom property of |
| | qosPolicySimpleCondition |
+--------------------------------+-------------------------------+
| qosPolicySimpleCondition to | Attachment or |
| qosPolicyIntegerValue | qpValueAtom property of |
| | qosPolicySimpleCondition |
+--------------------------------+-------------------------------+
| policyRule to | |
| policyRuleActionAssociation | DIT containment |
+--------------------------------+-------------------------------+
| policyRuleActionAssociation | Attachment or |
| to qosPolicyPRAction | policyActionDN property of |
| | policyRuleActionAssociation |
+--------------------------------+-------------------------------+
| policyRuleActionAssociation | Attachment or |
| to qosPolicyRSVPAction | policyActionDN property of |
| | policyRuleActionAssociation |
+--------------------------------+-------------------------------+
| qosPolicyPRAction to | Attachment or |
| qosPolicyPRTrfcProf | qpTrfcProf property of |
| | qosPolicyPRAction |
+--------------------------------+-------------------------------+
| qosPolicyPRAction to | Attachment or |
| qosPolicyMeter | qpMeter property of |
| | qosPolicyPRAction |
+--------------------------------+-------------------------------+
| qosPolicyRSVPAction to | Attachment or |
| qosPolicyRSVPTrfcProf | qpTrfcProf property of |
| | qosPolicyRSVPAction |
+--------------------------------+-------------------------------+
| qosPolicyRSVPAction to | Attachment or |
| qosPolicyRSVPInstallAction | qpInstallAction property of |
| | qosPolicyRSVPAction |
+--------------------------------+-------------------------------+
| qosPolicyRSVPAction to | Attachment or |
| qosPolicyRSVPSignalCtrlAction| qpSignalCtrlAction property of|
| | qosPolicyRSVPAction |
+--------------------------------+-------------------------------+
(table is continued on the next page)
Snir, Ramberg, Strassner, Cohen expires September 2000 18
Draft-ietf-policy-qos-schema-00.txt March 2000
(table is continued from the previous page)
+--------------------------------+-------------------------------+
| qosPolicyRSVPAction to | Attachment or |
| qosPolicyMeter | qpMeter property of |
| | qosPolicyRSVPAction |
+--------------------------------+-------------------------------+
| policyInstance to | Attachment |
| qosPolicyPRTrfcProf | |
+--------------------------------+-------------------------------+
| policyInstance to | Attachment |
| qosPolicyRSVPTrfcProf | |
+--------------------------------+-------------------------------+
Table 1. Relationship between classes defined in this draft and [QOSIM]
8. Class Definitions
This section contains the class and attribute definitions for this
schema. All class and attribute definitions for classes that are
defined in the QoS Policy Information Model [QOSIM] are noted here
but defined in [QOSIM] to facilitate ease of reference.
8.1. Class qosPolicyGroup
This class represents the root of the subtree that contains QoS policy
information. The qosPolicyGroup object contains the references to the
repositories that it uses and to the policy definition information that
it needs to represent policies.
This class is defined in [QOSIM].
8.2. Class policyRepository
This class represents the root (i.e., the top of the subtree) of the
QoS policy repository. The policyRepository object contains the DNs
of the specific repositories that contain reusable policy information.
This class is defined in [PCIM].
8.3. Class qosRepositoryContainmentAuxClass
This auxiliary class provides a single, multi-valued attribute that
points to a set of QoS policy repositories. By attaching this attribute
to instances of various other classes, a policy administrator has a
flexible way of providing an entry point into the directory that allows
a client to locate and retrieve the policy repositories relevant to it.
This provides the ability to have different repositories in two
different roots of the same DIT. This class is defined in [QOSIM].Snir,
Ramberg, Strassner, Cohen expires September 2000 19
Draft-ietf-policy-qos-schema-00.txt March 2000
8.4. Class qosPolicyDomain
This class defines 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 may have a potentially different set of
policies, access rules, decision strategy or other application of the
policy information organized in some fashion (which is represented by
the domain) that reflects distinct administrative control (compared to
the rest of the DIT). The policyGroup object points to a subtree in the
DIT that contains policy information, and each qosPolicyDomain object
points to a specific subsection of that subtree that contains
specialized policy information. The class definition is as follows:
NAME qosPolicyDomain
DESCRIPTION A class that is the root of an administrative
QoS policy domain, which resides in the
policyGroup container. It contains a group of
named policy containers.
DERIVED FROM policyGroup (defined in [PCIM])
TYPE Structural
AUXILIARY CLASSES PolicyGroupContainmentAuxClass,
policyRuleContainmentAuxClass,
policyElementAuxClass,
(all of these are defined in [PCIM]), qosPolicyElementAuxClass
(defined in this document)
OID
MUST
MAY qpDomainName, qpPHBSet
8.4.1. The Attribute qpDomainName
NAME qpDomainName
DESCRIPTION A user-friendly name of the QoS policy domain.
SYNTAX IA5String
OID
EQUALITY CaseExactIA5Match
MULTI-VALUED No
DEFAULT VALUE NULL
8.4.2. The Attribute qpPHBSet
NAME qpPHBSet
DESCRIPTION DN reference to the PHB set defined for the
domain.
SYNTAX DistinguishedName
OID
EQUALITY DistinguishedNameMatch
MULTI-VALUED YES
DEFAULT VALUE NULL
Snir, Ramberg, Strassner, Cohen expires September 2000 20
Draft-ietf-policy-qos-schema-00.txt March 2000
8.5. Class qosNamedPolicyContainer
This class represents an administrative policy rule container. All
policies serving a certain goal, servicing a certain type of
application, handling a certain type of flow or devices are
administrated in a particular qosNamedPolicyContainer. This enables
multiple levels of scoping to be applied: high-level policy aggregation
through the policyGroup or qosPolicyDomain classes, and finer-level
refinement of policies through instances of the qosNamedPolicyContainer
classes. The class definition is as follows:
NAME qosNamedPolicyContainer
DESCRIPTION A class that is a logical and physical
container of policies.
DERIVED FROM policyGroup (defined in [PCIM])
TYPE Structural
AUXILIARY CLASSES policyRuleContainmentAuxClass,
policyElementAuxClass
(these are both defined in [PCIM]),
qosPolicyElementAuxClass
OID
MUST qpPriority, qpPolicyRuleMatchMethod
MAY
8.5.1. The Attribute qpPriority
NAME qpPriority
DESCRIPTION The priority of a named group of rules in one
qosPolicyNamedContainer instance compared to other
qosPolicyNamedContainer instances. If two or
more qosPolicyNamedContainer objects have the
same priority, this means that the order
between these containers is of no importance,
but that they must each be evaluated before
other objects that have a numerically lower
priority.
SYNTAX Integer
OID
EQUALITY IntegerMatch
MULTI-VALUED No
DEFAULT VALUE NULL
8.5.2. The Attribute qpPolicyRuleMatchMethod
NAME qpPolicyRuleMatchMethod
DESCRIPTION The decision strategy to be applied on this set
of qos policy rules by policy servers.
SYNTAX Integer (ENUM)
{"FIRST MATCH " = 1; "MATCH ALL " = 2 }
OID
EQUALITY IntegerMatch
MULTI-VALUED No
DEFAULT VALUE 1
Snir, Ramberg, Strassner, Cohen expires September 2000 21
Draft-ietf-policy-qos-schema-00.txt March 2000
8.6. Class qosPolicyPRAction
This class defines DiffServ-specific actions to be applied on a flow,
including marking of DSCP value, policing and shaping. The class
definition is as follows:
NAME qosPolicyPRAction
DESCRIPTION A class that defines provisioning DiffServ
Traffic actions to be applied on a specific
flow or group of flows, if a certain rule's
condition is met.
DERIVED FROM policyActionAuxClass (defined in [PCIM])
TYPE Auxiliary
AUXILIARY CLASSES qosPolicyPRTrfcProf, qosPolicyMeter
OID
MUST
MAY qpDirection, qpSetDSCPvalue, qpMeter,
qpMeterScope, qpPRTrfcProf,
qpOutOfProfileAction,
qpOutOfProfileRemarkValue
8.6.1. The Attribute qpDirection
NAME qpDirection
DESCRIPTION this attribute defines the direction of the action
(e.g., the incoming or/and outgoing interfaces).
SYNTAX Integer (ENUM) {IN=0,OUT=1}
OID
EQUALITY IntegerMatch
MULTI-VALUED Yes
8.6.2. The Attribute qpSetDSCPvalue
NAME qpSetDSCPvalue
DESCRIPTION This attribute defines the DSCP value of the
mark action.
SYNTAX Integer
OID
EQUALITY IntegerMatch
MULTI-VALUED No
8.6.3. The Attribute qpMeter
NAME qpMeter
DESCRIPTION A DN reference to a qosPolicyMeter object used in
this provisioning action.
SYNTAX DistinguishedName
OID
EQUALITY DistinguishedNameMatch
MULTI-VALUED No
Snir, Ramberg, Strassner, Cohen expires September 2000 22
Draft-ietf-policy-qos-schema-00.txt March 2000
8.6.4. The Attribute qpMeterScope
NAME qpMeterScope
DESCRIPTION An integer that defines the scope of the metering
action.
SYNTAX Integer ENUM (flow=0,interface=1 device=2)
OID
EQUALITY IntegerMatch
MULTI-VALUED No
8.6.5. The Attribute qpTrfcProf
NAME qpTrfcProf
DESCRIPTION This attribute contains the DiffServ / provisioning
Policing instruction value, defined as a DN reference
to a qosPolicyTrfcProf entry.
SYNTAX DistinguishedName
OID
EQUALITY DistinguishedNameMatch
MULTI-VALUED No
8.6.6. The Attribute qpOutOfProfileAction
NAME qpOutOfProfileAction
DESCRIPTION The action to be applied to out of profile
packets, as defined in the DiffServPolicer entry.
SYNTAX Integer [ENUM] {SHAPE=0,DISCARD=1,REMARK=2}
OID
EQUALITY IntegerMatch
MULTI-VALUED No
8.6.7. The Attribute qpOutOfProfileNetstedAction
NAME qpOutOfProfileNestedAction
DESCRIPTION A DN reference of a qosPolicyPRAction to be applied
on out of band packets if the OutOfProfile action is
defined for this flow.
SYNTAX DistinguishedName
OID
EQUALITY DistinguishedNameMatch
MULTI-VALUED No
Snir, Ramberg, Strassner, Cohen expires September 2000 23
Draft-ietf-policy-qos-schema-00.txt March 2000
8.6.8. The Attribute qpOutOfProfileRemarkValue
NAME qpOutOfProfileRemarkValue
DESCRIPTION The DSCP value to be applied to out of profile
packets if the OutOfProfile action is defined
as REMARK.
SYNTAX Integer
OID
EQUALITY IntegerMatch
MULTI-VALUED No
8.7. Class qosPolicyRSVPAction
This class defines a policy action to be applied on RSVP signaling
messages that match the rule condition. The class definition is as
follows:
NAME qosPolicyRSVPAction
DESCRIPTION A class that defines an RSVP action to be
performed if a certain rule's condition is met.
DERIVED FROM policyActionAuxClass (defined in [PCIM])
TYPE Auxiliary
AUXILIARY CLASSES qosPolicyRSVPTrfcProf,
qosPolicyRSVPSignalCtrlAction,
qosPolicyRSVPInstallAction
OID
MUST
MAY qpDirection, qpRSVPMessageType, qpRSVPStyle, qpRSVPServiceType,
qpRSVPInstallAction, qpRSVPCtrlAction, qpMeter, qpMeterScope,
qpTrfcProf
8.7.1. The Attribute qpDirection
NAME qpDirection
DESCRIPTION This attribute defines the direction of the action(e.g.
,the incoming or/and outgoing interfaces).
SYNTAX Integer (ENUM) {IN=0,OUT=1}
OID
EQUALITY IntegerMatch
MULTI-VALUED Yes
8.7.2. The Attribute qpRSVPMessageType
NAME qpRSVPMessageType
DESCRIPTION This attribute defines the type of RSVP message to be
handled.
SYNTAX Integer (ENUM) { Path=0,Resv=1,ResvErr=2,PathErr=3}
OID
EQUALITY IntegerMatch
MULTI-VALUED Yes
Snir, Ramberg, Strassner, Cohen expires September 2000 24
Draft-ietf-policy-qos-schema-00.txt March 2000
8.7.3. The Attribute qpRSVPStyle
NAME qpRSVPStyle
DESCRIPTION This Property limits the scope of the action to be
enforced only on RSVP Requests with the specified
reservation style. The allowed styles are Shared
Explicit (SE), Fixed Filter (FF) and Wildcard Filter
(WF) as defined in [RSVP].
SYNTAX Integer (ENUM) {SE=0, FF=1, WF=2}
OID
EQUALITY IntegerMatch
MULTI-VALUED Yes
8.7.4. The Attribute qpRSVPServiceType
NAME qpRSVPServiceType
DESCRIPTION this Property limits the scope of the action to be
enforced only on RSVP Requests asking for specified
integrated service type.
SYNTAX Integer (ENUM)
{ControlledLoad =1 , GuaranteedService =2, NULL=3}
OID
EQUALITY IntegerMatch
MULTI-VALUED YES
8.7.5. The Attribute qpRSVPInstallAction
NAME qpRSVPInstallAction
DESCRIPTION A DN reference to a QosPolicyRSVPInstallAction object
used in conjunction with the RSVP reservation.
SYNTAX DistinguishedName
OID
EQUALITY DistinguishedNameMatch
MULTI-VALUED No
8.7.6. The Attribute qpRSVPCtrlAction
NAME qpRSVPCtrlAction
DESCRIPTION A DN reference to a qpRSVPCtrlAction object used in
conjunction with the RSVP reservation.
SYNTAX DistinguishedName
OID
EQUALITY DistinguishedNameMatch
MULTI-VALUED No
8.7.7. The Attribute qpMeter
NAME qpMeter
DESCRIPTION A DN reference to a qosPolicyMeter object used in this
RSVP action.
SYNTAX DistinguishedName
OID
EQUALITY DistinguishedNameMatch
MULTI-VALUED No
Snir, Ramberg, Strassner, Cohen expires September 2000 25
Draft-ietf-policy-qos-schema-00.txt March 2000
8.7.8. The Attribute qpMeterScope
NAME qpMeterScope
DESCRIPTION An integer that defines the scope of the metering
action.
SYNTAX Integer ENUM {flow=0,interface=1 device=2}
OID
EQUALITY IntegerMatch
MULTI-VALUED No
8.7.9. The Attribute qpTrfcProf
NAME qpTrfcProf
DESCRIPTION A DN list of references to RSVPTrfcProf objects that
define the desired RSVP action
SYNTAX DistinguishedName
OID
EQUALITY DistinguishedNameMatch
MULTI-VALUED No
8.8. Class qosPolicyPRTrfcProf
A provisioning traffic profile is used to define the policer or shaper
rate values to be enforced on a flow or a set of flows.
QosPolicyPRTrfcProfs may be implemented as reusable or rule-specific
objects; see [QOSIM] for more information.
The class definition is as follows:
NAME qosPolicyPRTrfcProf
DESCRIPTION A class that defines the policer or shaper rate
values to be enforced on a flow or a set of flows.
DERIVED FROM Policy (defined in [PCIM])
TYPE Auxiliary
AUXILIARY CLASSES
OID
MUST
MAY qpPRRate, qpPRNormalBurst,
qpPRExcessBurst
8.8.1. The Attribute qpPRRate
NAME qpPRRate
DESCRIPTION The token rate used for policing this flow or set of
flows. It is specified in units of bits/second. A
rate of zero means that all packets will be out
of profile.
SYNTAX Integer
OID
EQUALITY IntegerMatch
MULTI-VALUED No
Snir, Ramberg, Strassner, Cohen expires September 2000 26
Draft-ietf-policy-qos-schema-00.txt March 2000
8.8.2. The Attribute qpPRNormalBurst
NAME qpPRNormalBurst
DESCRIPTION The normal size of a burst measured in bytes
SYNTAX Integer
OID
EQUALITY IntegerMatch
MULTI-VALUED No
8.8.3. The Attribute qpPRExcessBurst
NAME qpPRExcessBurst
DESCRIPTION The excess size of a burst measured in bytes
SYNTAX Integer
OID
EQUALITY IntegerMatch
MULTI-VALUED No
8.9. Class qosPolicyRSVPTrfcProf
This class represents an IntServ RSVP traffic profile. Values of RSVP
policers are compared against the Traffic specification (TSPEC) and QoS
Reservation requests (RSPEC) carried in RSVP requests.
qosPolicyRSVPTrfcProf may be implemented as reusable or rule-specific
objects; see [QOSIM] for more information.
The class definition is as follows:
NAME qosPolicyRSVPTrfcProf
DESCRIPTION A class that defines rate limiting values for QoS
requests for a flow or a set of flow via RSVP
DERIVED FROM Policy (defined in [PCIM])
TYPE Auxiliary
AUXILIARY CLASSES
OID
MUST
MAY qpRSVPTokenRate, qpRSVPPeakRate,
qpRSVPBucketSize, qpRSVPResvRate, qpRSVPResvSlack, qpRSVPSessionNum,
qpMinPolicedUnit, qpMaxPktSize
8.9.1. The Attribute qpRSVPTokenRate
NAME qpRSVPTokenRate
DESCRIPTION Token Rate parameter, measured in bits/sec
SYNTAX Integer
OID
EQUALITY IntegerMatch
MULTI-VALUED No
Snir, Ramberg, Strassner, Cohen expires September 2000 27
Draft-ietf-policy-qos-schema-00.txt March 2000
8.9.2. The Attribute qpRSVPPeakRate
NAME qpRSVPPeakRate
DESCRIPTION Peak rate parameter, measured is bits/sec
SYNTAX Integer
OID
EQUALITY IntegerMatch
MULTI-VALUED No
8.9.3. The Attribute qpRSVPBucketSize
NAME qpRSVPBucketSize
DESCRIPTION Bucket Size, measured in bytes
SYNTAX Integer
OID
EQUALITY IntegerMatch
MULTI-VALUED No
8.9.4. The Attribute qpRSVPResvRate
NAME qpRSVPResvRate
DESCRIPTION Defines the RSVP Rate. This is the R-Spec parameter
in the RSVP Guaranteed service reservation. Measured
in bits/sec.
SYNTAX Integer
OID
EQUALITY IntegerMatch
MULTI-VALUED NO
8.9.5. The Attribute qpRSVPResvSlack
NAME qpRSVPResvSlack
DESCRIPTION Defines the RSVP Slack Termparameter in the RSVP
Guaranteed service reservation.
Measured in microseconds.
SYNTAX Integer
OID
EQUALITY IntegerMatch
MULTI-VALUED NO
8.9.6. The Attribute qpRSVPSessionNum
NAME qpRSVPSessionNum
DESCRIPTION The total number of allowed active RSVP sessions.
SYNTAX Integer
OID
EQUALITY IntegerMatch
MULTI-VALUED No
Snir, Ramberg, Strassner, Cohen expires September 2000 28
Draft-ietf-policy-qos-schema-00.txt March 2000
8.9.7. The Attribute qpMinPolicedUnit
NAME qpMinPolicedUnit
DESCRIPTION Defines the RSVP minimum policed unit, measured
in bytes.
SYNTAX Integer
OID
EQUALITY IntegerMatch
MULTI-VALUED NO
8.9.8. The Attribute qpMaxPktSize
NAME qpMaxPktSize
DESCRIPTION Defines the RSVP maximum allowed packet size,
measured in bytes.
SYNTAX Integer
OID
EQUALITY IntegerMatch
MULTI-VALUED NO
8.10. 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. This class can be
extended to support replacement of additional objects in RSVP messages,
beyond the replacement of the DCLASS and PREEMPTION objects that are
defined below.
An instance of this class SHOULD be attached to an object together with
an instance of the qosPolicyRSVPAction class.
NAME qosPolicyRSVPSignalCtrlAction
DESCRIPTION Actions modifying the behavior and content of RSVP
Signaling flows.
DERIVED FROM policyActionAuxClass (defined in [PCIM])
TYPE Auxiliary
AUXILIARY CLASSES
OID
MUST
MAY qpForwardingMode, qpSendError, qpReplaceDSCP,
qpReplacePreemptionPriority,
qpReplaceDefendingPriority
Snir, Ramberg, Strassner, Cohen expires September 2000 29
Draft-ietf-policy-qos-schema-00.txt March 2000
8.10.1. The Attribute qpForwardingMode
This attribute controls forwarding of RSVP messages. If the mode is set
to proxy, an RSVP Path messages is not forwarded and a Resv message is
returned as if the Resv was returned by the receiver.
NAME qpForwardingMode
DESCRIPTION Defines whether to forward or return RSVP signaling.
SYNTAX Integer (ENUM) {Forward=1 , Proxy=2}
OID
EQUALITY IntegerMatch
MULTI-VALUED No
8.10.2. The Attribute qpSendError
This attribute controls generation of Resv-Err and Path-Err messages
as defined in [COPSRSVP].
NAME qpSendError
DESCRIPTION Defines whether to send an RSVP error and warning
message.
SYNTAX Integer {No=0, Yes=1}
OID
EQUALITY IntegerMatch
MULTI-VALUED No
8.10.3. The Attribute qpReplaceDSCP
NAME qpReplaceDSCP
DESCRIPTION This attribute allows the replacement of a DCLASS
object carrying a DSCP value in an RSVP message.
SYNTAX Integer (ENUM) {0=REPLACE, 1=DON'T REPLACE}
OID
EQUALITY IntegerMatch
MULTI-VALUED No
8.10.4. The Attribute qpReplacePreemptionPriority
This attribute allows replacing or adding of preemption priority
[RSVP_PREEMP] objects to RSVP messages.
NAME qpReplacePreemptionPriority
DESCRIPTION A positive integer value specifying the preemption
priority that should be carried by RSVP messages.
SYNTAX Integer
OID
EQUALITY IntegerMatch
MULTI-VALUED No
DEFAULT VALUE 0
Snir, Ramberg, Strassner, Cohen expires September 2000 30
Draft-ietf-policy-qos-schema-00.txt March 2000
8.10.5. The Attribute qpReplaceDefendingPriority
This attribute allows replacing or adding of preemption priority
[RSVP_PREEMP] objects to RSVP messages.
NAME qpReplaceDefendingPriority
DESCRIPTION This attribute allows replacing or adding of
preemption priority [RSVP_PREEMP] objects to RSVP
messages. It specifies the defending priority within
the preemption object.
SYNTAX Integer
OID
EQUALITY IntegerMatch
MULTI-VALUED No
DEFAULT VALUE 0
8.11. Class qosPolicyRSVPInstallAction
This class extends the functionality of the qosPolicyRSVPAction class
by adding detailed control on COPS Install decisions [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 to set on the
flow RSVP is requesting QoS for.
This class should be extended when additional install decisions need to
be controlled.
An instance of this class SHOULD be attached to an object together with
an instance of the qosPolicyRSVPAction class.
The class definition is as follows:
NAME qosPolicyRSVPInstallAction
DESCRIPTION A class that defines actions to be
administered on a PEP.
DERIVED FROM policyActionAuxClass (defined in [PCIM])
TYPE Auxiliary
AUXILIARY CLASSES
OID
MUST
MAY qpSetDSCPValue, qpSetDefendingPriority qpSetPreemptionPriority,
Snir, Ramberg, Strassner expires April 2000 31
Draft-ietf-policy-qos-schema-00.txt January 2000
8.11.1. The Attribute qpSetDSCPValue
NAME qpSetDSCPValue
DESCRIPTION Defines the value the PEP must use to remark the flow
signaled by the RSVP request.
SYNTAX Integer
OID
EQUALITY IntegerMatch
MULTI-VALUED No
8.11.2. The Attribute qpSetDefendingPriority
This attribute allows setting the preemption priority [RSVP_PREEMP] of
RSVP flows.
NAME qpSetDefendingPriority
DESCRIPTION This attribute allows setting the preemption priority
[RSVP_PREEMP] of RSVP flows. It specifies the
defending priority within the preemption object.
SYNTAX Integer
OID
EQUALITY IntegerMatch
MULTI-VALUED No
DEFAULT VALUE 0
8.11.3. The Attribute qpSetPreemptionPriority
This attribute allows setting the preemption priority [RSVP_PREEMP] of
RSVP flows.
NAME qpSetPreemptionPriority
DESCRIPTION This attribute allows setting the preemption priority
[RSVP_PREEMP] of RSVP flows.
SYNTAX Integer
OID
EQUALITY IntegerMatch
MULTI-VALUED No
DEFAULT VALUE 0
Snir, Ramberg, Strassner expires April 2000 32
Draft-ietf-policy-qos-schema-00.txt January 2000
8.12. Class qosPolicySimpleCondition (Aux)
A simple condition is composed of a <Variable>, an <Operator>, and
<Value> triplet. The operator used in all definitions in this draft is
the 'match' operator. Such simple conditions are evaluated by answering
the question: Does <variable> match <value>? The operator attribute can
be extended to support other relations between variable and values;
however, this is beyond the scope of this draft.
Simple conditions are building blocks for more complex Boolean
conditions.
The qosPolicySimpleCondition is derived from the
policyConditionAuxClass class of the Core schema [PFSCHEMA].
QosPolicySimpleCondition is an auxiliary class. Simple conditions can
be kept in repositories for reuse. When kept in a directory, simple
conditions are attached to an instance of the policyConditionInstance
class. Otherwise, simple conditions are attached to an instance of the
policyRuleConditionAssociation structural class. For a complete
explanation of the use of simple conditions, see [QOSIM].
The class definition is as follows:
NAME qosPolicySimpleCondition
DESCRIPTION A class that represents a single Boolean condition. A
group of conditions make up a Boolean expression.
A simple condition is made of the triple
<Variable - relation - Value>
DERIVED FROM policyConditionAuxClass (defined in [PCIM])
TYPE Auxiliary
AUXILIARY CLASSES qosPolicyVariable, qosPolicyValue
NOTE: All classes derived from qosPolicyVariable and
qosPolicyValue defined below can be attached as well.
OID
MUST
MAY qpOperator, qpVariableAtom, qpValueAtom
8.12.1. The Attribute qpOperator
NAME qpOperator
DESCRIPTION The relation between a variable and a value, stored
in a directory entry.
SYNTAX DirectoryString
OID
EQUALITY CaseIgnoreString
MULTI-VALUED No
DEFAULT VALUE "match"
Snir, Ramberg, Strassner, Cohen expires September 2000 33
Draft-ietf-policy-qos-schema-00.txt March 2000
8.12.2. The Attribute qpVariableAtom
NAME qpVariableAtom
DESCRIPTION A reference to a variable, stored in a directory
entry
SYNTAX DistinguishedName
OID
EQUALITY DistinguishedNameMatch
MULTI-VALUED No
8.12.3. The Attribute qpValueAtom
NAME qpValueAtom
DESCRIPTION A reference to a value, stored in a directory entry
SYNTAX DistinguishedName
OID
EQUALITY DistinguishedNameMatch
MULTI-VALUED No
8.13. Class qosPolicyVariable
Variables are used for building individual conditions. 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. A source IP address variable can not be matched against a
value that specifies a port number. All variables have particular
syntaxes that select the set of values that can be matched.
A variable may also limit 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 in
the range of 0-65535. Integers outside this range can not be matched to
the 16 bits port entity.
The qosPolicyVariable class is an auxiliary class to allow attachment
of variables to policy conditions for efficient LDAP retrieval.
The class definition is as follows:
NAME qosPolicyVariable
DESCRIPTION A class that represents a single variable in a
Boolean condition
DERIVED FROM Policy (defined in [PCIM])
TYPE Auxiliary
AUXILIARY CLASSES
OID
MUST
MAY qpVariableName, qpValueTypes,
qpVariableDescription, qpValueConstraints
Snir, Ramberg, Strassner expires April 2000 34
Draft-ietf-policy-qos-schema-00.txt January 2000
8.13.1. The Attribute qpVariableName
NAME qpVariableName
DESCRIPTION A unique name for the variable.
SYNTAX IA5String
OID
EQUALITY CaseExactIA5Match
MULTI-VALUED No
Following is a table that defines the predefined Variable names and
their bindings. 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]. |
+-----------------+---------------------------------------------------+
| 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. |
+-----------------+---------------------------------------------------+
(table continuted on the following page)
Snir, Ramberg, Strassner, Cohen expires September 2000 35
Draft-ietf-policy-qos-schema-00.txt March 2000
(Table continued from the previous page)
+-----------------+---------------------------------------------------+
|Variable name | Logical binding |
+-----------------+---------------------------------------------------+
| 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
8.13.2 The Attribute qpValueTypes
This attribute 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.
NAME qpValueTypes
DESCRIPTION A list of class names of possible value types
that can be associated with this variable in a
condition
SYNTAX IA5String
OID
EQUALITY caseIgnoreIA5StringMatch
MULTI-VALUED Yes
Following is a table of variable names and their default allowed class
types.
+-----------------+---------------------------------------------------+
|Variable name | Allowed class types |
+-----------------+---------------------------------------------------+
| SourceIP | qosPolicyIPv4AddrValue, qosPolicyIPv6AddrValue |
+-----------------+---------------------------------------------------+
| SourcePort | qosPolicyIntegerValue |
+-----------------+---------------------------------------------------+
Snir, Ramberg, Strassner, Cohen expires September 2000 36
Draft-ietf-policy-qos-schema-00.txt March 2000
+-----------------+---------------------------------------------------+
| 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
8.13.3. The Attribute qpVariableDescription
NAME qpVariableDescription
DESCRIPTION A textual description of the variable
SYNTAX DirectoryString
OID
EQUALITY CaseIgnoreMatch
MULTI-VALUED No
8.13.4. The Attribute qpValueConstraints
NAME qpValueConstraints
DESCRIPTION A list of DNs of the objects serving
as constraints for this variable.
SYNTAX DistinguishedName
OID
EQUALITY DistinguishedNameMatch
MULTI-VALUED Yes
Snir, Ramberg, Strassner, Cohen expires September 2000 37
Draft-ietf-policy-qos-schema-00.txt March 2000
8.14. Class qosPolicyValue
This is an abstract class, and is used for defining values and
constants used in policy conditions. This class provides a common base
class for defining application-specific values. The following sections
describe some pre-defined subclasses of this class used to describe
commonly occurring values and constants used in DiffServ and RSVP
policies. The class definition is as follows:
NAME qosPolicyValue
DESCRIPTION This class is used as an abstract class for
defining values and constants used in policy
conditions
DERIVED FROM Policy (defined in [PCIM])
TYPE Abstract
AUXILIARY CLASSES
OID
MUST
MAY
8.15. Class qosPolicyIPv4AddrValue
This class is used to provide a list of IPv4Addresses and address range
values. The class definition is as follows:
NAME qosPolicyIPv4AddrValue
DESCRIPTION This class is used to define a list of IPv4
addresses and address range values
DERIVED FROM qosPolicyValue
TYPE Auxiliary
AUXILIARY CLASSES
OID
MUST
MAY qpIPv4AddrList
8.15.1. The Attribute qpIPv4AddrList
This attribute provides an unordered list of strings, each specifying a
single IPv4 address or a range of IPv4 addresses. The ABNF definition
[ABNF] of IPv4 address is:
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
IPv4prefix = IPv4address "/" 1*2DIGIT
IPv4range = IPv4address".."IPv4address
IPv4maskedaddress = IPv4address","IPv4address
Snir, Ramberg, Strassner, Cohen expires September 2000 38
draft-ietf-policy-qos-schema-00.txt March 2000
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 MUST follow guidelines and
restrictions specified in [NAMES].
Example: www.bigcompany.com
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
DESCRIPTION A list of IP addresses and IP address ranges.
SYNTAX IA5String
OID
EQUALITY caseIgnoreIA5Match
MULTI-VALUED Yes
FORMAT Ipv4address | hostname | Ipv4addressrange |
Ipv4maskedaddress | Ipv4prefix
8.16. Class qosPolicyIPv6AddrValue
This class is used to define a list of IPv6 addresses and address range
values. The class definition is as follows:
NAME qosPolicyIPv6AddrValue
DESCRIPTION This class is used to define a list of IPv6
addresses and IPv6 address range values.
DERIVED FROM qosPolicyValue
TYPE Auxiliary
AUXILIARY CLASSES
OID
MUST
MAY qpIPv6AddrList
Snir, Ramberg, Strassner, Cohen expires September 2000 39
Draft-ietf-policy-qos-schema-00.txt March 2000
8.16.1. The Attribute qpIPv6AddrList
This attribute provides an unordered list of strings, each specifying
an IPv6 address 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
Each string entry is either:
1. A single IPv6address as defined above.
2. A single Hostname. Hostname format MUST follow guidelines and
restrictions specified in [NAMES].
Example: www.bigcompany.com
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
DESCRIPTION A list of IPv6 addresses and IPv6 address ranges.
SYNTAX IA5String
OID
EQUALITY caseIgnoreIA5Match
MULTI-VALUED Yes
FORMAT IPv6address | hostname | IPv6addressrange |
IPv6maskedaddress | IPv6prefix
Snir, Ramberg, Strassner, Cohen expires September 2000 40
Draft-ietf-policy-qos-schema-00.txt March 2000
8.17. 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
DESCRIPTION This class is used to define a list of MAC
addresses and MAC address range values.
DERIVED FROM qosPolicyValue
TYPE Auxiliary
AUXILIARY CLASSES
OID
MUST
MAY qpMACAddrList
8.17.1. The Attribute qpMACAddrList
This attribute provides an unordered list of strings each specifying a
MAC address or a range of MAC addresses. 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
DESCRIPTION A list of MAC addresses and MAC address ranges.
SYNTAX IA5String
OID
EQUALITY caseIgnoreIA5Match
MULTI-VALUED Yes
FORMAT MACaddress | MACmaskedaddress
Snir, Ramberg, Strassner, Cohen expires September 2000 41
Draft-ietf-policy-qos-schema-00.txt March 2000
8.18. Class qosPolicyStringValue
This class is used to represent a single or set of string values.
The class definition is as follows:
NAME qosPolicyStringValue
DESCRIPTION This class is used to define a list of string
values with wildcards DERIVED FROM qosPolicyValue
TYPE Auxiliary
AUXILIARY CLASSES
OID
MUST
MAY qpStringList
8.18.1. The Attribute qpStringList
This attribute 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(i.e.,
zero or more characters). For example, the value "abc*def" matches
"abcxyzdef", and the value "abc*def*" match "abcxxxdefyyyzzz". The
syntax definition is identical to the substrig 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].
NAME qpStringList
DESCRIPTION A list of string values with wildcards
SYNTAX IA5String
OID
EQUALITY CaseIgnoreIA5Match
MULTI-VALUED Yes
8.19 Class qosPolicyBitStringValue
This class is used to represent a single or set of bit string values.
The class definition is as follows:
NAME qosPolicyBitStringValue
DESCRIPTION This class is used to define a list of bit
string values.
DERIVED FROM qosPolicyValue
TYPE Auxiliary
AUXILIARY CLASSES
OID
MUST
MAY qpBitStringList
Snir, Ramberg, Strassner, Cohen expires September 2000 42
Draft-ietf-policy-qos-schema-00.txt March 2000
8.19.1. The Attribute qpBitStringList
This attribute 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's most significant bit. The formal [ABNF]
definitions are:
binary-digit = "0" / "1"
bitstring = 1*binary-digit
maskedBitString = bitstring","bitstring
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 must 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
DESCRIPTION A list of bit string values
SYNTAX IA5String
OID
EQUALITY CaseIgnoreIA5Match
MULTI-VALUED Yes
FORMAT BitString | maskedBitString
8.20. Class qosPolicyDNValue
This class is used to represent a single or set of DN values, including
wildcards. This value can be used in comparison to DN values carried in
RSVP policy objects [IDENT].
The class definition is as follows:
NAME qosPolicyDNValue
DESCRIPTION This class is used to define a list of DN
values with wildcards.
DERIVED FROM qosPolicyValue
TYPE Auxiliary
AUXILIARY CLASSES
OID
MUST
MAY qpDNList
Snir, Ramberg, Strassner, Cohen expires September 2000 43
Draft-ietf-policy-qos-schema-00.txt March 2000
8.20.1. The Attribute qpDNList
This attribute provides an unordered list of strings, each representing
a Distinguished Name (DN) with wildcards. The format of a DN is defined
in [DNDEF]. The asterisk character ("*") is used as wildcard for either
a single attribute value or a wildcard for an RDN. The order of RDNs is
significant. For example: A qpDNList attribute carrying "OU=Sales, CN=*,
O=Widget Inc., *, C=US" matches: "OU=Sales, CN=J. Smith, O=Widget Inc,
C=US" and also matches "OU=Sales, CN=J. Smith, O=Widget Inc, C=US,
CN=CA".
NAME qpDNList
DESCRIPTION A list of DN string values with wildcards
SYNTAX IA5String
OID
EQUALITY CaseIgnoreIA5Match
MULTI-VALUED Yes
8.21. Class qosPolicyAttributeValue
This class is used to represent a single or set of attribute values.
The match operation used is dependent on the attribute name. This value
can be used in conjunction with DN values carried in RSVP objects
[IDENT]. The attribute name is used to specify a comparison between a
list of values and a specific set of attributes that the DN pointer is
referring.
For example, suppose a User class has a multi-valued attribute called
'member-of' that lists the names of groups this user belongs to.
Suppose this attribute uses caseIgnoreIA5Match matching. A simple
condition can be constructed to match the DN carried in an RSVP
Identity policy object to a qosPolicyAttributeValue with
qpAttributeName = "member-of" and qpAttributeList = "group-A". An
Identity policy object carrying a DN "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
DESCRIPTION This class is used to define an attribute and a
list of its values.
DERIVED FROM qosPolicyValue
TYPE Auxiliary
AUXILIARY CLASSES
OID
MUST
MAY qpAttributeName, qpAttributeValueList
Snir, Ramberg, Strassner, Cohen expires September 2000 44
Draft-ietf-policy-qos-schema-00.txt March 2000
8.21.1. The Attribute qpAttributeName
NAME qpAttributeName
DESCRIPTION This is the name of an attribute that the list
of values should be compared with
SYNTAX IA5String
OID
EQUALITY CaseIgnoreIA5Match
MULTI-VALUED No
8.21.2. The Attribute qpAttributeValueList
NAME qpAttributeValueList
DESCRIPTION A list of attribute values. Each value is
compared to a value of the attribute specified
by qpAttributeName.
SYNTAX IA5String
OID
EQUALITY CaseIgnoreMatch
MULTI-VALUED Yes
8.22. Class qosPolicyIntegerValue
This class provides a list of Integer and integer range values.
Integers of arbitrary size can be represented. For a given variable,
the set of possible range of integer values allowed is specified via
the variable's qpValueConstraints attribute.
The class definition is as follows:
NAME qosPolicyIntegerValue
DESCRIPTION This class is used to define Integer values
DERIVED FROM qosPolicyValue
TYPE Auxiliary
AUXILIARY CLASSES
OID
MUST
MAY qpIntegerList
8.22.1. The Attribute qpIntegerList
This attribute provides an unordered list of integers and integer range
values.
The format of the attribute 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.
Snir, Ramberg, Strassner, Cohen expires September 2000 45
Draft-ietf-policy-qos-schema-00.txt March 2000
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 also be expressed.
NAME qpIntegerList
DESCRIPTION
SYNTAX IA5string
OID
EQUALITY caseIgnoreIA5Match
MULTI-VALUED YES
FORMAT integer | integerrange
8.23. Class qosPolicyPHBSet
The qosPolicyPHBSet is an auxiliary class that serves as a named
container for qosPolicyPHB objects. A single PHB set is associated
(i.e., referenced) with a QoS domain using the domain attribute 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 attribute or by attachment of a qosPolicyPHBSet
object.
NAME qosPolicyPHBSet
DESCRIPTION This class defines a set of PHB definitions
DERIVED FROM policy (defined in [PCIM])
TYPE auxiliary
AUXILIARY CLASSES
OID
MUST
MAY
8.24. Class qosPolicyPHB
The qosPolicyPHB Class is an abstract class extending the Policy class,
which is intended to be extended with the information required to model
a PHB service class. The PHB service class is an abstraction over
device-specific parameters.
The class definition is as follows:
NAME qosPolicyPHB
DESCRIPTION This class defines a single service class in a
PHB set.
DERIVED FROM Policy (defined in [PCIM])
TYPE abstract
AUXILIARY CLASSES
OID
MUST
MAY qpDSCP
Snir, Ramberg, Strassner, Cohen expires September 2000 46
Draft-ietf-policy-qos-schema-00.txt March 2000
8.24.1. The attribute qpDSCP
NAME qpDSCP
DESCRIPTION An integer in the range 0..63, representing the
service classes in the domain that are used for
classification.
SYNTAX Integer
OID
EQUALITY IntegerMatch
MULTI-VALUED No
8.25. Class qosPolicyElementAuxClass
This class introduces no additional attributes, beyond those defined in
the class "PolicyElementAuxClass" from which it is derived. Its role
is to "tag" an instance of a class defined outside of the set of policy
containers that the policy system uses as being nevertheless relevant
to a QoS policy specification. This tagging can potentially take place
at two levels:
o Every instance to which qosPolicyElementAuxClass is attached
becomes an instance of the class "policy", since the
policyElementAuxClass is a subclass of "policy". Thus, a DIT
search with the filter "objectClass=policy" will return the
instance. (As noted earlier, this approach does not work for some
directory implementations. To accommodate these implementations,
policy-related entries SHOULD be tagged with the keyword
"POLICY", and the search modified to search instead for the
attribute "POLICY".)
o With the policyKeywords attribute that it inherits from "policy",
an instance to which policyElementAuxClass is attached can be
tagged as being relevant to a particular type or category of
policy, using standard keywords, administrator-defined keywords,
or both.
NAME qosPolicyElementAuxClass
DESCRIPTION An auxiliary class used to tag instances of
classes defined outside the realm of qos policy as
relevant to a particular policy specification.
DERIVED FROM policyElementAuxClass (defined in [PCIM])
TYPE Auxiliary
AUXILIARY CLASSES
OID
MUST
MAY
Snir, Ramberg, Strassner, Cohen expires September 2000 47
Draft-ietf-policy-qos-schema-00.txt March 2000
9. Extending the QoS Policy Schema
The following subsections provide general guidance on how to create a
domain-specific schema derived from the QoS Policy Schema by deriving
specific classes from the QoS Policy Schema.
9.1. Extending qosPolicyValue
The qosPolicyValue class and its subclasses describe the common value
types used in defining QoS policies. When other specific value types
are required, such as a floating-point number, the required class
should be derived from the qosPolicyValue class and an attribute that
contains the corresponding value should be added. Note that in many
cases, using the attribute value class allows the definition of
non-standard policy atoms without extending the qosPolicyValue class.
9.2. Extending qosPolicySimpleCondition
Policy condition describes 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 the
qosPolicySimpleCondition class as the superclass. Notice that the
qosPolicySimpleCondition class is an auxiliary class. This enables it
to be attached to the policyRule class instance. Any classes derived
from this class should also be auxiliary classes.
9.3. Extending qosPolicyAction
The Qos Policy action classes defined in the QoS Policy Schema includes
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.
In order to add other actions to a particular qosPolicyAction instance,
additional actions should be added to the qosPolicyAction by deriving a
new class and adding the appropriate attributes. Notice that the
qosPolicyAction is an auxiliary class in order to allow attachment to
the policyRule class instance. Any classes derived from this class
should also be auxiliary classes.
Snir, Ramberg, Strassner, Cohen expires September 2000 48
Draft-ietf-policy-qos-schema-00.txt March 2000
10. Security Considerations
See [PFSCHEMA]. This draft has the same security implications as does
the [PFSCHEMA] draft.
11. Acknowledgments
This document has benefitted from the comments and participation of
participants of the Policy Framework working group.
12. References
[TERMS] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", Internet RFC 2119, March 1997.
[PCIM] J. Strassner, E. Ellesson, B. Moore, "Policy Framework Core
Information Model",
draft-ietf-policy-core-info-model-00.txt
[PFSCHEMA] J. Strassner, E. Ellesson, B. Moore, "Policy Framework LDAP
Core Schema", draft-ietf-policy-core-schema-04.txt
[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
[LDAP_ATTR] M. Wahl, A. Coulbeck, " Lightweight Directory Access
Protocol (v3): Attribute Syntax Definitions", RFC 2252
[RSVP] Braden, R. ed., "Resource ReSerVation Protocol (RSVP) -
Functional Specification.", IETF RFC 2205,
Proposed Standard, Sep. 1997.
[RSVP_PREEMP] Shai Herzog, "Signaled Preemption Priority Policy
Element", RFC2751
[DIFF-SERV-ARCH] S. Blake D. Blake, "An Architecture for
Differentiated Services", RFC2475
[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>
[DEREF] R. Moats, J. Maziarski, J. Strassner, "Extensible Match
Rules to Dereference Pointer", Internet Draft
<draft-moats-ldap-dereference-match-02.txt>
Snir, Ramberg, Strassner, Cohen expires September 2000 49
Draft-ietf-policy-qos-schema-00.txt March 2000
[QOSCAP] J. Strassner, W. Weiss, D. Durham, A. Westerinen,
"Information Model for defining the QoS Capabilities of
Network Devices and Services", Internet Draft
<draft-ietf-policy-qos-capabilities-schema-00.txt>
[NAME] P. Mockapetris, " Domain names - implementation and
specification", RFC1035
[IPv6] R. Hinden, S. Deering, "IP Version 6 Addressing
Architecture", RFC2373, July 1998
[ABNF] Crocker, D., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, November
1997.
[DNDEF] Wahl, M., Kille, S., and T. Howes, "Lightweight
Directory Access Protocol (v3): UTF-8 String
Representation of Distinguished Names", RFC 2253,
December 1997.
[IDNET] S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore,
S. Herzog, "Identity Representation for RSVP", RFC2752,
January 2000
[QOSIM] Y. Snir, Y Ramberg, J. Strassner, R. Cohen "QoS Policy
Information model", internet draft
<qos-policy-info-model-00.txt>
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
170 West Tasman Drive, Building 15
San Jose, CA 95134
Phone: +1-408-527-1069
Fax: +1-408-527-2477
E-mail: johns@cisco.com
Snir, Ramberg, Strassner, Cohen expires September 2000 50
Draft-ietf-policy-qos-schema-00.txt March 2000
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 may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The derived value classes should be auxiliary so they can be
attached to the qosPolicyConstant class. This means that independent
instances of value classes can not be created.
Snir, Ramberg, Strassner, Cohen expires September 2000 51
| PAFTECH AB 2003-2026 | 2026-04-23 20:30:16 |