解决什么问题
队列、CBS 和 Qbv 都默认输入流量大致符合设计规格。如果 talker 本来承诺每 1 ms 发一帧，结果突然连续发 20 帧；或者最大帧长承诺 300 B，实际发 1500 B，那么后面的队列和调度都会被拖下水。
本节解决入口约束问题：确定性不是只靠交换机内部排队，源头输入也要可控。坏输入不能完全交给队列背锅。
背景与直觉
如果餐厅厨房按每分钟 10 单设计，前台却在 10 秒内塞进 100 单，后厨排班再合理也会崩。网络里也是一样。TSN 配置通常来自某个流量 contract，设备必须有办法检查输入是否符合这个 contract。
policing 更像门口检查：不符合规格的流量被标记、限制或丢弃。shaping 更像节奏调整：把符合或近似符合的流量按更温和的节奏发出去。
怎么解决
入口约束通常关注四类问题。
| 输入问题 | 影响 | 需要的动作 |
|---|---|---|
| 最大帧长超规格 | 发送时间和窗口预算变大 | 拒绝、丢弃或重新分类 |
| 周期/速率超规格 | 队列堆积，CBS credit 失真 | policing 或准入重新评估 |
| PCP/流标识错误 | 进入错误队列 | 分类规则和配置校验 |
| 非预期突发 | 尾延迟升高 | 限速、整形或告警 |
入口约束和 Qcc 的 stream contract 联系很紧。contract 描述流应该是什么样，入口设备要尽量保证实际进入网络的流没有偏离太远。
带来了什么新问题
入口限制会引入策略问题：超规格帧应该直接丢弃，还是降级到普通队列？短暂超速是否允许？错误分类是配置问题还是攻击行为？这些策略会影响业务可用性和安全性。
另一个问题是可观测性。你需要计数器和日志知道哪些流被限制过，否则现场只会看到“某条流偶发丢帧”，却不知道是入口保护在工作。
检查点
- 如果一个关键流实际最大帧长比 contract 大 4 倍，后续 Qbv 窗口会受到什么影响？
- policing 和 shaping 都能改变流量行为，它们分别位于哪个阶段，目的有什么不同？