Network Working Group V. Roca
Request for Comments: 5170 INRIA
Category: Standards Track C. Neumann
Thomson
D. Furodet
STMicroelectronics
June 2008
Network Working Group V. Roca
Request for Comments: 5170 INRIA
Category: Standards Track C. Neumann
Thomson
D. Furodet
STMicroelectronics
June 2008
Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC) Schemes
低密度奇偶校验（LDPC）阶梯和三角形前向纠错（FEC）方案
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This document describes two Fully-Specified Forward Error Correction (FEC) Schemes, Low Density Parity Check (LDPC) Staircase and LDPC Triangle, and their application to the reliable delivery of data objects on the packet erasure channel (i.e., a communication path where packets are either received without any corruption or discarded during transmission). These systematic FEC codes belong to the well-known class of "Low Density Parity Check" codes, and are large block FEC codes in the sense of RFC 3453.
本文描述了两种完全指定的前向纠错（FEC）方案，低密度奇偶校验（LDPC）阶梯和LDPC三角形，以及它们在数据包擦除信道上可靠传输数据对象方面的应用（即，一种通信路径，在该通信路径中，数据包被接收时没有任何损坏或在传输过程中被丢弃）。这些系统FEC码属于众所周知的“低密度奇偶校验”码类，并且是RFC 3453意义上的大块FEC码。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Definitions, Notations, and Abbreviations . . . . . . . . . . 3
3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
4. Formats and Codes . . . . . . . . . . . . . . . . . . . . . . 6
4.1. FEC Payload IDs . . . . . . . . . . . . . . . . . . . . . 6
4.2. FEC Object Transmission Information . . . . . . . . . . . 6
4.2.1. Mandatory Element . . . . . . . . . . . . . . . . . . 6
4.2.2. Common Elements . . . . . . . . . . . . . . . . . . . 6
4.2.3. Scheme-Specific Elements . . . . . . . . . . . . . . . 7
4.2.4. Encoding Format . . . . . . . . . . . . . . . . . . . 8
5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Determining the Maximum Source Block Length (B) . . . . . 11
5.3. Determining the Encoding Symbol Length (E) and Number
of Encoding Symbols per Group (G) . . . . . . . . . . . . 12
5.4. Determining the Maximum Number of Encoding Symbols
Generated for Any Source Block (max_n) . . . . . . . . . . 13
5.5. Determining the Number of Encoding Symbols of a Block
(n) . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.6. Identifying the G Symbols of an Encoding Symbol Group . . 14
5.7. Pseudo-Random Number Generator . . . . . . . . . . . . . . 17
6. Full Specification of the LDPC-Staircase Scheme . . . . . . . 19
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Parity Check Matrix Creation . . . . . . . . . . . . . . . 19
6.3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.4. Decoding . . . . . . . . . . . . . . . . . . . . . . . . . 21
7. Full Specification of the LDPC-Triangle Scheme . . . . . . . . 22
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.2. Parity Check Matrix Creation . . . . . . . . . . . . . . . 22
7.3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.4. Decoding . . . . . . . . . . . . . . . . . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 24
8.2. Attacks Against the Data Flow . . . . . . . . . . . . . . 24
8.2.1. Access to Confidential Objects . . . . . . . . . . . . 24
8.2.2. Content Corruption . . . . . . . . . . . . . . . . . . 25
8.3. Attacks Against the FEC Parameters . . . . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Trivial Decoding Algorithm (Informative Only) . . . . 30
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Definitions, Notations, and Abbreviations . . . . . . . . . . 3
3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
4. Formats and Codes . . . . . . . . . . . . . . . . . . . . . . 6
4.1. FEC Payload IDs . . . . . . . . . . . . . . . . . . . . . 6
4.2. FEC Object Transmission Information . . . . . . . . . . . 6
4.2.1. Mandatory Element . . . . . . . . . . . . . . . . . . 6
4.2.2. Common Elements . . . . . . . . . . . . . . . . . . . 6
4.2.3. Scheme-Specific Elements . . . . . . . . . . . . . . . 7
4.2.4. Encoding Format . . . . . . . . . . . . . . . . . . . 8
5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Determining the Maximum Source Block Length (B) . . . . . 11
5.3. Determining the Encoding Symbol Length (E) and Number
of Encoding Symbols per Group (G) . . . . . . . . . . . . 12
5.4. Determining the Maximum Number of Encoding Symbols
Generated for Any Source Block (max_n) . . . . . . . . . . 13
5.5. Determining the Number of Encoding Symbols of a Block
(n) . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.6. Identifying the G Symbols of an Encoding Symbol Group . . 14
5.7. Pseudo-Random Number Generator . . . . . . . . . . . . . . 17
6. Full Specification of the LDPC-Staircase Scheme . . . . . . . 19
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Parity Check Matrix Creation . . . . . . . . . . . . . . . 19
6.3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.4. Decoding . . . . . . . . . . . . . . . . . . . . . . . . . 21
7. Full Specification of the LDPC-Triangle Scheme . . . . . . . . 22
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.2. Parity Check Matrix Creation . . . . . . . . . . . . . . . 22
7.3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.4. Decoding . . . . . . . . . . . . . . . . . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 24
8.2. Attacks Against the Data Flow . . . . . . . . . . . . . . 24
8.2.1. Access to Confidential Objects . . . . . . . . . . . . 24
8.2.2. Content Corruption . . . . . . . . . . . . . . . . . . 25
8.3. Attacks Against the FEC Parameters . . . . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Trivial Decoding Algorithm (Informative Only) . . . . 30
[RFC3453] introduces large block FEC codes as an alternative to small block FEC codes like Reed-Solomon. The main advantage of such large block codes is the possibility to operate efficiently on source blocks with a size of several tens of thousands (or more) of source symbols. The present document introduces the Fully-Specified FEC Encoding ID 3 that is intended to be used with the LDPC-Staircase FEC codes, and the Fully-Specified FEC Encoding ID 4 that is intended to be used with the LDPC-Triangle FEC codes [RN04][MK03]. Both schemes belong to the broad class of large block codes. For a definition of the term Fully-Specified Scheme, see Section 4 of [RFC5052].
[RFC3453]引入了大块FEC码，作为诸如Reed Solomon之类的小块FEC码的替代方案。这样大的分组码的主要优点是可以对具有数万（或更多）源符号的源块进行有效操作。本文件介绍了拟用于LDPC阶梯FEC码的完全指定的FEC编码ID 3，以及拟用于LDPC三角形FEC码[RN04][MK03]的完全指定的FEC编码ID 4。这两种方案都属于大分组码的大类。关于术语完全指定方案的定义，请参见[RFC5052]第4节。
LDPC codes rely on a dedicated matrix, called a "parity check matrix", at the encoding and decoding ends. The parity check matrix defines relationships (or constraints) between the various encoding symbols (i.e., source symbols and repair symbols), which are later used by the decoder to reconstruct the original k source symbols if some of them are missing. These codes are systematic, in the sense that the encoding symbols include the source symbols in addition to the repair symbols.
LDPC码在编码和解码端依赖一个称为“奇偶校验矩阵”的专用矩阵。奇偶校验矩阵定义了各种编码符号（即，源符号和修复符号）之间的关系（或约束），如果其中一些丢失，解码器随后使用这些关系（或约束）来重构原始k个源符号。这些代码是系统的，因为编码符号除了修复符号之外还包括源符号。
Since the encoder and decoder must operate on the same parity check matrix, information must be communicated between them as part of the FEC Object Transmission Information.
由于编码器和解码器必须在相同的奇偶校验矩阵上操作，因此信息必须作为FEC对象传输信息的一部分在它们之间进行通信。
A publicly available reference implementation of these codes is available and distributed under a GNU/LGPL (Lesser General Public License) [LDPC-codec]. Besides, the code extracts included in this document are directly contributed to the IETF process by the authors of this document and by Radford M. Neal.
这些代码的公开参考实现可在GNU/LGPL（较小的通用公共许可证）[LDPC编解码器]下获得和分发。此外，本文件的作者和Radford M.Neal将本文件中包含的代码摘录直接贡献给IETF过程。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document uses the same terms and definitions as those specified in [RFC5052]. Additionally, it uses the following definitions:
本文件使用的术语和定义与[RFC5052]中规定的术语和定义相同。此外，它使用以下定义：
Source Symbol: a unit of data used during the encoding process
源符号：编码过程中使用的数据单位
Encoding Symbol: a unit of data generated by the encoding process
编码符号：由编码过程产生的数据单位
Repair Symbol: an 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. The code rate belongs to a ]0; 1] interval. A code rate close to 1 indicates that a small number of repair symbols have been produced during the encoding process
码率：k/n比，即源符号数与编码符号数之比。码率属于a]0；1] 间隔时间。接近1的码率表示在编码过程中产生了少量修复符号
Systematic Code: FEC code in which the source symbols are part of the encoding symbols
系统代码：FEC代码，其中源符号是编码符号的一部分
Source Block: a block of k source symbols that are considered together for the encoding
源代码块：为编码而考虑在一起的k个源符号块
Encoding Symbol Group: a group of encoding symbols that are sent together, within the same packet, and whose relationships to the source object can be derived from a single Encoding Symbol ID
编码符号组：在同一数据包内一起发送的一组编码符号，其与源对象的关系可从单个编码符号ID派生
Source Packet: a data packet containing only source symbols
源数据包：只包含源符号的数据包
Repair Packet: a data packet containing only repair symbols
修复包：仅包含修复符号的数据包
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
数据包擦除信道：数据包被丢弃（例如，被拥塞的路由器丢弃，或者因为传输错误的数量超过了物理层代码的纠正能力）或被接收的通信路径。当接收到数据包时，假定该数据包未损坏
This document uses the following notations:
本文件使用以下符号：
L denotes the object transfer length in bytes.
L表示对象传输长度（以字节为单位）。
k denotes the source block length in symbols, i.e., the number of source symbols of a source block.
k表示符号中的源块长度，即源块的源符号数。
n denotes the encoding block length, i.e., the number of encoding symbols generated for a source block.
n表示编码块长度，即，为源块生成的编码符号的数量。
E denotes the encoding symbol length in bytes.
E表示编码符号长度（以字节为单位）。
B denotes the maximum source block length in symbols, i.e., the maximum number of source symbols per source block.
B表示符号中的最大源块长度，即每个源块的最大源符号数。
N denotes the number of source blocks into which the object shall be partitioned.
N表示应将对象分割成的源块的数量。
G denotes the number of encoding symbols per group, i.e., the number of symbols sent in the same packet.
G表示每组编码符号的数量，即在同一数据包中发送的符号数量。
CR denotes the "code rate", i.e., the k/n ratio.
CR表示“码速率”，即k/n比。
max_n denotes the maximum number of encoding symbols generated for any source block. This is in particular the number of encoding symbols generated for a source block of size B.
max_n表示为任何源块生成的编码符号的最大数量。这尤其是为大小为B的源块生成的编码符号的数量。
H denotes the parity check matrix.
H表示奇偶校验矩阵。
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, where N1 is the target number of "1s" per column in the left side of the parity check matrix.
N1m3表示值N1-3，其中N1是奇偶校验矩阵左侧每列“1”的目标数。
pmms_rand(m) denotes the pseudo-random number generator defined in Section 5.7 that returns a new random integer in [0; m-1] each time it is called.
pmms_rand（m）表示第5.7节中定义的伪随机数生成器，它在每次调用[0；m-1]时返回一个新的随机整数。
This document uses the following abbreviations:
本文件使用以下缩写：
ESI: Encoding Symbol ID
ESI：编码符号ID
FEC OTI: FEC Object Transmission Information
FEC OTI:FEC对象传输信息
FPI: FEC Payload ID
FPI:FEC有效负载ID
LDPC: Low Density Parity Check
低密度奇偶校验
PRNG: Pseudo-Random Number Generator
伪随机数发生器
The FEC Payload ID is composed of the Source Block Number and the Encoding Symbol ID:
FEC有效负载ID由源块号和编码符号ID组成：
The Source Block Number (12-bit field) identifies from which source block of the object the encoding symbol(s) in the packet payload is(are) generated. There is a maximum of 2^^12 blocks per object. Source block numbering starts at 0.
源块编号（12位字段）标识从对象的哪个源块生成分组有效载荷中的编码符号。每个对象最多有2^^12个块。源块编号从0开始。
The Encoding Symbol ID (20-bit field) identifies which encoding symbol(s) generated from the source block is(are) carried in the packet payload. There is a maximum of 2^^20 encoding symbols per block. The first k values (0 to k-1) identify source symbols, the remaining n-k values (k to n-k-1) identify repair symbols.
编码符号ID（20位字段）标识从源块生成的哪些编码符号携带在分组有效载荷中。每个块最多有2^^20个编码符号。前k个值（0到k-1）标识源符号，其余n-k个值（k到n-k-1）标识修复符号。
There MUST be exactly one FEC Payload ID per packet. In the case of an Encoding Symbol Group, when multiple encoding symbols are sent in the same packet, the FEC Payload ID refers to the first symbol of the packet. The other symbols can be deduced from the ESI of the first symbol thanks to a dedicated function, as explained in Section 5.6
每个数据包必须只有一个FEC有效负载ID。在编码符号组的情况下，当在同一分组中发送多个编码符号时，FEC有效载荷ID指该分组的第一符号。如第5.6节所述，由于专用功能，可从第一个符号的ESI推导出其他符号
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 | Encoding Symbol ID (20 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Encoding Symbol ID (20 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: FEC Payload ID encoding format for FEC Encoding ID 3 and 4
图1:FEC编码ID 3和4的FEC有效负载ID编码格式
o FEC Encoding ID: the LDPC-Staircase and LDPC-Triangle Fully-Specified FEC Schemes use the FEC Encoding ID 3 (Staircase) and 4 (Triangle), respectively.
o FEC编码ID：LDPC阶梯和LDPC三角形完全指定的FEC方案分别使用FEC编码ID 3（阶梯）和4（三角形）。
The following elements MUST be defined with the present FEC Schemes:
以下要素必须与当前FEC方案一起定义：
o Transfer-Length (L): a non-negative integer indicating the length of the object in bytes. There are some restrictions on the maximum Transfer-Length that can be supported:
o 传输长度（L）：一个非负整数，表示对象的长度（字节）。可以支持的最大传输长度有一些限制：
maximum transfer length = 2^^12 * B * E
maximum transfer length = 2^^12 * B * E
For instance, if B=2^^19 (because of a code rate of 1/2, Section 5.2), and if E=1024 bytes, then the maximum transfer length is 2^^41 bytes (or 2 TB). The upper limit, with symbols of size 2^^16-1 bytes and a code rate larger or equal to 1/2, amounts to 2^^47 bytes (or 128 TB).
例如，如果B=2^^19（因为代码速率为1/2，第5.2节），并且如果E=1024字节，则最大传输长度为2^^41字节（或2 TB）。当符号大小为2^^16-1字节且码率大于或等于1/2时，上限为2^^47字节（或128 TB）。
o Encoding-Symbol-Length (E): a non-negative integer indicating the length of each encoding symbol in bytes.
o 编码符号长度（E）：一个非负整数，表示每个编码符号的长度（以字节为单位）。
o Maximum-Source-Block-Length (B): a non-negative integer indicating the maximum number of source symbols in a source block. There are some restrictions on the maximum B value, as explained in Section 5.2.
o 最大源块长度（B）：一个非负整数，表示源块中源符号的最大数量。如第5.2节所述，对最大B值有一些限制。
o Max-Number-of-Encoding-Symbols (max_n): a non-negative integer indicating the maximum number of encoding symbols generated for any source block. There are some restrictions on the maximum max_n value. In particular max_n is at most equal to 2^^20.
o 最大编码符号数（Max_n）：一个非负整数，表示为任何源块生成的最大编码符号数。最大最大值有一些限制。特别是，最大值最多等于2^^20。
Section 5 explains how to define the values of each of these elements.
第5节解释了如何定义这些元素的值。
The following elements MUST be defined with the present FEC Scheme:
当前FEC方案必须定义以下要素：
o N1m3: an integer between 0 (default) and 7, inclusive. The target number of "1s" per column in the left side of the parity check matrix, N1, is then equal to N1m3 + 3 (see Sections 6.2 and 7.2). Using the default value of 0 for N1m3 is recommended when the sender has no information on the decoding scheme used by the receivers. A value greater than 0 for N1m3 can be a good choice in specific situations, e.g., with LDPC-staircase codes when the sender knows that all the receivers use a Gaussian elimination decoding scheme. Nevertheless, the current document does not mandate any specific value. This choice is left to the codec developer.
o N1m3：介于0（默认值）和7（含7）之间的整数。奇偶校验矩阵左侧每列的目标“1”数N1等于N1m3+3（见第6.2节和第7.2节）。当发送方没有关于接收方使用的解码方案的信息时，建议对N1m3使用默认值0。在特定情况下，N1m3的值大于0可能是一个很好的选择，例如，当发送方知道所有接收机使用高斯消除解码方案时，使用LDPC阶梯码。然而，目前的文件没有规定任何具体价值。这个选择留给编解码器开发人员。
o G: an integer between 1 (default) and 31, inclusive, indicating the number of encoding symbols per group (i.e., per packet). The default value is 1, meaning that each packet contains exactly one symbol. Values greater than 1 can also be defined, as explained in Section 5.3.
o G：介于1（默认值）和31（含）之间的整数，表示每组（即每个数据包）的编码符号数。默认值为1，这意味着每个数据包只包含一个符号。如第5.3节所述，也可以定义大于1的值。
o PRNG seed: the seed is a 32-bit unsigned integer between 1 and 0x7FFFFFFE (i.e., 2^^31-2) inclusive. This value is used to initialize the Pseudo-Random Number Generator (Section 5.7).
o PRNG seed：seed是一个32位无符号整数，介于1和0x7FFFFFFFE（即2^^31-2）之间，包括1和0x7FFFFFFFE。该值用于初始化伪随机数生成器（第5.7节）。
This section shows two possible encoding formats of the above FEC OTI. The present document does not specify when or how these encoding formats should be used.
本节显示上述FEC OTI的两种可能的编码格式。本文件未规定何时或如何使用这些编码格式。
The FEC OTI binary format is the following when the EXT_FTI mechanism is used (e.g., within the Asynchronous Layer Coding (ALC) [RMT-PI-ALC] or NACK-Oriented Reliable Multicast (NORM) [RMT-PI-NORM] protocols).
当使用EXT_FTI机制时（例如，在异步层编码（ALC）[RMT-PI-ALC]或面向NACK的可靠多播（NORM）[RMT-PI-NORM]协议内），FEC OTI二进制格式如下所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET = 64 | HEL = 5 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Transfer-Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol Length (E) | N1m3| G | B (MSB) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B (LSB) | Max Nb of Enc. Symbols (max_n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRNG seed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET = 64 | HEL = 5 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Transfer-Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol Length (E) | N1m3| G | B (MSB) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B (LSB) | Max Nb of Enc. Symbols (max_n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRNG seed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: EXT_FTI Header for FEC Encoding ID 3 and 4
图2:FEC编码ID 3和4的EXT_FTI头
In particular:
特别地：
o The Transfer-Length (L) field size (48 bits) is larger than the size required to store the maximum transfer length (Section 4.2.2) for field alignment purposes.
o 传输长度（L）字段大小（48位）大于存储用于字段对齐的最大传输长度（第4.2.2节）所需的大小。
o The Maximum-Source-Block-Length (B) field (20 bits) is split into two parts: the 8 most significant bits (MSB) are in the third 32- bit word of the EXT_FTI, and the remaining 12 least significant bits (LSB) are in the fourth 32-bit word.
o 最大源块长度（B）字段（20位）分为两部分：8个最高有效位（MSB）位于EXT_FTI的第三个32位字中，其余12个最低有效位（LSB）位于第四个32位字中。
When it is desired that the FEC OTI be carried in the File Delivery Table (FDT) Instance of a File Delivery over Unidirectional Transport (FLUTE) session [RMT-FLUTE], the following XML attributes must be described for the associated object:
当需要在通过单向传输（FLUTE）会话[RMT-FLUTE]的文件传递的文件传递表（FDT）实例中携带FEC OTI时，必须为相关对象描述以下XML属性：
o FEC-OTI-FEC-Encoding-ID
o FEC OTI FEC编码ID
o FEC-OTI-Transfer-length
o FEC-OTI传输长度
o FEC-OTI-Encoding-Symbol-Length
o 编码符号长度
o FEC-OTI-Maximum-Source-Block-Length
o FEC OTI最大源块长度
o FEC-OTI-Max-Number-of-Encoding-Symbols
o FEC OTI编码符号的最大数量
o FEC-OTI-Scheme-Specific-Info
o FEC OTI方案特定信息
The FEC-OTI-Scheme-Specific-Info contains the string resulting from the Base64 encoding [RFC4648] of the following value:
FEC OTI方案特定信息包含以下值的Base64编码[RFC4648]产生的字符串：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRNG seed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| N1m3| G |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRNG seed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| N1m3| G |
+-+-+-+-+-+-+-+-+
Figure 3: FEC OTI Scheme-Specific Information to be Included in the FDT Instance for FEC Encoding ID 3 and 4
图3:FEC编码ID 3和4的FDT实例中包含的FEC OTI方案特定信息
During Base64 encoding, the 5 bytes of the FEC OTI Scheme-Specific Information are transformed into a string of 8 printable characters (in the 64-character alphabet) that is added to the FEC-OTI-Scheme-Specific-Info attribute.
在Base64编码期间，FEC OTI方案特定信息的5个字节被转换为8个可打印字符的字符串（以64个字符的字母表示），该字符串被添加到FEC OTI方案特定信息属性中。
This section defines procedures that are common to FEC Encoding IDs 3 and 4.
本节定义了FEC编码ID 3和4通用的过程。
The B (maximum source block length in symbols), E (encoding symbol length in bytes), and G (number of encoding symbols per group) parameters are first determined. The algorithms of Section 5.2 and
首先确定B（以符号表示的最大源块长度）、E（以字节表示的编码符号长度）和G（每组编码符号的数量）参数。第5.2节的算法和
Section 5.3 MAY be used to that purpose. Using other algorithms is possible without compromising interoperability since the B, E, and G parameters are communicated to the receiver by means of the FEC OTI.
第5.3节可用于此目的。由于通过FEC-OTI将B、E和G参数传送给接收机，因此可以在不损害互操作性的情况下使用其他算法。
Then, the source object MUST be partitioned using the block partitioning algorithm specified in [RFC5052]. To that purpose, the B, L (object transfer length in bytes), and E arguments are provided. As a result, the object is partitioned into N source blocks. These blocks are numbered consecutively from 0 to N-1. The first I source blocks consist of A_large source symbols, the remaining N-I source blocks consist of A_small source symbols. Each source symbol is E bytes in length, except perhaps the last symbol, which may be shorter.
然后，必须使用[RFC5052]中指定的块分区算法对源对象进行分区。为此，提供了B、L（以字节为单位的对象传输长度）和E参数。结果，对象被划分为N个源块。这些块从0到N-1连续编号。第一个I源块由A_个大源符号组成，其余N-I源块由A_个小源符号组成。每个源符号的长度为E字节，但最后一个符号可能较短。
Then, the max_n (maximum number of encoding symbols generated for any source block) parameter is determined. The algorithm in Section 5.4 MAY be used to that purpose. Using another algorithm is possible without compromising interoperability since the max_n parameter is communicated to the receiver by means of the FEC OTI.
然后，确定max_n（为任何源块生成的编码符号的最大数目）参数。第5.4节中的算法可用于此目的。在不损害互操作性的情况下使用另一种算法是可能的，因为max_n参数通过FEC OTI传送给接收机。
For each block, the actual number of encoding symbols, n, MUST then be determined using the "n-algorithm" detailed in Section 5.5.
对于每个块，必须使用第5.5节详述的“n算法”确定编码符号的实际数量n。
Then, FEC encoding and decoding can be done block per block, independently. To that purpose, a parity check matrix is created, that forms a system of linear equations between the source and repair symbols of a given block, where the basic operator is XOR.
然后，FEC编码和解码可以独立地逐块进行。为此，创建奇偶校验矩阵，在给定块的源符号和修复符号之间形成线性方程组，其中基本运算符为XOR。
This parity check matrix is logically divided into two parts: the left side (from column 0 to k-1) describes the occurrences of each source symbol in the system of linear equations; the right side (from column k to n-1) describes the occurrences of each repair symbol in the system of linear equations. The only difference between the LDPC-Staircase and LDPC-Triangle schemes is the construction of this right sub-matrix. An entry (a "1") in the matrix at position (i,j) (i.e., at row i and column j) means that the symbol with ESI j appears in equation i of the system.
该奇偶校验矩阵在逻辑上分为两部分：左侧（从第0列到第k-1列）描述线性方程组中每个源符号的出现情况；右侧（从k列到n-1列）描述了线性方程组中每个修复符号的出现情况。LDPC阶梯方案和LDPC三角形方案之间的唯一区别是构造这个右子矩阵。矩阵中位置（i，j）（即第i行和第j列）处的条目（a“1”）意味着带有ESI j的符号出现在系统的方程式i中。
When the parity symbols have been created, the sender transmits source and parity symbols. The way this transmission occurs can largely impact the erasure recovery capabilities of the LDPC-* FEC. In particular, sending parity symbols in sequence is suboptimal. Instead, it is usually recommended to shuffle these symbols. The interested reader will find more details in [NRFF05].
创建奇偶校验符号后，发送方发送源符号和奇偶校验符号。这种传输发生的方式会在很大程度上影响LDPC-*FEC的擦除恢复能力。特别是，按顺序发送奇偶校验符号是次优的。相反，通常建议将这些符号洗牌。感兴趣的读者将在[NRFF05]中找到更多详细信息。
The following sections detail how the B, E, G, max_n, and n parameters are determined (in Sections 5.2, 5.3, 5.4 and 5.5, respectively). Section 5.6 details how Encoding Symbol Groups are created, and finally, Section 5.7 covers the PRNG.
以下各节详细说明了如何确定B、E、G、max_n和n参数（分别在第5.2、5.3、5.4和5.5节中）。第5.6节详细介绍了如何创建编码符号组，最后，第5.7节介绍了PRNG。
The B parameter (maximum source block length in symbols) depends on several parameters: the code rate (CR), the Encoding Symbol ID field length of the FEC Payload ID (20 bits), as well as possible internal codec limitations.
B参数（符号中的最大源块长度）取决于几个参数：码率（CR）、FEC有效负载ID的编码符号ID字段长度（20位）以及可能的内部编解码器限制。
The B parameter cannot be larger than the following values, derived from the FEC Payload ID limitations, for a given code rate:
对于给定的代码速率，B参数不能大于从FEC有效负载ID限制导出的以下值：
max1_B = 2^^(20 - ceil(Log2(1/CR)))
max1_B = 2^^(20 - ceil(Log2(1/CR)))
Some common max1_B values are:
一些常见的最大值为：
o CR == 1 (no repair symbol): max1_B = 2^^20 = 1,048,576
o CR==1（无修复符号）：max1_B=2^^20=1048576
o 1/2 <= CR < 1: max1_B = 2^^19 = 524,288 symbols
o 1/2 <= CR < 1: max1_B = 2^^19 = 524,288 symbols
o 1/4 <= CR < 1/2: max1_B = 2^^18 = 262,144 symbols
o 1/4 <= CR < 1/2: max1_B = 2^^18 = 262,144 symbols
o 1/8 <= CR < 1/4: max1_B = 2^^17 = 131,072 symbols
o 1/8 <= CR < 1/4: max1_B = 2^^17 = 131,072 symbols
Additionally, a codec MAY impose other limitations on the maximum block size. For instance, this is the case when the codec uses internally 16-bit unsigned integers to store the Encoding Symbol ID, since it does not enable to store all the possible values of a 20-bit field. In that case, if for instance, 1/2 <= CR < 1, then the maximum source block length is 2^^15. Other limitations may also apply, 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_B limitation.
此外，编解码器可以对最大块大小施加其他限制。例如，当编解码器在内部使用16位无符号整数存储编码符号ID时就是这种情况，因为它不能存储20位字段的所有可能值。在这种情况下，例如，如果1/2<=CR<1，则最大源块长度为2^^15。其他限制也可能适用，例如，由于工作内存大小有限。当目标用例已知时，必须在实现时澄清该决策。这会导致max2_B限制。
Then, B is given by:
然后，B由下式给出：
B = min(max1_B, max2_B)
B=最小值（最大值为1，最大值为2）
Note that this calculation is only required at the coder, since the B parameter is communicated to the decoder through the FEC OTI.
注意，由于B参数通过FEC OTI传送到解码器，因此仅在编码器处需要该计算。
5.3. Determining the Encoding Symbol Length (E) and Number of Encoding Symbols per Group (G)
5.3. 确定编码符号长度（E）和每组编码符号的数量（G）
The E parameter usually depends on the maximum transmission unit on the path (PMTU) from the source to each receiver. In order to minimize the protocol header overhead (e.g., the Layered Coding Transport (LCT), UDP, IPv4, or IPv6 headers in the case of ALC), E is chosen to be as large as possible. In that case, E is chosen so that the size of a packet composed of a single symbol (G=1) remains below but close to the PMTU.
E参数通常取决于从源到每个接收器的路径（PMTU）上的最大传输单位。为了最小化协议头开销（例如，在ALC的情况下，分层编码传输（LCT）、UDP、IPv4或IPv6头），e被选择为尽可能大。在这种情况下，选择E使得由单个符号（G＝1）组成的分组的大小保持在低于但接近PMTU的位置。
However, other considerations can exist. For instance, the E parameter can be made a function of the object transfer length. Indeed, LDPC codes are known to offer better protection for large blocks. In the case of small objects, it can be advantageous to reduce the encoding symbol length (E) in order to artificially increase the number of symbols and therefore the block size.
然而，也可能存在其他考虑因素。例如，E参数可以作为对象传输长度的函数。事实上，众所周知，LDPC码可以为大数据块提供更好的保护。在小对象的情况下，减少编码符号长度（E）以人为地增加符号的数量从而增加块大小是有利的。
In order to minimize the protocol header overhead, several symbols can be grouped in the same Encoding Symbol Group (i.e., G > 1). Depending on how many symbols are grouped (G) and on the packet loss rate (G symbols are lost for each packet erasure), this strategy might or might not be appropriate. A balance must therefore be found.
为了最小化协议头开销，可以将多个符号分组在同一编码符号组中（即，G>1）。根据分组的符号数量（G）和分组丢失率（每个分组擦除丢失G个符号），此策略可能合适，也可能不合适。因此，必须找到平衡。
The current specification does not mandate any value for either E or G. The current specification only provides an example of possible choices for E and G. Note that this choice is made by the sender, and the E and G parameters are then communicated to the receiver thanks to the FEC OTI. Note also that the decoding algorithm used influences the choice of the E and G parameters. Indeed, increasing the number of symbols will negatively impact the processing load when decoding is based (in part or totally) on Gaussian elimination, whereas the impacts will be rather low when decoding is based on the trivial algorithm sketched in Section 6.4.
当前规范没有规定E或G的任何值。当前规范仅提供了E和G的可能选择示例。请注意，该选择由发送方做出，并且E和G参数随后通过FEC OTI传递给接收方。还要注意，所使用的解码算法影响E和G参数的选择。事实上，当解码（部分或全部）基于高斯消去法时，增加符号数量将对处理负载产生负面影响，而当解码基于第6.4节所述的普通算法时，影响将相当小。
Example:
例子：
Let us assume that the trivial decoding algorithm sketched in Section 6.4 is used. First, define the target packet payload size, pkt_sz (at most equal to the PMTU minus the size of the various protocol headers). The pkt_sz must be chosen in such a way that the symbol size is an integer. This can require that pkt_sz be a multiple of 4, 8, or 16 (see the table below). Then calculate the number of packets in the object: nb_pkts = ceil(L / pkt_sz). Finally, thanks to nb_pkts, use the following table to find a possible G value.
让我们假设使用了第6.4节中描述的普通解码算法。首先，定义目标数据包有效负载大小pkt_sz（最多等于PMTU减去各种协议头的大小）。pkt_sz的选择方式必须确保符号大小为整数。这可能需要pkt_sz是4、8或16的倍数（见下表）。然后计算对象中的数据包数：nb_pkts=ceil（L/pkt_sz）。最后，感谢nb_pkts，使用下表查找可能的G值。
+------------------------+----+-------------+-------------------+
| Number of packets | G | Symbol size | k |
+------------------------+----+-------------+-------------------+
| 4000 <= nb_pkts | 1 | pkt_sz | 4000 <= k |
| | | | |
| 1000 <= nb_pkts < 4000 | 4 | pkt_sz / 4 | 4000 <= k < 16000 |
| | | | |
| 500 <= nb_pkts < 1000 | 8 | pkt_sz / 8 | 4000 <= k < 8000 |
| | | | |
| 1 <= nb_pkts < 500 | 16 | pkt_sz / 16 | 16 <= k < 8000 |
+------------------------+----+-------------+-------------------+
+------------------------+----+-------------+-------------------+
| Number of packets | G | Symbol size | k |
+------------------------+----+-------------+-------------------+
| 4000 <= nb_pkts | 1 | pkt_sz | 4000 <= k |
| | | | |
| 1000 <= nb_pkts < 4000 | 4 | pkt_sz / 4 | 4000 <= k < 16000 |
| | | | |
| 500 <= nb_pkts < 1000 | 8 | pkt_sz / 8 | 4000 <= k < 8000 |
| | | | |
| 1 <= nb_pkts < 500 | 16 | pkt_sz / 16 | 16 <= k < 8000 |
+------------------------+----+-------------+-------------------+
5.4. Determining the Maximum Number of Encoding Symbols Generated for Any Source Block (max_n)
5.4. 确定为任何源块生成的编码符号的最大数量（max\n）
The following algorithm MAY be used by a sender to determine the maximum number of encoding symbols generated for any source block (max_n) as a function of B and the target code rate. Since the max_n parameter is communicated to the decoder by means of the FEC OTI, another method MAY be used to determine max_n.
发送方可以使用以下算法来确定作为B和目标码速率的函数为任何源块生成的编码符号的最大数目（max_n）。由于max_n参数通过FEC OTI传送给解码器，因此可以使用另一种方法来确定max_n。
Input:
输入：
B: Maximum source block length, for any source block. Section 5.2 MAY be used to determine its value.
B：任何源块的最大源块长度。第5.2节可用于确定其值。
CR: FEC code rate, which is provided by the user (e.g., when starting a FLUTE sending application). It is expressed as a floating point value. The CR value must be such that the resulting number of encoding symbols per block is at most equal to 2^^20 (Section 4.1).
CR:FEC码速率，由用户提供（例如，启动长笛发送应用程序时）。它表示为浮点值。CR值必须确保每个块产生的编码符号数最多等于2^^20（第4.1节）。
Output:
输出：
max_n: Maximum number of encoding symbols generated for any source block.
max_n：为任何源块生成的编码符号的最大数量。
Algorithm:
算法：
max_n = ceil(B / CR);
max_n = ceil(B / CR);
if (max_n > 2^^20), then return an error ("invalid code rate");
if (max_n > 2^^20), then return an error ("invalid code rate");
(NB: if B has been defined as explained in Section 5.2, this error should never happen.)
（注意：如果B的定义如第5.2节所述，则该错误永远不会发生。）
The following algorithm, also called "n-algorithm", MUST be used by the sender and the receiver to determine the number of encoding symbols for a given block (n) as a function of B, k, and max_n.
发送方和接收方必须使用以下算法（也称为“n-算法”）来确定给定块（n）的编码符号数，作为B、k和max_n的函数。
Input:
输入：
B: Maximum source block length, for any source block. At a sender, Section 5.2 MAY be used to determine its value. At a receiver, this value MUST be extracted from the received FEC OTI.
B：任何源块的最大源块长度。对于发送方，第5.2节可用于确定其值。在接收器处，必须从接收到的FEC OTI中提取该值。
k: Current source block length. At a sender or receiver, the block partitioning algorithm MUST be used to determine its value.
k：当前源块长度。在发送方或接收方，必须使用块划分算法来确定其值。
max_n: Maximum number of encoding symbols generated for any source block. At a sender, Section 5.4 MAY be used to determine its value. At a receiver, this value MUST be extracted from the received FEC OTI.
max_n：为任何源块生成的编码符号的最大数量。对于发送方，第5.4节可用于确定其值。在接收器处，必须从接收到的FEC OTI中提取该值。
Output:
输出：
n: Number of encoding symbols generated for this source block.
n：为此源块生成的编码符号数。
Algorithm:
算法：
n = floor(k * max_n / B);
n = floor(k * max_n / B);
When multiple encoding symbols are sent in the same packet, the FEC Payload ID information of the packet MUST refer to the first encoding symbol. It MUST then be possible to identify each symbol from this single FEC Payload ID. To that purpose, the symbols of an Encoding Symbol Group (i.e., packet):
当在同一分组中发送多个编码符号时，分组的FEC有效载荷ID信息必须参考第一个编码符号。然后必须能够从该单个FEC有效负载ID识别每个符号。为此，编码符号组（即，分组）的符号：
o MUST all be either source symbols or repair symbols. Therefore, only source packets and repair packets are permitted, not mixed ones.
o 必须全部为源符号或修复符号。因此，只允许源数据包和修复数据包，不允许混合数据包。
o are identified by a function, sender(resp. receiver)_find_ESIs_of_group(), that takes as argument:
o 由函数sender（resp.receiver）\u find\u ESIs\u of_group（）标识，该函数采用以下参数：
* for a sender, the index of the Encoding Symbol Group (i.e., packet) that the application wants to create,
* 对于发送方，应用程序要创建的编码符号组（即数据包）的索引，
* for a receiver, the ESI information contained in the FEC Payload ID.
* 对于接收机，包含在FEC有效负载ID中的ESI信息。
and returns a list of G Encoding Symbol IDs. In the case of a source packet, the G Encoding Symbol IDs are chosen consecutively, by incrementing the ESI. In the case of a repair packet, the G repair symbols are chosen randomly, as explained below.
并返回G编码符号ID的列表。在源分组的情况下，通过增加ESI连续选择G编码符号id。在修复分组的情况下，随机选择G个修复符号，如下所述。
o are stored in sequence in the packet, without any padding. In other words, the last byte of the i-th symbol is immediately followed by the first byte of (i+1)-th symbol.
o 按顺序存储在数据包中，没有任何填充。换句话说，第i个符号的最后一个字节紧跟第（i+1）个符号的第一个字节。
The system must first be initialized by creating a random permutation of the n-k indexes. This initialization function MUST be called immediately after creating the parity check matrix. More precisely, since the PRNG seed is not re-initialized, there must not have been a call to the PRNG function between the time the parity check matrix has been initialized and the time the following initialization function is called. This is true both at a sender and at a receiver.
必须首先通过创建n-k索引的随机排列来初始化系统。创建奇偶校验矩阵后，必须立即调用此初始化函数。更准确地说，由于PRNG种子未重新初始化，因此在奇偶校验矩阵已初始化和调用以下初始化函数之间不得有对PRNG函数的调用。这在发送方和接收方都是正确的。
int *txseqToID;
int *IDtoTxseq;
int *txseqToID;
int *IDtoTxseq;
/*
* Initialization function.
* Warning: use only when G > 1.
*/
void
initialize_tables ()
{
int i;
int randInd;
int backup;
/*
* Initialization function.
* Warning: use only when G > 1.
*/
void
initialize_tables ()
{
int i;
int randInd;
int backup;
txseqToID = malloc((n-k) * sizeof(int));
IDtoTxseq = malloc((n-k) * sizeof(int));
if (txseqToID == NULL || IDtoTxseq == NULL)
handle the malloc failures as appropriate...
/* initialize the two tables that map ID
* (i.e., ESI-k) to/from TxSequence. */
for (i = 0; i < n - k; i++) {
IDtoTxseq[i] = i;
txseqToID[i] = i;
}
/* now randomize everything */
for (i = 0; i < n - k; i++) {
randInd = pmms_rand(n - k);
backup = IDtoTxseq[i];
IDtoTxseq[i] = IDtoTxseq[randInd];
IDtoTxseq[randInd] = backup;
txseqToID[IDtoTxseq[i]] = i;
txseqToID = malloc((n-k) * sizeof(int));
IDtoTxseq = malloc((n-k) * sizeof(int));
if (txseqToID == NULL || IDtoTxseq == NULL)
handle the malloc failures as appropriate...
/* initialize the two tables that map ID
* (i.e., ESI-k) to/from TxSequence. */
for (i = 0; i < n - k; i++) {
IDtoTxseq[i] = i;
txseqToID[i] = i;
}
/* now randomize everything */
for (i = 0; i < n - k; i++) {
randInd = pmms_rand(n - k);
backup = IDtoTxseq[i];
IDtoTxseq[i] = IDtoTxseq[randInd];
IDtoTxseq[randInd] = backup;
txseqToID[IDtoTxseq[i]] = i;
txseqToID[IDtoTxseq[randInd]] = randInd;
}
return;
}
txseqToID[IDtoTxseq[randInd]] = randInd;
}
return;
}
It is then possible, at the sender, to determine the sequence of G Encoding Symbol IDs that will be part of the group.
然后，可以在发送方确定将成为组的一部分的G编码符号id的序列。
/*
* Determine the sequence of ESIs for the packet under construction
* at a sender.
* Warning: use only when G > 1.
* PktIdx (IN): index of the packet, in
* {0..ceil(k/G)+ceil((n-k)/G)} range
* ESIs[] (OUT): list of ESIs for the packet
*/
void
sender_find_ESIs_of_group (int PktIdx,
ESI_t ESIs[])
{
int i;
/*
* Determine the sequence of ESIs for the packet under construction
* at a sender.
* Warning: use only when G > 1.
* PktIdx (IN): index of the packet, in
* {0..ceil(k/G)+ceil((n-k)/G)} range
* ESIs[] (OUT): list of ESIs for the packet
*/
void
sender_find_ESIs_of_group (int PktIdx,
ESI_t ESIs[])
{
int i;
if (PktIdx < nbSourcePkts) {
/* this is a source packet */
ESIs[0] = PktIdx * G;
for (i = 1; i < G; i++) {
ESIs[i] = (ESIs[0] + i) % k;
}
} else {
/* this is a repair packet */
for (i = 0; i < G; i++) {
ESIs[i] =
k +
txseqToID[(i + (PktIdx - nbSourcePkts) * G)
% (n - k)];
}
}
return;
}
if (PktIdx < nbSourcePkts) {
/* this is a source packet */
ESIs[0] = PktIdx * G;
for (i = 1; i < G; i++) {
ESIs[i] = (ESIs[0] + i) % k;
}
} else {
/* this is a repair packet */
for (i = 0; i < G; i++) {
ESIs[i] =
k +
txseqToID[(i + (PktIdx - nbSourcePkts) * G)
% (n - k)];
}
}
return;
}
Similarly, upon receiving an Encoding Symbol Group (i.e., packet), a receiver can determine the sequence of G Encoding Symbol IDs from the first ESI, esi0, that is contained in the FEC Payload ID.
类似地，在接收到编码符号组（即，分组）时，接收机可以确定包含在FEC有效负载ID中的来自第一ESI的G编码符号ID的序列esi0。
/*
* Determine the sequence of ESIs for the packet received.
* Warning: use only when G > 1.
* esi0 (IN): : ESI contained in the FEC Payload ID
* ESIs[] (OUT): list of ESIs for the packet
*/
void
receiver_find_ESIs_of_group (ESI_t esi0,
ESI_t ESIs[])
{
int i;
/*
* Determine the sequence of ESIs for the packet received.
* Warning: use only when G > 1.
* esi0 (IN): : ESI contained in the FEC Payload ID
* ESIs[] (OUT): list of ESIs for the packet
*/
void
receiver_find_ESIs_of_group (ESI_t esi0,
ESI_t ESIs[])
{
int i;
if (esi0 < k) {
/* this is a source packet */
ESIs[0] = esi0;
for (i = 1; i < G; i++) {
ESIs[i] = (esi0 + i) % k;
}
} else {
/* this is a repair packet */
for (i = 0; i < G; i++) {
ESIs[i] =
k +
txseqToID[(i + IDtoTxseq[esi0 - k])
% (n - k)];
}
}
}
if (esi0 < k) {
/* this is a source packet */
ESIs[0] = esi0;
for (i = 1; i < G; i++) {
ESIs[i] = (esi0 + i) % k;
}
} else {
/* this is a repair packet */
for (i = 0; i < G; i++) {
ESIs[i] =
k +
txseqToID[(i + IDtoTxseq[esi0 - k])
% (n - k)];
}
}
}
The FEC Encoding IDs 3 and 4 rely on a pseudo-random number generator (PRNG) that must be fully specified, in particular in order to enable the receivers and the senders to build the same parity check matrix.
FEC编码id 3和4依赖于必须完全指定的伪随机数生成器（PRNG），特别是为了使接收机和发送机能够构建相同的奇偶校验矩阵。
The Park-Miler "minimal standard" PRNG [PM88] MUST be used. It defines a simple multiplicative congruential algorithm: Ij+1 = A * Ij (modulo M), with the following choices: A = 7^^5 = 16807 and M = 2^^31 - 1 = 2147483647. A validation criteria of such a PRNG is the following: if seed = 1, then the 10,000th value returned MUST be equal to 1043618065.
必须使用Park Miler“最低标准”PRNG[PM88]。它定义了一个简单的乘法同余算法：Ij+1=a*Ij（模M），具有以下选项：a=7^^5=16807和M=2^^31-1=2147483647。此类PRNG的验证标准如下：如果seed=1，则返回的第10000个值必须等于1043618065。
Several implementations of this PRNG are known and discussed in the literature. An optimized implementation of this algorithm, using only 32-bit mathematics, and which does not require any division, can be found in [rand31pmc]. It uses the Park and Miller algorithm [PM88] with the optimization suggested by D. Carta in [CA90]. The history behind this algorithm is detailed in [WI08]. Yet, any other
文献中已知并讨论了该PRNG的几种实现。该算法的优化实现，仅使用32位数学，不需要任何除法，可在[rand31pmc]中找到。它使用Park和Miller算法[PM88]，并采用D.Carta在[CA90]中提出的优化方法。[WI08]中详细介绍了该算法的历史。然而，还有其他的吗
implementation of the PRNG algorithm that matches the above validation criteria, like the ones detailed in [PM88], is appropriate.
实现符合上述验证标准的PRNG算法（如[PM88]中详述的标准）是合适的。
This PRNG produces, natively, a 31-bit value between 1 and 0x7FFFFFFE (2^^31-2) inclusive. Since it is desired to scale the pseudo-random number between 0 and maxv-1 inclusive, one must keep the most significant bits of the value returned by the PRNG (the least significant bits are known to be less random, and modulo-based solutions should be avoided [PTVF92]). The following algorithm MUST be used:
该PRNG本机生成1和0x7FFFFFFFE（2^^31-2）之间的31位值。由于需要在0和maxv-1（包括0和maxv-1）之间缩放伪随机数，因此必须保留PRNG返回值的最高有效位（已知最低有效位的随机性较小，应避免基于模的解决方案[PTVF92]）。必须使用以下算法：
Input:
输入：
raw_value: random integer generated by the inner PRNG algorithm, between 1 and 0x7FFFFFFE (2^^31-2) inclusive.
原始值：由内部PRNG算法生成的随机整数，介于1和0x7FFFFFFFE（2^^31-2）之间。
maxv: upper bound used during the scaling operation.
maxv：缩放操作期间使用的上限。
Output:
输出：
scaled_value: random integer between 0 and maxv-1 inclusive.
缩放_值：介于0和maxv-1（含）之间的随机整数。
Algorithm:
算法：
scaled_value = (unsigned long) ((double)maxv * (double)raw_value /
(double)0x7FFFFFFF);
scaled_value = (unsigned long) ((double)maxv * (double)raw_value /
(double)0x7FFFFFFF);
(NB: the above C type casting to unsigned long is equivalent to using floor() with positive floating point values.)
（注意：上述C类型转换为无符号long相当于使用floor（）和正浮点值。）
In this document, pmms_rand(maxv) denotes the PRNG function that implements the Park-Miller "minimal standard" algorithm, defined above, and that scales the raw value between 0 and maxv-1 inclusive, using the above scaling algorithm. Additionally, a function should be provided to enable the initialization of the PRNG with a seed (i.e., a 31-bit integer between 1 and 0x7FFFFFFE inclusive) before calling pmms_rand(maxv) the first time.
在本文件中，pmms_rand（maxv）表示PRNG函数，该函数实现上文定义的Park-Miller“最小标准”算法，并使用上述缩放算法在0和maxv-1（含0和maxv-1）之间缩放原始值。此外，在第一次调用pmms_rand（maxv）之前，应提供一个函数，以启用带有种子的PRNG初始化（即，1和0x7ffffe之间的31位整数）。
The LDPC-Staircase scheme is identified by the Fully-Specified FEC Encoding ID 3.
LDPC阶梯方案由完全指定的FEC编码ID 3标识。
The PRNG used by the LDPC-Staircase scheme must be initialized by a seed. This PRNG seed is an instance-specific FEC OTI attribute (Section 4.2.3).
LDPC阶梯方案使用的PRNG必须由种子初始化。该PRNG种子是特定于实例的FEC OTI属性（第4.2.3节）。
The LDPC-Staircase matrix can be divided into two parts: the left side of the matrix defines in which equations the source symbols are involved; the right side of the matrix defines in which equations the repair symbols are involved.
LDPC阶梯矩阵可分为两部分：矩阵左侧定义源符号所涉及的方程；矩阵右侧定义了维修符号所涉及的方程式。
The left side MUST be generated by using the following function:
必须使用以下函数生成左侧：
/*
* Initialize the left side of the parity check matrix.
* This function assumes that an empty matrix of size n-k * k has
* previously been allocated/reset and that the matrix_has_entry(),
* matrix_insert_entry() and degree_of_row() functions can access it.
* (IN): the k, n and N1 parameters.
*/
void left_matrix_init (int k, int n, int N1)
{
int i; /* row index or temporary variable */
int j; /* column index */
int h; /* temporary variable */
int t; /* left limit within the list of possible choices u[] */
int u[N1*MAX_K]; /* table used to have a homogeneous 1 distrib. */
/*
* Initialize the left side of the parity check matrix.
* This function assumes that an empty matrix of size n-k * k has
* previously been allocated/reset and that the matrix_has_entry(),
* matrix_insert_entry() and degree_of_row() functions can access it.
* (IN): the k, n and N1 parameters.
*/
void left_matrix_init (int k, int n, int N1)
{
int i; /* row index or temporary variable */
int j; /* column index */
int h; /* temporary variable */
int t; /* left limit within the list of possible choices u[] */
int u[N1*MAX_K]; /* table used to have a homogeneous 1 distrib. */
/* Initialize a list of all possible choices in order to
* guarantee a homogeneous "1" distribution */
for (h = N1*k-1; h >= 0; h--) {
u[h] = h % (n-k);
}
/* Initialize a list of all possible choices in order to
* guarantee a homogeneous "1" distribution */
for (h = N1*k-1; h >= 0; h--) {
u[h] = h % (n-k);
}
/* Initialize the matrix with N1 "1s" per column, homogeneously */
t = 0;
for (j = 0; j < k; j++) { /* for each source symbol column */
for (h = 0; h < N1; h++) { /* add N1 "1s" */
/* check that valid available choices remain */
for (i = t; i < N1*k && matrix_has_entry(u[i], j); i++);
if (i < N1*k) {
/* choose one index within the list of possible
* choices */
do {
i = t + pmms_rand(N1*k-t);
} while (matrix_has_entry(u[i], j));
matrix_insert_entry(u[i], j);
/* Initialize the matrix with N1 "1s" per column, homogeneously */
t = 0;
for (j = 0; j < k; j++) { /* for each source symbol column */
for (h = 0; h < N1; h++) { /* add N1 "1s" */
/* check that valid available choices remain */
for (i = t; i < N1*k && matrix_has_entry(u[i], j); i++);
if (i < N1*k) {
/* choose one index within the list of possible
* choices */
do {
i = t + pmms_rand(N1*k-t);
} while (matrix_has_entry(u[i], j));
matrix_insert_entry(u[i], j);
/* replace with u[t] which has never been chosen */
u[i] = u[t];
t++;
} else {
/* no choice left, choose one randomly */
do {
i = pmms_rand(n-k);
} while (matrix_has_entry(i, j));
matrix_insert_entry(i, j);
}
}
}
/* replace with u[t] which has never been chosen */
u[i] = u[t];
t++;
} else {
/* no choice left, choose one randomly */
do {
i = pmms_rand(n-k);
} while (matrix_has_entry(i, j));
matrix_insert_entry(i, j);
}
}
}
/* Add extra bits to avoid rows with less than two "1s".
* This is needed when the code rate is smaller than 2/(2+N1) */
for (i = 0; i < n-k; i++) { /* for each row */
if (degree_of_row(i) == 0) {
j = pmms_rand(k);
matrix_insert_entry(i, j);
}
if (degree_of_row(i) == 1) {
do {
j = pmms_rand(k);
} while (matrix_has_entry(i, j));
matrix_insert_entry(i, j);
}
}
}
/* Add extra bits to avoid rows with less than two "1s".
* This is needed when the code rate is smaller than 2/(2+N1) */
for (i = 0; i < n-k; i++) { /* for each row */
if (degree_of_row(i) == 0) {
j = pmms_rand(k);
matrix_insert_entry(i, j);
}
if (degree_of_row(i) == 1) {
do {
j = pmms_rand(k);
} while (matrix_has_entry(i, j));
matrix_insert_entry(i, j);
}
}
}
The right side (the staircase) MUST be generated by using the following function:
必须使用以下功能生成右侧（楼梯）：
/*
* Initialize the right side of the parity check matrix with a
* staircase structure.
* (IN): the k and n parameters.
*/
void right_matrix_staircase_init (int k, int n)
{
int i; /* row index */
/*
* Initialize the right side of the parity check matrix with a
* staircase structure.
* (IN): the k and n parameters.
*/
void right_matrix_staircase_init (int k, int n)
{
int i; /* row index */
matrix_insert_entry(0, k); /* first row */
for (i = 1; i < n-k; i++) { /* for the following rows */
matrix_insert_entry(i, k+i); /* identity */
matrix_insert_entry(i, k+i-1); /* staircase */
}
}
matrix_insert_entry(0, k); /* first row */
for (i = 1; i < n-k; i++) { /* for the following rows */
matrix_insert_entry(i, k+i); /* identity */
matrix_insert_entry(i, k+i-1); /* staircase */
}
}
Note that just after creating this parity check matrix, when Encoding Symbol Groups are used (i.e., G > 1), the function initializing the two random permutation tables (Section 5.6) MUST be called. This is true both at a sender and at a receiver.
注意，在创建该奇偶校验矩阵之后，当使用编码符号组时（例如，G>1），必须调用初始化两个随机排列表的函数（第5.6节）。这在发送方和接收方都是正确的。
Thanks to the staircase matrix, repair symbol creation is straightforward: each repair symbol is equal to the sum of all source symbols in the associated equation, plus the previous repair symbol (except for the first repair symbol). Therefore, encoding MUST follow the natural repair symbol order: start with the first repair symbol and generate a repair symbol with ESI i before a symbol with ESI i+1.
由于楼梯矩阵，修复符号的创建非常简单：每个修复符号等于关联方程式中所有源符号的总和，加上上上一个修复符号（第一个修复符号除外）。因此，编码必须遵循自然修复符号顺序：从第一个修复符号开始，在ESI i+1符号之前生成ESI i修复符号。
Decoding basically consists in solving a system of n-k linear equations whose variables are the n source and repair symbols. Of course, the final goal is to recover the value of the k source symbols only.
解码基本上包括求解n-k线性方程组，其变量为n个源符号和修复符号。当然，最终目标是仅恢复k个源符号的值。
To that purpose, many techniques are possible. One of them is the following trivial algorithm [ZP74]: given a set of linear equations, if one of them has only one remaining unknown variable, then the value of this variable is that of the constant term. So, replace this variable by its value in all the remaining linear equations and reiterate. The value of several variables can therefore be found recursively. Applied to LDPC FEC codes working over an erasure
为此，许多技术是可能的。其中之一是下面的平凡算法[ZP74]：给定一组线性方程组，如果其中一个方程组只有一个剩余未知变量，那么该变量的值就是常数项的值。因此，在所有剩余的线性方程组中，用它的值替换这个变量，然后重复。因此，可以递归地找到几个变量的值。应用于LDPC FEC码在擦除过程中的工作
channel, the parity check matrix defines a set of linear equations whose variables are the source symbols and repair symbols. Receiving or decoding a symbol is equivalent to having the value of a variable. Appendix A sketches a possible implementation of this algorithm.
奇偶校验矩阵定义了一组线性方程组，其变量为源符号和修复符号。接收或解码符号相当于具有变量的值。附录A概述了该算法的可能实现。
A Gaussian elimination (or any optimized derivative) is another possible decoding technique. Hybrid solutions that start by using the trivial algorithm above and finish with a Gaussian elimination are also possible [CR08].
高斯消去（或任何优化的导数）是另一种可能的解码技术。混合解决方案也可以从使用上述平凡算法开始，以高斯消去法结束[CR08]。
Because interoperability does not depend on the decoding algorithm used, the current document does not recommend any particular technique. This choice is left to the codec developer.
由于互操作性不依赖于所使用的解码算法，因此当前文档不推荐任何特定技术。这个选择留给编解码器开发人员。
However, choosing a decoding technique will have great practical impacts. It will impact the erasure capabilities: a Gaussian elimination enables to solve the system with a smaller number of known symbols compared to the trivial technique. It will also impact the CPU load: a Gaussian elimination requires more processing than the above trivial algorithm. Depending on the target use case, the codec developer will favor one feature or the other.
然而，选择解码技术将有很大的实际影响。它将影响擦除能力：高斯消去法使系统的已知符号数比普通技术少。它还将影响CPU负载：高斯消去法比上述普通算法需要更多的处理。根据目标用例的不同，编解码器开发人员会选择其中一种功能。
LDPC-Triangle is identified by the Fully-Specified FEC Encoding ID 4.
LDPC三角形由完全指定的FEC编码ID 4标识。
The PRNG used by the LDPC-Triangle scheme must be initialized by a seed. This PRNG seed is an instance-specific FEC OTI attribute (Section 4.2.3).
LDPC三角形方案使用的PRNG必须由种子初始化。该PRNG种子是特定于实例的FEC OTI属性（第4.2.3节）。
The LDPC-Triangle matrix can be divided into two parts: the left side of the matrix defines in which equations the source symbols are involved; the right side of the matrix defines in which equations the repair symbols are involved.
LDPC三角矩阵可分为两部分：矩阵左侧定义源符号所涉及的方程；矩阵右侧定义了维修符号所涉及的方程式。
The left side MUST be generated by using the same left_matrix_init() function as with LDPC-Staircase (Section 6.2).
左侧必须使用与LDPC楼梯相同的左_矩阵_init（）函数生成（第6.2节）。
The right side (the triangle) MUST be generated by using the following function:
必须使用以下函数生成右侧（三角形）：
/*
* Initialize the right side of the parity check matrix with a
* triangle structure.
* (IN): the k and n parameters.
*/
void right_matrix_staircase_init (int k, int n)
{
int i; /* row index */
int j; /* randomly chosen column indexes in 0..n-k-2 */
int l; /* limitation of the # of "1s" added per row */
/*
* Initialize the right side of the parity check matrix with a
* triangle structure.
* (IN): the k and n parameters.
*/
void right_matrix_staircase_init (int k, int n)
{
int i; /* row index */
int j; /* randomly chosen column indexes in 0..n-k-2 */
int l; /* limitation of the # of "1s" added per row */
matrix_insert_entry(0, k); /* first row */
for (i = 1; i < n-k; i++) { /* for the following rows */
matrix_insert_entry(i, k+i); /* identity */
matrix_insert_entry(i, k+i-1); /* staircase */
/* now fill the triangle */
j = i-1;
for (l = 0; l < j; l++) { /* limit the # of "1s" added */
j = pmms_rand(j);
matrix_insert_entry(i, k+j);
}
}
}
matrix_insert_entry(0, k); /* first row */
for (i = 1; i < n-k; i++) { /* for the following rows */
matrix_insert_entry(i, k+i); /* identity */
matrix_insert_entry(i, k+i-1); /* staircase */
/* now fill the triangle */
j = i-1;
for (l = 0; l < j; l++) { /* limit the # of "1s" added */
j = pmms_rand(j);
matrix_insert_entry(i, k+j);
}
}
}
Note that just after creating this parity check matrix, when Encoding Symbol Groups are used (i.e., G > 1), the function initializing the two random permutation tables (Section 5.6) MUST be called. This is true both at a sender and at a receiver.
注意，在创建该奇偶校验矩阵之后，当使用编码符号组时（例如，G>1），必须调用初始化两个随机排列表的函数（第5.6节）。这在发送方和接收方都是正确的。
Here also, repair symbol creation is straightforward: each repair symbol of ESI i is equal to the sum of all source and repair symbols (with ESI lower than i) in the associated equation. Therefore, encoding MUST follow the natural repair symbol order: start with the first repair symbol, and generate repair symbol with ESI i before symbol with ESI i+1.
这里，修复符号的创建也很简单：ESI i的每个修复符号等于关联方程式中所有源符号和修复符号（ESI小于i）的总和。因此，编码必须遵循自然修复符号顺序：从第一个修复符号开始，在使用ESI+1的符号之前使用ESI生成修复符号。
Decoding basically consists in solving a system of n-k linear equations, whose variables are the n source and repair symbols. Of course, the final goal is to recover the value of the k source symbols only. To that purpose, many techniques are possible, as explained in Section 6.4.
解码基本上包括求解n-k线性方程组，其变量为n个源符号和修复符号。当然，最终目标是仅恢复k个源符号的值。为此，如第6.4节所述，许多技术是可能的。
Because interoperability does not depend on the decoding algorithm used, the current document does not recommend any particular technique. This choice is left to the codec implementer.
由于互操作性不依赖于所使用的解码算法，因此当前文档不推荐任何特定技术。这个选择留给编解码器实现者。
A content delivery system is potentially subject to many attacks: some of them target the network (e.g., to compromise the routing infrastructure, by compromising the congestion control component), others target the Content Delivery Protocol (CDP) (e.g., to compromise its normal behavior), and finally some attacks target the content itself. Since this document focuses on an FEC building block independently of any particular CDP (even if ALC and NORM are two natural candidates), this section only discusses the additional threats that an arbitrary CDP may be exposed to when using this building block.
内容交付系统可能会受到多种攻击：其中一些攻击以网络为目标（例如，通过破坏拥塞控制组件来破坏路由基础设施），另一些攻击以内容交付协议（CDP）为目标（例如，破坏其正常行为），最后一些攻击以内容本身为目标。由于本文档关注的是独立于任何特定CDP的FEC构建块（即使ALC和NORM是两个自然候选），因此本节仅讨论任意CDP在使用该构建块时可能面临的其他威胁。
More specifically, several kinds of attacks exist:
更具体地说，存在几种类型的攻击：
o those that are meant to give access to a confidential content (e.g., in case of a non-free content),
o 用于访问机密内容的内容（例如，在非免费内容的情况下），
o those that try to corrupt the object being transmitted (e.g., to inject malicious code within an object, or to prevent a receiver from using an object), and
o 试图破坏正在传输的对象（例如，在对象内注入恶意代码，或阻止接收者使用对象）的人，以及
o those that try to compromise the receiver's behavior (e.g., by making the decoding of an object computationally expensive).
o 那些试图损害接收者行为的行为（例如，通过使解码对象的计算代价高昂）。
These attacks can be launched either against the data flow itself (e.g., by sending forged symbols) or against the FEC parameters that are sent either in-band (e.g., in an EXT_FTI or FDT Instance) or out-of-band (e.g., in a session description).
这些攻击可以针对数据流本身（例如，通过发送伪造符号）或针对带内（例如，在EXT_FTI或FDT实例中）或带外（例如，在会话描述中）发送的FEC参数发起。
First of all, let us consider the attacks against the data flow.
首先，让我们考虑对数据流的攻击。
Access control to a confidential object being transmitted is typically provided by means of encryption. This encryption can be done over the whole object (e.g., by the content provider, before the FEC encoding process), or be done on a packet per packet basis (e.g., when IPsec/ESP is used [RFC4303]). If confidentiality is a concern,
对正在传输的机密对象的访问控制通常通过加密的方式提供。这种加密可以在整个对象上完成（例如，由内容提供商在FEC编码过程之前完成），或者在每个包的基础上完成（例如，当使用IPsec/ESP时[RFC4303]）。如果保密是一个问题，
it is RECOMMENDED that one of these solutions be used. Even if we mention these attacks here, they are not related or facilitated by the use of FEC.
建议使用其中一种解决方案。即使我们在这里提到这些攻击，它们也与FEC的使用无关，也不为FEC的使用提供便利。
Protection against corruptions (e.g., after sending forged packets) is achieved by means of a content integrity verification/sender authentication scheme. This service can be provided at the object level, but in that case a receiver has no way to identify which symbol(s) is(are) corrupted if the object is detected as corrupted. This service can also be provided at the packet level. In this case, after removing all forged packets, the object may be, in some cases, recovered. Several techniques can provide this source authentication/content integrity service:
通过内容完整性验证/发送方身份验证方案实现对损坏的保护（例如，在发送伪造数据包之后）。可以在对象级别提供此服务，但在这种情况下，如果检测到对象已损坏，则接收器无法识别哪些符号已损坏。也可以在分组级别提供该服务。在这种情况下，在移除所有伪造数据包之后，在某些情况下，可以恢复该对象。有几种技术可以提供此源身份验证/内容完整性服务：
o at the object level, the object MAY be digitally signed (with public key cryptography), for instance, by using RSASSA-PKCS1-v1_5 [RFC3447]. This signature enables a receiver to check the object integrity, once the latter has been fully decoded. Even if digital signatures are computationally expensive, this calculation occurs only once per object, which is usually acceptable;
o 在对象级别，对象可以进行数字签名（使用公钥加密），例如，使用RSASSA-PKCS1-v1_5[RFC3447]。一旦对象的完整性被完全解码，该签名使接收者能够检查对象的完整性。即使数字签名在计算上很昂贵，但每个对象只进行一次计算，这通常是可以接受的；
o at the packet level, each packet can be digitally signed. A major limitation is the high computational and transmission overheads that this solution requires (unless perhaps if Elliptic Curve Cryptography (ECC) is used). To avoid this problem, the signature may span a set of symbols (instead of a single one) in order to amortize the signature calculation. But if a single symbol is missing, the integrity of the whole set cannot be checked;
o 在数据包级别，每个数据包都可以进行数字签名。一个主要的限制是该解决方案需要较高的计算和传输开销（除非可能使用椭圆曲线加密（ECC））。为了避免这个问题，签名可以跨越一组符号（而不是单个符号），以便分摊签名计算。但如果缺少一个符号，则无法检查整套符号的完整性；
o at the packet level, a Group Message Authentication Code (MAC) [RFC2104] scheme can be used, for instance, by using HMAC-SHA-1 with a secret key shared by all the group members, senders, and receivers. This technique creates a cryptographically secured (thanks to the secret key) digest of a packet that is sent along with the packet. The Group MAC scheme does not create a prohibitive processing load or transmission overhead, but it has a major limitation: it only provides a group authentication/ integrity service since all group members share the same secret group key, which means that each member can send a forged packet. It is therefore restricted to situations where group members are fully trusted (or in association with another technique such as a pre-check);
o 在分组级别，例如，可以通过使用HMAC-SHA-1和由所有组成员、发送者和接收者共享的密钥来使用组消息认证码（MAC）[RFC2104]方案。这种技术创建了一个加密安全的（由于密钥）数据包摘要，该摘要随数据包一起发送。组MAC方案不会产生禁止性的处理负载或传输开销，但它有一个主要限制：它只提供组身份验证/完整性服务，因为所有组成员共享相同的组密钥，这意味着每个成员都可以发送伪造的数据包。因此，它仅限于组成员完全受信任（或与另一种技术（如预检查）相关联）的情况；
o at the packet level, Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [RFC4082] is an attractive solution that is robust to losses, provides a true authentication/integrity
o 在数据包级别，定时高效流丢失容忍认证（TESLA）[RFC4082]是一个具有吸引力的解决方案，它对丢失具有鲁棒性，提供真正的认证/完整性
service, and does not create any prohibitive processing load or transmission overhead. Yet, checking a packet requires a small delay (a second or more) after its reception.
服务，并且不会产生任何禁止性的处理负载或传输开销。然而，检查数据包需要在接收后有一个小的延迟（一秒或更长）。
Techniques relying on public key cryptography (digital signatures and TESLA during the bootstrap process, when used) require that public keys be securely associated to the entities. This can be achieved by a Public Key Infrastructure (PKI), or by a PGP Web of Trust, or by pre-distributing the public keys of each group member.
依靠公钥加密技术（使用引导过程中的数字签名和特斯拉）的技术要求公钥与实体安全关联。这可以通过公钥基础设施（PKI）、PGP信任网或预分发每个组成员的公钥来实现。
Techniques relying on symmetric key cryptography (Group MAC) require that a secret key be shared by all group members. This can be achieved by means of a group key management protocol, or simply by pre-distributing the secret key (but this manual solution has many limitations).
依赖对称密钥加密（组MAC）的技术要求所有组成员共享密钥。这可以通过组密钥管理协议或简单地通过预分发密钥来实现（但此手动解决方案有许多限制）。
It is up to the CDP developer, who knows the security requirements and features of the target application area, to define which solution is the most appropriate. Nonetheless, in case there is any concern of the threat of object corruption, it is RECOMMENDED that at least one of these techniques be used.
CDP开发人员知道目标应用程序领域的安全需求和特性，因此需要定义最合适的解决方案。尽管如此，如果担心对象损坏的威胁，建议至少使用其中一种技术。
Let us now consider attacks against the FEC parameters (or FEC OTI). The FEC OTI can either be sent in-band (i.e., in an EXT_FTI or in an FDT Instance containing FEC OTI for the object) or out-of-band (e.g., in a session description). Attacks on these FEC parameters can prevent the decoding of the associated object: for instance, modifying the B parameter will lead to a different block partitioning.
现在让我们考虑对FEC参数（或FEC OTI）的攻击。FEC-OTI可以在带内（即，在EXT_-FTI中或在包含对象的FEC-OTI的FDT实例中）或带外（例如，在会话描述中）发送。对这些FEC参数的攻击可以阻止相关对象的解码：例如，修改B参数将导致不同的块分区。
It is therefore RECOMMENDED that security measures be taken to guarantee the FEC OTI integrity. To that purpose, the packets carrying the FEC parameters sent in-band in an EXT_FTI header extension SHOULD be protected by one of the per-packet techniques described above: digital signature, Group MAC, or TESLA. When FEC OTI is contained in an FDT Instance, this object SHOULD be protected, for instance, by digitally signing it with XML digital signatures [RFC3275]. Finally, when FEC OTI is sent out-of-band (e.g., in a session description) the latter SHOULD be protected, for instance, by digitally signing it with [RFC3852].
因此，建议采取安全措施以保证FEC OTI的完整性。为此目的，携带在EXT_FTI报头扩展中的带内发送的FEC参数的分组应当受到上述每分组技术之一的保护：数字签名、组MAC或TESLA。当FEC OTI包含在FDT实例中时，应保护该对象，例如，使用XML数字签名对其进行数字签名[RFC3275]。最后，当FEC OTI在带外发送时（例如，在会话描述中），后者应受到保护，例如，通过使用[RFC3852]对其进行数字签名。
The same considerations concerning the key management aspects apply here, also.
关于关键管理方面的同样考虑也适用于这里。
Values of FEC Encoding IDs and FEC Instance IDs are subject to IANA registration. For general guidelines on IANA considerations as they apply to this document, see [RFC5052].
FEC编码ID和FEC实例ID的值受IANA注册的约束。有关适用于本文件的IANA注意事项的一般指南，请参见[RFC5052]。
This document assigns the Fully-Specified FEC Encoding ID 3 under the "ietf:rmt:fec:encoding" name-space to "LDPC Staircase Codes".
本文档将“ietf:rmt:FEC:Encoding”名称空间下的完全指定的FEC编码ID 3分配给“LDPC阶梯码”。
This document assigns the Fully-Specified FEC Encoding ID 4 under the "ietf:rmt:fec:encoding" name-space to "LDPC Triangle Codes".
本文档将“ietf:rmt:FEC:Encoding”名称空间下完全指定的FEC编码ID 4分配给“LDPC三角码”。
Section 5.5 is derived from an earlier document, and we would like to thank S. Peltotalo and J. Peltotalo for their contribution. We would also like to thank Pascal Moniot, Laurent Fazio, Mathieu Cunche, Aurelien Francillon, Shao Wenjian, Magnus Westerlund, Brian Carpenter, Tim Polk, Jari Arkko, Chris Newman, Robin Whittle, and Alfred Hoenes for their comments.
第5.5节源自先前的文件，我们要感谢S.Peltotalo和J.Peltotalo的贡献。我们还要感谢帕斯卡·莫尼奥特、劳伦特·法齐奥、马修·坎切、奥雷林·弗朗西隆、邵文建、马格努斯·韦斯特隆德、布赖恩·卡彭特、蒂姆·波尔克、贾里·阿尔科、克里斯·纽曼、罗宾·惠特尔和阿尔弗雷德·霍恩斯的评论。
Last but not least, the authors are grateful to Radford M. Neal (University of Toronto) whose LDPC software (http://www.cs.toronto.edu/~radford/ldpc.software.html) inspired this work.
最后但并非最不重要的是，作者感谢Radford M.Neal（多伦多大学）的LDPC软件(http://www.cs.toronto.edu/~radford/ldpc.software.html）启发了这项工作。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 2119，BCP 14，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月。
[ZP74] Zyablov, V. and M. Pinsker, "Decoding Complexity of Low-Density Codes for Transmission in a Channel with Erasures", Translated from Problemy Peredachi Informatsii, Vol.10, No. 1, pp.15-28, January-March 1974.
[ZP74]Zyablov，V.和M.Pinsker，“在具有擦除的信道中传输的低密度码的解码复杂性”，翻译自Problemy Peredachi Informatsii，第10卷，第1期，第15-28页，1974年1月至3月。
[RN04] Roca, V. and C. Neumann, "Design, Evaluation and Comparison of Four Large Block FEC Codecs: LDPC, LDGM, LDGM-Staircase and LDGM-Triangle, Plus a Reed-Solomon Small Block FEC Codec", INRIA Research Report RR-5225, June 2004.
[RN04]Roca，V.和C.Neumann，“四种大块FEC编解码器的设计、评估和比较：LDPC、LDGM、LDGM楼梯和LDGM三角形，以及里德-所罗门小块FEC编解码器”，INRIA研究报告RR-5225，2004年6月。
[NRFF05] Neumann, C., Roca, V., Francillon, A., and D. Furodet, "Impacts of Packet Scheduling and Packet Loss Distribution on FEC Performances: Observations and Recommendations", ACM CoNEXT'05 Conference, Toulouse, France (an extended version is available as INRIA Research Report RR-5578), October 2005.
[NRFF05]Neumann，C.，Roca，V.，Francillon，A.，和D.Furodet，“数据包调度和数据包丢失分布对FEC性能的影响：观察和建议”，ACM CoNEXT'05会议，法国图卢兹（扩展版见INRIA研究报告RR-5578），2005年10月。
[CR08] Cunche, M. and V. Roca, "Improving the Decoding of LDPC Codes for the Packet Erasure Channel with a Hybrid Zyablov Iterative Decoding/Gaussian Elimination Scheme", INRIA Research Report RR-6473, March 2008.
[CR08]Cunche，M.和V.Roca，“使用混合Zyablov迭代解码/高斯消除方案改进分组擦除信道LDPC码的解码”，INRIA研究报告RR-6473，2008年3月。
[LDPC-codec] Roca, V., Neumann, C., Cunche, M., and J. Laboure, "LDPC-Staircase/LDPC-Triangle Codec Reference Implementation", INRIA Rhone-Alpes and STMicroelectronics, <http://planete-bcast.inrialpes.fr/>.
[LDPC编解码器]Roca，V.，Neumann，C.，Cunche，M.，和J.Laboure，“LDPC楼梯/LDPC三角形编解码器参考实现”，INRIA Rhone Alpes和意法半导体公司<http://planete-bcast.inrialpes.fr/>.
[MK03] MacKay, D., "Information Theory, Inference and Learning Algorithms", Cambridge University Press, ISBN: 0-521-64298-1, 2003.
[MK03]MacKay，D.，“信息论、推理和学习算法”，剑桥大学出版社，ISBN:0-521-64298-12003年。
[PM88] Park, S. and K. Miller, "Random Number Generators: Good Ones are Hard to Find", Communications of the ACM, Vol. 31, No. 10, pp.1192-1201, 1988.
[PM88]Park，S.和K.Miller，“随机数生成器：很难找到好的”，ACM通讯，第31卷，第10期，第1192-12011988页。
[CA90] Carta, D., "Two Fast Implementations of the Minimal Standard Random Number Generator", Communications of the ACM, Vol. 33, No. 1, pp.87-88, January 1990.
[CA90]Carta，D.，“最小标准随机数发生器的两种快速实现”，《ACM通讯》，第33卷，第1期，第87-88页，1990年1月。
[WI08] Whittle, R., "Park-Miller-Carta Pseudo-Random Number Generator", January 2008, <http://www.firstpr.com.au/dsp/rand31/>.
[WI08]Whittle，R.，“Park Miller Carta伪随机数生成器”，2008年1月<http://www.firstpr.com.au/dsp/rand31/>.
[rand31pmc] Whittle, R., "31 bit pseudo-random number generator", September 2005, <http://www.firstpr.com.au/dsp/rand31/ rand31-park-miller-carta.cc.txt>.
[rand31pmc]Whittle，R.，“31位伪随机数发生器”，2005年9月<http://www.firstpr.com.au/dsp/rand31/ rand31 park miller carta.cc.txt>。
[PTVF92] Press, W., Teukolsky, S., Vetterling, W., and B. Flannery, "Numerical Recipes in C; Second Edition", Cambridge University Press, ISBN: 0-521-43108-5, 1992.
[PTVF92]出版社，W.，Teukolsky，S.，Vetterling，W.，和B.Flannery，“C中的数字配方；第二版”，剑桥大学出版社，ISBN:0-521-43108-51992。
[RMT-PI-ALC] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", Work in Progress, November 2007.
[RMT-PI-ALC]Luby，M.，Watson，M.，和L.Vicisano，“异步分层编码（ALC）协议实例化”，正在进行的工作，2007年11月。
[RMT-PI-NORM] Adamson, B., Bormann, C., Handley, M., and J. Macker, "Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol", Work in Progress, January 2008.
[RMT-PI-NORM]Adamson，B.，Bormann，C.，Handley，M.，和J.Macker，“面向否定确认（NACK）的可靠多播（NORM）协议”，正在进行的工作，2008年1月。
[RMT-FLUTE] Paila, T., Walsh, R., Luby, M., Lehtonen, R., and V. Roca, "FLUTE - File Delivery over Unidirectional Transport", Work in Progress, October 2007.
[RMT-FLUTE]Paila，T.，Walsh，R.，Luby，M.，Lehtonen，R.，和V.Roca，“长笛-单向传输上的文件交付”，在建工程，2007年10月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC2104] "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]“HMAC：用于消息认证的键控哈希”，RFC2104，1997年2月。
[RFC4082] "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005.
[RFC4082]“定时高效流丢失容忍认证（TESLA）：多播源认证转换介绍”，RFC 40822005年6月。
[RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[RFC3275]Eastlake，D.，Reagle，J.，和D.Solo，“（可扩展标记语言）XML签名语法和处理”，RFC3275，2002年3月。
[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月。
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[RFC3852]Housley，R.，“加密消息语法（CMS）”，RFC3852，2004年7月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月。
Appendix A. Trivial Decoding Algorithm (Informative Only)
附录A.普通解码算法（仅供参考）
A trivial decoding algorithm is sketched below (please see [LDPC-codec] for the details omitted here):
下面是一个简单的解码算法（这里省略的细节请参见[LDPC codec]）：
Initialization: allocate a table partial_sum[n-k] of buffers, each buffer being of size the symbol size. There's one entry per equation since the buffers are meant to store the partial sum of each equation; Reset all the buffers to zero;
初始化：分配缓冲区的表部分和[n-k]，每个缓冲区的大小为符号大小。每个方程有一个条目，因为缓冲区用于存储每个方程的部分和；将所有缓冲区重置为零；
/*
* For each newly received or decoded symbol, try to make progress
* in the decoding of the associated source block.
* NB: in case of a symbol group (G>1), this function is called for
* each symbol of the received packet.
* NB: a callback function indicates to the caller that new symbol(s)
* has(have) been decoded.
* new_esi (IN): ESI of the new symbol received or decoded
* new_symb (IN): Buffer of the new symbol received or decoded
*/
void
decoding_step(ESI_t new_esi,
symbol_t *new_symb)
{
If (new_symb is an already decoded or received symbol) {
Return; /* don't waste time with this symbol */
}
/*
* For each newly received or decoded symbol, try to make progress
* in the decoding of the associated source block.
* NB: in case of a symbol group (G>1), this function is called for
* each symbol of the received packet.
* NB: a callback function indicates to the caller that new symbol(s)
* has(have) been decoded.
* new_esi (IN): ESI of the new symbol received or decoded
* new_symb (IN): Buffer of the new symbol received or decoded
*/
void
decoding_step(ESI_t new_esi,
symbol_t *new_symb)
{
If (new_symb is an already decoded or received symbol) {
Return; /* don't waste time with this symbol */
}
If (new_symb is the last missing source symbol) {
Remember that decoding is finished;
Return; /* work is over now... */
}
If (new_symb is the last missing source symbol) {
Remember that decoding is finished;
Return; /* work is over now... */
}
Create an empty list of equations having symbols decoded during this decoding step;
创建具有在此解码步骤中解码的符号的等式的空列表；
/*
* First add this new symbol to the partial sum of all the
* equations where the symbol appears.
*/
For (each equation eq in which new_symb is a variable and
having more than one unknown variable) {
/*
* First add this new symbol to the partial sum of all the
* equations where the symbol appears.
*/
For (each equation eq in which new_symb is a variable and
having more than one unknown variable) {
Add new_symb to partial_sum[eq];
将新符号添加到部分和[eq]；
Remove entry(eq, new_esi) from the H matrix;
从H矩阵中删除条目（eq，新的_esi）；
If (the new degree of equation eq == 1) {
/* a new symbol can be decoded, remember the
* equation */
Append eq to the list of equations having symbols
decoded during this decoding step;
}
}
If (the new degree of equation eq == 1) {
/* a new symbol can be decoded, remember the
* equation */
Append eq to the list of equations having symbols
decoded during this decoding step;
}
}
/*
* Then finish with recursive calls to decoding_step() for each
* newly decoded symbol.
*/
For (each equation eq in the list of equations having symbols
decoded during this decoding step) {
/*
* Then finish with recursive calls to decoding_step() for each
* newly decoded symbol.
*/
For (each equation eq in the list of equations having symbols
decoded during this decoding step) {
/*
* Because of the recursion below, we need to check that
* decoding is not finished, and that the equation is
* __still__ of degree 1
*/
If (decoding is finished) {
break; /* exit from the loop */
}
/*
* Because of the recursion below, we need to check that
* decoding is not finished, and that the equation is
* __still__ of degree 1
*/
If (decoding is finished) {
break; /* exit from the loop */
}
If ((degree of equation eq == 1) {
Let dec_esi be the ESI of the newly decoded symbol in
equation eq;
If ((degree of equation eq == 1) {
Let dec_esi be the ESI of the newly decoded symbol in
equation eq;
Remove entry(eq, dec_esi);
删除条目（eq，dec_esi）；
Allocate a buffer, dec_symb, for this symbol and copy partial_sum[eq] to dec_symb;
为该符号分配一个缓冲区dec_symb，并将部分和[eq]复制到dec_symb；
Inform the caller that a new symbol has been decoded via a callback function;
通过回调函数通知调用者已解码新符号；
/* finally, call this function recursively */
decoding_step(dec_esi, dec_symb);
}
}
/* finally, call this function recursively */
decoding_step(dec_esi, dec_symb);
}
}
Free the list of equations having symbols decoded;
Return;
}
Free the list of equations having symbols decoded;
Return;
}
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/
Christoph Neumann Thomson 12, bd de Metz Rennes 35700 France
克里斯托夫·诺依曼·汤姆森12号，北德梅茨雷恩35700法国
EMail: christoph.neumann@thomson.net
URI: http://planete.inrialpes.fr/people/chneuman/
EMail: christoph.neumann@thomson.net
URI: http://planete.inrialpes.fr/people/chneuman/
David Furodet STMicroelectronics 12, Rue Jules Horowitz BP217 Grenoble Cedex 38019 France
David Furodet STMicroelectronics 12，Jules Horowitz街BP217格勒诺布尔Cedex 38019法国
EMail: david.furodet@st.com
URI: http://www.st.com/
EMail: david.furodet@st.com
URI: http://www.st.com/
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.