Network Working Group M. Watson
Request for Comments: 5052 M. Luby
Obsoletes: 3452 L. Vicisano
Category: Standards Track Digital Fountain
August 2007
Network Working Group M. Watson
Request for Comments: 5052 M. Luby
Obsoletes: 3452 L. Vicisano
Category: Standards Track Digital Fountain
August 2007
Forward Error Correction (FEC) Building Block
前向纠错（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) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for bulk data transfer over IP multicast. This document defines a framework for the definition of the information that needs to be communicated in order to use an FEC code for bulk data transfer, in addition to the encoded data itself, and for definition of formats and codes for communication of that information. Both information communicated with the encoded data itself and information that needs to be communicated 'out-of-band' are considered. The procedures for specifying new FEC codes, defining the information communication requirements associated with those codes and registering them with the Internet Assigned Numbers Authority (IANA) are also described. The requirements on Content Delivery Protocols that wish to use FEC codes defined within this framework are also defined. The companion document titled "The Use of Forward Error Correction (FEC) in Reliable Multicast" describes some applications of FEC codes for delivering content. This document obsoletes RFC 3452.
本文档描述了如何使用前向纠错（FEC）代码有效地提供和/或增强IP多播上批量数据传输的可靠性。除编码数据本身外，本文件还定义了一个框架，用于定义需要传输的信息，以便使用FEC代码进行批量数据传输，以及定义该信息传输的格式和代码。考虑与编码数据本身通信的信息和需要“带外”通信的信息。还描述了指定新FEC代码、定义与这些代码相关的信息通信要求以及向互联网分配号码管理局（IANA）注册这些代码的程序。还定义了希望使用此框架中定义的FEC代码的内容交付协议的要求。标题为“可靠多播中前向纠错（FEC）的使用”的附带文档描述了FEC代码在交付内容方面的一些应用。本文件淘汰RFC 3452。
Table of Contents
目录
1. Introduction ....................................................3
2. Definitions and Abbreviations ...................................4
3. Requirements Notation ...........................................4
4. Rationale .......................................................5
5. Applicability Statement .........................................6
6. Functionality ...................................................6
6.1. FEC Schemes ................................................8
6.2. FEC Object Transmission Information .......................10
6.2.1. Transport of FEC Object Transmission Information ...11
6.2.2. Opacity of FEC Object Transmission Information .....12
6.2.3. Mandatory FEC Object Transmission
Information Elements ...............................12
6.2.4. Common FEC Object Transmission Information
Elements ...........................................12
6.2.5. Scheme-Specific FEC Object Transmission
Information Element ................................13
6.3. FEC Payload ID ............................................13
7. FEC Scheme Specifications ......................................14
8. CDP Specifications .............................................17
9. Common Algorithms ..............................................18
9.1. Block Partitioning Algorithm ..............................18
9.1.1. First Step .........................................18
9.1.2. Second step ........................................19
10. Requirements from Other Building Blocks .......................20
11. Security Considerations .......................................20
12. IANA Considerations ...........................................21
12.1. Explicit IANA Assignment Guidelines ......................21
13. Changes from RFC 3452 .........................................22
14. Acknowledgments ...............................................23
15. References ....................................................23
15.1. Normative References .....................................23
15.2. Informative References ...................................23
1. Introduction ....................................................3
2. Definitions and Abbreviations ...................................4
3. Requirements Notation ...........................................4
4. Rationale .......................................................5
5. Applicability Statement .........................................6
6. Functionality ...................................................6
6.1. FEC Schemes ................................................8
6.2. FEC Object Transmission Information .......................10
6.2.1. Transport of FEC Object Transmission Information ...11
6.2.2. Opacity of FEC Object Transmission Information .....12
6.2.3. Mandatory FEC Object Transmission
Information Elements ...............................12
6.2.4. Common FEC Object Transmission Information
Elements ...........................................12
6.2.5. Scheme-Specific FEC Object Transmission
Information Element ................................13
6.3. FEC Payload ID ............................................13
7. FEC Scheme Specifications ......................................14
8. CDP Specifications .............................................17
9. Common Algorithms ..............................................18
9.1. Block Partitioning Algorithm ..............................18
9.1.1. First Step .........................................18
9.1.2. Second step ........................................19
10. Requirements from Other Building Blocks .......................20
11. Security Considerations .......................................20
12. IANA Considerations ...........................................21
12.1. Explicit IANA Assignment Guidelines ......................21
13. Changes from RFC 3452 .........................................22
14. Acknowledgments ...............................................23
15. References ....................................................23
15.1. Normative References .....................................23
15.2. Informative References ...................................23
This document describes how to use Forward Error Correction (FEC) codes to provide support for reliable delivery of content within the context of a Content Delivery Protocol (CDP). This document describes a building block as defined in [10], specifically Section 4.2 of that document, and follows the general guidelines provided in [5].
本文档描述了如何使用前向纠错（FEC）代码在内容交付协议（CDP）的上下文中为内容的可靠交付提供支持。本文件描述了[10]中定义的构建块，特别是该文件的第4.2节，并遵循[5]中提供的一般指南。
The purpose of this building block is to define a framework for forward error correction such that:
此构建块的目的是定义前向纠错框架，以便：
1. CDPs can be designed to operate with a range of different FEC codes/schemes, without needing to know details of the specific FEC code/scheme that may be used.
1. CDP可以设计为使用一系列不同的FEC代码/方案，而不需要知道可能使用的特定FEC代码/方案的详细信息。
2. FEC schemes can be designed to operate with a range of different CDPs, without needing to know details of the specific CDPs.
2. FEC方案可以设计为与一系列不同的CDP一起运行，而无需了解特定CDP的详细信息。
Note that a 'CDP' in the context of this document may consist of several distinct protocol mechanisms and may support any kind of application requiring reliable transport -- for example, object delivery and streaming applications.
请注意，本文档上下文中的“CDP”可能由几个不同的协议机制组成，并且可能支持需要可靠传输的任何类型的应用程序，例如，对象交付和流式应用程序。
This document also provides detailed guidelines on how to write an RFC for an FEC scheme corresponding to a new FEC Encoding ID (for both Fully-Specified and Under-Specified FEC Schemes -- see Section 4).
本文档还提供了有关如何为对应于新FEC编码ID的FEC方案编写RFC的详细指南（对于完全指定的和未指定的FEC方案，请参见第4节）。
RFC 3452 [3], which is obsoleted by this document, contained a previous version, which was published in the "Experimental" category. RFC 3452 was published as an Experimental RFC in part due to the lack at that time of specified congestion control strategies suitable for use with Reliable Multicast protocols.
RFC 3452[3]已被本文件废弃，其中包含一个先前版本，该版本在“实验”类别中发布。RFC3452作为一种实验性RFC出版，部分原因是当时缺乏适用于可靠多播协议的特定拥塞控制策略。
This Proposed Standard specification is thus based on RFC 3452 [3] updated according to accumulated experience and growing protocol maturity since the publication of RFC 3452 [3]. Said experience applies both to this specification itself and to congestion control strategies related to the use of this specification.
因此，本拟议标准规范以RFC 3452[3]为基础，根据RFC 3452[3]出版以来积累的经验和不断增长的协议成熟度进行更新。上述经验既适用于本规范本身，也适用于与本规范使用相关的拥塞控制策略。
The differences between RFC 3452 [3] and this document are listed in Section 13.
RFC 3452[3]与本文件之间的差异见第13节。
Object: An ordered sequence of octets to be transferred by the transport protocol. For example, a file or stream.
对象：由传输协议传输的有序八位字节序列。例如，文件或流。
Symbol: A unit of data processed by the Forward Error Correction code. A symbol is always considered as a unit, i.e., it is either completely received or completely lost.
符号：由前向纠错码处理的数据单位。符号始终被视为一个单元，即它要么完全接收，要么完全丢失。
Source symbol: A symbol containing information from the original object.
源符号：包含原始对象信息的符号。
Repair symbol: A symbol containing information generated by the FEC code which can be used to recover lost source symbols.
修复符号：包含FEC代码生成的信息的符号，可用于恢复丢失的源符号。
Encoding symbol: A source symbol or a repair symbol.
编码符号：源符号或修复符号。
Encoder: The FEC scheme specific functions required to transform a object into FEC encoded data. That is, the functions that produce repair symbols using source symbols.
编码器：将对象转换为FEC编码数据所需的FEC方案特定功能。即，使用源符号生成修复符号的函数。
Decoder: The FEC scheme-specific functions required to transform received FEC-encoded data into a copy of the original object.
解码器：将接收到的FEC编码数据转换为原始对象副本所需的FEC方案特定功能。
Receiver: A system supporting the receiving functions of a CDP and FEC scheme according to this specification.
接收器：根据本规范，支持CDP和FEC方案接收功能的系统。
Sender: A system supporting the sending functions of a CDP and FEC scheme according to this specification.
发送方：根据本规范，支持CDP和FEC方案发送功能的系统。
Source Block: A part of the object formed from a subset of the object's source symbols.
源块：由对象源符号子集构成的对象的一部分。
CDP: Content Delivery Protocol
内容交付协议
FEC: Forward Error Correction
前向纠错
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 [1].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[1]中所述进行解释。
An FEC code, in the general sense, is a valuable basic component of any CDP that is to provide reliable delivery of an object. Using FEC codes is effective in the context of IP multicast and reliable delivery because FEC encoding symbols can be useful to all receivers for reconstructing an object even when the receivers have received different encoding symbols. Furthermore, FEC codes can ameliorate or even eliminate the need for feedback from receivers to senders to request retransmission of lost packets.
在一般意义上，FEC代码是任何CDP的一个有价值的基本组件，用于提供对象的可靠交付。使用FEC码在IP多播和可靠传送的上下文中是有效的，因为FEC编码符号可用于所有接收机重构对象，即使接收机已接收到不同的编码符号。此外，FEC码可以改善甚至消除从接收器到发送者的反馈以请求丢失分组的重传的需要。
Central to this document is the concept of an 'FEC Scheme', which we distinguish from the concept of an 'FEC code' or 'FEC algorithm'. An FEC scheme defines the ancillary information and procedures which, combined with an FEC code or algorithm specification, fully define how the FEC code can be used with CDPs. An FEC scheme may be associated with a single standardized FEC code (A 'Fully-Specified' FEC scheme) or may be applicable to many FEC codes (An 'Under-Specified' FEC scheme).
本文件的核心是“FEC方案”的概念，我们将其与“FEC代码”或“FEC算法”的概念区分开来。FEC方案定义了辅助信息和程序，这些信息和程序与FEC代码或算法规范相结合，完全定义了如何将FEC代码与CDP一起使用。FEC方案可与单个标准化FEC代码（“完全指定”FEC方案）相关联，或可适用于许多FEC代码（“未指定”FEC方案）。
This document describes a framework for the definition of FEC schemes. Definition of actual FEC schemes is outside the scope of this document. This document also defines requirements for reliable CDPs that make use of FEC schemes. Any CDP that is compliant to the requirements specified in this document can make use of any FEC scheme that is defined within the framework described here. Note that FEC schemes may place restrictions on the types of CDP they are intended to be used with. For example, some FEC schemes may be specific to particular types of application, such as file delivery or streaming.
本文件描述了FEC方案定义的框架。实际FEC方案的定义不在本文件范围内。本文件还定义了使用FEC方案的可靠CDP的要求。符合本文件规定要求的任何CDP都可以使用此处所述框架内定义的任何FEC方案。请注意，FEC方案可能会对其拟用于的CDP类型施加限制。例如，一些FEC方案可能特定于特定类型的应用，例如文件交付或流式传输。
The goal of the FEC building block is to describe functionality directly related to FEC codes that is common to all reliable CDPs and to all FEC schemes, and to leave out any additional functionality that is specific to particular CDPs or particular FEC schemes. The primary functionality described in this document that is common to all such CDPs that use FEC codes is the definition and transport of three kinds of information from sender to receiver(s):
FEC构建块的目标是描述与所有可靠CDP和所有FEC方案通用的FEC代码直接相关的功能，并省略特定CDP或特定FEC方案的任何附加功能。本文档中描述的所有使用FEC代码的CDP共有的主要功能是定义和传输三种信息，从发送方到接收方：
1) encoding symbols themselves, 2) ancillary information associated with encoding symbols (or groups of such symbols, such as the group of symbols in a single packet, or the group of symbols related to a single source block), and 3) ancillary information associated with the whole object being transferred.
1) 编码符号本身，2）与编码符号相关联的辅助信息（或此类符号的组，例如单个分组中的符号组，或与单个源块相关联的符号组），以及3）与被传输的整个对象相关联的辅助信息。
It is important to note that this information is only required by the receiver if one or more of the encoding symbols to which it relates are received.
重要的是要注意，只有当接收到与该信息相关的一个或多个编码符号时，接收机才需要该信息。
This document does not describe how receivers may request transmission of particular encoding symbols for an object. This is because although there are CDPs where requests for transmission are of use, there are also CDPs that do not require such requests.
本文档不描述接收机如何请求传输对象的特定编码符号。这是因为尽管有些CDP使用传输请求，但也有一些CDP不需要此类请求。
The companion document [4] should be consulted for a full explanation of the benefits of using FEC codes for reliable content delivery using IP multicast. FEC codes are also useful in the context of unicast, and thus the scope and applicability of this document is not limited to IP multicast.
应参考配套文件[4]，全面解释使用FEC代码进行IP多播可靠内容交付的好处。FEC代码在单播上下文中也很有用，因此本文档的范围和适用性不限于IP多播。
The FEC building block does not provide any support for congestion control. Any complete multicast CDP MUST provide congestion control that conforms to [6], in particular, Section 3.2 of that document. Thus, congestion control MUST be provided by another building block when the FEC building block is used in a CDP.
FEC构建块不支持拥塞控制。任何完整的多播CDP必须提供符合[6]的拥塞控制，特别是该文件的第3.2节。因此，当在CDP中使用FEC构建块时，拥塞控制必须由另一个构建块提供。
A more complete description of the applicability of FEC codes can be found in the companion document [4].
有关FEC代码适用性的更完整说明，请参见配套文件[4]。
This section describes FEC information that is to be sent either in packets also containing FEC encoding symbols or 'out-of-band'. The FEC information is associated with transmission of encoding symbols related to a particular object. There are three classes of packets that may contain FEC information: data packets, session-control packets, and feedback packets. They generally contain different kinds of FEC information. Note that some CDPs may not use session-control or feedback packets.
本节描述将在同样包含FEC编码符号的数据包或“带外”数据包中发送的FEC信息。FEC信息与与特定对象相关的编码符号的传输相关联。有三类包可能包含FEC信息：数据包、会话控制包和反馈包。它们通常包含不同种类的FEC信息。请注意，某些CDP可能不使用会话控制或反馈数据包。
Data packets may sometimes serve as session-control packets as well; both data and session-control packets generally travel downstream from the sender towards receivers and are sent to a multicast channel or to a specific receiver using unicast. Session-control packets may additionally travel upstream from receivers to senders.
数据包有时也可用作会话控制包；数据和会话控制数据包通常从发送方向接收方下行，并使用单播发送到多播信道或特定接收方。会话控制分组还可以从接收器向发送器上游移动。
As a general rule, feedback packets travel upstream from receivers to the sender. Sometimes, however, they might be sent to a multicast channel or to another receiver or to some intermediate node or neighboring router that provides recovery services.
一般来说，反馈数据包从接收者向发送者的上游传输。然而，有时它们可能被发送到多播信道或另一个接收器，或发送到提供恢复服务的某个中间节点或相邻路由器。
This document specifies both the FEC information that must be carried in data packets and the FEC information that must be communicated from sender to receiver(s) either out-of-band or in data packets. Specification of protocol mechanisms for transporting this information, for example, field and packet formats, is out of scope of this document. Instead, this document specifies at a higher level the information that must be communicated and provides detailed requirements for FEC Scheme and Content Delivery Protocol specifications, which are where the detailed field and packet formats should be defined.
本文件规定了必须在数据包中携带的FEC信息以及必须在带外或数据包中从发送方传送到接收方的FEC信息。用于传输此信息的协议机制（例如字段和数据包格式）的规范不在本文档的范围内。相反，本文件在更高级别上规定了必须传达的信息，并提供了FEC方案和内容交付协议规范的详细要求，其中应定义详细的字段和数据包格式。
FEC information is classified as follows:
FEC信息分类如下：
1. FEC information associated with an object
1. 与对象关联的FEC信息
This is information that is essential for the FEC decoder to decode a specific object. An example of this information is the identity of the FEC scheme that is being used to encode the object, in the form of the FEC Encoding ID. The FEC Encoding ID is described further below. This information may also include FEC scheme-specific parameters for the FEC decoder.
这是FEC解码器解码特定对象所必需的信息。该信息的一个示例是用于以FEC编码ID的形式对对象进行编码的FEC方案的标识。下面将进一步描述FEC编码ID。该信息还可以包括FEC解码器的FEC方案特定参数。
2. FEC information associated with specific encoding symbols for an object
2. 与对象的特定编码符号关联的FEC信息
This is information that is associated with one or more encoding symbols and is thus needed by the decoder whenever one or more of those encoding symbols have been received. Depending on the FEC scheme, information may be associated with individual symbols and/or with groups of symbols. One common such grouping is the group of symbols included within a single packet. Many FEC schemes also segment the object being encoded into multiple 'source blocks', each of which is processed independently for FEC purposes. Information about each source block is another type of information associated with a group of encoding symbols -- in this case, the group of symbols which are related to a given source block.
这是与一个或多个编码符号相关联的信息，因此每当接收到这些编码符号中的一个或多个时，解码器就需要这些信息。根据FEC方案，信息可以与单个符号和/或符号组相关联。一种常见的此类分组是包含在单个分组中的符号组。许多FEC方案还将被编码的对象分割成多个“源块”，每个“源块”都是为FEC目的独立处理的。关于每个源块的信息是与一组编码符号相关联的另一类信息——在本例中，是与给定源块相关的一组符号。
Two 'containers' are provided for communicating the FEC information described above, but there is not necessarily a one-to-one correspondence between the class of FEC information and the mechanism used. The two mechanisms are:
提供两个“容器”用于传送上述FEC信息，但是FEC信息的类别和所使用的机制之间不一定存在一对一的对应关系。这两种机制是：
a. FEC Object Transmission Information
a. 对象传输信息
CDPs must provide a reliable mechanism for communicating certain FEC information from sender to receiver(s). This information is known as 'FEC Object Transmission Information' and its contents
CDP必须提供可靠的机制，用于将某些FEC信息从发送方传送到接收方。该信息称为“FEC对象传输信息”及其内容
depend on the particular FEC scheme. It includes all information of the first class above and may include information of the second class. The FEC Object Transmission Information can be sent to a receiver within the data packet headers, within session control packets, or by some other means.
取决于特定的FEC方案。它包括上述第一类的所有信息，也可能包括第二类的信息。FEC对象传输信息可以在数据分组报头内、在会话控制分组内或通过某种其他方式发送到接收机。
b. FEC Payload ID
b. 有效载荷ID
CDPs must provide a mechanism for communicating information which identifies (for FEC purposes) the encoding symbols carried by a packet. This information is known as the FEC Payload ID, and its contents depend on the FEC scheme. It includes only information of the second class above. A data packet that carries encoding symbols MUST include an FEC Payload ID.
CDP必须提供一种通信信息的机制，用于识别（出于FEC目的）数据包携带的编码符号。该信息称为FEC有效负载ID，其内容取决于FEC方案。它只包含上面第二类的信息。携带编码符号的数据包必须包括FEC有效负载ID。
Two types of FEC scheme are defined by this document: 'Fully-Specified' FEC schemes and 'Under-Specified' FEC schemes. An FEC scheme is a Fully-Specified FEC scheme if the encoding scheme is formally and Fully-Specified, in a way that independent implementors can implement both encoder and decoder from a specification that is an IETF RFC.
本文件定义了两种类型的FEC方案：“完全指定的”FEC方案和“未指定的”FEC方案。如果编码方案是正式和完全指定的，则FEC方案是完全指定的FEC方案，独立的实现者可以根据IETF RFC规范实现编码器和解码器。
It is possible that an FEC scheme may not be a Fully-Specified FEC scheme, because either a specification is simply not available or a party exists that owns the encoding scheme and is not willing to disclose the algorithm or specification. We refer to such an FEC encoding scheme as an Under-Specified FEC scheme.
FEC方案可能不是完全指定的FEC方案，因为要么规范根本不可用，要么存在拥有编码方案并且不愿意公开算法或规范的一方。我们将这种FEC编码方案称为欠指定的FEC方案。
FEC schemes are identified by an FEC Encoding ID, which is an integer identifier assigned by IANA. The FEC Encoding ID allows receivers to select the appropriate FEC decoder. The value of the FEC Encoding ID MUST be the same for all transmission of encoding symbols related to a particular object, but MAY vary across different transmissions of encoding symbols about different objects, even if transmitted to the same set of multicast channels and/or using a single upper-layer session.
FEC方案由FEC编码ID标识，该ID是IANA分配的整数标识符。FEC编码ID允许接收机选择适当的FEC解码器。对于与特定对象相关的编码符号的所有传输，FEC编码ID的值必须相同，但在关于不同对象的编码符号的不同传输中可能不同，即使传输到同一组多播信道和/或使用单个上层会话。
The FEC Instance ID is an integer value that identifies a specific instance of an Under-Specified FEC scheme. This value is not used for Fully-Specified FEC schemes. The FEC Instance ID is scoped by the FEC Encoding ID, and FEC Instance ID values are subject to IANA registration.
FEC实例ID是一个整数值，用于标识未指定FEC方案的特定实例。此值不用于完全指定的FEC方案。FEC实例ID的范围由FEC编码ID确定，FEC实例ID值受IANA注册的约束。
The FEC Encoding ID for Fully-Specified FEC Schemes and both the FEC Encoding ID and FEC Instance ID for Under-Specified FEC Schemes are essential for the decoder to decode an object. Thus, they are part of the FEC Object Transmission Information.
对于解码器解码对象而言，完全指定的FEC方案的FEC编码ID和不完全指定的FEC方案的FEC编码ID和FEC实例ID都是必不可少的。因此，它们是FEC对象传输信息的一部分。
The following requirements apply to all FEC schemes, whether Fully-Specified or Under-Specified:
以下要求适用于所有FEC方案，无论是完全指定的还是未指定的：
o The type, semantics, and an encoding format for the FEC Payload ID and the FEC Object Transmission Information MUST be defined.
o 必须定义FEC有效负载ID和FEC对象传输信息的类型、语义和编码格式。
o A value for the FEC Encoding ID MUST be reserved and associated with the types, semantics, and encoding format of the FEC Payload ID and the FEC Object Transmission Information.
o FEC编码ID的值必须保留，并与FEC有效负载ID和FEC对象传输信息的类型、语义和编码格式相关联。
The specification for an Under-Specified FEC Scheme MAY allocate a sub-field within the Scheme-specific FEC Object Transmission Information element which is for instance-specific information. Each specific instance of the Under-Specified FEC Scheme may then use this field in an instance-specific way. The FEC scheme should define the scheme-specific FEC Object Transmission Information element in such a way that receivers that do not support the received FEC Instance ID can still parse and interpret the scheme-specific FEC Object Transmission Information element with the exception of the instance-specific field.
指定不足的FEC方案的规范可以在方案特定的FEC对象传输信息元素内分配子字段，该子字段是例如特定的信息。然后，未指定FEC方案的每个特定实例可以以特定于实例的方式使用该字段。FEC方案应当以这样的方式定义特定于方案的FEC对象传输信息元素，即不支持接收到的FEC实例ID的接收机仍然可以解析和解释特定于方案的FEC对象传输信息元素，但特定于实例的字段除外。
An already defined Under-Specified FEC Scheme (i.e., FEC Encoding ID value) MUST be reused if the associated FEC Payload ID and FEC Object Transmission Information have the required fields and encoding formats for a new Under-Specified FEC scheme instance.
如果相关联的FEC有效负载ID和FEC对象传输信息具有新的指定FEC方案实例所需的字段和编码格式，则必须重用已在指定FEC方案下定义的FEC方案（即FEC编码ID值）。
An instance of an Under-Specified FEC scheme is fully identified by the tuple (FEC Encoding ID, FEC Instance ID). The tuple MUST identify a single scheme instance that has at least one implementation. The party that owns this tuple MUST be able to provide information on how to obtain the Under-Specified FEC scheme instance identified by the tuple, e.g., a pointer to a publicly available reference-implementation or the name and contacts of a company that sells it, either separately or embedded in another product.
指定不足的FEC方案的实例由元组（FEC编码ID，FEC实例ID）完全标识。元组必须标识至少有一个实现的单个scheme实例。拥有此元组的一方必须能够提供有关如何获取元组标识的未充分指定的FEC方案实例的信息，例如，指向公开可用的参考实现的指针，或销售该元组的公司的名称和联系人（单独或嵌入另一产品中）。
This specification reserves the range 0-127 for the values of FEC Encoding IDs for Fully-Specified FEC schemes and the range 128-255 for the values of Under-Specified FEC schemes.
本规范为完全指定的FEC方案的FEC编码ID的值保留范围0-127，为未指定的FEC方案的值保留范围128-255。
The FEC Object Transmission Information contains information which is essential to the decoder in order to decode the encoded object. It may also contain information which is required to decode certain groups of encoding symbols, for example, individual Source Blocks within the object. This information is communicated reliably by the CDP to the receiver(s) as described in Section 8.
FEC对象传输信息包含解码器解码编码对象所必需的信息。它还可以包含解码特定编码符号组所需的信息，例如，对象内的单个源块。如第8节所述，CDP将该信息可靠地传送给接收机。
The FEC Object Transmission Information may consist of several elements and each element may be one of three types, as follows:
FEC对象传输信息可以由几个元素组成，每个元素可以是三种类型之一，如下所示：
Mandatory: These elements are defined in this specification and are each mandatory for at least one of the two types of FEC Scheme. Each FEC scheme specifies how the values of the Mandatory FEC Object Transmission Information elements are determined and each CDP specifies how this information is encoded and reliably communicated to the receiver(s). The Mandatory FEC Object Transmission Information includes the identification of the FEC Scheme, which is needed by the receiver to determine whether it supports the FEC Scheme.
强制性：这些元素在本规范中定义，并且对于两种类型的FEC方案中的至少一种都是强制性的。每个FEC方案指定如何确定强制FEC对象传输信息元素的值，并且每个CDP指定如何编码该信息并将其可靠地传送给接收机。强制性FEC对象传输信息包括FEC方案的标识，接收机需要该标识来确定其是否支持FEC方案。
Common: These elements are defined in this specification and are optional to be used by an FEC scheme. Each FEC scheme specifies which of the Common FEC Object Transmission Information elements it uses and how the values of these elements are determined.
通用：这些元素在本规范中定义，可供FEC方案选择使用。每个FEC方案指定它使用的公共FEC对象传输信息元素以及如何确定这些元素的值。
Scheme-specific: An FEC scheme may specify a single Scheme-specific FEC Object Transmission Information element. The FEC scheme specifies the type, semantics, and encoding format of the Scheme-specific FEC Object Transmission Information element. The resulting octet string is known as the "encoded Scheme-specific FEC Object Transmission Information". Each CDP specifies how the encoded Scheme-specific FEC Object Transmission is communicated reliably to the receiver(s), i.e., exactly where it shall be carried within packets of the CDP. Note that although from the point of view of this specification and of CDPs, there is only a single Scheme-specific FEC Object Transmission Information element, the FEC scheme may specify this element to contain multiple distinct pieces of information.
方案特定：FEC方案可以指定单个方案特定的FEC对象传输信息元素。FEC方案指定特定于方案的FEC对象传输信息元素的类型、语义和编码格式。产生的八位组字符串称为“编码方案特定的FEC对象传输信息”。每个CDP指定编码的特定于方案的FEC对象传输如何可靠地传送到接收机，即，在CDP的分组中准确地传送到何处。注意，尽管从本规范和cdp的观点来看，只有单个方案特定的FEC对象传输信息元素，但是FEC方案可以指定该元素包含多个不同的信息片段。
Each FEC scheme specifies an encoding format for the Common and Scheme-specific FEC Object Transmission Information. Each CDP must specify at least one of the following:
每个FEC方案为公共和方案特定的FEC对象传输信息指定编码格式。每个CDP必须至少指定以下一项：
1. A means to reliably communicate the Common FEC Object Transmission Information elements to the receiver(s) using the encoding format defined by the FEC scheme.
1. 使用由FEC方案定义的编码格式将公共FEC对象传输信息元素可靠地传送给接收机的装置。
2. An alternative, CDP-specific, encoding format for each of the Common FEC Object Transmission Information elements.
2. 每个公共FEC对象传输信息元素的替代的、CDP特定的编码格式。
The Mandatory and Common FEC Object Transmission Information elements are defined in the sections below.
强制性和通用FEC对象传输信息元素在以下各节中定义。
It is the responsibility of the CDP to reliably transport the FEC Object Transmission Information to the receiver(s).
CDP负责将FEC对象传输信息可靠地传输到接收机。
It is important to note that the encoding format of the Mandatory FEC Object Transmission Information elements (the FEC Encoding ID) is defined by the CDP. This is so that the receiver can identify the FEC Scheme to be used for interpreting the remaining FEC Object Transmission Information elements. All CDPs must define encoding formats for the Mandatory FEC Object Transmission Information element.
需要注意的是，强制FEC对象传输信息元素（FEC编码ID）的编码格式由CDP定义。这使得接收机能够识别用于解释剩余FEC对象传输信息元素的FEC方案。所有CDP必须为强制FEC对象传输信息元素定义编码格式。
Common FEC Object Transmission Information elements can be transported in two different ways: (a) the FEC Scheme defines an encoding format for the Common FEC Object Transmission Information elements that it uses, and the CDP transports this encoded data block, or (b) the CDP defines an encoding format for each Common FEC Object Transmission Information element and transports the information in this format.
公共FEC对象传输信息元素可以以两种不同的方式传输：（a）FEC方案为其使用的公共FEC对象传输信息元素定义编码格式，并且CDP传输该编码数据块，或者（b）CDP为每个公共FEC对象传输信息元素定义编码格式，并以此格式传输信息。
An FEC Scheme MUST define an encoding format for the Common FEC Object Transmission Information elements that it uses. The resulting octet string is known as the "encoded Common FEC Object Transmission Information". A CDP MAY define individual encoding formats for each of the Common FEC Object Transmission Information elements. The choice of which way the Common FEC Object Transmission Information elements shall be transported, (a) or (b), is made by the Content Delivery Protocol, and a particular method SHOULD be defined in the Content Delivery Protocol specification. Note that a CDP may provide support for one or both options.
FEC方案必须为其使用的公共FEC对象传输信息元素定义编码格式。产生的八位字节字符串称为“编码的公共FEC对象传输信息”。CDP可以为每个公共FEC对象传输信息元素定义单独的编码格式。公共FEC对象传输信息元素的传输方式（a）或（b）由内容交付协议决定，具体方法应在内容交付协议规范中定义。请注意，CDP可能支持一个或两个选项。
In the case that the CDP uses the encoding format specified by the FEC scheme, it may simply concatenate the encoded Common FEC Object Transmission Information and the encoded Scheme-specific FEC Object Transmission Information, or it may carry each in a separate field or wrapper within the CDP. In the former case, the concatenated octet string is known as the encoded FEC Object Transmission Information. The FEC scheme must define the encoding format for the Common FEC Object Transmission Information elements that it uses in such a way that the length of each element is either fixed or can be determined from the encoded data itself.
在CDP使用由FEC方案指定的编码格式的情况下，它可以简单地连接编码的公共FEC对象传输信息和编码的方案特定的FEC对象传输信息，或者它可以在CDP内的单独字段或包装中携带每一个。在前一种情况下，级联的八位字节字符串被称为编码的FEC对象传输信息。FEC方案必须定义其使用的公共FEC对象传输信息元素的编码格式，以便每个元素的长度是固定的，或者可以从编码数据本身确定。
The encoding format of the Scheme-specific FEC Object Transmission Information element is defined by the FEC scheme. CDPs specify only how the resulting octet sequence is communicated. As with the encoding format for the Common FEC Object Transmission Information elements, the length of the Scheme-specific FEC Object Transmission Information must either be fixed or be possible to determine from the encoded data itself.
方案特定FEC对象传输信息元素的编码格式由FEC方案定义。CDP仅指定产生的八位字节序列的通信方式。与公共FEC对象传输信息元素的编码格式一样，特定于方案的FEC对象传输信息的长度必须是固定的，或者可以从编码数据本身确定。
The Scheme-specific FEC Object Transmission Information element is opaque to the CDP in the sense that inspecting the contents of this element can only be done if FEC scheme-specific logic is included in the CDP.
方案特定的FEC对象传输信息元素对于CDP是不透明的，因为只有在CDP中包括FEC方案特定的逻辑时才能检查该元素的内容。
Any encoding formats defined by the FEC scheme for the Common FEC Object Transmission Information elements are also opaque to the CDP in the same sense.
由FEC方案为公共FEC对象传输信息元素定义的任何编码格式对CDP也是同样意义上的不透明的。
Any encoding formats defined by the CDP for the Common FEC Object Transmission Information elements are not opaque in this sense, although it must be considered that different FEC Schemes may use different combinations of the Common FEC Object Transmission Information elements.
在这个意义上，CDP为公共FEC对象传输信息元素定义的任何编码格式都不是不透明的，尽管必须考虑不同的FEC方案可以使用公共FEC对象传输信息元素的不同组合。
The Mandatory FEC Object Transmission Information element is:
强制FEC对象传输信息元素为：
FEC Encoding ID: an integer between 0 and 255 inclusive identifying a specific FEC scheme (Fully-Specified or Under-Specified.)
FEC编码ID：一个介于0和255（含0和255）之间的整数，用于标识特定的FEC方案（完全指定或未指定）
The Common FEC Object Transmission Information elements are described below. Note that with the exception of the FEC Instance ID, this specification does not provide complete definitions of these fields. Instead, only aspects of the abstract type are defined. The precise type and semantics are defined for each FEC scheme in the FEC scheme specification.
下面描述公共FEC对象传输信息元素。请注意，除FEC实例ID外，本规范未提供这些字段的完整定义。相反，只定义抽象类型的各个方面。FEC方案规范中为每个FEC方案定义了精确的类型和语义。
FEC Instance ID: an integer between 0 and 65535 inclusive identifying an instance of an Under-Specified FEC scheme
FEC实例ID：介于0和65535（含）之间的整数，用于标识指定FEC方案下的实例
Transfer-Length: a non-negative integer indicating the length of the object in octets
传输长度：一个非负整数，以八位字节表示对象的长度
Encoding-Symbol-Length: a non-negative integer indicating the length of each encoding symbol in octets
编码符号长度：一个非负整数，以八位字节表示每个编码符号的长度
Maximum-Source-Block-Length: a non-negative integer indicating the maximum number of source symbols in a source block
最大源块长度：一个非负整数，表示源块中源符号的最大数量
Max-Number-of-Encoding-Symbols: a non-negative integer indicating the maximum number of encoding symbols (i.e., source plus repair symbols in the case of a systematic code)
编码符号的最大数量：一个非负整数，表示编码符号的最大数量（即系统代码中的源加修复符号）
The FEC Instance ID MUST be used by all Under-Specified FEC schemes and MUST NOT be used by Fully-Specified FEC Schemes.
FEC实例ID必须由所有未指定的FEC方案使用，而不能由完全指定的FEC方案使用。
FEC Schemes define the precise type of those of the above elements that they use and in particular may restrict the value range of each element. FEC Schemes also define an encoding format for the subset of the above elements that they use. CDPs may also provide an encoding format for each element; in which case, this encoding format MUST be capable of representing values up to (2^^16)-1 in the case of the FEC Instance ID, (2^^48)-1 in the case of the Transfer-Length, and up to (2^^32)-1 for the other elements. CDPs may additionally or alternatively provide a mechanism to transport the encoded Common FEC Object Transmission information defined by the FEC scheme. For example, FLUTE [8] specifies an XML-based encoding format for these elements, but can also transport FEC scheme-specific encoding formats within the EXT-FTI LCT header extension.
FEC方案定义了它们使用的上述元素的精确类型，特别是可能限制每个元素的值范围。FEC方案还为它们使用的上述元素的子集定义编码格式。CDP还可以为每个元素提供编码格式；在这种情况下，对于FEC实例ID，此编码格式必须能够表示最多（2^^16）-1的值；对于传输长度，此编码格式必须能够表示最多（2^^48）-1的值；对于其他元素，此编码格式必须能够表示最多（2^^32）-1的值。cdp可附加地或替代地提供传输由FEC方案定义的经编码的公共FEC对象传输信息的机制。例如，FLUTE[8]为这些元素指定了基于XML的编码格式，但也可以在EXT-FTI LCT头扩展中传输FEC方案特定的编码格式。
The Scheme-specific FEC Object Transmission Information element may be used by an FEC Scheme to communicate information that is essential to the decoder and that cannot adequately be represented within the Mandatory or Common FEC Object Transmission Information elements.
特定于方案的FEC对象传输信息元素可由FEC方案用于传送对解码器至关重要且不能在强制性或公共FEC对象传输信息元素内充分表示的信息。
From the point of view of a CDP, the Scheme-specific FEC Object Transmission Information element is an opaque, variable length, octet string. The FEC Scheme defines the structure of this octet string, which may contain multiple distinct elements.
从CDP的角度来看，特定于方案的FEC对象传输信息元素是不透明的、可变长度的八位字节字符串。FEC方案定义了这个八进制字符串的结构，它可能包含多个不同的元素。
The FEC Payload ID contains information that indicates to the FEC decoder the relationships between the encoding symbols carried by a particular packet and the FEC encoding transformation. For example, if the packet carries source symbols, then the FEC Payload ID indicates which source symbols of the object are carried by the packet. If the packet carries repair symbols, then the FEC Payload
FEC有效载荷ID包含向FEC解码器指示由特定分组携带的编码符号与FEC编码转换之间的关系的信息。例如，如果分组携带源符号，则FEC有效负载ID指示分组携带对象的哪些源符号。如果数据包携带修复符号，则FEC有效载荷
ID indicates how those repair symbols were constructed from the object.
ID指示如何从对象构造这些修复符号。
The FEC Payload ID may also contain information about larger groups of encoding symbols of which those contained in the packet are part. For example, the FEC Payload ID may contain information about the source block the symbols are related to.
FEC有效载荷ID还可以包含关于分组中包含的编码符号是其一部分的较大编码符号组的信息。例如，FEC有效负载ID可以包含关于与符号相关的源块的信息。
The FEC Payload ID for a given packet is essential to the decoder if and only if the packet itself is received. Thus, it must be possible to obtain the FEC Payload ID from the received packet. Usually, the FEC Payload ID is simply carried explicitly as a separate field within each packet. In this case, the size of the FEC Payload ID field SHOULD be a small fraction of the packet size. Some FEC schemes may specify means for deriving the relationship between the carried encoding symbols and the object implicitly from other information within the packet, such as protocol headers already present. Such FEC schemes could obviously only be used with CDPs which provided the appropriate information from which the FEC Payload ID could be derived.
当且仅当接收到分组本身时，给定分组的FEC有效载荷ID对于解码器是必不可少的。因此，必须能够从接收到的分组获得FEC有效负载ID。通常，FEC有效负载ID只是作为每个分组中的单独字段显式携带。在这种情况下，FEC有效负载ID字段的大小应该是分组大小的一小部分。一些FEC方案可以指定用于从分组内的其他信息（例如已经存在的协议报头）隐式地导出所携带的编码符号和对象之间的关系的方法。这种FEC方案显然只能与cdp一起使用，cdp提供了适当的信息，从中可以导出FEC有效负载ID。
The encoding format of the FEC Payload ID, including its size, is defined by the FEC Scheme. CDPs specify how the FEC Payload ID is carried within data packets, i.e., the position of the FEC Payload ID within the CDP packet format and the how it is associated with encoding symbols.
FEC有效负载ID的编码格式（包括其大小）由FEC方案定义。CDP指定FEC有效负载ID在数据分组中的携带方式，即，FEC有效负载ID在CDP分组格式中的位置及其与编码符号的关联方式。
FEC schemes for systematic FEC codes (that is, those codes in which the original source data is included within the encoded data) MAY specify two FEC Payload ID formats, one for packets carrying only source symbols and another for packets carrying at least one repair symbol. CDPs must include an indication of which of the two FEC Payload ID formats is included in each packet if they wish to support such FEC Schemes.
用于系统FEC码（即，其中原始源数据包括在编码数据内的那些码）的FEC方案可以指定两种FEC有效载荷ID格式，一种用于仅携带源符号的分组，另一种用于携带至少一个修复符号的分组。如果CDP希望支持此类FEC方案，则CDP必须包括两种FEC有效负载ID格式中的哪一种包含在每个数据包中的指示。
A specification for a new FEC scheme MUST include the following things:
新FEC方案的规范必须包括以下内容：
1. The FEC Encoding ID value that uniquely identifies the FEC scheme. This value MUST be registered with IANA as described in Section 12.
1. 唯一标识FEC方案的FEC编码ID值。该值必须按照第12节所述向IANA注册。
2. The type, semantics, and encoding format of one or two FEC Payload IDs. Where two FEC Payload ID formats are specified, then the FEC scheme MUST be a systematic FEC code and one FEC Payload ID format MUST be designated for use with packets
2. 一个或两个FEC有效负载ID的类型、语义和编码格式。如果指定了两种FEC有效负载ID格式，则FEC方案必须是系统FEC代码，并且必须指定一种FEC有效负载ID格式用于数据包
carrying only source symbols, and the other FEC Payload ID format MUST be designated for use with packets carrying at least one repair symbol.
仅携带源符号，并且必须指定其他FEC有效负载ID格式，以便与携带至少一个修复符号的数据包一起使用。
3. The type and semantics of the FEC Object Transmission Information. The FEC Scheme MAY define additional restrictions on the type (including value range) of the Common FEC Object Transmission Information elements.
3. FEC对象传输信息的类型和语义。FEC方案可以定义对公共FEC对象传输信息元素的类型（包括值范围）的附加限制。
4. An encoding format for the Common FEC Object Transmission Information elements used by the FEC Scheme.
4. FEC方案使用的公共FEC对象传输信息元素的编码格式。
Fully-Specified FEC schemes MUST further specify:
完全指定的FEC方案必须进一步规定：
1. A full specification of the FEC code.
1. FEC代码的完整规范。
This specification MUST precisely define the valid FEC Object Transmission Information values, the valid FEC Payload ID values, and the valid packet payload sizes for any given object (where packet payload refers to the space -- not necessarily contiguous -- within a packet dedicated to carrying encoding symbol octets).
该规范必须精确定义任何给定对象的有效FEC对象传输信息值、有效FEC有效负载ID值和有效数据包有效负载大小（其中数据包有效负载指专用于承载编码符号八位字节的数据包内的空间，不一定是连续的）。
Furthermore, given an object, valid values for each of the FEC Object Transmission Information elements used by the FEC Scheme, a valid FEC Payload ID value, and a valid packet payload size, the specification MUST uniquely define the values of the encoding symbol octets to be included in the packet payload of a packet with the given FEC Payload ID value.
此外，给定对象、FEC方案使用的每个FEC对象传输信息元素的有效值、有效FEC有效载荷ID值和有效分组有效载荷大小，该规范必须唯一地定义编码符号八位字节的值，以包括在具有给定FEC有效负载ID值的分组的分组有效负载中。
A common and simple way to specify the FEC code to the required level of detail is to provide a precise specification of an encoding algorithm which, given an object, valid values for each of the FEC Object Transmission Information elements used by the FEC Scheme for the object, a valid FEC Payload ID, and packet payload length as input produces the exact value of the encoding symbol octets as output.
将FEC代码指定到所需详细程度的一种常见且简单的方法是提供编码算法的精确说明，该编码算法给定一个对象，该对象的FEC方案使用的每个FEC对象传输信息元素的有效值，有效的FEC有效载荷ID，数据包有效负载长度作为输入，产生编码符号八位字节的精确值作为输出。
2. A description of practical encoding and decoding algorithms.
2. 实用编码和解码算法的描述。
This description need not be to the same level of detail as for (1) above; however, it must be sufficient to demonstrate that encoding and decoding of the code is both possible and practical.
该说明不必与上述（1）的详细程度相同；然而，它必须足以证明编码和解码的代码是可行和实用的。
FEC scheme specifications MAY additionally define the following:
FEC方案规范可另外定义以下内容：
1. Type, semantics, and encoding format of a Scheme-specific FEC Object Transmission Information element.
1. 特定于方案的FEC对象传输信息元素的类型、语义和编码格式。
Note that if an FEC scheme does not define a Scheme-specific FEC Object Transmission Information element, then such an element MUST NOT be introduced in future versions of the FEC Scheme. This requirement is included to ensure backwards-compatibility of CDPs designed to support only FEC Schemes that do not use the Scheme-specific FEC Object Transmission Information element.
注意，如果FEC方案没有定义方案特定的FEC对象传输信息元素，则在FEC方案的未来版本中不得引入这样的元素。包括此要求是为了确保CDP的向后兼容性，CDP设计为仅支持不使用方案特定FEC对象传输信息元素的FEC方案。
Whenever an FEC scheme specification defines an 'encoding format' for an element, this must be defined in terms of a sequence of octets that can be embedded within a protocol. The length of the encoding format MUST either be fixed, or it must be possible to derive the length from examining the encoded octets themselves. For example, the initial octets may include some kind of length indication.
每当FEC方案规范定义元素的“编码格式”时，必须根据可嵌入到协议中的八位字节序列来定义。编码格式的长度必须是固定的，或者可以通过检查编码的八位字节本身来推导长度。例如，初始八位字节可以包括某种长度指示。
FEC schemes SHOULD make use of the Common FEC Object Transmission Information elements in preference to including information in a Scheme-specific FEC Object Transmission Information element.
FEC方案应当优先使用公共FEC对象传输信息元素，而不是将信息包括在方案特定的FEC对象传输信息元素中。
FEC scheme specifications SHOULD use the terminology defined in this document and SHOULD follow the following format:
FEC方案规范应使用本文件中定义的术语，并应遵循以下格式：
1. Introduction <define whether the scheme is Fully-Specified or Under-Specified>
1. 引言<定义方案是完全指定还是未指定>
<describe the use-cases addressed by this FEC scheme>
<描述此FEC方案解决的用例>
2. Formats and Codes
2. 格式和代码
2.1 FEC Payload ID(s) <define the type and format of one or two FEC Payload IDs>
2.1 FEC有效负载ID<定义一个或两个FEC有效负载ID的类型和格式>
2.2 FEC Object Transmission Information
2.2 对象传输信息
2.2.1 Mandatory <define the value of the FEC Encoding ID for this FEC scheme>
2.2.1 必填<定义此FEC方案的FEC编码ID的值>
2.2.2 Common <describe which Common FEC Object Transmission Information elements are used by this FEC scheme, define their value ranges, and define an encoding format for them>
2.2.2 Common<描述此FEC方案使用哪些公共FEC对象传输信息元素，定义它们的值范围，并为它们定义编码格式>
2.2.3 Scheme-Specific <define the Scheme-specific FEC Object Transmission Information, including an encoding format, if required>
2.2.3 特定于方案<定义特定于方案的FEC对象传输信息，包括编码格式，如果需要>
3. Procedures <describe any procedures that are specific to this FEC scheme, in particular derivation and interpretation of the fields in the FEC Payload ID and FEC Object Transmission Information.>
3. 过程<描述特定于此FEC方案的任何过程，特别是FEC有效载荷ID和FEC对象传输信息中字段的推导和解释。>
4. FEC code specification (for Fully-Specified FEC schemes only) <provide a complete specification of the FEC Code>
4. FEC代码规范（仅适用于完全指定的FEC方案）<提供FEC代码的完整规范>
Specifications MAY include additional sections such as those containing examples.
规范可能包括其他章节，如包含示例的章节。
Each FEC scheme MUST be specified independently of all other FEC schemes; for example, in a separate specification or a completely independent section of a larger specification.
必须独立于所有其他FEC方案指定每个FEC方案；例如，在单独的规范或更大规范的完全独立部分中。
A specification for a CDP that uses this building block MUST include the following things:
使用此构建块的CDP规范必须包括以下内容：
1. Definitions of an encoding format for the Mandatory FEC Object Transmission Information element.
1. 强制FEC对象传输信息元素的编码格式定义。
2. A means to reliably communicate the Mandatory FEC Object Transmission Information element from sender to receiver(s) using the encoding format defined in (1).
2. 一种使用（1）中定义的编码格式将强制FEC对象传输信息元素从发送方可靠地传送到接收方的方法。
3. Means to reliably communicate the Common FEC Object Transmission Information element from sender to receiver(s) using either or both of (a) the encoding format defined by the FEC Scheme or (b) encoding formats defined by the CDP
3. 用于使用（a）FEC方案定义的编码格式或（b）CDP定义的编码格式中的一种或两种从发送方到接收方可靠地传送公共FEC对象传输信息元素的装置
4. A means to reliably communicate the Scheme-specific FEC Object Transmission Information element from sender to receiver(s) using the encoding format of the Scheme-specific FEC Object Transmission Information element defined by the FEC scheme.
4. 使用由FEC方案定义的方案特定FEC对象传输信息元素的编码格式，将方案特定FEC对象传输信息元素从发送方可靠地传输到接收方的装置。
5. A means to communicate the FEC Payload ID in association with a data packet. Note that the encoding format of the FEC Payload ID is defined by the FEC Scheme.
5. 与数据分组相关联地传送FEC有效载荷ID的装置。注意，FEC有效负载ID的编码格式由FEC方案定义。
If option (b) of (3) above is used, then the CDP MUST specify an encoding format for the Common FEC Object Transmission Information elements.
如果使用上述（3）的选项（b），则CDP必须为公共FEC对象传输信息元素指定编码格式。
CDPs MAY additionally specify the following things:
CDP可另外规定以下事项：
1. A means to indicate whether the FEC Payload ID within a packet is encoded according to the format for packets including only source symbols or according to the format for packets including at least one repair symbol.
1. 指示分组内的FEC有效载荷ID是根据仅包括源符号的分组的格式还是根据包括至少一个修复符号的分组的格式进行编码的装置。
This section describes certain algorithms that are expected to be commonly required by FEC schemes or by CDPs. FEC Schemes and CDPs SHOULD use these algorithms in preference to scheme- or protocol-specific algorithms, where appropriate.
本节描述FEC方案或CDP通常需要的某些算法。在适当的情况下，FEC方案和CDP应优先使用这些算法，而不是方案或协议特定的算法。
This algorithm computes a partitioning of an object into source blocks so that all source blocks are as close to being equal length as possible. A first number of source blocks are of the same larger length, and the remaining second number of source blocks are of the same smaller length.
此算法将对象划分为源块，以便所有源块的长度尽可能接近相等。第一数量的源块具有相同的较大长度，剩余的第二数量的源块具有相同的较小长度。
This algorithm is described in two steps, the second of which may be useful in itself as an independent algorithm in some cases. In the first step, the number of source symbols (T) and the number of source blocks (N) are derived from the Object transfer length (L), Maximum Source Block Length (B), and Symbol Length (E).
该算法分两步描述，第二步在某些情况下作为独立算法本身可能很有用。在第一步中，源符号的数量（T）和源块的数量（N）从对象传输长度（L）、最大源块长度（B）和符号长度（E）导出。
In the second step, the partitioning of the object is derived from the number of source symbols (T) and the number of source blocks (N). The partitioning is defined in terms of a first number of source blocks (I), a second number of source blocks (N-I), the length of each of the first source blocks (A_large), and the length of each of the second source blocks (A_small).
在第二步中，从源符号的数量（T）和源块的数量（N）导出对象的分区。分区根据第一数量的源块（I）、第二数量的源块（N-I）、每个第一源块的长度（a_大）和每个第二源块的长度（a_小）来定义。
The following notation is used in the description below:
以下描述中使用了以下符号：
ceil[x] denotes x rounded up to the nearest integer.
ceil[x]表示x向上舍入到最接近的整数。
floor[x] denotes x rounded down to the nearest integer.
下限[x]表示x向下舍入到最接近的整数。
Input:
输入：
B -- Maximum Source Block Length, i.e., the maximum number of source symbols per source block
B——最大源块长度，即每个源块的最大源符号数
L -- Transfer Length in octets
L——以八位字节为单位的传输长度
E -- Encoding Symbol Length in octets
E——编码符号长度（以八位字节为单位）
Output:
输出：
T -- the number of source symbols in the object.
T——对象中源符号的数量。
N -- the number of source blocks into which the object shall be partitioned.
N——对象应划分到的源块数。
Algorithm:
算法：
1. The number of source symbols in the transport object is computed as T = ceil[L/E].
1. 传输对象中的源符号数计算为T=ceil[L/E]。
2. The transport object shall be partitioned into N = ceil[T/B] source blocks.
2. 传输对象应划分为N=ceil[T/B]源块。
Input:
输入：
T -- the number of source symbols in the object.
T——对象中源符号的数量。
N -- the number of source blocks into which the object is partitioned.
N—对象被分割到的源块数。
Output:
输出：
I -- the number of larger source blocks.
I——较大源块的数量。
A_large -- the length of each of the larger source blocks in symbols.
A_large——符号中每个较大源块的长度。
A_small -- the length of each of the smaller source blocks in symbols.
A_small——符号中每个较小源块的长度。
Algorithm:
算法：
1. A_large = ceil[T/N]
1. A_large=ceil[T/N]
2. A_small = floor[T/N]
2. A_small=楼层[T/N]
3. I = T - A_small * N
3. I=T-A_小*N
Each of the first I source blocks then consists of A_large source symbols; each source symbol is E octets in length. Each of the remaining N-I source blocks consist of A_small source symbols; each source symbol is E octets in length, except that the last source symbol of the last source block is L-((L-1)/E) rounded down to the nearest integer)*E octets in length.
然后，每个第一I源块由一个较大的源符号组成；每个源符号的长度为E个八位字节。剩余的N-I源块中的每一个由一个小源符号组成；每个源符号的长度为E个八位字节，但最后一个源块的最后一个源符号的长度为L-（（L-1）/E）四舍五入到最接近的整数）*E个八位字节。
The FEC building block does not provide any support for congestion control. Any complete CDP MUST provide congestion control that conforms to [6], and thus this MUST be provided by another building block when the FEC building block is used in a CDP.
FEC构建块不支持拥塞控制。任何完整的CDP必须提供符合[6]的拥塞控制，因此，当FEC构建块用于CDP时，必须由另一个构建块提供。
There are no other specific requirements from other building blocks for the use of this FEC building block. However, any CDP that uses the FEC building block may use other building blocks, for example, to provide support for sending higher level session information within data packets containing FEC encoding symbols.
对于该FEC构建块的使用，其他构建块没有其他具体要求。然而，使用FEC构建块的任何CDP例如可以使用其他构建块来提供对在包含FEC编码符号的数据分组内发送更高级别会话信息的支持。
Data delivery can be subject to denial-of-service attacks by attackers which send corrupted packets that are accepted as legitimate by receivers. This is particularly a concern for multicast delivery because a corrupted packet may be injected into the session close to the root of the multicast tree, in which case, the corrupted packet will arrive at many receivers. This is particularly a concern for the FEC building block because the use of even one corrupted packet containing encoding data may result in the decoding of an object that is completely corrupted and unusable. It is thus RECOMMENDED that source authentication and integrity checking are applied to decoded objects before delivering objects to an application. For example, a SHA-1 hash [7] of an object may be appended before transmission, and the SHA-1 hash is computed and checked after the object is decoded, but before it is delivered to an application. Source authentication SHOULD be provided, for example, by including a digital signature verifiable by the receiver and computed on top of the hash value. It is also RECOMMENDED that a packet authentication protocol such as Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [9] be used to detect and discard corrupted packets upon arrival. Furthermore, it is RECOMMENDED that Reverse Path Forwarding checks be enabled in all network routers and switches along the path from the sender to receivers to limit the possibility of a bad agent successfully injecting a corrupted packet into the multicast tree data path.
数据传输可能受到攻击者的拒绝服务攻击，攻击者发送被接收方视为合法的损坏数据包。这对于多播交付来说尤其令人担忧，因为损坏的分组可能被注入到靠近多播树根的会话中，在这种情况下，损坏的分组将到达多个接收机。这是FEC构建块特别关注的问题，因为即使使用一个包含编码数据的损坏分组也可能导致对完全损坏和不可用的对象进行解码。因此，建议在将对象交付给应用程序之前，对解码对象应用源身份验证和完整性检查。例如，对象的SHA-1散列[7]可以在传输之前追加，并且在解码对象之后但在将其交付给应用程序之前计算和检查SHA-1散列。应提供源认证，例如，通过包括可由接收器验证并在哈希值之上计算的数字签名。还建议使用诸如定时高效流丢失容忍认证（TESLA）[9]之类的分组认证协议来检测和丢弃到达时损坏的分组。此外，建议在从发送方到接收方的路径上的所有网络路由器和交换机中启用反向路径转发检查，以限制坏代理将损坏的数据包成功注入多播树数据路径的可能性。
Another security concern is that some FEC information may be obtained by receivers out-of-band in a session description, and if the session description is forged or corrupted, then the receivers will not use the correct protocol for decoding content from received packets. To avoid these problems, it is RECOMMENDED that measures be taken to prevent receivers from accepting incorrect session descriptions, e.g., by using source authentication to ensure that receivers only accept legitimate session descriptions from authorized senders.
另一个安全问题是，一些FEC信息可能由会话描述中的带外接收器获得，并且如果会话描述是伪造的或损坏的，则接收器将不会使用正确的协议来解码来自所接收分组的内容。为了避免这些问题，建议采取措施防止接收者接受不正确的会话描述，例如，通过使用源身份验证确保接收者只接受来自授权发送者的合法会话描述。
Values of FEC Encoding IDs and FEC Instance IDs are subject to IANA registration. They are in the registry named "Reliable Multicast Transport (RMT) FEC Encoding IDs and FEC Instance IDs" located at time of publication at: http://www.iana.org/assignments/rmt-fec-parameters
FEC编码ID和FEC实例ID的值受IANA注册的约束。它们位于发布时位于以下位置的名为“可靠多播传输（RMT）FEC编码ID和FEC实例ID”的注册表中：http://www.iana.org/assignments/rmt-fec-parameters
FEC Encoding IDs and FEC Instance IDs are hierarchical: FEC Encoding IDs scope independent ranges of FEC Instance IDs. Only FEC Encoding IDs that correspond to Under-Specified FEC schemes scope a corresponding set of FEC Instance IDs.
FEC编码ID和FEC实例ID是分层的：FEC编码ID作用域独立于FEC实例ID的范围。只有与指定的FEC方案对应的FEC编码ID才能作用于相应的FEC实例ID集。
The FEC Encoding ID and FEC Instance IDs are non-negative integers. In this document, the range of values for FEC Encoding IDs is 0 to 255. Values from 0 to 127 are reserved for Fully-Specified FEC schemes, and Values from 128 to 255 are reserved for Under-Specified FEC schemes, as described in more detail in Section 6.1.
FEC编码ID和FEC实例ID是非负整数。在本文档中，FEC编码ID的值范围为0到255。0到127之间的值为完全指定的FEC方案保留，128到255之间的值为未指定的FEC方案保留，详见第6.1节。
This document defines a name-space for FEC Encoding IDs named:
ietf:rmt:fec:encoding
This document defines a name-space for FEC Encoding IDs named:
ietf:rmt:fec:encoding
The values that can be assigned within the "ietf:rmt:fec:encoding" name-space are numeric indexes in the range [0, 255], boundaries included. Assignment requests are granted on a "IETF Consensus" basis as defined in [2]. Section 7 defines explicit requirements that documents defining new FEC Encoding IDs should meet.
可以在“ietf:rmt:fec:encoding”名称空间中分配的值是[0255]范围内的数字索引，包括边界。分配请求是在[2]中定义的“IETF共识”基础上批准的。第7节定义了定义新FEC编码ID的文件应满足的明确要求。
This document also defines a name-space for FEC Instance IDs named:
ietf:rmt:fec:encoding:instance
This document also defines a name-space for FEC Instance IDs named:
ietf:rmt:fec:encoding:instance
The "ietf:rmt:fec:encoding:instance" name-space is a sub-name-space associated with the "ietf:rmt:fec:encoding" name-space. Each value of "ietf:rmt:fec:encoding" assigned in the range [128, 255] has a separate "ietf:rmt:fec:encoding:instance" sub-name-space that it scopes. Values of "ietf:rmt:fec:encoding" in the range [0, 127] do not scope a "ietf:rmt:fec:encoding:instance" sub-name-space.
“ietf:rmt:fec:encoding:instance”名称空间是与“ietf:rmt:fec:encoding”名称空间关联的子名称空间。在[128255]范围内分配的“ietf:rmt:fec:encoding”的每个值都有一个单独的“ietf:rmt:fec:encoding:instance”子名称空间，其作用域为。范围[0127]中的“ietf:rmt:fec:encoding”的值不限定“ietf:rmt:fec:encoding:instance”子名称空间的范围。
The values that can be assigned within each "ietf:rmt:fec:encoding: instance" sub-name-space are non-negative integers less than 65536. Assignment requests are granted on a "First Come First Served" basis as defined in [2]. The same value of "ietf:rmt:fec:encoding: instance" can be assigned within multiple distinct sub-name-spaces, i.e., the same value of "ietf:rmt:fec:encoding:instance" can be used for multiple values of "ietf:rmt:fec:encoding".
每个“ietf:rmt:fec:encoding:instance”子名称空间中可以分配的值是小于65536的非负整数。按照[2]中的定义，“先到先得”的原则批准分配请求。“ietf:rmt:fec:encoding:instance”的相同值可以在多个不同的子名称空间中分配，即“ietf:rmt:fec:encoding:instance”的相同值可以用于“ietf:rmt:fec:encoding”的多个值。
Requestors of "ietf:rmt:fec:encoding:instance" assignments MUST provide the following information:
“ietf:rmt:fec:encoding:instance”分配的请求者必须提供以下信息：
o The value of "ietf:rmt:fec:encoding" that scopes the "ietf:rmt: fec:encoding:instance" sub-name-space. This must be in the range [128, 255].
o “ietf:rmt:fec:encoding”的值，其作用域为“ietf:rmt:fec:encoding:instance”子名称空间。这必须在[128255]范围内。
o Point of contact information
o 联络点信息
o A pointer to publicly accessible documentation describing the Under-Specified FEC scheme, associated with the value of "ietf: rmt:fec:encoding:instance" assigned, and a way to obtain it (e.g., a pointer to a publicly available reference-implementation or the name and contacts of a company that sells it, either separately or embedded in a product).
o 指向描述未指定FEC方案的公开可访问文档的指针，与分配的“ietf:rmt:FEC:encoding:instance”值关联，以及获取该值的方法（例如，指向公开可用的参考实现或销售该方案的公司的名称和联系人的指针，单独或嵌入到产品中）。
It is the responsibility of the requestor to keep all the above information up to date.
请求者有责任使上述所有信息保持最新。
This section lists the changes between the Experimental version of this specification, [3], and this version:
本节列出了本规范试验版本[3]与本版本之间的变化：
o The requirements for definition of a new FEC Scheme and the requirements for specification of new Content Delivery Protocols that use FEC Schemes are made more explicit to permit independent definition of FEC Schemes and Content Delivery Protocols.
o 新FEC方案的定义要求和使用FEC方案的新内容交付协议的规范要求更加明确，以允许独立定义FEC方案和内容交付协议。
o The definitions of basic FEC Schemes have been removed with the intention of publishing these separately.
o 已删除基本FEC方案的定义，目的是单独发布这些方案。
o The FEC Object Transmission Information (OTI) is more explicitly defined, and in particular, three classes of FEC OTI (Mandatory, Common, and Scheme-specific) are introduced to permit reusable definition of explicit fields in Content Delivery Protocols to carry these elements.
o 对FEC对象传输信息（OTI）进行了更明确的定义，特别是引入了三类FEC-OTI（强制、通用和特定于方案），以允许在内容交付协议中对显式字段进行可重用的定义，以承载这些元素。
o FEC Schemes are required to specify a complete encoding for the FEC Object Transmission, which can be carried transparently by Content Delivery protocols (instead of defining explicit elements).
o FEC方案需要为FEC对象传输指定一个完整的编码，该编码可以通过内容交付协议透明地传输（而不是定义显式元素）。
o The possibility for FEC Schemes to define two FEC Payload ID formats for use with source and repair packets, respectively, in the case of systematic FEC codes is introduced.
o 介绍了在系统FEC码的情况下，FEC方案定义两种FEC有效负载ID格式分别用于源数据包和修复数据包的可能性。
o The file blocking algorithm from FLUTE is included here as a common algorithm that is recommended to be reused by FEC Schemes when appropriate.
o 这里包含了来自FLUTE的文件阻塞算法，作为一种常见算法，建议FEC方案在适当时重用该算法。
This document is largely based on RFC 3452 [3], and thus thanks are due to the additional authors of that document: J. Gemmell, L. Rizzo, M. Handley, and J. Crowcroft.
本文件主要基于RFC 3452[3]，因此感谢该文件的其他作者：J.Gemmell、L.Rizzo、M.Handley和J.Crowcroft。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[2] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[3] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002.
[3] 卢比，M.，维西萨诺，L.，杰梅尔，J.，里佐，L.，汉德利，M.，和J.克罗夫特，“前向纠错（FEC）构建块”，RFC 3452，2002年12月。
[4] 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.
[4] Luby，M.，Vicisano，L.，Gemmell，J.，Rizzo，L.，Handley，M.，和J.Crowcroft，“在可靠多播中使用前向纠错（FEC）”，RFC 3453，2002年12月。
[5] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
[5] Kermode，R.和L.Vicisano，“可靠多播传输（RMT）构建块和协议实例化文档的作者指南”，RFC 3269，2002年4月。
[6] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[6] Mankin，A.，Romanov，A.，Bradner，S.，和V.Paxson，“评估可靠多播传输和应用协议的IETF标准”，RFC 2357，1998年6月。
[7] Federal Information Processing Standards Publication (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
[7] 联邦信息处理标准出版物（FIPS PUB）180-1，安全哈希标准，1995年4月17日。
[8] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, "FLUTE - File Delivery over Unidirectional Transport", RFC 3926, October 2004.
[8] Paila，T.，Luby，M.，Lehtonen，R.，Roca，V.，和R.Walsh，“长笛-单向传输上的文件交付”，RFC 3926，2004年10月。
[9] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005.
[9] Perrig，A.，Song，D.，Canetti，R.，Tygar，J.，和B.Briscoe，“定时高效流丢失容忍认证（TESLA）：多播源认证转换介绍”，RFC 40822005年6月。
[10] 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.
[10] Whetten，B.，Vicisano，L.，Kermode，R.，Handley，M.，Floyd，S.，和M.Luby，“一对多批量数据传输的可靠多播传输构建块”，RFC 3048，2001年1月。
Authors' Addresses
作者地址
Mark Watson Digital Fountain 39141 Civic Center Drive Suite 300 Fremont, CA 94538 U.S.A.
马克·沃森数字喷泉美国加利福尼亚州弗里蒙特市公民中心大道300号39141室，邮编94538。
EMail: mark@digitalfountain.com
EMail: mark@digitalfountain.com
Michael Luby Digital Fountain 39141 Civic Center Drive Suite 300 Fremont, CA 94538 U.S.A.
迈克尔·鲁比数字喷泉美国加利福尼亚州弗里蒙特市市中心大道300号39141室，邮编94538。
EMail: luby@digitalfountain.com
EMail: luby@digitalfountain.com
Lorenzo Vicisano Digital Fountain 39141 Civic Center Drive Suite 300 Fremont, CA 94538 U.S.A.
洛伦佐·维西萨诺数字喷泉美国加利福尼亚州弗里蒙特市市民中心大道300号39141室，邮编94538。
EMail: lorenzo@digitalfountain.com
EMail: lorenzo@digitalfountain.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。