Policy Framework Y. Snir
Internet Draft Y. Ramberg
Expires April 2000 J. Strassner
R. Cohen
draft-ietf-policy-qos-info-model-00.txt Cisco Systems
January, 2000
Policy Framework QoS Information Model
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
This document presents an object-oriented information model for
representing network QoS policies. The QoS policy information model
refines the core policy information model presented in [PFCORE].
Specifically, this draft refines the concept of generic policy rules,
conditions and actions to cover extensions necessary for representing
QoS policies. This information model covers Differential Service QoS
enforcement, and Integrated Service QoS enforcement via policy
control on RSVP admission. A companion document [QoSSCHEMA] defines
the mapping of these classes to a directory that uses LDAPv3 as its
access protocol.
Snir, Ramberg, Strassner, Cohen expires September 2000 1
Draft-ietf-policy-qos-info-model-00.txt March 2000
Table of Contents
1. Introduction ...............................................5
2. Information model Hierarchy ................................5
3. Containment Hierarchy.......................................5
3.1. Containment Model ........................................6
3.2. QoS Domain Containment Hierarchy .........................7
3.2.1. Domain grouping and nesting ............................8
3.2.2. Resource sharing .......................................9
3.2.3. Placement ..............................................9
3.2.4. Named Policy Containers ...............................10
3.2.5. Policy rules ..........................................10
3.2.6. Conditions and Actions ................................11
3.2.7. Data tree example .....................................11
3.3. Reusable Objects Repositories ...........................12
3.4. Relationships between QoS Domains and repositories ......13
4. Constructing a QoS Policy Rule ............................13
4.1 Policy Rule Structure ....................................14
4.2 QoS Policy Condition .....................................14
4.2.1 Reusable vs. ad-hoc conditions .........................15
4.2.2. Using simple conditions ...............................16
4.2.3. Composing complex conditions ..........................16
4.3 Simple Condition operator ................................17
4.4. Variable ................................................17
4.4.1 Variable Binding .......................................18
4.4.2. Pre-defined Variables .................................18
4.5 QoS Policy Values ........................................21
4.6. PolicyTimePeriodCondition ...............................22
4.7. Actions .................................................22
4.7.1 Provisioning Actions ...................................22
4.7.2 Signaling Actions ......................................24
5. Decision strategy .........................................28
5.1. First match .............................................29
5.2. Match All ...............................................29
5.3. Decision Strategy example ...............................29
6. Per Hop Behavior ..........................................30
6.1. PHB .....................................................30
6.2. PHB Set .................................................31
7. QoS Policy Class Inheritance ..............................31
Snir, Ramberg, Strassner, Cohen expires September 2000 2
Draft-ietf-policy-qos-info-model-00.txt March 2000
8. Class definition ..........................................33
8.1. Class qosPolicyDomain ...................................33
8.1.1. The Property qpDomainName .............................33
8.1.2. The Property qpPHBSet .................................33
8.1.3. The Property qpPolicyRuleMatchMethod ..................33
8.2. Class qosNamedPolicyContainer ...........................33
8.2.1. The Property qpPriority ...............................34
8.2.2. The Property qpPolicyRuleMatchMethod ..................34
8.3. Class qosPolicyPRAction .................................34
8.3.1. The Property qpDirection ..............................35
8.3.2. The Property qpSetDSCPvalue ...........................35
8.3.3. The Property qpMeter ..................................35
8.3.4. The Property qpMeterScope .............................35
8.3.5. The Property qpPRTrfcProf .............................35
8.3.6. The Property qpOutOfProfileAction .....................35
8.3.7. The Property qpOutofProfileRemarkValue ................36
8.4. Class qosPolicyRSVPAction ...............................36
8.4.1. The Property qpDirection ..............................36
8.4.2. The Property qpRSVPMessageType ........................36
8.4.3. The Property qpRSVPStyle ..............................36
8.4.4. The Property qpRSVPServiceType ........................37
8.4.5. The Property qpRSVPInstallAction ......................37
8.4.6. The Property qpRSVPCtrlAction .........................37
8.4.7. The Property qpMeter ..................................37
8.4.8. The Property qpMeterScope .............................37
8.4.9. The Property qpRSVPTrfcProf ...........................37
8.5. Class qosPolicyPRTrfcProf ...............................38
8.5.1. The Property qpPRRate .................................38
8.5.2. The Property qpPRNormalBurst ..........................38
8.5.3. The Property qpPRExcessBurst ..........................38
8.6. Class qosPolicyRSVPTrfcProf ............................38
8.6.1. The Property qpRSVPTokenRate ..........................39
8.6.2. The Property qpRSVPPeakRate ...........................39
8.6.3. The Property qpRSVPBucketSize .........................39
8.6.4. The Property qpRSVPResvRate ...........................39
8.6.5. The Property qpRSVPResvSlack ..........................39
8.6.6. The Property qpRSVPSessionNum .........................39
8.6.7. The Property qpMinPolicedUnit .........................40
8.6.8. The Property qpMaxPktSize .............................40
8.7. Class qosPolicyRSVPSignalCtrlAction .....................40
8.7.1. The Property qpForwardingMode .........................40
8.7.2. The Property qpSendError...............................41
8.7.3. The Property qpReplaceDSCP ............................41
8.7.4. The Property qpPreemptionPriority .....................41
8.7.5. The Property qpDefendingPriority ......................41
8.8. Class qosPolicyRSVPInstallAction ........................41
8.8.1. The Property qpSetDSCPValue ...........................42
8.8.2. The Property qpSetDefendingPriority ...................42
8.8.3. The Property qpSetPreemptionPriority ..................42
Snir, Ramberg, Strassner, Cohen expires September 2000 3
Draft-ietf-policy-qos-info-model-00.txt March 2000
8.9. Class qosPolicySimpleCondition ..........................43
8.9.1. The Property qpOperator ...............................43
8.9.2. The Property qpVariableAtom ...........................43
8.9.3. The Property qpValueAtom ..............................43
8.10. Class qosPolicyVariable ................................44
8.10.1. The Property qpVariableName ..........................44
8.10.2 The Property qpValueTypes ...........................46
8.10.3. The Property qpVariableDescription ..................47
8.10.4. The Property qpValueConstraints ......................47
8.11. Class qosPolicyValue ...................................47
8.12. Class qosPolicyIPv4AddrValue ...........................48
8.12.1. The Property qpIPv4AddrList ..........................48
8.13. Class qosPolicyIPv6AddrValue ...........................49
8.13.1. The Property qpIPv6AddrList ..........................49
8.14. Class qosPolicyMACAddrValue ............................50
8.14.1. The Property qpMACAddrList ...........................50
8.15. Class qosPolicyStringValue .............................50
8.15.1. The Property qpStringList ............................51
8.16 Class qosPolicyBitStringValue ...........................51
8.16.1. The Property qpBitStringList .........................51
8.17. Class qosPolicyDNValue .................................52
8.17.1. The Property qpDNList ................................52
8.18. Class qosPolicyPropertyValue ...........................53
8.18.1. The Property qpPropertyName ..........................53
8.18.2. The Property qpPropertyValueList .....................53
8.19. Class qosPolicyIntegerValue ............................53
8.19.1. The Property qpIntegerList ...........................54
8.20. Class qosPolicyPHBSet ..................................54
8.21. Class qosPolicyPHB .....................................55
8.21.1. The Property qpDSCP ..................................55
8.22. Class qosPolicyElementAuxClass .........................55
9. Extending the QoS Policy Schema ...........................55
9.1. Extending qosPolicyValue ................................55
9.2. Extending qosPolicySimpleCondition ......................55
9.3. Extending qosPolicyAction ...............................55
10. Security Considerations ..................................56
11. Acknowledgments ..........................................56
12. References ...............................................56
13. Author's Addresses .......................................58
14. Full Copyright Statement .................................59
Snir, Ramberg, Strassner, Cohen expires September 2000 4
Draft-ietf-policy-qos-info-model-00.txt March 2000
1. Introduction
This document presents an object-oriented information model for
representing network QoS policies. The QoS policy information model
refines the core policy information model presented in [PFCORE].
Specifically, this draft refines the concept of generic policy rules,
conditions and actions to cover extensions necessary for representing
QoS policies. This information model covers Differential Service QoS
enforcement, and Integrated Service QoS enforcement via policy control
on RSVP admission. A companion document [QoSSCHEMA] defines the mapping
of these classes to a directory that uses LDAPv3 as its access
protocol.
The document presents high level QoS policies that can be used to
enforce consistent behavior across a network, regardless of the actual
vendor specific implementation details. The purpose of introducing a
standard information model and schema is to allow interoperability
between Policy Servers, Policy Management Applications, and Network
devices. A standard schema allows each of these components to be built
by different vendors, yet the final outcome of the QoS policies
enforced on the network will be identical.
The information model presented in this document contains information
that can be shared by other network policy managers, e.g. Security
managers, IP address managers, etc. Examples include sharing of the
same definition of well-known application port numbers, IP addresses of
servers and other network attributes. It allows checking of consistent
behaviors of the interaction between the different managers by
comparing for example the set of QoS and security actions enforced on
the same set of flows.
Representation of QoS capabilities of devices is described in a
companion draft [QoSCAPABLE]. It allows deduction of the set of
enforceable policies on each network device. Information model for
representation of PHBs is further elaborated in [PHBSET].
The remainder of this document presents, describes and defines the
concepts of the QoS Policy schema, its structure and organization, its
relationships to the Core schema and issues related to correct usage of
the schema.
2. Information model Hierarchy
This section discusses the hierarchy between the Core
information model, the QoS information model and future
extension of the QoS information model.
The Core Policy information model models high-level policy
concepts and introduces structural conventions and nomenclature
common to all types of policies. The QoS Policy schema refines
the concepts of the Core Schema and introduces a framework of
classes dedicated to model QoS Policies that can be used to
configure and manage RSVP and Differential service capable
Snir, Ramberg, Strassner, Cohen expires September 2000 5
Draft-ietf-policy-qos-info-model-00.txt March 2000
devices and services. The QoS information model provides
building blocks to control most of policy aspects, but it is
clear that not all knobs are provided. The core and QoS
information model are extensible. An implementation-specific
schema that is derived from this schema should further
concretize the QoS concepts of the QoS Policy schema.
3. Containment Hierarchy
In this section we describe the organization and structure of the
information model hierarchy.
The QoS Policy information model consists of two hierarchies: A policy
definition hierarchy and a reusable objects repository hierarchy. A
particular data tree may contain any number of instances of each
hierarchy. Section 3.1 explains the containment and reference model
used in the construction of QoS Policy data trees. Section 3.2
describes the particular containment hierarchy of the policy definition
entity, which is modeled by the QoSDomain class. Section 3.3 describes
the structure of the reusable objects repository. Further down (section
3.4) we explain the relationships between those entities.
3.1. Containment model
The QoS Policy Information Model employs containment model of [PFCORE].
The following paragraphs are a reminder and do not replace the detailed
definitions of [PFCORE].
The fundamental data model of the QoS Policy definition information
model is tree hierarchy. To describe the hierarchy of data in an actual
instance of model data we use the term 'data tree'. A data tree is
simply an arrangement of objects in a tree structure. The data tree
starts from a root object node. The root node may have several branch
nodes û these are just several objects placed "right below" the root.
The tree construction involves placing objects as leaves of other
objects while maintaining a strict tree structure.
The basic mechanism used for expressing containment is data tree
placement. To express the relationship of "container û contained"
between a container object and the objects it contains, the contained
objects are placed below the container object.
Certain elements of the QoS Information Model need a mechanism for an
entity to reference objects not on the same hierarchy as the
referencing entity. For example, QoS Policy rules (PolicyRule [PFCORE])
is a container of actions and conditions (PolicyCondition, PolicyAction
[PFCORE]). However, the information model should allow formation of
(complex) conditions (and actions) where some of the condition's
components are referenced remotely (e.g., a reusable simple condition)
must be referenced because it always resides on a hierarchy different
from the one where the referencing rule resides).
Snir, Ramberg, Strassner, Cohen expires September 2000 6
Draft-ietf-policy-qos-info-model-00.txt March 2000
To support a unified mechanism for containment of "local" and "remote"
objects, [PFCORE] introduces the notion of association classes. An
association class is an intermediate placeholder for a contained object
that may be a direct child of its container or a referenced remote
object. The relationships between the container object and its
contained element is then:
Container
|
|-- Association classes (containment by placement)
|
|-- local contained objects (packed inside the assoc.
| instances)
|
|-- remote contained objects (referenced by the assoc.
instances)
The association classes can (and do) carry the added semantics needed
by the information model. For example, internal order of contained
objects is information that can be carried on the association objects
themselves, making the containment model more flexible (same object may
be used by two containers but in a different position).
Refer to [PFCORE] for details of the association class mechanism.
3.2. QoS Domain Containment Hierarchy
The entity that represents a single policy hierarchy is called QOS
Domain and is modeled by the qosDomain class, which is a derivative of
the PolicyGroup class in [PFCORE].
Figure 1 shows a summary view of the QoS Domain containment hierarchy.
The text in parenthesis denotes object containment style: either
through data tree placement or through association classes.
+---------------+
|qosPolicyDomain| (root)
+-|-------------+
| +-----------------------+
-->|qosNamedPolicyContainer| (placement)
+-|---------------------+
| +-------------+
-->|policyRule| | (placement)
+-|-----------+
|
| +------------------------+
|-->|qosPolicySimpleCondition| (via association)
| +------------------------+
|
| +---------------+
|-->|qosPolicyAction| (via association)
+---------------+
Figure 1: Qos Domain containment hierarchy
Snir, Ramberg, Strassner, Cohen expires September 2000 7
Draft-ietf-policy-qos-info-model-00.txt March 2000
3.2.1. Domain grouping and nesting
QOS Domains may be grouped together to model multi-domain systems.
Grouping may be desired to enhance various administrative tasks and may
be required by a particular policy application. The grouping strategy
(as well as all location-oriented strategies) is left for users/vendors
to model based on their unique situation and requirement. This document
presents guidelines and recommendations for grouping QoS Domains but
specific implementations may use other techniques without violating the
integrity and consistency of the information model.
Grouping of QoS Domains can be done by creating a common root for
several QoS Domain data tree instances. One way for doing this is by
using the PolicyGroup [PFCORE] class as a root for the multi-domain
tree. In this case we just place several QoS Domain instances under the
root PolicyGroup instance.
Figure 2 is an example that depicts the ability to provide different
classes of service to different organizations within a single
enterprise. The different organizations are each represented by a
separate QoS policy domain (which is an instance of the qosPolicyDomain
class). Each qosPolicyDomain class is used as a container to hold all
of the policies of a given portion of the organization. In Figure 2
this level is represented by the nesting of qosPolicyDomain classes.
Each qosPolicyDomain instance serves as a container that contains an
ordered list of related QoS policy rule groups that apply to a
different parts or functions of the domain (e.g., Eastern Sales vs.
Western Sales). Each qosPolicyDomain contains a set of containers
(implemented as instances of the qosNamedPolicyContainer class) that
groups together QoS rules.
+----------------+
|qosPolicyGroup | <-------------------QoS policies for an enterprise
+--|-------------+
| +---------------+
-->|qosPolicyDomain| <--------------QoS policies for sales
+-|-------------+
| +---------------+
|-->|qosPolicyDomain| <--------QoS policies for Western Sales
| +-|-------------+
| | +-----------------------+
| |-->|qosNamedPolicyContainer| <--Qos Policies for group
| | +-----------------------+ A within Western Region
| | +-----------------------+
| -->|qosNamedPolicyContainer| <--Qos Policies for group
| +-----------------------+ B within Western Region
|
| +---------------+
-->|qosPolicyDomain| <--------QoS policies for Eastern Sales
+-|-------------+
(Figure continued in next page)
Snir, Ramberg, Strassner, Cohen expires September 2000 8
Draft-ietf-policy-qos-info-model-00.txt March 2000
(Figure continued from previous page)
| +-----------------------+
|-->|qosNamedPolicyContainer| <--Qos Policies for group
| +-----------------------+ C within Eastern Region
| +-----------------------+
-->|qosNamedPolicyContainer| <--Qos Policies for group
+-----------------------+ d within Eastern Region
Figure 2: Top-level policy data tree example
The modeling approach used in the previous example is but one possible
strategy among many. The information model allows for arbitrary nesting
of groups, thus providing the means for modeling both wide and deep
hierarchies.
3.2.2. Resource sharing
While different hierarchy instances are indifferent to each other (no
cross-referencing among QoS Domains), multiple QoS Domains may still
share data by means of references to reusable objects (residing in a
reusable objects repositories). The sharing of global or common
definition enhances the interoperability of various policy agents thus
serving the primary goal of this information model. Such commonly used
building blocks as important conditions (PolicyCondition) and actions
(PolicyAction) can be placed in the repository and used by policy
rules. The information model does not restrict the number of
repositories that can be referenced from a single QoS Domain. Even a
single instance of a policy rule (PolicyRule) may contain references to
objects residing in more than one repository. The information model
does not dictate a QoS Domain wide scope for reusable objects (there's
a many-to-many relationship between QoS Domains and reusable objects
repositories).
3.2.3. Placement
Intending to allow a flexible structure that does not pre-impose harsh
restriction on data tree constructors, the information model must not
contain a hidden assumption about placement of particular QoS Domains
hierarchies (including, for that matter, placement of repositories as
explained in section 3.3). Consequently, the information model does not
require a certain pre-defined location for the portion of the data tree
dedicated to policy. An instance of the global data tree (a corporate
directory, for example) may contain several QoS Domains hooked to the
tree in various places. Zero or more reusable objects repository may
also be present in the global data tree. The information model does not
dictate any standard organization of objects to be controlled via
policy. The only location/organizational rule that must be followed is:
Snir, Ramberg, Strassner, Cohen expires September 2000 9
Draft-ietf-policy-qos-info-model-00.txt March 2000
"Each QoS Domain must contain complete policy information either by
containment of objects or by containment of association objects. In
other words: Simple tree navigation and occasional reference chasing,
starting at the tree root (QoS Domain) must lead to all policy
definition objects needed to enforce the domain's policy."
3.2.4. Named Policy Containers
A QoS Domain is a container of (named) QoS Policy Containers, as
explained above. The information model class representing policy
containers is QoSNamedPolicyContainer, which extends the PolicyGroup
class of [PFCORE]. A (non-empty) policy container is an ordered list of
policy rules (PolicyRule [PFCORE]). The order of the rules inside their
container is interpreted as priority, where the top of the order is the
highest prioritized element. Section 4 describes PolicyRules.
As implied by the class name, each instance of a policy container must
be assigned a name that must be unique within its QoS Domain. A given
policy container must belong to (i.e.: contained in) a single QoS
Domain. Sharing of policy containers among QoS Domains is not
recommended because of the dependency of the decision strategy on the
relative priority within each domain.
The purpose of "dividing" a QoS Domain's policy rules among the
domains' policy containers provides a flexible framework for fine grain
administrative (or functional) structure. As the example shown in
figure 2, it makes sense to divide policies for the sales organization
into two regional containers: Western and Eastern. A change in policies
for the Eastern region does not have to effect the policies currently
in place for the Western region. Another policy system may take a
slightly different approach in modeling its policy structure by
assigning a different set of PHB's (see section 6) to different policy
container, thus modifying the interpretation of policies of each policy
container according to different specifications.
Each policy container is assigned a "match strategy", which is a name
of a method to interpret the order of its rules (see section 1.2.1.5).
For example, a FirstMatch strategy means that the rules will be
"matched" according to ascending order of their Priority attribute.
Decision strategy is explained in section 5.
Policy container can be nested. A policy container may contain policy
rules (PolicyRule [PFCORE]) or named policy containers. A particular
data tree, then, can be constructed as a deep hierarchy, if the
designers of the policy system deem it desirable.
3.2.5. Policy rules
Each named policy container holds a set of policy rules (or possibly
policy containers that contain policy rules). QoS policy rules are
modeled by the [PFCORE] class PolicyRule.
Snir, Ramberg, Strassner, Cohen expires September 2000 10
Draft-ietf-policy-qos-info-model-00.txt March 2000
The semantics of a policy rule is, in essence, a conditional imperative
statement in the form 'if <condition> then <action>'. Applying a rule
means to evaluate its condition and, depending on the truth value of
the condition, wither execute the action or move along (do nothing).
Evaluating a condition is known as 'matching the rule', an expression
we'll be using further down.
A given policy rule must belong to one (and only one) named
container.
This model is chosen because the units of reusability are the policy
condition and action terms that comprise a policy rule, as opposed to
the policy rule itself. A policy rule is a composite object, made up
from several objects (some reusable) and is viewed as a coherent
statement. It is believed that allowing a policy rule to belong to more
than one policy container would decrease its coherence. For example,
the rule itself is "aware" of its position inside its policy container,
so if we wanted to share a rule among many containers we'd have to
remove this knowledge from the rule. The notion of order of rules is so
essential to the concept of policy that removing it from the rule also
renders the rule less expressive, making policy modeling a more
difficult job. Furthermore, there are other important attributes that
are unique to the rule's specific placement inside the policy group
and/or the policy domain. For example, the DSCP values (section 6.)
that define how a flow is colored (which in turn define the set of QoS
actions that should be invoked by the rule) may be interpreted
differently in different QoS domains (or policy containers). These
examples show that the modeling of shared rules is inappropriate for
the QoS Policy information model.
The order of the rules inside a group is based on the value of the rule
priority attribute [PFCORE]. The enforcement of policy rules also
depends on particular settings belonging to the group. The match
strategy to be applied to the rules contained in this container is
defined in the policyRuleMatchMethod attribute of the
qosNamedPolicyContainer object.
3.2.6. Conditions and Actions
A policy rule is a composite object, as mentioned above. The most
important components of a rule are the conditions and actions it
contains. A condition is a Boolean expression that is evaluated to see
if the rule should be applied. An action is a specification of QoS
device configuration instruction that must be done if the rule is to be
applied.
Conditions and actions are discussed in detail [PFIM].
3.2.7. Data tree example
The following example illustrates the hierarchical nature of the QoS
Policy data tree. Each organizational entity is related to a specific
type of class, which is shown in parentheses.
Snir, Ramberg, Strassner, Cohen expires September 2000 11
Draft-ietf-policy-qos-info-model-00.txt March 2000
There are two domains in this example, grouped together under the same
root (domain grouping). The QoS Domains are:
1. EastCoast (qosPolicyDomain)
2. WestCost (qosPolicyDomain)
Each of these two QoS policy domains has its PHB set. The EastCoast
domain has 2 named policy containers. The first deals only with ERP
traffic and the second handles all other traffic:
1. EastCoast (qosPolicyDomain)
1.1. ERP (qosNamedPolicyContainer)
1.2. General (qosNamedPolicyContainer).
The WestCoast domain has 3 policy rule groups. The first deals only with
ERP flows, the second deals with VOIP, and the third with all other
traffic:
2. WestCoast
2.1. ERP (qosNamedPolicyContainer)
2.2. VOIP (qosNamedPolicyContainer)
2.3. General (qosNamedPolicyContainer).
Each one of the qosNamedPolicyContainer entries can contain a
prioritized rule set. For example, the WestCoast ERP group contains the
rules relevant to ERP applications administrated by the west coast
domain administrator.
We see from the above structure that this structure provides the
administrator with a great deal of flexibility. For example, similarly
named containers, represented by the ERP and General
qosNamedPolicyContainers, can reuse common policy conditions and
actions. However, they are implemented as physically different
containers to enable the administrator to administrate them
according to their own domain-specific needs.
3.3. Reusable Objects Repositories
Reusable objects are objects that can be referred to (hence "used by")
from other objects. The reference is accomplished by allocating an
attribute on the referencing object that contain the location of the
referenced object.
The concept of object repositories is introduced by [PFCORE] for the
purpose of allowing data tree constructors to share data among many
users as explained in section 1.2.1.2.
The following sections are merely a reminder of the mechanism for
modeling reusable objects repositories introduced in [PFCORE].
Snir, Ramberg, Strassner, Cohen expires September 2000 12
Draft-ietf-policy-qos-info-model-00.txt March 2000
A reusable objects repository hierarchy is rooted in an instance of the
PolicyRepository class [PFCORE]. Individual repositories are named
containers for reusable objects. Note that [PFCORE] allows arbitrary
nesting of repositories, thus a repository of repositories is a natural
modeling technique.
Each named repository is a container of "reusable objects". A reusable
object must have a unique name within the repository that container.
The complete containment model for the reusable objects repositories, as
well as detailed description of the various mechanisms for constructing
and maintaining such repositories are described in great detail in
[PFCORE].
Anywhere in the QoS Policy information model, where a reference to an
object can be made (a 'reference' type attribute), this reference may
point to a reusable object in a reusable objects repository.
Common candidates for reusability are named instances of these classes:
QoSPolicyVariable, QoSPolicyValue and its derivatives,
QoSPolicySimpleCondition, PolicyAction and its derivatives,
QoSPolicyPRTrfcProf, QoSPolicyRSVPTrfcProf and QoSPolicyPHBSet.
Throughout this document we point out the possible use of repository and
repository objects, wherever this is appropriate.
3.4. Relationships between QoS Domains and repositories
As explained above, a QoS Domain contains within it groups of policy
rules. A policy rule can contain ordered lists of conditions and
actions. The conditions and actions may be reusable object that reside
in reusable objects repositories.
Many references to reusable objects may be made from the rules of a
given QoS Domain. Those references need not be all poining to the same
repository; even e single rule may contain references to reusable
objects that reside in different repositories.
The maintenance of the policy system is made somewhat more complicated
due to the flexibility of the reference model. It is more difficult to
prevent "dangling" references to repositories that are no longer
present, for instance. Schema designers are encouraged to pay extra
attention to this problem and exercise any technique available from
their implementation platform to maintain integrity of their data trees.
[PFCORE] discusses this issue as well.
4. Constructing a QoS Policy Rule
A policy rule modeled in [PFCORE] represents the "If Condition then
Action" semantics associated with a policy. The policyRule class uses
the rule container class PolicyRuleInPolicyGroup to establish
Snir, Ramberg, Strassner, Cohen expires September 2000 13
Draft-ietf-policy-qos-info-model-00.txt March 2000
containment relationships between a policy rule and possible sub-rules,
modeled by the same PolicyRule class.
4.1 Policy Rule Structure
A policy rule has the following attributes [PFCORE]:
1. Enable flag.
2. A Boolean condition.
3. Ordered list of Actions.
4. Informational attributes.
The enable flag indicates whether a policy rule is administratively
enabled, administratively disabled, or enabled for debug mode. Only
enabled policy rules are enforced on the domain network.
The Boolean condition is used to evaluate if the set of actions should
be performed on a network flow by matching the network flow attributes
against the condition. A condition is composed from
qosPolicySimpleCondition conditions defined in this document and
PolicyTimePeriodCondition conditions [PFCORE]. The combination of
individual conditions in a policy rule is defined in [PFCORE] using
ConditionInPolicyRule class.
Each action in the list is modeled by an action derived from
PolicyAction. The ActionInPolicyRule class defines the order of which
policy actions are performed.
Informational attributes correspond to various meta-data used for
managing policy rules.
The interpretation of a policy rule in regard to a given network flow
may be expressed as follows:
"If the rule is enabled and the Boolean expression is evaluated to
TRUE, then use the Action list to extract the prescribed treatment for
this flow."
The rest of this section describes the components of the policyRule
class and their relationships to the other classes defined in this
schema.
4.2 QoS Policy Conditions
A policy rule modeled in [PFCORE] represents the "If Condition then
Action" semantics associated with a policy. A condition is represented
as either an ORed set of ANDed conditions or an ANDed set of ORed
conditions. Individual conditions may either be negated (NOT C) or
unnegated (C). The actions specified by a policy rule are to be
performed if and only if the policy rule condition evaluates to TRUE.
Many conditions in policy rules,
from a networking perspective, can be modeled as Filters. Filters are
Snir, Ramberg, Strassner, Cohen expires September 2000 14
Draft-ietf-policy-qos-info-model-00.txt March 2000
not modeled directly in either the QoS Policy schema or the core schema
(i.e., no Filter class is defined). However, the filter concept is
central in the QoS Policy data model, and is modeled in the Network
Model of DEN and used in the companion QoS capabilities draft [QoSCap].
The semantics of an individual condition is not specified in [PFCORE].
Conditions such as: "If the source IP address of the flow belongs to
10.1.x.x subnet" as well as "If the IP protocol number of the flow
equals TCP protocol number" are modeled in this document. Individual
conditions are modeled by the qosPolicySimpleCondition class using the
triplet <variable>, <operator> and <value>. The variable specifies the
attribute of a flow that should be matched when evaluating the
condition. A set of predefined variables that cover the basic network
attribute are introduced to foster interoperability. The list cover
layer 3 IP attribute such as IP network addresses, protocols and ports,
as well as a set of layer 2 attributes and higher level attributes such
as application and user identity. The variable is matched against a
value to produce the Boolean result. In the first example above, a
source IP address variable is matched against a 10.1.x.x subnet value.
The operator specifies the type of relation between the variable and
the value evaluated in the condition. Operators should model the
'belong to' and 'equal' relations in the examples above. In many cases,
a generic 'match' operator can be used, and the interpretation of the
relation between the variable and value is implied by the value itself.
For example, the variable source IP address can be matched to an IP
address, where the 'equal' relation is implied, to a hostname in which
the 'resolve to' relation is implied, or to a subnet address in which
'belongs to' relation is implied.
4.2.1 Reusable vs. ad-hoc conditions
This schema enables the reuse of simple conditions by placing them in a
common portion of the policy information tree (called the reusable-
objects repository). In order for a simple condition to be a member of
this repository, it must carry a name, as any reusable object
[PFCORE]).
A qosPolicySimpleCondition can either directly contain a value and a
variable, or can reference either one of them if they are kept in a
repository.
Simple condition composition must enforce the following type
conformance rules: The qpValueTypes property of the variable must be
compatible with the value class name.
The QoS information model defines four different ways to compose a
simple condition through the combination of representations of
variables and values. The following combinations of representing a
simple condition by references and containment are possible:
Snir, Ramberg, Strassner, Cohen expires September 2000 15
Draft-ietf-policy-qos-info-model-00.txt March 2000
Variable representation
1. The class qosPolicyVariable may be contained in the
qosPolicySimpleCondition instance.
2. The class qosPolicyVariable may be referenced from the
qosPolicySimpleCondition instance (Reusable variable)
Value representation
1. The qosPolicyValue class may be contained in the
qosPolicySimpleCondition class.
2. The qosPolicyValue class may be referenced from
the qosPolicySimpleCondition instance. This allows reusing the
qosPolicyValue object, which could be named and considered a named
constant.
4.2.2. Using simple conditions
In most cases, the use of the qosPolicySimpleCondition class is
sufficient for the definition of a condition for a policyRule. A simple
condition can be added to a policyRule in two ways:
1. A direct attachment of an instance of the simple condition to the
ConditionInPolicyRule instance. In this case we call this an "ad-hoc"
simple condition. This method allows the creation of a "private" simple
condition. This instance of the condition can't be referenced by any
other policy rule, and therefore is not reusable. However, since it
embeds the condition directly in the
ConditionInPolicyRule instance, it eliminates the extra access(es)
required to fetch each of the condition elements that are refernced by
pointers.
2. Use the simple condition list attribute, ContainedCondition
(defined in the ConditionInPolicyRule class) to point to a repository-
resident simple condition. This is called a reusable simple condition.
This method allows the sharing of simple conditions by multiple policy
rules.
4.2.3. Composing complex conditions
A complex condition consists of groups of simple conditions (i.e.,
instances of either the policySimpleCondition and/or the
qosPolicySimpleCondition classes) that are combined in either
conjunctive or disjunctive normal form (as defined in [PFCORE]).
A complex condition is modeled by the mechanism supplied in PFCORE
attributes:
Snir, Ramberg, Strassner, Cohen expires September 2000 16
Draft-ietf-policy-qos-info-model-00.txt March 2000
1. The ConditionListType attribute of the policyRule, which
is a boolean expression type (from the Core schema) that
defines whether the simple condition is in conjunctive or
disjunctive normal form.
2. The ConditionInPolicyRule class that defines whether the condition
is negated or not and what is the associated group of the boolean
expression this condition belongs to. For details see [PFCORE]
section 6.3.
4.3 Simple Condition operator
The QoS policy simple condition includes the qpOperator property,
specifiing the type of relation between the variable and the value
evaluated in the condition.
In many cases, a generic 'match' operator can be used, and the
interpretation of the relation between the variable and value is
implied by the value itself. For example, the variable source IP
address can be matched to an IP address, where the 'equal' relation is
implied, to a hostname in which the 'resolve to' relation is implied,
or to a subnet address in which 'belongs to' relation is implied.
The QoS Policy information model defines a single operator:
ômatchö that models the equal / belong to relationship.
4.4 QoS Policy Variable
QoS Policy Variables are used for building individual conditions, as
defined in section 4.2. The variable specifies the attribute of a flow
that should be matched when evaluating the condition.
Not every combination of a variable and a value creates a meaningful
condition. A source IP address variable can not be matched against a
value that specifies a port number. A given variable selects the set of
matchable value types, i.e. a value that could be compared and
evaluated to a Boolean expression.
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 property qpVariableName of the QosPolicyVariable class defines the
well-known name used for ligical binding of this variable.
The qpValueTypes is the list of value classes that could be matched to
this variable, for example the source port variable qpValueTypes
property will not include the QosPolicyIPv4AddrValue class for obvious
reasons, but will include the QosPolicyIntegerValue class name.
The qpValueConstraints will include a list of constraint on the
variable; I.e. values that the Variable must match.
In the above example the source port variable may include a constraint
reference to a value object defining the integer range 0..63535.
Snir, Ramberg, Strassner, Cohen expires September 2000 17
Draft-ietf-policy-qos-info-model-00.txt March 2000
4.4.1. Variable Binding
For the QoS Policy schema to be interoperable, different policy
management systems and policy servers must instantiate the same
variables with identical values (in the same evaluation operation).
While different policy servers may use a different binding mechanism,
the binding logic must result in an identical instantiation.
Each variable defined in the QoS policy repository must be bound to a
logical entity such as a specific field in the IP header, application
unique identifier or an application-specific parameter.
When a policy server attempts to evaluate an expression containing
variables, it must instantiate the variables. To instantiate a
variable, that variable must be bound to a specific value (or values,
depending on its type category) and associated with a logical entity.
For example, in the expression 'sourceport == 80', the variable
'sourceport' must be instantiated to a value and logically associated
with the packet header field containing the source port number, for the
expression to be evaluated.
If, in this example, the variable sourceport is bound to a value of
'80', then the expression is evaluated to TRUE for each packet that the
source port number in the IP header field equals 80. Otherwise it is
evaluated to FALSE.
4.4.2. Pre-defined Variables
The purpose of this section is to explain the need and define the
relationship of standard, frequently used variables with their logical
entities. Pre-defined variables are necessary for ensuring
interoperability among policy servers and policy management tools from
different vendors.
For example, different policy servers may have to evaluate the same
policy rule. Variables enable the condition term to be abstracted such
that its evaluation can be performed in the same
way.
The QoS Policy information model specifies a set of pre-defined
variables to support a set of fundamental QoS variables such as IP
header fields, user information, applications, etc. A pre-defined
variable must always have the same name and binding semantics, i.e.: a
given pre-defined variable should be bound to the same logical entity
by all client systems (typically policy servers). Similarly, the pre-
defined variable should be stored in the reusable-objects repository to
enable reuse and sharing of the pre-defined variable.
All standard variable names are case insensitive and do not include
spaces or other non-standard characters.
Snir, Ramberg, Strassner, Cohen expires September 2000 18
Draft-ietf-policy-qos-info-model-00.txt March 2000
The implementers of client systems that use the QoS Policy schema must
provide binding methods to bind pre-defined variables according to the
semantics specified in this section.
Following is a table that defines the predefined Variable names and
their binding. The table indicates which fields are checked in actual
filters used in provisioning policies as well as in RSVP signaling
messages.
+-----------------+---------------------------------------------------+
|Variable name | Logical binding |
+-----------------+---------------------------------------------------+
| SourceIP | The source IP address of the flow. Compared to the|
| | source IP header field, or the sender address in |
| | the RSVP Filter spec object [RSVP]. |
+-----------------+---------------------------------------------------+
| SourcePort | The source Port of a UDP/TCP flow. Compared to the|
| | source port field in the TCP/UDP header, or the |
| | sender port in the RSVP Filter spec object [RSVP].|
+-----------------+---------------------------------------------------+
| DestinationIP | The destination IP address of the flow. Compared |
| | to the destination IP header field, or the session|
| | address in the RSVP SESSION object [RSVP]. |
+-----------------+---------------------------------------------------+
| DestinationPort | The destination Port of a UDP/TCP flow. Compared |
| | to the destination port field in the TCP/UDP |
| | header, or the session port in the RSVP SESSION |
| | object [RSVP]. |
+-----------------+---------------------------------------------------+
| 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 continued in next page)
Snir, Ramberg, Strassner, Cohen expires September 2000 19
Draft-ietf-policy-qos-info-model-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
The definition of each predefined variable includes a standard name and
the allowed value types, i.e. the variableÆs qpValueTypes property.
Following is a table of variable names and their default allowed class
types.
+-----------------+---------------------------------------------------+
|Variable name | Allowed class types |
+-----------------+---------------------------------------------------+
| SourceIP | qosPolicyIPv4AddrValue, qosPolicyIPv6AddrValue |
+-----------------+---------------------------------------------------+
| SourcePort | qosPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| DestinationIP | qosPolicyIPv4AddrValue, qosPolicyIPv6AddrValue |
+-----------------+---------------------------------------------------+
| DestinationPort | qosPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| IPProtocol | qosPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| ToS | qosPolicyIntegerValue, qosPolicyBitStringValue |
+-----------------+---------------------------------------------------+
| DSCP | qosPolicyIntegerValue, qosPolicyBitStringValue |
+-----------------+---------------------------------------------------+
(Table continued in next page)
Snir, Ramberg, Strassner, Cohen expires September 2000 20
Draft-ietf-policy-qos-info-model-00.txt March 2000
(Table continued from previous page)
+-----------------+---------------------------------------------------+
| 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
For Value type definition check the QoS Policy Value section.
4.5 QoS Policy Value
This abstract class QoSPolicyValue is used for defining values and
constants used in policy conditions. Different value types are derived
from this class and represent the various attributes required.
Extensions off the QoS Polictvalue class, defined in this document
provide a list of values for representing the basic network attribute.
Values can be used to represent constants as named values. Named values
could be kept in a repository to be reused by multiple conditions.
Examples of constants include well-known ports, well-known protocol,
server addresses, etc.
The QoS Policy value classes define 3 types of basic values, scalars,
ranges and sets. For example a well-known port number could be defined
using the qosPolicyIntegerValue, defining a single value (80 for HTTP)
a range (80-88) or a set (80, 82, 8080). For details see the class
definition for each value type.
The QoS policy information model provide the following classes, all of
them extending the QoSPolicyvalue:
General:
QosPolicyStringValue
QosPolicyIntegerValue,
Snir, Ramberg, Strassner, Cohen expires September 2000 21
Draft-ietf-policy-qos-info-model-00.txt March 2000
QosPolicyBitStringValue,
QosPolicyDNValue,
QosPolicyAttributeValue.
Layer 3 Network values:
qosPolicyIPv4AddrValue,
qosPolicyIPv6AddrValue.
Layer 2 Network values:
QosPolicyMACAddrValue.
For details see class definition section of each value.
4.6. PolicyTimePeriodCondition
The QoS Policy Information model uses the PolicyTimePeriodCondition
class [PFCORE] to define time based QoS Policy rules. For details see
[PFCORE] section 6.5.
4.7. Actions
The QoS Policy schema defines actions to control QoS enforcement in
both the Integrated-Service model as well as the Differential service
model. Two types of actions are provided: Signaling and Provisioning
actions. Signaling actions are used to provide policy control on RSVP
requests. Provisioning actions are used to directly control the data
traffic, regardless of any out-of-band signaling.
A Policy rule may include 0..n provisioning actions and 0..m signaling
actions objects, each defining an action to perform.
Actions are ordered (prioritized). The order of actions is specified in
[PFCORE]; Order of actions for a rule is determined by the integer
value assigned to the policyActionOrder property of the
policyRuleActionAssociation class. Provisioning and signaling actions
are intermixed in the rule. Policy consumers (such as PDPs) may
separate the actions to two lists but must respect the internal order
of the specified actions.
QoS Policy action classes extend the [PFCORE] PolicyAction class.
Additional type of actions may be added as extensions to this schema by
extending the PolicyAction and using the current mechanisms.
4.7.1 Provisioning Actions
QoS Policy provisioning actions model traffic conditioner [DIFF-SERV-
ARCH] elements. Actions model meters, markers, shapers and droppers.
1. Meters measure the temporal properties of the stream of packets
selected by a classifier against a traffic profile. QosPolicyMeter
object models a meter. A meter can be shared between different policy
rules. A meter shared by more than one policy rule resides in a
repository and is referenced by all sharing rules. The property QpMeter
holds a reference to a meter kept in repository. The qpMeterScope
Snir, Ramberg, Strassner, Cohen expires September 2000 22
Draft-ietf-policy-qos-info-model-00.txt March 2000
property specifies whether the meter should measure flows matching
the rule condition per interface, per device or per flow. A
per flow meter conceptually creates a new meter for each flow,
measuring each flow against the profile. A per interface meter measures
the aggregate set of flows matching the rule condition forwarded via a
single interface. Meters are measured against traffic profile modeled
by the qosPolicyPRTrfcProf object. The property qpTrfcProf holds a
reference to a traffic profile that resides in a repository.
2. Markers set the DS field of a packet to a particular DS codepoint,
adding the marked packet to a particular DS behavior aggregate. The
marker may be configured to mark all packets steered to it to a single
codepoint, or may be configured to mark a packet to one of a set of
codepoints used to select a PHB in a PHB group, according to the state
of a meter. When the marker changes the codepoint in a packet it is
said to have "re-marked" the packet. Marking is modeled by the property
qpSetDSCPValue specifying the DS code-point to set. Remarking out-of-
profile packets is modeled by the qpOutofProfileRemarkValue property.
The property qpOutOfProfileAction should be set to 'remark' when the
remark DSCP value is used.
3. Shapers delay some or all of the packets in a traffic stream in
order to bring the stream into compliance with a traffic profile. A
shaper usually has a finite-size buffer, and packets may be discarded
if there is not sufficient buffer space to hold the delayed packets.
The property qpOutOfProfileAction 'shape' specify that packets measured
by a meter should be shaped according to the traffic profile specified
by a qosPoilicyPRTrfcProf.
4. Droppers discard some or all of the packets in a traffic stream in
order to bring the stream into compliance with a traffic profile. This
process is known as "policing" the stream. The property
qpOutOfProfileAction 'drop' specify that packets measured by a meter
should be policed according to the traffic-profile specified by a
qosPoilicyPRTrfcProf.
Example for a rule enforcing QoS provisioning actions:
Rule P = If (<condition>) than mark = <DS Value> AND activate a per-
flow policer <FLOWP> AND activate a per policy rule policer <CLASSP>.
Activate rule on outgoing traffic.
Rule P is represented using 3 qosPolicyPRAction objects:
Object 1:
qpDirection: OUT
qpSetDSCPValue: <DS Value>
Object 2:
qpDirection: OUT
qpMeterScope: flow
qpTrfcProf: <FLOWP> DN (repository reference)
qpOutOfProfileAction: discard
Snir, Ramberg, Strassner, Cohen expires September 2000 23
Draft-ietf-policy-qos-info-model-00.txt March 2000
Object 3:
qpDirection: OUT
qpMeterScope: Interface
qpTrfcProf: <CLASSP> DN (repository reference)
qpOutOfProfileAction: discard
qpMeter: <Meter>
Some PHBs require the successive application of a number of traffic
conditioners. An example of a policy with two levels of traffic
conditioners is the following: "Mark packets to DSCP=24 if rate is
within profile x=<64Kb/s>, else mark packets with DSCP=25 if rate is
within profile y=<128kb/s>, else drop out-of-profile packets". This
policy rule is modeled by using two actions. The first action measures
the traffic against the first profile specifying DSCP=24 to set for
within profile packets. Out-of-profile packets are marked to DSCP=23.
The subsequent action measured traffic against the second higher
profile, and drops out-of-profile packets. Arbitrary cascading of
traffic conditioners can be constructed, where each action measures
traffic against a higher traffic profile and change only the out-of-
profile action as required.
4.7.2 Signaling Action
RSVP is the standard protocol used for requesting QoS resources from
the network. The QoS Policy signaling actions control the decision
whether to admit or reject an RSVP request based on the request's
attributes and the specified policy. The QoS policy signaling actions
allow modifying the content and forwarding behavior of RSVP requests.
The signaling policies control the admission priority of resources and
provide preemption support. Mapping of integrated services signaled by
RSVP to differential services in a core network is controlled by
signaling policies as well, by assigning DSCP to flows on the boundary
of the differential service core.
The set of policies specified allow a policy server (policy decision
point) to instruct an RSVP node (policy enforcement point) to enforce
all set of controls defined in the COPS protocol specification. The
actions defined here follow the different decision types of the COPS
protocol [COPS] and the guidelines for it's use in RSVP environment
[COPS-RSVP]. The basic decision to accept or deny a reservation is
modeled by qosPolicyRSVPAction. Two supplements can be added to this
decision. qosPolicyRSVPSignalCtrlAction controls the content and
forwarding behavior of RSVP flows. qosPolicyRSVPInstallAction controls
the processing of RSVP requests and accompanying flows within the RSVP
node itself. QoS signaling policies does not require a policy server
for decision making. A local policy module can use signaling policies
for making local decisions, as well as if other outsourcing policy
protocol beside COPS is used.
Snir, Ramberg, Strassner, Cohen expires September 2000 24
Draft-ietf-policy-qos-info-model-00.txt March 2000
The qosPolicyRSVPAction action includes a specification of the subset
of RSVP flows on which the action should be taken. The following
parameters can be specified:
1. Direction - in/out
2. Message type - Path/Resv/PathErr/ResvErr
3. Service type - Gaurenteed Service / Controlled Load / Null
4. Service style - SE, WF, FF
The direction refers to the direction of the flow, hence the direction
of the RSVP Path messages. Therefore out-direction policies control
outgoing Path messages as well as incoming Resv messages.
The basic decision modeled by this class is whether to admit or reject
the RSVP request. The decision can be based on comparison of the
request TSPEC or FLOWSPEC to a traffic profile and a meter. A meter can
be used to track the temporal resources allocation of RSVP requests
matching a network condition. Such meters allow enforcement of policies
of the form: "Allow allocation of resource via RSVP for flows coming
from subnet x up to a total aggregated rate of 256kb/sec". Use of
meters and meter scope is identical to their use in provisioning
policies. The following properties are used:
1. Traffic Profile - referencing a traffic profile.
2. Meter - referencing a meter.
Both traffic profile and meter can be directly included within the
action as well.
Note that if traffic profile is not provided, it is implicitly assumed
that the RSVP request should be accepted. Rejecting all RSVP request
matching the condition is specified by a zero valued traffic profile.
The qosPolicyRSVPInstallAction adds the following controls:
1. Set DSCP value
2. Set the Preemption priority of the RSVP request.
Setting DSCP on the flow on the edge of a differential service core
allow provisioning of QoS end to end over a mixed integrated and
differential service clouds.
RSVP node is responsible for admission decision based on its available
resources. Setting preemption priority [RSVP_PREEMP] allows the RSVP
node to decide which of its reservations should be admitted, and when
to make room for a newer reservation by preempting an already installed
one.
This class should be extended to cover other COPS install decisions if
required.
The qosPolicyRSVPSignalCtrlAction adds the following controls:
1. Replace/add DCLASS object in RSVP message.
2. Replace/add Preemption priority object in RSVP message.
3. Trigger an error/warning RSVP message.
Snir, Ramberg, Strassner, Cohen expires September 2000 25
Draft-ietf-policy-qos-info-model-00.txt March 2000
4. Instruct the RSVP node to proxy RSVP message as if sent by
the RSVP end nodes.
Modifying the content of messages can be enforced using COPS replace
decision. This class should be extended to cover other object
replacements and in particular replacement of policy objects.
Triggering error and warnings is important in scenarios when there is a
need to notify the end nodes that their reservation is about to expire
and various other information.
There are scenarios in which it makes sense not to carry RSVP requests
end to end. An RSVP node on the boundary of a differential service core
may map the RSVP request to specific PHB by setting the DSCP on the
flow packets, without forwarding the Path message downstream. Still,
this RSVP node may send back an RSVP Resv message as if the receiver
has sent it, to complete the RSVP cycle.
Example for a rule enforcing QoS signaling actions:
Rule S = If (<condition>) than accept RSVP request requesting less ore
all traffic exceeds the rate limit. Traffic that falls between the
normal burst size and the Excess Burst size exceeds the traffic profile
with a probability that increases as the burst size increases. This
provides a Random Discard mechanism for policer, markers and shapers.
Excess burst size should be larger than normal burst size. If excess
burst is not specified, it is assumed that excess burst size is equal
to normal burst size. In this case, burst larger than the normal burst
size will always be counted as out-of-profile packets.
RSVP signaling QoS policy can condition the decision whether to accept
or deny an RSVP request based on the traffic specification of the flow
(TSPEC) or the amount of QoS resources requested (FLOWSPEC). The TSPEC
and FLOWSPEC objects are either compared directly with a traffic
profile, or aggregated to a meter that measures the temporal admitted
RSVP states and than compared to the traffic specification.
QosPolicyRSVPTrfcProf class models such a traffic profile. The
qosPolicyRSVPTrfcProf class has the following properties:
1. Token Rate (r) measured in bits/sec.
2. Peak Rate (p) measured in bits/sec.
3. Bucket Size (b) measured in bytes.
4. Min Policed unit (m) measured in bytes.
5. Max packet size (M) measured in bytes.
6. Resv Rate (R) measured in bits/sec.
7. Slack term (s) measured in microseconds.
8. Number of sessions.
The first 5 parameters are the traffic specification parameters used in
integrated service. For a definition and full explanation of their
meaning refer to [RSVP-IS]. These parameters are used to define a
Snir, Ramberg, Strassner, Cohen expires September 2000 27
Draft-ietf-policy-qos-info-model-00.txt March 2000
sender TSPEC as well as FLOWSPEC for the Controlled Load service [CL].
Parameters 6 and 7 are the additional parameters used for specification
of the Guaranteed Service FLOWSPEC [GS].
A partial order is defined between TSPECs (and FLOWSPECs). A TSPEC A is
larger than TSPEC B if and only if rA>rB, pA>pB, bA>bB, mA<mB and
MA>MB. A TSPEC RSVP measured against a traffic profile use the same
ordering rule. An RSVP message is accepted only if its TSPEC (FLOWSPEC)
is either smaller or equal to the traffic profile. Only parameters
specified in the traffic profile are compared. GS FLOWSPEC is compared
also against the rate R and the slack term S. R should not be larger
than the traffic profile R parameter, while the FLOWSPEC slack term
should not be smaller than that specified in the slack term.
TSPECs as well as FLOWSPECs can be added. The sum of two TSPECs is
computed by summing the rate r, the peak rate p, the bucket size b, and
by taking the minimum of min policed unit m and the maximum of the max
packet size M. GS FLOWSPECs are summed by adding the Resv rate and
minimizing the slack term s. These rules are used to compute a meter
that measures the temporal state of admitted RSVP states. The meter is
than compared with the traffic profile specified in the signaling
policy using the same rules for comparison of TSPECs (FLOWSPECs) to a
traffic profile.
RSVP traffic profile may specify also the maximal number of allowed
RSVP sessions. This provides an easy way to limit the number of
admitted RSVP requests without pre knowledge of the aggregated rates
requested.
5. Decision strategy
The decision strategy to be used by policy servers and other policy
decision points in the network on the set of defined policies is
defined per qosNamedPolicyContainer group.
In order to get a consistent behavior of different policy servers using
the same group of policy rules, the priority of the policy rules must
be pre-defined and the decision strategy implemented by each different
policy server must be defined explicitly.
The decision strategy is defined per domain and can be overridden per
qosNamedPolicyContainer. When a policy decision point evaluates a set
of rules, it implements the decision strategy defined in each container
of rules. Nested containers can override the decision strategy of their
containers.
The order of decision making of nested rules is defined by their
internal priority, the priority of the policy rule containing the
nested rule and the priority of their containers.
Nested rules have a higher priority then their containing rule.
Priority is compared between rules and qosNameddContainers, as defined
in [PCIM].
Snir, Ramberg, Strassner, Cohen expires September 2000 28
Draft-ietf-policy-qos-info-model-00.txt March 2000
Two decision strategies are defined:
1. "FIRST MATCH"
2. "MATCH ALL"
5.1. First match
The first match decision strategy is defined as a process that
evaluates the policy rules in the defined order, evaluating the rules'
conditions, until a condition is evaluated to TRUE. The rule's actions
are applied and the process of decision-making is complete.
5.2. Match All
The match all decision strategy is a process of going over the complete
set of rules according to their defined order of priority and applying
the actions of each rule that the flow meets with the rule's
conditions. This matching strategy may in many cases mean that a number
of rules may meet the flow's parameters and all of their actions will
be applied.
A Match All strategy may result in applying conflicting rules. Handling
conflicts is outside the scope of this draft. The implementers of QoS
systems must provide proprietary conflict detection and avoidance or
resolution mechanisms.
5.3. Decision Strategy example
This section demonstrates both decision strategies and rule
prioritization.
Domain
|
+--Rule1 (priority 19)
|
+--NamedContainer1 (priority 5)
| |
| +--Rule 1.1 (priority 303)
| |
| +--Rule 1.2 (priority 3)
|
+--Rule3 (priority 4)
|
+--Rule4
Figure 3: Decision Strategy example
For simplicity we assume that a Policy Decision Point needs to enforce
all rules described above.
Snir, Ramberg, Strassner, Cohen expires September 2000 29
Draft-ietf-policy-qos-info-model-00.txt March 2000
The rules will be evaluated in the following order:
1. Rule1 (higher priority between Rule1, namedContainer1 and Rule3
2. Rule1.2 (higher priority between Rule1.1 and Rule1.2)
3. Rule1.1
4. Rule4 (nested in Rule 3)
5. Rule3
If the decision strategy of the domain is first match and it is
not overridden by NamedContainer1, the decision process stops once
a rule's condition is matched.
If the decision strategy of the domain is match all and it is not
overridden by NamedContainer1, the match-all decision process runs
over all rules according to the order above.
If the decision strategy of the domain is first match and the decision
process of NamedContainer1 is match all, Rule1 will be evaluated
first. If its condition matches, the decision process stops. Else,
both Rules 1.1 and 1.2 will be evaluated and executed if their
condition match. If one of NamedContainer1 rule match, the decision
process stops. Else Rules 3 and 4 will be evaluated using first match
decision strategy.
If the decision strategy of the domain is match all and the decision
process of NamedContainer1 is first match, the decision process will
evaluate Rule1 and continue to evaluate NamedContainer1 rules. Rules
1.1 and 1.2 will be evaluated using first match strategy. The decision
process continues to evaluate rules 3 and 4 according to match-all
decision strategy.
6. Per Hop Behavior
A per-hop behavior (PHB) is a description of the externally observable
forwarding behavior of a DS node applied to a particular DS behavior
aggregate. A PHB is selected at a node by the DS codepoint in a
received packet. A set of PHBs is enforced on a QoS domain. The set of
PHBs share buffer and scheduler resources among them. The QoS
informational model provides abstract placeholders for PHBs and for a
set of PHBs enforced together on a QoS domain. Further specification of
PHBs and PHP sets are outside the scope of this document.
6.1. PHB
The qosPolicyPHB abstract class models a single PHB. The qosPolicyPHB
class includes a single property, the DSCP value, an integer with
allowed value of 0 to 63.
The qosPolicyPHB name will be defined using the cn property belonging
to the Policy class [PFCORE].
Snir, Ramberg, Strassner, Cohen expires September 2000 30
Draft-ietf-policy-qos-info-model-00.txt March 2000
6.1. PHB Set
The qosPolicyPHBSet abstract class serves as a named container for
instances of qosPolicyPHB classes. It models the set of PHBs enforced
together on a QoS domain. Different PHB sets can be kept in a
repository. A PHB set enforced on the domain is specified by either a
reference from the qosPolicyDOmain class to one of the repository PHB
sets, or by directly attaching a PHB set to the domain class.
To fine tune PHB parameters and to further restrict the namespace in
which a particular PHB is used, PHB sets can be referenced or attached
to qosNamedPolicyContainers. In order to maintain an end to end
consistent behavior, overriding the domain's PHB set should be done
only to fine tune the parameters of each PHBs, and not to use different
set of PHBs altogether.
Markers coloring packets of flows on domain ingress edges should pick a
DS codepoint selecting one of the PHB enforced on the QoS domain.
7. QoS Policy Class Inheritance
The following diagram illustrates the class hierarchy for the
Policy schema classes (relevant Core classes are included):
top
|
+--policy (abstract)
| |
| +--policyGroup
| | |
| | +--qosPolicyDomain
| | |
| | +--qosNamedPolicyContainer
| |
| |
| +--policyRule
| |
| +--policyRuleConditionAssociation
| |
| +--policyRuleActionAssociation
| |
| +--policyConditionInstance
| |
| +--policyActionInstance
| |
| +--policyInstance
| |
| |
(Diagram continued in next page)
Snir, Ramberg, Strassner, Cohen expires September 2000 31
Draft-ietf-policy-qos-info-model-00.txt March 2000
(Diagram continued from previous page)
| +--policyCondition
| | |
| | +--qosPolicySimpleCondition
| |
| |
| +--qosPolicyVariable
| |
| |
| +--qosPolicyValue(abstract)
| | |
| | +--qosPolicyIPv4AddrValue
| | |
| | +--qosPolicyIPv6AddrValue
| | |
| | +--qosPolicyMACAddrValue
| | |
| | +--qosPolicyStringValue
| | |
| | +--qosPolicyBitStringValue
| | |
| | +--qosPolicyDNValue
| | |
| | +--qosPolicyAttributeValue
| | |
| | +--qosPolicyIntegerValue
| |
| +-- qosPolicyMeter
| |
| +-- qosPolicyPRTrfcProf
| |
| +-- qosPolicyRSVPTrfcProf
| |
| +-- qosPolicyPHBSet (abstract)
| |
| +-- qosPHB (abstract)
|
+--policyActionAuxClass
| |
| +-- qosPolicyPRAction
| |
| +-- qosPolicyRSVPAction
| |
| +-- qosPolicyRSVPSignalCtrlAction
| |
| +-- qosPolicyRSVPInstallAction
|
+--policyRepository
Note: classes with a "qos" prefix are QoS Policy Schema classes.
Snir, Ramberg, Strassner, Cohen expires September 2000 32
Draft-ietf-policy-qos-info-model-00.txt March 2000
8. Class definition:
8.1. 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 has a potentially different set of PHBs and
policies, access rules, decision strategy or other application of the
policy information organized in some fashion. The class definition is
as follows:
NAME qosPolicyDomain
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 (Core)
PROPERTIES qpDomainName, qpPHBSet, qpPolicyRuleMatchMethod
8.1.1. The Property qpDomainName
NAME qpDomainName
DESCRIPTION A user-friendly name of the QoS policy domain.
SYNTAX String
8.1.2. The Property qpPHBSet
NAME qpPHBSet
DESCRIPTION Reference to the PHB set defined for the domain.
SYNTAX Reference
8.1.3. The Property 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 }
8.2. 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. The class
definition is as follows:
Snir, Ramberg, Strassner, Cohen expires September 2000 33
Draft-ietf-policy-qos-info-model-00.txt March 2000
NAME qosNamedPolicyContainer
DESCRIPTION A class that is a logical and physical
container of policies.
DERIVED FROM PolicyGroup (Core)
PROPERTIES qpPriority, qpPolicyRuleMatchMethod
8.2.1. The Property qpPriority
NAME qpPriority
DESCRIPTION The priority of a named group of rules compared
to the other qosPolicyNamedContainer objects.
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 each be evaluated
before other objects that have a numerically
lower priority.
SYNTAX Integer
8.2.2. The Property 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 }
8.3. Class qosPolicyPRAction
This class defines Diff-Serv 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 Diff-Serv
Traffic action to be applied on a specific flow
or group of flows.
DERIVED FROM PolicyAction (Core)
ABSTRACT False
PROPERTIES qpDirection, qpSetDSCPvalue, qpMeter, qpMeterScope,
qpTrfcProf, qpOutOfProfileAction,
qpOutOfProfileRemarkValue
Snir, Ramberg, Strassner, Cohen expires September 2000 34
Draft-ietf-policy-qos-info-model-00.txt March 2000
8.3.1. The Property qpDirection
NAME qpDirection
DESCRIPTION this Property defines the direction of the action,
incoming or/and outgoing interfaces.
SYNTAX Integer [ENUM] {IN=0,OUT=1}
8.3.2. The Property qpSetDSCPvalue
NAME qpSetDSCPvalue
DESCRIPTION this Property defines DSCP value of the mark action.
SYNTAX Integer
8.3.3. The Property qpMeter
NAME qpMeter
DESCRIPTION A reference to a qosPolicyMeter object used in this
provisioning action.
SYNTAX Reference
8.3.4. The Property qpMeterScope
NAME qpMeterScope
DESCRIPTION An integer, enum, that defines the scope of the
metering action.
SYNTAX Integer enum [flow=0,interface=1 device=2]
8.3.5. The Property qpPRTrfcProf
NAME qpPRTrfcProf
DESCRIPTION This Property contains the DiffServ / provisioning
Policing instruction value, defined as a reference to a
qosPolicyPRTrfcProf entry.
SYNTAX Reference
8.3.6. The Property qpOutOfProfileAction
NAME qpOutOfProfileAction
DESCRIPTION The action to be applied to out of profile
packets, as defined in the DiffServTrfcProf
entry.
SYNTAX Integer [ENUM] {SHAPE=0,DISCARD=1,REMARK=2}
Snir, Ramberg, Strassner, Cohen expires September 2000 35
Draft-ietf-policy-qos-info-model-00.txt March 2000
8.3.7. The Property qpOutofProfileRemarkValue
NAME qpOutofProfileRemarkValue
DESCRIPTION The DSCP value to be applied to out of profile
packets if the qpOutofProfile action is defined
as REMARK.
SYNTAX Integer
8.4. Class qosPolicyRSVPAction
This class defines a policy action to be applied on an 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 PolicyAction (Core)
ABSTRACT False
PROPERTIES qpDirection, qpRSVPMessageType[], qpRSVPService[],
qpRSVPStyle[], qpRSVPInstallAction, qpRSVPCtrlAction,
qpMeter, qpMeterScope, qpRSVPTrfcProf,
8.4.1. The Property qpDirection
NAME qpDirection
DESCRIPTION this Property defines the direction of the action,
incoming or/and outgoing interfaces.
SYNTAX Integer [ENUM] {IN=0,OUT=1}
8.4.2. The Property qpRSVPMessageType
NAME qpRSVPMessageType
DESCRIPTION this Property limits the scope of the action to be
enforced only on specific type of RSVP messages.
SYNTAX Integer [ENUM] { Path=0 Resv=1 ResvErr=2 PathErr=3}
8.4.3. The Property qpRSVPStyle
NAME qpRSVPStyle
DESCRIPTION this Property limits the scope of the action to be
enforced only on RSVP Requests with the specified
reservation style.
SYNTAX Integer [ENUM] {SE=0 FF=1 WF=2}
Snir, Ramberg, Strassner, Cohen expires September 2000 36
Draft-ietf-policy-qos-info-model-00.txt March 2000
8.4.4. The Property 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}
8.4.5. The Property qpRSVPInstallAction
NAME qpRSVPInstallAction
DESCRIPTION A reference to a qpRSVPInstallAction object used in
conjunction with the RSVP reservation.
SYNTAX Reference
8.4.6. The Property qpRSVPCtrlAction
NAME qpRSVPCtrlAction
DESCRIPTION A reference to a qpRSVPCtrlAction object used in
conjunction with the RSVP reservation.
SYNTAX Reference
8.4.7. The Property qpMeter
NAME qpMeter
DESCRIPTION A reference to a qosPolicyMeter object used in this
RSVP action.
SYNTAX Reference
8.4.8. The Property qpMeterScope
NAME qpMeterScope
DESCRIPTION An integer, enum, that defines the scope of the
metering action.
SYNTAX Integer enum [flow=0,interface=1 device=2]
8.4.9. The Property qpRSVPTrfcProf
NAME qpRSVPTrfcProf
DESCRIPTION A reference to RSVPTrfcProf object that define the
traffic profile compared with TSPEC or FLOWSPEC
objects, or with value kept in meter.
SYNTAX Reference
Snir, Ramberg, Strassner, Cohen expires September 2000 37
Draft-ietf-policy-qos-info-model-00.txt March 2000
8.5. Class qosPolicyPRTrfcProf
A provisioning Traffic profile is a class that carries the policer or
shaper rate values to be enforced on a flow or a set of flows.
The class definition is as follows:
NAME qosPolicyPRTrfcProf
DESCRIPTION A class that carries the policer or shaper rate
values to be enforced on a flow or a set of flows.
DERIVED FROM Policy (Core)
ABSTRACT False
PROPERTIES qpPRRate, qpPRNormalBurst,
qpPRExcessBurst
8.5.1. The Property qpPRRate
NAME qpPRRate
DESCRIPTION The token rate. It is specified in units of
bits/second. A rate of zero means that all packets
will be out of profile.
SYNTAX Integer
8.5.2. The Property qpPRNormalBurst
NAME qpPRNormalBurst
DESCRIPTION The normal size of a burst measured in bytes
SYNTAX Integer
8.5.3. The Property qpPRExcessBurst
NAME qpPRExcessBurst
DESCRIPTION The excess size of a burst measured in bytes
SYNTAX Integer
8.6. Class qosPolicyRSVPTrfcProf
This class represents an IntServ RSVP Traffic profile. Values of RSVP
traffic profiles are compared against Traffic specification (TSPEC) and
QoS Reservation requests (FLOWSPEC) carried in RSVP requests. Traffic
profiles can be reusable objects or ad-hoc.
The class definition is as follows:
NAME qosPolicyRSVPTrfcProf
DESCRIPTION A class that defines rate limiting values for QoS
requests for a flow or a set of flow via RSVP
Snir, Ramberg, Strassner, Cohen expires September 2000 38
Draft-ietf-policy-qos-info-model-00.txt March 2000
DERIVED FROM Policy (Core)
ABSTRACT False
PROPERTIES qpRSVPTokenRate, qpRSVPPeakRate,
qpRSVPBucketSize, qpRSVPResvRate, qpRSVPResvSlack,
qpRSVPSessionNum, qpMinPolicedUnit, qpMaxPktSize
8.6.1. The Property qpRSVPTokenRate
NAME qpRSVPTokenRate
DESCRIPTION Token Rate parameter, measured in bits/sec
SYNTAX Integer
8.6.2. The Property qpRSVPPeakRate
NAME qpRSVPPeakRate
DESCRIPTION Peak rate parameter, measured is bits/sec
SYNTAX Integer
8.6.3. The Property qpRSVPBucketSize
NAME qpRSVPBucketSize
DESCRIPTION Bucket Size, measured in bytes
SYNTAX Integer
8.6.4. The Property qpRSVPResvRate
NAME qpRSVPResvRate
DESCRIPTION Defines RSVP Rate - R-Spec parameter in the RSVP
Guaranteed service reservation. Measured in bits/sec.
SYNTAX Integer
8.6.5. The Property qpRSVPResvSlack
NAME qpRSVPResvSlack
DESCRIPTION Defines RSVP Slack Term - [RSVP] Flowspec::xspec_S
parameter in the RSVP Guaranteed service reservation
(microseconds).
SYNTAX Integer
8.6.6. The Property qpRSVPSessionNum
NAME qpRSVPSessionNum
DESCRIPTION The total number of allowed active RSVP sessions.
SYNTAX Integer
Snir, Ramberg, Strassner, Cohen expires September 2000 39
Draft-ietf-policy-qos-info-model-00.txt March 2000
8.6.7. The Property qpMinPolicedUnit
NAME qpMinPolicedUnit
DESCRIPTION Defines the RSVP minimum policed unit, measured
in bytes.
SYNTAX Integer
8.6.8. The Property qpMaxPktSize
NAME qpMaxPktSize
DESCRIPTION Defines RSVP maximum allowed packet size, measured
in bytes.
SYNTAX Integer
8.7. Class qosPolicyRSVPSignalCtrlAction
This class extends the functionality of the qosPolicyRSVPAction class
by adding detailed control on the signaling protocol behavior itself.
The information carried in RSVP messages can be modified using this
action, as well as the RSVP forwarding behavior. This class can be
extended to support replacement of additional object in RSVP messages,
beyond replacement of DCLASS and PREEMPTION object replacement defined
below.
This class SHOULD be aggregated to a qosPolicyRSVPAction object.
NAME qosPolicyRSVPSignalCtrlAction
DESCRIPTION Actions modifying the behavior and content of RSVP
Signaling flows.
DERIVED FROM policyAction
ABSTRACT False
PROPERTIES qpForwardingMode, qpSendError,
qpReplaceDSCP,qpReplacePreemptionPriority,
qpReplaceDefendingPriority
8.7.1. The Property qpForwardingMode
This Property 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}
Snir, Ramberg, Strassner, Cohen expires September 2000 40
Draft-ietf-policy-qos-info-model-00.txt March 2000
8.7.2. The Property qpSendError
This Property controls generation of Resv-Err and Path-Err messages as
defined in [COPSRSVP].
NAME qpSendError
DESCRIPTION Defines whether to send RSVP error and warning
message.
SYNTAX Integer {No=0, Yes=1}
8.7.3. The Property qpReplaceDSCP
NAME qpReplaceDSCP
DESCRIPTION allows the replacement of a DCLASS object carrying
DSCP value in RSVP message.
SYNTAX Integer
8.7.4. The Property qpReplacePreemptionPriority
This Property allows replacing or adding of preemption priority
[RSVP_PREEMP] object to RSVP messages.
NAME qpReplacePreemptionPriority
DESCRIPTION A positive integer value specifying the preemption
Priority that should be carried by RSVP messages.
SYNTAX Integer
8.7.5. The Property qpReplaceDefendingPriority
This Property allows replacing or adding of preemption priority
[RSVP_PREEMP] object to RSVP messages.
NAME qpReplaceDefendingPriority
DESCRIPTION This Property allows replacing or adding of
preemption priority [RSVP_PREEMP] object to RSVP
messages. It specifies the defending priority within
the preemption object.
SYNTAX Integer
8.8. 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 actions 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.
Snir, Ramberg, Strassner, Cohen expires September 2000 41
Draft-ietf-policy-qos-info-model-00.txt March 2000
This class SHOULD be attached to an object together with
qosPolicyRSVPAction.
class definition is as follows:
NAME qosPolicyRSVPInstallAction
DESCRIPTION A class that defines a actions to be
administrated on a the PEP.
DERIVED FROM policyAction
ABSTRACT False
PROPERTIES qpSetDSCPValue, qpSetPreemptionPriority,
qpSetDefendingPriority
8.8.1. The Property qpSetDSCPValue
NAME qpSetDSCPValue
DESCRIPTION Defines the value the PEP PROPERTIES use to remark
the flow signaled by the RSVP requests.
SYNTAX Integer
8.8.2. The Property qpSetDefendingPriority
This Property allows setting the preemption priority [RSVP_PREEMP] of
RSVP flows.
NAME qpSetDefendingPriority
DESCRIPTION This Property allows setting the
preemption priority [RSVP_PREEMP] of RSVP flows.
It specifies the defending priority within
the preemption object.
SYNTAX Integer
8.8.3. The Property qpSetPreemptionPriority
This Property allows setting the preemption priority [RSVP_PREEMP] of
RSVP flows.
NAME qpSetPreemptionPriority
DESCRIPTION This Property allows setting the
preemption priority [RSVP_PREEMP] of RSVP flows.
SYNTAX Integer
Snir, Ramberg, Strassner, Cohen expires September 2000 42
Draft-ietf-policy-qos-info-model-00.txt March 2000
8.9. Class qosPolicySimpleCondition (Aux)
A simple condition is composed of a <Variable> an <Operator> and
<Value> triplet. The operator used in all definition in this draft is
the 'match' operator. Such simple conditions are evaluated by answering
the question: Does <variable> match <value>? The operator Property can
be extended to support other relations between variable and values.
Simple conditions are building blocks for more complex Boolean
conditions.
The qosPolicySimpleCondition is derived from the policyCondition class
of the Core schema [PFSCHEMA]. Simple conditions can be kept in
repositories for reuse. For a complete explanation of the use of simple
conditions see the relevant section.
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 single condition is made of the triple <Variable -
relation - Value>
DERIVED FROM PolicyCondition (Core)
ABSTRACT False
All classes derived from qosPolicyVariable and qosPolicyValue defined
below can be attached as well.
PROPERTIES qpOperator, qpVariableAtom, qpValueAtom
8.9.1. The Property qpOperator
NAME qpOperator
DESCRIPTION The relation between a variable and a value.
SYNTAX String
8.9.2. The Property qpVariableAtom
NAME qpVariableAtom
DESCRIPTION A reference to a variable
SYNTAX Reference
8.9.3. The Property qpValueAtom
NAME qpValueAtom
DESCRIPTION A reference to a value.
SYNTAX Reference
Snir, Ramberg, Strassner, Cohen expires September 2000 43
Draft-ietf-policy-qos-info-model-00.txt March 2000
8.10. Class qosPolicyVariable
Variables are used for building individual conditions. The variable
specifies the Property of a flow that should be matched when evaluating
the condition.
Not every combination of a variable and a value creates a meaningful
condition. A source IP address variable can not be matched against a
value that specifies a port number. A given variable selects the set of
matchable value types.
A variable also limits the set of values within a particular value type
that can be matched against it in a condition. For example, a source-
port variable limits the set of values to represent integers 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 (Core)
ABSTRACT False
PROPERTIES qpVariableName, qpValueTypes[]
qpVariableDescription,
qpValueConstraints[ref qosPolicyValue [0..n]]
8.10.1. The Property qpVariableName
NAME qpVariableName
DESCRIPTION A unique name for the variable.
SYNTAX String
Following is a table that defines the predefined Variable names and
their logical binding. The table indicates which fields are checked in
actual filters used in provisioning policies as well as in RSVP
signaling messages.
Snir, Ramberg, Strassner, Cohen expires September 2000 44
Draft-ietf-policy-qos-info-model-00.txt March 2000
+-----------------+---------------------------------------------------+
|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. |
+-----------------+---------------------------------------------------+
|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. |
+-----------------+---------------------------------------------------+
Snir, Ramberg, Strassner, Cohen expires September 2000 45
Draft-ietf-policy-qos-info-model-00.txt March 2000
+-----------------+---------------------------------------------------+
| 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.10.2 The Property qpValueTypes
This Property 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
allow 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 String
Following is a table of variable names and their default allowed class
types.
+-----------------+---------------------------------------------------+
|Variable name | Allowed class types |
+-----------------+---------------------------------------------------+
| SourceIP | qosPolicyIPv4AddrValue, qosPolicyIPv6AddrValue |
+-----------------+---------------------------------------------------+
| SourcePort | qosPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| DestinationIP | qosPolicyIPv4AddrValue, qosPolicyIPv6AddrValue |
+-----------------+---------------------------------------------------+
| DestinationPort | qosPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| IPProtocol | qosPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| ToS | qosPolicyIntegerValue, qosPolicyBitStringValue |
+-----------------+---------------------------------------------------+
| DSCP | qosPolicyIntegerValue, qosPolicyBitStringValue |
+-----------------+---------------------------------------------------+
| DestinationMAC | qosPolicyMACAddrValue |
+-----------------+---------------------------------------------------+
| SourceMAC | qosPolicyMACAddrValue |
+-----------------+---------------------------------------------------+
Snir, Ramberg, Strassner, Cohen expires September 2000 46
Draft-ietf-policy-qos-info-model-00.txt March 2000
+-----------------+---------------------------------------------------+
| 8021QID | qosPolicyIntegerValue, qosPolicyBitStringValue |
+-----------------+---------------------------------------------------+
| Snap | qosPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| Ethertype | qosPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| Ssap | qosPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| Dsap | qosPolicyIntegerValue |
+-----------------+---------------------------------------------------+
| Application | qosPolicyDNValue, qosPolicyStringValue, |
| | qosPolicyPropertyValue |
+-----------------+---------------------------------------------------+
| User | qosPolicyDNValue, qosPolicyStringValue, |
| | qosPolicyPropertyValue |
+-----------------+---------------------------------------------------+
Table 3. Allowed Variable Names and Their Default Class Types
8.10.3. The Property qpVariableDescription
NAME qpVariableDescription
DESCRIPTION A textual description of the variable
SYNTAX String
8.10.4. The Property qpValueConstraints
NAME qpValueConstraints
DESCRIPTION A list of references of the value objects
serving as constraints for this variable.
SYNTAX Reference
8.11. Class qosPolicyValue
This abstract class used for
defining values and constants used in policy conditions. 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
ABSTRACT True
PROPERTIES
Snir, Ramberg, Strassner, Cohen expires September 2000 47
Draft-ietf-policy-qos-info-model-00.txt March 2000
8.12. 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
ABSTRACT False
PROPERTIES qpIPv4AddrList[]
8.12.1. The Property qpIPv4AddrList
This Property 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
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 PROPERTIES 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 String
FORMAT Ipv4address | hostname | Ipv4addressrange |
Ipv4maskedaddress | Ipv4prefix
Snir, Ramberg, Strassner, Cohen expires September 2000 48
Draft-ietf-policy-qos-info-model-00.txt March 2000
8.13. 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
ABSTRACT False
PROPERTIES qpIPv6AddrList[]
8.13.1. The Property qpIPv6AddrList
This Property 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 PROPERTIES 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 String
Snir, Ramberg, Strassner, Cohen expires September 2000 49
Draft-ietf-policy-qos-info-model-00.txt March 2000
FORMAT IPv6address | hostname | Ipv6addressrange |
Ipv6maskedaddress | Ipv6prefix
8.14. Class qosPolicyMACAddrValue
This class is used to define a List of MAC addresses and MAC address
range values. The class definition is as follows:
NAME qosPolicyMACAddrValue
DESCRIPTION This class is used to define a list of MAC
addresses and MAC address range values.
DERIVED FROM qosPolicyValue
ABSTRACT False
PROPERTIES qpMACAddrList[]
8.14.1. The Property qpMACAddrList
This Property provides an unordered list of strings each specifying a
MAC address or a range of MAC addresses. 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 qpIPv6AddrList
DESCRIPTION A list of MAC addresses and MAC address ranges.
SYNTAX String
FORMAT MACaddress | MACmaskedaddress
8.15. Class qosPolicyStringValue
This class is used to represent a single or set of string values.
The class definition is as follows:
Snir, Ramberg, Strassner, Cohen expires September 2000 50
Draft-ietf-policy-qos-info-model-00.txt March 2000
NAME qosPolicyStringValue
DESCRIPTION This class is used to define a list of string
values with wildcards DERIVED FROM qosPolicyValue
ABSTRACT False
PROPERTIES qpStringList[]
8.15.1. The Property qpStringList
This Property provides an unordered list of strings each representing a
single string with wildcards. The asterix character "*" is used as
wildcard and represents an arbitrary sub-string replacement. For
example, the value "abc*def" match "abcxyzdef", and the value
"abc*def*" match "abcxxxdefyyyzzz". The syntax definition is identical
to substrig assertion syntax defined in [LDAP_ATTR]. If the asterix
character is required as part of the string value itself, It is quoted
as described in section 4.3 of [LDAP_ATTR].
NAME qpStringList
DESCRIPTION A list of string values with wildcards
SYNTAX String
8.16 Class qosPolicyBitStringValue
This class is used to represent a single or set of bit string values.
The class definition is as follows:
NAME qosPolicyBitStringValue
DESCRIPTION This class is used to define a list of bit string
Values.
DERIVED FROM qosPolicyValue
ABSTRACT False
PROPERTIES qpBitStringList[]
8.16.1. The Property qpBitStringList
This Property provides an unordered list of strings each representing a
single bit string or a set of bit strings. The number of bits specified
should equal the number of bits of the expected variable. For example,
for an 8-bit byte variable, 8 bits should be specified. If the variable
does not have a fixed length, the bit string should be matched against
the variable most significant bit string.
The formal definitions are:
binary-digit = "0" / "1"
bitstring = 1*binary-digit
maskedBitString = bitstring","bitstring
Snir, Ramberg, Strassner, Cohen expires September 2000 51
Draft-ietf-policy-qos-info-model-00.txt March 2000
Each string entry is either:
1. A single bit string. Example: 00111010
2. A range of bit strings specifies using a bit string and a bit mask.
The bit string and mask PROPERTIES have the same number of bits
specified. The mask bit string specifies the significant bits in the
bit string value. For example, 110110, 100110 and 110111 would match
the maskedBitString 100110,101110 but 100100 would not.
NAME qpBitStringList
DESCRIPTION A list of bit string values
SYNTAX String
FORMAT BitString | maskedBitString
8.17. Class qosPolicyDNValue
This class is used to represent a single or set of Directory Name
values including wildcards. This value can be used in comparison to
reference 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 reference
values with wildcards.
DERIVED FROM qosPolicyValue
ABSTRACT False
PROPERTIES qpDNList[]
8.17.1. The Property qpDNList
This Property provides an unordered list of references each
representing a single object referenced.
An example of such reference is the directory server implementation of
the information model is the Distinguished Name (DN).
NAME qpDNList
DESCRIPTION A list of values with wildcards.
SYNTAX Reference
Snir, Ramberg, Strassner, Cohen expires September 2000 52
Draft-ietf-policy-qos-info-model-00.txt March 2000
8.18. Class qosPolicyPropertyValue
This class is used to represent a single or set of Property values. The
match operation used is dependent on the Property name. This value can
be used in conjunction with reference values carried in RSVP objects
[IDENT]. The Property name is used to specify which of the Properties
the pointer points to, should be compared to the list of values. For
example, suppose a User class has a multi-valued Property called
'member-of' that lists the names of groups this user belongs to.
Suppose this Property uses caseIgnoreMatch matching. A simple condition
can be constructed to match the reference carried in RSVP Identity
policy object to a qosPolicyPropertyValue with qpPropertyName="member-
of" and qpPropertyList = "group-A". An Identity policy object carrying
a reference "OU=Sales, CN=J. Smith, O=Widget Inc." will match this
simple condition only if J. Smith belongs to group-a.
The class definition is as follows:
NAME qosPolicyPropertyValue
DESCRIPTION This class is used to define an Property and a
list of its values.
DERIVED FROM qosPolicyValue
ABSTRACT False
PROPERTIES qpPropertyName, qpPropertyValueList[]
8.18.1. The Property qpPropertyName
NAME qpPropertyName
DESCRIPTION A name of a property the list of values should
be compared with
SYNTAX String
8.18.2. The Property qpPropertyValueList
NAME qpPropertyValueList
DESCRIPTION A list of property values. Each value is compared
to a value of the property specified by
qpPropertyName.
SYNTAX String
8.19. Class qosPolicyIntegerValue
This class provides a list of Integer and integer range values. Integer
of arbitrary size can be represented. For a given variable, the set of
Snir, Ramberg, Strassner, Cohen expires September 2000 53
Draft-ietf-policy-qos-info-model-00.txt March 2000
possible range of integer values allowed is specified via the
variable's qpValueConstraints Property.
The class definition is as follows:
NAME qosPolicyIntegerValue
DESCRIPTION This class is used to define Integer values
DERIVED FROM qosPolicyValue
ABSTRACT False
PROPERTIES qpIntegerList[]
8.19.1. The Property qpIntegerList
This Property provides an unordered list of integers and integer range
values. The format of the Property can take on of the following forms:
1. An integer value.
2. A range of integers. The range is specifies by a start integer and
an end integer separated by "..". The range includes all integers
between start and end integers, including the start and end integers.
To represent a range of integers that is not bounded, the reserved word
INFINITY can be used as the end range integer.
The ABNF definition [ABNF] is:
integer = 1*DIGIT | "INFINITY"
integerrange = integer".."integer
Using ranges the operators greater-than, greater-than-or-equal-to,
less-than and less-than-or-equal-to can be expressed.
NAME qpIntegerList
DESCRIPTION
SYNTAX String
FORMAT integer | integerrange
8.20. Class qosPolicyPHBSet
The qosPolicyPHBSet is an class that serves as a named container for
qosPolicyPHB objects. A single PHB set is associated with a QoS domain
using the domain property defined in the qosPolicyDomain object.
Instances of the qosNamedPolicyContainer class can override the
domain's PHB set by referencing another PHB set via the qosPolicyPHBSet
Property or by aggregation of a qosPolicyPHBSet object.
NAME qosPolicyPHBSet
DESCRIPTION This class defines a set of PHB definitions
DERIVED FROM policy
ABSTRACT False
PROPERTIES
Snir, Ramberg, Strassner, Cohen expires September 2000 54
Draft-ietf-policy-qos-info-model-00.txt March 2000
8.21. 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.
NAME qosPolicyPHB
DESCRIPTION This class defines a single service class in a PHB
set.
DERIVED FROM Policy (Core)
ABSTRACT True
PROPERTIES qpDSCP
8.21.1. The Property 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
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 extending
the QoS policy classes.
9.1. Extending qosPolicyValue
The qosPolicyValue class and its subclasses describe the common
value types used in QoS policy information model.
When other specific types are required, such as a floating-point
numbers, the required class should be derived from the
qosPolicyValue class and properties that contain the corresponding
values should be added.
Notice, that in many cases using the qosPolicyPropertyValue class
allows the definition of non-standard policy atoms with out 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 an unary condition.
Subclassing could be done using either PolicyCondition or
qosPolicySimpleCondition as the superclass.
Snir, Ramberg, Strassner, Cohen expires September 2000 55
Draft-ietf-policy-qos-info-model-00.txt March 2000
9.3. Extending qosPolicyAction
The Qos Policy actions 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.
Additional actions could be associated with QoS policy rules by
extending the PolicyAction class with the appropriate properties.
10. Security Considerations
See [PFSCHEMA].
11. Acknowledgments
12. References
[TERMS] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", Internet RFC 2119, March 1997.
[PFCORE] 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
Snir, Ramberg, Strassner, Cohen expires September 2000 56
Draft-ietf-policy-qos-info-model-00.txt March 2000
[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>
[QOSCAP] J. Strassner, W. Weiss, D. Durham, A. Westerinen,
Information Model for defining the QoS
Capabilities of Network Devices and Services,
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", RFC 2752, January 2000
[QOSSCHEMA] Y. Snir, Y Ramberg, J. Strassner, R. Cohen QoS
Policy Schema , qos-ietf-policy-info-model-00.txt
[RSVP-IS] J. Wroclawski, "The Use of RSVP with IETF Integrated
Services", RFC2210, September 1997
[CL] J. Wroclawski, "Specification of the Controlled-Load
Network Element Service", RFC2211, September 1997
[GS] S. Shenker, C. Partridge, R. Guerin, "Specification
of the Guaranteed Quality of Service", RFC2212,
September 1997
Snir, Ramberg, Strassner, Cohen expires September 2000 57
Draft-ietf-policy-qos-info-model-00.txt March 2000
13. Author's Addresses
Yoram Snir
Cisco Systems
4 Maskit Street
Herzliya Pituach, Israel 46766
Phone: +972-9-970-0085
Fax: +972-9-970-0219
E-mail: ysnir@cisco.com
Yoram Ramberg
Cisco Systems
4 Maskit Street
Herzliya Pituach, Israel 46766
Phone: +972-9-970-0081
Fax: +972-9-970-0219
E-mail: yramberg@cisco.com
John Strassner
Cisco Systems
Bldg 15
170 West Tasman Drive
San Jose, CA 95134
Phone: +1-408-527-1069
Fax: +1-408-527-2477
E-mail: johns@cisco.com
Ron Cohen
Cisco Systems
4 Maskit Street
Herzliya Pituach, Israel 46766
Phone: +972-9-970-0064
Fax: +972-9-970-0219
E-mail: ronc@cisco.com
14. Full Copyright Statement
This document and translations of it be copied and furnished to others,
and derivative works that comment on or otherwise explain it or assist
in its implementation be prepared, copied, published and distributed,
in whole or in part, without restriction of any kind, provided that the
above copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself not be
modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process PROPERTIES be followed, or as required to translate
it into languages other than English.
Snir, Ramberg, Strassner, Cohen expires September 2000 58
Draft-ietf-policy-qos-info-model-00.txt March 2000
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE
Snir, Ramberg, Strassner, Cohen expires September 2000 59
Datatracker
Report a datatracker bug
draft-ietf-policy-qos-info-model-00
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 3644.
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |