and 30% for the last queue.
The actions specifying the bandwidth guarantee implicitly assume that
the bandwidth resource being guaranteed is the bandwidth available at
the interface level. A PolicyRoleCollection is a class defined in
[PCIMe] whose purpose is to identify the set of resources (in this
example, interfaces) that are assigned to a particular role. Thus,
the type of managed elements aggregated within the
PolicyRoleCollection defines the bandwidth resource being controlled.
In our example, interfaces are aggregated within the
PolicyRoleCollection. Therefore, the rules specify bandwidth
allocation to all interfaces that match a given role. Other behavior
could be similarly defined by changing what was aggregated within the
PolicyRoleCollection.
Normally, a full specification of the rules would require indicating
the direction of the traffic for which bandwidth allocation is being
made. Using the direction variable defined in [PCIMe], the rules can
be specified in the following form:
If (direction is out)
If (IP protocol is UDP) THEN (guarantee 30% of available BW)
If (IP protocol is TCP) THEN (guarantee 40% of available BW)
where indentation is used to indicate rule nesting. To save space,
we omit the direction condition from further discussion.
Rule nesting provides the ability to further refine the scope of
bandwidth allocation within a given traffic class forwarded via these
interfaces. The example below adds two nested rules to refine
bandwidth allocation for UDP and TCP applications.
If (IP protocol is UDP) THEN (guarantee 30% of available BW) (1)
If (protocol is TFTP) THEN (guarantee 10% of available BW) (1a)
If (protocol is NFS) THEN (guarantee 40% of available BW) (1b)
If (IP protocol is TCP) THEN (guarantee 40% of available BW) (2)
If (protocol is HTTP) THEN guarantee 20% of available BW) (2a)
If (protocol is FTP) THEN (guarantee 30% of available BW) (2b)
Subrules 1a and 1b specify bandwidth allocation for UDP applications.
The total bandwidth resource being partitioned among UDP applications
is the bandwidth available for the UDP traffic class (i.e., 30%), not
the total bandwidth available at the interface level. Furthermore,
TFTP and NFS are guaranteed to get at least 10% and 40% of the total
available bandwidth for UDP, while other UDP applications aren’t
guaranteed to receive anything. Thus, TFTP and NFS are guaranteed to
get at least 3% and 12% of the total bandwidth. Similar logic
applies to the TCP applications.
The point of this section will be to show that a hierarchical policy
representation enables a finer level of granularity for bandwidth
allocation to be specified than is otherwise available using a non-
hierarchical policy representation. To see this, let’s compare this
set of rules with a non-hierarchical (flat) rule representation. In
the non-hierarchical representation, the guaranteed bandwidth for
TFTP flows is calculated by taking 10% of the bandwidth guaranteed to
UDP flows, resulting in 3% of the total interface bandwidth
guarantee.
If (UDP AND TFTP) THEN (guarantee 3% of available BW) (1a)
If (UDP AND NFS) THEN (guarantee 12% of available BW) (1b)
If (other UDP APPs) THEN (guarantee 15% of available BW) (1c)
If (TCP AND HTTP) THEN guarantee 8% of available BW) (2a)
If (TCP AND FTP) THEN (guarantee 12% of available BW) (2b)
If (other TCP APPs) THEN (guarantee 20% of available BW) (2c)
Are these two representations identical? No, bandwidth allocation is
not the same. For example, within the hierarchical representation,
UDP applications are guaranteed 30% of the bandwidth. Suppose a
single UDP flow of an application different from NFS or TFTP is
running. This application would be guaranteed 30% of the interface
bandwidth in the hierarchical representation but only 15% of the
interface bandwidth in the flat representation.
A two stage scheduler is best modeled by a hierarchical
representation whereas a flat representation may be realized by a
non-hierarchical scheduler.
A schematic hierarchical Weighted-Round-Robin scheduler
implementation that supports the hierarchical rule representation is
described below.
--UDP AND TFTP queue--10%
--UDP AND NFS queue--40%-Scheduler-30%--+
--Other UDP queue--50% A1 |
|
--TCP AND HTTP queue--20% |
--TCP AND FTP queue--30%-Scheduler-40%--Scheduler--Interface
--Other TCP queue--50% A2 | B
|
------------Non UDP/TCP traffic-----30%--+
Scheduler A1 extracts packets from the 3 UDP queues according to the
weight specified by the UDP sub-rule policy. Scheduler A2 extracts
packets from the 3 TCP queues specified by the TCP sub-rule policy.
The second stage scheduler B schedules between UDP, TCP and all other
traffic according to the policy specified in the top most rule level.
Another difference between the flat and hierarchical rule
representation is the actual division of bandwidth above the minimal
bandwidth guarantee. Suppose two high rate streams are being
forwarded via this interface: an HTTP stream and an NFS stream.
Suppose that the rate of each flow is far beyond the capacity of the
interface. In the flat scheduler implementation, the ratio between
the weights is 8:12 (i.e., HTTP:NFS), and therefore HTTP stream would
consume 40% of the bandwidth while NFS would consume 60% of the
bandwidth. In the hierarchical scheduler implementation the only
scheduler that has two queues filled is scheduler B, therefore the
ratio between the HTTP (TCP) stream and the NFS (UDP) stream would be
30:40, and therefore the HTTP stream would consume approximately 42%
of the interface bandwidth while NFS would consume 58% of the
interface bandwidth. In both cases both HTTP and NFS streams got
more than the minimal guaranteed bandwidth, but the actual rates
forwarded via the interface differ.
The conclusion is that hierarchical policy representation provides
additional structure and context beyond the flat policy
representation. Furthermore, policies specifying bandwidth
allocation using rule hierarchies should be enforced using
hierarchical schedulers where the rule hierarchy level is mapped to
the hierarchical scheduler level.
1.4.2. Use of Rule Hierarchy to Describe Drop Threshold Policies
Two major resources govern the per hop behavior in each node. The
bandwidth allocation resource governs the forwarding behavior of each
traffic class. A scheduler priority and weights are controlled by
the bandwidth allocation policies, as well as the (minimal) number of
queues needed for traffic separation. A second resource, which is
not controlled by bandwidth allocation policies, is the queuing
length and drop behavior. For this purpose, queue length and
threshold policies are used.
Rule hierarchy is used to describe the context on which thresholds
act. The policy rule’s condition describes the traffic class and the
rule’s actions describe the bandwidth allocation, the forwarding
priority and the queue length. If the traffic class contains
different drop precedence sub-classes that require different
thresholds within the same queue, the sub-rules actions describe
these thresholds.
Below is an example of the use of rule nesting for threshold control
purposes. Let’s look at the following rules:
If (protocol is FTP) THEN (guarantee 10% of available BW)
(queue length equals 40 packets)
(drop technique is random)
if (src-ip is from net 2.x.x.x) THEN min threshold = 30%
max threshold = 70%
if (src-ip is from net 3.x.x.x) THEN min threshold = 40%
max threshold = 90%
if (all other) THEN min threshold = 20%
max threshold = 60%
The rule describes the bandwidth allocation, the queue length and the
drop technique assigned to FTP flows. The sub-rules describe the
drop threshold priorities within those FTP flows. FTP packets
received from all networks apart from networks 2.x.x.x and 3.x.x.x
are randomly dropped when the queue threshold for FTP flows
accumulates to 20% of the queue length. Once the queue fills to 60%,
all these packets are dropped before queuing. The two other sub
rules provide other thresholds for FTP packets coming from the
specified two subnets. The Assured Forwarding per hop behavior (AF)
is another good example of the use of hierarchy to describe the
different drop preferences within a traffic class. This example is
provided in a later section.
1.4.3. Restrictions of the Use of Hierarchy Within QPIM
Rule nesting is used within QPIM for two important purposes:
1) Enhance clarity, readability and reusability.
2) Provide hierarchical context for actions.
The second point captures the ability to specify context for
bandwidth allocation, as well as providing context for drop threshold
policies.
When is a hierarchy level supposed to specify the bandwidth
allocation context, when is the hierarchy used for specifying the
drop threshold context, and when is it used merely for clarity and
reusability? The answer depends entirely on the actions. Bandwidth
control actions within a sub-rule specify how the bandwidth allocated
to the traffic class determined by the rule’s condition clause should
be further divided among the sub-rules. Drop threshold actions
control the traffic class’s queue drop behavior for each of the sub-
rules. The bandwidth control actions have an implicit pointer
saying: the bandwidth allocation is relative to the bandwidth
resources defined by the higher level rule. Drop threshold actions
have an implicit pointer saying: the thresholds are taken from the
queue resources defined by the higher level rule. Other actions do
not have such an implicit pointer, and for these actions hierarchy is
used only for reusability and readability purposes.
Each rule that includes a bandwidth allocation action implies that a
queue should be allocated to the traffic class defined by the rule’s
condition clause. Therefore, once a bandwidth allocation action
exists within the actions of a sub-rule, a threshold action within
this sub-rule cannot refer to thresholds of the parent rule’s queue.
Instead, it must refer to the queue of the sub-rule itself.
Therefore, in order to have a clear and unambiguous definition,
refinement of thresholds and refinements of bandwidth allocations
within sub-rules should be avoided. If both refinements are needed
for the same rule, threshold refinements and bandwidth refinements
rules should each be aggregated to a separate group, and these groups
should be aggregated under the policy rule, using the
PolicySetComponent aggregation.
1.5. Intended Audiences
QPIM is intended for several audiences. The following lists some of
the intended audiences and their respective uses:
1. Developers of QoS policy management applications can use this
model as an extensible framework for defining policies to control
PEPs and PDPs in an interoperable manner.
2. Developers of Policy Decision Point (PDP) systems built to control
resource allocation signaled by RSVP requests.
3. Developers of Policy Decision Points (PDP) systems built to create
QoS configuration for PEPs.
4. Builders of large organization data and knowledge bases who decide
to combine QoS policy information with other networking policy
information, assuming all modeling is based on [PCIM] and [PCIMe].
5. Authors of various standards may use constructs introduced in this
document to enhance their work. Authors of data models wishing to
map a storage specific technology to QPIM must use this document
as well.
2. Class Hierarchies
2.1. Inheritance Hierarchy
QPIM’s class and association inheritance hierarchies are rooted in
[PCIM] and [PCIMe]. Figures 2 and 3 depict these QPIM inheritance
hierarchies, while noting their relationships to [PCIM] and
[PCIMe]classes. Note that many other classes used to form QPIM
policies, such as SimplePolicyCondition, are defined in [PCIM] and
[PCIMe]. Thus, the following figures do NOT represent ALL necessary
classes and relationships for defining QPIM policies. Rather, the
designer using QPIM should use appropriate classes and relationships
from [PCIM] and [PCIMe] in conjunction with those defined below.
[ManagedElement] (abstract, PCIM)
|
+--Policy (abstract, PCIM)
| |
| +---PolicyAction (abstract, PCIM)
| | |
| | +---SimplePolicyAction (PCIMe)
| | | |
| | | +---QoSPolicyRSVPSimpleAction (QPIM)
| | |
| | +---QoSPolicyDiscardAction (QPIM)
| | |
| | +---QoSPolicyAdmissionAction (abstract, QPIM)
| | | |
| | | +---QoSPolicyPoliceAction (QPIM)
| | | |
| | | +---QoSPolicyShapeAction (QPIM)
| | | |
| | | +---QoSPolicyRSVPAdmissionAction (QPIM)
| | |
| | +---QoSPolicyPHBAction (abstract, QPIM)
| | |
| | +---QoSPolicyBandwidthAction (QPIM)
| | |
| | +---QoSPolicyCongestionControlAction (QPIM)
| |
| +---QoSPolicyTrfcProf (abstract, QPIM)
| | |
| | +---QoSPolicyTokenBucketTrfcProf (QPIM)
| | |
| | +---QoSPolicyIntServTrfcProf (QPIM)
| |
| |
| +---PolicyVariable (abstract, PCIMe)
| | |
| | +---PolicyImplicitVariable (abstract, PCIMe)
| | |
| | +---QoSPolicyRSVPVariable (abstract, QPIM)
| | |
| | +---QoSPolicyRSVPSourceIPv4Variable (QPIM)
| | |
| | +---QoSPolicyRSVPDestinationIPv4Variable (QPIM)
| | |
| | +---QoSPolicyRSVPSourceIPv6Variable (QPIM)
| | |
(continued on the next page)
(continued from the previous page)
[ManagedElement] (abstract, PCIM, repeated for convenience)
|
+--Policy (abstract, PCIM, repeated for convenience)
| |
| +---PolicyVariable (abstract, PCIMe)
| | |
| | +---PolicyImplicitVariable (abstract, PCIMe)
| | |
| | +---QoSPolicyRSVPVariable (abstract, QPIM)
| | |
| | +---QoSPolicyRSVPDestinationIPv6Variable (QPIM)
| | |
| | +---QoSPolicyRSVPSourcePortVariable (QPIM)
| | |
| | +---QoSPolicyRSVPDestinationPortVariable (QPIM)
| | |
| | +---QoSPolicyRSVPIPProtocolVariable (QPIM)
| | |
| | +---QoSPolicyRSVPIPVersionVariable (QPIM)
| | |
| | +---QoSPolicyRSVPDCLASSVariable (QPIM)
| | |
| | +---QoSPolicyRSVPStyleVariable (QPIM)
| | |
| | +---QoSPolicyRSVPDIntServVariable (QPIM)
| | |
| | +---QoSPolicyRSVPMessageTypeVariable (QPIM)
| | |
| | +---QoSPolicyRSVPPreemptionPriorityVariable (QPIM)
| | |
| | +---QoSPolicyRSVPPreemptionDefPriorityVariable (QPIM)
| | |
| | +---QoSPolicyRSVPUserVariable (QPIM)
| | |
| | +---QoSPolicyRSVPApplicationVariable (QPIM)
| | |
| | +---QoSPolicyRSVPAuthMethodVariable (QPIM)
| |
| +---PolicyValue (abstract, PCIMe)
| | |
| | +---QoSPolicyDNValue (QPIM)
| | |
| | +---QoSPolicyAttributeValue (QPIM)
Figure 2. The QPIM Class Inheritance Hierarchy
2.2. Relationship Hierarchy
Figure 3 shows the QPIM relationship hierarchy.
[unrooted] (abstract, PCIM)
|
+---Dependency (abstract)
| |
| +--- QoSPolicyTrfcProfInAdmissionAction (QPIM)
| |
| +--- QoSPolicyConformAction (QPIM)
| |
| +--- QoSPolicyExceedAction (QPIM)
| |
| +--- QoSPolicyViolateAction (QPIM)
| |
| +--- PolicyVariableInSimplePolicyAction
| | |
| | + QoSPolicyRSVPVariableInRSVPSimplePolicyAction
Figure 3. The QPIM Association Class Inheritance Hierarchy
3. QoS Actions
This section describes the QoS actions that are modeled by QPIM. QoS
actions are policy enforced network behaviors that are specified for
traffic selected by QoS conditions. QoS actions are modeled using
the classes PolicyAction (defined in [PCIM]), SimplePolicyAction
(defined in [PCIMe]) and several QoS actions defined in this document
that are derived from both of these classes, which are described
below.
Note that there is no discussion of PolicyRule, PolicyGroup, or
different types of PolicyCondition classes in this document. This is
because these classes are fully specified in [PCIM] and [PCIMe].
3.1. Overview
QoS policy based systems allow the network administrator to specify a
set of rules that control both the selection of the flows that need
to be provided with a preferred forwarding treatment, as well as
specifying the specific set of preferred forwarding behaviors. QPIM
provides an information model for specifying such a set of rules.
QoS policy rules enable controlling environments in which RSVP
signaling is used to request different forwarding treatment for
different traffic types from the network, as well as environments
where no signaling is used, but preferred treatment is desired for
some (but not all) traffic types. QoS policy rules also allow
controlling environments where strict QoS guarantees are provided to
individual flows, as well as environments where QoS is provided to
flow aggregates. QoS actions allow a PDP or a PEP to determine which
RSVP requests should be admitted before network resources are
allocated. QoS actions allow control of the RSVP signaling content
itself, as well as differentiation between priorities of RSVP
requests. QoS actions allow controlling the Differentiated Service
edge enforcement including policing, shaping and marking, as well as
the per-hop behaviors used in the network core. Finally, QoS actions
can be used to control mapping of RSVP requests at the edge of a
differentiated service cloud into per hop behaviors.
Four groups of actions are derived from action classes defined in
[PCIM] and [PCIMe]. The first QoS action group contains a single
action, QoSPolicyRSVPSimpleAction. This action is used for both RSVP
signal control and install actions. The second QoS action group
determines whether a flow or class of flows should be admitted. This
is done by specifying an appropriate traffic profile using the
QoSPolicyTrfcProf class and its subclasses. This set of actions also
includes QoS admission control actions, which use the
QoSPolicyAdmissionAction class and its subclasses. The third group
of actions control bandwidth allocation and congestion control
differentiations, which together specify the per-hop behavior
forwarding treatment. This group of actions includes the
QoSPolicyPHBAction class and its subclasses. The fourth QoS action
is an unconditional packet discard action, which uses the
QoSPolicyDiscardAction class. This action is used either by itself
or as a building block of the QoSPolicyPoliceAction.
Note that some QoS actions are not directly modeled. Instead, they
are modeled by using the class SimplePolicyAction with the
appropriate associations. For example, the three marking actions
(DSCP, IPP and CoS) are modeled by using the SimplePolicyAction
class, and associating that class with variables and values of the
appropriate type defined in [PCIMe].
3.2. RSVP Policy Actions
There are three types of decisions a PDP (either remote or within a
PEP) can make when it evaluates an RSVP request:
1. Admit or reject the request
2. Add or modify the request admission parameters
3. Modify the RSVP signaling content
The COPS for RSVP [RFC2749] specification uses different Decision
object types to model each of these decisions. QPIM follows the COPS
for RSVP specification and models each decision using a different
action class.
The QoSPolicyRSVPAdmissionAction controls the Decision Command and
Decision Flags objects used within COPS for RSVP. The
QoSPolicyRSVPAdmissionAction class, with its associated
QoSPolicyIntServTrfcProf class, is used to determine whether to
accept or reject a given RSVP request by comparing the RSVP request’s
TSPEC or RSPEC parameters against the traffic profile specified by
the QoSPolicyIntServTrfcProf. For a full description of the
comparison method, see section 4. Following the COPS for RSVP
specification, the admission decision has an option to both accept
the request and send a warning to the requester. The
QoSPolicyRSVPAdmissionAction can be used to limit the number of
admitted reservations as well.
The class QoSPolicyRSVPSimpleAction, which is derived from the
PolicySimpleAction class [PCIMe], can be used to control the two
other COPS RSVP decision types. The property qpRSVPActionType
designates the instance of the class to be either of type ’REPLACE’,
’STATELESS’, or both (’REPLACEANDSTATELESS’). For instances carrying
a qpRSVPActionType property value of ’REPLACE’, the action is
interpreted as a COPS Replace Decision, controlling the contents of
the RSVP message. For instances carrying a qpRSVPActionType property
value of ’STATELESS’, the action is interpreted as a COPS Stateless
Decision, controlling the admission parameters. If both of these
actions are required, this can be done by assigning the value
REPLACEANDSTATELESS to the qpRSVPActionType property.
This class is modeled to represent the COPS for RSVP Replace and
Stateless decisions. This similarity allows future use of these COPS
decisions to be directly controlled by a QoSPolicySimpleAction. The
only required extension might be the definition of a new RSVP
variable.
3.2.1. Example: Controlling COPS Stateless Decision
The QoSPolicyRSVPSimpleAction allows the specification of admission
parameters. It allows specification of the preemption priority
[RFC3181] of a given RSVP Reservation request. Using the preemption
priority value, the PEP can determine the importance of a Reservation
compared with already admitted reservations, and if necessary can
preempt lower priority reservations to make room for the higher