Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29341-11-2:2008 — UPnP QoS Component — Building Blocks for Network Quality of Service
Defining the base QoS component types, state variables, and data type schemas for the UPnP QoS framework
Introduction to the QoS Component Model
ISO/IEC 29341-11-2:2008 defines the foundational component types, data structures, and state variable definitions that underpin all services in the UPnP QoS Architecture. While the QoS Device Service, QoS Manager, and QoS Policy Holder specify the behaviour of functional entities, the QoS Component standard provides the shared vocabulary and type system that enables these entities to interoperate. It is the common language spoken by all participants in the UPnP QoS framework.
Think of the QoS Component standard as the “alphabet” from which all QoS service interfaces are constructed. Without this common type system, each service would define its own data structures independently, leading to incompatibilities between different vendors’ implementations of the same QoS service.
The standard defines component types in several categories: traffic specification components (TrafficDescriptor, TrafficClass, TrafficSpec), policy components (PolicyRule, PolicyAction, PolicyPrecedence), QoS configuration components (TrafficShape, QueueConfiguration, InterfaceInfo), and status and error components (QoSState, QoSErrorCode, TrafficStats). Each component type is defined with its data type, valid value range, and semantic meaning, ensuring consistent interpretation across all QoS service implementations.
| Component Category | Component Type | Base Data Type | Used By |
|---|---|---|---|
| Traffic Specification | TrafficDescriptor | String (structured XML) | QoS Manager, Policy Holder |
| Traffic Specification | TrafficClass | Unsigned Int (0–7) | All QoS services |
| Traffic Specification | TrafficSpec | String (structured XML) | QoS Manager |
| Policy | PolicyRule | String (structured XML) | Policy Holder, QoS Manager |
| Configuration | TrafficShape | String (structured XML) | QoS Device Service |
| Configuration | QueueConfiguration | String (structured XML) | QoS Device Service |
| Status | QoSState | String (structured XML) | QoS Manager |
| Error | QoSErrorCode | Unsigned Int | All QoS services |
| Statistics | TrafficStats | String (structured XML) | QoS Device Service |
The use of structured XML strings as the base data type for complex components (TrafficDescriptor, PolicyRule, TrafficShape, etc.) provides schema flexibility without requiring modifications to the UPnP service interface. New fields can be added to the XML schema without changing the action signatures, enabling backward-compatible protocol evolution.
Traffic Specification Components
The TrafficSpec component is the most detailed traffic specification in the QoS framework. It encapsulates all parameters needed to describe a traffic flow’s QoS requirements, including committed information rate (CIR), peak information rate (PIR), maximum burst size, delay tolerance, jitter tolerance, packet loss tolerance, and the traffic class. The TrafficSpec is used by applications to communicate their QoS needs to the QoS Manager through the RequestTrafficQoS action.
The TrafficDescriptor component serves as the matching pattern used in policy rules. It can specify source and destination IP addresses (with subnet masks), transport protocol, source and destination port ranges, DSCP value, 802.1p priority, and an optional application identifier string. The matching semantics follow a “logical AND” within each descriptor group and “logical OR” across multiple descriptor groups, enabling flexible rule composition for complex traffic identification scenarios.
Engineering Design Insights
Key technical considerations for working with QoS Component types include:
- XML schema extensibility: All complex component types use XML-based serialization. The standard defines a base XML schema for each component, but vendors may extend the schema with proprietary elements using a separate namespace. QoS service implementations must ignore unknown elements from extended schemas (forward compatibility) while correctly parsing all elements defined in the base schema.
- State variable typing: UPnP state variables defined in the QoS Component standard use a consistent naming convention: variables ending in “Info” are read-only information sources (e.g., QoSDeviceInfo), variables ending in “List” are multi-valued (e.g., ActiveFlowList), and variables ending in “Config” are writeable configuration parameters (e.g., QueueConfig). This convention simplifies implementation by making the variable semantics clear from its name.
- Error code standardization: The QoS Component standard defines a unified error code table used by all QoS services. Error codes range from 700 to 799 (the range allocated for the QoS device and service). Critical error codes include 701 (insufficient bandwidth), 702 (traffic class not supported), 703 (policy violation), and 704 (path not available). A consistent error code scheme across all services simplifies application-level error handling.
When extending the TrafficSpec XML schema with vendor-specific parameters, implementers must ensure that extended parameters do not affect the admission control behaviour of standard-conformant QoS Managers that do not understand the extensions. The base schema parsing must be self-contained — extended parameters should only augment, never override, base TrafficSpec semantics.
State Variable Definitions and Data Flow
The QoS Component standard defines the state variables that form the backbone of QoS service interactions. Key state variables include: QoSDeviceInfo (advertises device capabilities including supported traffic classes, queue count, and shaping rate limits), TrafficShapeList (the set of active traffic conditioning rules on a device), PolicyTable (the complete policy rule set stored in a Policy Holder), and ActiveFlowTable (all currently admitted QoS flows tracked by the QoS Manager). Each variable has a defined data type, allowed value range, and eventing behaviour (whether changes generate UPnP events).
The data flow between components follows a well-defined lifecycle: TrafficSpec from application to QoS Manager, PolicyRule from Policy Holder to QoS Manager, TrafficShape configuration from QoS Manager to QoS Device Service, and TrafficStats from QoS Device Service back to QoS Manager for monitoring purposes. The QoS Component standard’s type definitions ensure that each stage of this data flow uses interoperable data representations, regardless of the device manufacturer or implementation language.
Frequently Asked Questions
Q: Why does the QoS Component standard use XML strings rather than native UPnP data types for complex structures?
A: UPnP state variables support only simple data types (integer, string, boolean, etc.) natively. Complex hierarchical data structures like traffic descriptors and policy rules require a structured representation. XML was chosen for its wide tool support, human readability during debugging, and extensibility through namespaces. The XML payload is carried within a UPnP string variable, which imposes a size limit (typically 32 KB) that is adequate for QoS component data.
A: UPnP state variables support only simple data types (integer, string, boolean, etc.) natively. Complex hierarchical data structures like traffic descriptors and policy rules require a structured representation. XML was chosen for its wide tool support, human readability during debugging, and extensibility through namespaces. The XML payload is carried within a UPnP string variable, which imposes a size limit (typically 32 KB) that is adequate for QoS component data.
Q: Can a device implement only the QoS Component standard without implementing any specific QoS service?
A: The QoS Component standard is designed as a dependency for other QoS services, not as a standalone implementable specification. A device must implement at least one of the QoS Device Service, QoS Manager, or QoS Policy Holder to participate in the UPnP QoS framework. However, implementations of these services must import and correctly handle the component types defined in ISO/IEC 29341-11-2 as part of their state variable and action argument definitions.
A: The QoS Component standard is designed as a dependency for other QoS services, not as a standalone implementable specification. A device must implement at least one of the QoS Device Service, QoS Manager, or QoS Policy Holder to participate in the UPnP QoS framework. However, implementations of these services must import and correctly handle the component types defined in ISO/IEC 29341-11-2 as part of their state variable and action argument definitions.
Q: How are the QoS error codes (700–799) used in practice?
A: Error codes are returned as action output arguments in UPnP SOAP responses. When a QoS service action fails, the error code provides structured information about the failure cause. For example, a QoS Device Service rejecting an AddTrafficShape request returns error code 701 with the additional text “Insufficient bandwidth on interface eth0”. The calling QoS Manager can use this code to determine whether to retry with reduced parameters (error 701) or report a permanent failure (error 703 — policy violation).
A: Error codes are returned as action output arguments in UPnP SOAP responses. When a QoS service action fails, the error code provides structured information about the failure cause. For example, a QoS Device Service rejecting an AddTrafficShape request returns error code 701 with the additional text “Insufficient bandwidth on interface eth0”. The calling QoS Manager can use this code to determine whether to retry with reduced parameters (error 701) or report a permanent failure (error 703 — policy violation).
Q: Does the QoS Component standard define any mandatory-to-implement state variables?
A: Each QoS service specification (11-10, 11-11, 11-12) defines its own mandatory state variables. The QoS Component standard defines the type and structure of these variables but does not itself mandate which variables a device must implement. However, the variable naming conventions, data type mappings, and XML schemas defined in the Component standard are mandatory for any device claiming compliance with the respective QoS service standard.
A: Each QoS service specification (11-10, 11-11, 11-12) defines its own mandatory state variables. The QoS Component standard defines the type and structure of these variables but does not itself mandate which variables a device must implement. However, the variable naming conventions, data type mappings, and XML schemas defined in the Component standard are mandatory for any device claiming compliance with the respective QoS service standard.
