解决什么问题
流级配置里最容易混淆的是：谁描述业务需求，谁计算网络配置，谁负责把结果落到设备。CUC/CNC 的分工就是为了把这些角色拆开。
如果应用直接面对交换机配置，它很难知道队列、GCL 和路径资源；如果网络控制器直接猜应用需求，也很容易漏掉 deadline、周期和可靠性要求。
背景与直觉
可以把 CUC 看成需求翻译者，把 CNC 看成网络规划者。CUC 帮应用把通信需求整理成网络能理解的形式；CNC 根据拓扑、设备能力和已有资源计算能不能满足这些需求。
怎么解决
用一张分工表理解。
| 角色 | 更关心什么 | 典型输出 |
|---|---|---|
| Application | 控制周期、业务 deadline | 原始通信需求 |
| CUC | talker/listener、流规格、需求表达 | stream request |
| CNC | 拓扑、路径、资源、设备能力 | 网络配置 |
| Bridge/end station | 实际队列、GCL、FRER 状态 | applied state |
这种分工不是为了增加术语，而是减少责任混乱。需求侧不要直接假设网络细节，网络侧也不要凭空猜业务边界。
带来了什么新问题
分工清楚后，接口就变重要。CUC 给 CNC 的需求如果不完整，CNC 计算再准确也没有意义。CNC 下发到设备后，如果没有状态反馈，也无法证明配置落地。
所以 Qcc 的学习不能只停在 CUC/CNC 名词，而要继续看准入控制、配置漂移和验证。
检查点
- CUC 和 CNC 分别更靠近应用侧还是网络侧？
- 如果 CUC 没有提供最大帧长，CNC 的调度计算会缺少什么？