解决什么问题
TSN 不是只配置端口，而是保护具体的流。一条关键流从哪个 talker 发出，送到哪些 listener，周期多长，最大帧多大，截止时间是多少，能走哪些路径，是否需要冗余，这些信息都必须被描述清楚。
stream contract 这个说法强调：网络不能只知道“有关键流量”，还要知道这条流的身份和需求。没有清晰输入，调度算法无法计算，交换机无法一致配置，测试报告也不知道该验证什么。
背景与直觉
把 stream contract 想成工程任务单。任务单里要写清楚发件人、收件人、货物大小、发货频率、最晚到达时间和特殊保护要求。没有任务单，仓库和运输系统只能凭经验处理，自然无法承诺严格边界。
TSN 的流级配置也是这样。优先级、队列、窗口、路径和冗余都应该服务于某条具体流，而不是孤立存在。
怎么解决
描述一条关键流时，至少要关注六类信息。第一是端点：talker 和 listener。第二是流量规格：周期、帧长、突发和速率。第三是时间需求：最大延迟、抖动容忍和截止时间。第四是路径和资源：经过哪些 bridge、需要哪些队列和带宽。第五是保护需求：是否需要复制、多路径或故障恢复。第六是验证目标：最终要测哪些指标。
这些信息可以被集中式控制器、配置工具或人工流程使用。无论形式如何，关键是整条路径上的设备要对同一条流有一致理解。
| 字段 | 为什么重要 | 写错后果 |
|---|---|---|
| 周期/发送间隔 | 决定窗口重复和带宽 | 窗口过少或资源过保守 |
| 最大帧长 | 决定发送时间和 guard band | 窗口预算不足 |
| deadline | 决定端到端约束 | 调度目标不明确 |
| listener 集合 | 决定分发路径 | 漏配某个接收端 |
| 冗余需求 | 决定是否复制和多路径 | 故障连续性无法证明 |
带来了什么新问题
流描述不准确会直接导致配置失效。周期估小了，调度窗口不够；帧长估小了，发送时间不够；listener 变化了，路径资源可能不足；业务升级后流量模型改变，旧配置可能不再成立。
因此 stream contract 不是一次性文档，而应该随系统演进维护。现场变更、设备替换和软件版本升级都可能影响它。
检查点
- 为一条 1ms 周期、最大 300B、要求 250us 内到达的控制流写出最小 contract。
- 如果最大帧长实际是 800B，但 contract 里写 300B，会影响哪些预算？