classes. The complete IntServ device model will, as we have
indicated earlier, be addressed in a subsequent document.
This document models a small subset of the QoS policy problem, in
hopes of constructing a methodology that can be adapted for other
aspects of QoS in particular, and of policy construction in general.
The focus in this document is on QoS for devices that implement
traffic conditioning in the datapath.
DiffServ operates exclusively in the datapath. It has all of the
same components of the IntServ datapath, with two major differences.
First, DiffServ classifies packets based solely on their DSCP field,
whereas IntServ examines a subset of a standard flow’s addressing 5-
tuple. The exception to this rule occurs in a router or host at the
boundary of a DiffServ domain. A device in this position may examine
a packet’s DSCP, its addressing 5-tuple, other fields in the packet,
or even information wholly outside the packet, in determining the
DSCP value with which to mark the packet prior to its transfer into
the DiffServ domain. However, routers in the interior of a DiffServ
domain will only need to classify based on the DSCP field.
The second difference between IntServ and DiffServ is that the
signaling protocol used in IntServ (e.g., RSVP) affects the
configuration of the datapath in a more dynamic fashion. This is
because each newly admitted RSVP reservation requires a
reconfiguration of the datapath. In contrast, DiffServ requires far
fewer changes to the datapath after the Per Hop Behaviors (PHBs) have
been configured.
The approach advocated in this document for the creation of policies
that control the various QoS mechanisms of networking devices is to
first identify the attributes with which policies are to be
constructed. These attributes are the parameters used in expressions
that are necessary to construct policies. There is also a parallel
desire to define the operators, relations, and precedence constructs
necessary to construct the conditions and actions that constitute
these policies. However, these efforts are beyond the scope of this
document.
2.2. Specific Needs Of DiffServ
DiffServ-specific rules focus on two particular areas: the core and
the edges of the network. As explained in the DiffServ Architecture
document [R2475], devices at the edge of the network classify traffic
into different traffic streams. The core of the network then
forwards traffic from different streams by using a set of Per Hop
Behaviors (PHBs). A DSCP identifies each PHB. The DSCP is part of
the IP header of each packet (as described in [R2474]). This enables
multiple traffic streams to be aggregated into a small number of
aggregated traffic streams, where each aggregate traffic stream is
identified by a particular DSCP, and forwarded using a particular
PHB.
The attributes used to manipulate QoS capabilities in the core of the
network primarily address the behavioral characteristics of each
supported PHB. At the edges of the DiffServ network, the additional
complexities of flow classification, policing, RSVP mappings,
remarkings, and other factors have to be considered. Additional
modeling will be required in this area. However, first, the
standards for edges of the DiffServ network need more detail - to
allow the edges to be incorporated into the policy model.
2.3. Specific Needs Of IntServ
This document focuses exclusively on the forwarding aspects of
network QoS. Therefore, while the forwarding aspects of IntServ are
considered, the management of IntServ is not considered. This topic
will be addressed in a future document.
3. Methodology
There is a clear need to define attributes and behavior that together
define how traffic should be conditioned. This document defines a
set of classes and relationships that represent the QoS mechanisms
used to condition traffic; [QPIM] is used to define policies to
control the QoS mechanisms defined in this document.
However, some very basic issues need to be considered when combining
these documents. Considering these issues should help in
constructing a schema for managing the operation and configuration of
network QoS mechanisms through the use of QoS policies.
3.1. Level of Abstraction for Expressing QoS Policies
The first issue requiring consideration is the level of abstraction
at which QoS policies should be expressed. If we consider policies
as a set of rules used to react to events and manipulate attributes
or generate new events, we realize that policy represents a continuum
of specifications that relate business goals and rules to the
conditioning of traffic done by a device or a set of devices. An
example of a business level policy might be: from 1:00 pm PST to 7:00
am EST, sell off 40% of the network capacity on the open market. In
contrast, a device-specific policy might be: if the queue depth grows
at a geometric rate over a specified duration, trigger a potential
link failure event.
A general model for this continuum is shown in Figure 1 below.
+---------------------+
| High-Level Business | Not directly related to device
| Policies | operation and configuration details
+---------------------+
|
|
+---------V-----------+
| Device-Independent | Translate high-level policies to
| Policies | generic device operational and
+---------------------+ configuration information
|
|
+---------V-----------+
| Device-Dependent | Translate generic device information
| Policies | to specify how particular devices
+---------------------+ should operate and be configured
Figure 1. The Policy Continuum
High-level business policies are used to express the requirements of
the different applications, and prioritize which applications get
"better" treatment when the network is congested. The goal, then, is
to use policies to relate the operational and configuration needs of
a device directly to the business rules that the network
administrator is trying to implement in the network that the device
belongs to.
Device-independent policies translate business policies into a set of
generalized operational and configuration policies that are
independent of any specific device, but dependent on a particular set
of QoS mechanisms, such as random early detection (RED) dropping or
weighted round robin scheduling. Not only does this enable different
types of devices (routers, switches, hosts, etc.) to be controlled by
QoS policies, it also enables devices made by different vendors that
use the same types of QoS mechanisms to be controlled. This enables
these different devices to each supply the correct relative
conditioning to the same type of traffic.
In contrast, device-dependent policies translate device-independent
policies into ones that are specific for a given device. The reason
that a distinction is made between device-independent and device-
dependent policies is that in a given network, many different devices
having many different capabilities need to be controlled together.
Device-independent policies provide a common layer of abstraction for
managing multiple devices of different capabilities, while device-
dependent policies implement the specific conditioning that is
required. This document provides a common set of abstractions for
representing QoS mechanisms in a device-independent way.
This document is focused on the device-independent representation of
QoS mechanisms. QoS mechanisms are modeled in sufficient detail to
provide a common device-independent representation of QoS policies.
They can also be used to provide a basis for specialization, enabling
each vendor to derive a set of vendor-specific classes that represent
how traffic conditioning is done for that vendor’s set of devices.
3.2. Specifying Policy Parameters
Policies are a function of parameters (attributes) and operators
(boolean, arithmetic, relational, etc.). Therefore, both need to be
defined as part of the same policy in order to correctly condition
the traffic. If the parameters of the policy are specified too
narrowly, they will reflect the individual implementations of QoS in
each device. As there is currently little consensus in the industry
on what the correct implementation model for QoS is, most defined
attributes would only be applicable to the unique characteristics of
a few individual devices. Moreover, standardizing all of these
potential implementation alternatives would be a never-ending task as
new implementations continued to appear on the market.
On the other hand, if the parameters of the policy are specified too
broadly, it is impossible to develop meaningful policies. For
example, if we concentrate on the so-called Olympic set of policies,
a business policy like "Bob gets Gold Service," is clearly
meaningless to the large majority of existing devices. This is
because the device has no way of determining who Bob is, or what QoS
mechanisms should be configured in what way to provide Gold service.
Furthermore, Gold service may represent a single service, or it may
identify a set of services that are related to each other. In the
latter case, these services may have different conditioning
characteristics.
This document defines a set of parameters that fit into a canonical
model for modeling the elements in the forwarding path of a device
implementing QoS traffic conditioning. By defining this model in a
device-independent way, the needed parameters can be appropriately
abstracted.
3.3. Specifying Policy Services
Administrators want the flexibility to be able to define traffic
conditioning without having to have a low-level understanding of the
different QoS mechanisms that implement that conditioning.
Furthermore, administrators want the flexibility to group different
services together, describing a higher-level concept such as "Gold
Service". This higher-level service could be viewed as providing the
processing to deliver "Gold" quality of service.
These two goals dictate the need for the following set of
abstractions:
o a flexible way to describe a service
o must be able to group different services that may use different
technologies (e.g., DiffServ and IEEE 802.1Q) together
o must be able to define a set of sub-services that together make up
a higher-level service
o must be able to associate a service and the set of QoS mechanisms
that are used to condition traffic for that service
o must be able to define policies that manage the QoS mechanisms
used to implement a service.
This document addresses this set of problems by defining a set of
classes and associations that can represent abstract concepts like
"Gold Service," and bind each of these abstract services to a
specific set of QoS mechanisms that implement the conditioning that
they require. Furthermore, this document defines the concept of
"sub-services," to enable Gold Service to be defined either as a
single service or as a set of services that together should be
treated as an atomic entity.
Given these abstractions, policies (as defined in [QPIM]) can be
written to control the QoS mechanisms and services defined in this
document.
3.4. Level of Abstraction for Defining QoS Attributes and Classes
This document defines a set of classes and properties to support
policies that configure device QoS mechanisms. This document
concentrates on the representation of services in the datapath that
support both DiffServ (for aggregate traffic conditioning) and
IntServ (for flow-based traffic conditioning). Classes and
properties for modeling IntServ admission control services may be
defined in a future document.
The classes and properties in this document are designed to be used
in conjunction with the QoS policy classes and properties defined in
[QPIM]. For example, to preserve the delay characteristics committed
to an end-user, a network administrator may wish to create policies
that monitor the queue depths in a device, and adjust resource
allocations when delay budgets are at risk (perhaps as a result of a
network topology change). The classes and properties in this
document define the specific services and mechanisms required to
implement those services. The classes and properties defined in
[QPIM] provide the overall structure of the policy that manages and
configures this service.
This combination of low-level specification (using this document) and
high-level structuring (using [QPIM]) of network services enables
network administrators to define new services required of the
network, that are directly related to business goals, while ensuring
that such services can be managed. However, this goal (of creating
and managing service-oriented policies) can only be realized if
policies can be constructed that are capable of supporting diverse
implementations of QoS. The solution is to model the QoS
capabilities of devices at the behavioral level. This means that for
traffic conditioning services realized in the datapath, the model
must support the following characteristics:
o modeling of a generic network service that has QoS capabilities
o modeling of how the traffic conditioning itself is defined
o modeling of how statistics are gathered to monitor QoS traffic
conditioning services - this facet of the model will be added in a
future document.
This document models a network service, and associates it with one or
more QoS mechanisms that are used to implement that service. It also
models in a canonical form the various components that are used to
condition traffic, such that standard as well as custom traffic
conditioning services may be described.
3.5. Characterization of QoS Properties
The QoS properties and classes will be described in more detail in
Section 4. However, we should consider the basic characteristics of
these properties, to understand the methodology for representing
them.
There are essentially two types of properties, state and
configuration. Configuration properties describe the desired state
of a device, and include properties and classes for representing
desired or proposed thresholds, bandwidth allocations, and how to
classify traffic. State properties describe the actual state of the
device. These include properties to represent the current
operational values of the attributes in devices configured via the
configuration properties, as well as properties that represent state
(queue depths, excess capacity consumption, loss rates, and so
forth).
In order to be correlated and used together, these two types of
properties must be modeled using a common information model. The
possibility of modeling state properties and their corresponding
configuration settings is accomplished using the same classes in this
model - although individual instances of the classes would have to be
appropriately named or placed in different containers to distinguish
current state values from desired configuration settings.
State information is addressed in a very limited fashion by QDDIM.
Currently, only CurrentQueueDepth is proposed as an attribute on
QueuingService. The majority of the model is related to
configuration. Given this fact, it is assumed that this model is a
direct memory map into a device. All manipulation of model classes
and properties directly affects the state of the device. If it is
desired to also use these classes to represent desired configuration,
that is left to the discretion of the implementor.
It is acknowledged that additional properties are needed to
completely model current state. However, many of the properties
defined in this document represent exactly the state variables that
will be configured by the configuration properties. Thus, the
definition of the configuration properties has an exact
correspondence with the state properties, and can be used in modeling
both actual (state) and desired/proposed configuration.
3.6. QoS Information Model Derivation
The question of context also leads to another question: how does the
information specified in the core and QoS policy models ([PCIM],
[PCIME], and [QPIM], respectively) integrate with the information
defined in this document? To put it another way, where should
device-independent concepts that lead to device-specific QoS
attributes be derived from?
Past thinking was that QoS was part of the policy model. This view
is not completely accurate, and it leads to confusion. QoS is a set
of services that can be controlled using policy. These services are
represented as device mechanisms. An important point here is that
QoS services, as well as other types of services (e.g., security),
are provided by the mechanisms inherent in a given device. This
means that not all devices are indeed created equal. For example,
although two devices may have the same type of mechanism (e.g., a
queue), one may be a simple implementation (i.e., a FIFO queue)
whereas one may be much more complex and robust (e.g., class-based
weighted fair queuing (CBWFQ)). However, both of these devices can
be used to deliver QoS services, and both need to be controlled by
policy. Thus, a device-independent policy can instruct the devices
to queue certain traffic, and a device-specific policy can be used to
control the queuing in each device.
Furthermore, policy is used to control these mechanisms, not to
represent them. For example, QoS services are implemented with
classifiers, meters, markers, droppers, queues, and schedulers.
Similarly, security is also a characteristic of devices, as
authentication and encryption capabilities represent services that
networked devices perform (irrespective of interactions with policy
servers). These security services may use some of the same
mechanisms that are used by QoS services, such as the concepts of
filters. However, they will mostly require different mechanisms than
the ones used by QoS, even though both sets of services are
implemented in the same devices.
Thus, the similarity between the QoS model and models for other
services is not so much that they contain a few common mechanisms.
Rather, they model how a device implements their respective services.
As such, the modeling of QoS should be part of a networking device
schema rather than a policy schema. This allows the networking
device schema to concentrate on modeling device mechanisms, and the
policy schema to focus on the semantics of representing the policy
itself (conditions, actions, operators, etc.). While this document
concentrates on defining an information model to represent QoS
services in a device datapath, the ultimate goal is to be able to
apply policies that control these services in network devices.
Furthermore, these two schemata (device and policy) must be tightly
integrated in order to enable policy to control QoS services.
3.7. Attribute Representation
The last issue to be considered is the question of how attributes are
represented. If QoS attributes are represented as absolute numbers
(e.g., Class AF2 gets 2 Mbs of bandwidth), it is more difficult to
make them uniform across multiple ports in a device or across
multiple devices, because of the broad variation in link capacities.
However, expressing attributes in relative or proportional terms
(e.g., Class AF2 gets 5% of the total link bandwidth) makes it more
difficult to express certain types of conditions and actions, such
as:
(If ConsumedBandwidth = AssignedBandwidth Then ...)
There are really three approaches to addressing this problem:
o Multiple properties can be defined to express the same value in
various forms. This idea has been rejected because of the
difficulty in keeping these different properties synchronized
(e.g., when one property changes, the others all have to be
updated).
o Multi-modal properties can be defined to express the same value,
in different terms, based on the access or assignment mode. This
option was rejected because it significantly complicates the model
and is impossible to express in current directory access protocols
(e.g., (L)DAP).
o Properties can be expressed as "absolutes", but the operators in
the policy schema would need to be more sophisticated. Thus, to
represent a percentage, division and multiplication operators are
required (e.g., Class AF2 gets .05 * the total link bandwidth).
This is the approach that has been taken in this document.
3.8. Mental Model
The mental model for constructing this schema is based on the work
done in the Differentiated Services working group. This schema is
based on information provided in the current versions of the DiffServ
Informal Management Model [DSMODEL], the DiffServ MIB [DSMIB], the
PIB [PIB], as well as on information in the set of RFCs that
constitute the basic definition of DiffServ itself ([R2475], [R2474],
[R2597], and [R3246]). In addition, a common set of terminology is
available in [POLTERM].
This model is built around two fundamental class hierarchies that are
bound together using a set of associations. The two class
hierarchies derive from the QoSService and ConditioningService base
classes. A set of associations relate lower-level QoSService
subclasses to higher-level QoS services, relate different types of
conditioning services together in processing a traffic class, and
relate a set of conditioning services to a specific QoS service.
This combination of associations enables us to view the device as
providing a set of services that can be configured, in a modular
building block fashion, to construct application-specific services.
Thus, this document can be used to model existing and future standard
as well as application-specific network QoS services.
3.8.1. The QoSService Class
The first of the classes defined here, QoSService, is used to
represent higher-level network services that require special
conditioning of their traffic. An instance of QoSService (or one of
its subclasses) is used to bring together a group of conditioning
services that, from the perspective of the system manager, are all
used to deliver a common service. Thus, the set of classifiers,
markers, and related conditioning services that provide premium
service to the "selected" set of user traffic may be grouped together
into a premium QoS service.
QoSService has a set of subclasses that represent different
approaches to delivering IP services. The currently defined set of
subclasses are a FlowService for flow-oriented QoS delivery and a
DiffServService for DiffServ aggregate-oriented QoS service delivery.
The QoS services can be related to each other as peers, or they can
be implemented as subservient services to each other. The
QoSSubService aggregation indicates that one or more QoSService
objects are subservient to a particular QoSService object. For
example, this enables us to define Gold Service as a combination of
two DiffServ services, one for high quality traffic treatment, and
one for servicing the rest of the traffic. Each of these
DiffServService objects would be associated with a set of
classifiers, markers, etc, such that the high quality traffic would
get EF marking and appropriate queuing.
The DiffServService class itself has an AFService subclass. This
subclass is used to represent the specific notion that several
related markings within the AF PHB Group work together to provide a
single service. When other DiffServ PHB Groups are defined that use
more than one code point, these will be likely candidates for
additional DiffServService subclasses.
Technology-specific mappings of these services, representing the
specific use of PHB marking or 802.1Q marking, are captured within
the ConditioningService hierarchy, rather than in the subclasses of
QoSService.
These concepts are depicted in Figure 2. Note that both of the
associations are aggregations: a QoSService object aggregates both
the set of QoSService objects subservient to it, and the set of
ConditioningService objects that realize it. See Section 4 for class
and association definitions.
/\______
0..1 \/ |
+--------------+ | QoSSubService +---------------+
| |0..n | | |