Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29341-11-11:2008 — UPnP QoS Manager — Orchestrating Quality of Service Across the Network
Defining the QoS Manager service for admission control, policy enforcement, and cross-device coordination
The Role of the QoS Manager in the UPnP QoS Architecture
ISO/IEC 29341-11-11:2008 defines the QoS Manager, the central coordination entity in the UPnP QoS Architecture. The QoS Manager is responsible for processing application QoS requests, discovering network paths, performing admission control decisions, coordinating traffic conditioning across multiple QoS Device Services along the traffic path, and enforcing QoS policies retrieved from the Policy Holder. It is the intelligence behind the entire UPnP QoS framework.
Unlike traditional QoS models where each network device makes independent prioritization decisions, the UPnP QoS Manager provides centralized coordination — it has visibility of the entire network topology, all active flows, and the complete policy rule set, enabling globally optimal admission control decisions.
The QoS Manager service exposes actions organized into four functional groups: request handling (RequestTrafficQoS, UpdateTrafficQoS, ReleaseTrafficQoS), path discovery (DiscoverPath, GetPathInformation), policy interaction (GetPolicyDecision, GetAllPolicies), and status monitoring (GetQoSState, GetActiveFlowList). The service also defines an extensive set of state variables that track the current QoS state of the managed network, including active flow tables, path topology, device capability registries, and policy cache entries.
| QoS Manager Action | Functional Group | Description | Response |
|---|---|---|---|
| RequestTrafficQoS | Request Handling | Application submits a QoS request specifying traffic requirements | Admit, Reject, or Negotiate with alternative parameters |
| UpdateTrafficQoS | Request Handling | Modifies an existing QoS reservation (e.g., bandwidth change) | Updated reservation parameters or rejection |
| ReleaseTrafficQoS | Request Handling | Releases a previously admitted QoS flow | Confirmation of release |
| DiscoverPath | Path Discovery | Discovers the network path between source and destination | Ordered list of QoS Device Services on the path |
| GetPolicyDecision | Policy Interaction | Retrieves the applicable policy decision for a traffic flow | TrafficClass and treatment parameters |
| GetQoSState | Status Monitoring | Returns the overall QoS state of the managed network | Flow counts, available capacity, device status |
The RequestTrafficQoS action supports a “negotiate” response mode: when the QoS Manager cannot fulfil the requested QoS level, it may return alternative parameters (e.g., a lower traffic class or reduced bandwidth) that the requesting application can accept or decline. This negotiation capability enables graceful degradation rather than binary admit/reject decisions.
Admission Control and Path Discovery
The admission control process begins when the QoS Manager receives a RequestTrafficQoS call from a control point. The request includes the source and destination device identifiers, the required traffic class (or a traffic specification descriptor from which the class can be derived), and optionally a requested bandwidth and latency budget. The QoS Manager first invokes DiscoverPath to determine the sequence of network segments and QoS-capable devices between source and destination.
Once the path is known, the QoS Manager queries each QoS Device Service on the path for its current traffic load and available capacity using GetQoSDeviceInfo. Simultaneously, it retrieves applicable policy rules from the QoS Policy Holder. The admission decision is a function of three factors: (1) whether a policy exists that permits the requested traffic class, (2) whether each device along the path has sufficient available capacity to accommodate the flow, and (3) whether admitting the flow would violate any existing QoS commitments to already-admitted flows.
Engineering Design Insights
Key considerations for QoS Manager implementation and deployment include:
- Path discovery caching: In networks with stable topology (typical of home and small-office environments), the QoS Manager should cache path discovery results with a configurable time-to-live (TTL). This avoids repeated discover-query cycles for each new flow to the same destination pair, significantly reducing admission control latency.
- Admission control algorithm selection: The standard does not mandate a specific admission control algorithm, allowing implementation flexibility. Common approaches include simple “sum of CIR” (check that total committed rates do not exceed interface capacity), measurement-based admission control (use actual traffic measurements rather than declared rates), and worst-case dimensioning (reserve peak rate for real-time flows and statistical multiplex for data flows).
- Policy cache management: The QoS Manager maintains a local cache of policy rules retrieved from the Policy Holder. The cache must be invalidated when the Policy Holder sends a policy change event. Stale policy caches can lead to incorrect admission decisions — a newly added policy that permits a previously blocked traffic class might not take effect until the cache is refreshed.
A common pitfall in QoS Manager implementations is performing admission control based solely on bandwidth without considering latency and jitter requirements. A flow requesting TrafficClass 5 (streaming video) may have modest bandwidth needs but stringent latency constraints. The QoS Manager must consider all dimensions of the traffic specification during admission control, not just the bandwidth parameter.
Error Handling and Flow State Management
The QoS Manager maintains an active flow table that records all admitted QoS flows, including each flow’s source and destination, traffic class, shaping parameters, and the set of QoS Device Services involved in its enforcement. This state machine governs flow lifecycle transitions from REQUESTED to ADMITTED to ACTIVE to RELEASED. If a QoS Device Service reports a traffic conditioning failure (e.g., a hardware queue error), the QoS Manager may either re-route the flow through an alternative path, renegotiate the QoS level downward, or release the flow entirely depending on the severity of the failure.
The QoS Manager also implements a keep-alive monitoring mechanism. If no traffic activity is detected for an admitted flow beyond a configurable timeout, the manager may proactively query the originating control point to determine whether the flow is still active. Stale flows that remain unacknowledged are automatically released, preventing resource leaks from orphaned reservations.
Frequently Asked Questions
Q: How many QoS Manager instances can exist in a single UPnP network?
A: The standard allows multiple QoS Manager instances, but only one Manager should be active at any time to avoid conflicting admission control decisions. A backup Manager may subscribe to state events from the active Manager and take over if the active Manager fails. The handover protocol is implementation-defined, as the standard focuses on the Manager’s external interfaces rather than internal redundancy mechanisms.
A: The standard allows multiple QoS Manager instances, but only one Manager should be active at any time to avoid conflicting admission control decisions. A backup Manager may subscribe to state events from the active Manager and take over if the active Manager fails. The handover protocol is implementation-defined, as the standard focuses on the Manager’s external interfaces rather than internal redundancy mechanisms.
Q: Can the QoS Manager preempt existing flows to admit higher-priority traffic?
A: Yes — the standard defines a preemption mechanism. When a high-priority QoS request cannot be accommodated without exceeding available capacity, the QoS Manager may preempt lower-priority flows. The preemption policy is retrieved from the QoS Policy Holder, which specifies the conditions under which preemption is allowed and which traffic classes may be preempted by which higher classes.
A: Yes — the standard defines a preemption mechanism. When a high-priority QoS request cannot be accommodated without exceeding available capacity, the QoS Manager may preempt lower-priority flows. The preemption policy is retrieved from the QoS Policy Holder, which specifies the conditions under which preemption is allowed and which traffic classes may be preempted by which higher classes.
Q: How does the QoS Manager handle asymmetric network paths?
A: In networks with asymmetric routing (common in home networks with different upstream and downstream paths), the QoS Manager performs separate path discovery for each direction. The admission decision considers the capacity constraints of both the forward and reverse paths independently. A flow may be admitted in one direction but limited or rejected in the other based on asymmetric capacity availability.
A: In networks with asymmetric routing (common in home networks with different upstream and downstream paths), the QoS Manager performs separate path discovery for each direction. The admission decision considers the capacity constraints of both the forward and reverse paths independently. A flow may be admitted in one direction but limited or rejected in the other based on asymmetric capacity availability.
Q: Does the QoS Manager support inter-domain QoS (between different UPnP networks)?
A: The base standard focuses on intra-domain QoS within a single UPnP network. Inter-domain QoS is outside the scope of ISO/IEC 29341-11-11, but the architecture provides an extensibility mechanism through which bridges between UPnP QoS domains can be implemented using the same QoS Manager interface, with additional inter-domain policy and routing logic at the bridge points.
A: The base standard focuses on intra-domain QoS within a single UPnP network. Inter-domain QoS is outside the scope of ISO/IEC 29341-11-11, but the architecture provides an extensibility mechanism through which bridges between UPnP QoS domains can be implemented using the same QoS Manager interface, with additional inter-domain policy and routing logic at the bridge points.
