roles to help the administrator map a given set of devices or
interfaces to a given set of policy constructs.
The policy constructs define the functionality required to perform
the desired traffic conditioning for particular traffic type(s). The
functions themselves depend on the particular type of networking
technologies chosen. For example, the DiffServ methodology
encourages us to aggregate similar types of traffic by assigning to
each traffic class a particular per-hop forwarding behavior on each
node. RSVP enables bandwidth to be reserved. These two
methodologies can be used separately or in conjunction, as defined by
the appropriate business policy. QPIM provides specific classes to
enable DiffServ and RSVP conditioning to be modeled.
The QPIM class definitions are used to create instances of various
policy constructs such as QoS actions and conditions that may be
hierarchically organized in rules and groups (PolicyGroup and
PolicyRule as defined in [PCIM] and [PCIMe]). Examples of policy
actions are rate limiting, jitter control and bandwidth allocation.
Policy conditions are constructs that can select traffic according to
a complex Boolean expression.
A hierarchical organization was chosen for two reasons. First, it
best reflects the way humans tend to think about complex policy.
Second, it enables policy to be easily mapped onto administrative
organizations, as the hierarchical organization of policy mirrors
most administrative organizations. It is important to note that the
policy definition process described here is done independent of any
specific device capabilities and configuration options. The policy
definition is completely independent from the details of the
implementation and the configuration interface of individual network
elements, as well as of the mechanisms that a network element can use
to condition traffic.
1.2. Design Goals and Their Ramifications
This section explains the QPIM design goals and how these goals are
addressed in this document. This section also describes the
ramifications of the design goals and the design decisions made in
developing QPIM.
1.2.1. Policy-Definition Oriented
The primary design goal of QPIM is to model policies controlling QoS
behavior in a way that as closely as possible reflects the way humans
tend to think about policy. Therefore, QPIM is designed to address
the needs of policy definition and management, and not device/network
configuration.
There are several ramifications of this design goal. First, QPIM
uses rules to define policies, based on [PCIM] and [PCIMe]. Second,
QPIM uses hierarchical organizations of policies and policy
information extensively. Third, QPIM does not force the policy
writer to specify all implementation details; rather, it assumes that
configuration agents (PDPs) interpret the policies and match them to
suit the needs of device-specific configurations.
1.2.1.1. Rule-based Modeling
Policy is best described using rule-based modeling as explained and
described in [PCIM] and [PCIMe]. A QoS policy rule is structured as
a condition clause and an action clause. The semantics are simple:
if the condition clause evaluates to TRUE, then a set of QoS actions
(specified in the action clause) can be executed. For example, the
rule:
"WEB traffic should receive at least 50% of the available
bandwidth resources or more, when more is available"
can be formalized as:
"<If protocol == HTTP> then <minimum BW = 50%>"
where the first angle bracketed clause is a traffic condition and the
second angle bracketed clause is a QoS action.
This approach differs from data path modeling that describes the
mechanisms that operates on the packet flows to achieve the desired
effect.
Note that the approach taken in QPIM specifically did NOT subclass
the PolicyRule class. Rather, it uses the SimplePolicyCondition,
CompoundPolicyCondition, SimplePolicyAction, and CompoundPolicyAction
classes defined in [PCIMe], as well as defining subclasses of the
following classes: Policy, PolicyAction, SimplePolicyAction,
PolicyImplicitVariable, and PolicyValue. Subclassing the PolicyRule
class would have made it more difficult to combine actions and
conditions defined within different functional domains [PCIMe] within
the same rules.
1.2.1.2. Organize Information Hierarchically
The organization of the information represented by QPIM is designed
to be hierarchical. To do this, QPIM utilizes the PolicySetComponent
aggregation [PCIMe] to provide an arbitrarily nested organization of
policy information. A policy group functions as a container of
policy rules and/or policy groups. A policy rule can also contain
policy rules and/or groups, enabling a rule/sub-rule relationship to
be realized.
The hierarchical design decision is based on the realization that it
is natural for humans to organize policy rules in groups. Breaking
down a complex policy into a set of simple rules is a process that
follows the way people tend to think and analyze systems. The
complexity of the abstract, business-oriented policy is simplified
and made into a hierarchy of simple rules and grouping of simple
rules.
The hierarchical information organization helps to simplify the
definition and readability of data instances based on QPIM.
Hierarchies can also serve to carry additional semantics for QoS
actions in a given context. An example, detailed in section 2.3,
demonstrates how hierarchical bandwidth allocation policies can be
specified in an intuitive form, without the need to specify complex
scheduler structures.
1.2.1.3. Goal-Oriented Policy Definition
QPIM facilitates goal-oriented QoS policy definition. This means
that the process of defining QoS policy is focused on the desired
effect of policies, as opposed to the means of implementing the
policy on network elements.
QPIM is intended to define a minimal specification of desired network
behavior. It is the role of device-specific configuration agents to
interpret policy expressed in a standard way and fill in the
necessary configuration details that are required for their
particular application. The benefit of using QPIM is that it
provides a common lingua franca that each of the device- and/or
vendor-specific configuration agents can use. This helps ensure a
common interpretation of the general policy as well as aid the
administrator in specifying a common policy to be implemented across
different devices. This is analogous to the fundamental object-
oriented paradigm of separating specification from implementation.
Using QPIM, traffic conditioning can be specified in a general manner
that can help different implementations satisfy a common goal.
For example, a valid policy may include only a single rule that
specifies that bandwidth should be reserved for a given set of
traffic flows. The rule does not need to include any of the various
other details that may be needed for implementing a scheduler that
supports this bandwidth allocation (e.g., the queue length required).
It is assumed that a PDP or the PEPs would fill in these details
using (for example) their default queue length settings. The policy
writer need only specify the main goal of the policy, making sure
that the preferred application receives enough bandwidth to operate
adequately.
1.2.2. Policy Domain Model
An important design goal of QPIM is to provide a means for defining
policies that span numerous devices. This goal differentiates QPIM
from device-level information models, which are designed for modeling
policy that controls a single device, its mechanisms and
capabilities.
This design goal has several ramifications. First, roles [PCIM] are
used to define policies across multiple devices. Second, the use of
abstract policies frees the policy definition process from having to
deal with individual device peculiarities, and leaves interpretation
and configuration to be modeled by PDPs or other configuration
agents. Third, QPIM allows extensive reuse of all policy building
blocks in multiple rules used within different devices.
1.2.2.1. Model QoS Policy in a Device- and Vendor-Independent Manner
QPIM models QoS policy in a way designed to be independent of any
particular device or vendor. This enables networks made up of
different devices that have different capabilities to be managed and
controlled using a single standard set of policies. Using such a
single set of policies is important because otherwise, the policy
will itself reflect the differences between different device
implementations.
1.2.2.2. Use Roles for Mapping Policy to Network Devices
The use of roles enables a policy definition to be targeted to the
network function of a network element, rather than to the element’s
type and capabilities. The use of roles for mapping policy to
network elements provides an efficient and simple method for compact
and abstract policy definition. A given abstract policy may be
mapped to a group of network elements without the need to specify
configuration for each of those elements based on the capabilities of
any one individual element.
The policy definition is designed to allow aggregating multiple
devices within the same role, if desired. For example, if two core
network interfaces operate at different rates, one does not have to
define two separate policy rules to express the very same abstract
policy (e.g., allocating 30% of the interface bandwidth to a given
preferred set of flows). The use of hierarchical context and
relative QoS actions in QPIM addresses this and other related
problems.
1.2.2.3. Reusability
Reusable objects, as defined by [PCIM] and [PCIMe], are the means for
sharing policy building blocks, thus allowing central management of
global concepts. QPIM provides the ability to reuse all policy
building blocks: variables and values, conditions and actions,
traffic profiles, and policy groups and policy rules. This provides
the required flexibility to manage large sets of policy rules over
large policy domains.
For example, the following rule makes use of centrally defined
objects being reused (referenced):
If <DestinationAddress == FinanceSubNet> then <DSCP =
MissionCritical>
In this rule, the condition refers to an object named FinanceSubNet,
which is a value (or possibly a set of values) defined and maintained
in a reusable objects container. The QoS action makes use of a value
named MissionCritical, which is also a reusable object. The
advantage of specifying a policy in this way is its inherent
flexibility. Given the above policy, whenever business needs require
a change in the subnet definition for the organization, all that’s
required is to change the reusable value FinanceSubNet centrally.
All referencing rules are immediately affected, without the need to
modify them individually. Without this capability, the repository
that is used to store the rules would have to be searched for all
rules that refer to the finance subnet, and then each matching rule’s
condition would have to be individually updated. This is not only
much less efficient, but also is more prone to error.
For a complete description of reusable objects, refer to [PCIM] and
[PCIMe].
1.2.3. Enforceable Policy
Policy defined by QPIM should be enforceable. This means that a PDP
can use QPIM’s policy definition in order to make the necessary
decisions and enforce the required policy rules. For example, RSVP
admission decisions should be made based on the policy definitions
specified by QPIM. A PDP should be able to map QPIM policy
definitions into PEP configurations, using either standard or
proprietary protocols.
QPIM is designed to be agnostic of any particular, vendor-dependent
technology. However, QPIM’s constructs SHOULD always be interpreted
so that policy-compliant behavior can be enforced on the network
under management. Therefore, there are three fundamental
requirements that QPIM must satisfy:
1. Policy specified by QPIM must be able to be mapped to actual
network elements.
2. Policy specified by QPIM must be able to control QoS network
functions without making reference to a specific type of device or
vendor.
3. Policy specified by QPIM must be able to be translated into
network element configuration.
QPIM satisfies requirements #1 and #2 above by using the concept of
roles (specifically, the PolicyRoles property, defined in PCIM). By
matching roles assigned to policy groups and to network elements, a
PDP (or other enforcement agent) can determine what policy should be
applied to a given device or devices.
The use of roles in mapping policy to network elements supports model
scalability. QPIM policy can be mapped to large-scale policy domains
by assigning a single role to a group of network elements. This can
be done even when the policy domain contains heterogeneous devices.
So, a small set of policies can be deployed to large networks without
having to re-specify the policy for each device separately. This
QPIM property is important for QoS policy management applications
that strive to ease the task of policy definition for large policy
domains.
Requirement #2 is also satisfied by making QPIM domain-oriented (see
[TERMS] for a definition of "domain"). In other words, the target of
the policy is a domain, as opposed to a specific device or interface.
Requirement #3 is satisfied by modeling QoS conditions and actions
that are commonly configured on various devices. However, QPIM is
extensible to allow modeling of actions that are not included in
QPIM.
It is important to note that different PEPs will have different
capabilities and functions, which necessitate different individual
configurations even if the different PEPs are controlled by the same
policy.
1.2.4. QPIM Covers Both Signaled And Provisioned QoS
The two predominant standards-based QoS methodologies developed so
far are Differentiated Services (DiffServ) and Integrated Services
(IntServ). The DiffServ provides a way to enforce policies that
apply to a large number of devices in a scalable manner. QPIM
provides actions and conditions that control the classification,
policing and shaping done within the differentiated service domain
boundaries, as well as actions that control the per-hop behavior
within the core of the DiffServ network. QPIM does not mandate the
use of DiffServ as a policy methodology.
Integrated services, together with its signaling protocol (RSVP),
provides a way for end nodes (and edge nodes) to request QoS from the
network. QPIM provides actions that control the reservation of such
requests within the network.
As both methodologies continue to evolve, QPIM does not attempt to
provide full coverage of all possible scenarios. Instead, QPIM aims
to provide policy control modeling for all major scenarios. QPIM is
designed to be extensible to allow for incorporation of control over
newly developed QoS mechanisms.
1.2.5. Interoperability for PDPs and Management Applications
Another design goal of QPIM is to facilitate interoperability among
policy systems such as PDPs and policy management applications. QPIM
accomplishes this interoperability goal by standardizing the
representation of policy. Producers and consumers of QoS policy need
only rely on QPIM-based schemata (and resulting data models) to
ensure mutual understanding and agreement on the semantics of QoS
policy.
For example, suppose that a QoS policy management application, built
by vendor A writes its policies based on the LDAP schema that maps
from QPIM to a directory implementation using LDAP. Now assume that
a separately built PDP from vendor B also relies on this same LDAP
schema derived from QPIM. Even though these are two vendors with two
different PDPs, each may read the schema of the other and
"understand" it. This is because both the management application and
the PDP were architected to comply with the QPIM specification. The
same is true with two policy management applications. For example,
vendor B’s policy application may run a validation tool that computes
whether there are conflicts within rules specified by the other
vendor’s policy management application.
Interoperability of QPIM producers/consumers is by definition at a
high level, and does not guarantee that the same policy will result
in the same PEP configuration. First, different PEPs will have
different capabilities and functions, which necessitate different
individual configurations even if the different PEPs are controlled
by the same policy. Second, different PDPs will also have different
capabilities and functions, and may choose to translate the high-
level QPIM policy differently depending on the functionality of the
PDP, as well as on the capabilities of the PEPs that are being
controlled by the PDP. However, the different configurations should
still result in the same network behavior as that specified by the
policy rules.
1.3. Modeling Abstract QoS Policies
This section provides a discussion of QoS policy abstraction and the
way QPIM addresses this issue.
As described above, the main goal of the QPIM is to create an
information model that can be used to help bridge part of the
conceptual gap between a human policy maker and a network element
that is configured to enforce the policy. Clearly this wide gap
implies several translation levels, from the abstract to the
concrete. At the abstract end are the business QoS policy rules.
Once the business rules are known, a network administrator must
interpret them as network QoS policy and represent this QoS policy by
using QPIM constructs. QPIM facilitates a formal representation of
QoS rules, thus providing the first concretization level: formally
representing humanly expressed QoS policy.
When a human business executive defines network policy, it is usually
done using informal business terms and language. For example, a
human may utter a policy statement that reads:
"human resources applications should have better QoS than simple
web applications"
This might be translated to a slightly more sophisticated form, such
as:
"traffic generated by our human resources applications should have
a higher probability of communicating with its destinations than
traffic generated by people browsing the WEB using non-mission-
critical applications"
While this statement clearly defines QoS policy at the business
level, it isn’t specific enough to be enforceable by network
elements. Translation to "network terms and language" is required.
On the other end of the scale, a network element functioning as a
PEP, such as a router, can be configured with specific commands that
determine the operational parameters of its inner working QoS
mechanisms. For example, the (imaginary) command "output-queue-depth
= 100" may be an instruction to a network interface card of a router
to allow up to 100 packets to be stored before subsequent packets are
discarded (not forwarded). On a different device within the same
network, the same instruction may take another form, because a
different vendor built that device or it has a different set of
functions, and hence implementation, even though it is from the same
vendor. In addition, a particular PEP may not have the ability to
create queues that are longer than, say, 50 packets, which may result
in a different instruction implementing the same QoS policy.
The first example illustrates ’abstract policy’, while the second
illustrates ’concrete configuration’. Furthermore, the first example
illustrates end-to-end policy, which covers the conditioning of
application traffic throughout the network. The second example
illustrates configuration for a particular PEP or a set thereof.
While an end-to-end policy statement can only be enforced by
configuration of PEPs in various parts of the network, the
information model of policy and that of the mechanisms that a PEP
uses to implement that policy are vastly different.
The translation process from abstract business policy to concrete PEP
configuration is roughly expressed as follows:
1. Informal business QoS policy is expressed by a human policy maker
(e.g., "All executives’ WEB requests should be prioritized ahead
of other employees’ WEB requests")
2. A network administrator analyzes the policy domain’s topology and
determines the roles of particular device interfaces. A role may
be assigned to a large group of elements, which will result in
mapping a particular policy to a large group of device interfaces.
3. The network administrator models the informal policy using QPIM
constructs, thus creating a formal representation of the abstract
policy. For example, "If a packet’s protocol is HTTP and its
destination is in the ’EXECUTIVES’ user group, then assign IPP 7
to the packet header".
4. The network administrator assigns roles to the policy groups
created in the previous step matching the network elements’ roles
assigned in step #2 above.
5. A PDP translates the abstract policy constructs created in step #3
into device-specific configuration commands for all devices
effected by the new policy (i.e., devices that have interfaces
that are assigned a role matching the new policy constructs’
roles). In this process, the PDP consults the particular devices’
capabilities to determine the appropriate configuration commands
implementing the policy.
6. For each PEP in the network, the PDP (or an agent of the PDP)
issues the appropriate device-specific instructions necessary to
enforce the policy.
QPIM, PCIM and PCIMe are used in step #3 above.
1.4. Rule Hierarchy
Policy is described by a set of policy rules that may be grouped into
subsets [PCIMe]. Policy rules and policy groups can be nested within
other policy rules, providing a hierarchical policy definition.
Nested rules are also called sub-rules, and we use both terms in this
document interchangeably. The aggregation PolicySetComponent
(defined in [PCIMe] is used to represent the nesting of a policy rule
or group in another policy rule.
The hierarchical policy rule definition enhances policy readability
and reusability. Within the QoS policy information model, hierarchy
is used to model context or scope for the sub-rule actions. Within
QPIM, bandwidth allocation policy actions and drop threshold actions
use this hierarchal context. First we provide a detailed example of
the use of hierarchy in bandwidth allocation policies. The
differences between flat and hierarchical policy representation are
discussed. The use of hierarchy in drop threshold policies is
described in a following subsection. Last but not least, the
restrictions on the use of rule hierarchies within QPIM are
described.
1.4.1. Use of Hierarchy Within Bandwidth Allocation Policies
Consider the following example where the informal policy reads:
On any interface on which these rules apply, guarantee at least
30% of the interface bandwidth to UDP flows, and at least 40% of
the interface bandwidth to TCP flows.
The QoS Policy information model follows the Policy Core information
model by using roles as a way to specify the set of interfaces on
which this policy applies. The policy does not assume that all
interfaces are run at the same speed, or have any other property in
common apart from being able to forward packets. Bandwidth is
allocated between UDP and TCP flows using percentages of the
available interface bandwidth. Assume that we have an available
interface bandwidth of 1 Mbits/sec. Then this rule will guarantee
300Kbits/sec to UDP flows. However, if the interface bandwidth was
instead only 64kbits/sec, then this rule would correspondingly
guarantee 19.2kb/sec.
This policy is modeled within QPIM using two policy rules of the
form:
If (IP protocol is UDP) THEN (guarantee 30% of available BW) (1)
If (IP protocol is TCP) THEN (guarantee 40% of available BW) (2)
Assume that these two rules are grouped within a PolicySet [PCIMe]
carrying the appropriate role combination. A possible implementation
of these rules within a PEP would be to use a Weighted-Round-Robin
scheduler with 3 queues. The first queue would be used for UDP
traffic, the second queue for TCP traffic and the third queue for the
rest of the traffic. The weights of the Weighted-Round-Robin
scheduler would be 30% for the first queue, 40% for the second queue