stream contract：一条关键流应该怎样被描述

解决什么问题

TSN 不是只配置端口，而是保护具体的流。一条关键流从哪个 talker 发出，送到哪些 listener，周期多长，最大帧多大，截止时间是多少，能走哪些路径，是否需要冗余，这些信息都必须被描述清楚。

stream contract 这个说法强调：网络不能只知道“有关键流量”，还要知道这条流的身份和需求。没有清晰输入，调度算法无法计算，交换机无法一致配置，测试报告也不知道该验证什么。

背景与直觉

把 stream contract 想成工程任务单。任务单里要写清楚发件人、收件人、货物大小、发货频率、最晚到达时间和特殊保护要求。没有任务单，仓库和运输系统只能凭经验处理，自然无法承诺严格边界。

TSN 的流级配置也是这样。优先级、队列、窗口、路径和冗余都应该服务于某条具体流，而不是孤立存在。

怎么解决

描述一条关键流时，至少要关注六类信息。第一是端点：talker 和 listener。第二是流量规格：周期、帧长、突发和速率。第三是时间需求：最大延迟、抖动容忍和截止时间。第四是路径和资源：经过哪些 bridge、需要哪些队列和带宽。第五是保护需求：是否需要复制、多路径或故障恢复。第六是验证目标：最终要测哪些指标。

这些信息可以被集中式控制器、配置工具或人工流程使用。无论形式如何，关键是整条路径上的设备要对同一条流有一致理解。

带来了什么新问题

流描述不准确会直接导致配置失效。周期估小了，调度窗口不够；帧长估小了，发送时间不够；listener 变化了，路径资源可能不足；业务升级后流量模型改变，旧配置可能不再成立。

因此 stream contract 不是一次性文档，而应该随系统演进维护。现场变更、设备替换和软件版本升级都可能影响它。

本节掌握标准

学完后，你应该能为一条关键流写出最小 contract：谁发送，谁接收，周期和帧长是多少，最大延迟是多少，是否需要指定路径或冗余。只要这些输入不清楚，后面的调度、整形和验证都很难可靠。