Internet Engineering Task Force (IETF) V. Roca
Request for Comments: 6865 INRIA
Category: Standards Track M. Cunche
ISSN: 2070-1721 INSA-Lyon/INRIA
J. Lacan
ISAE, Univ. of Toulouse
A. Bouabdallah
CDTA
K. Matsuzono
Keio University
February 2013
Internet Engineering Task Force (IETF) V. Roca
Request for Comments: 6865 INRIA
Category: Standards Track M. Cunche
ISSN: 2070-1721 INSA-Lyon/INRIA
J. Lacan
ISAE, Univ. of Toulouse
A. Bouabdallah
CDTA
K. Matsuzono
Keio University
February 2013
Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME
FEC帧的简单Reed-Solomon前向纠错（FEC）方案
Abstract
摘要
This document describes a fully-specified simple Forward Error Correction (FEC) scheme for Reed-Solomon codes over the finite field (also known as the Galois Field) GF(2^^m), with 2 <= m <= 16, that can be used to protect arbitrary media streams along the lines defined by FECFRAME. The Reed-Solomon codes considered have attractive properties, since they offer optimal protection against packet erasures and the source symbols are part of the encoding symbols, which can greatly simplify decoding. However, the price to pay is a limit on the maximum source block size, on the maximum number of encoding symbols, and a computational complexity higher than that of the Low-Density Parity Check (LDPC) codes, for instance.
本文档描述了有限域（也称为伽罗瓦域）GF（2^^m）上的Reed-Solomon码的一种完全指定的简单前向纠错（FEC）方案，该方案具有2<=m<=16，可用于沿FECFRAME定义的线路保护任意媒体流。所考虑的Reed-Solomon码具有吸引人的特性，因为它们提供了针对分组擦除的最佳保护，并且源符号是编码符号的一部分，这可以大大简化解码。然而，付出的代价是对最大源块大小、编码符号的最大数量的限制，以及比低密度奇偶校验（LDPC）码更高的计算复杂度。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6865.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6865.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Definitions Notations and Abbreviations . . . . . . . . . . . 5
3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 8
4. Common Procedures Related to the ADU Block and Source
Block Creation . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Restrictions . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. ADU Block Creation . . . . . . . . . . . . . . . . . . . . 9
4.3. Source Block Creation . . . . . . . . . . . . . . . . . . 10
5. Simple Reed-Solomon FEC Scheme over GF(2^^m) for Arbitrary
ADU Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Formats and Codes . . . . . . . . . . . . . . . . . . . . 12
5.1.1. FEC Framework Configuration Information . . . . . . . 12
5.1.2. Explicit Source FEC Payload ID . . . . . . . . . . . . 14
5.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 15
5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3. FEC Code Specification . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6.1. Attacks Against the Data Flow . . . . . . . . . . . . . . 17
6.1.1. Access to Confidential Content . . . . . . . . . . . . 17
6.1.2. Content Corruption . . . . . . . . . . . . . . . . . . 18
6.2. Attacks Against the FEC Parameters . . . . . . . . . . . . 18
6.3. When Several Source Flows Are to Be Protected Together . . 19
6.4. Baseline Secure FECFRAME Operation . . . . . . . . . . . . 19
7. Operations and Management Considerations . . . . . . . . . . . 19
7.1. Operational Recommendations: Finite Field Size (m) . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Definitions Notations and Abbreviations . . . . . . . . . . . 5
3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 8
4. Common Procedures Related to the ADU Block and Source
Block Creation . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Restrictions . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. ADU Block Creation . . . . . . . . . . . . . . . . . . . . 9
4.3. Source Block Creation . . . . . . . . . . . . . . . . . . 10
5. Simple Reed-Solomon FEC Scheme over GF(2^^m) for Arbitrary
ADU Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Formats and Codes . . . . . . . . . . . . . . . . . . . . 12
5.1.1. FEC Framework Configuration Information . . . . . . . 12
5.1.2. Explicit Source FEC Payload ID . . . . . . . . . . . . 14
5.1.3. Repair FEC Payload ID . . . . . . . . . . . . . . . . 15
5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3. FEC Code Specification . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6.1. Attacks Against the Data Flow . . . . . . . . . . . . . . 17
6.1.1. Access to Confidential Content . . . . . . . . . . . . 17
6.1.2. Content Corruption . . . . . . . . . . . . . . . . . . 18
6.2. Attacks Against the FEC Parameters . . . . . . . . . . . . 18
6.3. When Several Source Flows Are to Be Protected Together . . 19
6.4. Baseline Secure FECFRAME Operation . . . . . . . . . . . . 19
7. Operations and Management Considerations . . . . . . . . . . . 19
7.1. Operational Recommendations: Finite Field Size (m) . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . . 21
The use of the Forward Error Correction (FEC) codes is a classic solution to improve the reliability of unicast, multicast, and broadcast Content Delivery Protocols (CDP) and applications. [RFC6363] describes a generic framework to use FEC schemes with media delivery applications, and for instance with real-time streaming media applications based on the Real-time Transport Protocol (RTP). Similarly, [RFC5052] describes a generic framework to use FEC schemes with object delivery applications (where the objects are files, for example) based on the Asynchronous Layered Coding (ALC) [RFC5775] and NACK-Oriented Reliable Multicast (NORM) [RFC5740] transport protocols.
使用前向纠错（FEC）码是提高单播、多播和广播内容交付协议（CDP）和应用程序可靠性的经典解决方案。[RFC6363]描述了将FEC方案用于媒体交付应用程序的通用框架，例如用于基于实时传输协议（RTP）的实时流媒体应用程序。类似地，[RFC5052]描述了基于异步分层编码（ALC）[RFC5775]和面向NACK的可靠多播（NORM）[RFC5740]传输协议将FEC方案用于对象交付应用程序（例如，对象是文件）的通用框架。
More specifically, the [RFC5053] and [RFC5170] FEC schemes introduce erasure codes based on sparse parity-check matrices for object delivery protocols like ALC and NORM. These codes are efficient in terms of processing but not optimal in terms of erasure recovery capabilities when dealing with "small" objects.
更具体地说，[RFC5053]和[RFC5170]FEC方案为对象传递协议（如ALC和NORM）引入了基于稀疏奇偶校验矩阵的擦除码。在处理“小”对象时，这些代码在处理方面是有效的，但在擦除恢复能力方面不是最佳的。
The Reed-Solomon FEC codes described in this document belong to the class of Maximum Distance Separable (MDS) codes that are optimal in terms of erasure recovery capability. It means that a receiver can recover the k source symbols from any set of exactly k encoding symbols. These codes are also systematic codes, which means that the k source symbols are part of the encoding symbols. However, they are limited in terms of maximum source block size and number of encoding symbols. Since the real-time constraints of media delivery applications usually limit the maximum source block size, this is not considered to be a major issue in the context of FECFRAME for many (but not necessarily all) use cases. Additionally, if the encoding/ decoding complexity is higher with Reed-Solomon codes than it is with [RFC5053] or [RFC5170] codes, it remains reasonable for most use cases, even in case of a software codec.
本文档中描述的Reed-Solomon FEC码属于最大距离可分离（MDS）码，在擦除恢复能力方面是最佳的。这意味着接收器可以从任何一组精确的k个编码符号中恢复k个源符号。这些代码也是系统代码，这意味着k个源符号是编码符号的一部分。然而，它们在最大源块大小和编码符号数量方面受到限制。由于媒体交付应用程序的实时约束通常会限制最大源块大小，因此对于许多（但不一定是所有）用例，这在FECFRAME上下文中不是一个主要问题。此外，如果里德-所罗门码的编码/解码复杂度高于[RFC5053]或[RFC5170]码，则即使在软件编解码器的情况下，对于大多数使用情况也是合理的。
Many applications dealing with reliable content transmission or content storage already rely on packet-based Reed-Solomon erasure recovery codes. In particular, many of them use the Reed-Solomon codec of Luigi Rizzo [RS-codec] [Rizzo97]. The goal of the present document is to specify a simple Reed-Solomon scheme that is compatible with this codec.
许多处理可靠内容传输或内容存储的应用程序已经依赖于基于分组的Reed-Solomon擦除恢复码。特别是，他们中的许多人使用Luigi Rizzo[RS codec][Rizzo97]的Reed Solomon编解码器。本文档的目标是指定一个与此编解码器兼容的简单Reed-Solomon方案。
More specifically, [RFC5510] introduced such Reed-Solomon codes and several associated FEC schemes that are compatible with the [RFC5052] framework. The present document inherits from Section 8 of [RFC5510], "Reed-Solomon Codes Specification for the Erasure
更具体地说，[RFC5510]引入了此类里德-所罗门码以及与[RFC5052]框架兼容的若干相关FEC方案。本文件继承了[RFC5510]第8节“Reed-Solomon代码擦除规范”
Channel", the specifications of the core Reed-Solomon codes based on Vandermonde matrices and specifies a simple FEC scheme that is compatible with FECFRAME [RFC6363]:
信道”，核心Reed-Solomon码的规范基于Vandermonde矩阵，并规定了与FECFRAME[RFC6363]兼容的简单FEC方案：
The Fully-Specified FEC Scheme with FEC Encoding ID 8 specifies a simple way of using of Reed-Solomon codes over GF(2^^m), with 2 <= m <= 16, in order to protect arbitrary Application Data Unit (ADU) flows.
具有FEC编码ID 8的完全指定的FEC方案指定了一种简单的方法来使用GF（2^^m）上的Reed-Solomon码，其中2<=m<=16，以保护任意应用数据单元（ADU）流。
Therefore, Sections 4, 5, 6, and 7 of [RFC5510] that define [RFC5052]-specific Formats and Procedures are not considered and are replaced by FECFRAME-specific Formats and Procedures.
因此，不考虑[RFC5510]中定义[RFC5052]特定格式和过程的第4、5、6和7节，并将其替换为FECFRAME特定格式和过程。
For instance, with this scheme, a set of Application Data Units (ADUs) coming from one or several media delivery applications (e.g., a set of RTP packets), are grouped in an ADU block and FEC encoded as a whole. With Reed-Solomon codes over GF(2^^8), there is a strict limit over the number of ADUs that can be protected together, since the number of encoded symbols, n, must be inferior or equal to 255. This constraint is relaxed when using a higher finite field size (m > 8), at the price of an increased computational complexity.
例如，使用该方案，来自一个或多个媒体递送应用（例如，一组RTP分组）的一组应用数据单元（ADU）被分组在ADU块中，并且FEC作为一个整体进行编码。对于GF（2^^8）上的Reed-Solomon码，可以一起保护的ADU数量有严格限制，因为编码符号的数量n必须小于或等于255。当使用更大的有限域大小（m>8）时，该约束会得到放松，但代价是计算复杂度增加。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This document uses the following terms and definitions. Some of these terms and definitions are FEC scheme specific and are in line with [RFC5052]:
本文件使用以下术语和定义。其中一些术语和定义是FEC方案特定的，符合[RFC5052]：
Source symbol: unit of data used during the encoding process. In this specification, there is always one source symbol per ADU.
源符号：编码过程中使用的数据单位。在本规范中，每个ADU始终有一个源符号。
Encoding symbol: unit of data generated by the encoding process. With systematic codes, source symbols are part of the encoding symbols.
编码符号：编码过程产生的数据单位。对于系统代码，源符号是编码符号的一部分。
Repair symbol: encoding symbol that is not a source symbol.
修复符号：编码非源符号的符号。
Code rate: the k/n ratio, i.e., the ratio between the number of source symbols and the number of encoding symbols. By definition, the code rate is such that: 0 < code rate <= 1. A code rate close to 1 indicates that a small number of repair symbols have been produced during the encoding process.
码率：k/n比，即源符号数与编码符号数之比。根据定义，代码速率为：0<代码速率<=1。接近1的码率表示在编码过程中产生了少量修复符号。
Systematic code: FEC code in which the source symbols are part of the encoding symbols. The Reed-Solomon codes introduced in this document are systematic.
系统代码：FEC代码，其中源符号是编码符号的一部分。本文件中介绍的Reed-Solomon代码是系统的。
Source Block: a block of k source symbols that are considered together for the encoding.
源代码块：为编码而考虑在一起的k个源代码块。
Packet erasure channel: a communication path where packets are either dropped (e.g., by a congested router, or because the number of transmission errors exceeds the correction capabilities of the physical layer codes) or received. When a packet is received, it is assumed that this packet is not corrupted.
数据包擦除信道：数据包被丢弃（例如，被拥塞的路由器丢弃，或者因为传输错误的数量超过了物理层代码的纠正能力）或被接收的通信路径。当接收到数据包时，假定该数据包未损坏。
Some of these terms and definitions are FECFRAME specific and are in line with [RFC6363]:
其中一些术语和定义是特定于框架的，符合[RFC6363]：
Application Data Unit (ADU): The unit of source data provided as payload to the transport layer. Depending on the use case, an ADU may use an RTP encapsulation.
应用数据单元（ADU）：作为有效负载提供给传输层的源数据单元。根据用例，ADU可以使用RTP封装。
(Source) ADU Flow: A sequence of ADUs associated with a transport-layer flow identifier (such as the standard 5-tuple {Source IP address, source port, destination IP address, destination port, transport protocol}). Depending on the use case, several ADU flows may be protected together by FECFRAME.
（源）ADU流：与传输层流标识符（例如标准5元组{源IP地址、源端口、目标IP地址、目标端口、传输协议}）关联的ADU序列。根据使用情况，多个ADU流可以通过FECFRAME一起保护。
ADU Block: a set of ADUs that are considered together by the FECFRAME instance for the purpose of the FEC scheme. Along with the flow ID (F[]), length (L[]), and padding (Pad[]) fields, they form the set of source symbols over which FEC encoding will be performed.
ADU块：FEC帧实例为了FEC方案的目的而考虑在一起的一组ADU。与流ID（F[]、长度（L[]）和padding（Pad[]）字段一起，它们构成了将在其上执行FEC编码的源符号集。
ADU Information (ADUI): a unit of data constituted by the ADU and the associated Flow ID, Length and Padding fields (Section 4.3). This is the unit of data that is used as source symbol.
ADU信息（ADUI）：由ADU和相关流ID、长度和填充字段组成的数据单位（第4.3节）。这是用作源符号的数据单位。
FEC Framework Configuration Information (FFCI): Information that controls the operation of FECFRAME. The FFCI enables the synchronization of the FECFRAME sender and receiver instances.
FEC框架配置信息（FFCI）：控制FEC框架操作的信息。FFCI支持帧发送方和接收方实例的同步。
FEC Source Packet: At a sender (respectively, at a receiver) a payload submitted to (respectively, received from) the transport protocol containing an ADU along with an Explicit Source FEC Payload ID (that must be present in the FEC scheme defined by the present document, see Section 5.1.2).
FEC源数据包：在发送方（分别在接收方），提交给（分别从）包含ADU的传输协议的有效载荷以及明确的源FEC有效载荷ID（必须存在于本文件定义的FEC方案中，见第5.1.2节）。
FEC Repair Packet: At a sender (respectively, at a receiver) a payload submitted to (respectively, received from) the transport protocol containing one repair symbol along with a Repair FEC Payload ID and possibly an RTP header.
FEC修复包：在发送方（分别在接收方）提交（分别从）传输协议的有效载荷，包含一个修复符号以及修复FEC有效载荷ID，可能还有一个RTP报头。
The above terminology is illustrated in Figure 1 (sender's point of view):
上述术语如图1所示（发送者的观点）：
+----------------------+
| Application |
+----------------------+
|
| (1) Application Data Units (ADUs)
|
v
+----------------------+ +----------------+
| FECFRAME | | |
| |-------------------------->| FEC Scheme |
|(2) Construct source |(3) Source Block | |
| blocks | |(4) FEC Encoding|
|(6) Construct FEC |<--------------------------| |
| source and repair | | |
| packets |(5) Explicit Source FEC | |
+----------------------+ Payload IDs +----------------+
| Repair FEC Payload IDs
| Repair symbols
|
|(7) FEC source and repair packets
v
+----------------------+
| Transport Layer |
| (e.g., UDP) |
+----------------------+
+----------------------+
| Application |
+----------------------+
|
| (1) Application Data Units (ADUs)
|
v
+----------------------+ +----------------+
| FECFRAME | | |
| |-------------------------->| FEC Scheme |
|(2) Construct source |(3) Source Block | |
| blocks | |(4) FEC Encoding|
|(6) Construct FEC |<--------------------------| |
| source and repair | | |
| packets |(5) Explicit Source FEC | |
+----------------------+ Payload IDs +----------------+
| Repair FEC Payload IDs
| Repair symbols
|
|(7) FEC source and repair packets
v
+----------------------+
| Transport Layer |
| (e.g., UDP) |
+----------------------+
Figure 1: Terminology used in this document (sender).
图1：本文件中使用的术语（发件人）。
This document uses the following notations. Some of them are FEC scheme specific.
本文件使用以下符号。其中一些是FEC方案特定的。
k denotes the number of source symbols in a source block.
k表示源块中源符号的数量。
max_k denotes the maximum number of source symbols for any source block.
max_k表示任何源块的最大源符号数。
n denotes the number of encoding symbols generated for a source block.
n表示为源块生成的编码符号数。
E denotes the encoding symbol length in bytes.
E表示编码符号长度（以字节为单位）。
GF(q) denotes a finite field (also known as the Galois Field) with q elements. We assume that q = 2^^m in this document.
GF（q）表示具有q元素的有限域（也称为伽罗瓦域）。在本文件中，我们假设q=2^^m。
m defines the length of the elements in the finite field, in bits. In this document, m is such that 2 <= m <= 16.
m定义有限域中元素的长度，单位为位。在本文件中，m等于2<=m<=16。
q defines the number of elements in the finite field. We have: q = 2^^m in this specification.
q定义有限域中的元素数。本规范中有：q=2^^m。
CR denotes the "code rate", i.e., the k/n ratio.
CR表示“码速率”，即k/n比。
a^^b denotes a raised to the power b.
a^^b表示a升到b的幂。
Some of them are FECFRAME specific:
其中一些是特定于帧的：
B denotes the number of ADUs per ADU block.
B表示每个ADU块的ADU数量。
max_B denotes the maximum number of ADUs for any ADU block.
max_B表示任何ADU块的最大ADU数量。
This document uses the following abbreviations:
本文件使用以下缩写：
ADU stands for Application Data Unit.
ADU代表应用程序数据单元。
ADUI stands for Application Data Unit Information.
ADUI代表应用程序数据单元信息。
ESI stands for Encoding Symbol ID.
ESI代表编码符号ID。
FEC stands for Forward Error (or Erasure) Correction code.
FEC代表前向纠错（或擦除）码。
FFCI stands for FEC Framework Configuration Information.
FFCI代表FEC框架配置信息。
FSSI stands for FEC Scheme-Specific Information.
FSSI代表FEC方案特定信息。
MDS stands for Maximum Distance Separable code.
MDS代表最大距离可分离代码。
SBN stands for Source Block Number.
SBN代表源块编号。
SDP stands for Session Description Protocol.
SDP代表会话描述协议。
This section introduces the procedures that are used during the ADU block and the related source block creation for the FEC scheme considered.
本节介绍ADU块期间使用的程序以及所考虑的FEC方案的相关源块创建。
This specification has the following restrictions:
本规范有以下限制：
o there MUST be exactly one source symbol per ADUI, and therefore per ADU;
o 每个ADUI必须有一个源符号，因此每个ADU必须有一个源符号；
o there MUST be exactly one repair symbol per FEC Repair Packet;
o 每个FEC修复包必须只有一个修复符号；
o there MUST be exactly one source block per ADU block.
o 每个ADU块必须只有一个源块。
Two kinds of limitations exist that impact the ADU block creation:
存在两种影响ADU块创建的限制：
o at the FEC Scheme level: the finite field size (m parameter) directly impacts the maximum source block size and the maximum number of encoding symbols;
o 在FEC方案级别：有限字段大小（m参数）直接影响最大源块大小和最大编码符号数；
o at the FECFRAME instance level: the target use case can have real-time constraints that can/will define a maximum ADU block size.
o 在FECFRAME实例级别：目标用例可以具有实时约束，这些约束可以/将定义最大ADU块大小。
Note that terms "maximum source block size" and "maximum ADU block size" depend on the point of view that is adopted (FEC Scheme versus FECFRAME instance). However, in this document, both refer to the same value since Section 4.1 requires there is exactly one source symbol per ADU. We now detail each of these aspects.
注意，术语“最大源块大小”和“最大ADU块大小”取决于所采用的观点（FEC方案与FEC帧实例）。然而，在本文件中，两者均指相同的值，因为第4.1节要求每个ADU只有一个源符号。我们现在详细介绍这些方面。
The finite field size parameter m defines the number of non-zero elements in this field, which is equal to: q - 1 = 2^^m - 1. This q - 1 value is also the theoretical maximum number of encoding symbols that can be produced for a source block. For instance, when m = 8 (default) there is a maximum of 2^^8 - 1 = 255 encoding symbols. So: k < n <= 255. Given the target FEC code rate (e.g., provided by the end-user or upper application when starting the FECFRAME instance, and taking into account the known or estimated packet loss rate), the sender calculates:
有限字段大小参数m定义此字段中非零元素的数量，等于：q-1=2^^m-1。该q-1值也是源块可以产生的理论最大编码符号数。例如，当m=8（默认值）时，最多有2^^8-1=255个编码符号。所以：k<n<=255。给定目标FEC码速率（例如，在启动FECFRAME实例时由最终用户或上层应用程序提供，并考虑已知或估计的分组丢失率），发送方计算：
max_k = floor((2^^m - 1) * CR)
max_k = floor((2^^m - 1) * CR)
This max_k value leaves enough room for the sender to produce the desired number of repair symbols. Since there is one source symbol per ADU, max_k is also an upper bound to the maximum number of ADUs per ADU block.
该max_k值为发送方留出足够的空间来生成所需数量的修复符号。由于每个ADU有一个源符号，因此max_k也是每个ADU块的最大ADU数的上限。
The source ADU flows can have real-time constraints. When there are multiple flows, with different real-time constraints, let us consider the most stringent constraints (see [RFC6363], Section 10.2, item 6 for recommendations when several flows are globally protected). In that case, the maximum number of ADUs of an ADU block must not exceed a certain threshold since it directly impacts the decoding delay. The larger the ADU block size, the longer a decoder may have to wait until it has received a sufficient number of encoding symbols for decoding to succeed, and therefore the larger the decoding delay. When the target use case is known, these real-time constraints result in an upper bound to the ADU block size, max_rt.
源ADU流可能具有实时约束。当有多个流，具有不同的实时约束时，让我们考虑最严格的约束（参见[RCF6363]，第10.2节，项目6，当几个流被全局保护）时的建议。在这种情况下，ADU块的最大ADU数量不得超过某个阈值，因为它直接影响解码延迟。ADU块大小越大，解码器可能必须等待的时间越长，直到接收到足够数量的编码符号才能成功解码，因此解码延迟越大。当目标用例已知时，这些实时约束会导致ADU块大小的上限max\u rt。
For instance, if the use case specifies a maximum decoding latency l, and if each source ADU covers a duration d of a continuous media (we assume here the simple case of a constant bit-rate ADU flow), then the ADU block size must not exceed:
例如，如果用例指定了最大解码延迟l，并且如果每个源ADU覆盖连续媒体的持续时间d（我们在此假设恒定比特率ADU流的简单情况），则ADU块大小不得超过：
max_rt = floor(l / d)
max_rt = floor(l / d)
After encoding, this block will produce a set of at most n = max_rt / CR encoding symbols. These n encoding symbols will have to be sent at a rate of n / l packets per second. For instance, with d = 10 ms, l = 1 s, max_rt = 100 ADUs.
编码后，该块将产生一组最多n=max\u rt/CR的编码符号。这些n个编码符号必须以每秒n/l个数据包的速率发送。例如，d=10毫秒，l=1秒，最大值=100阿杜。
If we take into account all these constraints, we find:
如果我们考虑所有这些约束，我们会发现：
max_B = min(max_k, max_rt)
最大值B=最小值（最大值k，最大值rt）
This max_B parameter is an upper bound to the number of ADUs that can constitute an ADU block.
该max_B参数是可构成ADU块的ADU数量的上限。
In their most general form, FECFRAME and the Reed-Solomon FEC scheme are meant to protect a set of independent flows. Since the flows have no relationship to one another, the ADU size of each flow can potentially vary significantly. Even in the special case of a single flow, the ADU sizes can largely vary (e.g., the various frames of a "Group of Pictures" (GOP) of an H.264 flow will have different sizes). This diversity must be addressed since the Reed-Solomon FEC scheme requires a constant encoding symbol size (E parameter) per
在最一般的形式中，FECFRAME和Reed-Solomon FEC方案旨在保护一组独立的流。由于流量彼此之间没有关系，因此每个流量的ADU大小可能会发生显著变化。即使在单个流的特殊情况下，ADU大小也可以大幅度变化（例如，H.264流的“图片组”（GOP）的各种帧将具有不同的大小）。必须解决这种多样性，因为Reed-Solomon FEC方案要求每个用户具有恒定的编码符号大小（E参数）
source block. Since this specification requires that there is only one source symbol per ADU, E must be large enough to contain all the ADUs of an ADU block along with their prepended 3 bytes (see below).
源块。由于本规范要求每个ADU只有一个源符号，因此E必须足够大，以包含ADU块的所有ADU及其前置3字节（见下文）。
In situations where E is determined per source block (default, specified by the FFCI/FSSI with S = 0, Section 5.1.1.2), E is equal to the size of the largest ADU of this source block plus 3 (for the prepended 3 bytes; see below). In this case, upon receiving the first FEC Repair Packet for this source block, since this packet MUST contain a single repair symbol (Section 5.1.3), a receiver determines the E parameter used for this source block.
在每个源块确定E的情况下（默认情况下，由FFCI/FSSI指定，S=0，第5.1.1.2节），E等于该源块最大ADU的大小加上3（对于预加的3个字节；见下文）。在这种情况下，在接收到该源块的第一个FEC修复数据包时，由于该数据包必须包含单个修复符号（第5.1.3节），接收机确定用于该源块的E参数。
In situations where E is fixed (specified by the FFCI/FSSI with S = 1, Section 5.1.1.2), then E must be greater or equal to the size of the largest ADU of this source block plus 3 (for the prepended 3 bytes; see below). If this is not the case, an error is returned. How to handle this error is use-case specific (e.g., a larger E parameter may be communicated to the receivers in an updated FFCI message using an appropriate mechanism) and is not considered by this specification.
在E固定的情况下（由FFCI/FSSI规定，S=1，第5.1.1.2节），则E必须大于或等于该源块最大ADU的大小加上3（对于预加的3个字节；见下文）。如果不是这样，则返回一个错误。如何处理该错误是特定于用例的（例如，可以使用适当的机制在更新的FFCI消息中向接收机传送较大的e参数），本规范不考虑该错误。
The ADU block is always encoded as a single source block. There are a total of B <= max_B ADUs in this ADU block. For the ADU i, with 0 <= i <= B-1, 3 bytes are prepended (Figure 2):
ADU块始终编码为单个源块。该ADU区块中总共有B<=最大值B ADU。对于ADU i，如果0<=i<=B-1，则在前面加上3个字节（图2）：
o The first byte, F[i] (Flow ID), contains the integer identifier associated to the source ADU flow to which this ADU belongs to. It is assumed that a single byte is sufficient, or said differently, that no more than 256 flows will be protected by a single instance of FECFRAME.
o 第一个字节F[i]（流ID）包含与此ADU所属的源ADU流关联的整数标识符。假设单个字节就足够了，或者换言之，FECFRAME的单个实例将保护不超过256个流。
o The following 2 bytes, L[i] (Length), contain the length of this ADU, in network byte order (i.e., big endian). This length is for the ADU itself and does not include the F[i], L[i], or Pad[i] fields.
o 以下2个字节L[i]（长度）包含此ADU的长度，按网络字节顺序排列（即大端字节）。该长度用于ADU本身，不包括F[i]、L[i]或Pad[i]字段。
Then zero padding is added to ADU i (if needed), in field Pad[i], for alignment purposes up to a size of exactly E bytes. The data unit resulting from the ADU i and the F[i], L[i], and Pad[i] fields, is called ADU Information (or ADUI). Each ADUI contributes to exactly one source symbol of the source block.
然后，在字段Pad[i]中将零填充添加到ADU i（如果需要），以便对齐，大小精确到E字节。由ADU i和F[i]、L[i]和Pad[i]字段产生的数据单元称为ADU信息（或ADUI）。每个ADUI只贡献源块的一个源符号。
Encoding Symbol Length (E)
< ----------------------------------------------------------------- >
+----+--------+-----------------------+-----------------------------+
|F[0]| L[0] | ADU[0] | Pad[0] |
+----+--------+----------+------------+-----------------------------+
|F[1]| L[1] | ADU[1] | Pad[1] |
+----+--------+----------+------------------------------------------+
|F[2]| L[2] | ADU[2] |
+----+--------+------+----------------------------------------------+
|F[3]| L[3] |ADU[3]| Pad[3] |
+----+--------+------+----------------------------------------------+
\_________________________________ ________________________________/
\/
simple FEC encoding
Encoding Symbol Length (E)
< ----------------------------------------------------------------- >
+----+--------+-----------------------+-----------------------------+
|F[0]| L[0] | ADU[0] | Pad[0] |
+----+--------+----------+------------+-----------------------------+
|F[1]| L[1] | ADU[1] | Pad[1] |
+----+--------+----------+------------------------------------------+
|F[2]| L[2] | ADU[2] |
+----+--------+------+----------------------------------------------+
|F[3]| L[3] |ADU[3]| Pad[3] |
+----+--------+------+----------------------------------------------+
\_________________________________ ________________________________/
\/
simple FEC encoding
+-------------------------------------------------------------------+
| Repair 4 |
+-------------------------------------------------------------------+
. .
. .
+-------------------------------------------------------------------+
| Repair 7 |
+-------------------------------------------------------------------+
+-------------------------------------------------------------------+
| Repair 4 |
+-------------------------------------------------------------------+
. .
. .
+-------------------------------------------------------------------+
| Repair 7 |
+-------------------------------------------------------------------+
Figure 2: Source block creation, for code rate 1/2 (equal number of source and repair symbols; 4 in this example), and S = 0.
图2：源代码块创建，代码速率为1/2（相同数量的源代码和修复符号；本例中为4），S=0。
Note that neither the initial 3 bytes nor the optional padding are sent over the network. However, they are considered during FEC encoding. It means that a receiver who lost a certain FEC source packet (e.g., the UDP datagram containing this FEC source packet) will be able to recover the ADUI if FEC decoding succeeds. Thanks to the initial 3 bytes, this receiver will get rid of the padding (if any) and identify the corresponding ADU flow.
请注意，初始3个字节和可选填充都不是通过网络发送的。但是，在FEC编码期间会考虑它们。这意味着，如果FEC解码成功，丢失某个FEC源数据包（例如，包含该FEC源数据包的UDP数据报）的接收器将能够恢复ADUI。由于最初的3个字节，此接收器将消除填充（如果有）并识别相应的ADU流。
This Fully-Specified FEC Scheme specifies the use of Reed-Solomon codes over GF(2^^m), with 2 <= m <= 16, with a simple FEC encoding for arbitrary packet flows.
这个完全指定的FEC方案指定在GF（2^^m）上使用Reed-Solomon码，其中2<=m<=16，并对任意分组流使用简单的FEC编码。
The FEC Framework Configuration Information (or FFCI) includes information that must be communicated between the sender and receiver(s) [RFC6363]. More specifically, it enables the
FEC框架配置信息（或FFCI）包括必须在发送方和接收方之间通信的信息[RFC6363]。更具体地说，它使
synchronization of the FECFRAME sender and receiver instances. It includes both mandatory elements and scheme-specific elements, as detailed below.
帧发送方和接收方实例的同步。它包括强制性要素和方案特定要素，详情如下。
o FEC Encoding ID: the value assigned to this Fully-Specified FEC scheme MUST be 8, as assigned by IANA (Section 8).
o FEC编码ID：分配给这个完全指定的FEC方案的值必须是IANA分配的8（第8节）。
When SDP is used to communicate the FFCI, this FEC Encoding ID MUST be carried in the 'encoding-id' parameter of the 'fec-repair-flow' attribute specified in RFC 6364 [RFC6364].
当SDP用于传递FFCI时，此FEC编码ID必须包含在RFC 6364[RFC6364]中指定的“FEC修复流”属性的“编码ID”参数中。
The FEC Scheme-Specific Information (FSSI) includes elements that are specific to the present FEC scheme. More precisely:
FEC方案特定信息（FSSI）包括特定于当前FEC方案的元素。更准确地说：
o Encoding Symbol Length (E): a non-negative integer, inferior to 2^^16, that indicates either the length of each encoding symbol in bytes ("strict" mode, i.e., if S = 1), or the maximum length of any encoding symbol (i.e., if S = 0).
o 编码符号长度（E）：一个非负整数，小于2^^16，表示每个编码符号的字节长度（“严格”模式，即，如果S=1），或任何编码符号的最大长度（即，如果S=0）。
o Strict (S) flag: when set to 1, this flag indicates that the E parameter is the actual encoding symbol length value for each block of the session (unless otherwise notified by an updated FFCI if this possibility is considered by the use case or CDP). When set to 0, this flag indicates that the E parameter is the maximum encoding symbol length value for each block of the session (unless otherwise notified by an updated FFCI if this possibility is considered by the use case or CDP).
o 严格（S）标志：当设置为1时，该标志表示E参数是会话每个块的实际编码符号长度值（除非更新的FFCI另有通知，如果用例或CDP考虑了这种可能性）。当设置为0时，该标志指示E参数是会话的每个块的最大编码符号长度值（除非更新的FFCI另有通知，如果用例或CDP考虑了这种可能性）。
o m parameter (m): an integer that defines the length of the elements in the finite field, in bits. We have: 2 <= m <= 16.
o m参数（m）：定义有限域中元素长度的整数，单位为位。我们有：2<=m<=16。
These elements are required both by the sender (Reed-Solomon encoder) and the receiver(s) (Reed-Solomon decoder).
发送方（里德-所罗门编码器）和接收方（里德-所罗门解码器）都需要这些元件。
When SDP is used to communicate the FFCI, this FEC scheme-specific information MUST be carried in the 'fssi' parameter of the 'fec-repair-flow' attribute, in textual representation as specified in RFC 6364 [RFC6364]. For instance:
当SDP用于传递FFCI时，该FEC方案特定信息必须以RFC 6364[RFC6364]中规定的文本表示形式，包含在“FEC修复流”属性的“fssi”参数中。例如：
a=fec-repair-flow: encoding-id=8; fssi=E:1400,S:0,m:8
a=fec-repair-flow: encoding-id=8; fssi=E:1400,S:0,m:8
If another mechanism requires the FSSI to be carried as an opaque octet string (for instance after a Base64 encoding), the encoding format consists of the following 3 octets of Figure 3:
如果另一种机制要求FSSI作为不透明的八位字节字符串携带（例如在Base64编码之后），则编码格式由图3中的以下3个八位字节组成：
o Encoding symbol length (E): 16-bit field.
o 编码符号长度（E）：16位字段。
o Strict (S) flag: 1-bit field.
o 严格（S）标志：1位字段。
o m parameter (m): 7-bit field.
o m参数（m）：7位字段。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol Length (E) |S| m |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol Length (E) |S| m |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: FSSI encoding format.
图3:FSSI编码格式。
A FEC source packet MUST contain an Explicit Source FEC Payload ID that is appended to the end of the packet as illustrated in Figure 4.
FEC源数据包必须包含一个附加到数据包末尾的显式源FEC有效负载ID，如图4所示。
+--------------------------------+
| IP Header |
+--------------------------------+
| Transport Header |
+--------------------------------+
| ADU |
+--------------------------------+
| Explicit Source FEC Payload ID |
+--------------------------------+
+--------------------------------+
| IP Header |
+--------------------------------+
| Transport Header |
+--------------------------------+
| ADU |
+--------------------------------+
| Explicit Source FEC Payload ID |
+--------------------------------+
Figure 4: Structure of a FEC Source Packet with the Explicit Source FEC Payload ID.
图4：具有显式源FEC有效负载ID的FEC源数据包的结构。
More precisely, the Explicit Source FEC Payload ID is composed of the Source Block Number, the Encoding Symbol ID, and the Source Block Length. The length of the first 2 fields depends on the m parameter (transmitted separately in the FFCI, Section 5.1.1.2):
更准确地说，显式源FEC有效负载ID由源块编号、编码符号ID和源块长度组成。前两个字段的长度取决于m参数（在FFCI第5.1.1.2节中单独传输）：
o Source Block Number (SBN) ((32-m)-bit field): this field identifies the source block to which this FEC source packet belongs.
o 源块编号（SBN）（（32-m）-位字段：此字段标识此FEC源数据包所属的源块。
o Encoding Symbol ID (ESI) (m-bit field): this field identifies the source symbol contained in this FEC source packet. This value is such that 0 <= ESI <= k - 1 for source symbols.
o 编码符号ID（ESI）（m位字段）：此字段标识此FEC源数据包中包含的源符号。对于源符号，该值为0<=ESI<=k-1。
o Source Block Length (k) (16-bit field): this field provides the number of source symbols for this source block, i.e., the k parameter. If 16 bits are too much when m <= 8, it is needed when 8 < m <= 16. Therefore, we provide a single common format regardless of m.
o 源块长度（k）（16位字段）：此字段提供此源块的源符号数，即k参数。如果m<=8时16位太多，则在8<m<=16时需要16位。因此，我们提供了一个单一的通用格式，与m无关。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Number (24 bits) | Enc. Symb. ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length (k) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Number (24 bits) | Enc. Symb. ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length (k) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Source FEC Payload ID encoding format for m = 8 (default).
图5:m=8的源FEC有效负载ID编码格式（默认值）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Nb (16 bits) | Enc. Symbol ID (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length (k) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Nb (16 bits) | Enc. Symbol ID (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length (k) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Source FEC Payload ID encoding format for m = 16.
图6:m=16的源FEC有效负载ID编码格式。
The format of the Source FEC Payload ID for m = 8 and m = 16 are illustrated in Figures 5 and 6, respectively.
图5和图6分别说明了m=8和m=16的源FEC有效负载ID的格式。
A FEC repair packet MUST contain a Repair FEC Payload ID that is prepended to the repair symbol(s) as illustrated in Figure 7. There MUST be a single repair symbol per FEC repair packet.
FEC修复数据包必须包含修复FEC有效负载ID，该ID在修复符号之前，如图7所示。每个FEC修复数据包必须有一个修复符号。
+--------------------------------+
| IP Header |
+--------------------------------+
| Transport Header |
+--------------------------------+
| Repair FEC Payload ID |
+--------------------------------+
| Repair Symbol |
+--------------------------------+
+--------------------------------+
| IP Header |
+--------------------------------+
| Transport Header |
+--------------------------------+
| Repair FEC Payload ID |
+--------------------------------+
| Repair Symbol |
+--------------------------------+
Figure 7: Structure of a FEC Repair Packet with the Repair FEC Payload ID.
图7：具有修复FEC有效负载ID的FEC修复数据包的结构。
More precisely, the Repair FEC Payload ID is composed of the Source Block Number, the Encoding Symbol ID, and the Source Block Length. The length of the first 2 fields depends on the m parameter (transmitted separately in the FFCI, Section 5.1.1.2):
更准确地说，修复FEC有效负载ID由源块编号、编码符号ID和源块长度组成。前两个字段的长度取决于m参数（在FFCI第5.1.1.2节中单独传输）：
o Source Block Number (SBN) ((32-m)-bit field): this field identifies the source block to which the FEC repair packet belongs.
o 源块编号（SBN）（（32-m）-位字段：该字段标识FEC修复数据包所属的源块。
o Encoding Symbol ID (ESI) (m-bit field): this field identifies the repair symbol contained in this FEC repair packet. This value is such that k <= ESI <= n - 1 for repair symbols.
o 编码符号ID（ESI）（m位字段）：此字段标识此FEC修复数据包中包含的修复符号。对于维修符号，该值为k<=ESI<=n-1。
o Source Block Length (k) (16-bit field): this field provides the number of source symbols for this source block, i.e., the k parameter. If 16 bits are too much when m <= 8, it is needed when 8 < m <= 16. Therefore, we provide a single common format regardless of m.
o 源块长度（k）（16位字段）：此字段提供此源块的源符号数，即k参数。如果m<=8时16位太多，则在8<m<=16时需要16位。因此，我们提供了一个单一的通用格式，与m无关。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Number (24 bits) | Enc. Symb. ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length (k) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Number (24 bits) | Enc. Symb. ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length (k) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Repair FEC Payload ID encoding format for m = 8 (default).
图8:m=8的修复FEC有效负载ID编码格式（默认）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Nb (16 bits) | Enc. Symbol ID (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length (k) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Nb (16 bits) | Enc. Symbol ID (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length (k) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Repair FEC Payload ID encoding format for m = 16.
图9:m=16的修复FEC有效负载ID编码格式。
The format of the Repair FEC Payload ID for m = 8 and m = 16 are illustrated in Figures 8 and 9, respectively.
图8和图9分别说明了m=8和m=16的修复FEC有效负载ID的格式。
The following procedures apply:
以下程序适用：
o The source block creation MUST follow the procedures specified in Section 4.3.
o 源块创建必须遵循第4.3节中规定的程序。
o The SBN value MUST start with value 0 for the first block of the ADU flow and MUST be incremented by 1 for each new source block. Wrapping to zero will happen for long sessions, after value 2^^(32-m) - 1.
o 对于ADU流的第一个块，SBN值必须以值0开始，对于每个新的源块，SBN值必须增加1。在值2^^（32-m）-1之后，长会话将换行为零。
o The ESI of encoding symbols MUST start with value 0 for the first symbol and MUST be managed sequentially. The first k values (0 <= ESI <= k - 1) identify source symbols, whereas the last n-k values (k <= ESI <= n - 1) identify repair symbols.
o 编码符号的ESI必须以第一个符号的值0开始，并且必须按顺序管理。前k个值（0<=ESI<=k-1）标识源符号，而最后n-k个值（k<=ESI<=n-1）标识修复符号。
o The FEC repair packet creation MUST follow the procedures specified in Section 5.1.3.
o FEC修复包的创建必须遵循第5.1.3节规定的程序。
The present document inherits from Section 8 of [RFC5510], "Reed-Solomon Codes Specification for the Erasure Channel", the specifications of the core Reed-Solomon codes based on Vandermonde matrices.
本文件继承了[RFC5510]第8节“擦除信道的里德所罗门码规范”，即基于范德蒙矩阵的核心里德所罗门码规范。
The FECFRAME document [RFC6363] provides a comprehensive analysis of security considerations applicable to FEC schemes. Therefore, the present section follows the security considerations section of [RFC6363] and only discusses topics that are specific to the use of Reed-Solomon codes.
FECFRAME文档[RFC6363]提供了适用于FEC方案的安全注意事项的综合分析。因此，本节遵循[RFC6363]的安全注意事项部分，仅讨论特定于使用Reed-Solomon代码的主题。
The Reed-Solomon FEC Scheme specified in this document does not change the recommendations of [RFC6363]. To summarize, if confidentiality is a concern, it is RECOMMENDED that one of the solutions mentioned in [RFC6363] is used with special considerations to the way this solution is applied (e.g., is encryption applied before or after FEC protection, within the end-system or in a middlebox) to the operational constraints (e.g., performing FEC decoding in a protected environment may be complicated or even impossible) and to the threat model.
本文件中规定的Reed-Solomon FEC方案不会改变[RFC6363]的建议。总之，如果涉及机密性，建议使用[RFC6363]中提到的解决方案之一，并特别考虑该解决方案应用于操作约束的方式（例如，在FEC保护之前或之后，在终端系统内或在中间盒中应用加密）（例如，在受保护的环境中执行FEC解码可能会很复杂，甚至不可能）并与威胁模型相关联。
The Reed-Solomon FEC Scheme specified in this document does not change the recommendations of [RFC6363]. To summarize, it is RECOMMENDED that one of the solutions mentioned in [RFC6363] is used on both the FEC Source and Repair Packets.
本文件中规定的Reed-Solomon FEC方案不会改变[RFC6363]的建议。总之，建议在FEC源和修复数据包上使用[RFC6363]中提到的解决方案之一。
The FEC Scheme specified in this document defines parameters that can be the basis of several attacks. More specifically, the following parameters of the FFCI may be modified by an attacker (Section 5.1.1.2):
本文档中指定的FEC方案定义了可作为多种攻击基础的参数。更具体地说，攻击者可以修改FFCI的以下参数（第5.1.1.2节）：
o FEC Encoding ID: changing this parameter leads the receiver to consider a different FEC Scheme, which enables an attacker to create a Denial of Service (DoS).
o FEC编码ID：改变这个参数导致接收器考虑不同的FEC方案，这使得攻击者能够创建拒绝服务（DoS）。
o Encoding symbol length (E): setting this E parameter to a value smaller than the valid one enables an attacker to create a DoS since the repair symbols and certain source symbols will be larger than E, which is an incoherency for the receiver. Setting this E parameter to a value larger than the valid one has similar impacts when S = 1 since the received repair symbol size will be smaller than expected. On the opposite, it will not lead to any incoherency when S = 0 since the actual symbol length value for the block is determined by the size of any received repair symbol, as long as this value is smaller than E. However, setting this E parameter to a larger value may have impacts on receivers that pre-allocate memory space in advance to store incoming symbols.
o 编码符号长度（E）：将此E参数设置为小于有效值的值可使攻击者创建DoS，因为修复符号和某些源符号将大于E，这对接收器来说是不一致的。当S=1时，将此E参数设置为大于有效值的值会产生类似的影响，因为收到的修复符号大小将小于预期值。相反，S=0时不会导致任何不一致，因为块的实际符号长度值由任何接收到的修复符号的大小决定，只要该值小于E。但是，将此E参数设置为较大的值可能会对预先分配内存空间以存储传入符号的接收器产生影响。
o Strict (S) flag: flipping this S flag from 0 to 1 (i.e., E is now considered as a strict value) enables an attacker to mislead the receiver if the actual symbol size varies over different source blocks. Flipping this S flag from 1 to 0 has no major consequences unless the receiver requires to have a fixed E value (e.g., because the receiver pre-allocates memory space).
o 严格（S）标志：如果实际符号大小在不同的源块上不同，则将此S标志从0翻转到1（即，e现在被视为严格值）会使攻击者误导接收器。将该S标志从1翻转到0不会产生重大后果，除非接收器要求具有固定的E值（例如，因为接收器预先分配内存空间）。
o m parameter: changing this parameter triggers a DoS since the receiver and sender will consider different codes, and the receiver will interpret the Explicit Source FEC Payload ID and Repair FEC Payload ID differently. Additionally, by increasing this m parameter to a larger value (typically m = 16 rather than 8, when both values are possible in the target use case) will create additional processing load at a receiver if decoding is attempted.
o M参数：改变此参数触发DOS，因为接收方和发送方将考虑不同的代码，并且接收方将不同地解释显式源FEC有效载荷ID和修复FEC有效载荷ID。此外，如果尝试解码，则通过将该m参数增加到更大的值（当两个值在目标用例中都可能时，通常m＝16而不是8），将在接收器处创建额外的处理负载。
It is therefore RECOMMENDED that security measures are taken to guarantee the FFCI integrity, as specified in [RFC6363]. How to achieve this depends on the way the FFCI is communicated from the sender to the receiver, which is not specified in this document.
因此，建议按照[RFC6363]中的规定，采取安全措施以保证FFCI的完整性。如何实现这一点取决于FFCI从发送方到接收方的通信方式，本文件未对此进行规定。
Similarly, attacks are possible against the Explicit Source FEC Payload ID and Repair FEC Payload ID: by modifying the Source Block Number (SBN), or the Encoding Symbol ID (ESI), or the Source Block Length (k), an attacker can easily corrupt the block identified by the SBN. Other consequences, that are use case and/or CDP dependent, may also happen. It is therefore RECOMMENDED that security measures are taken to guarantee the FEC Source and Repair Packets as stated in [RFC6363].
类似地，针对显式源FEC有效负载ID和修复FEC有效负载ID的攻击也是可能的：通过修改源块编号（SBN）、编码符号ID（ESI）或源块长度（k），攻击者可以轻易损坏SBN标识的块。还可能发生其他依赖于用例和/或CDP的后果。因此，建议采取安全措施，以保证FEC源和修复[RFC6363]中所述的数据包。
The Reed-Solomon FEC Scheme specified in this document does not change the recommendations of [RFC6363].
本文件中规定的Reed-Solomon FEC方案不会改变[RFC6363]的建议。
The Reed-Solomon FEC Scheme specified in this document does not change the recommendations of [RFC6363] concerning the use of the IPsec/ESP security protocol as a mandatory to implement (but not mandatory to use) security scheme. This is well suited to situations where the only insecure domain is the one over which FECFRAME operates.
本文件中规定的Reed-Solomon FEC方案不会改变[RFC6363]关于将IPsec/ESP安全协议作为强制实施（但非强制使用）安全方案的建议。这非常适合于唯一不安全的域是FECFRAME操作的域的情况。
The FECFRAME document [RFC6363] provides a comprehensive analysis of operations and management considerations applicable to FEC schemes. Therefore, the present section only discusses topics that are specific to the use of Reed-Solomon codes as specified in this document.
FEC框架文件[RFC6363]提供了适用于FEC方案的运营和管理考虑因素的综合分析。因此，本节仅讨论本文件中规定的特定于使用里德-所罗门代码的主题。
The present document requires that m, the length of the elements in the finite field in bits, is such that 2 <= m <= 16. However, all possibilities are not equally interesting from a practical point of view. It is expected that m = 8, the default value, will be mostly used since it offers the possibility to have small to medium sized source blocks and/or a significant number of repair symbols (i.e., k < n <= 255). Additionally, elements in the finite field are 8 bits long, which makes read/write memory operations aligned on bytes during encoding and decoding.
本文件要求有限域中元素的长度m（以位为单位）为2<=m<=16。然而，从实践的角度来看，并非所有的可能性都同样有趣。预计将主要使用默认值m=8，因为它提供了具有中小型源块和/或大量修复符号（即k<n<=255）的可能性。此外，有限域中的元素长度为8位，这使得在编码和解码期间读/写内存操作在字节上对齐。
An alternative when it is known that only very small source blocks will be used is m = 4 (i.e., k < n <= 15). Elements in the finite field are 4 bits long, so if 2 elements are accessed at a time, read/ write memory operations are aligned on bytes during encoding and decoding.
已知仅使用非常小的源块时的备选方案是m＝4（即，k＜n＜15）。有限域中的元素长度为4位，因此，如果一次访问2个元素，则在编码和解码期间，读/写内存操作将按字节对齐。
An alternative when very large source blocks are needed is m = 16 (i.e., k < n<= 65535). However, this choice has significant impact on the processing load. For instance, using pre-calculated tables to speed up operations over the finite field (as done with smaller finite fields) may require a prohibitive amount of memory to be used on embedded platforms. Alternative lightweight solutions (e.g., LDPC FEC [RFC5170]) may be preferred in situations where the processing load is an issue and the source block length is large enough [Matsuzono10].
当需要非常大的源块时，另一种选择是m=16（即k<n<=65535）。但是，此选择对处理负载有重大影响。例如，使用预先计算的表来加速有限域上的运算（如使用较小的有限域所做的），可能需要在嵌入式平台上使用大量的内存。在处理负载是一个问题且源块长度足够大的情况下，可优选替代的轻型解决方案（例如，LDPC FEC[RFC5170]）。
Since several values for the m parameter are possible, the use case SHOULD define which value or values need to be supported. In situations where this is not specified, the default m = 8 value MUST be used.
由于m参数可能有多个值，因此用例应该定义需要支持的一个或多个值。在未指定的情况下，必须使用默认的m=8值。
In any case, any compliant implementation MUST support at least the default m = 8 value.
在任何情况下，任何兼容的实现都必须至少支持默认的m=8值。
Values of FEC Encoding IDs are subject to IANA registration. [RFC6363] defines general guidelines on IANA considerations. In particular, it defines the "FEC Framework (FECFRAME) FEC Encoding IDs" subregistry of the "Reliable Multicast Transport (RMT) FEC Encoding IDs and FEC Instance IDs" registry, whose registration procedure is IETF Review.
FEC编码ID的值受IANA注册的约束。[RFC6363]定义了IANA考虑事项的一般指南。特别是，它定义了“可靠多播传输（RMT）FEC编码ID和FEC实例ID”注册表的“FEC框架（FEC框架）FEC编码ID”子区，其注册过程为IETF Review。
This document registers one value in the "FEC Framework (FECFRAME) FEC Encoding IDs" subregistry as follows:
本文件在“FEC框架（FEC框架）FEC编码ID”子区域中注册一个值，如下所示：
8 refers to the Simple Reed-Solomon [RFC5510] FEC Scheme over GF(2^^m) for Arbitrary Packet Flows.
8指用于任意分组流的GF（2^^m）上的简单Reed-Solomon[RFC5510]FEC方案。
The authors want to thank Hitoshi Asaeda and Ali Begen for their valuable comments.
作者要感谢浅田仁和阿里·贝根的宝贵评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5052]Watson，M.，Luby，M.，和L.Vicisano，“前向纠错（FEC）构建块”，RFC 5052，2007年8月。
[RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo, "Reed-Solomon Forward Error Correction (FEC) Schemes", RFC 5510, April 2009.
[RFC5510]Lacan，J.，Roca，V.，Peltotalo，J.，和S.Peltotalo，“里德-所罗门前向纠错（FEC）方案”，RFC 55102009年4月。
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, October 2011.
[RFC6363]Watson，M.，Begen，A.，和V.Roca，“前向纠错（FEC）框架”，RFC6363，2011年10月。
[RFC6364] Begen, A., "Session Description Protocol Elements for the Forward Error Correction (FEC) Framework", RFC 6364, October 2011.
[RFC6364]Begen，A.，“前向纠错（FEC）框架的会话描述协议元素”，RFC6364，2011年10月。
[Matsuzono10] Matsuzono, K., Detchart, J., Cunche, M., Roca, V., and H. Asaeda, "Performance Analysis of a High-Performance Real-Time Application with Several AL-FEC Schemes", 35th Annual IEEE Conference on Local Computer Networks (LCN 2010), October 2010.
[Matsuzono 10]Matsuzono，K.，Detchart，J.，Cunche，M.，Roca，V.，和H.Asaeda，“几种AL-FEC方案的高性能实时应用的性能分析”，第35届IEEE本地计算机网络年会（LCN 2010），2010年10月。
[RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, "Raptor Forward Error Correction Scheme for Object Delivery", RFC 5053, October 2007.
[RFC5053]Luby，M.，Shokrollahi，A.，Watson，M.，和T.Stockhammer，“用于对象交付的猛禽前向纠错方案”，RFC 5053，2007年10月。
[RFC5170] Roca, V., Neumann, C., and D. Furodet, "Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC) Schemes", RFC 5170, June 2008.
[RFC5170]Roca，V.，Neumann，C.，和D.Furodet，“低密度奇偶校验（LDPC）阶梯和三角形前向纠错（FEC）方案”，RFC 51702008年6月。
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", RFC 5740, November 2009.
[RFC5740]Adamson，B.，Bormann，C.，Handley，M.，和J.Macker，“面向NACK的可靠多播（NORM）传输协议”，RFC 57402009年11月。
[RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 5775, April 2010.
[RFC5775]Luby，M.，Watson，M.，和L.Vicisano，“异步分层编码（ALC）协议实例化”，RFC 5775，2010年4月。
[Rizzo97] Rizzo, L., "Effective Erasure Codes for Reliable Computer Communication Protocols", ACM SIGCOMM Computer Communication Review, Vol.27, No.2, pp.24-36, April 1997.
[Rizzo97]Rizzo，L.“用于可靠计算机通信协议的有效擦除代码”，《ACM SIGCOMM计算机通信评论》，第27卷，第2期，第24-36页，1997年4月。
[RS-codec] Rizzo, L., "Reed-Solomon FEC codec (C language)", original codec: http://info.iet.unipi.it/~luigi/vdm98/ vdm980702.tgz, improved codec: http://openfec.org/, July 1998.
[RS编解码器]Rizzo，L.，“Reed-Solomon FEC编解码器（C语言）”，原始编解码器：http://info.iet.unipi.it/~luigi/vdm98/vdm980702.tgz，改进的编解码器：http://openfec.org/，1998年7月。
Authors' Addresses
作者地址
Vincent Roca INRIA 655, av. de l'Europe Inovallee; Montbonnot ST ISMIER cedex 38334 France
Vincent Roca INRIA 655，av。欧洲伊诺瓦利；蒙博诺圣伊斯梅尔塞德斯38334法国
EMail: vincent.roca@inria.fr
URI: http://planete.inrialpes.fr/people/roca/
EMail: vincent.roca@inria.fr
URI: http://planete.inrialpes.fr/people/roca/
Mathieu Cunche INSA-Lyon/INRIA Laboratoire CITI 6 av. des Arts Villeurbanne cedex 69621 France
马蒂厄·坎切（Mathieu Cunche INSA Lyon/INRIA Laboratoroire CITI）6大道。法国维勒班尼艺术中心69621
EMail: mathieu.cunche@inria.fr
URI: http://mathieu.cunche.free.fr/
EMail: mathieu.cunche@inria.fr
URI: http://mathieu.cunche.free.fr/
Jerome Lacan ISAE, Univ. of Toulouse 10 av. Edouard Belin; BP 54032 Toulouse cedex 4 31055 France
Jerome Lacan ISAE，图卢兹大学10 av。爱德华·贝林；英国石油54032图卢兹cedex 4 31055法国
EMail: jerome.lacan@isae.fr
URI: http://personnel.isae.fr/jerome-lacan/
EMail: jerome.lacan@isae.fr
URI: http://personnel.isae.fr/jerome-lacan/
Amine Bouabdallah CDTA Center for Development of Advanced Technologies Cite 20 aout 1956, Baba Hassen Algiers Algeria
Amine Bouabdallah CDTA先进技术开发中心，1956年12月20日，巴巴哈森阿尔及尔，阿尔及利亚
EMail: abouabdallah@cdta.dz
EMail: abouabdallah@cdta.dz
Kazuhisa Matsuzono Keio University Graduate School of Media and Governance 5322 Endo Fujisawa, Kanagawa 252-8520 Japan
松野和久庆应大学媒体与治理研究生院5322藤泽内多，神奈川252-8520日本
EMail: kazuhisa@sfc.wide.ad.jp
EMail: kazuhisa@sfc.wide.ad.jp