IEEE 802.1 / TSN Wiki

来源_IEEE_802.1CB_可靠性帧复制与消除_deep_dive

24分钟阅读

深度来源笔记：IEEE 802.1CB 可靠性帧复制与消除

来源信息

  • 标题：IEEE Standard for Local and metropolitan area networks - Frame Replication and Elimination for Reliability
  • 标准号：IEEE Std 802.1CB-2017
  • 发布时间：2017-10-27
  • 原始文件：raw/802.1CB.md
  • 学习定位：TSN 可靠性机制核心标准
  • 关联概念：概念_FRER与复合流、概念_VLAN感知桥与转发数据库

这篇资料解决什么问题

802.1CB 试图解决一个很工程化的问题：在工业控制、车载网络、音视频、自动化等时间敏感场景里，某些数据流不能接受“链路断了以后等网络重新收敛”。FRER 的策略不是等故障发生后再修复路径，而是提前复制关键流，让多个副本沿不同路径传输，在接收侧或中间恢复点只保留一个有效副本。

这份标准的中心思想可以压缩成一句话：给每个关键帧加上可识别的序列信息，把它变成多个成员流冗余发送，再在合并点根据序列号消除重复。

不过 802.1CB 的边界也很重要。它不做路径计算，不保证路径无拥塞，不保证重排成原始顺序，也不单独完成 TSN 的全部确定性目标。它更像一层可靠性功能，需要和 802.1Q 的桥接、流识别、资源预约、队列控制一起工作。

阅读前需要知道什么

802.1Q 桥接背景

FRER 不是一个脱离二层桥接网络的新协议。它会嵌入 802.1Q 的 Forwarding Process，并且依赖 VLAN、端口、转发、流标识等已有机制。因此读 802.1CB 时，要不断把它放回 概念_VLAN感知桥与转发数据库 的背景里。

TSN Stream 背景

标准里的 Stream 不是“随便一条 TCP 连接”那种泛称。它通常有 Talker、Listener、最大包大小、固定或受约束的发送间隔，也可能有带宽和延迟资源规划。FRER 对这样的 Stream 做复制与恢复。

可靠性和确定性不是同一件事

FRER 提高送达概率，但它可能引入重复、乱序、额外带宽和缓存压力。要达到“无拥塞损失”和“有限时延”，还需要其它 TSN 机制配合。

原文结构地图

Clause 1：Overview

这一章最重要，建议先读。它包含 Scope、Rationale、Specification model 和 Introduction。Scope 说明标准定义桥和端系统中的识别、复制、去重流程，但不负责多路径创建。Rationale 解释为什么需要 FRER：动态恢复太慢时，预先冗余更可靠。Introduction 引出 Talker、Listener、Reservation、Compound Stream、Member Stream 的模型。

Clause 3/4：Definitions 与 Acronyms

这里给出几个必须掌握的词：Compound Stream、Member Stream、FRER、R-TAG。读后文时最容易混淆的是 Stream 的不同层次：一个应用意义上的流、802.1Q 中被预约的流、FRER 中的复合流和成员流，语境不同。

Clause 5：Conformance

这一章从设备角色角度拆 FRER：Stream identification component、Talker end system、Listener end system、Relay system、FRER C-component。它的价值不是背条款，而是看懂“FRER 功能可以部署在哪里”。

Clause 6：Stream identification

FRER 要先知道某个帧属于哪个流，才谈得上复制和恢复。这里定义 stream_handle 和 sequence_number 等服务参数，也介绍不同识别方式，例如 Source MAC and VLAN、Active Destination MAC and VLAN、IP Stream identification。

Clause 7：FRER 核心机制

这是标准主体。它定义 Compound Stream、Member Stream、Sequence generation、Sequence recovery、Base recovery、Individual recovery、Sequence encode/decode、R-TAG、HSR/PRP 互操作等。学习这章时，建议按“生成序列号 → 复制 → 传输 → 合并 → 去重”这条线读。

Clause 8：FRER in Bridges

这一章解释 FRER 如何放进 802.1Q 桥。重点是：FRER 功能可以出现在桥的输入侧、输出侧或转发路径周围，但外部可见行为要符合标准模型。这里还解释了 FRER 与 VLAN tag 的关系。

Clause 9/10：管理对象和计数器

这两章偏实现和运维。它们定义如何配置 FRER，如何表示 Stream identification、sequence generation、sequence recovery、autoconfiguration，以及如何统计错误、重复、恢复等行为。

Annex C：系统示例

这是理解 FRER 最友好的部分。它把抽象机制放进具体拓扑：端到端 FRER、relay proxy、梯形冗余、多播、协议互通、带宽预约和个体恢复。对学习者来说，Annex C 往往比条款正文更有解释力。

核心概念表

概念正式语境学习时的直觉
Talker发起 Stream 的端系统关键数据的源头
Listener消费 Stream 的端系统需要收到数据的一端
Stream被识别、预约或处理的一类流FRER 操作的对象
Compound Stream由多个 Member Streams 组成的 FRER 流一个逻辑流的冗余整体
Member StreamCompound Stream 中的一条成员流一个副本走的一条路径
Sequence number标识帧顺序的数字判断“这个包见过没”的依据
Sequence generation生成序列号的功能给每个要复制的帧贴编号
Sequence recovery合并成员流并去重的功能只保留第一个有效副本
Individual recovery针对单个 Member Stream 的恢复功能拦截坏路径上的重复旧帧
R-TAGRedundancy tag把序列号放进以太帧的一种标签
Stream identification流识别功能判断帧属于哪个 FRER 处理实例

机制拆解

1. 流识别：先把帧归属搞清楚

FRER 的第一步不是复制，而是识别。一个桥或端系统必须知道输入帧属于哪个 Stream，才能决定它是否要被序列化、复制、恢复或普通转发。标准通过 stream_handle 把识别结果传给后续功能。

Stream identification 可以基于不同字段。Source MAC and VLAN 适合按源和 VLAN 组织流；Active Destination MAC and VLAN 可以在输出侧改变目标 MAC/VLAN，让成员流在桥接网络里走不同路径；IP Stream identification 则适合在代理场景里识别上层流。

2. 序列生成：让副本之间可比较

复制后的帧如果没有共同编号，接收侧就无法判断两个副本是不是同一个原始帧。Sequence generation function 的作用就是为每个帧生成序列号。序列号通常在 Talker 或靠近 Talker 的代理 relay 上生成。

序列号不一定在整个系统全局唯一。它通常只需要在对应 Stream 和对应恢复窗口中有意义。标准还讨论了 per-Stream sequencing 和 per-source sequencing 的区别，这对实现和配置都很重要。

3. 复制与成员流：把一个逻辑流变成多个路径流

FRER 把原始 Stream 组织成 Compound Stream。Compound Stream 包含一个或多个 Member Streams，每个 Member Stream 可以沿不同路径传播。复制可以发生在 Talker，也可以发生在 relay。标准甚至允许 relay 代理不支持 FRER 的终端，把普通流转成 FRER 复合流。

这里要小心一个点：Member Stream 的路径选择不是 802.1CB 本身完成的。路径可能来自 VLAN 规划、显式配置、其它冗余机制、链路聚合或专门的 TSN 配置。

4. 序列编码：让序列号进入帧

内部服务参数需要通过某种方式放进实际帧中，才能跨设备传输。R-TAG 是 802.1CB 中非常重要的一种方式，它给帧携带 redundancy tag 和 sequence number。标准还讨论了 HSR sequence tag、PRP sequence trailer 等互操作形式。

如果某些终端不理解这些额外标签，就需要在靠近终端的 relay 上插入或移除标签。Annex C.8 特别提醒：标签没有正确移除时，不支持对应解码功能的终端可能无法解析帧。

5. 合并和去重：恢复单一有效流

当多个 Member Streams 在某个节点汇合时，Sequence recovery function 根据 sequence number 判断哪些帧已经见过。第一个有效副本被交付，后续重复副本被丢弃。

标准里有两个恢复算法方向：VectorRecoveryAlgorithm 和 MatchRecoveryAlgorithm。它们都服务于“识别重复并决定是否交付”，但适用流类型和状态维护方式不同。学习阶段可以先抓住共同目标：恢复函数维护一个历史窗口，用于判断新来的序列号是否已经被接收。

6. 个体恢复：提前隔离坏成员流

Individual recovery function 容易被忽视。它不是合并多个 Member Streams 的主恢复点，而是针对单个 Member Stream 做重复过滤。它的典型用途是防止某条路径上的故障节点不断重复发送旧帧，让这些旧帧污染后续 Sequence recovery。

换句话说，Sequence recovery 是“合并处去重”，Individual recovery 是“单条成员路径上先清理异常重复”。

关键流程 / 数据路径 / 控制路径

发送侧数据路径

  1. 输入帧被 Stream identification 识别。
  2. 系统为该 Stream 选择一个 FRER 处理实例。
  3. Sequence generation 生成序列号。
  4. Sequence encode/decode 把序列号编码到帧里，例如使用 R-TAG。
  5. Stream splitting 或桥接多播机制复制帧。
  6. 不同副本被标识为不同 Member Streams 并送往不同端口或路径。

中间 relay 数据路径

relay 可以有多种角色：

  • 纯转发：只转发 Member Streams，不做恢复。
  • 代理发送侧：为不支持 FRER 的终端生成序列号并复制。
  • 中间恢复点：在网络中间合并一部分 Member Streams，丢掉重复后再继续转发。
  • 协议互通点：在 R-TAG、HSR、PRP 或其它封装之间转换。

接收侧数据路径

  1. 多个 Member Streams 到达同一恢复点。
  2. Stream identification 把它们归入同一个恢复实例。
  3. Sequence encode/decode 取出序列号。
  4. Sequence recovery 检查历史窗口。
  5. 未见过的帧被交付，重复帧被丢弃。
  6. 上层看到的是尽量恢复后的单一流。

控制与管理路径

Clause 9/10 的管理对象用于配置：

  • 哪些流需要被识别。
  • 哪些端口执行 sequence generation 或 sequence recovery。
  • 使用哪种序列编码方式。
  • 恢复历史窗口长度、超时、计数器等参数。
  • autoconfiguration 如何根据收到的帧自动建立部分配置。

章节级拆解

Clause 1.1 Scope

本标准定义桥和端系统中的 FRER 程序、管理对象和协议。它强调三类能力：识别要复制的包、冗余传输、识别并消除重复包。它也明确排除多路径创建。

学习重点：范围边界。读完这一节要知道 FRER 不是路由协议，也不是完整 TSN 系统，只是可靠性功能块。

Clause 1.2 Rationale

动机是提高给定数据包送达概率。标准提到，在固定拓扑、且路径被保护免于拥塞丢失时，FRER 能显著降低因设备故障导致的丢包概率。

学习重点：FRER 的效果依赖前提。路径要独立，资源要被正确配置，复制才有价值。

Clause 1.6 Introduction

这里建立 Talker、Listener、Stream、Reservation、Compound Stream、Member Stream 的总体模型。它说明在动态恢复不可接受时，可以把一个 Stream 拆成多个 Member Streams，复制后再合并。

学习重点：这是理解全标准的概念入口。

Clause 5 Conformance

Conformance 不是只给厂商测试用。它也告诉学习者 FRER 功能可能部署在哪些设备中：

  • Talker 负责产生 Compound Streams。
  • Listener 负责消费 Compound Streams。
  • Relay systems 可以转发或丢弃 Compound Stream 的包。
  • Stream identification component 可以只识别流，不处理序列号。

学习重点：FRER 不一定端到端都由终端完成，中间桥也可以承担代理或恢复职责。

Clause 6 Stream identification

FRER 需要 stream_handle 和 sequence_number 这样的内部服务参数。标准定义了多种识别方式，包括基于 MAC/VLAN 和基于 IP 的识别。FRER 与 802.1Q 的联系在这里非常明显，因为 VLAN 和桥接转发字段会参与流识别。

学习重点：没有流识别，FRER 的复制和恢复都没有对象。

Clause 7 FRER functions

这是核心章。建议分成四层读：

  • 目标层：提高送达概率，但不保证重排。
  • 结构层：Compound Stream 和 Member Streams。
  • 功能层：sequence generation、sequence recovery、individual recovery、encode/decode、splitting。
  • 算法层：VectorRecoveryAlgorithm、MatchRecoveryAlgorithm、历史窗口和超时。

学习重点：FRER 的本质是“有状态的去重系统”，复制只是前半段，恢复窗口和序列状态才决定后半段是否正确。

Clause 8 FRER in Bridges

这章把 FRER 放进 802.1Q 桥。标准说明 FRER 功能可以嵌入 Forwarding Process 周围，且可以用桥接多播机制完成复制。它还讨论了带 VLAN tag 和 R-TAG 的帧格式关系。

学习重点：FRER 不是绕开桥接，而是利用桥接。很多复制、输出端口选择和 VLAN 变换仍依赖 802.1Q。

Clause 10 Management

这一章提供配置表和计数器。对学习者来说，不必第一遍记住每个对象名，但要理解管理对象对应的工程问题：配置哪个流、在哪个端口恢复、用什么封装、窗口多大、错误怎么计数。

学习重点：FRER 是可配置的功能集合，不是单一自动行为。

Annex C Examples

Annex C 是把理论落地的关键。它解释：

  • End-to-end FRER：两端系统完成复制和恢复。
  • Various stack positions：relay 可以替普通终端代理 FRER。
  • Ladder redundancy：用上下路径和横向连接抵抗链路故障。
  • Multicast trees：多 Listener 场景下的冗余路径。
  • Protocol interworking：不同封装方式之间的转换。
  • FRER and reserved bandwidth：复制和路径时延差会带来额外缓存需求。
  • Individual recovery：坏成员流重复旧帧时，提前丢弃有价值。

学习重点：Annex C 说明了 FRER 的灵活性，也暴露了它的复杂性。

关键定义的定位

  • Scope：raw/802.1CB.md 中 Clause 1.1 附近。
  • Rationale：Clause 1.2。
  • Compound Stream：Definitions 中的 Compound Stream 条目。
  • Member Stream：Definitions 中的 Member Stream 条目。
  • R-TAG：Acronyms 与 Clause 7.8 附近。
  • Sequence generation：Clause 7.4.1。
  • Sequence recovery：Clause 7.4.2 与 7.4.3。
  • FRER in Bridges：Clause 8。
  • Practical examples：Annex C。

术语之间的依赖关系

flowchart TD
  A["Stream identification"] --> B["stream_handle"]
  B --> C["Sequence generation"]
  C --> D["sequence_number"]
  D --> E["Sequence encode/decode"]
  E --> F["Member Streams"]
  F --> G["Sequence recovery"]
  G --> H["Duplicate elimination"]
  H --> I["Reconstituted Stream"]

这个依赖图可以帮助阅读：先识别流，再生成序列号，再复制成成员流，最后用序列号恢复。

与其它来源的关系

易混点

FRER 不是路径控制

标准不创建多路径。路径可能来自 VLAN 配置、显式路径、链路聚合、DRNI、HSR/PRP 互操作或其它网络规划。

去重不等于排序

FRER 可以丢弃重复副本，但不同路径长度不同会导致乱序。标准明确把恢复原始顺序放在范围之外。

成员流也可能需要资源

如果每条 Member Stream 都占用网络资源，那么带宽预约和缓存设计要按复制后的流量考虑。Annex C.9 专门说明路径时延差可能导致恢复点出现短时间双倍负载。

R-TAG 不是唯一封装

R-TAG 是 802.1CB 的重要标签，但标准还讨论了 HSR/PRP 等序列编码互操作。实现时要关注封装转换和标签移除。

Relay 可以很主动

中间桥不一定只是转发。它可以代理不支持 FRER 的终端，执行序列生成、复制、恢复、封装转换等功能。

例子 / 场景推演

场景 1：端到端 FRER

Talker 支持 FRER。它为每个帧生成序列号，复制成两条 Member Streams。网络中间只负责把两条路径转发到 Listener。Listener 用 sequence recovery 合并两条成员流。如果两条都到，只交付一份；如果一条断了，另一条仍能提供数据。

适合场景：端系统能力强，网络中间配置相对简单。

场景 2：Relay 代理普通终端

终端 A 不支持 FRER，但靠近 A 的 relay B 支持。B 识别 A 发出的普通流，为其生成序列号并复制成多个 Member Streams。后续 relay 或 Listener 再恢复。

适合场景：终端不能改造，但网络设备支持 TSN 功能。

场景 3：中间恢复点

多个 Member Streams 可以在网络中间先合并一次，消除重复后再继续传播。这可以减少后半段网络负载，也可以构建多级可靠性结构。

风险：恢复点本身变成关键配置点，需要正确设置恢复窗口和输出行为。

场景 4：短路径恢复后的突发

如果两条路径时延差很大，短路径失败后又恢复，恢复点可能短时间收到来自短路径的新包和长路径积压包。Sequence recovery 会去重，但输出速率和缓存压力仍然要处理。这个问题超出 FRER 本身，需要预约、整形或缓存策略配合。

读这篇标准时的推荐顺序

  1. 先读 Clause 1.1、1.2、1.6，建立范围和直觉。
  2. 再读 Definitions 里的 Compound Stream、Member Stream、R-TAG。
  3. 读 Clause 6，弄清 Stream identification。
  4. 读 Clause 7.1、7.3、7.4，掌握 FRER 功能和序列恢复。
  5. 读 Clause 8，理解它如何进入 802.1Q 桥。
  6. 读 Annex C，补具体场景。
  7. 最后再回头看 Clause 9/10 的管理对象。

我还没完全理解的问题

  • VectorRecoveryAlgorithm 和 MatchRecoveryAlgorithm 在工程产品中的默认选择依据是什么。
  • FRER 与 802.1Q 预约机制一起使用时，每个 Member Stream 的带宽、缓存和延迟预算如何系统计算。
  • Relay proxy 部署中，哪些封装转换最容易造成互操作问题。
  • Autoconfiguration 在只使用 R-TAG 的网络里能简化到什么程度。
  • 在存在多级恢复点时，如何判断哪个节点应该执行 Individual recovery，哪个节点应该执行 Sequence recovery。

已拆出的概念页

关联页面

关系图谱

反向链接