Network Working Group M. Luby
Request for Comments: 3695 Digital Fountain
Category: Experimental L. Vicisano
Cisco
February 2004
Network Working Group M. Luby
Request for Comments: 3695 Digital Fountain
Category: Experimental L. Vicisano
Cisco
February 2004
Compact Forward Error Correction (FEC) Schemes
紧凑前向纠错（FEC）方案
Status of this Memo
本备忘录的状况
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
This document introduces some Forward Error Correction (FEC) schemes that supplement the FEC schemes described in RFC 3452. The primary benefits of these additional FEC schemes are that they are designed for reliable bulk delivery of large objects using a more compact FEC Payload ID, and they can be used to sequentially deliver blocks of an object of indeterminate length. Thus, they more flexibly support different delivery models with less packet header overhead.
本文介绍了一些前向纠错（FEC）方案，它们补充了RFC 3452中描述的FEC方案。这些附加FEC方案的主要优点是，它们设计用于使用更紧凑的FEC有效负载ID可靠地批量交付大型对象，并且它们可用于顺序交付长度不确定的对象块。因此，它们可以更灵活地支持不同的交付模型，同时减少数据包头开销。
This document also describes the Fully-Specified FEC scheme corresponding to FEC Encoding ID 0. This Fully-Specified FEC scheme requires no FEC coding and is introduced primarily to allow simple interoperability testing between different implementations of protocol instantiations that use the FEC building block.
本文档还描述了与FEC编码ID 0相对应的完全指定的FEC方案。这种完全指定的FEC方案不需要FEC编码，主要用于允许在使用FEC构建块的协议实例化的不同实现之间进行简单的互操作性测试。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Packet Header Fields . . . . . . . . . . . . . . . . . . . . . 3
2.1. FEC Payload ID for FEC Encoding IDs 0 and 130. . . . . . 4
2.2. Compact No-Code FEC scheme . . . . . . . . . . . . . . . 5
2.3. Compact FEC scheme . . . . . . . . . . . . . . . . . . . 5
3. Compact No-Code FEC scheme . . . . . . . . . . . . . . . . . . 6
3.1. Source Block Logistics . . . . . . . . . . . . . . . . . 7
3.2. Sending and Receiving a Source Block . . . . . . . . . . 8
4. Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Reliable Bulk Data Delivery. . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Packet Header Fields . . . . . . . . . . . . . . . . . . . . . 3
2.1. FEC Payload ID for FEC Encoding IDs 0 and 130. . . . . . 4
2.2. Compact No-Code FEC scheme . . . . . . . . . . . . . . . 5
2.3. Compact FEC scheme . . . . . . . . . . . . . . . . . . . 5
3. Compact No-Code FEC scheme . . . . . . . . . . . . . . . . . . 6
3.1. Source Block Logistics . . . . . . . . . . . . . . . . . 7
3.2. Sending and Receiving a Source Block . . . . . . . . . . 8
4. Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Reliable Bulk Data Delivery. . . . . . . . . . . . . . . 9
4.2. Block-Stream Delivery. . . . . . . . . . . . . . . . . . 10
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 12
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
4.2. Block-Stream Delivery. . . . . . . . . . . . . . . . . . 10
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 12
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
This document describes two new Forward Error Correction (FEC) schemes corresponding to FEC Encoding IDs 0 and 130 which supplement the FEC schemes corresponding to FEC Encoding IDs 128 and 129 described in the FEC Building Block [4].
本文档描述了与FEC编码ID 0和130对应的两个新的前向纠错（FEC）方案，它们补充了FEC构建块[4]中描述的与FEC编码ID 128和129对应的FEC方案。
The new FEC schemes are particularly applicable when an object is partitioned into equal-length source blocks. In this case, the source block length common to all source blocks can be communicated out-of-band, thus saving the additional overhead of carrying the source block length within the FEC Payload ID of each packet. The new FEC schemes are similar to the FEC schemes with FEC Encoding ID 128 defined in RFC 3452 [4], except that the FEC Payload ID is half as long. This is the reason that these new FEC schemes are called Compact FEC schemes.
新的FEC方案特别适用于将对象划分为等长源块的情况。在这种情况下，所有源块共有的源块长度可以在带外通信，从而节省在每个分组的FEC有效负载ID内携带源块长度的额外开销。新的FEC方案类似于RFC 3452[4]中定义的FEC编码ID为128的FEC方案，不同之处在于FEC有效负载ID为原来的一半。这就是这些新的FEC方案被称为紧凑FEC方案的原因。
The primary focus of FEC Encoding IDs 128 and 129 is to reliably deliver bulk objects of known length. The FEC schemes described in this document are designed to be used for both reliable delivery of bulk objects of known length, and for the delivery of a stream of source blocks for an object of indeterminate length. Within the block-stream delivery model, reliability guarantees can range from acknowledged reliable delivery of each block to unacknowledged enhanced-reliability delivery of time-sensitive blocks, depending on the properties of the protocol instantiation in which the FEC scheme is used. Acknowledged reliable block-stream delivery is similar in spirit to the byte-stream delivery that TCP offers, except that the unit of delivery is a block of data instead of a byte of data. In the spirit of a building block (see RFC 3048 [6]), the FEC schemes described in this document can be used to provide reliability for other service models as well.
FEC编码IDs 128和129的主要重点是可靠地传递已知长度的批量对象。本文件中描述的FEC方案设计用于可靠交付已知长度的批量对象，以及交付不确定长度对象的源块流。在块流交付模型中，可靠性保证的范围从每个块的已确认可靠交付到时间敏感块的未确认增强可靠性交付，这取决于使用FEC方案的协议实例化的属性。公认的可靠块流交付在精神上类似于TCP提供的字节流交付，只是交付单元是数据块而不是数据字节。本着构建块的精神（参见RFC 3048[6]），本文件中描述的FEC方案也可用于为其他服务模型提供可靠性。
The two new FEC Encoding IDs 0 and 130 are described in Section 2, and this supplements Section 5 of the FEC building block [4]. Section 3 of this document describes the Fully-Specified FEC scheme corresponding to the FEC Encoding ID 0. This Fully-Specified FEC
第2节描述了两个新的FEC编码ID 0和130，这是对FEC构建块[4]第5节的补充。本文档第3节描述了与FEC编码ID 0相对应的完全指定的FEC方案。这是完全指定的FEC
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构建块的协议实例化的不同实现之间进行简单的互操作性测试。
This document inherits the context, language, declarations and restrictions of the FEC building block [4]. This document also uses the terminology of the companion document [7] 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构建块的上下文、语言、声明和限制[4]。本文件还使用了配套文件[7]中的术语，该文件描述了在可靠IP多播传输环境中FEC代码的使用，并介绍了一些常用的FEC代码。
Building blocks are defined in RFC 3048 [6]. This document is a product of the IETF RMT WG and follows the general guidelines provided in RFC 3269 [3].
RFC 3048[6]中定义了构建块。本文件是IETF RMT工作组的产品，遵循RFC 3269[3]中提供的一般指南。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2]中所述进行解释。
Statement of Intent
意向书
This memo contains part of the definitions necessary to fully specify a Reliable Multicast Transport (RMT) protocol in accordance with RFC 2357 [5]. As per RFC 2357, the use of any reliable multicast protocol in the Internet requires an adequate congestion control scheme.
本备忘录包含根据RFC 2357[5]完全指定可靠多播传输（RMT）协议所需的部分定义。根据RFC2357，在互联网上使用任何可靠的多播协议都需要适当的拥塞控制方案。
While waiting for such a scheme to be available, or for an existing scheme to be proven adequate, the RMT working group publishes this Request for Comments in the "Experimental" category.
在等待此类方案可用或现有方案被证明足够时，RMT工作组发布了“实验”类评论请求。
It is the intent of RMT to re-submit this specification as an IETF Proposed Standard as soon as the above condition is met.
RMT的目的是，一旦满足上述条件，立即将本规范作为IETF建议的标准重新提交。
This section specifies FEC Encoding IDs 0 and 130 and the associated FEC Payload ID formats and the specific information in the corresponding FEC Object Transmission Information. The FEC scheme associated with FEC Encoding ID 0 is Fully-Specified whereas the FEC schemes associated with FEC Encoding ID 130 are Under-Specified.
本节规定FEC编码ID 0和130以及相关FEC有效负载ID格式和相应FEC对象传输信息中的特定信息。与FEC编码ID 0关联的FEC方案被完全指定，而与FEC编码ID 130关联的FEC方案被指定不足。
FEC Encoding IDs 0 and 130 have the same FEC Payload ID format, which is described in the following subsection. The FEC Object Transmission Information for FEC Encoding IDs 0 and 130 is different, and is described in the subsequent two subsections.
FEC编码ID 0和130具有相同的FEC有效负载ID格式，这将在以下小节中描述。用于FEC编码id 0和130的FEC对象传输信息不同，并且在随后的两小节中描述。
The FEC Payload ID for FEC Encoding IDs 0 and 130 is composed of a Source Block Number and an Encoding Symbol ID structured as follows:
FEC编码ID 0和130的FEC有效负载ID由源块号和编码符号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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 16-bit Source Block Number 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.
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 the source block is processed at the transport layer by the sender, the network transit time for packets, and the amount of time the source block is processed at the transport layer by a receiver. This allows the receiver to clearly decide which packets belong to which source block.
如果使用非唯一SBN模式，则从源块到源块编号的映射必须在带外传递给接收机，并且如何实现这一点不在本文档的范围内。该映射可以是隐式的，例如由源块的传输顺序确定。在非唯一SBN模式下，映射到相同源块编号的两个不同源块的数据包不应在短于源块传输时间的时间间隔内发送。源块的传输时间包括发送方在传输层处理源块的时间量、分组的网络传输时间以及接收方在传输层处理源块的时间量。这允许接收器清楚地决定哪些数据包属于哪个源块。
The 16-bit Encoding Symbol ID 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 for FEC Encoding ID 0 are specified in Section 3. The exact details of the correspondence between Encoding Symbol IDs and the encoding symbol(s) in the packet payload for FEC Encoding ID 130 are dependent on the
16位编码符号ID标识在分组有效载荷中携带从源块生成的特定编码符号。编码符号ID与FEC编码ID 0的分组有效载荷中的编码符号之间的对应关系的确切细节在第3节中规定。编码符号ID和用于FEC编码ID 130的分组有效载荷中的编码符号之间的对应关系的确切细节取决于
particular encoding algorithm used as identified by the FEC Encoding ID and by the FEC Instance ID.
由FEC编码ID和FEC实例ID标识的特定编码算法。
This subsection reserves FEC Encoding ID 0 for the Compact No-Code FEC scheme described in this subsection and in Section 3. This is a Fully-Specified FEC scheme that is primarily intended to be used for simple interoperability testing between different implementations of protocol instantiations that use the FEC building block. The value of this FEC scheme is that no FEC encoding or decoding is required to implement it and therefore it is easy to test interoperability between protocols that may use different proprietary FEC schemes in production in their first implementations.
本小节为本小节和第3节中描述的紧凑无码FEC方案保留FEC编码ID 0。这是一个完全指定的FEC方案，主要用于使用FEC构建块的协议实例化的不同实现之间的简单互操作性测试。该FEC方案的价值在于，实现该方案不需要FEC编码或解码，因此很容易测试协议之间的互操作性，这些协议在第一次实现时可能在生产中使用不同的专有FEC方案。
The FEC Payload ID format for FEC Encoding ID 0 is described in Subsection 2.1. The FEC Object Transmission Information has the following specific information:
FEC编码ID 0的FEC有效负载ID格式如第2.1小节所述。FEC对象发送信息具有以下特定信息：
o The FEC Encoding ID 0.
o FEC编码ID为0。
o For each source block of the object, the length in bytes of the encoding symbol carried in the packet payload. This length MUST be the same for all packets sent for the same source block, but MAY be different for different source blocks in the same object.
o 对于对象的每个源块，数据包有效负载中携带的编码符号的字节长度。对于为同一源块发送的所有数据包，此长度必须相同，但对于同一对象中的不同源块，此长度可能不同。
o For each source block of the object, the length of the source block in bytes. Typically, each source block for the object has the same length and thus only one length common to all source blocks need be communicated, but this is not a requirement. For convenience, the source block length MAY be a multiple of the length of the encoding symbol carried in one packet payload.
o 对于对象的每个源块，源块的长度（以字节为单位）。通常，对象的每个源块具有相同的长度，因此只需要传输所有源块共有的一个长度，但这不是要求。为方便起见，源块长度可以是一个分组有效载荷中携带的编码符号长度的倍数。
How this out-of-band information is communicated is outside the scope of this document.
如何传达带外信息超出了本文件的范围。
Other information, such as the object length and the number of source blocks of the object for an object of known length may be needed by a receiver to support some delivery models, i.e., reliable bulk data delivery.
接收器可能需要其他信息，例如对象长度和已知长度对象的对象源块的数量，以支持一些传递模型，即可靠的批量数据传递。
This subsection reserves FEC Encoding ID 130 for the Compact FEC scheme that is described in this subsection. This 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
本小节为本小节中描述的紧凑FEC方案保留FEC编码ID 130。这是一个欠指定的FEC方案。该FEC方案在精神上类似于紧凑的无码FEC方案，只是可以使用非平凡的FEC编码（未指定）来生成编码
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解码器可用于从接收到的分组产生源块。
The FEC Payload ID format for FEC Encoding ID 0 is described in Subsection 2.1. The FEC Object Transmission Information has the following specific information:
FEC编码ID 0的FEC有效负载ID格式如第2.1小节所述。FEC对象发送信息具有以下特定信息：
o The FEC Encoding ID 130.
o FEC编码ID 130。
o The FEC Instance ID associated with the FEC Encoding ID 130 to be used.
o 与要使用的FEC编码ID 130相关联的FEC实例ID。
o For each source block of the object, the aggregate length of the encoding symbol(s) carried in one packet payload. This length MUST be the same for all packets sent for the same source block, but MAY be different for different source blocks in the same object.
o 对于对象的每个源块，一个数据包有效载荷中携带的编码符号的总长度。对于为同一源块发送的所有数据包，此长度必须相同，但对于同一对象中的不同源块，此长度可能不同。
o For each source block of the object, the length of the source block in bytes. Typically, each source block for the object has the same length and thus only one length common to all source blocks need to be communicated, but this is not a requirement. For convenience, the source block length MAY be a multiple of the aggregate length of the encoding symbol(s) carried in one packet payload.
o 对于对象的每个源块，源块的长度（以字节为单位）。通常，对象的每个源块具有相同的长度，因此只需要传输所有源块共有的一个长度，但这不是要求。为了方便起见，源块长度可以是一个分组有效载荷中携带的编码符号的总长度的倍数。
How this out-of-band information is communicated is outside the scope of this document.
如何传达带外信息超出了本文件的范围。
Other information, such as the object length and the number of source blocks of the object for an object of known length may be needed by a receiver to support some delivery models, i.e., reliable bulk data delivery.
接收器可能需要其他信息，例如对象长度和已知长度对象的对象源块的数量，以支持一些传递模型，即可靠的批量数据传递。
In this section we describe a Fully-Specified FEC scheme corresponding to FEC Encoding ID 0. The primary purpose for introducing these FEC schemes is to allow simple interoperability testing between different implementations of the same protocol instantiation that uses the FEC building block.
在本节中，我们将描述与FEC编码ID 0相对应的完全指定的FEC方案。引入这些FEC方案的主要目的是允许在使用FEC构建块的相同协议实例化的不同实现之间进行简单的互操作性测试。
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. The FEC Payload ID consists of two fields, the 16-bit Source Block Number and the 16-bit Encoding Symbol ID, as described in Subsection 2.1. The relative lengths of these fields were chosen for their similarity with the corresponding fields of the FEC Payload ID associated with FEC Encoding ID 130, and
紧凑的无码FEC方案不需要FEC编码或解码。相反，每个编码符号由对象的源块的连续字节组成。FEC有效载荷ID由两个字段组成，即16位源块编号和16位编码符号ID，如第2.1小节所述。选择这些字段的相对长度是因为它们与与与FEC编码ID 130相关联的FEC有效载荷ID的对应字段相似，以及
because of this testing interoperability of the FEC scheme associated with FEC Encoding ID 0 provides a first basic step to testing interoperability of an FEC scheme associated with FEC Encoding ID 130.
由于该测试，与FEC编码ID 0相关联的FEC方案的互操作性提供了测试与FEC编码ID 130相关联的FEC方案的互操作性的第一个基本步骤。
Subsection 2.1. describes mapping between source blocks of an object and Source Block Numbers. The next two subsections describe the details of how the Compact No-Code FEC scheme operates for each source block of an object. These subsections are not meant to suggest a particular implementation, but just to illustrate the general algorithm through the description of a simple, non-optimized implementation.
第2.1小节。描述对象的源块与源块编号之间的映射。接下来的两小节将详细介绍紧凑型无代码FEC方案如何对对象的每个源块进行操作。这些小节的目的不是建议一个特定的实现，而是通过描述一个简单的、非优化的实现来说明一般的算法。
Let X > 0 be the length of a source block in bytes. The value of X is 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为源块的长度（以字节为单位）。X的值是FEC对象传输信息的一部分，并且如何将该信息传递给接收机不在本文档的范围内。
Let L > 0 be the length of the encoding symbol contained in the payload of each packet. There are several possible ways the length of the encoding symbol L can be communicated to the receiver, and how this is done is outside the scope of this document. As an example, a sender could fix the packet payload length to be L in order to place the encoding symbol of length L into the packet, and then a receiver could infer the value of L from the length of the received packet payload. It is REQUIRED that L be the same for all packets sent for the same source block but MAY be different for different source blocks within the same object.
设L>0为每个数据包的有效载荷中包含的编码符号的长度。有几种可能的方式可以将编码符号L的长度传送给接收器，并且如何传送不在本文档的范围内。例如，发送方可以将分组有效载荷长度固定为L，以便将长度为L的编码符号放入分组中，然后接收方可以从接收到的分组有效载荷的长度推断L的值。对于为同一源块发送的所有数据包，要求L相同，但对于同一对象内的不同源块，L可能不同。
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 of refer to the companion document [7] for general advice.
对于发送方如何生成编码符号以从源块发送，没有超出上述规则的限制。但是，建议的实施者参考配套文件[7]以获取一般建议。
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 consisting of the L bytes of the source block numbered L*Y through L*(Y+1)-1.
o 如果Y<N-1，则生成由编号为L*Y到L*（Y+1）-1的源块的L字节组成的编码符号。
o If Y = N-1 then generate the encoding symbol consisting of the last X - L*(N-1) bytes of the source block numbered L*(N-1) through X-1 followed by L*N - X padding bytes of zeroes.
o 如果Y=N-1，则生成编码符号，该编码符号由编号为L*（N-1）到X-1的源块的最后X-L*（N-1）字节组成，后跟L*N-X零填充字节。
o 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 将源块长度设置为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 describe 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 received out-of-band as part of
建议接收方根据从使用上述转盘程序的发送方接收源块的数据包，采用以下程序恢复源块。接收机可以通过FEC有效负载ID中携带的源块编号确定从哪个源块生成接收到的分组。在接收到源块的第一个FEC有效负载ID后，接收机使用带外接收到的源块长度作为发送的一部分
the FEC Object Transmission Information to determine the length X in bytes of the source block, and allocates space for the X bytes that the source block requires. The receiver also computes the length L of the encoding symbol in the payload of the packet by substracting the packet header length from the total length of the received packet (and the receiver checks that this length is the same in each subsequent received packet from the same source block). 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 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 FEC Payload ID of the packet. If Y < N-1 then the receiver copies the L bytes of the encoding symbol into bytes numbered L*Y through L*(Y+1)-1 of the space reserved for the source block. If Y = N-1 then the receiver copies the first X - L*(N-1) bytes of the encoding symbol into bytes numbered L*(N-1) through X-1 of the space reserved for the source block. In either case, the receiver sets RECEIVED[Y] = true. At each point in time, the receiver has successfully recovered bytes L*Y through L*(Y+1)-1 of the source block for all Y in the interval [0..N-1] for which RECEIVED[Y] is true. If all N entries of RECEIVED are true then the receiver has recovered the entire source block.
FEC对象传输信息，以确定源块的长度X（字节），并为源块所需的X字节分配空间。接收机还通过从接收的分组的总长度中减去分组报头长度来计算分组的有效载荷中的编码符号的长度L（并且接收机检查来自相同源块的每个后续接收分组中的该长度是否相同）。在计算N=X/L四舍五入到最接近的整数后，接收器分配一个接收到的布尔数组[0..N-1]，其中所有N个条目初始化为false，以跟踪接收到的编码符号。只要RECEIVED中至少有一个条目仍然设置为false，或者直到应用程序决定放弃此源块并转移到其他源块，接收器就会继续接收源块的数据包。对于源块的每个接收到的分组（包括第一分组），帮助恢复源块的步骤如下。设Y为分组的FEC有效负载ID内的编码符号ID的值。如果Y<N-1，则接收器将编码符号的L字节复制到为源块保留的空间中编号为L*Y到L*（Y+1）-1的字节中。如果Y=N-1，则接收器将编码符号的第一个X-L*（N-1）字节复制到为源块保留的空间中编号为L*（N-1）到X-1的字节中。在任何一种情况下，接收器都将接收到的[Y]=真。在每个时间点，接收器已经成功地恢复了间隔[0..N-1]中所有Y的源块的字节L*Y到L*（Y+1）-1，其中接收到的[Y]为真。如果接收的所有N个条目均为真，则接收器已恢复整个源块。
The following subsections outline some usage examples for FEC Encoding IDs 0 and 130.
以下小节概述了FEC编码ID 0和130的一些使用示例。
One possible delivery model that can be supported using any FEC scheme described in this document is reliable bulk data delivery. In this model, one or more potentially large objects are delivered reliably to potentially multiple receivers using multicast. For this delivery model the unique SBN mode is often used. Using this mode the maximum length of an object that can be delivered is at most the number of possible source blocks times the maximum length of a source block. If the aggregate length of encoding symbols carried in a packet payload is L bytes then the maximum length of a source block is the number of distinct Encoding Symbol IDs times L, or 2^16 * L for FEC Encoding IDs 0 and 130. If for example L = 1 KB then the length of a source block can be up to around 65 MB. However, in practice the length of the source block is usually shorter than the
使用本文中描述的任何FEC方案都可以支持的一种可能的交付模型是可靠的批量数据交付。在该模型中，使用多播将一个或多个潜在的大型对象可靠地传递给潜在的多个接收器。对于这种交付模式，通常使用独特的SBN模式。使用此模式，可交付对象的最大长度最多为可能的源块数乘以源块的最大长度。如果数据包有效载荷中携带的编码符号的总长度为L字节，则源块的最大长度为不同编码符号ID的数量乘以L，或者对于FEC编码ID 0和130，为2^16*L。例如，如果L=1KB，则源块的长度最多可达65MB左右。然而，在实践中，源块的长度通常比源块的长度短
number of distinct Encoding Symbol IDs times L, and thus generally the length of a source block is a fraction of 65 MB. Since the number of distinct Source Block Numbers is 2^16, for this example an object can be more than a terabyte.
不同编码符号ID的数量乘以L，因此通常源块的长度是65MB的一小部分。由于不同源代码块编号的数量为2^16，因此在本例中，对象的大小可以超过1 TB。
The non-unique SBN mode of delivery can also be effectively used for reliably delivering large object. In this case, the length of the object delivered could be arbitrarily large, depending on the out-of-band mapping between source blocks and Source Block Numbers.
非唯一的SBN交付模式也可以有效地用于可靠地交付大型对象。在这种情况下，交付的对象的长度可以任意大，这取决于源块和源块编号之间的带外映射。
Another possible delivery model that can be supported using FEC Encoding ID 0 or 130 is block-stream delivery of an object. In this model, the source blocks of a potentially indeterminate length object are to be reliably delivered in sequence to one or multiple receivers. Thus, the object could be partitioned into source blocks on-the-fly at the sender as the data arrives, and all packets generated for one source block are sent before any packets are sent for the subsequent source block. In this example, all source blocks could be of the same length and this length could be communicated out-of-band to a receiver before the receiver joins the session. For this delivery model it is not required that the Source Block Numbers for all source blocks are unique. However, a suggested usage is to use all 2^16 Source Block Numbers for consecutive source blocks of the object, and thus the time between reuse of a Source Block Number is the time it takes to send the packets for 2^16 source blocks.
使用FEC编码ID 0或130可以支持的另一种可能的传递模型是对象的块流传递。在该模型中，潜在不确定长度对象的源块将按顺序可靠地传递给一个或多个接收器。因此，当数据到达时，可以在发送方将对象动态地划分为源块，并且在为后续源块发送任何数据包之前，发送为一个源块生成的所有数据包。在该示例中，所有源块可以具有相同的长度，并且该长度可以在接收器加入会话之前在带外传送到接收器。对于该交付模型，不要求所有源块的源块编号都是唯一的。但是，建议的用法是将所有2^16源块编号用于对象的连续源块，因此，重复使用源块编号之间的时间是为2^16源块发送数据包所需的时间。
This delivery model can be used to reliably deliver an object to one or multiple receivers, using either an ACK or NACK based acknowledgement based scheme for each source block. As another example the sender could send a fixed number of packets for each source block without any acknowledgements from receivers, for example in a live streaming without feedback application.
该交付模型可用于使用针对每个源块的基于ACK或NACK的确认方案，将对象可靠地交付给一个或多个接收机。作为另一个示例，发送方可以为每个源块发送固定数量的分组，而无需来自接收方的任何确认，例如在无反馈的实时流应用中。
The security considerations for this document are the same as they are for RFC 3452 [4].
本文件的安全注意事项与RFC 3452[4]的安全注意事项相同。
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 RFC 3452 [4]. This document assigns the Fully-Specified FEC Encoding ID 0 under the ietf:rmt:fec:encoding name-space to "Compact No-Code". The FEC Payload ID format and corresponding FEC Object Transmission Information associated with FEC
FEC编码ID和FEC实例ID的值受IANA注册的约束。有关适用于本文件的IANA注意事项的一般指南，请参见RFC 3452[4]。本文档将ietf:rmt:FEC:Encoding名称空间下完全指定的FEC编码ID 0分配给“压缩无代码”。与FEC相关联的FEC有效负载ID格式和相应的FEC对象传输信息
Encoding ID 0 is described in Subsections 2.1 and 2.2, and the corresponding FEC scheme is described in Section 3.
第2.1和2.2小节描述了编码ID 0，第3节描述了相应的FEC方案。
This document assigns the Under-Specified FEC Encoding ID 130 under the ietf:rmt:fec:encoding name-space to "Compact FEC". The FEC Payload ID format and corresponding FEC Object Transmission Information associated with FEC Encoding ID 130 are described in Subsections 2.1 and 2.3.
本文档将ietf:rmt:FEC:Encoding名称空间下指定的FEC编码ID 130分配给“Compact-FEC”。第2.1和2.3小节描述了与FEC编码ID 130相关联的FEC有效载荷ID格式和相应的FEC对象传输信息。
As FEC Encoding ID 130 is Under-Specified, a new "FEC Instance ID" sub-name-space must be established, in accordance to RFC 3452. Hence this document also establishes a new "FEC Instance ID" registry named
由于未指定FEC编码ID 130，因此必须根据RFC 3452建立新的“FEC实例ID”子名称空间。因此，本文档还建立了一个新的“FEC实例ID”注册表，名为
ietf:rmt:fec:encoding:instance:130
ietf:rmt:fec:encoding:instance:130
and scoped by
范围是
ietf:rmt:fec:encoding = 130 (Compact FEC)
ietf:rmt:fec:encoding = 130 (Compact FEC)
As per RFC 3452, the values that can be assigned within ietf:rmt:fec:encoding:instance:130 are non-negative numeric indices. Assignment requests are granted on a "First Come First Served" basis. RFC 3452 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:130.
根据RFC 3452，可以在ietf:rmt:fec:encoding:instance:130中分配的值是非负数字索引。派遣申请以“先到先得”的方式批准。RFC 3452指定了在通用ietf:rmt:fec:encoding:instance name空间中分配必须满足的附加标准。这些标准也适用于ietf:rmt:fec:encoding:instance:130。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation Documents", RFC 3269, April 2002.
[3] Kermode，R.和L.Vicisano，“可靠多播传输（RMT）构建块和协议实例化文档的作者指南”，RFC 3269，2002年4月。
[4] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002.
[4] 卢比，M.，维西萨诺，L.，杰梅尔，J.，里佐，L.，汉德利，M.和J.克罗夫特，“前向纠错（FEC）构建块”，RFC 3452，2002年12月。
[5] Mankin, A., Romanow, A., Bradner, S. and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[5] Mankin，A.，Romanow，A.，Bradner，S.和V.Paxson，“IETF评估可靠多播传输和应用协议的标准”，RFC 2357，1998年6月。
[6] 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.
[6] Whetten，B.，Vicisano，L.，Kermode，R.，Handley，M.，Floyd，S.和M.Luby，“一对多批量数据传输的可靠多播传输构建块”，RFC 3048，2001年1月。
[7] 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.
[7] Luby，M.，Vicisano，L.，Gemmell，J.，Rizzo，L.，Handley，M.和J.Crowcroft，“前向纠错（FEC）在可靠多播中的使用”，RFC 3453，2002年12月。
Michael Luby Digital Fountain, Inc. 39141 Civic Center Drive Suite 300 Fremont, CA 94538
Michael Luby Digital Fountain，Inc.加利福尼亚州弗里蒙特市公民中心大道300号39141室，邮编94538
EMail: luby@digitalfountain.com
EMail: luby@digitalfountain.com
Lorenzo Vicisano cisco Systems, Inc. 170 West Tasman Dr., San Jose, CA, USA, 95134
Lorenzo Vicisano cisco Systems，Inc.170 West Tasman Dr.，美国加利福尼亚州圣何塞，邮编：95134
EMail: lorenzo@cisco.com
EMail: lorenzo@cisco.com
Copyright (C) The Internet Society (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。