| | +------------------+ | Name=BandSched |
| +------+PriorityScheduling| +------------+--++
| |Element | ^ |
| | Name=PriEF |ElementSchedSvc | |
| | Priority=1 +---------------------+ | |
| +------------------+ | | |
|NextService | | |
+-------------------------------------------------+ | | |
| | | |
NextService | | | |
+-----------------------------------------------+ | | | |
| | | | | |
| +------------------+ElementSchedSvc | | | | |
| |PriorityScheduling+--------+ | | | | |
| |Element | | | | | | |
| | Name=PriBE | | v v | | |
| +------+ Priority=2 | +---+--------+-+-+-+Next| |
| | +------------------+ |SchedulingService +----+ |
| | | Name=PriSched |Sched |
| | +------------------+ |
| |QueueTo |
| |Schedule +----------------+ |
| | |AllocationSched |ElementSchedSvc |
+----+---------+ |Element +-----------------+
|QueuingService|QueueTo | Name=BandBE |
| Name=BE +------------+ Units=Bytes |
| |Schedule | Bandwidth=50 |
| | +----------------+
+--------------+
Figure 6. Example 2: Complex Hierarchical Scheduler
3.11.3. Excess Capacity Scheduler
An excess capacity scheduler offers a similar requirement to support
two scheduling parameter sets per queue. However, in this scenario
the reasons are a little different. Suppose a set of queues have
each been assigned bandwidth limits to ensure that no traffic class
starves out another traffic class. The result may be that one or
more queues have exceeded their allocation while the queues that
deserve scheduling opportunities are empty.
The question then is how is the excess (idle) bandwidth allocated.
Conceivably, the scheduling criteria for excess capacity are
completely different from the criteria that determine allocations
under uniform load. This could be supported with a scheduling
hierarchy. However, the problem is that the criteria for using the
subsequent scheduler are different from those in the last two cases.
Specifically, the next scheduler should only be used if a scheduling
opportunity exists that was passed over by the prior scheduler.
When a scheduler chooses to forgo a scheduling decision, it is
behaving as a non-work conserving scheduler. Work conserving
schedulers, by definition, will always take advantage of a scheduling
opportunity, irrespective of which queue is being serviced and how
much bandwidth it has consumed in the past. This point leads to an
interesting insight. The semantics of a non-work conserving
scheduler are equivalent to those of a meter, in that if a packet is
in profile it is given the scheduling opportunity, and if it is out
of profile it does not get a scheduling opportunity. However, with
meters there are semantics that determine the next action behavior
when the packet is in profile and when the packet is out of profile.
Similarly, with the non-work conserving scheduler, there needs to be
a means for determining the next scheduler when a scheduler chooses
not to utilize a scheduling opportunity.
Figure 7 illustrates this last scenario. It appears very similar to
Figure 6, except that the binding between the allocation scheduler
and the WRR scheduler is using a FailNextScheduler association. This
association is explicitly indicating the fact that the only time the
WRR scheduler would be used is when there are non-empty queues that
the allocation scheduler rejected for scheduling consideration. Note
that Figure 7 is incomplete, in that typically there would be several
more queues that are bound to an allocation scheduler and a WRR
scheduler.
+------------+
|QueuingSvc |
| Name=EF |
| |
| |
++-+---------+
| |
| |QueueTo
| |Schedule +--------------+
| | |SchedulingSvc |
| | +------------------+ | Name=WRRSched|
| +------+AllocationSched | +----------+-+-+
| |Element | ^ |
| | Name=BandEF |ElementSchedSvc | |
| | Units=Bytes +--------------------+ | |
| | Bandwidth=100 | | | |
| +------------------+ | | |
|NextService | | |
+----------------------------------------------+ | | |
| | | |
NextService | | | |
+--------------------------------------------+ | | | |
| | | | | |
| +------------------+ElementSchedSvc | | | | |
| |AllocationSched +--------+ | | | | |
| |Element | | | | | | |
| | Name=BandwidthAF1| | | | | | |
| | Units=Bytes | | v v | | |
| +------+ Bandwidth=50 | +--+----------+-+-++FailNext| |
| | +------------------+ |SchedulingService +--------+ |
| |QueueTo | Name=BandSched |Scheduler |
| |Schedule +------------------+ |
| | |
| | +---------------------+ |
++-+-----------+ | WRRSchedulingElement| |
|QueuingService|QueueTo | Name=WRRBE +------------+
| Name=BE +-----------+ Weight=30 |ElementSchedSvc
+--------------+Schedule +---------------------+
Figure 7. Example 3: Excess Capacity Scheduler
3.11.4. Hierarchical CBQ Scheduler
A hierarchical class-based queuing (CBQ) scheduler is the fourth
scenario to be considered. In hierarchical CBQ, each queue is
allocated a specific bandwidth allocation. Queues are grouped
together into a logical scheduler. This logical scheduler in turn
has an aggregate bandwidth allocation that equals the sum of the
queues it is scheduling. In turn, logical schedulers can be
aggregated into higher-level logical schedulers. Changing
perspectives and looking top down, the top-most logical scheduler has
100% of the link capacity. This allocation is parceled out to
logical schedulers below it such that the sum of the allocations is
equal to 100%. These second tier schedulers may in turn parcel out
their allocation across a third tier of schedulers and so forth until
the lowest tier that parcels out their allocations to specific queues
representing relatively fine-grained classes of traffic. The unique
aspect of hierarchical CBQ is that when there is insufficient
bandwidth for a specific allocation, schedulers higher in the tree
are tested to see if another portion of the tree has capacity to
spare.
Figure 8 demonstrates this example with two tiers. The example is
split in half because of space constraints, resulting in the CBQTier1
scheduling service instance being represented twice. Note that the
total allocation at the top tier is 50 Mb. The voice allocation is
22 Mb. The remaining 23 Mb is split between FTP and Web. Hence, if
Web traffic is actually consuming 20 Mb (5 Mb in excess of the
allocation). If FTP is consuming 5 Mb, then it is possible for the
CBQTier1 scheduler to offer 3Mb of its allocation to Web traffic.
However, this is not enough, so the FailNextScheduler association
needs to be traversed to determine if there is any excess capacity
available from the voice class. If the voice class is only consuming
15 Mb of its 22 Mb allocation, there are sufficient resources to
allow the web traffic through. Note that FailNextScheduler is used
as the association. The reason is because the CBQTier1 scheduler in
fact failed to schedule a packet because of insufficient resources.
It is conceivable that a variant of hierarchical CBQ allows a
hierarchy for successful scheduling as well. Hence, both
associations are necessary.
Note that due to space constraints of the document, the
SchedulingService CBQTier1 is represented twice, to show how it is
connected to all the other objects.
+-----------+ NextService
|QueuingSvc +-------------------------------------------+
| Name=Web | |
| |QueueTo+----------------+ ElementSchedSvc |
| +-------+AllocationSched +----------------+ |
+-----------+Sched |Element | | |
| Name=Web-Alloc | | v
| Bandwidth=15 | +-----------+-+-+
+----------------+ |SchedulingSvc +
| Name=CBQTier1 +
+----------------+ +-----------+-+-+
|AllocationSched | ElementSchedSvc| ^
+-----------+ |Element +----------------+ |
|QueuingSvc |QueueTo| Name=FTP-Alloc | |
| Name=FTP +-------+ Bandwidth=8 | |
| |Sched +----------------+ |
| | NextService |
| +-------------------------------------------+
+-----------+
:
+---------------+ FailNextScheduler
|SchedulingSvc +---------------------------------------------+
| Name=CBQTier1 | |
+-------+-------+ +---------------------+ElementSchedSvc|
| SchedToSched |AllocationScheduling +--------+ |
+---------------+Element | | |
| Name=LowPri-Alloc | | |
| Bandwidth=23 | | v
+---------------------+ +-----+------+-+
|SchedulingSvc |
| Name=CBQTop |
+---------------------+ +----------+-+-+
|AllocationScheduling |ElementSchedSvc | ^
+------------+ |Element +----------------+ |
|QueuingSvc |QueueTo| Name=BE-Band | |
| Name=Voice +-------+ Bandwidth=22 | |
| |Sched +---------------------+ |
| | NextService |
| +------------------------------------------------+
+------------+
Figure 8. Example 4: Hierarchical CBQ Scheduler
4. The Class Hierarchy
The following sections present the class and association hierarchies
that together comprise the information model for modeling QoS
capabilities at the device level.
4.1. Associations and Aggregations
Associations and aggregations are a means of representing
relationships between two (or theoretically more) objects.
Dependency, aggregation, and other relationships are modeled as
classes containing two (or more) object references. It should be
noted that aggregations represent either "whole-part" or "collection"
relationships. For example, aggregation can be used to represent the
containment relationship between a system and the components that
constitute the system.
Since associations and aggregations are classes, they can benefit
from all of the object-oriented features that other non-relationship
classes have. For example, they can contain properties and methods,
and inheritance can be used to refine their semantics such that they
represent more specialized types of their superclasses.
Note that an association (or an aggregation) object is treated as an
atomic unit (individual instance), even though it relates/collects/is
comprised of multiple objects. This is a defining feature of an
association (or an aggregation) - although the individual elements
that are related to other objects have their own identities, the
association (or aggregation) object that is constructed using these
objects has its own identity and name as well.
It is important to note that associations and aggregations form an
inheritance hierarchy that is separate from the class inheritance
hierarchy. Although associations and aggregations are typically bi-
directional, there is nothing that prevents higher order associations
or aggregations from being defined. However, such associations and
aggregations are inherently more complex to define, understand, and
use. In practice, associations and aggregations of orders higher
than binary are rarely used, because of their greatly increased
complexity and lack of generality. All of the associations and
aggregations defined in this model are binary.
Note also that by definition, associations and aggregations cannot be
unary.
Finally, note that associations and aggregations that are defined
between two classes do not affect the classes themselves. That is,
the addition or deletion of an association or an aggregation does not
affect the interfaces of the classes that it is connecting.
4.2. The Structure of the Class Hierarchies
The structure of the class, association, and aggregation class
inheritance hierarchies for managing the datapaths of QoS devices is
shown, respectively, in Figure 9, Figure 10, and Figure 11. The
notation (CIMCORE) identifies a class defined in the CIM Core model.
Please refer to [CIM] for the definitions of these classes.
Similarly, the notation [PCIME] identifies a class defined in the
Policy Core Information Model Extensions document. This model has
been influenced by [CIM], and is compatible with the Directory
Enabled Networks (DEN) effort.
+--ManagedElement (CIMCORE)
|
+--ManagedSystemElement (CIMCORE)
| |
| +--LogicalElement (CIMCORE)
| |
| +--Service (CIMCORE)
| | |
| | +--ConditioningService
| | | |
| | | +--ClassifierService
| | | | |
| | | | +--ClassifierElement
| | | |
| | | +--MeterService
| | | | |
| | | | +--AverageRateMeterService
| | | | |
| | | | +--EWMAMeterService
| | | | |
| | | | +--TokenBucketMeterService
| | | |
| | | +--MarkerService
| | | | |
| | | | +--PreambleMarkerService
| | | | |
| | | | +--TOSMarkerService
| | | | |
| | | | +--DSCPMarkerService
| | | | |
(continued from previous page;
the first four elements are repeated for convenience)
+--ManagedElement (CIMCORE)
|
+--ManagedSystemElement (CIMCORE)
| |
| +--LogicalElement (CIMCORE)
| |
| +--Service (CIMCORE)
| | | | +--8021QMarkerService
| | | |
| | | +--DropperService
| | | | |
| | | | +--HeadTailDropperService
| | | | |
| | | | +--RedDropperService
| | | |
| | | +--QueuingService
| | | |
| | | +--PacketSchedulingService
| | | |
| | | +--NonWorkConservingSchedulingService
| | |
| | +--QoSService
| | | |
| | | +--DiffServService
| | | | |
| | | | +--AFService
| | | |
| | | +--FlowService
| | |
| | +--DropThresholdCalculationService
| |
| +--FilterEntryBase [PCIME]
| | |
| | +--IPHeaderFilter [PCIME]
| | |
| | +--8021Filter [PCIME]
| | |
| | +--PreambleFilter
| |
| +--FilterList [PCIME]
| |
| +--ServiceAccessPoint (CIMCORE)
| |
| +--ProtocolEndpoint
(continued from previous page;
the first four elements are repeated for convenience)
+--ManagedElement (CIMCORE)
|
+--ManagedSystemElement (CIMCORE)
| |
| +--LogicalElement (CIMCORE)
| |
| +--Service (CIMCORE)
|
+--Collection (CIMCORE)
| |
| +--CollectionOfMSEs (CIMCORE)
| |
| +--BufferPool
|
+--SchedulingElement
|
+--AllocationSchedulingElement
|
+--WRRSchedulingElement
|
+--PrioritySchedulingElement
|
+--BoundedPrioritySchedulingElement
Figure 9. Class Inheritance Hierarchy
The inheritance hierarchy for the associations defined in this
document is shown in Figure 10.
+--Dependency (CIMCORE)
| |
| +--ServiceSAPDependency (CIMCORE)
| | |
| | +--IngressConditioningServiceOnEndpoint
| | |
| | +--EgressConditioningServiceOnEndpoint
| |
| +--HeadTailDropQueueBinding
| |
| +--CalculationBasedOnQueue
| |
| +--ProvidesServiceToElement (CIMCORE)
| | |
| | +--ServiceServiceDependency (CIMCORE)
| | |
| | +--CalculationServiceForDropper
| |
| +--QueueAllocation
| |