Information Model for Describing Network Device QoS Datapath Mechanisms
Extracted elements (24)
A FilterList object is always required even when it contains only a single FilterEntryBase subclass object, because ClassifierElement can only be associated with a FilterList and not with an individual FilterEntry directly.
QoS attributes are expressed as absolute numbers rather than relative or proportional values. Multiple-property synchronization was rejected as error-prone, and multi-modal properties are unrepresentable in LDAP; absolute values allow the policy schema's arithmetic operators to derive percentages (e.g., AF2 gets 0.05 * total link bandwidth).
QoS mechanisms are modeled separately from the policy model because QoS services represent device-inherent capabilities that are controlled by policy, not defined by it. The QDDIM class hierarchies derive from the DMTF CIM network QoS submodel rather than PCIM, keeping device-mechanism modeling distinct from policy-condition/action modeling.
The FailNextScheduler association models the case where a non-work-conserving scheduler declines a scheduling opportunity, passing control to a fallback scheduler (e.g., WRR) only for queues that were passed over. This is semantically equivalent to a meter's out-of-profile behavior applied to scheduling.
The model imposes no fixed ordering on ConditioningService instances on an interface. Instead, NextService, NextServiceAfterMeter, and NextServiceAfterClassifierElement associations chain services explicitly, because different interfaces may require different subsets, multiplicities, and orderings of conditioning services.
Unlike the DiffServ Informal Management Model (DSMODEL), QDDIM allows ingress QoS conditioning results to be communicated to the egress interface via a packet preamble. This extension reflects a capability present in many network devices that the original DSMODEL did not represent.
QDDIM class hierarchies root in DMTF CIM Core classes (ManagedElement, ManagedSystemElement, LogicalElement, Service) and are compatible with the Directory Enabled Networks (DEN) effort. FilterEntryBase, IPHeaderFilter, 8021Filter, and FilterList are defined in PCIME rather than in this document to allow reuse across other services such as security.
The admission control element of IntServ (RSVP signaling, reservation management, policy server interaction) is explicitly outside the scope of this model; only the datapath forwarding aspects of IntServ are modeled. A future document is expected to address IntServ admission control.
A dropper always plays the PrecedingService role and the associated queue always plays the FollowingService role in a NextService association; there is always exactly one queue from which a dropper drops packets.
ClassifierService instances that aggregate other ClassifierService instances may not specify a FilterList via the ClassifierElementUsesFilterList association; such instances serve only as a classifier-collecting function.
ClassifierService groups ClassifierElement instances; each ClassifierElement references a FilterList via ClassifierElementUsesFilterList and identifies the next conditioning service via NextServiceAfterClassifierElement. A ClassifierService that aggregates other ClassifierService instances must not itself reference a FilterList.
ConditioningService is the abstract base class for all traffic-conditioning primitives: ClassifierService, MeterService, MarkerService, DropperService, QueuingService, and PacketSchedulingService. Instances are chained into a datapath via NextService and related associations rather than by any fixed order.
DiffServService represents DiffServ aggregate-oriented QoS delivery; its subclass AFService models the set of related markings within an AF PHB Group that together constitute a single service. FlowService represents flow-oriented (IntServ-style) QoS delivery.
DropperService and its subclasses—HeadTailDropperService and REDDropperService—model packet dropping. A dropper always plays the PrecedingService role in a NextService association to exactly one QueuingService. HeadTailDropQueueBinding links a dropper's algorithm to one or more monitored queues; the default combining rule is simple addition of queue lengths.
DropThresholdCalculationService (DTCS) represents per-queue smoothing parameterization (weight and time interval) consumed by a REDDropperService. A DTCS instance is tied to exactly one queue, but a queue may be referenced by multiple DTCS instances; a single DTCS may be shared across multiple REDDropperService instances.
FilterList (defined in PCIME) bridges ClassifierElement to filter criteria. The EntriesInFilterList aggregation's EntrySequence property accepts only the value '0', meaning all FilterEntries in the list are ANDed together to determine packet match; earlier CIM ordering semantics are explicitly not supported.
MarkerService subclasses cover ToSMarkerService (IP ToS byte), DSCPMarkerService (DSCP field per RFC 2474), 8021QMarkerService (IEEE 802.1Q priority bits), and PreambleMarkerService (device-internal preamble). PreambleMarkerService appends to existing preamble data rather than overwriting it.
MeterService and its subclasses—AverageRateMeterService, EWMAMeterService, and TokenBucketMeterService—model traffic metering. Post-metering packet paths (conforming vs. nonconforming) are expressed via the NextServiceAfterMeter association.
PacketSchedulingService and NonWorkConservingSchedulingService model packet scheduling. Successor schedulers are chained via NextScheduler (work-conserving) or FailNextScheduler (invoked only on a declined scheduling opportunity). SchedulingElement subclasses—AllocationSchedulingElement, WRRSchedulingElement, PrioritySchedulingElement, BoundedPrioritySchedulingElement—carry per-queue or per-scheduler parameters.
PreambleFilter is a subclass of FilterEntryBase that matches on '<type>,<value>' strings stored by a PreambleMarkerService. For the three meter-related types, the value field may be a wildcard 'any', allowing a single ClassifierElement to select all conforming (or nonconforming) packets regardless of which meter they traversed.
PreambleMarkerService stores QoS conditioning results in an ordered, multi-valued string property FilterItemList, where each entry has the form '<type>,<value>'. Defined types are ConformingFromMeter, PartConformingFromMeter, NonConformingFromMeter, and VlanId; implementations may add types, and future revisions may make the type namespace IANA-administered.
QoSService is the top-level class representing higher-level network services (e.g., 'Gold Service') that require special traffic conditioning. It aggregates sub-services via QoSSubService and conditioning services via QoSConditioningSubService; subclasses include DiffServService and FlowService.
QueuingService models a packet queue with a CurrentQueueDepth state property. Queues are linked to schedulers via QueueToSchedule and to preceding DropperService instances via the NextService association.
Security considerations are addressed in Section 7. Because this information model describes QoS mechanisms that directly configure device datapaths (treated as a direct memory map into the device), unauthorized access to or modification of model instances could allow an attacker to alter traffic conditioning, degrade service quality, or cause denial of service by reconfiguring classifiers, meters, droppers, queues, or schedulers.