解决什么问题
在一条路径上，每台设备都可能配置正确，但组合起来仍然错误。第一跳窗口太早，第二跳窗口太晚；某台设备队列映射不同；中间链路没有足够带宽；冗余路径实际共享同一个故障点。集中式配置要解决的就是这种端到端一致性问题。
它的价值不只是“自动下发配置”，而是用全局视角计算路径和资源。局部最优不一定端到端可行，尤其是关键流数量变多以后。
背景与直觉
把网络配置想成城市交通管制。每个路口自己调灯，可能会让本路口看起来顺畅，但整条干线未必协调。集中式规划至少知道整条路线、车流需求和路口能力，才能设计绿波或限流策略。
TSN 的 CNC/CUC 思路也类似。用户侧描述通信需求，网络侧根据拓扑和设备能力计算配置，再下发到相关设备，并收集状态反馈。
怎么解决
集中式配置通常需要四类输入：拓扑、设备能力、流需求和策略目标。拓扑告诉控制器有哪些节点和链路；设备能力告诉它支持哪些 TSN 功能；流需求来自 stream contract；策略目标可能是最小延迟、最大可调度流数量、减少 guard band 或提高冗余。
输出则可能包括路径、队列映射、带宽预留、GCL、抢占配置和 FRER 规则。真正可靠的系统还需要反馈机制，确认设备是否成功应用配置。
| 输入/输出 | 例子 | 风险 |
|---|---|---|
| 拓扑输入 | 节点、链路、速率、故障域 | 拓扑过期导致路径不可用 |
| 设备能力 | Qbv、抢占、FRER、队列数量 | 假设设备支持但实际不支持 |
| 流需求 | 周期、帧长、deadline | 调度计算输入错误 |
| 配置输出 | GCL、队列、路径、冗余 | 下发失败或部分应用 |
| 状态反馈 | applied/failed、版本、错误码 | 没反馈就无法证明一致 |
带来了什么新问题
集中式配置引入控制平面复杂度。控制器要获得准确拓扑，处理设备差异，管理配置版本，避免下发中途出现不一致状态。控制器本身也可能成为可靠性和安全性关注点。
此外，集中规划的算法复杂度可能很高。多流、多路径、多机制共同优化时，很容易变成难以快速求解的问题。这也是为什么很多工具和算法关注启发式策略、增量调度和可扩展性。
检查点
- 集中式配置至少需要哪些输入，才能计算一条关键流的路径和资源？
- 为什么“控制器下发了配置”还不等于“设备实际处于正确状态”？