解决什么问题
任何调度或整形机制都要先知道自己作用在哪些流量上。关键帧如果没有被正确识别，后面的 Qbv 窗口、CBS 整形、优先级策略都可能作用不到它身上。流量分类和队列映射就是 TSN 的入口。
在以太网里，流量可能通过 VLAN PCP、端口规则、协议字段、流标识或控制平面配置被映射到某个 traffic class，再进入对应队列。这个过程看似基础，却是很多现场问题的源头：标记不一致、映射表错误、不同设备默认行为不同，都会让端到端设计断裂。
背景与直觉
队列像车站不同候车区。只有先把乘客分到正确候车区，后面的检票顺序、发车窗口和优先服务才有意义。如果关键乘客被分到普通候车区，再高级的专用通道也帮不上忙。
TSN 里的关键流量也是这样。你可以为某个队列配置严格窗口，但如果关键流没有进入该队列，窗口只是给错对象留了时间。反过来，如果太多普通流量被误放进关键队列，关键队列内部又会重新拥堵。
怎么解决
工程上要明确三层关系。第一层是流量识别：这条帧属于哪条流，是否关键，周期和大小是什么。第二层是分类映射：这条流被标成哪个 priority 或 traffic class。第三层是队列行为：该队列使用优先级、CBS、Qbv 还是其他策略。
好的配置会让这些关系在整条路径上保持一致。talker 标记、交换机映射、端口队列和调度表必须互相匹配。测试时也要抓包确认标记是否正确，不能只看管理界面。
| 层次 | 常见配置 | 出错后果 |
|---|---|---|
| 流识别 | MAC/VLAN/IP/端口/stream ID | 关键流没有被识别 |
| 标记 | VLAN PCP、优先级重写 | 不同设备理解不同 |
| 队列映射 | traffic class 到 egress queue | 保护机制作用到错队列 |
| 调度策略 | strict priority、CBS、Qbv | 延迟边界和预期不符 |
带来了什么新问题
分类规则越复杂，误配置风险越高。不同厂商设备对默认 PCP 映射可能不同；某些中间节点可能重写 VLAN 标签；边缘设备可能没有按预期打标。多租户或多业务网络里，还要防止普通业务冒用关键优先级。
因此流量分类既是技术问题，也是治理问题。谁有权声明关键流，关键流数量是否受控，配置变更如何审计，这些都会影响网络长期稳定性。
检查点
- 如果 talker 打了 PCP 6，但中间交换机把 PCP 6 映射到普通队列，会发生什么？
- 为什么测试 TSN 配置时要抓包确认 VLAN/优先级标记，而不是只看设备配置页面？