RFC 3644
Policy Quality of Service (QoS) Information Model
Pages: 73
Proposed Standard
Proposed Standard
Part 2 of 3 – Pages 23 to 48
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 Hierarchy3. 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 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 Action3.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 profile uses the same ordering rule. An RSVP message is accepted only if its TSPEC (FLOWSPEC) is either smaller or equal to the traffic profile. Only parameters specified in the traffic profile are compared. The GS FLOWSPEC is compared against the rate R and the slack term s. The term 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 value of the minimum policed unit m and the maximum value of the maximum packet size M. GS FLOWSPECs are summed by adding the Resv rate and minimizing the slack term s. These rules are used to compute the temporal state of admitted RSVP states matching the traffic class defined by the rule condition. This state is compared with the traffic profile to arrive at an admission decision when the scope of the QoSPolicyRSVPAdmissionAction is set to 'class'.5. Pre-Defined QoS-Related Variables
Pre-defined variables are necessary for ensuring interoperability among policy servers and policy management tools from different vendors. The purpose of this section is to define frequently used variables in QoS policy domains. Notice that this section only adds to the variable classes as defined in [PCIMe] and reuses the mechanism defined there. The QoS policy information model specifies a set of pre-defined variable classes to support a set of fundamental QoS terms that are commonly used to form conditions and actions and are missing from the [PCIMe]. Examples of these include RSVP related variables. All variable classes defined in this document extend the QoSPolicyRSVPVariable class (defined in this document), which itself extends the PolicyImplictVariable class, defined in [PCIMe]. Subclasses specify the data type and semantics of the policy variables. This document defines the following RSVP variable classes; for details, see their class definitions: RSVP related Variables: 1. QoSPolicyRSVPSourceIPv4Variable - The source IPv4 address of the RSVP signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP] objects. 2. QoSPolicyRSVPDestinationIPv4Variable - The destination port of the RSVP signaled flow, as defined in the RSVP PATH and RESV SESSION [RSVP] objects (for IPv4 traffic). 3. QoSPolicyRSVPSourceIPv6Variable - The source IPv6 address of the RSVP signaled flow, as defied in the RSVP PATH SENDER_TEMPLATE and RSVP RESV FILTER_SPEC [RSVP] objects.
4. QoSPolicyRSVPDestinationIPv6Variable - The destination port of
the RSVP signaled flow, as defined in the RSVP PATH and RESV
SESSION [RSVP] objects (for IPv6 traffic).
5. QoSPolicyRSVPSourcePortVariable - The source port of the RSVP
signaled flow, as defined in the RSVP PATH SENDER_TEMPLATE and
RSVP RESV FILTER_SPEC [RSVP] objects.
6. QoSPolicyRSVPDestinationPortVariable - The destination port of
the RSVP signaled flow, as defined in the RSVP PATH and RESV
SESSION [RSVP] objects.
7. QoSPolicyRSVPIPProtocolVariable - The IP Protocol of the RSVP
signaled flow, as defined in the RSVP PATH and RESV SESSION
[RSVP] objects.
8. QoSPolicyRSVPIPVersionVariable - The version of the IP addresses
carrying the RSVP signaled flow, as defined in the RSVP PATH and
RESV SESSION [RSVP] objects.
9. QoSPolicyRSVPDCLASSVariable - The DSCP value as defined in the
RSVP DCLASS [DCLASS] object.
10. QoSPolicyRSVPStyleVariable - The reservation style (FF, SE, WF)
as defined in the RSVP RESV message [RSVP].
11. QoSPolicyRSVPIntServVariable - The type of Integrated Service
(CL, GS, NULL) requested in the RSVP Reservation message, as
defined in the FLOWSPEC RSVP Object [RSVP].
12. QoSPolicyRSVPMessageTypeVariable - The RSVP message type, either
PATH, PATHTEAR, RESV, RESVTEAR, RESVERR, CONF or PATHERR [RSVP].
13. QoSPolicyRSVPPreemptionPriorityVariable - The RSVP reservation
priority as defined in [RFC3181].
14. QoSPolicyRSVPPreemptionDefPriorityVariable - The RSVP preemption
reservation defending priority as defined in [RFC3181].
15. QoSPolicyRSVPUserVariable - The ID of the user that initiated
the flow as defined in the User Locator string in the Identity
Policy Object [RFC3182].
16. QoSPolicyRSVPApplicationVariable - The ID of the application
that generated the flow as defined in the application locator
string in the Application policy object [RFC2872].
17. QoSPolicyRSVPAuthMethodVariable - The RSVP Authentication type
used in the Identity Policy Object [RFC3182].
Each class restricts the possible value types associated with a
specific variable. For example, the QoSPolicyRSVPSourcePortVariable
class is used to define the source port of the RSVP signaled flow.
The value associated with this variable is of type
PolicyIntegerValue.
6. QoS Related Values
Values are used in the information model as building blocks for the
policy conditions and policy actions, as described in [PCIM] and
[PCIMe]. This section defines a set of auxiliary values that are
used for QoS policies as well as other policy domains.
All value classes extend the PolicyValue class [PCIMe]. The
subclasses specify specific data/value types that are not defined in
[PCIMe].
This document defines the following two subclasses of the PolicyValue
class:
QoSPolicyDNValue This class is used to represent a single or
set of Distinguished Name [DNDEF] values,
including wildcards. A Distinguished Name
is a name that can be used as a key to
retrieve an object from a directory
service. This value can be used in
comparison to reference values carried in
RSVP policy objects, as specified in
[RFC3182]. This class is defined in
Section 8.31.
QoSPolicyAttributeValue A condition term uses the form "Variable
matches Value", and an action term uses the
form "set Variable to Value" ([PCIMe]).
This class is used to represent a single or
set of property values for the "Value" term
in either a condition or an action. This
value can be used in conjunction with
reference values carried in RSVP objects,
as specified in [RFC3182]. This class is
defined in section 8.12.
The property name is used to specify which of the properties in the
QoSPolicyAttributeValue class instance is being used in the condition
or action term. The value of this property or properties will then
be retrieved. In the case of a condition, a match (which is
dependent on the property name) will be used to see if the condition
is satisfied or not. In the case of an action, the semantics are
instead "set the variable to this value".
For example, suppose the "user" objects in the organization include
several properties, among them:
- First Name
- Last Name
- Login Name
- Department
- Title
A simple condition could be constructed to identify flows by their
RSVP user carried policy object. The simple condition: Last Name =
"Smith" to identify a user named Bill would be constructed in the
following way:
A SimplePolicyCondition [PCIMe] would aggregate a
QoSPolicyRSVPUserVariable [QPIM] object, via the
PolicyVariableInSimplePolicyCondition [PCIMe] aggregation.
The implicit value associated with this condition is created in the
following way:
A QoSPolicyAttributeValue object would be aggregated to the simple
condition object via a PolicyValueInSimplePolicyCondition [PCIMe].
The QoSPolicyAttributeValue attribute qpAttributeName would be set
to "last name" and the qpAttributeValueList would be set to
"Smith".
Another example is a condition that has to do with the user's
organizational department. It can be constructed in the exact same
way, by changing the QoSPolicyAttributeValue attribute
qpAttributeName to "Department" and the qpAttributeValueList would be
set to the particular value that is to be matched (e.g.,
"engineering" or "customer support"). The logical condition would
than be evaluated to true if the user belong to either the
engineering department or the customer support.
Notice that many multiple-attribute objects require the use of the
QoSPolicyAttributeValue class to specify exactly which of its
attributes should be used in the condition match operation.
7. Class Definitions: Association Hierarchy
The following sections define associations that are specified by QPIM.7.1. The Association "QoSPolicyTrfcProfInAdmissionAction"
This association links a QoSPolicyTrfcProf object (defined in section 8.9), modeling a specific traffic profile, to a QoSPolicyAdmissionAction object (defined in section 8.2). The class definition for this association is as follows: NAME QoSPolicyTrfcProfInAdmissionAction DESCRIPTION A class representing the association between a QoS admission action and its traffic profile. DERIVED FROM Dependency (See [PCIM]) ABSTRACT FALSE PROPERTIES Antecedent[ref QoSPolicyAdmissionAction [0..n]] Dependent[ref QoSPolicyTrfcProf [1..1]]7.1.1. The Reference "Antecedent"
This property is inherited from the Dependency association, defined in [PCIM]. Its type is overridden to become an object reference to a QoSPolicyAdmissionAction object. This represents the "independent" part of the association. The [0..n] cardinality indicates that any number of QoSPolicyAdmissionAction object(s) may use a given QoSPolicyTrfcProf.7.1.2. The Reference "Dependent"
This property is inherited from the Dependency association, and is overridden to become an object reference to a QoSPolicyTrfcProf object. This represents a specific traffic profile that is used by any number of QoSPolicyAdmissionAction objects. The [1..1] cardinality means that exactly one object of the QoSPolicyTrfcProf can be used by a given QoSPolicyAddmissionAction.7.2. The Association "PolicyConformAction"
This association links a policing action with an object defining an action to be applied to conforming traffic relative to the associated traffic profile. The class definition for this association is as follows:
NAME PolicyConformAction
DESCRIPTION A class representing the association between a
policing action and the action that should be
applied to traffic conforming to an associated
traffic profile.
DERIVED FROM Dependency (see [PCIM])
ABSTRACT FALSE
PROPERTIES Antecedent[ref QoSPolicyPoliceAction[0..n]]
Dependent[ref PolicyAction [1..1]]
7.2.1. The Reference "Antecedent"
This property is inherited from the Dependency association. Its type
is overridden to become an object reference to a
QoSPolicyPoliceAction object. This represents the "independent" part
of the association. The [0..n] cardinality indicates that any number
of QoSPolicyPoliceAction objects may be given the same action to be
executed as the conforming action.
7.2.2. The Reference "Dependent"
This property is inherited from the Dependency association, and is
overridden to become an object reference to a PolicyAction object.
This represents a specific policy action that is used by a given
QoSPolicyPoliceAction. The [1..1] cardinality means that exactly one
policy action can be used as the "conform" action for a
QoSPolicyPoliceAction. To execute more than one conforming action,
use the PolicyCompoundAction class to model the conforming action.
7.3. The Association "QoSPolicyExceedAction"
This association links a policing action with an object defining an
action to be applied to traffic exceeding the associated traffic
profile. The class definition for this association is as follows:
NAME QoSPolicyExceedAction
DESCRIPTION A class representing the association between a
policing action and the action that should be
applied to traffic exceeding an associated traffic
profile.
DERIVED FROM Dependency (see [PCIM])
ABSTRACT FALSE
PROPERTIES Antecedent[ref QoSPolicePoliceAction[0..n]]
Dependent[ref PolicyAction [1..1]]
7.3.1. The Reference "Antecedent"
This property is inherited from the Dependency association. Its type is overridden to become an object reference to a QoSPolicyPoliceAction object. This represents the "independent" part of the association. The [0..n] cardinality indicates that any number of QoSPolicyPoliceAction objects may be given the same action to be executed as the exceeding action.7.3.2. The Reference "Dependent"
This property is inherited from the Dependency association, and is overridden to become an object reference to a PolicyAction object. This represents a specific policy action that is used by a given QoSPolicyPoliceAction. The [1..1] cardinality means that a exactly one policy action can be used as the "exceed" action by a QoSPolicyPoliceAction. To execute more than one conforming action, use the PolicyCompoundAction class to model the exceeding action.7.4. The Association "PolicyViolateAction"
This association links a policing action with an object defining an action to be applied to traffic violating the associated traffic profile. The class definition for this association is as follows: NAME PolicyViolateAction DESCRIPTION A class representing the association between a policing action and the action that should be applied to traffic violating an associated traffic profile. DERIVED FROM Dependency (see [PCIM]) ABSTRACT FALSE PROPERTIES Antecedent[ref QoSPolicePoliceAction[0..n]] Dependent[ref PolicyAction [1..1]]7.4.1. The Reference "Antecedent"
This property is inherited from the Dependency association. Its type is overridden to become an object reference to a QoSPolicyPoliceAction object. This represents the "independent" part of the association. The [0..n] cardinality indicates that any number of QoSPolicyPoliceAction objects may be given the same action to be executed as the violating action.
7.4.2. The Reference "Dependent"
This property is inherited from the Dependency association, and is overridden to become an object reference to a PolicyAction object. This represents a specific policy action that is used by a given QoSPolicyPoliceAction. The [1..1] cardinality means that exactly one policy action can be used as the "violate" action by a QoSPolicyPoliceAction. To execute more than one violating action, use the PolicyCompoundAction class to model the conforming action.7.5. The Aggregation "QoSPolicyRSVPVariableInRSVPSimplePolicyAction"
A simple RSVP policy action is represented as a pair {variable, value}. This aggregation provides the linkage between a QoSPolicyRSVPSimpleAction instance and a single QoSPolicyRSVPVariable. The aggregation PolicyValueInSimplePolicyAction links the QoSPolicyRSVPSimpleAction to a single PolicyValue. The class definition for this aggregation is as follows: NAME QoSPolicyRSVPVariableInRSVPSimplePolicyAction DERIVED FROM PolicyVariableInSimplePolicyAction ABSTRACT FALSE PROPERTIES GroupComponent[ref QoSPolicyRSVPSimpleAction [0..n]] PartComponent[ref QoSPolicyRSVPVariable [1..1] ]7.5.1. The Reference "GroupComponent"
The reference property "GroupComponent" is inherited from PolicyComponent, and overridden to become an object reference to a QoSPolicyRSVPSimpleAction that contains exactly one QoSPolicyRSVPVariable. Note that for any single instance of the aggregation class QoSPolicyRSVPVariableInRSVPSimplePolicyAction, this property is single-valued. The [0..n] cardinality indicates that there may be 0, 1, or more QoSPolicyRSVPSimpleAction objects that contain any given RSVP variable object.7.5.2. The Reference "PartComponent"
The reference property "PartComponent" is inherited from PolicyComponent, and overridden to become an object reference to a QoSPolicyRSVPVariable that is defined within the scope of a QoSPolicyRSVPSimpleAction. Note that for any single instance of the association class QoSPolicyRSVPVariableInRSVPSimplePolicyAction, this property (like all reference properties) is single-valued. The
[1..1] cardinality indicates that a QoSPolicyRSVPVariableInRSVPSimplePolicyAction must have exactly one RSVP variable defined within its scope in order to be meaningful.
(page 48 continued on part 3)