Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29341-11-2:2008 — UPnP QoS组件 — 网络服务质量的构建模块
定义UPnP QoS框架的基础组件类型、状态变量和数据类型模式
QoS组件模型介绍
ISO/IEC 29341-11-2:2008定义了支撑UPnP QoS架构中所有服务的基础组件类型、数据结构和状态变量定义。虽然QoS设备服务、QoS管理器和QoS策略持有者规定了功能实体的行为，但QoS组件标准提供了使这些实体能够互操作的共享词汇和类型系统。它是UPnP QoS框架中所有参与者共同使用的语言。
可以将QoS组件标准视为构建所有QoS服务接口的”字母表”。没有这个公共类型系统，每个服务将独立定义其自己的数据结构，导致同一QoS服务的不同供应商实现之间出现不兼容问题。
该标准定义了多个类别的组件类型：流量规格组件（TrafficDescriptor、TrafficClass、TrafficSpec）、策略组件（PolicyRule、PolicyAction、PolicyPrecedence）、QoS配置组件（TrafficShape、QueueConfiguration、InterfaceInfo）以及状态和错误组件（QoSState、QoSErrorCode、TrafficStats）。每个组件类型都定义了其数据类型、有效值范围和语义含义，确保跨所有QoS服务实现的一致解释。
| 组件类别 | 组件类型 | 基础数据类型 | 使用方 |
|---|---|---|---|
| 流量规格 | TrafficDescriptor | 字符串（结构化XML） | QoS管理器、策略持有者 |
| 流量规格 | TrafficClass | 无符号整数（0–7） | 所有QoS服务 |
| 流量规格 | TrafficSpec | 字符串（结构化XML） | QoS管理器 |
| 策略 | PolicyRule | 字符串（结构化XML） | 策略持有者、QoS管理器 |
| 配置 | TrafficShape | 字符串（结构化XML） | QoS设备服务 |
| 配置 | QueueConfiguration | 字符串（结构化XML） | QoS设备服务 |
| 状态 | QoSState | 字符串（结构化XML） | QoS管理器 |
| 错误 | QoSErrorCode | 无符号整数 | 所有QoS服务 |
| 统计 | TrafficStats | 字符串（结构化XML） | QoS设备服务 |
对复杂组件（TrafficDescriptor、PolicyRule、TrafficShape等）使用结构化XML字符串作为基础数据类型，提供了模式灵活性而无需修改UPnP服务接口。可以向XML模式添加新字段而不更改动作签名，从而实现向后兼容的协议演进。
流量规格组件
TrafficSpec组件是QoS框架中最详细的流量规格说明。它封装了描述流量流QoS需求所需的所有参数，包括承诺信息速率、峰值信息速率、最大突发大小、延迟容限、抖动容限、丢包容限和流量类别。应用程序通过RequestTrafficQoS动作使用TrafficSpec向QoS管理器传达其QoS需求。
TrafficDescriptor组件作为策略规则中使用的匹配模式。它可以指定源和目标IP地址（含子网掩码）、传输协议、源和目标端口范围、DSCP值、802.1p优先级以及可选的应用程序标识符字符串。匹配语义在每个描述符组内遵循”逻辑与”，在多个描述符组之间遵循”逻辑或”，支持灵活的组合规则以处理复杂的流量识别场景。
工程设计见解
使用QoS组件类型的关键技术考虑因素包括：
- XML模式可扩展性：所有复杂组件类型都使用基于XML的序列化。标准为每个组件定义了基础XML模式，但供应商可以使用单独的名称空间将专有元素扩展到模式中。QoS服务实现必须忽略来自扩展模式的未知元素（向前兼容），同时正确解析基础模式中定义的所有元素。
- 状态变量命名：QoS组件标准中定义的UPnP状态变量使用一致的命名约定：以”Info”结尾的变量是只读信息源（如QoSDeviceInfo），以”List”结尾的变量是多值变量（如ActiveFlowList），以”Config”结尾的变量是可写配置参数（如QueueConfig）。这种约定通过名称清晰地表达了变量语义，简化了实现。
- 错误代码标准化：QoS组件标准定义了一个由所有QoS服务使用的统一错误代码表。错误代码范围从700到799（分配给QoS设备和服务的范围）。关键错误代码包括701（带宽不足）、702（不支持流量类别）、703（策略违规）和704（路径不可用）。跨所有服务的一致错误代码方案简化了应用级别的错误处理。
在使用供应商特定参数扩展TrafficSpec XML模式时，实现者必须确保扩展参数不影响不理解这些扩展的标准兼容QoS管理器的接纳控制行为。基础模式解析必须是自包含的——扩展参数应仅增强、绝不覆盖基础TrafficSpec语义。
状态变量定义与数据流
QoS组件标准定义了构成QoS服务交互主干的狀態变量。关键状态变量包括：QoSDeviceInfo（通告设备能力，包括支持的流量类别、队列数量和整形速率限制）、TrafficShapeList（设备上活跃的流量调节规则集）、PolicyTable（存储在策略持有者中的完整策略规则集）和ActiveFlowTable（QoS管理器跟踪的所有当前已接纳QoS流）。每个变量都有定义的数据类型、允许值范围和事件通知行为（变更是否生成UPnP事件）。
组件之间的数据流遵循定义良好的生命周期：TrafficSpec从应用到QoS管理器，PolicyRule从策略持有者到QoS管理器，TrafficShape配置从QoS管理器到QoS设备服务，以及TrafficStats从QoS设备服务返回QoS管理器用于监控目的。QoS组件标准的类型定义确保此数据流的每个阶段都使用可互操作的数据表示，无论设备制造商或实现语言如何。
常见问题解答
问：为什么QoS组件标准对复杂结构使用XML字符串而非原生UPnP数据类型？
答：UPnP状态变量本身只支持简单数据类型（整数、字符串、布尔值等）。复杂的层次化数据结构如流量描述符和策略规则需要结构化表示。选择XML是因为其广泛的工具支持、调试时的人类可读性以及通过名称空间实现的扩展性。XML负载在UPnP字符串变量内传输，这有一个大小限制（通常为32 KB），对QoS组件数据来说足够使用。
答：UPnP状态变量本身只支持简单数据类型（整数、字符串、布尔值等）。复杂的层次化数据结构如流量描述符和策略规则需要结构化表示。选择XML是因为其广泛的工具支持、调试时的人类可读性以及通过名称空间实现的扩展性。XML负载在UPnP字符串变量内传输，这有一个大小限制（通常为32 KB），对QoS组件数据来说足够使用。
问：设备能否仅实现QoS组件标准而不实现任何具体的QoS服务？
答：QoS组件标准设计为其他QoS服务的依赖项，而非独立的可实现规范。设备必须至少实现QoS设备服务、QoS管理器或QoS策略持有者之一才能参与UPnP QoS框架。但是，这些服务的实现必须导入并正确处理ISO/IEC 29341-11-2中定义的组件类型，作为其状态变量和动作参数定义的一部分。
答：QoS组件标准设计为其他QoS服务的依赖项，而非独立的可实现规范。设备必须至少实现QoS设备服务、QoS管理器或QoS策略持有者之一才能参与UPnP QoS框架。但是，这些服务的实现必须导入并正确处理ISO/IEC 29341-11-2中定义的组件类型，作为其状态变量和动作参数定义的一部分。
问：QoS错误代码（700–799）在实践中如何使用？
答：错误代码作为动作输出参数在UPnP SOAP响应中返回。当QoS服务动作失败时，错误代码提供了关于失败原因的结构化信息。例如，QoS设备服务拒绝AddTrafficShape请求时返回错误代码701并附加文本”接口eth0带宽不足”。调用方QoS管理器可以使用此代码来确定是使用降级参数重试（错误701）还是报告永久性故障（错误703——策略违规）。
答：错误代码作为动作输出参数在UPnP SOAP响应中返回。当QoS服务动作失败时，错误代码提供了关于失败原因的结构化信息。例如，QoS设备服务拒绝AddTrafficShape请求时返回错误代码701并附加文本”接口eth0带宽不足”。调用方QoS管理器可以使用此代码来确定是使用降级参数重试（错误701）还是报告永久性故障（错误703——策略违规）。
问：QoS组件标准是否定义了任何强制实现的状态变量？
答：每个QoS服务规范（11-10、11-11、11-12）都定义了其自己的强制状态变量。QoS组件标准定义了这些变量的类型和结构，但本身并未强制要求设备必须实现哪些变量。但是，组件标准中定义的变量命名约定、数据类型映射和XML模式对于任何声称符合相应QoS服务标准的设备都是强制性的。
答：每个QoS服务规范（11-10、11-11、11-12）都定义了其自己的强制状态变量。QoS组件标准定义了这些变量的类型和结构，但本身并未强制要求设备必须实现哪些变量。但是，组件标准中定义的变量命名约定、数据类型映射和XML模式对于任何声称符合相应QoS服务标准的设备都是强制性的。
