Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29341-11-10:2008 — UPnP QoS Device Service — Traffic Conditioning at the Network Edge
Defining the QoS Device Service interface for traffic shaping, marking, policing, and queue management
Introduction to the QoS Device Service
ISO/IEC 29341-11-10:2008 specifies the QoS Device Service, a UPnP service that resides on every QoS-capable network device — including routers, switches, wireless access points, media adapters, IP set-top boxes, and VoIP phones. This service is the enforcement point of the UPnP QoS Architecture, responsible for translating abstract QoS policy decisions from the QoS Manager into concrete traffic conditioning actions on the network interface.
Think of the QoS Device Service as the “traffic police” of the UPnP QoS framework — it receives instructions from the QoS Manager about which traffic flows get priority treatment and then applies shaping, marking, and queueing disciplines to enforce those decisions at the packet level.
The service exposes a set of actions grouped into three categories: traffic configuration actions (AddTrafficShape, UpdateTrafficShape, RemoveTrafficShape), queue management actions (SetQueueConfiguration, GetQueueConfiguration), and information actions (GetQoSDeviceInfo, GetTrafficShapeList). Each action operates on a well-defined set of state variables that represent the current QoS state of the device, including traffic shape entries, queue configurations, and device capability descriptors.
| QoS Device Action | Category | Description | Key Arguments |
|---|---|---|---|
| AddTrafficShape | Traffic Configuration | Creates a new traffic shaping rule for an admitted flow | FlowID, TrafficClass, ShapingRate, BurstSize |
| UpdateTrafficShape | Traffic Configuration | Modifies parameters of an existing traffic shape entry | FlowID, NewShapingRate, NewPriority |
| RemoveTrafficShape | Traffic Configuration | Removes a traffic shape entry and releases associated resources | FlowID |
| SetQueueConfiguration | Queue Management | Configures the priority queue parameters for a network interface | InterfaceID, QueueParams |
| GetQoSDeviceInfo | Information | Returns the QoS capabilities of the device | — |
| GetTrafficStats | Information | Returns traffic statistics including packet counts and drops per class | TrafficClass |
The separation of traffic shape management from queue configuration is architecturally significant: it allows the QoS Manager to define per-flow shaping parameters while independently managing the underlying priority queue structures that determine packet scheduling behaviour on each interface.
Traffic Conditioning Mechanisms
The QoS Device Service implements three fundamental traffic conditioning mechanisms: classification, marking, and shaping. Classification identifies packets belonging to an admitted flow based on header fields (IP addresses, ports, protocol). Marking sets the Layer 2 (802.1p) and Layer 3 (DSCP) priority indicators on classified packets. Shaping controls the transmission rate of the traffic flow to conform to the agreed bandwidth profile, using a token bucket or leaky bucket algorithm.
Each traffic shape entry includes a TrafficClass parameter (0–7), a ShapingRate parameter specifying the committed information rate (CIR) in kilobits per second, and a BurstSize parameter defining the maximum burst size in kilobytes. The device service uses these parameters to configure its hardware or software traffic conditioner. If the device cannot support the requested parameters (due to hardware limitations or conflicting existing reservations), it returns an error code indicating the specific constraint violation.
Engineering Design Insights
Several practical considerations govern effective QoS Device Service deployment:
- Hardware offload support: Many consumer-grade network devices implement QoS in software rather than hardware. Engineers should verify that the device’s QoS Device Service implementation leverages hardware traffic classification features (e.g., IEEE 802.1p priority code point decoding in switch silicon) to avoid excessive CPU load during high-throughput traffic conditioning.
- Queue depth sizing: The SetQueueConfiguration action allows configuration of queue depths for each priority level. Improper queue depth sizing can cause either unnecessary packet drops (too shallow) or excessive latency for real-time traffic (too deep for the priority queue). A recommended starting point is 10–20 ms of buffering at the interface line rate for real-time queues and 50–100 ms for best-effort queues.
- Multi-interface consistency: In devices with multiple network interfaces (e.g., a wireless router with four LAN ports and one WAN port), traffic shapes must be applied consistently across all interfaces that a flow traverses. The QoS Manager is responsible for ensuring this consistency, but the device service on each interface performs independent traffic conditioning.
When a QoS Device Service cannot honour a requested shaping rate due to competing flows, it must reject the AddTrafficShape request with a specific error code rather than silently accepting and oversubscribing the interface. This strict admission behaviour is essential for maintaining QoS guarantees across the network.
Traffic Statistics and Monitoring
The GetTrafficStats action provides per-traffic-class counters including total packets transmitted, packets dropped due to shaping, packets marked with each priority level, and current queue occupancy. These statistics enable the QoS Manager to monitor the effectiveness of traffic conditioning and detect network congestion before it impacts application performance. The QoS Device Service also generates event notifications when traffic statistics cross configurable thresholds, enabling proactive QoS management without polling.
The standard defines an optional aging mechanism for traffic shape entries: if no packets matching a traffic shape are observed within a configurable idle timeout period, the device service may automatically remove the shape entry and notify the QoS Manager. This self-cleaning behaviour prevents stale reservations from consuming network resources after an application terminates without explicitly releasing its QoS flow.
Frequently Asked Questions
Q: Can a single device host multiple QoS Device Service instances?
A: Yes — a device with multiple network interfaces may host a separate QoS Device Service instance for each interface. Each instance manages traffic conditioning independently for its associated interface, while the QoS Manager coordinates cross-interface policies. The device description document must list all service instances with distinct UDN (Unique Device Name) identifiers.
A: Yes — a device with multiple network interfaces may host a separate QoS Device Service instance for each interface. Each instance manages traffic conditioning independently for its associated interface, while the QoS Manager coordinates cross-interface policies. The device description document must list all service instances with distinct UDN (Unique Device Name) identifiers.
Q: How does the QoS Device Service handle 802.1p marking on wireless interfaces?
A: On wireless interfaces, 802.1p marking is mapped to IEEE 802.11e EDCA Access Categories (AC). The priority mapping is: 802.1p 1–2 to AC_BK (Background), 0–3 to AC_BE (Best Effort), 4–5 to AC_VI (Video), and 6–7 to AC_VO (Voice). The QoS Device Service implementation must handle this mapping transparently so that higher-layer QoS policies remain technology-independent.
A: On wireless interfaces, 802.1p marking is mapped to IEEE 802.11e EDCA Access Categories (AC). The priority mapping is: 802.1p 1–2 to AC_BK (Background), 0–3 to AC_BE (Best Effort), 4–5 to AC_VI (Video), and 6–7 to AC_VO (Voice). The QoS Device Service implementation must handle this mapping transparently so that higher-layer QoS policies remain technology-independent.
Q: What happens when a traffic shape is added for a flow that already exceeds the requested shaping rate?
A: The QoS Device Service applies shaping immediately upon accepting the request. Any packets already in the device’s transmit queue that exceed the newly configured rate will be shaped according to the token bucket parameters. The device may also transmit a traffic alarm event if the sustained rate significantly exceeds the configured CIR, allowing the QoS Manager to take corrective action.
A: The QoS Device Service applies shaping immediately upon accepting the request. Any packets already in the device’s transmit queue that exceed the newly configured rate will be shaped according to the token bucket parameters. The device may also transmit a traffic alarm event if the sustained rate significantly exceeds the configured CIR, allowing the QoS Manager to take corrective action.
Q: Is the QoS Device Service required to support all six traffic conditioning actions?
A: No — the standard defines three conformance levels: Base (GetQoSDeviceInfo and traffic statistics only), Standard (add/update/remove traffic shapes plus base), and Advanced (all actions including queue configuration). This graduated conformance model allows simple devices (e.g., a basic Ethernet switch) to implement only the Base level while full-featured routers implement the Advanced level.
A: No — the standard defines three conformance levels: Base (GetQoSDeviceInfo and traffic statistics only), Standard (add/update/remove traffic shapes plus base), and Advanced (all actions including queue configuration). This graduated conformance model allows simple devices (e.g., a basic Ethernet switch) to implement only the Base level while full-featured routers implement the Advanced level.
