priority one. This class can also be used to control mapping of RSVP
requests to a differentiated services domain by setting the
QoSPolicyRSVPDCLASSVariable to the required value. This instructs
the PEP to mark traffic matching the Session and Sender
specifications carried in an RSVP request to a given DSCP value.
3.2.2. Example: Controlling the COPS Replace Decision
A Policy system should be able to control the information carried in
the RSVP messages. The QoSPolicyRSVPSimpleAction allows control of
the content of RSVP signaling messages. An RSVP message can carry a
preemption policy object [RFC3181] specifying the priority of the
reservation request in comparison to other requests. An RSVP message
can also carry a policy object for authentication purposes. An RSVP
message can carry a DCLASS [DCLASS] object that specifies to the
receiver or sender the particular DSCP value that should be set on
the data traffic. A COPS for RSVP Replacement Data Decision controls
the content of the RSVP message by specifying a set of RSVP objects
replacing or removing the existing ones.
3.3. Provisioning Policy Actions
The differentiated Service Architecture [DIFFSERV] was designed to
provide a scalable QoS differentiation without requiring any
signaling protocols running between the hosts and the network. The
QoS actions modeled in QPIM can be used to control all of the
building blocks of the Differentiated Service architecture, including
per-hop behaviors, edge classification, and policing and shaping,
without a need to specify the datapath mechanisms used by PEP
implementations. This provides an abstraction level hiding the
unnecessary details and allowing the network administrator to write
rules that express the network requirements in a more natural form.
In this architecture, as no signaling between the end host and the
network occurs before the sender starts sending information, the QoS
mechanisms should be set up in advance. This usually means that PEPs
need to be provisioned with the set of policy rules in advance.
Policing and Shaping actions are modeled as subclasses of the QoS
admission action. DSCP and CoS marking are modeled by using the
SimplePolicyAction ([PCIMe]) class associated with the appropriate
variables and values. Bandwidth allocation and congestion control
actions are modeled as subclasses of the QpQPolicyPHBAction, which is
itself a subclass PolicyAction class ([PCIM])
3.3.1. Admission Actions: Controlling Policers and Shapers
Admission Actions (QoSPolicyAdmissionAction and its subclasses) are
used to police and/or shape traffic.
Each Admission Action is bound to a traffic profile
(QoSPolicyTrfcProf) via the QoSPolicyTrfcProfInAdmissionAction
association. The traffic profile is used to meter traffic for
purposes of policing or shaping.
An Admission Action carries a scope property (qpAdmissionScope) that
is used to determine whether the action controls individual traffic
flows or aggregate traffic classes. The concepts of "flow" and
"traffic class" are explained in [DIFFSERV] using the terms
’microflow’ and ’traffic stream’. Roughly speaking, a flow is a set
of packets carrying an IP header that has the same values for source
IP, destination IP, protocol and layer 4 source and destination
ports. A traffic class is a set of flows. In QPIM, simple and
compound conditions can identify flows and/or traffic classes by
using Boolean terms over the values of IP header fields, including
the value of the ToS byte.
Thus, the interpretation of the scope property is as follows: If the
value of the scope property is 0 (per-flow), each (micro) flow that
can be positively matched with the rule’s condition is metered and
policed individually. If the value of the scope property is 1 (per-
class), all flows matched with the rule’s condition are metered as a
single aggregate and policed together.
The following example illustrates the use of the scope property.
Using two provisioned policing actions, the following policies can be
enforced:
- Make sure that each HTTP flow will not exceed 64kb/s
- Make sure that the aggregate rate of all HTTP flows will not
exceed 512Kb/s
Both policies are modeled using the same class QoSPolicyPoliceAction
(derived from QoSPolicyAdmissionAction). The first policy has its
scope property set to ’flow’, while the second policy has its scope
property set to ’class’. The two policies are modeled using a rule
with two police actions that, in a pseudo-formal definition, looks
like the following:
If (HTTP) Action1=police, Traffic Profile1=64kb/s, Scope1=flow
Action2=police, Traffic Profile2=512kb/s, Scope2=class
The provisioned policing action QoSPolicyPoliceAction has three
associations, QoSPolicyConformAction, QoSPolicyExceedAction and
QoSPolicyViolateAction.
To accomplish the desired result stated above, two possible modeling
techniques may be used: The two actions can be part of a single
policy rule using two PolicyActionInPolicyRule [PCIM] associations.
In this case the ExecutionStrategy property of the PolicyRule class
[PCIMe] SHOULD be set to "Do All" so that both individual flows and
aggregate streams are policed.
Alternatively, Action1 and Action2 could be aggregated in a
CompundPolicyAction instance using the PolicyActionInPolicyAction
aggregations [PCIMe]. In this case, in order for both individual
flows and aggregate traffic classes to be policed, the
ExecutionStrategy property of the CompoundPolicyAction class [PCIMe]
SHOULD be set to "Do All".
The policing action is associated with a three-level token bucket
traffic profile carrying rate, burst and excess-burst parameters.
Traffic measured by a meter can be classified as conforming traffic
when the metered rate is below the rate defined by the traffic
profile, as excess traffic when the metered traffic is above the
normal burst and below the excess burst size, and violating traffic
when rate is above the maximum excess burst.
The [DIFF-MIB] defines a two-level meter, and provides a means to
combine two-level meters into more complex meters. In this document,
a three-level traffic profile is defined. This allows construction
of both two-level meters as well as providing an easier definition
for three-level meters needed for creating AF [AF] provisioning
actions.
A policing action that models three-level policing MUST associate
three separate actions with a three-level traffic profile. These
actions are a conforming action, an exceeding action and a violating
action. A policing action that models two-level policing uses a
two-level traffic profile and associates only conforming and
exceeding actions. A policing action with a three-level traffic
profile that specifies an exceed action but does not specify a
violate action implies that the action taken when the traffic is
above the maximum excess burst is identical to the action taken when
the traffic is above the normal burst. A policer determines whether
the profile is being met, while the actions to be performed are
determined by the associations QoSPolicyXXXAction.
Shapers are used to delay some or all of the packets in a traffic
stream, in order to bring the stream into compliance with a traffic
profile. A shaper usually has a finite-sized buffer, and packets may
be discarded if there is not sufficient buffer space to hold the
delayed packets. Shaping is controlled by the QoSPolicyShapeAction
class. The only required association is a traffic profile that
specifies the rate and burst parameters that the outgoing flows
should conform with.
3.3.2. Controlling Markers
Three types of marking control actions are modeled in QPIM:
Differentiated Services Code Point (DSCP) assignment, IP Precedence
(IPP) assignment and layer-2 Class of Service (CoS) assignment.
These assignment actions themselves are modeled by using the
SimplePolicyAction class associated with the appropriate variables
and values.
DSCP assignment sets ("marks" or "colors") the DS field of a packet
header to a particular DS Code Point (DSCP), adding the marked packet
to a particular DS behavior aggregate.
When used in the basic form, "If <condition> then ’DCSP = ds1’", the
assignment action assigns a DSCP value (ds1) to all packets that
result in the condition being evaluated to true.
When used in combination with a policing action, a different
assignment action can be issued via each of the ’conform’, ’exceed’
and ’violate’ action associations. This way, one may select a PHB in
a PHB group according to the state of a meter.
The semantics of the DSCP assignment is encapsulated in the pairing
of a DSCP variable and a DSCP value within a single
SimplePolicyAction instance via the appropriate associations.
IPP assignment sets the IPP field of a packet header to a particular
IPP value (0 through 7). The semantics of the IPP assignment is
encapsulated in the pairing of a ToS variable (PolicyIPTosVariable)
and a bit string value () (defined in [PCIMe]) within a single
SimplePolicyAction instance via the appropriate associations. The
bit string value is used in its masked bit string format. The mask
indicates the relevant 3 bits of the IPP sub field within the ToS
byte, while the bit string indicates the IPP value to be set.
CoS assignments control the mapping of a per-hop behavior to a
layer-2 Class of Service. For example, mapping of a set of DSCP
values into a 802.1p user priority value can be specified using a
rule with a condition describing the set of DSCP values, and a CoS
assignment action that specifies the required mapping to the given
user priority value. The semantics of the CoS assignment is
encapsulated in the pairing of a CoS variable and a CoS value
(integer in the range of 0 through 7) within a single
SimplePolicyAction instance via the appropriate associations.
3.3.3. Controlling Edge Policies - Examples
Assuming that the AF1 behavior aggregate is enforced within a DS
domain, policy rules on the boundaries of the network should mark
packets to one of the AF1x DSCPs, depending on the conformance of the
traffic to a predetermined three-parameter traffic profile. QPIM
models such AF1 policing action as defined in Figure 4.
+-----------------------+ +------------------------------+
| QoSPolicyPoliceAction |====| QoSPolicyTokenBucketTrfcProf |
| scope = class | | rate = x, bc = y, be = z |
+-----------------------+ +------------------------------+
* @ #
* @ #
* @ +--------------------+ +--------------------------+
* @ | SimplePolicyAction |---| PolicyIntegerValue -AF13 |
* @ +--------------------+ +--------------------------+
* @
* +--------------------+ +---------------------------+
* | SimplePolicyAction |---| PolicyIntegerValue - AF12 |
* +--------------------+ +---------------------------+
*
+--------------------+ +---------------------------+
| SimplePolicyAction |---| PolicyIntegerValue - AF11 |
+--------------------+ +---------------------------+
Association and Aggregation Legend:
**** QoSPolicyConformAction
@@@@ QoSPolicyExceedAction
#### QoSPolicyViolateAction
==== QoSTrfcProfInAdmissionAction
---- PolicyValueInSimplePolicyAction ([PCIMe])
&&&& PolicyVariableInSimplePolicyAction ([PCIMe], not shown)
Figure 4. AF Policing and Marking
The AF policing action is composed of a police action, a token bucket
traffic profile and three instances of the SimplePolicyAction class.
Each of the simple policy action instances models a different marking
action. Each SimplePolicyAction uses the aggregation
PolicyVariableInSimplePolicyAction to specify that the associated
PolicyDSCPVariable is set to the appropriate integer value. This is
done using the PolicyValueInSimplePolicyAction aggregation. The
three PolicyVariableInSimplePolicyAction aggregations which connect
the appropriate SimplePolicyActions with the appropriate DSCP
Variables, are not shown in this figure for simplicity. AF11 is
marked on detecting conforming traffic; AF12 is marked on detecting
exceeding traffic, and AF13 on detecting violating traffic.
The second example, shown in Figure 5, is the simplest policing
action. Traffic below a two-parameter traffic profile is unmodified,
while traffic exceeding the traffic profile is discarded.
+-----------------------+ +------------------------------+
| QoSPolicyPoliceAction |====| QoSPolicyTokenBucketTrfcProf |
| scope = class | | rate = x, bc = y |
+-----------------------+ +------------------------------+
@
@
+-------------------------+
| QoSPolicyDiscardAction |
+-------------------------+
Association and Aggregation Legend:
**** QoSPolicyConformAction (not used)
@@@@ QoSPolicyExceedAction
#### QoSPolicyViolateAction (not used)
==== QoSTrfcProfInAdmissionAction
Figure 5. A Simple Policing Action
3.4. Per-Hop Behavior Actions
A Per-Hop Behavior (PHB) is a description of the externally
observable forwarding behavior of a DS node applied to a particular
DS behavior aggregate [DIFFSERV]. The approach taken here is that a
PHB action specifies both observable forwarding behavior (e.g., loss,
delay, jitter) as well as specifying the buffer and bandwidth
resources that need to be allocated to each of the behavior
aggregates in order to achieve this behavior. That is, a rule with a
set of PHB actions can specify that an EF packet must not be delayed
more than 20 msec in each hop. The same rule may also specify that
EF packets need to be treated with preemptive forwarding (e.g., with
priority queuing), and specify the maximum bandwidth for this class,
as well as the maximum buffer resources. PHB actions can therefore
be used both to represent the final requirements from PHBs and to
provide enough detail to be able to map the PHB actions into a set of
configuration parameters to configure queues, schedulers, droppers
and other mechanisms.
The QoSPolicyPHBAction abstract class has two subclasses. The
QoSPolicyBandwidthAction class is used to control bandwidth, delay
and forwarding behavior, while the QoSPolicyCongestionControlAction
class is used to control queue size, thresholds and congestion
algorithms. The qpMaxPacketSize property of the QoSPolicyPHBAction
class specifies the packet size in bytes, and is needed when
translating the bandwidth and congestion control actions into actual
implementation configurations. For example, an implementation
measuring queue length in bytes will need to use this property to map
the qpQueueSize property into the desired queue length in bytes.
3.4.1. Controlling Bandwidth and Delay
QoSPolicyBandwidthAction allows specifying the minimal bandwidth that
should be reserved for a class of traffic. The property
qpMinBandwidth can be specified either in Kb/sec or as a percentage
of the total available bandwidth. The property qpBandwidthUnits is
used to determine whether percentages or fixed values are used.
The property qpForwardingPriority is used whenever preemptive
forwarding is required. A policy rule that defines the EF PHB should
indicate a non-zero forwarding priority. The qpForwardingPriority
property holds an integer value to enable multiple levels of
preemptive forwarding where higher values are used to specify higher
priority.
The property qpMaxBandwidth specifies the maximum bandwidth that
should be allocated to a class of traffic. This property may be
specified in PHB actions with non-zero forwarding priority in order
to guard against starvation of other PHBs.
The properties qpMaxDelay and qpMaxJitter specify limits on the per-
hop delay and jitter in milliseconds for any given packet within a
traffic class. Enforcement of the maximum delay and jitter may
require use of preemptive forwarding as well as minimum and maximum
bandwidth controls. Enforcement of low max delay and jitter values
may also require fragmentation and interleave mechanisms over low
speed links.
The Boolean property qpFairness indicates whether flows should have a
fair chance to be forwarded without drop or delay. A way to enforce
a bandwidth action with qpFairness set to TRUE would be to build a
queue per flow for the class of traffic specified in the rule’s
filter. In this way, interactive flows like terminal access will not
be queued behind a bursty flow (like FTP) and therefore have a
reasonable response time.
3.4.2. Congestion Control Actions
The QoSPolicyCongestionControlAction class controls queue length,
thresholds and congestion control algorithms.
A PEP should be able to keep in its queues qpQueueSize packets
matching the rule’s condition. In order to provide a link-speed
independent queue size, the qpQueueSize property can also be measured
in milliseconds. The time interval specifies the time needed to
transmit all packets within the queue if the link speed is dedicated
entirely for transmission of packets within this queue. The property
qpQueueSizeUnit determines whether queue size is measured in number
of packets or in milliseconds. The property qpDropMethod selects
either tail-drop, head-drop or random-drop algorithms. The set of
maximum and minimum threshold values can be specified as well, using
qpDropMinThresholdValue and qpDropMaxThresholdValue properties,
either in packets or in percentage of the total available queue size
as specified by the qpDropThresholdUnits property.
3.4.3. Using Hierarchical Policies: Examples for PHB Actions
Hierarchical policy definition is a primary tool in the QoS Policy
information model. Rule nesting introduced in [PCIMe] allows
specification of hierarchical policies controlling RSVP requests,
hierarchical shaping, policing and marking actions, as well as
hierarchical schedulers and definition of the differences in PHB
groups.
This example provides a set of rules that specify PHBs enforced
within a Differentiated Service domain. The network administrator
chose to enforce the EF, AF11 and AF13 and Best Effort PHBs. For
simplicity, AF12 is not differentiated. The set of rules takes the
form:
If (EF) then do EF actions
If (AF1) then do AF1 actions
If (AF11) then do AF11 actions
If (AF12) then do AF12 actions
If (AF13) then do AF13 actions
If (default) then do Default actions.
EF, AF1, AF11, AF12 and AF13 are conditions that filter traffic
according to DSCP values. The AF1 condition matches the entire AF1
PHB group including the AF11, AF12 and AF13 DSCP values. The default
rule specifies the Best Effort rules. The nesting of the AF1x rules
within the AF1 rule specifies that there are further refinements on
how AF1x traffic should be treated relative to the entire AF1 PHB
group. The set of rules reside in a PolicyGroup with a decision
strategy property set to ’FirstMatching’.
The class instances below specify the set of actions used to describe
each of the PHBs. Queue sizes are not specified, but can easily be
added to the example.
The actions used to describe the Best Effort PHB are simple. No
bandwidth is allocated to Best Effort traffic. The first action
specifies that Best Effort traffic class should have fairness.
QoSPolicyBandwidthAction BE-B:
qpFairness: TRUE
The second action specifies that the congestion algorithm for the
Best Effort traffic class should be random, and specifies the
thresholds in percentage of the default queue size.
QoSPolicyCongestionControlAction BE-C:
qpDropMethod: random
qpDropThresholdUnits %
qpDropMinThreshold: 10%
qpDropMaxThreshold: 70%
EF requires preemptive forwarding. The maximum bandwidth is also
specified to make sure that the EF class does not starve the other
classes. EF PHB uses tail drop as the applications using EF are
supposed to be UDP-based and therefore would not benefit from a
random dropper.
QoSPolicyBandwidthAction EF-B:
qpForwardingPriority: 1
qpBandwidthUnits: %
qpMaxBandwidth 50%
qpFairness: FALSE
QoSPolicyCongestionControlAction EF-C:
qpDropMethod: tail-drop
qpDropThresholdUnits packet
qpDropMaxThreshold: 3 packets
The AF1 actions define the bandwidth allocations for the entire PHB
group:
QoSPolicyBandwidthAction AF1-B:
qpBandwidthUnits: %
qpMinBandwidth: 30%
The AF1i actions specifies the differentiating refinement for the
AF1x PHBs within the AF1 PHB group. The different threshold values
provide the difference in discard probability of the AF1x PHBs within
the AF1 PHB group.
QoSPolicyCongestionControlAction AF11-C:
qpDropMethod: random
qpDropThresholdUnits packet
qpDropMinThreshold: 6 packets
qpDropMaxThreshold: 16 packets
QoSPolicyCongestionControlAction AF12-C:
qpDropMethod: random
qpDropThresholdUnits packet
qpDropMinThreshold: 4 packets
qpDropMaxThreshold: 13 packets
QoSPolicyCongestionControlAction AF13-C:
qpDropMethod: random
qpDropThresholdUnits packet
qpDropMinThreshold: 2 packets
qpDropMaxThreshold: 10 packets
4. Traffic Profiles
Meters measure the temporal state of a flow or a set of flows against
a traffic profile. In this document, traffic profiles are modeled by
the QoSPolicyTrfcProf class. The association QoSPolicyTrfcProf
InAdmissionAction binds the traffic profile to the admission action
using it. Two traffic profiles are derived from the abstract class
QoSPolicyTrfcProf. The first is a Token Bucket provisioning traffic
profile carrying rate and burst parameters. The second is an RSVP
traffic profile, which enables flows to be compared with RSVP TSPEC
and FLOWSPEC parameters.
4.1. Provisioning Traffic Profiles
Provisioned Admission Actions, including shaping and policing, are
specified using a two- or three-parameter token bucket traffic
profile. The QoSPolicyTokenBucketTrfcProf class includes the
following properties:
1. Rate measured in kbits/sec
2. Normal burst measured in bytes
3. Excess burst measured in bytes
Rate determines the long-term average transmission rate. Traffic
that falls under this rate is conforming, as long as the normal burst
is not exceeded at any time. Traffic exceeding the normal burst but
still below the excess burst is exceeding the traffic profile.
Traffic beyond the excess burst is said to be violating the traffic
profile.
Excess burst size is measured in bytes in addition to the burst size.
A zero excess burst size indicates that no excess burst is allowed.
4.2. RSVP traffic profiles
RSVP admission policy can condition the decision whether to accept or
deny an RSVP request based on the traffic specification of the flow
(TSPEC) or the amount of QoS resources requested (FLOWSPEC). The
admission decision can be based on matching individual RSVP requests
against a traffic profile or by matching the aggregated sum of all
FLOWSPECs (TSPECs) currently admitted, as determined by the
qpAdmissionScope property in an associated
QoSPolicyRSVPAdmissionAction.
The QoSPolicyIntservTrfcProf class models both such traffic profiles.
This class has the following properties:
1. Token Rate (r) measured in bits/sec
2. Peak Rate (p) measured in bits/sec
3. Bucket Size (b) measured in bytes
4. Min Policed unit (m) measured in bytes
5. Max packet size (M) measured in bytes
6. Resv Rate (R) measured in bits/sec
7. Slack term (s) measured in microseconds
The first five parameters are the traffic specification parameters
used in the Integrated Service architecture ([INTSERV]). These
parameters are used to define a sender TSPEC as well as a FLOWSPEC
for the Controlled-Load service [CL]. For a definition and full
explanation of their meanings, please refer to [RSVP-IS].
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). The TSPEC
A is larger than the TSPEC B if and only if rA>rB, pA>pB, bA>bB,
mA<mB and MA>MB. A TSPEC (FLOWSPEC) measured against a traffic