learn
CUC 与 CNC：需求侧和网络侧各负责什么
理解 802.1Qcc 集中式模型里的 CUC/CNC 分工，避免把应用需求、网络规划和设备下发混在一起。
第七章：流级配置编排资源IEEE 802.1Qcc18 分钟
本节学习目标
- 理解 CUC 更靠近应用需求，CNC 更靠近网络资源。
- 知道需求表达和网络配置之间需要翻译层。
- 能解释为什么 Qcc 不只是一个控制器。
建议先读
核心概念
CUCCNCuser requirementsnetwork configuration
本章目录
- 01stream contract：一条关键流应该怎样被描述从 talker、listener、周期、帧长、截止时间和路径需求理解 802.1Qcc 的流级视角。
- 02CUC 与 CNC：需求侧和网络侧各负责什么理解 802.1Qcc 集中式模型里的 CUC/CNC 分工，避免把应用需求、网络规划和设备下发混在一起。
- 03集中式配置：为什么端到端一致比单点正确更重要理解 CNC/CUC 式集中规划如何减少路径配置漂移，以及它对拓扑、设备能力和状态反馈的依赖。
- 04准入控制：网络什么时候应该拒绝一条新流理解 Qcc 不只是下发配置，还要判断新增关键流是否会破坏已有流的时间、带宽和可靠性边界。
- 05路由与调度耦合：路径选错会让排表变难理解 Qcc 中路径选择、Qbv 调度、FRER 冗余和资源预留互相影响，不能把路由和排表完全分开。
- 06配置漂移与状态反馈：控制器算对了还不够学习 Qcc 落地时最容易忽略的问题：设备是否真的应用配置，版本是否一致，失败是否被反馈。
- 07部署与回滚：配置失败时网络要进入可解释状态学习 Qcc 配置上线时如何处理分批下发、部分失败、回滚、安全状态和验证窗口，避免自动化配置造成不可控中间态。
解决什么问题
流级配置里最容易混淆的是：谁描述业务需求，谁计算网络配置，谁负责把结果落到设备。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 的调度计算会缺少什么？
掌握检查
读完本节后，先用下面这些问题校准自己，而不是只确认“看过了”。
- 1能用自己的话区分 CUC 和 CNC。
- 2能说明 CUC/CNC 分工如何减少应用和网络之间的误解。