Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29341-11-12:2008 — UPnP QoS策略持有者 — 集中式策略存储与管理
定义用于策略规则存储、检索和生命周期管理的QoS策略持有者服务
QoS策略持有者介绍
ISO/IEC 29341-11-12:2008定义了QoS策略持有者，这是UPnP QoS架构中QoS策略规则的持久化存储和管理实体。策略持有者维护着适用于网络的所有QoS策略的权威数据库，通过标准化的UPnP服务接口提供创建、读取、更新和删除（CRUD）操作。它充当QoS策略决策的单一真相来源，确保跨所有QoS管理器实例和网络段的一致规则执行。
QoS策略持有者是UPnP QoS框架的”规则簿”。虽然QoS管理器做出实时的接纳控制决策，但策略持有者定义了管理这些决策的规则——包括允许哪些流量类别、哪些应用获得优先级处理，以及在什么条件下允许抢占。
策略持有者服务暴露的动作包括AddPolicy、UpdatePolicy、RemovePolicy、GetPolicy、GetAllPolicies和GetPolicyChangeCounter。这些动作操作于策略数据库，其中每个条目都是ISO/IEC 29341-10-12中定义的完整QoS策略规则，包括优先级值、流量描述符、流量类别分配、动作列表和可选的有效时段。该服务还会在策略被添加、修改或删除时生成事件通知，使QoS管理器和其他订阅的控制点能够维护同步的策略缓存。
| 策略持有者动作 | 描述 | 参数 | 错误条件 |
|---|---|---|---|
| AddPolicy | 向数据库添加新的策略规则 | PolicyRule（完整规则结构） | 重复优先级、无效描述符、存储已满 |
| UpdatePolicy | 修改由策略ID标识的现有策略规则 | PolicyID, UpdatedRule字段 | PolicyID未找到、版本不匹配 |
| RemovePolicy | 从数据库删除策略规则 | PolicyID | PolicyID未找到、规则受保护 |
| GetPolicy | 按ID检索特定策略规则 | PolicyID | PolicyID未找到 |
| GetAllPolicies | 检索所有策略规则，可按流量类别过滤 | 可选TrafficClass过滤器 | — |
| GetPolicyChangeCounter | 返回当前策略变更计数器值 | — | — |
GetPolicyChangeCounter动作提供了一种高效的基于轮询的变更检测机制。QoS管理器和其他订阅者可以定期轮询此计数器（而非订阅事件），并且仅在计数器值变化时才检索完整的策略集，从而在策略更新不频繁的网络中最小化带宽开销。
策略数据库架构与版本管理
策略持有者使用版本化数据库模型管理策略。每条策略规则带有PolicyID（创建时分配的唯一标识符）和VersionNumber（每次更新时单调递增）。VersionNumber支持并发访问一致性：检索具有特定版本的策略规则的QoS管理器可以使用条件更新操作来防止当多个管理器或管理工具同时修改同一策略时出现丢失更新的冲突。
策略数据库通过可选的PolicyGroup标签支持策略分组，使管理员能够按应用领域（如”视频流”、”语音”、”游戏”）、网络段或设备类型组织规则。分组还便于批量操作——GetAllPolicies动作可以按组过滤，当设备或服务退役时，RemovePolicy动作可以清除属于特定组的所有策略。
工程设计见解
有效部署QoS策略持有者需要注意以下几个设计考虑因素：
- 策略存储容量规划：家庭网络设备通常在资源受限的平台上实现策略持有者（例如具有有限闪存存储的住宅网关）。工程师应规划至少128条策略规则作为基线，高级部署需要512条或更多。标准允许策略持有者通过其设备描述报告最大容量，使QoS管理器能够相应地做出策略添加决策。
- 受保护策略规则：标准定义了一个”受保护”标志，阻止通过标准的UpdatePolicy/RemovePolicy动作修改或删除策略规则。受保护规则通常是制造商定义的默认策略（如”始终优先处理DHCP和DNS流量”），确保即使策略数据库通过管理工具配置错误，基本网络功能仍能正常运行。
- 策略验证与冲突检测：在接受AddPolicy或UpdatePolicy请求之前，策略持有者应验证规则结构的内部一致性——检查流量描述符格式是否正确、优先级值是否在允许范围内、以及引用的流量类别是否得到网络设备的支持。高级实现还可以执行跨规则冲突检测，以警告管理员存在具有不一致流量类别分配的重叠描述符。
过于宽泛的策略规则（如一条规则匹配所有TCP流量并将其分配到TrafficClass 7）可能导致批量数据传输优先于实时应用。工程师应设计具有适当特定性的策略规则——匹配端口范围、应用签名或DSCP值——以确保优先级仅在需要的地方应用。
事件通知与缓存同步
QoS策略持有者实现标准的UPnP事件通知机制。当策略被添加、更新或删除时，策略持有者向所有订阅的控制点（通常是QoS管理器和管理工具）发送PolicyChanged事件。事件负载包括PolicyChangeCounter值和受影响规则的PolicyID，允许订阅者增量更新其本地缓存，而无需在每次变更时执行完整的策略数据库检索。
为增强网络弹性，策略持有者应在每次修改后将其策略数据库持久化到非易失性存储。设备重启时，策略持有者从持久化存储重新加载策略数据库，并向所有订阅者发送完整的策略集通知，确保在任何策略持有者中断后QoS管理器缓存能够重新同步。这种持久化和重新同步机制对于跨设备重启和网络分区维护一致的QoS行为至关重要。
常见问题解答
问：同一个UPnP网络上可以有多个QoS策略持有者吗？
答：可以——一个网络上可以有多个策略持有者，每个管理不同网段或设备组的策略。QoS管理器在接纳控制期间必须查询所有可用的策略持有者，以获取适用于流量流的完整策略集。跨多个持有者的策略冲突由QoS管理器使用基于优先级的合并算法解决：限制最严格的适用策略获胜。
答：可以——一个网络上可以有多个策略持有者，每个管理不同网段或设备组的策略。QoS管理器在接纳控制期间必须查询所有可用的策略持有者，以获取适用于流量流的完整策略集。跨多个持有者的策略冲突由QoS管理器使用基于优先级的合并算法解决：限制最严格的适用策略获胜。
问：策略持有者如何处理恢复出厂设置场景？
答：标准建议策略持有者实现一个”出厂默认”策略集，在触发设备重置时恢复。制造商定义的受保护策略包含在此默认集中，而用户添加的策略被清除。QoS管理器通过PolicyChanged事件接收策略重置通知，触发完整的策略缓存刷新。
答：标准建议策略持有者实现一个”出厂默认”策略集，在触发设备重置时恢复。制造商定义的受保护策略包含在此默认集中，而用户添加的策略被清除。QoS管理器通过PolicyChanged事件接收策略重置通知，触发完整的策略缓存刷新。
问：QoS策略持有者在存储策略之前是否需要验证策略？
答：标准要求基本的结构验证（必填字段格式正确、值范围有效），但复杂的语义验证（如验证引用的DSCP值是否得到网络设备支持）是实现定义的。高级策略持有者实现可以与QoS管理器的GetQoSDeviceInfo功能集成，在AddPolicy操作期间执行跨设备策略验证。
答：标准要求基本的结构验证（必填字段格式正确、值范围有效），但复杂的语义验证（如验证引用的DSCP值是否得到网络设备支持）是实现定义的。高级策略持有者实现可以与QoS管理器的GetQoSDeviceInfo功能集成，在AddPolicy操作期间执行跨设备策略验证。
问：哪些安全机制保护策略数据库免受未授权修改？
答：基本UPnP QoS架构未强制要求策略持有者接口的特定安全机制。但是，UPnP设备架构版本1.1及更高版本提供了可选的安全功能，包括操作授权和访问控制列表。针对企业或服务提供商部署的实现应启用这些安全功能，并额外考虑对策略持有者通信进行传输层保护。
答：基本UPnP QoS架构未强制要求策略持有者接口的特定安全机制。但是，UPnP设备架构版本1.1及更高版本提供了可选的安全功能，包括操作授权和访问控制列表。针对企业或服务提供商部署的实现应启用这些安全功能，并额外考虑对策略持有者通信进行传输层保护。
