Network Working Group M. Watson
Request for Comments: 5445 Digital Fountain
Obsoletes: 3452, 3695 March 2009
Category: Standards Track
Network Working Group M. Watson
Request for Comments: 5445 Digital Fountain
Obsoletes: 3452, 3695 March 2009
Category: Standards Track
Basic Forward Error Correction (FEC) Schemes
基本前向纠错（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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
This document provides Forward Error Correction (FEC) Scheme specifications according to the Reliable Multicast Transport (RMT) FEC building block for the Compact No-Code FEC Scheme, the Small Block, Large Block, and Expandable FEC Scheme, the Small Block Systematic FEC Scheme, and the Compact FEC Scheme. This document obsoletes RFC 3695 and assumes responsibility for the FEC Schemes defined in RFC 3452.
本文档根据可靠多播传输（RMT）FEC构建块提供了前向纠错（FEC）方案规范，用于紧凑无码FEC方案、小块、大块和可扩展FEC方案、小块系统FEC方案和紧凑FEC方案。本文件废除RFC 3695，并对RFC 3452中定义的FEC方案负责。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Compact No-Code FEC Scheme . . . . . . . . . . . . . . . . . . 4
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 4
3.2.1. FEC Payload ID(s) . . . . . . . . . . . . . . . . . . 4
3.2.2. FEC Object Transmission Information . . . . . . . . . 5
3.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 7
3.4.1. Source Block Logistics . . . . . . . . . . . . . . . . 7
3.4.2. Sending and Receiving a Source Block . . . . . . . . . 8
4. Small Block, Large Block, and Expandable FEC Scheme . . . . . 9
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 9
4.2.1. FEC Payload ID(s) . . . . . . . . . . . . . . . . . . 9
4.2.2. FEC Object Transmission Information . . . . . . . . . 10
4.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 12
5. Small Block Systematic FEC Scheme . . . . . . . . . . . . . . 12
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 12
5.2.1. FEC Payload ID(s) . . . . . . . . . . . . . . . . . . 12
5.2.2. FEC Object Transmission Information . . . . . . . . . 13
5.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 14
5.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 15
6. Compact FEC Scheme . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 15
6.2.1. FEC Payload ID(s) . . . . . . . . . . . . . . . . . . 15
6.2.2. FEC Object Transmission Information . . . . . . . . . 15
6.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 15
6.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Changes from Schemes Defined in RFC 3452 and RFC 3695 . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Compact No-Code FEC Scheme . . . . . . . . . . . . . . . . . . 4
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 4
3.2.1. FEC Payload ID(s) . . . . . . . . . . . . . . . . . . 4
3.2.2. FEC Object Transmission Information . . . . . . . . . 5
3.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 7
3.4.1. Source Block Logistics . . . . . . . . . . . . . . . . 7
3.4.2. Sending and Receiving a Source Block . . . . . . . . . 8
4. Small Block, Large Block, and Expandable FEC Scheme . . . . . 9
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 9
4.2.1. FEC Payload ID(s) . . . . . . . . . . . . . . . . . . 9
4.2.2. FEC Object Transmission Information . . . . . . . . . 10
4.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 12
5. Small Block Systematic FEC Scheme . . . . . . . . . . . . . . 12
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 12
5.2.1. FEC Payload ID(s) . . . . . . . . . . . . . . . . . . 12
5.2.2. FEC Object Transmission Information . . . . . . . . . 13
5.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 14
5.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 15
6. Compact FEC Scheme . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 15
6.2.1. FEC Payload ID(s) . . . . . . . . . . . . . . . . . . 15
6.2.2. FEC Object Transmission Information . . . . . . . . . 15
6.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 15
6.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Changes from Schemes Defined in RFC 3452 and RFC 3695 . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . . 18
The document specifies the following FEC Schemes according to the specification requirements of the FEC building block [RFC5052]:
本文件根据FEC构建块[RFC5052]的规范要求规定了以下FEC方案：
o Compact No-Code FEC Scheme
o 紧凑无码FEC方案
o Small Block, Large Block, and Expandable FEC Scheme
o 小分组、大分组和可扩展FEC方案
o Small Block Systematic FEC Scheme
o 小分组系统FEC方案
o Compact FEC Scheme
o 紧凑FEC方案
This document inherits the context, language, declarations and restrictions of the FEC building block [RFC5052]. This document also uses the terminology of the companion document [RFC3453], which describes the use of FEC codes within the context of reliable IP multicast transport and provides an introduction to some commonly used FEC codes.
本文档继承了FEC构建块[RFC5052]的上下文、语言、声明和限制。本文件还使用了配套文件[RFC3453]的术语，该文件描述了在可靠IP多播传输环境下FEC代码的使用，并介绍了一些常用的FEC代码。
Building blocks are defined in [RFC3048]. This document follows the general guidelines provided in [RFC3269].
[RFC3048]中定义了构建块。本文件遵循[RFC3269]中提供的一般指南。
[RFC3452] and [RFC3695] contain previous versions of the FEC Schemes defined in this specification. These RFCs were published in the "Experimental" category. It was the stated intent of the RMT working group to re-submit these specifications as an IETF Proposed Standard in due course. This document obsoletes [RFC3695]. [RFC3452] has already been obsoleted by [RFC5052], and this document assumes responsibility for aspects of [RFC3452] that were not included in [RFC5052].
[RFC3452]和[RFC3695]包含本规范中定义的FEC方案的早期版本。这些RFC以“实验”类别发表。RMT工作组声明的意图是在适当的时候将这些规范重新提交为IETF提议的标准。本文件废除了[RFC3695]。[RFC3452]已被[RFC5052]淘汰，本文件对[RFC3452]中未包含的方面承担责任。
This Proposed Standard specification is thus based on and backwards compatible with the FEC Schemes defined in [RFC3452] and [RFC3695], updated according to accumulated experience and growing protocol maturity since their original publication. Said experience applies both to this specification itself and to congestion control strategies related to the use of this specification.
因此，本拟议标准规范基于[RFC3452]和[RFC3695]中定义的FEC方案，并与之向后兼容，该方案根据积累的经验和自最初发布以来不断增长的协议成熟度进行更新。上述经验既适用于本规范本身，也适用于与本规范使用相关的拥塞控制策略。
The differences between the FEC Scheme specifications in [RFC3452] and [RFC3695] and this document are listed in Section 10.
第10节列出了[RFC3452]和[RFC3695]中FEC方案规范与本文件之间的差异。
Integer fields specified in this document are all encoded in network byte order.
本文档中指定的整数字段均按网络字节顺序编码。
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]中所述进行解释。
The Compact No-code FEC Scheme is a Fully-Specified FEC Scheme. The scheme requires no FEC coding and is specified primarily to allow simple interoperability testing between different implementations of protocol instantiations that use the FEC building block.
紧凑型无码FEC方案是一种完全指定的FEC方案。该方案不需要FEC编码，主要用于允许在使用FEC构建块的协议实例化的不同实现之间进行简单的互操作性测试。
The FEC Payload ID for the Compact No-Code FEC Scheme is composed of a Source Block Number and an Encoding Symbol ID as shown in Figure 1.
紧凑无码FEC方案的FEC有效负载ID由源块号和编码符号ID组成，如图1所示。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: FEC Payload ID Format for Compact No-Code FEC Scheme
图1：紧凑无码FEC方案的FEC有效负载ID格式
The Source Block Number (SBN) is a 16-bit unsigned integer that is used to identify from which source block of the object the encoding symbol in the payload of the packet is generated. There are two possible modes: in the unique SBN mode, each source block within the object has a unique Source Block Number associated with it, and in the non-unique SBN mode, the same Source Block Number may be used for more than one source block within the object. Which mode is being used for an object is outside the scope of this document and MUST be communicated, either explicitly or implicitly, out-of-band to receivers.
源块号（SBN）是一个16位无符号整数，用于标识从对象的哪个源块生成数据包有效负载中的编码符号。有两种可能的模式：在唯一SBN模式下，对象内的每个源块都有一个与之关联的唯一源块编号；在非唯一SBN模式下，同一源块编号可用于对象内的多个源块。对象使用的模式不在本文档的范围内，必须显式或隐式地在带外与接收者进行通信。
If the unique SBN mode is used, then successive Source Block Numbers are associated with consecutive source blocks of the object starting with Source Block Number 0 for the first source block of the object. In this case, there are at most 2^^16 source blocks in the object.
如果使用唯一SBN模式，则连续源块编号与对象的连续源块相关联，从对象的第一个源块的源块编号0开始。在这种情况下，对象中最多有2^^16个源块。
If the non-unique SBN mode is used, then the mapping from source blocks to Source Block Numbers MUST be communicated out-of-band to receivers, and how this is done is outside the scope of this document. This mapping could be implicit, for example, determined by the transmission order of the source blocks. In non-unique SBN mode, packets for two different source blocks mapped to the same Source Block Number SHOULD NOT be sent within an interval of time that is shorter than the transport time of a source block. The transport time of a source block includes the amount of time needed to process the source block at the sender transport layer, the network transit time for packets, and the amount of time needed to process the source block at the receiver transport. This allows the receiver to clearly decide which packets belong to which source block.
如果使用非唯一SBN模式，则从源块到源块编号的映射必须在带外传达给接收机，如何实现这一点超出了本文件的范围。该映射可以是隐式的，例如，由源块的传输顺序确定。在非唯一SBN模式下，映射到相同源块编号的两个不同源块的数据包不应在短于源块传输时间的时间间隔内发送。源块的传输时间包括在发送方传输层处理源块所需的时间量、分组的网络传输时间以及在接收方传输层处理源块所需的时间量。这允许接收器清楚地决定哪些数据包属于哪个源块。
The Encoding Symbol ID is a 16-bit unsigned integer that identifies which specific encoding symbol generated from the source block is carried in the packet payload. The exact details of the correspondence between Encoding Symbol IDs and the encoding symbols in the packet payload are specified in Section 3.4.
编码符号ID是一个16位无符号整数，用于标识从源块生成的特定编码符号在数据包有效负载中携带。第3.4节规定了编码符号ID和数据包有效载荷中编码符号之间对应关系的确切细节。
The mandatory FEC Object Transmission Information element for the Compact No-Code FEC Scheme is:
紧凑型无码FEC方案的强制FEC对象传输信息元素为：
o FEC Encoding ID: zero (0)
o FEC编码ID:零（0）
The Common FEC Object Transmission Information elements and their value ranges for the Compact No-Code FEC Scheme are:
紧凑型无码FEC方案的公共FEC对象传输信息元素及其值范围为：
Transfer-Length: a non-negative integer, less than 2^^48, indicating the length of the object in octets.
传输长度：一个非负整数，小于2^^48，以八位字节表示对象的长度。
Encoding-Symbol-Length: a non-negative integer, less than 2^^16, indicating the length of each encoding symbol in octets.
编码符号长度：一个非负整数，小于2^^16，以八位字节表示每个编码符号的长度。
Maximum-Source-Block-Length: a non-negative integer, less than 2^^32, indicating the maximum number of source symbols in a source block.
最大源块长度：非负整数，小于2^^32，表示源块中源符号的最大数量。
The encoded Common FEC Object Transmission Information is defined in Figure 2.
图2中定义了编码的公共FEC对象传输信息。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transfer Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol Length | Max. Source Block Length (MSB)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max. Source Block Length (LSB)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transfer Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol Length | Max. Source Block Length (MSB)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max. Source Block Length (LSB)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Encoded Common FEC Object Transmission Information (OTI) for Compact No-Code FEC Scheme
图2：紧凑无码FEC方案的编码公共FEC对象传输信息（OTI）
The Transfer Length, Encoding Symbol Length, and Maximum Source Block Length are encoded as unsigned integers, of length 48 bits, 16 bits, and 32 bits, respectively.
传输长度、编码符号长度和最大源块长度分别编码为长度为48位、16位和32位的无符号整数。
All Encoding Symbols of a transport object MUST have length equal to the length specified in the Encoding Symbol Length element, with the optional exception of the last source symbol of the last source block (so that redundant padding is not mandatory in this last symbol). This last source symbol MUST be logically padded out with zeroes when another Encoding Symbol is computed based on this source symbol to ensure the same interpretation of this Encoding Symbol value by the sender and receiver. However, this padding does not actually need to be sent with the data of the last source symbol.
传输对象的所有编码符号的长度必须等于编码符号长度元素中指定的长度，但最后一个源块的最后一个源符号除外（因此，在最后一个符号中，冗余填充不是必需的）。当基于此源符号计算另一个编码符号时，最后一个源符号必须在逻辑上用零填充，以确保发送方和接收方对此编码符号值的解释相同。但是，这个填充实际上不需要与最后一个源符号的数据一起发送。
The "Reserved" field in the Encoded FEC Object Transmission Information MUST be set to zero by senders and its value MUST be ignored by receivers.
发送方必须将编码的FEC对象传输信息中的“保留”字段设置为零，接收方必须忽略其值。
Note: this FEC Scheme was first defined in [RFC3695], which did not require that the Encoding Symbol Length should be the same for every source block. This document introduces a general requirement that the Encoding Symbol Length be the same across source blocks. Since no protocols were defined that support variation in the Encoding Symbol Length between source blocks, this can be done without introducing backwards compatibility issues.
注：此FEC方案首先在[RFC3695]中定义，它不要求每个源块的编码符号长度都相同。本文档介绍了编码符号长度在源块之间相同的一般要求。由于没有定义支持源块之间编码符号长度变化的协议，因此可以在不引入向后兼容性问题的情况下实现这一点。
No Scheme-Specific FEC Object Transmission Information elements are defined by this FEC Scheme.
此FEC方案未定义特定于方案的FEC对象传输信息元素。
The algorithm defined in Section 9.1. of [RFC5052] MUST be used to partition the file into source blocks.
第9.1节中定义的算法。必须使用[RFC5052]将文件划分为源块。
The Compact No-Code FEC Scheme does not require FEC encoding or decoding. Instead, each encoding symbol consists of consecutive bytes of a source block of the object.
紧凑的无码FEC方案不需要FEC编码或解码。相反，每个编码符号由对象的源块的连续字节组成。
The following two subsections describe the details of how the Compact No-Code FEC Scheme operates for each source block of an object.
以下两小节详细介绍了紧凑型无代码FEC方案如何对对象的每个源块进行操作。
Let X > 0 be the length of a source block in bytes. Let L > 0 be the length of the encoding symbol contained in the payload of each packet. The value of X and L are part of the FEC Object Transmission Information, and how this information is communicated to a receiver is outside the scope of this document.
设X>0为源块的长度（以字节为单位）。设L>0为每个数据包的有效载荷中包含的编码符号的长度。X和L的值是FEC对象传输信息的一部分，并且如何将该信息传递给接收机不在本文档的范围内。
For a given source block X bytes in length with Source Block Number I, let N = X/L rounded up to the nearest integer. The encoding symbol carried in the payload of a packet consists of a consecutive portion of the source block. The source block is logically partitioned into N encoding symbols, each L bytes in length, and the corresponding Encoding Symbol IDs range from 0 through N-1 starting at the beginning of the source block and proceeding to the end. Thus, the encoding symbol with Encoding Symbol ID Y consists of bytes L*Y through L*(Y+1)-1 of the source block, where the bytes of the source block are numbered from 0 through X-1. If X/L is not integral then the last encoding symbol with Encoding Symbol ID = N-1 consists of bytes L*(N-1) through the last byte X-1 of the source block, and the remaining L*N - X bytes of the encoding symbol can by padded out with zeroes.
对于给定的源块，长度为X字节，源块编号为I，让N=X/L向上舍入到最接近的整数。包的有效载荷中携带的编码符号由源块的连续部分组成。源块在逻辑上被划分为N个编码符号，每个编码符号的长度为L个字节，相应的编码符号ID的范围从0到N-1，从源块的开始一直到结束。因此，编码符号ID为Y的编码符号由源块的字节L*Y到L*（Y+1）-1组成，其中源块的字节从0到X-1进行编号。如果X/L不是整数，则编码符号ID=N-1的最后一个编码符号由从源块的最后一个字节X-1到L*（N-1）的字节组成，编码符号的剩余L*N-X字节可以用零填充。
As an example, suppose that the source block length X = 20,400 and encoding symbol length L = 1,000. The encoding symbol with Encoding Symbol ID = 10 contains bytes 10,000 through 10,999 of the source block, and the encoding symbol with Encoding Symbol ID = 20 contains bytes 20,000 through the last byte 20,399 of the source block and the remaining 600 bytes of the encoding symbol can be padded with zeroes.
例如，假设源块长度X=20400，编码符号长度L=1000。编码符号ID=10的编码符号包含源块的字节10000到10999，编码符号ID=20的编码符号包含源块的最后一个字节20399到20000的字节，编码符号的剩余600字节可以用零填充。
There are no restrictions beyond the rules stated above on how a sender generates encoding symbols to send from a source block. However, it is recommended that an implementor refer to the companion document [RFC3452] for general advice.
对于发送方如何生成编码符号以从源块发送，没有超出上述规则的限制。但是，建议实施者参考配套文件[RFC3452]以获取一般建议。
In the next subsection, a procedure is recommended for sending and receiving source blocks.
在下一小节中，建议使用发送和接收源块的过程。
The following carousel procedure is RECOMMENDED for a sender to generate packets containing FEC Payload IDs and corresponding encoding symbols for a source block with Source Block Number I. Set the length in bytes of an encoding symbol to a fixed value L, which is reasonable for a packet payload (e.g., ensure that the total packet size does not exceed the MTU) and that is smaller than the source block length X, e.g., L = 1,000 for X >= 1,000. Initialize Y to a value randomly chosen in the interval [0..N-1]. Repeat the following for each packet of the source block to be sent.
建议发送方使用以下转盘程序为源块编号为I的源块生成包含FEC有效负载ID和相应编码符号的数据包。将编码符号的字节长度设置为固定值L，这对于数据包有效负载来说是合理的（例如，确保总数据包大小不超过MTU）且小于源块长度X，例如，对于X>=1000，L=1000。将Y初始化为在间隔[0..N-1]中随机选择的值。对要发送的源块的每个数据包重复以下操作。
o If Y <= N-1, then generate the encoding symbol Y.
o 如果Y<=N-1，则生成编码符号Y。
o Within the FEC Payload ID, set the Source Block Length to X, set the Source Block Number = I, set the Encoding Symbol ID = Y, place the FEC Payload ID and the encoding symbol into the packet to send.
o 在FEC有效负载ID内，将源块长度设置为X，将源块编号设置为I，将编码符号ID设置为Y，将FEC有效负载ID和编码符号放入要发送的数据包中。
o In preparation for the generation of the next packet: if Y < N-1 then increment Y by one else if Y = N-1 then reset Y to zero.
o 为生成下一个数据包做准备：如果Y<N-1，则增加Y，如果Y=N-1，则将Y重置为零。
The following procedure is RECOMMENDED for a receiver to recover the source block based on receiving packets for the source block from a sender that is using the carousel procedure described above. The receiver can determine from which source block a received packet was generated by the Source Block Number carried in the FEC Payload ID. Upon receipt of the first FEC Payload ID for a source block, the receiver uses the Source Block Length and Encoding Symbol Length received out-of-band as part of the FEC Object Transmission Information to determine the length X in bytes of the source block and length L in bytes of each encoding symbol. The receiver allocates space for the X bytes that the source block requires. The receiver also computes the length of the encoding symbol in the payload of the packet by subtracting the packet header length from the total length of the received packet. The receiver checks that this symbol length is equal to L, except in the case that this is the last symbol of the source block in which case the symbol length in the packet may be less than L. After calculating N = X/L rounded up to the nearest integer, the receiver allocates a boolean array RECEIVED[0..N-1] with all N entries initialized to false to track received encoding symbols. The receiver keeps receiving packets for the source block as long as there is at least one entry in RECEIVED still set to false or until the application decides to give up on this source block and move on to other source blocks. For each
建议接收方根据从使用上述转盘过程的发送方接收源块的数据包来恢复源块的以下过程。接收器可通过FEC有效载荷ID中携带的源块编号确定从哪个源块生成接收到的分组。在接收到源块的第一个FEC有效载荷ID时，接收机使用带外接收的源块长度和编码符号长度作为FEC对象传输信息的一部分来确定源块的长度X（以字节为单位）和每个编码符号的长度L（以字节为单位）。接收器为源块所需的X字节分配空间。接收机还通过从接收到的分组的总长度减去分组报头长度来计算分组的有效载荷中的编码符号的长度。接收机检查该符号长度是否等于L，除非这是源块的最后一个符号，在这种情况下，数据包中的符号长度可能小于L。在计算N=X/L四舍五入到最接近的整数后，接收机分配接收到的布尔数组[0..N-1]将所有N个条目初始化为false以跟踪接收到的编码符号。只要RECEIVED中至少有一个条目仍然设置为false，或者直到应用程序决定放弃此源块并转移到其他源块，接收器就会继续接收源块的数据包。每人
received packet for the source block (including the first packet), the steps to be taken to help recover the source block are as follows. Let Y be the value of the Encoding Symbol ID within the FEC Payload ID of the packet. If Y <= N-1, then the receiver copies the encoding symbol into the appropriate place within the space reserved for the source block and sets RECEIVED[Y] = true. If all N entries of RECEIVED are true, then the receiver has recovered the entire source block.
接收到源块的数据包（包括第一个数据包），帮助恢复源块的步骤如下。设Y为分组的FEC有效载荷ID内的编码符号ID的值。如果Y<=N-1，则接收器将编码符号复制到为源块保留的空间内的适当位置，并将接收到的[Y]=true。如果接收的所有N个条目均为真，则接收器已恢复整个源块。
This section defines an Under-Specified FEC Scheme for Small Block FEC codes, Large Block FEC codes, and Expandable FEC codes as described in [RFC3453].
本节定义了[RFC3453]中所述的适用于小分组FEC码、大分组FEC码和可扩展FEC码的欠指定FEC方案。
The FEC Payload ID is composed of a Source Block Number and an Encoding Symbol ID structured as shown in Figure 3.
FEC有效负载ID由源块号和编码符号ID组成，其结构如图3所示。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: FEC Payload ID Format for Small Block, Large Block, and Expandable FEC Codes
图3：小数据块、大数据块和可扩展FEC代码的FEC有效负载ID格式
The Source Block Number is a 32-bit unsigned integer that identifies from which source block of the object the encoding symbol(s) in the payload are generated. These blocks are numbered consecutively from 0 to N-1, where N is the number of source blocks in the object.
源块编号是一个32位无符号整数，用于标识有效负载中的编码符号是从对象的哪个源块生成的。这些块从0到N-1连续编号，其中N是对象中源块的数量。
The Encoding Symbol ID is a 32-bit unsigned integer that identifies which specific encoding symbol(s) generated from the source block are carried in the packet payload. The exact details of the correspondence between Encoding Symbol IDs and the encoding symbol(s) in the packet payload are dependent on the particular FEC Scheme instance used as identified by the FEC Encoding ID and by the FEC Instance ID, and these details may be proprietary.
编码符号ID是一个32位无符号整数，用于标识从源块生成的哪些特定编码符号在数据包有效负载中携带。分组有效载荷中的编码符号ID和编码符号之间的对应关系的确切细节取决于由FEC编码ID和FEC实例ID标识的使用的特定FEC方案实例，并且这些细节可以是专有的。
The mandatory FEC Object Transmission Information element for the Small Block, Large Block, and Expandable FEC Scheme are:
小块、大块和可扩展FEC方案的强制FEC对象传输信息元素为：
o FEC Encoding ID: 128
o FEC编码ID:128
The Common FEC Object Transmission Information elements and their value ranges for the Small Block, Large Block, and Expandable FEC Scheme are:
小块、大块和可扩展FEC方案的常见FEC对象传输信息元素及其值范围为：
FEC Instance ID: a non-negative integer less than 2^^16.
FEC实例ID:小于2^^16的非负整数。
Transfer-Length: a non-negative integer less than 2^^48, indicating the length of the object in octets.
传输长度：小于2^^48的非负整数，以八位字节表示对象的长度。
Encoding-Symbol-Length: a non-negative integer less than 2^^16, indicating the length of each encoding symbol in octets.
编码符号长度：小于2^^16的非负整数，以八位字节表示每个编码符号的长度。
Maximum-Source-Block-Length: a non-negative integer less than 2^^32, indicating the maximum number of source symbols in a source block.
最大源块长度：小于2^^32的非负整数，表示源块中源符号的最大数量。
The encoded Common FEC Object Transmission Information is defined in Figure 4.
编码的公共FEC对象传输信息如图4所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transfer Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | FEC Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol Length | Max. Source Block Length (MSB)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max. Source Block Length (LSB)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transfer Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | FEC Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol Length | Max. Source Block Length (MSB)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max. Source Block Length (LSB)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Encoded Common FEC OTI for Small Block, Large Block, and Expandable FEC Scheme
图4：用于小数据块、大数据块和可扩展FEC方案的编码公共FEC OTI
The Transfer Length (48 bits), FEC Instance ID (16 bits), Encoding Symbol Length (16 bits), and Maximum Source Block Length (32 bits) are encoded as unsigned integers.
传输长度（48位）、FEC实例ID（16位）、编码符号长度（16位）和最大源块长度（32位）被编码为无符号整数。
The Scheme-Specific FEC Object Transmission Information field for the Small Block, Large Block, and Expandable FEC Scheme provides for the possibility of Instance-specific FEC Object Transmission Information. The format of the Scheme-Specific FEC Object Transmission Information for this FEC Scheme is defined in Figure 5.
针对小块、大块和可扩展FEC方案的方案特定FEC对象传输信息字段提供了实例特定FEC对象传输信息的可能性。图5中定义了该FEC方案的方案特定FEC对象传输信息的格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Instance-specific FEC OTI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Instance-specific FEC OTI contd. |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Instance-specific FEC OTI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Instance-specific FEC OTI contd. |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Encoded Scheme-Specific FEC OTI for Small Block, Large Block, and Expandable FEC Scheme
图5：用于小数据块、大数据块和可扩展FEC方案的编码方案特定FEC OTI
The Scheme-Specific FEC Object Transmission Information field contains the following sub-fields:
方案特定FEC对象传输信息字段包含以下子字段：
Length (1 octet): an unsigned integer that specifies the length of the Scheme-Specific FEC OTI in four-octet words (including this length field), except that the value zero indicates that no Instance-specific FEC OTI Information is provided. When the Length is zero, three padding bytes containing value zero SHALL follow the Length field to maintain 4-octet alignment.
长度（1个八位字节）：一个无符号整数，它以四个八位字节字（包括此长度字段）指定特定于方案的FEC OTI的长度，但值为零表示未提供特定于实例的FEC OTI信息。当长度为零时，三个包含值零的填充字节应跟随长度字段，以保持4-八位字节对齐。
Instance-specific FEC OTI Information: the contents of this field are FEC Scheme Instance-specific.
实例特定的FEC OTI信息：该字段的内容是FEC方案实例特定的。
Note that in the case of a Content Delivery protocol that supports external signaling of the total FEC Object Transmission Information length, then the Scheme-Specific FEC OTI field defined here is optional. Otherwise, this field MUST be included.
注意，在支持总FEC对象传输信息长度的外部信令的内容交付协议的情况下，这里定义的特定于方案的FEC OTI字段是可选的。否则，必须包含此字段。
The algorithm defined in Section 9.1. of [RFC5052] MUST be used to partition the file into source blocks.
第9.1节中定义的算法。必须使用[RFC5052]将文件划分为源块。
The FEC code specification and the correspondence of Encoding Symbols IDs to encoding symbols are defined by specific instances of this scheme and so are out of scope of this document.
FEC代码规范和编码符号ID与编码符号的对应关系由该方案的特定实例定义，因此不在本文档的范围内。
This section defines an Under-Specified FEC Scheme for Small Block Systematic FEC codes as described in [RFC3453]. For Small Block Systematic FEC codes, each source block is of length at most 65535 source symbols.
本节定义了[RFC3453]中所述的用于小数据块系统FEC代码的欠指定FEC方案。对于小分组系统FEC码，每个源块的长度最多为65535个源符号。
Although these codes can generally be accommodated by the FEC Encoding ID described in Section 4, a specific FEC Encoding ID is defined for Small Block Systematic FEC codes to allow more flexibility and to retain header compactness. The small source block length and small expansion factor that often characterize systematic codes may require the data source to frequently change the source block length. To allow the dynamic variation of the source block length and to communicate it to the receivers with low overhead, the block length is included in the FEC Payload ID.
尽管这些代码通常可以由第4节中描述的FEC编码ID容纳，但是为小块系统FEC代码定义了特定的FEC编码ID，以允许更大的灵活性并保持报头紧凑性。通常表征系统代码的小源块长度和小扩展因子可能要求数据源频繁更改源块长度。为了允许源块长度的动态变化并以低开销将其传送给接收机，块长度包括在FEC有效负载ID中。
The FEC Payload ID is composed of the Source Block Number, Source Block Length, and the Encoding Symbol ID structured as shown in Figure 6.
FEC有效负载ID由源块编号、源块长度和编码符号ID组成，其结构如图6所示。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length | Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length | Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: FEC Payload ID Format for Small Block Systematic FEC Scheme
图6：小数据块系统FEC方案的FEC有效负载ID格式
The Source Block Number is a 32-bit unsigned integer that identifies from which source block of the object the encoding symbol(s) in the payload are generated. These blocks are numbered consecutively from 0 to N-1, where N is the number of source blocks in the object.
源块编号是一个32位无符号整数，用于标识有效负载中的编码符号是从对象的哪个源块生成的。这些块从0到N-1连续编号，其中N是对象中源块的数量。
The Source Block Length is a 16-bit unsigned integer that specifies the length in units of source symbols of the source block identified by the Source Block Number.
源块长度是一个16位无符号整数，它以源块编号标识的源块的源符号为单位指定长度。
The Encoding Symbol ID is a 16-bit unsigned integer that identifies which specific encoding symbol(s) generated from the source block are carried in the packet payload. Each encoding symbol is either an original source symbol or a redundant symbol generated by the encoder. The exact details of the correspondence between Encoding Symbol IDs and the encoding symbol(s) in the packet payload are dependent on the particular FEC Scheme instance used as identified by the FEC Instance ID, and these details may be proprietary.
编码符号ID是一个16位无符号整数，用于标识从源块生成的哪些特定编码符号在数据包有效负载中携带。每个编码符号要么是原始源符号，要么是编码器生成的冗余符号。编码符号ID和分组有效载荷中的编码符号之间的对应关系的确切细节取决于由FEC实例ID标识的所使用的特定FEC方案实例，并且这些细节可以是专有的。
The mandatory FEC Object Transmission Information element for the Small Block Systematic FEC Scheme is:
小数据块系统FEC方案的强制FEC对象传输信息元素为：
o FEC Encoding ID: 129
o FEC编码ID:129
The Common FEC Object Transmission Information elements and their value ranges for the Small Block Systematic FEC Scheme are:
用于小块系统FEC方案的公共FEC对象传输信息元素及其值范围为：
FEC Instance ID: a non-negative integer less than 2^^16.
FEC实例ID:小于2^^16的非负整数。
Transfer-Length: a non-negative integer less than 2^^48, indicating the length of the object in octets.
传输长度：小于2^^48的非负整数，以八位字节表示对象的长度。
Encoding-Symbol-Length: a non-negative integer less than 2^^16, indicating the length of each encoding symbol in octets.
编码符号长度：小于2^^16的非负整数，以八位字节表示每个编码符号的长度。
Maximum-Source-Block-Length: a non-negative integer less than 2^^16, indicating the maximum number of source symbols in a source block.
最大源块长度：小于2^^16的非负整数，表示源块中源符号的最大数量。
Max-Number-of-Encoding-Symbols: a non-negative integer less than 2^^16, indicating the maximum number of encoding symbols per block (i.e., source plus repair symbols in the case of a systematic code).
最大编码符号数：小于2^^16的非负整数，表示每个块的最大编码符号数（即系统代码中的源加修复符号）。
The encoded Common FEC Object Transmission Information is defined in Figure 7.
编码的公共FEC对象传输信息如图7所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transfer Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | FEC Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol Length | Maximum Source Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max. Num. of Encoding Symbols |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transfer Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | FEC Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol Length | Maximum Source Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max. Num. of Encoding Symbols |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: FEC OTI Format for Small Block Systematic FEC Scheme
图7：小数据块系统FEC方案的FEC OTI格式
The Transfer Length (48 bits), FEC Instance ID (16 bits), Encoding Symbol Length (16 bits), Maximum Source Block Length (16 bits), and Maximum Number of Encoding Symbols (16 bits) are encoded as unsigned integers.
传输长度（48位）、FEC实例ID（16位）、编码符号长度（16位）、最大源块长度（16位）和最大编码符号数（16位）被编码为无符号整数。
All Encoding Symbols of a transport object MUST have length equal to the length specified in the Encoding Symbol Length field, with the optional exception of the last source symbol of the last source block (so that redundant padding is not mandatory in this last symbol). This last source symbol MUST be logically padded out with zeroes when another Encoding Symbol is computed based on this source symbol to ensure the same interpretation of this Encoding Symbol value by the sender and receiver. However, this padding need not be actually sent with the data of the last source symbol.
传输对象的所有编码符号的长度必须等于“编码符号长度”字段中指定的长度，但最后一个源块的最后一个源符号除外（因此，最后一个符号中不强制使用冗余填充）。当基于此源符号计算另一个编码符号时，最后一个源符号必须在逻辑上用零填充，以确保发送方和接收方对此编码符号值的解释相同。但是，此填充实际上不需要与最后一个源符号的数据一起发送。
Note: this FEC Scheme was first defined in [RFC3452], which did not require that the Encoding Symbol Length should be the same for every source block. However, no protocols have been defined that support variation in the Encoding Symbol Length between source blocks, and thus introduction of a general requirement that the Encoding Symbol Length be the same across source blocks (as defined here) should not cause backwards compatibility issues and will aid interoperability.
注：此FEC方案首先在[RFC3452]中定义，它不要求每个源块的编码符号长度都相同。然而，尚未定义支持源块之间编码符号长度变化的协议，因此引入了一个通用要求，即编码符号长度在源块之间（如本文所定义）相同，这不应导致向后兼容性问题，并将有助于互操作性。
The Scheme-Specific FEC Object Transmission Information format defined in Section 4.2.2.3 SHALL be used.
应使用第4.2.2.3节中定义的方案特定FEC对象传输信息格式。
The algorithm defined in Section 9.1. of [RFC5052] MAY be used to partition the file into source blocks. Otherwise, the FEC Scheme instance MUST specify the algorithm that is used.
第9.1节中定义的算法。可以使用[RFC5052]的函数将文件划分为源块。否则，FEC方案实例必须指定所使用的算法。
The FEC code specification and the correspondence of Encoding Symbols IDs to encoding symbols are defined by specific instances of this scheme and so are out of scope of this document.
FEC代码规范和编码符号ID与编码符号的对应关系由该方案的特定实例定义，因此不在本文档的范围内。
The Compact FEC Scheme is an Under-Specified FEC Scheme. This FEC Scheme is similar in spirit to the Compact No-Code FEC Scheme, except that a non-trivial FEC encoding (that is Under-Specified) may be used to generate encoding symbol(s) placed in the payload of each packet and a corresponding FEC decoder may be used to produce the source block from received packets.
紧凑FEC方案是一种欠指定的FEC方案。该FEC方案在精神上类似于紧凑的无码FEC方案，不同之处在于可以使用非平凡FEC编码（未指定）来生成放置在每个分组的有效载荷中的编码符号，并且可以使用相应的FEC解码器从接收到的分组生成源块。
The FEC Payload ID format defined in Section 3.2.1 SHALL be used.
应使用第3.2.1节中定义的FEC有效载荷ID格式。
The mandatory FEC Object Transmission Information element for the Compact No-Code FEC Scheme is:
紧凑型无码FEC方案的强制FEC对象传输信息元素为：
o FEC Encoding ID: 130
o FEC编码ID:130
The Common FEC Object Transmission Information elements and their encoding are the same as defined for the Small Block, Large Block, and Expandable FEC Scheme in Figure 4.
公共FEC对象传输信息元素及其编码与图4中为小块、大块和可扩展FEC方案定义的相同。
The Scheme-Specific FEC Object Transmission Information format defined in Section 4.2.2.3 SHALL be used.
应使用第4.2.2.3节中定义的方案特定FEC对象传输信息格式。
The algorithm defined in Section 9.1. of [RFC5052] MUST be used to partition the file into source blocks.
第9.1节中定义的算法。必须使用[RFC5052]将文件划分为源块。
The FEC code specification and the correspondence of Encoding Symbols IDs to encoding symbols are defined by specific instances of this scheme and so are out of scope of this document.
FEC代码规范和编码符号ID与编码符号的对应关系由该方案的特定实例定义，因此不在本文档的范围内。
This specification does not introduce any further security considerations beyond those described in [RFC5052].
除[RFC5052]中所述的安全注意事项外，本规范不引入任何其他安全注意事项。
This document is substantially based on [RFC3695] by Michael Luby and Lorenzo Vicisano and [RFC3452] by Michael Luby, Lorenzo Vicisano, Jim Gemmell, Luigi Rizzo, Mark Handley, and Jon Crowcroft.
本文件主要基于Michael Luby和Lorenzo Vicisano的[RFC3695]和Michael Luby、Lorenzo Vicisano、Jim Gemmell、Luigi Rizzo、Mark Handley和Jon Crowcroft的[RFC3452]。
FEC Encoding IDs 0 and 130 were first defined and registered in the ietf:rmt:fec:encoding namespace by [RFC3695]. This document updates and obsoletes the definitions from that specification. References to that specification should be replaced with references to this document.
FEC编码ID 0和130首先由[RFC3695]在ietf:rmt:FEC:Encoding命名空间中定义和注册。本文件更新并废除了该规范中的定义。对该规范的引用应替换为对本文件的引用。
FEC Encoding IDs 128 and 129 were first defined and registered in the ietf:rmt:fec:encoding namespace by [RFC3452]. This document updates and obsoletes the definitions from that specification. References to that specification should be replaced with references to this document.
FEC编码ID 128和129首先由[RFC3452]在ietf:rmt:FEC:Encoding命名空间中定义和注册。本文件更新并废除了该规范中的定义。对该规范的引用应替换为对本文件的引用。
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 0 under the ietf:rmt:fec:encoding name-space (which was previously assigned by [RFC3695], which is obsoleted by this document) to "Compact No-Code" as specified in Section 3 above.
本文件将ietf:rmt:FEC:Encoding名称空间下完全指定的FEC编码ID 0（该名称空间先前由[RFC3695]分配，本文件已废弃）分配给上文第3节中规定的“压缩无代码”。
This document assigns the Under-Specified FEC Encoding ID 128 under the ietf:rmt:fec:encoding name-space (which was previously assigned by [RFC3452]) to "Small Block, Large Block, and Please note that we have added a comma between large block and expandable throughout this document (RFC Editor style is to include a comme before the last item of a series). If you do not object, we will ask IANA to include this comma in their registry for consistency. --> Expandable FEC Codes" as specified in Section 4 above.
本文档将ietf:rmt:FEC:Encoding名称空间（之前由[RFC3452]分配）下指定的FEC编码ID 128分配给“小块，大块，请注意，我们在本文档中的大块和可扩展块之间添加了逗号（RFC编辑器样式是在系列的最后一项之前包含一个逗号）。如果您不反对，我们将要求IANA在其注册表中包含此逗号，以确保一致性。-->上文第4节中指定的“可扩展FEC代码”。
This document assigns the Under-Specified FEC Encoding ID 129 under the ietf:rmt:fec:encoding name-space (which was previously assigned by [RFC3452]) to "Small Block Systematic FEC Codes" as specified in Section 5 above.
本文件将ietf:rmt:FEC:Encoding名称空间（先前由[RFC3452]分配）下指定的FEC编码ID 129分配给上文第5节中规定的“小块系统FEC代码”。
This document assigns the Under-Specified FEC Encoding ID 130 under the ietf:rmt:fec:encoding name-space (which was previously assigned by [RFC3695], which is obsoleted by this document) to "Compact FEC" as specified in Section 6 above.
本文件将ietf:rmt:FEC:Encoding名称空间（先前由[RFC3695]分配，本文件已废弃）下未指定的FEC编码ID 130分配给上文第6节规定的“紧凑FEC”。
As FEC Encoding IDs 128, 129, and 130 are Under-Specified, "FEC Instance ID" sub-name-spaces must be established, in accordance to [RFC5052]. Hence, this document also assumes responsibility for the "FEC Instance ID" registries named.
由于未指定FEC编码ID 128、129和130，因此必须根据[RFC5052]建立“FEC实例ID”子名称空间。因此，本文档还负责名为的“FEC实例ID”注册表。
ietf:rmt:fec:encoding:instance:128, scoped by ietf:rmt:fec:
encoding = 128
ietf:rmt:fec:encoding:instance:128, scoped by ietf:rmt:fec:
encoding = 128
ietf:rmt:fec:encoding:instance:129, scoped by ietf:rmt:fec:
encoding = 129
ietf:rmt:fec:encoding:instance:129, scoped by ietf:rmt:fec:
encoding = 129
ietf:rmt:fec:encoding:instance:130, scoped by ietf:rmt:fec:
encoding = 130
ietf:rmt:fec:encoding:instance:130, scoped by ietf:rmt:fec:
encoding = 130
The values that can be assigned within these namespaces are non-negative numeric indices. Assignment requests are granted on a "First Come First Served" basis. [RFC5052] specifies additional criteria that MUST be met for the assignment within the generic ietf: rmt:fec:encoding:instance name-space. These criteria also apply to ietf:rmt:fec:encoding:instance:128, ietf:rmt:fec:encoding:instance: 129, and ietf:rmt:fec:encoding:instance:130.
可以在这些名称空间中分配的值是非负数字索引。派遣申请以“先到先得”的方式批准。[RFC5052]指定在通用ietf:rmt:fec:encoding:实例名称空间内分配必须满足的其他标准。这些标准也适用于ietf:rmt:fec:encoding:instance:128、ietf:rmt:fec:encoding:instance:129和ietf:rmt:fec:encoding:instance:130。
This section describes the changes between the Experimental versions of these FEC Scheme specifications contained in RFC 3452 [RFC3452] and RFC 3695 [RFC3695] and those defined in this specification:
本节描述了RFC 3452[RFC3452]和RFC 3695[RFC3695]中包含的这些FEC方案规范的实验版本与本规范中定义的版本之间的变化：
o Scheme definitions have been updated to meet the requirements of [RFC5052].
o 方案定义已更新，以满足[RFC5052]的要求。
o Complete encoding formats for the FEC Object Transmission Information for each scheme are defined here, instead of within content delivery protocol specifications, since the exact format depends on the FEC Scheme.
o 这里定义了每个方案的FEC对象传输信息的完整编码格式，而不是在内容交付协议规范中，因为确切的格式取决于FEC方案。
o The previous specifications for the Compact No-Code and Small Block Systematic FEC Schemes did not require that all encoding symbols of the object should have the same length. This requirement is introduced in this specification. Since no protocols have been defined that support variation of the encoding symbol length within an object this should not cause backwards compatibility issues.
o 紧凑无码和小块系统FEC方案的先前规范不要求对象的所有编码符号具有相同的长度。本规范中介绍了这一要求。由于并没有定义支持对象内编码符号长度变化的协议，所以这不会导致向后兼容性问题。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5052]Watson，M.，Luby，M.，和L.Vicisano，“前向纠错（FEC）构建块”，RFC 5052，2007年8月。
[RFC3452] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002.
[RFC3452]Luby，M.，Vicisano，L.，Gemmell，J.，Rizzo，L.，Handley，M.，和J.Crowcroft，“前向纠错（FEC）构建块”，RFC 3452，2002年12月。
[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月。
[RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
[RFC3269]Kermode，R.和L.Vicisano，“可靠多播传输（RMT）构建块和协议实例化文档的作者指南”，RFC 3269，2002年4月。
[RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S., and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.
[RFC3048]Whetten，B.，Vicisano，L.，Kermode，R.，Handley，M.，Floyd，S.，和M.Luby，“一对多批量数据传输的可靠多播传输构建块”，RFC 3048，2001年1月。
[RFC3695] Luby, M. and L. Vicisano, "Compact Forward Error Correction (FEC) Schemes", RFC 3695, February 2004.
[RFC3695]Luby，M.和L.Vicisano，“紧凑前向纠错（FEC）方案”，RFC 3695，2004年2月。
Author's Address
作者地址
Mark Watson Digital Fountain 39141 Civic Center Drive Suite 300 Fremont, CA 94538 USA
马克·沃森数字喷泉美国加利福尼亚州弗里蒙特市市中心大道300号39141室，邮编94538
EMail: mark@digitalfountain.com
EMail: mark@digitalfountain.com