| QoSService |----- | Conditioning |
| | | Service |
| | | |
| |0..n 0..n| |
| | /\______________________| |
| | \/ QoSConditioning | |
+--------------+ SubService +---------------+
Figure 2. QoSService and its Aggregations
3.8.2. The ConditioningService Class
The goal of the ConditioningService classes is to describe the
sequence of traffic conditioning that is applied to a given traffic
stream on the ingress interface through which it enters a device, and
then on the egress interface through which it leaves the device.
This is done using a set of classes and relationships. The routing
decision in the device core, which selects which egress interface a
particular packet will use, is not represented in this model.
A single base class, ConditioningService, is the superclass for a set
of subclasses representing the mechanisms that condition traffic.
These subclasses define device-independent conditioning primitives
(including classifiers, meters, markers, droppers, queues, and
schedulers) that together implement the conditioning of traffic on an
interface. This model abstracts these services into a common set of
modular building blocks that can be used, regardless of device
implementation, to model the traffic conditioning internal to a
device.
The different conditioning mechanisms need to be related to each
other to describe how traffic is conditioned. Several important
variations of how these services are related together exist:
o A particular ingress or egress interface may not require all the
types of ConditioningServices.
o Multiple instances of the same mechanism may be required on an
ingress or egress interface.
o There is no set order of application for the ConditioningServices
on an ingress or egress interface.
Therefore, this model does not dictate a fixed ordering among the
subclasses of ConditioningService, or identify a subclass of
ConditioningService that must appear first or last among the
ConditioningServices on an ingress or egress interface. Instead,
this model ties together the various ConditioningService instances on
an ingress or egress interface using the NextService,
NextServiceAfterMeter, and NextServiceAfterConditioningElement
associations. There are also separate associations, called
IngressConditioningServiceOnEndpoint and
EgressConditioningServiceOnEndpoint, which, respectively, tie an
ingress interface to its first ConditioningService, and tie an egress
interface to its last ConditioningService(s).
3.8.3. Preserving QoS Information from Ingress to Egress
There is one important way in which the QDDIM model diverges from the
[DSMODEL]. In [DSMODEL], traffic passes through a network device in
three stages:
o It comes in on an ingress interface, where it may receive QoS
conditioning.
o It traverses the routing core, where logic outside the scope of
QoS determines which egress interface it will use to leave the
device.
o It may receive further QoS conditioning on the selected egress
interface, and then it leaves the device.
In this model, no information about the QoS conditioning that a
packet receives on the ingress interface is communicated with the
packet across the routing core to the egress interface.
The QDDIM model relaxes this restriction, to allow information about
the treatment that a packet received on an ingress interface to be
communicated along with the packet to the egress interface. (This
relaxation adds a capability that is present in many network
devices.) QDDIM represents this information transfer in terms of a
packet preamble, which is how many devices implement it. But
implementations are free to use other mechanisms to achieve the same
result.
+---------+
| Meter-A |
a | | b d
--->| In-|---PM-1--->
| | c e
| Out-|---PM-2--->
+---------+
Figure 3: Meter Followed by Two Preamble Markers
Figure 3 shows an example in which meter results are captured in a
packet preamble. The arrows labeled with single letters represent
instances of either the NextService association (a, d, and e), or of
its peer association NextServiceAfterMeter (b and c). PreambleMarker
PM-1 adds to the packet preamble an indication that the packet exited
Meter A as conforming traffic. Similarly, PreambleMarker PM-2 adds to
the preambles of packets that come through it indications that they
exited Meter A as nonconforming traffic. A PreambleMarker appends
its information to whatever is already present in a packet preamble,
as opposed to overwriting what is already there.
To foster interoperability, the basic format of the information
captured by a PreambleMarker is specified. (Implementations, of
course, are free to represent this information in a different way
internally - this is just how it is represented in the model.) The
information is represented by an ordered, multi-valued string
property FilterItemList, where each individual value of the property
is of the form "<type>,<value>". When a PreambleMarker "appends" its
information to the information that was already present in a packet
preamble, it does so by adding additional items of the indicated
format to the end of the list.
QDDIM provides a limited set of <type>’s that a PreambleMarker may
use:
o ConformingFromMeter: the value is the name of the meter.
o PartConformingFromMeter: the value is the name of the meter.
o NonConformingFromMeter: the value is the name of the meter.
o VlanId: the value is the virtual LAN identifier (VLAN ID).
Implementations may recognize other <type>’s in addition to these.
If collisions of implementation-specific <type>’s become a problem,
it is possible that <type>’s may become an IANA-administered range in
a future revision of this document.
To make use of the information that a PreambleMarker stores in a
packet preamble, a specific subclass PreambleFilter of
FilterEntryBase is defined, to match on the "<type>,<value>" strings.
To simplify the case where there’s just a single level of metering in
a device, but different individual meters on each ingress interface,
PreambleFilter allows a wildcard "any" for the <value> part of the
three meter-related filters. With this wildcard, an administrator
can specify a Classifier to select all packets that were found to be
conforming (or partially conforming, or non-conforming) by their
respective meters, without having to name each meter individually in
a separate ClassifierElement.
Once a meter result has been stored in a packet preamble, it is
available for any subsequent Classifier to use. So while the
motivation for this capability has been described in terms of
preserving QoS conditioning information from an ingress interface to
an egress interface, a prior meter result may also be used for
classifying packets later in the datapath on the same interface where
the meter resides.
3.9. Classifiers, FilterLists, and Filter Entries
This document uses a number of classes to model the classifiers
defined in [DSMODEL]: ClassifierService, ClassifierElement,
FilterList, FilterEntryBase, and various subclasses of
FilterEntryBase. There are also two associations involved:
ClassifierElementUsesFilterList and EntriesInFilterList. The QDDIM
model makes no use of CIM’s FilterEntry class.
In [DSMODEL], a single traffic stream coming into a classifier is
split into multiple traffic streams leaving it, based on which of an
ordered set of filters each packet in the incoming stream matches. A
filter matches either a field in the packet itself, or possibly other
attributes associated with the packet. In the case of a multi-field
(MF) classifier, packets are assigned to output streams based on the
contents of multiple fields in the packet header. For example, an MF
classifier might assign packets to an output stream based on their
complete IP-addressing 5-tuple.
To optimize the representation of MF classifiers, subclasses of
FilterEntryBase are introduced, which allow multiple related packet
header fields to be represented in a single object. These subclasses
are IPHeaderFilter and 8021Filter. With IPHeaderFilter, for example,
criteria for selecting packets based on all five of the IP 5-tuple
header fields and the DiffServ DSCP can be represented by a
FilterList containing one IPHeaderFilter object. Because these two
classes have applications beyond those considered in this document,
they, as well as the abstract class FilterEntryBase, are defined in
the more general document [PCIME] rather than here.
The FilterList object is always needed, even if it contains only one
filter entry (that is, one FilterEntryBase subclass) object. This is
because a ClassifierElement can only be associated with a Filter
List, as opposed to an individual FilterEntry. FilterList is also
defined in [PCIME].
The EntriesInFilterList aggregation (also defined in [PCIME]) has a
property EntrySequence, which in the past (in CIM) could be used to
specify an evaluation order on the filter entries in a FilterList.
Now, however, the EntrySequence property supports only a single
value: ’0’. This value indicates that the FilterEntries are ANDed
together to determine whether a packet matches the MF selector that
the FilterList represents.
A ClassifierElement specifies the starting point for a specific
policy or data path. Each ClassifierElement uses the
NextServiceAfterClassifierElement association to determine the next
conditioning service to apply for packets to.
A ClassifierService defines a grouping of ClassifierElements. There
are certain instances where a ClassifierService actually specifies an
aggregation of ClassifierServices. One practical case would be where
each ClassifierService specifies a group of policies associated with
a particular application and another ClassifierService groups the
application-specific ClassifierService instances. In this particular
case, the application-specific ClassifierService instances are
specified once, but unique combinations of these ClassifierServices
are specified, as needed, using other ClassifierService instances.
ClassifierService instances grouping other ClassifierService
instances may not specify a FilterList using the
ClassifierElementUsesFilterList association. This special use of
ClassifierService serves just as a Classifier collecting function.
3.10. Modeling of Droppers
In [DSMODEL], a distinction is made between absolute droppers and
algorithmic droppers. In QDDIM, both of these types of droppers are
modeled with the DropperService class, or with one of its subclasses.
In both cases, the queue from which the dropper drops packets is tied
to the dropper by an instance of the NextService association. The
dropper always plays the PrecedingService role in these associations,
and the queue always plays the FollowingService role. There is
always exactly one queue from which a dropper drops packets.
Since an absolute dropper drops all packets in its queue, it needs no
configuration beyond a NextService tie to that queue. For an
algorithmic dropper, however, further configuration is needed:
o a specific drop algorithm;
o parameters for the algorithm (for example, token bucket size);
o the source(s) of input(s) to the algorithm;
o possibly per-input parameters for the algorithm.
The first two of these items are represented by properties of the
DropperService class, or properties of one of its subclasses. The
last two, however, involve additional classes and associations.
3.10.1. Configuring Head and Tail Droppers
The HeadTailDropQueueBinding is the association that identifies the
inputs for the algorithm executed by a tail dropper. This
association is not used for a head dropper, because a head dropper
always has exactly one input to its drop algorithm, and this input is
always the queue from which it drops packets. For a tail dropper,
this association is defined to have a many-to-many cardinality.
There are, however, two distinct cases:
One dropper bound to many queues: This represents the case where the
drop algorithm for the dropper involves inputs from more than one
queue. The dropper still drops from only one queue, the one to which
it is tied by a NextService association. But the drop decision may
be influenced by the state of several queues. For the classes
HeadTailDropper and HeadTailDropQueueBinding, the rule for combining
the multiple inputs is simple addition: if the sum of the lengths of
the monitored queues exceeds the dropper’s QueueThreshold value, then
packets are dropped. This rule for combining inputs may, however, be
overridden by a different rule in subclasses of one or both of these
classes.
One queue bound to many droppers: This represents the case where the
state of one queue (which is typically also the queue from which
packets are dropped) provides an input to multiple droppers’ drop
algorithms. A use case here is a classifier that splits a traffic
stream into, say, four parts, representing four classes of traffic.
Each of the parts goes through a separate HeadTailDropper, then
they’re re-merged onto the same queue. The net is a single queue
containing packets of four traffic types, with, say, the following
drop thresholds:
o Class 1 - 90% full
o Class 2 - 80% full
o Class 3 - 70% full
o Class 4 - 50% full
Here the percentages represent the overall state of the queue. With
this configuration, when the queue in question becomes 50% full,
Class 4 packets will be dropped rather than joining the queue, when
it becomes 70% full, Class 3 and 4 packets will be dropped, etc.
The two cases described here can also occur together, if a dropper
receives inputs from multiple queues, one or more of which are also
providing inputs to other droppers.
3.10.2. Configuring RED Droppers
Like a tail dropper, a RED dropper, represented by an instance of the
REDDropperService class, may take as its inputs the states of
multiple queues. In this case, however, there is an additional step:
each of these inputs may be smoothed before the RED dropper uses it,
and the smoothing process itself must be parameterized. Consequently,
in addition to REDDropperService and QueuingService, a third class,
DropThresholdCalculationService, is introduced, to represent the
per-queue parameterization of this smoothing process.
The following instance diagram illustrates how these classes work
with each other:
RDSvc-A
| | |
+-----+ | +-----+
| | |
DTCS-1 DTCS-2 DTCS-3
| | |
Q-1 Q-2 Q-3
Figure 4. Inputs for a RED Dropper
So REDDropperService-A (RDSvc-A) is using inputs from three queues to
make its drop decision. (As always, RDSvc-A is linked to the queue
from which it drops packets via the NextService association.) For
each of these three queues, there is a
(DropThresholdCalculationService) DTCS instance that represents the
smoothing weight and time interval to use when looking at that queue.
Thus each DTCS instance is tied to exactly one queue, although a
single queue may be examined (with different weight and time values)
by multiple DTCS instances. Also, a DTCS instance and the queue
behind it can be thought of as a "unit of reusability". So a single
DTCS can be referred to by multiple RDSvc’s.
Unless it is overridden by a different rule in a subclass of
REDDropperService, the rule that a RED dropper uses to combine the
smoothed inputs from the DTCS’s to create a value to use in making
its drop decision is simple addition.
3.11. Modeling of Queues and Schedulers
In order to appreciate the rationale behind this rather complex model
for scheduling, we must consider the rather complex nature of
schedulers, as well as the extreme variations in algorithms and
implementations. Although these variations are broad, we have
identified four examples that serve to test the model and justify its
complexity.
3.11.1. Simple Hierarchical Scheduler
A simple, hierarchical scheduler has the following properties. First,
when a scheduling opportunity is given to a set of queues, a single,
viable queue is determined based on some scheduling criteria, such as
bandwidth or priority. The output of the scheduler is the input to
another scheduler that treats the first scheduler (and its queues) as
a single logical queue. Hence, if the first scheduler determined the
appropriate packet to release based on a priority assigned to each
queue, the second scheduler might specify a bandwidth
limit/allocation for the entire set of queues aggregated by the first
scheduler.
+----------+ NextService
|QueuingSvc+----------------------------------------------+
| Name=EF1 | |
| | QueueTo +--------------+ ElementSched |
| +------------+PrioritySched +---------------+ |
+----------+ Schedule |Element | Service | |
| Name=EF1-Pri | | v
| Priority=1 | +-----------+-+-+
+--------------+ |SchedulingSvc +
| Name=PriSched1+
+--------------+ +----------+--+-+
|PrioritySched | ElementSched | ^
+----------+ |Element +---------------+ |
|QueuingSvc| QueueTo | Name=AF1x-Pri| Service |
| Name=AF1x+------------+ Priority=2 | |
| | Schedule +--------------+ |
| | NextService |
| +----------------------------------------------+
+----------+
:
+---------------+ NextScheduler
|SchedulingSvc +--------------------------------------------+
| Name=PriSched1| |
+-------+-------+ +--------------------+ElementSchedSvc|
| SchedToSched |AllocationScheduling+--------+ |
+---------------+Element | | |
| Name=PriSched1-Band| | |
| Units=Bytes | | v
| Bandwidth=100 | +------+------+--+
+--------------------+ |SchedulingSvc |
| Name=BandSched1|
+--------------------+ +------+------+--+
|AllocationScheduling| | ^
+---------------+ |Element +--------+ |
|QueuingService | | Name=BE-Band |ElementSchedSvc|
| Name=BE |QueueTo+ Units=Bytes | |
| |-------+ Bandwidth=50 | |
| |Sched +--------------------+ |
| | NextService |
| +--------------------------------------------+
+---------------+
Figure 5. Example 1: Simple Hierarchical Scheduler
Figure 5 illustrates the example and how it would be instantiated
using the model. In the figure, NextService determines the first
scheduler after the queue. NextScheduler determines the
subsequent ordering of schedulers. In addition, the
ElementSchedulingService association determines the set of
scheduling parameters used by a specific scheduler. Scheduling
parameters can be bound either to queues or to schedulers. In
the case of the SchedulingElement EF1-Pri, the binding is to a
queue, so the QueueToSchedule association is used. In the case
of the SchedulingElement PriSched1-Band, the binding is to
another scheduler, so the SchedulerToSchedule association is
used. Note that due to space constraints of the document, the
SchedulingService PRISched1 is represented twice, to show how it
is connected to all the other objects.
3.11.2. Complex Hierarchical Scheduler
A complex, hierarchical scheduler has the same characteristics as
a simple scheduler, except that the criteria for the second
scheduler are determined on a per queue basis rather than on an
aggregate basis. One scenario might be a set of bounded priority
schedulers. In this case, each queue is assigned a relative
priority. However, each queue is also not allowed to exceed a
bandwidth allocation that is unique to that queue. In order to
support this scenario, the queue must be bound to two separate
schedulers. Figure 6 illustrates this situation, by describing
an EF queue and a best effort (BE) queue both pointing to a
priority scheduler via the NextService association. The
NextScheduler association between the priority scheduler and the
bandwidth scheduler in turn defines the ordering of the
scheduling hierarchy. Also note that each scheduler has a
distinct set of scheduling parameters that are bound back to each
queue. This demonstrates the need to support two or more
parameter sets on a per queue basis.
+----------------+
|QueuingService |
| Name=EF |
| |QueueTo +----------------+ElementSchedSvc
| +----------+AllocationSched +--------+
++---+-----------+Schedule |Element | |
| | | Name=BandEF | |
| |QueueTo | Units=Bytes | |
| |Schedule | Bandwidth=100 | |
| | +----------------+ +------+---------+
| | |SchedulingSvc |