learn
运行时更新与切换：新旧 GCL 混用会怎样出错
理解 Qbv 配置变更时的 base time、版本一致性和回滚问题，避免多设备更新过程中出现短暂窗口错位。
第五章：时间感知调度核心机制IEEE 802.1QbvTAS20 分钟
本节学习目标
- 理解 Qbv GCL 更新不是简单覆盖配置。
- 知道多设备新旧表混用会造成窗口错位。
- 能说明 base time 和版本反馈在更新中的作用。
建议先读
核心概念
schedule updateconfiguration versionbase time activationrollback
本章目录
- 01GCL、cycle 与窗口：Qbv 的最小心智模型从 Gate Control List 的周期、base time、窗口和队列状态理解 Time-Aware Shaper。
- 02guard band 与路径接力：Qbv 真正难在端到端理解普通大帧跨窗、窗口余量、路径传播延迟和多跳接力如何影响 Qbv 可行性。
- 03base time 与 offset：窗口从什么时候开始才算对理解 Qbv 调度表里的 base time、cycle offset 和多设备窗口相位，避免每台设备都正确却端到端错位。
- 04调度可行性：标准定义机制，不替你求解排表理解 Qbv 真正困难的是多流、多跳、多约束下的可行排表，标准机制本身不会自动产生日程。
- 05流量模型与 flow set：排表前先把输入说清楚理解 Qbv 排表需要准确的周期、帧长、deadline、路径和优先级输入，flow set 描述不清会让调度结论失效。
- 06运行时更新与切换：新旧 GCL 混用会怎样出错理解 Qbv 配置变更时的 base time、版本一致性和回滚问题，避免多设备更新过程中出现短暂窗口错位。
- 07Qbv 调试信号：迟到时先看哪几类证据把 Qbv 失败拆成时间同步、队列映射、窗口相位、guard band、流量模型和设备执行几类证据，形成调试路径。
解决什么问题
真实网络不会永远使用同一张 GCL。新增流、路径变化、设备维护、故障切换都可能要求更新调度表。问题是，Qbv 依赖多设备窗口接力，如果某些设备已经使用新表，另一些还在旧表，关键帧就可能掉进错位窗口。
本节解决运行时更新问题：调度表不仅要算对，还要切换对。
背景与直觉
多路口绿波如果要改信号灯计划，不能让一半路口今天切换，另一半明天切换。否则原本连续的绿波会断开。Qbv 也是这样，尤其是多跳关键流。
怎么解决
更新 GCL 时要关注四件事。
| 问题 | 为什么重要 |
|---|---|
| 统一生效时间 | 避免新旧表在路径上混用 |
| 配置版本 | 知道每台设备处于哪一版 |
| 状态反馈 | 确认设备是否成功应用 |
| 回滚策略 | 失败时回到可解释状态 |
base time 可以帮助安排未来某个共同时间点生效。控制器先下发新表，让设备准备好，再在同一个未来时间切换。切换后还要确认设备状态和关键流表现。
带来了什么新问题
运行时更新会让验证变复杂。你不仅要验证稳定运行状态，还要验证切换窗口：切换前、切换中、切换后是否出现 miss、重复或乱序。
如果网络支持冗余路径，切换还可能和 FRER 交互。主路径更新失败时是否切备用，备用路径是否有对应新表，都需要设计。
检查点
- 为什么多设备 Qbv 更新需要统一生效时间？
- 如果路径中一台交换机没有切到新 GCL，你会在抓包或计数器里期待看到什么异常？
掌握检查
读完本节后，先用下面这些问题校准自己，而不是只确认“看过了”。
- 1能解释为什么 GCL 更新最好有统一生效时间。
- 2能列出更新失败时应该保留的回滚或安全策略。