Internet Engineering Task Force (IETF) V. Roca
Request for Comments: 6816 INRIA
Category: Standards Track M. Cunche
ISSN: 2070-1721 INSA-Lyon/INRIA
J. Lacan
ISAE, Univ. of Toulouse
December 2012
Internet Engineering Task Force (IETF) V. Roca
Request for Comments: 6816 INRIA
Category: Standards Track M. Cunche
ISSN: 2070-1721 INSA-Lyon/INRIA
J. Lacan
ISAE, Univ. of Toulouse
December 2012
Simple Low-Density Parity Check (LDPC) Staircase Forward Error Correction (FEC) Scheme for FECFRAME
用于FEC帧的简单低密度奇偶校验（LDPC）阶梯前向纠错（FEC）方案
Abstract
摘要
This document describes a fully specified simple Forward Error Correction (FEC) scheme for Low-Density Parity Check (LDPC) Staircase codes that can be used to protect media streams along the lines defined by FECFRAME. These codes have many interesting properties: they are systematic codes, they perform close to ideal codes in many use-cases, and they also feature very high encoding and decoding throughputs. LDPC-Staircase codes are therefore a good solution to protect a single high bitrate source flow or to protect globally several mid-rate flows within a single FECFRAME instance. They are also a good solution whenever the processing load of a software encoder or decoder must be kept to a minimum.
本文档描述了一种用于低密度奇偶校验（LDPC）阶梯码的完全指定的简单前向纠错（FEC）方案，该方案可用于沿FEC帧定义的线路保护媒体流。这些代码有许多有趣的特性：它们是系统代码，在许多用例中的性能接近理想代码，并且它们还具有非常高的编码和解码吞吐量。因此，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/rfc6816.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6816.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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 ..................................................8
4.1. Restrictions ...............................................9
4.2. ADU Block Creation .........................................9
4.3. Source Block Creation .....................................11
5. LDPC-Staircase FEC Scheme for Arbitrary ADU Flows ..............13
5.1. Formats and Codes .........................................13
5.1.1. FEC Framework Configuration Information ............13
5.1.2. Explicit Source FEC Payload ID .....................14
5.1.3. Repair FEC Payload ID ..............................16
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 FEC Framework Operation ...................19
7. Operations and Management Considerations .......................19
7.1. Operational Recommendations ...............................19
8. IANA Considerations ............................................21
9. Acknowledgments ................................................21
10. References ....................................................21
10.1. Normative References .....................................21
10.2. Informative References ...................................22
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 ..................................................8
4.1. Restrictions ...............................................9
4.2. ADU Block Creation .........................................9
4.3. Source Block Creation .....................................11
5. LDPC-Staircase FEC Scheme for Arbitrary ADU Flows ..............13
5.1. Formats and Codes .........................................13
5.1.1. FEC Framework Configuration Information ............13
5.1.2. Explicit Source FEC Payload ID .....................14
5.1.3. Repair FEC Payload ID ..............................16
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 FEC Framework Operation ...................19
7. Operations and Management Considerations .......................19
7.1. Operational Recommendations ...............................19
8. IANA Considerations ............................................21
9. Acknowledgments ................................................21
10. References ....................................................21
10.1. Normative References .....................................21
10.2. Informative References ...................................22
The use of Forward Error Correction (FEC) codes is a classic solution to improve the reliability of unicast, multicast, and broadcast Content Delivery Protocols (CDPs) and applications [RFC3453]. "Forward Error Correction (FEC) Framework" [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 RTP real-time protocol. Similarly, "Forward Error Correction (FEC) Building Block" [RFC5052] describes a generic framework to use FEC schemes with objects (e.g., files) delivery applications based on either the Asynchronous Layered Coding (ALC) [RFC5775] or the NACK-Oriented Reliable Multicast (NORM) [RFC5740] protocols.
使用前向纠错（FEC）码是提高单播、多播和广播内容交付协议（CDP）和应用程序可靠性的经典解决方案[RFC3453]。“前向纠错（FEC）框架”[RFC6363]描述了将FEC方案用于媒体交付应用程序的通用框架，例如，用于基于RTP实时协议的实时流媒体应用程序。类似地，“前向纠错（FEC）构建块”[RFC5052]描述了基于异步分层编码（ALC）[RFC5775]或面向NACK的可靠多播（NORM）[RFC5740]协议将FEC方案与对象（例如，文件）交付应用程序一起使用的通用框架。
More specifically, the [RFC5053] (Raptor) and [RFC5170] (LDPC-Staircase and LDPC-Triangle) FEC schemes introduce erasure codes based on sparse parity check matrices for object delivery protocols like ALC and NORM. Similarly, "Reed-Solomon Forward Error Correction (FEC) Schemes" [RFC5510] introduces Reed-Solomon codes based on Vandermonde matrices for the same object delivery protocols. All these codes are systematic codes, meaning that the k source symbols are part of the n encoding symbols. Additionally, the Reed-Solomon FEC codes belong to the class of Maximum Distance Separable (MDS) codes that are optimal in terms of erasure recovery capabilities. It means that a receiver can recover the k source symbols from any set of exactly k encoding symbols out of n. This is not the case with either Raptor or LDPC-Staircase codes, and these codes require a certain number of encoding symbols in excess to k. However, this number is small in practice when an appropriate decoding scheme is used at the receiver [Cunche08]. Another key difference is the high encoding/decoding complexity of Reed-Solomon codecs compared to Raptor or LDPC-Staircase codes. A difference of one or more orders of magnitude in terms of encoding/decoding speed exists between the Reed-Solomon and LDPC-Staircase software codecs [Cunche08][CunchePHD10]. Finally, Raptor and LDPC-Staircase codes are large block FEC codes, in the sense of [RFC3453], since they can efficiently deal with a large number of source symbols.
更具体地说，[RFC5053]（Raptor）和[RFC5170]（LDPC阶梯和LDPC三角形）FEC方案为对象传递协议（如ALC和NORM）引入基于稀疏奇偶校验矩阵的擦除码。类似地，“Reed-Solomon前向纠错（FEC）方案”[RFC5510]为相同的对象交付协议引入了基于Vandermonde矩阵的Reed-Solomon码。所有这些代码都是系统代码，这意味着k个源符号是n个编码符号的一部分。此外，Reed-Solomon FEC码属于最大距离可分离（MDS）码的类别，其在擦除恢复能力方面是最优的。这意味着接收机可以从n个编码符号中的任意一组恰好k个编码符号中恢复k个源符号。Raptor或LDPC阶梯码都不是这种情况，这些码需要一定数量的编码符号，超过k。然而，当在接收机处使用适当的解码方案时，该数字实际上很小[Cunche08]。另一个关键区别是，与Raptor或LDPC阶梯码相比，Reed-Solomon编解码器的编码/解码复杂度较高。里德-所罗门和LDPC楼梯软件编解码器[Cunche08][CunchePHD10]之间存在一个或多个数量级的编码/解码速度差异。最后，Raptor和LDPC阶梯码是[RFC3453]意义上的大分组FEC码，因为它们可以有效地处理大量源符号。
The present document focuses on LDPC-Staircase codes that belong to the well-known class of "Low Density Parity Check" codes. Because of their key features, these codes are a good solution in many situations, as detailed in Section 7.
本文档重点介绍属于众所周知的“低密度奇偶校验”码类的LDPC阶梯码。由于其关键特性，这些代码在许多情况下都是一个很好的解决方案，详见第7节。
This document inherits from [RFC5170], Section 6 "Full Specification of the LDPC-Staircase Scheme", the specifications of the core LDPC-Staircase codes, and from Section 5.7 "Pseudo-Random Number Generator", the specifications of the PRNG used by these codes. Therefore, this document specifies only the information specific to
本文件继承了[RFC5170]，第6节“LDPC楼梯方案的完整规范”，核心LDPC楼梯码规范，以及第5.7节“伪随机数发生器”，这些代码使用的PRNG规范。因此，本文件仅规定了特定于
the FECFRAME context and refers to [RFC5170] for the core specifications of the codes. To that purpose, the present document introduces:
FECFRAME上下文和参考[RFC5170]获取代码的核心规范。为此目的，本文件介绍：
o the Fully Specified FEC Scheme with FEC Encoding ID 7 that specifies a simple way of using LDPC-Staircase codes in order to protect arbitrary Application Data Unit (ADU) flows.
o 具有FEC编码ID 7的完全指定FEC方案，该方案指定了使用LDPC阶梯码的简单方法，以保护任意应用数据单元（ADU）流。
Therefore Sections 4 and 5 (except Section 5.7, see above) of [RFC5170], that define [RFC5052] specific Formats and Procedures, are not considered and are replaced by FECFRAME specific Formats and Procedures.
因此，不考虑[RFC5170]中定义[RFC5052]特定格式和程序的第4节和第5节（第5.7节除外，见上文），并由FECFRAME特定格式和程序代替。
Finally, publicly available reference implementations of these codes are available [LDPC-codec] [LDPC-codec-OpenFEC].
最后，这些代码的公开参考实现可用[LDPC codec][LDPC codec OpenFEC]。
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. Those in the list below 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 LDPC-Staircase codes introduced in this document are systematic.
系统代码：FEC代码，其中源符号是编码符号的一部分。本文介绍的LDPC阶梯码是系统的。
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.
数据包擦除信道：数据包被丢弃（例如，被拥塞的路由器丢弃，或者因为传输错误的数量超过了物理层代码的纠正能力）或被接收的通信路径。当接收到数据包时，假定该数据包未损坏。
The following 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 the FEC Framework. 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 optional Explicit Source FEC Payload ID.
FEC源数据包：在发送方（分别在接收方），提交给（分别从）包含ADU的传输协议的有效载荷以及可选的显式源FEC有效载荷ID。
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
+----------------------+ +----------------+
| FEC Framework | | |
| |-------------------------->| 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
+----------------------+ +----------------+
| FEC Framework | | |
| |-------------------------->| 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. Those in the list below 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表示编码符号长度（以字节为单位）。
CR denotes the "code rate", i.e., the k/n ratio.
CR表示“码速率”，即k/n比。
N1 denotes the target number of "1s" per column in the left side of the parity check matrix.
N1表示奇偶校验矩阵左侧每列“1”的目标数。
N1m3 denotes the value N1 - 3.
N1m3表示值N1-3。
G G denotes the number of encoding symbols per group, i.e., the number of symbols sent in the same packet.
G表示每组编码符号的数量，即在同一数据包中发送的符号数量。
a^^b denotes a raised to the power b.
a^^b表示a升到b的幂。
The following 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 Application Data Unit
ADU应用数据单元
ESI Encoding Symbol ID
ESI编码符号ID
FEC Forward Error (or Erasure) Correction
前向纠错（或擦除）
FFCI FEC Framework Configuration Information
FFCI FEC框架配置信息
FSSI FEC Scheme-Specific Information
FSSI FEC方案特定信息
LDPC Low-Density Parity Check
低密度奇偶校验
MDS Maximum Distance Separable
最大距离可分
PRNG Pseudo-Random Number Generator
伪随机数发生器
SDP Session Description Protocol
会话描述协议
This section introduces the procedures that are used during the ADU block and 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区块必须只有一个源区块；
o the use of the LDPC-Staircase scheme is such that there MUST be exactly one encoding symbol per group; i.e., G MUST be equal to 1 [RFC5170];
o LDPC阶梯方案的使用使得每个组必须恰好有一个编码符号；i、 例如，G必须等于1[RFC5170]；
Two kinds of limitations exist that impact the ADU block creation:
存在两种影响ADU块创建的限制：
o at the FEC scheme level: the FEC scheme and the FEC codec have limitations that define a maximum source block size;
o 在FEC方案级别：FEC方案和FEC编解码器具有定义最大源块大小的限制；
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 the use of the terminology "maximum source block size" and "maximum ADU block size" depends 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 be exactly one source symbol per ADU. We now detail each of these aspects.
注意，术语“最大源块大小”和“最大ADU块大小”的使用取决于所采用的观点（FEC方案与FEC帧实例）。然而，在本文件中，两者均指相同的值，因为第4.1节要求每个ADU只有一个源符号。我们现在详细介绍这些方面。
The maximum source block size in symbols, max_k, depends on several parameters: the code rate (CR) and the Encoding Symbol ID (ESI) field length in the Explicit Source/Repair FEC Payload ID (16 bits), as well as possible internal codec limitations. More specifically, max_k cannot be larger than the following values, derived from the ESI field size limitation, for a given code rate:
符号中的最大源块大小max_k取决于几个参数：显式源/修复FEC有效负载ID（16位）中的码率（CR）和编码符号ID（ESI）字段长度，以及可能的内部编解码器限制。更具体地说，对于给定的码率，max_k不能大于从ESI字段大小限制导出的以下值：
max1_k = 2^^(16 - ceil(Log2(1/CR)))
max1_k = 2^^(16 - ceil(Log2(1/CR)))
Some common max1_k values are:
一些常见的最大值为：
o CR == 1 (no repair symbol): max1_k = 2^^16 = 65536 symbols
o CR==1（无修复符号）：max1_k=2^^16=65536符号
o 1/2 <= CR < 1: max1_k = 2^^15 = 32,768 symbols
o 1/2 <= CR < 1: max1_k = 2^^15 = 32,768 symbols
o 1/4 <= CR < 1/2: max1_k = 2^^14 = 16,384 symbols
o 1/4 <= CR < 1/2: max1_k = 2^^14 = 16,384 symbols
Additionally, a codec can impose other limitations on the maximum source block size, for instance, because of a limited working memory size. This decision MUST be clarified at implementation time, when the target use-case is known. This results in a max2_k limitation.
此外，编解码器可以对最大源块大小施加其他限制，例如，因为工作内存大小有限。当目标用例已知时，必须在实现时澄清该决策。这会导致max2_k限制。
Then, max_k is given by:
然后，max_k由下式给出：
max_k = min(max1_k, max2_k)
max_k=min（max1_k，max2_k）
Note that this calculation is only required at the encoder (sender), since the actual k parameter (k <= max_k) is communicated to the decoder (receiver) through the Explicit Source/Repair FEC Payload ID.
注意，由于实际k参数（k<=max_k）通过显式源/修复FEC有效负载ID传送给解码器（接收器），因此仅在编码器（发送器）处需要此计算。
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 its most general form, FECFRAME and the LDPC-Staircase 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). This diversity must be addressed since the LDPC-Staircase FEC Scheme requires a constant encoding symbol size (E parameter) per source block. Since this specification requires that there be 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).
在其最一般的形式中，FEC帧和LDPC阶梯FEC方案旨在保护一组独立流。由于流量彼此之间没有关系，因此每个流量的ADU大小可能会发生显著变化。即使在单个流的特殊情况下，ADU大小也可以有很大的变化（例如，H.264流的一组图片（GOP）的各种帧）。由于LDPC阶梯FEC方案要求每个源块具有恒定的编码符号大小（E参数），因此必须解决这种分集问题。由于本规范要求每个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 three (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个字节，见下文）。在这种情况下，在接收到该源块的第一个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 three (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个字节，见下文）。如果不是这样，则返回一个错误。如何处理该错误是特定于用例的（例如，可以使用适当的机制在更新的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. 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 two 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 以下两个字节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流。
The FEC Framework Configuration Information (or FFCI) includes information that MUST be communicated between the sender and receiver(s). More specifically, it enables the synchronization of the FECFRAME sender and receiver instances. It includes both mandatory elements and scheme-specific elements, as detailed below.
FEC框架配置信息（或FFCI）包括必须在发送方和接收方之间通信的信息。更具体地说，它支持FECFRAME发送方和接收方实例的同步。它包括强制性要素和方案特定要素，详情如下。
o FEC Encoding ID: the value assigned to this fully specified FEC scheme MUST be 7, as assigned by IANA (Section 8).
o FEC编码ID：根据IANA（第8节）的分配，分配给这个完全指定的FEC方案的值必须为7。
When SDP is used to communicate the FFCI, this FEC Encoding ID is carried in the 'encoding-id' parameter.
当使用SDP与FFCI通信时，此FEC编码ID将携带在“Encoding ID”参数中。
The FEC Scheme-Specific Information (FSSI) includes elements that are specific to the present FEC scheme. More precisely:
FEC方案特定信息（FSSI）包括特定于当前FEC方案的元素。更准确地说：
o PRNG seed (seed): a non-negative 32-bit integer used as the seed of the Pseudo-Random Number Generator, as defined in [RFC5170].
o PRNG seed（seed）：用作伪随机数生成器种子的非负32位整数，如[RFC5170]中所定义。
o Encoding symbol length (E): a non-negative integer 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）：一个非负整数，表示每个编码符号的长度（字节）（严格模式，即，如果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 N1 minus 3 (n1m3): an integer between 0 (default) and 7, inclusive. The number of "1s" per column in the left side of the parity check matrix, N1, is then equal to N1m3 + 3, as specified in [RFC5170].
o N1减3（n1m3）：介于0（默认值）和7（含7）之间的整数。奇偶校验矩阵N1左侧每列的“1”数等于N1m3+3，如[RFC5170]中所规定。
These elements are required both by the sender (LDPC-Staircase encoder) and the receiver(s) (LDPC-Staircase decoder).
发送方（LDPC阶梯编码器）和接收方（LDPC阶梯解码器）都需要这些元件。
When SDP is used to communicate the FFCI, this FEC scheme-specific information is carried in the 'fssi' parameter in textual representation as specified in [RFC6364]. For instance:
当使用SDP与FFCI进行通信时，FEC方案特定信息以文本表示形式载于[RFC6364]中规定的“fssi”参数中。例如：
fssi=seed:1234,E:1400,S:0,n1m3:0
fssi=seed:1234,E:1400,S:0,n1m3:0
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 7 octets:
如果另一种机制要求FSSI作为不透明八位字节字符串携带（例如，在Base64编码之后），则编码格式由以下7个八位字节组成：
o PRNG seed (seed): 32-bit field.
o PRNG seed（种子）：32位字段。
o Encoding symbol length (E): 16-bit field.
o 编码符号长度（E）：16位字段。
o Strict (S) flag: 1-bit field.
o 严格（S）标志：1位字段。
o Reserved: a 4-bit field that MUST be set to zero.
o 保留：必须设置为零的4位字段。
o N1m3 parameter (n1m3): 3-bit field.
o N1m3参数（N1m3）：3位字段。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRNG seed (seed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol Length (E) |S| resvd | n1m3|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRNG seed (seed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol Length (E) |S| resvd | n1m3|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 following fields (Figure 5):
更准确地说，显式源FEC有效负载ID由以下字段组成（图5）：
o Source Block Number (SBN) (16-bit field): this field identifies the source block to which this FEC source packet belongs.
o 源块编号（SBN）（16位字段）：此字段标识此FEC源数据包所属的源块。
o Encoding Symbol ID (ESI) (16-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）（16位字段）：此字段标识此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.
o 源块长度（k）（16位字段）：此字段提供此源块的源符号数，即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 (SBN) | Encoding Symbol ID (ESI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 (SBN) | Encoding Symbol ID (ESI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length (k) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Source FEC Payload ID Encoding Format
图5：源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 6. There
MUST be a single repair symbol per FEC repair packet.
+--------------------------------+
| IP Header |
+--------------------------------+
| Transport Header |
+--------------------------------+
| Repair FEC Payload ID |
+--------------------------------+
| Repair Symbol |
+--------------------------------+
A FEC repair packet MUST contain a Repair FEC Payload ID that is
prepended to the repair symbol(s) as illustrated in Figure 6. There
MUST be a single repair symbol per FEC repair packet.
+--------------------------------+
| IP Header |
+--------------------------------+
| Transport Header |
+--------------------------------+
| Repair FEC Payload ID |
+--------------------------------+
| Repair Symbol |
+--------------------------------+
Figure 6: Structure of a FEC Repair Packet with the Repair Payload ID
图6：具有修复有效负载ID的FEC修复包的结构
More precisely, the Repair FEC Payload ID is composed of the following fields (Figure 7):
更准确地说，修复FEC有效负载ID由以下字段组成（图7）：
o Source Block Number (SBN) (16-bit field): this field identifies the source block to which the FEC repair packet belongs.
o 源块编号（SBN）（16位字段）：该字段标识FEC修复数据包所属的源块。
o Encoding Symbol ID (ESI) (16-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）（16位字段）：此字段标识此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.
o 源块长度（k）（16位字段）：此字段提供此源块的源符号数，即k参数。
o Number of Encoding Symbols (n) (16-bit field): this field provides the number of encoding symbols for this source block, i.e., the n parameter.
o 编码符号数（n）（16位字段）：此字段提供此源块的编码符号数，即n参数。
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 (SBN) | Encoding Symbol ID (ESI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length (k) | Number Encoding Symbols (n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (SBN) | Encoding Symbol ID (ESI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length (k) | Number Encoding Symbols (n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Repair FEC Payload ID Encoding Format
图7：修复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^^16 - 1.
o 对于ADU流的第一个块，SBN值必须以值0开始，对于每个新的源块，SBN值必须增加1。值2^^16-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 [RFC5170] the specification of the core LDPC-Staircase codes for a packet erasure transmission channel (see Section 1).
本文件继承了[RFC5170]关于分组擦除传输信道的核心LDPC阶梯码的规范（参见第1节）。
Because of the requirement to have exactly one encoding symbol per group, i.e., because G MUST be equal to 1 (Section 4.1), several parts of [RFC5170] are not of use. In particular, this is the case of Section 5.6, "Identifying the G Symbols of an Encoding Symbol Group".
由于要求每组只有一个编码符号，即G必须等于1（第4.1节），因此[RFC5170]的几个部分不可用。具体而言，这是第5.6节“识别编码符号组的G符号”的情况。
The FEC Framework 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 LDPC-Staircase codes.
FEC框架文件[RFC6363]提供了适用于FEC方案的安全考虑因素的综合分析。因此，本节遵循[RFC6363]的安全注意事项部分，仅讨论LDPC楼梯码使用的特定主题。
The LDPC-Staircase 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] be used, with special considerations
本文件中规定的LDPC楼梯FEC方案不会改变[RFC6363]的建议。总之，如果需要考虑保密性，建议使用[RFC6363]中提到的解决方案之一，并特别考虑
to the way this solution is applied (e.g., Is encryption applied before or after FEC protection? Is it 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.
该解决方案的应用方式（例如，加密是在FEC保护之前还是之后应用？是在终端系统中还是在中间盒中？），操作限制（例如，在受保护的环境中执行FEC解码可能很复杂，甚至不可能），以及威胁模型。
The LDPC-Staircase 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] be used on both the FEC source and repair packets.
本文件中规定的LDPC楼梯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. Contrarily, 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 N1 minus 3 (n1m3): changing this parameter leads the receiver to consider a different code, which enables an attacker to create a DoS.
o N1减3（N1M3）：改变这个参数导致接收器考虑不同的代码，这使得攻击者能够创建DOS。
Therefore, it is RECOMMENDED that security measures be 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), or the Number Encoding Symbols (n), 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 be taken to guarantee the FEC source and repair packets as stated in [RFC6363].
类似地，针对显式源FEC有效负载ID和修复FEC有效负载ID的攻击也是可能的：通过修改源块编号（SBN）、编码符号ID（ESI）、源块长度（k）或编码符号编号（n），攻击者可以轻易损坏SBN标识的块。还可能发生其他依赖于用例和/或CDP的后果。因此，建议采取安全措施，以保证FEC源并修复[RFC6363]中所述的数据包。
The LDPC-Staircase FEC Scheme specified in this document does not change the recommendations of [RFC6363].
本文件中规定的LDPC楼梯FEC方案不会改变[RFC6363]的建议。
The LDPC-Staircase 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 the FEC Framework operates.
本文件中规定的LDPC楼梯FEC方案不会改变[RFC6363]中关于使用IPsec/ESP安全协议作为强制实施（但非强制使用）安全方案的建议。这非常适合于唯一不安全的域是FEC框架运行的域的情况。
The FEC Framework 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 LDPC-Staircase codes as specified in this document.
FEC框架文件[RFC6363]提供了适用于FEC方案的运营和管理考虑因素的综合分析。因此，本节仅讨论本文件中规定的LDPC楼梯码使用的特定主题。
LDPC-Staircase codes have excellent erasure recovery capabilities with large source blocks, close to ideal MDS codes. For instance, independently of FECFRAME, let us consider a source block of size k=1024 symbols, CR=2/3 (i.e., 512 repair symbols are added), N1=7, G=1, a transmission scheme where all the symbols are sent in a random order, and a hybrid ITerative/Maximum Likelihood (IT/ML) decoder (see below). An ideal MDS code with code rate 2/3 can recover from erasures up to a 33.33% channel loss rate. With LDPC-Staircase codes, the average overhead amounts to 0.237% (i.e., receiving 2.43 symbols in addition to k, which corresponds to a 33.18% channel loss
LDPC阶梯码具有良好的擦除恢复能力，具有较大的源块，接近理想的MDS码。例如，独立于FECGrand，让我们考虑大小为k＝1024符号的源块、CR＝2/3（即，添加512个修复符号）、N1＝7、G＝1、以随机顺序发送所有符号的传输方案、以及混合迭代/最大似然（IT/ML）解码器（见下文）。码率为2/3的理想MDS代码可以从擦除中恢复，信道丢失率高达33.33%。对于LDPC阶梯码，平均开销达到0.237%（即，除了k之外，还接收2.43个符号，这相当于33.18%的信道损耗）
rate, enables a successful decoding with a probability 0.5), and an overhead of 1.46% (i.e., receiving 15 symbols in addition to k, which corresponds to a 32.36% channel loss rate) is sufficient to reduce the probability that decoding fails down to 8.2*10^^-5. This is why these codes are a good solution to protect a single high bitrate source flow as in [Matsuzono10] or to protect globally several mid-rate source flows within a single FECFRAME instance: in both cases, the source block size can be assumed to be equal to a few hundred (or more) source symbols.
速率，以0.5）的概率实现成功解码，并且1.46%的开销（即，除了k之外，还接收15个符号，这对应于32.36%的信道丢失率）足以将解码失败的概率降低到8.2×10^-5。这就是为什么这些代码是一个很好的解决方案，可以像[Matsuzono10]中那样保护单个高比特率源流，或者在单个FECFRAME实例中全局保护多个中速源流：在这两种情况下，可以假设源块大小等于几百（或更多）个源符号。
LDPC-Staircase codes are also a good solution whenever the processing load at a software encoder or decoder must be kept to a minimum. This is true when the decoder uses an IT decoding algorithm, an ML algorithm (we use a Gaussian Elimination as the ML algorithm) when carefully implemented, or a mixture of both techniques, which is the recommended solution [Cunche08][CunchePHD10][LDPC-codec-OpenFEC]. Let us consider the same conditions as above (k=1024 source symbols, CR=2/3, N1=7, G=1), with encoding symbols of size 1024 bytes. With an Intel Xeon 5120/1.86 GHz workstation running Linux/64 bits, the average decoding speed is between 1.78 Gbps (overhead of 2 symbols in addition to k, corresponding to a very bad channel with a 33.20% loss rate, close to the theoretical decoding limit, where ML decoding is required) and 3.91 Gbps (corresponding to a good channel with a 5% loss rate only, where IT decoding is sufficient). Under the same conditions, on a Samsung Galaxy SII smartphone (GT-I9100P model, featuring an ARM Cortex-A9/1.2 GHz processor and running Android 2.3.4), the decoding speed is between 397 Mbps (bad channel with a 33.20% loss rate, close to the theoretical decoding limit) and 813 Mbps (good channel with a 5% loss rate only).
当软件编码器或解码器的处理负载必须保持在最小值时，LDPC阶梯码也是一个很好的解决方案。当解码器在仔细实施时使用IT解码算法、ML算法（我们使用高斯消去法作为ML算法）或这两种技术的混合时，这是正确的，这是推荐的解决方案[Cunche08][CunchePHD10][LDPC编解码器OpenFEC]。让我们考虑与上面相同的条件（k＝1024个源符号，Cr＝2/3，N1＝7，G＝1），具有大小为1024字节的编码符号。对于运行Linux/64位的Intel Xeon 5120/1.86 GHz工作站，平均解码速度介于1.78 Gbps（除了k之外，还有2个符号的开销，对应于丢失率为33.20%的非常糟糕的信道，接近理论解码极限，需要ML解码）和3.91 Gbps之间（对应于只有5%丢失率的好通道，解码就足够了）。在相同条件下，在三星Galaxy SII智能手机（GT-I9100P型号，采用ARM Cortex-A9/1.2 GHz处理器，运行Android 2.3.4）上，解码速度在397 Mbps之间（丢失率为33.20%的坏信道，接近理论解码极限）和813 Mbps（仅丢失率为5%的好信道）。
As the source block size decreases, the erasure recovery capabilities of LDPC codes in general also decrease. In the case of LDPC-Staircase codes, in order to limit this phenomenon, it is recommended to use a value of the N1 parameter at least equal to 7 (e.g., experiments carried out in [Matsuzono10] use N1=7 if k=170 symbols, and N1=5 otherwise). For instance, independently of FECFRAME, with a source block of size k=256 symbols, CR=2/3 (i.e., 128 repair symbols are added), N1=7, and G=1, the average overhead amounts to 0.706% (i.e., receiving 1.8 symbols in addition to k enables a successful decoding with a probability 0.5), and an overhead of 5.86% (i.e., receiving 15 symbols in addition to k) is sufficient to reduce the decoding failure probability to 5.9*10^^-5.
随着源块大小的减小，LDPC码的擦除恢复能力通常也会降低。在LDPC阶梯码的情况下，为了限制这种现象，建议使用至少等于7的N1参数值（例如，在[Matsuzono10]中进行的实验，如果k=170个符号，则使用N1=7，否则使用N1=5）。例如，独立于FECFRAME，对于大小为k＝256个符号、CR＝2/3（即，添加128个修复符号）、N1＝7和G＝1的源块，平均开销达到0.706%（即，除了k之外接收1.8个符号使得能够以概率0.5成功解码），并且开销为5.86%（即，除了k之外接收15个符号）足以将解码失败概率降低到5.9×10^-5。
The processing load also decreases with the source block size. For instance, under these conditions (k=256 source symbols, CR=2/3, N1=7, and G=1), with encoding symbols of size 1024 bytes, on a Samsung Galaxy SII smartphone, the decoding speed is between 518 Mbps (bad channel) and 863 Mbps (good channel with a 5% loss rate only).
处理负载也随着源块的大小而减小。例如，在这些条件下（k=256个源符号，CR=2/3，N1=7，G=1），编码符号大小为1024字节，在三星Galaxy SII智能手机上，解码速度介于518 Mbps（坏信道）和863 Mbps（好信道，仅丢失率为5%）之间。
With very small source blocks (e.g., a few tens of symbols), using for instance Reed-Solomon codes [SIMPLE_RS] or 2D parity check codes may be more appropriate.
对于非常小的源块（例如，几十个符号），例如使用里德-所罗门码[SIMPLE_RS]或2D奇偶校验码可能更合适。
The way the FEC repair packets are transmitted is of high importance. A good strategy, that works well for any kind of channel loss model, consists in sending FEC repair packets in random order (rather than in sequence) while FEC source packets are sent first and in sequence. Sending all packets in a random order is another possibility, but it requires that all repair symbols for a source block be produced first, which adds some extra delay at a sender.
FEC修复包的传输方式非常重要。一种适用于任何类型的信道丢失模型的好策略是，以随机顺序（而不是顺序）发送FEC修复数据包，而FEC源数据包是先按顺序发送的。以随机顺序发送所有数据包是另一种可能性，但它要求首先生成源块的所有修复符号，这会在发送方增加一些额外的延迟。
This document registers one value in the "FEC Framework (FECFRAME) FEC Encoding IDs" registry [RFC6363] as follows:
本文档在“FEC框架（FEC框架）FEC编码ID”注册表[RFC6363]中注册一个值，如下所示：
o 7 refers to the Simple LDPC-Staircase FEC Scheme for Arbitrary Packet Flows, as defined in Section 5 of this document.
o 7指用于任意分组流的简单LDPC阶梯FEC方案，如本文件第5节所定义。
The authors want to thank K. Matsuzono, J. Detchart, and H. Asaeda for their contributions in evaluating the use of LDPC-Staircase codes in the context of FECFRAME [Matsuzono10].
作者要感谢K.Matsuzono、J.Detchart和H.Asaeda在评估FECFRAME中LDPC阶梯码的使用方面所做的贡献[Matsuzono 10]。
[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月。
[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月。
[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月。
[Cunche08] Cunche, M. and V. Roca, "Optimizing the Error Recovery Capabilities of LDPC-Staircase Codes Featuring a Gaussian Elimination Decoding Scheme", 10th IEEE International Workshop on Signal Processing for Space Communications (SPSC'08), October 2008.
[Cunche08]Cunche，M.和V.Roca，“优化具有高斯消除解码方案的LDPC阶梯码的错误恢复能力”，第十届IEEE空间通信信号处理国际研讨会（SPSC'08），2008年10月。
[CunchePHD10] Cunche, M., "High performances AL-FEC codes for the erasure channel : variation around LDPC codes", PhD dissertation (in French) (http:// tel.archives-ouvertes.fr/tel-00451336/en/), June 2010.
[CunchePHD10]Cunche，M.，“擦除信道的高性能AL-FEC码：LDPC码的变化”，博士论文（法语）（http://tel.archives-ouvertes.fr/tel-00451336/en/），2010年6月。
[LDPC-codec] Cunche, M., Roca, V., Neumann, C., and J. Laboure, "LDPC-Staircase/LDPC-Triangle Codec Reference Implementation", INRIA Rhone-Alpes and STMicroelectronics, <http://planete-bcast.inrialpes.fr/>.
[LDPC编解码器]Cunche，M.，Roca，V.，Neumann，C.，和J.Laboure，“LDPC楼梯/LDPC三角形编解码器参考实现”，INRIA Rhone Alpes和意法半导体公司<http://planete-bcast.inrialpes.fr/>.
[LDPC-codec-OpenFEC] "The OpenFEC project", <http://openfec.org/>.
[LDPC编解码器OpenFEC]“OpenFEC项目”<http://openfec.org/>.
[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月。
[RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002.
[RFC3453]Luby，M.，Vicisano，L.，Gemmell，J.，Rizzo，L.，Handley，M.，和J.Crowcroft，“在可靠多播中使用前向纠错（FEC）”，RFC 3453，2002年12月。
[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月。
[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月。
[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月。
[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月。
[SIMPLE_RS] Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K. Matsuzono, "Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME", Work in Progress, October 2012.
[SIMPLE_RS]Roca，V.，Cunche，M.，Lacan，J.，Bouabdallah，A.，和K.Matsuzono，“FEC帧的简单Reed-Solomon前向纠错（FEC）方案”，正在进行的工作，2012年10月。
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/