Network Working Group M. Luby
Request for Comments: 3452 Digital Fountain
Category: Experimental L. Vicisano
Cisco
J. Gemmell
Microsoft
L. Rizzo
Univ. Pisa
M. Handley
ICIR
J. Crowcroft
Cambridge Univ.
December 2002
Network Working Group M. Luby
Request for Comments: 3452 Digital Fountain
Category: Experimental L. Vicisano
Cisco
J. Gemmell
Microsoft
L. Rizzo
Univ. Pisa
M. Handley
ICIR
J. Crowcroft
Cambridge Univ.
December 2002
Forward Error Correction (FEC) Building Block
前向纠错（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 (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document generally describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for data transport. The primary focus of this document is the application of FEC codes to one-to-many reliable data transport using IP multicast. This document describes what information is needed to identify a specific FEC code, what information needs to be communicated out-of-band to use the FEC code, and what information is needed in data packets to identify the encoding symbols they carry. The procedures for specifying FEC codes and registering them with the Internet Assigned Numbers Authority (IANA) are also described. This document should be read in conjunction with and uses the terminology of the companion document titled, "The Use of Forward Error Correction (FEC) in Reliable Multicast".
本文档通常描述如何使用前向纠错（FEC）代码有效地提供和/或增强数据传输的可靠性。本文档的主要重点是FEC代码在使用IP多播的一对多可靠数据传输中的应用。本文档描述了识别特定FEC代码所需的信息、使用FEC代码所需的带外通信信息以及数据包中识别其携带的编码符号所需的信息。还描述了指定FEC代码并将其注册到互联网分配号码管理局（IANA）的程序。本文件应结合标题为“可靠多播中前向纠错（FEC）的使用”的配套文件中的术语阅读并使用。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2. Rationale. . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Functionality. . . . . . . . . . . . . . . . . . . . . . . 3
3.1 FEC Encoding ID and FEC Instance ID. . . . . . . . . . . 5
3.2 FEC Payload ID and FEC Object Transmission Information . 6
4. Applicability Statement . . . . . . . . . . . . . . . . . 7
5. Packet Header Fields . . . . . . . . . . . . . . . . . . . 8
5.1 Small Block, Large Block and Expandable FEC Codes. . . . 8
5.2 Small Block Systematic FEC Codes . . . . . . . . . . . . 9
6. Requirements from other building blocks. . . . . . . . . . 11
7. Security Considerations. . . . . . . . . . . . . . . . . . 11
8. IANA Considerations. . . . . . . . . . . . . . . . . . . . 12
8.1 Explicit IANA Assignment Guidelines. . . . . . . . . . . 12
9. Intellectual Property Disclosure . . . . . . . . . . . . . 13
10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . 14
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 15
13. Full Copyright Statement . . . . . . . . . . . . . . . . . 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2. Rationale. . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Functionality. . . . . . . . . . . . . . . . . . . . . . . 3
3.1 FEC Encoding ID and FEC Instance ID. . . . . . . . . . . 5
3.2 FEC Payload ID and FEC Object Transmission Information . 6
4. Applicability Statement . . . . . . . . . . . . . . . . . 7
5. Packet Header Fields . . . . . . . . . . . . . . . . . . . 8
5.1 Small Block, Large Block and Expandable FEC Codes. . . . 8
5.2 Small Block Systematic FEC Codes . . . . . . . . . . . . 9
6. Requirements from other building blocks. . . . . . . . . . 11
7. Security Considerations. . . . . . . . . . . . . . . . . . 11
8. IANA Considerations. . . . . . . . . . . . . . . . . . . . 12
8.1 Explicit IANA Assignment Guidelines. . . . . . . . . . . 12
9. Intellectual Property Disclosure . . . . . . . . . . . . . 13
10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . 14
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 15
13. Full Copyright Statement . . . . . . . . . . . . . . . . . 16
This document describes how to use Forward Error Correction (FEC) codes to provide support for reliable delivery of content using IP multicast. This document should be read in conjunction with and uses the terminology of the companion document [4], 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）代码为使用IP多播的内容的可靠交付提供支持。本文件应结合并使用配套文件[4]的术语阅读，该文件描述了在可靠IP多播传输环境下FEC代码的使用，并介绍了一些常用的FEC代码。
This document describes a building block as defined in RFC 3048 [9]. This document is a product of the IETF RMT WG and follows the general guidelines provided in RFC 3269 [3].
本文件描述了RFC 3048[9]中定义的构建块。本文件是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 RFC2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC2119[2]中所述进行解释。
Statement of Intent
意向书
This memo contains part of the definitions necessary to fully specify a Reliable Multicast Transport protocol in accordance with RFC 2357. As per RFC 2357, the use of any reliable multicast protocol in the Internet requires an adequate congestion control scheme.
本备忘录包含根据RFC 2357完全指定可靠多播传输协议所需的部分定义。根据RFC2357，在互联网上使用任何可靠的多播协议都需要适当的拥塞控制方案。
While waiting for such a scheme to be available, or for an existing scheme to be proven adequate, the Reliable Multicast Transport working group (RMT) 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建议的标准重新提交。
FEC codes are a valuable basic component of any transport protocol that is to provide reliable delivery of content. Using FEC codes is valuable in the context of IP multicast and reliable delivery because FEC encoding symbols can be useful to all receivers for reconstructing content 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代码是任何传输协议的重要基本组件，用于提供可靠的内容交付。在IP多播和可靠传送的上下文中，使用FEC码是有价值的，因为FEC编码符号可用于所有接收机重构内容，即使接收机已接收到不同的编码符号。此外，FEC码可以改善甚至消除从接收器到发送者的反馈以请求丢失分组的重传的需要。
The goal of the FEC building block is to describe functionality directly related to FEC codes that is common to all reliable content delivery IP multicast protocols, and to leave out any additional functionality that is specific to particular protocols. The primary functionality described in this document that is common to all such protocols that use FEC codes are FEC encoding symbols for an object that is included in packets that flow from a sender to receivers. This document for example does not describe how receivers may request transmission of particular encoding symbols for an object. This is because although there are protocols where requests for transmission are of use, there are also protocols that do not require such requests.
FEC构建块的目标是描述与FEC代码直接相关的功能，这些功能是所有可靠内容交付IP多播协议所共有的，并且省略特定协议的任何附加功能。本文档中描述的使用FEC代码的所有此类协议所共有的主要功能是对象的FEC编码符号，该对象包括在从发送方流向接收方的包中。例如，本文档不描述接收机如何请求传输对象的特定编码符号。这是因为，尽管存在使用传输请求的协议，但也存在不需要此类请求的协议。
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多播。
This section describes FEC information that is either to be sent out-of-band or in packets. The FEC information is associated with transmission of data about 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 protocols may not use session-control or feedback packets.
本节描述将在带外或分组中发送的FEC信息。FEC信息与关于特定对象的数据的传输相关联。有三类数据包可能包含FEC信息：数据包、会话控制数据包和反馈数据包。它们通常包含不同种类的FEC信息。请注意，某些协议可能不使用会话控制或反馈数据包。
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.
数据包有时也可用作会话控制包；数据和会话控制数据包通常从发送方向接收方下行，并使用单播发送到多播信道或特定接收方。
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 the FEC information that must be carried in data packets and the other FEC information that must be communicated either out-of-band or in data packets. This document does not specify out-of-band methods nor does it specify the way out-of-band FEC information is associated with FEC information carried in data packets. These methods must be specified in a complete protocol instantiation that uses the FEC building block. FEC information is classified as follows:
本文件规定了必须在数据包中携带的FEC信息以及必须在带外或数据包中传输的其他FEC信息。本文件未规定带外方法，也未规定带外FEC信息与数据包中携带的FEC信息相关联的方式。这些方法必须在使用FEC构建块的完整协议实例化中指定。FEC信息分类如下：
1) FEC Encoding ID
1) FEC编码ID
Identifies the FEC encoder being used and allows receivers to select the appropriate FEC decoder. The value of the FEC Encoding ID MUST be the same for all transmission of data related to a particular object, but MAY vary across different transmissions of data about different objects, even if transmitted to the same set of multicast channels and/or using a single upper-layer session. The FEC Encoding ID is subject to IANA registration.
标识正在使用的FEC编码器，并允许接收机选择适当的FEC解码器。对于与特定对象相关的数据的所有传输，FEC编码ID的值必须相同，但在关于不同对象的数据的不同传输中可能不同，即使传输到同一组多播信道和/或使用单个上层会话。FEC编码ID需要IANA注册。
2) FEC Instance ID
2) FEC实例ID
Provides a more specific identification of the FEC encoder being used for an Under-Specified FEC scheme. This value is not used for Fully-Specified FEC schemes. (See Section 3.1 for the definition of Under-Specified and Fully-Specified FEC schemes.) The FEC Instance ID is scoped by the FEC Encoding ID, and is subject to IANA registration.
提供用于未指定FEC方案的FEC编码器的更具体标识。此值不用于完全指定的FEC方案。（有关未指定和完全指定的FEC方案的定义，请参见第3.1节。）FEC实例ID的范围由FEC编码ID确定，并接受IANA注册。
3) FEC Payload ID
3) 有效载荷ID
Identifies the encoding symbol(s) in the payload of the packet. The types and lengths of the fields in the FEC Payload ID, i.e., the format of the FEC Payload ID, are determined by the FEC Encoding ID. The full specification of each field MUST be uniquely determined by the FEC Encoding ID for Fully-Specified FEC schemes, and MUST be uniquely determined by the combination of the FEC Encoding ID and the FEC Instance ID for Under-Specified FEC schemes. As an example, for the Under-Specified FEC scheme with
标识数据包有效负载中的编码符号。FEC有效负载ID中字段的类型和长度，即FEC有效负载ID的格式，由FEC编码ID确定。对于完全指定的FEC方案，每个字段的完整规范必须由FEC编码ID唯一确定，并且必须由指定FEC方案下的FEC编码ID和FEC实例ID的组合唯一确定。例如，对于指定不足的FEC方案
FEC Encoding ID 129 defined in Section 5.1, the fields in the FEC Payload ID are a 32-bit Source Block Number followed by a 32-bit Encoding Symbol ID, where the full specification of both of these fields depends on the FEC Instance ID.
第5.1节中定义的FEC编码ID 129，FEC有效负载ID中的字段是32位源块号，后跟32位编码符号ID，其中这两个字段的完整规范取决于FEC实例ID。
4) FEC Object Transmission Information
4) 对象传输信息
This is information regarding the encoding of a specific object needed by the FEC decoder. As an example, for the Under-Specified FEC scheme with FEC Encoding ID 129 defined in Section 5.1, this information might include the lengths of the different source blocks that make up the object and the overall object length. This might also include specific parameters of the FEC encoder.
这是关于FEC解码器所需的特定对象的编码的信息。例如，对于第5.1节中定义的具有FEC编码ID 129的欠指定FEC方案，该信息可能包括组成对象的不同源块的长度和对象的总长度。这还可能包括FEC编码器的特定参数。
The FEC Encoding ID, FEC Instance ID (for Under-Specified FEC schemes) and 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. In any case, the means for communicating this to a receiver is outside the scope of this document. The FEC Payload ID MUST be included in the data packet header fields, as it provides a description of the encoding symbols contained in the packet.
FEC编码ID、FEC实例ID（对于未指定的FEC方案）和FEC对象传输信息可以在数据分组报头内、会话控制分组内或通过某种其他方式发送给接收机。在任何情况下，将此信息传达给接收者的方式不在本文件的范围内。FEC有效负载ID必须包含在数据包报头字段中，因为它提供了数据包中包含的编码符号的描述。
The FEC Encoding ID is a numeric index that identifies a specific FEC scheme OR a class of encoding schemes that share the same FEC Payload ID format.
FEC编码ID是一个数字索引，用于标识共享相同FEC有效负载ID格式的特定FEC方案或一类编码方案。
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. The FEC Encoding ID uniquely identifies a Fully-Specified FEC scheme. Companion documents of this specification may specify Fully-Specified FEC schemes and associate them with FEC Encoding ID values.
如果编码方案是正式和完全指定的，则FEC方案是完全指定的FEC方案，独立的实现者可以根据IETF RFC规范实现编码器和解码器。FEC编码ID唯一标识完全指定的FEC方案。本规范的配套文件可规定完全指定的FEC方案，并将其与FEC编码ID值相关联。
These documents MUST also specify a format for the FEC Payload ID and specify the information in the FEC Object Transmission Information.
这些文档还必须指定FEC有效负载ID的格式，并指定FEC对象传输信息中的信息。
It is possible that a 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 schemes as an Under-Specified FEC scheme. The following holds for an Under-Specified FEC scheme:
FEC方案可能不是完全指定的FEC方案，因为要么规范根本不可用，要么存在拥有编码方案并且不愿意公开算法或规范的一方。我们将这种FEC编码方案称为欠指定的FEC方案。对于未指定的FEC方案，以下情况适用：
o The fields and their formats of the FEC Payload ID and the specific information in the FEC Object Transmission Information MUST be defined for the Under-Specified FEC scheme.
o FEC有效负载ID的字段及其格式以及FEC对象传输信息中的特定信息必须为未指定的FEC方案定义。
o A value for the FEC Encoding ID MUST be reserved and associated with the fields and their formats of the FEC Payload ID and the specific information in the FEC Object Transmission Information. An already reserved FEC Encoding ID value MUST be reused if the associated FEC Payload ID has the same fields and formats and the FEC Object Transmission Information has same information as the ones needed for the new Under-Specified FEC scheme.
o FEC编码ID的值必须保留，并与FEC有效负载ID的字段及其格式以及FEC对象传输信息中的特定信息相关联。如果相关联的FEC有效负载ID具有相同的字段和格式，并且FEC对象传输信息具有与新的指定FEC方案所需的信息相同的信息，则必须重用已保留的FEC编码ID值。
o A value for the FEC Instance ID MUST be reserved.
o 必须保留FEC实例ID的值。
An Under-Specified FEC scheme is fully identified by the tuple (FEC Encoding ID, FEC Instance ID). The tuple MUST identify a single scheme 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 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）完全标识。元组必须标识至少有一个实现的单个方案。拥有此元组的一方必须能够提供有关如何获取元组标识的未充分指定的FEC方案的信息，例如，指向公开参考实现的指针或销售该方案的公司的名称和联系人，无论是单独的还是嵌入到另一个产品中的。
Different Under-Specified FEC schemes that share the same FEC Encoding ID -- but have different FEC Instance IDs -- also share the same fields and corresponding formats of the FEC Payload ID and specify the same information in the FEC Object Transmission Information.
共享相同FEC编码ID但具有不同FEC实例ID的不同指定FEC方案也共享相同字段和FEC有效负载ID的相应格式，并在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。
A document that specifies an FEC scheme and reserves a value of FEC Encoding ID MUST define the fields and their packet formats for the FEC Payload ID and specify the information in the FEC Object Transmission Information according to the needs of the encoding scheme. This applies to documents that reserve values of FEC Encoding IDs for both Fully-Specified and Under-Specified FEC schemes.
指定FEC方案并保留FEC编码ID值的文档必须定义FEC有效负载ID的字段及其分组格式，并根据编码方案的需要指定FEC对象传输信息中的信息。这适用于为完全指定和低于指定的FEC方案保留FEC编码ID值的文档。
The specification of the fields and their packet formats for the FEC Payload ID MUST specify the meaning of the fields and their format down to the level of specific bits. The total length of all the
FEC有效负载ID的字段及其数据包格式的规范必须指定字段的含义及其格式，直至特定位的级别。所有管道的总长度
fields in the FEC Payload ID MUST have a length that is a multiple of a 4-byte word. This requirement facilitates the alignment of packet fields in protocol instantiations.
FEC有效负载ID中的字段长度必须是4字节字的倍数。此要求有助于协议实例化中数据包字段的对齐。
The FEC building block applies to creating and sending encoding symbols for objects that are to be reliably transported using IP multicast or unicast. The FEC building block does not provide higher level session support. Thus, for example, many objects may be transmitted within the same session, in which case a higher level building block may carry a unique Transport Object ID (TOI) for each object in the session to allow the receiver to demultiplex packets within the session based on the TOI within each packet. As another example, a receiver may subscribe to more than one session at a time.
FEC构建块适用于为要使用IP多播或单播可靠传输的对象创建和发送编码符号。FEC构建块不提供更高级别的会话支持。因此，例如，许多对象可以在同一会话中传输，在这种情况下，更高级别的构建块可以为会话中的每个对象携带唯一的传输对象ID（TOI），以允许接收机基于每个分组中的TOI来解复用会话中的分组。作为另一个示例，接收器一次可以订阅多个会话。
In this case a higher level building block may carry a unique Transport Session ID (TSI) for each session to allow the receiver to demultiplex packets based on the TSI within each packet.
在这种情况下，更高级别的构建块可以为每个会话携带唯一的传输会话ID（TSI），以允许接收机基于每个分组内的TSI来解复用分组。
Other building blocks may supply direct support for carrying out-of-band information directly relevant to the FEC building block to receivers. For example, the length of the object is part of the FEC Object Transmission Information that may in some cases be communicated out-of-band to receivers, and one mechanism for providing this to receivers is within the context of another building block that provides this information.
其他构建块可向接收机提供直接支持，以执行与FEC构建块直接相关的带外信息。例如，对象的长度是FEC对象传输信息的一部分，在某些情况下，FEC对象传输信息可以在带外传送给接收机，并且向接收机提供该信息的一个机制在提供该信息的另一个构建块的上下文中。
Some protocols may use FEC codes as a mechanism for repairing the loss of packets. Within the context of FEC repair schemes, feedback packets are (optionally) used to request FEC retransmission. The FEC-related information present in feedback packets usually contains an FEC Block ID that defines the block that is being repaired, and the number of Repair Symbols requested. Although this is the most common case, variants are possible in which the receivers provide more specific information about the Repair Symbols requested (e.g., an index range or a list of symbols accepted). It is also possible to include multiple requests in a single feedback packet. This document does not provide any detail about feedback schemes used in combination with FEC nor the format of FEC information in feedback packets. If feedback packets are used in a complete protocol instantiation, these details must be provided in the protocol instantiation specification.
一些协议可以使用FEC代码作为修复数据包丢失的机制。在FEC修复方案的上下文中，反馈分组（可选地）用于请求FEC重传。反馈分组中存在的FEC相关信息通常包含FEC块ID，该FEC块ID定义正在被修复的块以及请求的修复符号的数量。尽管这是最常见的情况，但也可能出现接收器提供有关所请求的维修符号的更具体信息的变体（例如，索引范围或接受的符号列表）。还可以在单个反馈数据包中包含多个请求。本文件未提供与FEC结合使用的反馈方案的任何细节，也未提供反馈数据包中FEC信息的格式。如果在完整的协议实例化中使用反馈数据包，则必须在协议实例化规范中提供这些详细信息。
The FEC building block does not provide any support for congestion control. Any complete protocol MUST provide congestion control that conforms to RFC 2357 [5], and thus this MUST be provided by another building block when the FEC building block is used in a protocol.
FEC构建块不支持拥塞控制。任何完整的协议都必须提供符合RFC 2357[5]的拥塞控制，因此当FEC构建块用于协议时，必须由另一个构建块提供。
A more complete description of the applicability of FEC codes can be found in the companion document [4].
有关FEC代码适用性的更完整说明，请参见配套文件[4]。
This section specifies the FEC Encoding ID, the associated FEC Payload ID format, and the specific information in the FEC Object Transmission Information for a number of known Under-Specified FEC schemes. Under-Specified FEC schemes that use the same FEC Payload ID fields, formats, and specific information in the FEC Object Transmission Information (as for one of the FEC Encoding IDs specified in this section) MUST use the corresponding FEC Encoding ID. Other FEC Encoding IDs may be specified for other Under-Specified FEC schemes in companion documents.
本节规定了FEC编码ID、相关联的FEC有效负载ID格式，以及FEC对象传输信息中的特定信息，这些信息用于指定的FEC方案下的许多已知信息。在指定的FEC方案下，使用相同的FEC有效负载ID字段、格式和FEC对象传输信息中的特定信息（对于本节中指定的FEC编码ID之一）必须使用相应的FEC编码ID。其他FEC编码ID可以在附带文档中为其他未指定的FEC方案指定。
This subsection reserves the FEC Encoding ID value 128 for the Under-Specified FEC schemes described in [4] that are called Small Block FEC codes, Large Block FEC codes and Expandable FEC codes.
本小节为[4]中描述的未充分指定的FEC方案保留FEC编码ID值128，这些方案称为小块FEC码、大块FEC码和可扩展FEC码。
The FEC Payload ID is composed of a Source Block Number and an Encoding Symbol ID structured as follows:
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 Source Block Number identifies from which source block of the object the encoding symbol(s) in the payload are generated. These blocks are numbered consecutively from 0 to N-1, where N is the number of source blocks in the object.
源块编号标识有效负载中的编码符号是从对象的哪个源块生成的。这些块从0到N-1连续编号，其中N是对象中源块的数量。
The Encoding Symbol ID identifies which specific encoding symbol(s) generated from the source block are carried in the packet payload. The exact details of the correspondence between Encoding Symbol IDs and the encoding symbol(s) in the packet payload are dependent on the particular encoding algorithm used as identified by the FEC Encoding ID and by the FEC Instance ID, and these details may be proprietary.
编码符号ID标识从源块生成的哪些特定编码符号被携带在分组有效载荷中。编码符号ID和分组有效载荷中的编码符号之间的对应关系的确切细节取决于由FEC编码ID和FEC实例ID标识的使用的特定编码算法，并且这些细节可以是专有的。
The FEC Object Transmission Information has the following specific information:
FEC对象发送信息具有以下特定信息：
o The FEC Encoding ID 128.
o FEC编码ID为128。
o The FEC Instance ID associated with the FEC Encoding ID 128 to be used.
o 与要使用的FEC编码ID 128相关联的FEC实例ID。
o The total length of the object in bytes.
o 对象的总长度（以字节为单位）。
o The number of source blocks that the object is partitioned into, and the length of each source block in bytes.
o 对象被分割成的源块的数量，以及每个源块的长度（以字节为单位）。
To understand how this out-of-band information is communicated, one must look outside the scope of this document. One example may be that the source block lengths may be derived by a fixed algorithm from the object length. Another example may be that all source blocks are the same length and this is what is passed out-of-band to the receiver. A third example could be that the full sized source block length is provided and this is the length used for all but the last source block, which is calculated based on the full source block length and the object length.
要了解带外信息是如何传达的，必须查看本文档范围之外的内容。一个示例可以是源块长度可以通过固定算法从对象长度导出。另一个例子可能是，所有源块的长度相同，这就是带外传递给接收机的长度。第三个示例可能是提供了完整大小的源块长度，这是用于除最后一个源块以外的所有源块的长度，该长度是基于完整源块长度和对象长度计算的。
This subsection reserves the FEC Encoding ID value 129 for the Under-Specified FEC schemes described in [4] that are called Small Block Systematic FEC codes. For Small Block Systematic FEC codes, each source block is of length at most 65536 source symbols.
本小节为[4]中描述的被称为小块系统FEC码的欠指定FEC方案保留FEC编码ID值129。对于小分组系统FEC码，每个源块的长度最多为65536个源符号。
Although these codes can generally be accommodated by the FEC Encoding ID described in Section 5.1, a specific FEC Encoding ID is defined for Small Block Systematic FEC codes to allow more flexibility and to retain header compactness. The small source block length and small expansion factor that often characterize systematic codes may require the data source to frequently change the source block length. To allow the dynamic variation of the source block length and to communicate it to the receivers with low overhead, the block length is included in the FEC Payload ID.
尽管这些代码通常可以通过第5.1节中描述的FEC编码ID来容纳，但为小块系统FEC代码定义了特定的FEC编码ID，以允许更大的灵活性并保持报头的紧凑性。通常表征系统代码的小源块长度和小扩展因子可能要求数据源频繁更改源块长度。为了允许源块长度的动态变化并以低开销将其传送给接收机，块长度包括在FEC有效负载ID中。
The FEC Payload ID is composed of the Source Block Number, Source Block Length and the Encoding Symbol ID:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length | Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length | Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Source Block Number identifies from which source block of the object the encoding symbol(s) in the payload are generated. These blocks are numbered consecutively from 0 to N-1, where N is the number of source blocks in the object.
源块编号标识有效负载中的编码符号是从对象的哪个源块生成的。这些块从0到N-1连续编号，其中N是对象中源块的数量。
The Source Block Length is the length in units of source symbols of the source block identified by the Source Block Number.
源块长度是以源块编号标识的源块的源符号为单位的长度。
The Encoding Symbol ID identifies which specific encoding symbol(s) generated from the source block are carried in the packet payload. Each encoding symbol is either an original source symbol or a redundant symbol generated by the encoder. The exact details of the correspondence between Encoding Symbol IDs and the encoding symbol(s) in the packet payload are dependent on the particular encoding algorithm used as identified by the FEC Encoding ID and by the FEC Instance ID, and these details may be proprietary.
编码符号ID标识从源块生成的哪些特定编码符号被携带在分组有效载荷中。每个编码符号要么是原始源符号，要么是编码器生成的冗余符号。编码符号ID和分组有效载荷中的编码符号之间的对应关系的确切细节取决于由FEC编码ID和FEC实例ID标识的使用的特定编码算法，并且这些细节可以是专有的。
The FEC Object Transmission Information has the following specific information:
FEC对象发送信息具有以下特定信息：
o The FEC Encoding ID 129.
o FEC编码ID 129。
o The FEC Instance ID associated with the FEC Encoding ID 129 to be used.
o 与要使用的FEC编码ID 129相关联的FEC实例ID。
o The total length of the object in bytes.
o 对象的总长度（以字节为单位）。
o The maximum number of encoding symbols that can be generated for any source block. This field is provided for example to allow receivers to preallocate buffer space that is suitable for decoding to recover any source block.
o 可为任何源块生成的最大编码符号数。例如，提供该字段是为了允许接收机预先分配适合于解码的缓冲空间以恢复任何源块。
o For each source block, the length in bytes of encoding symbols for the source block.
o 对于每个源块，源块编码符号的字节长度。
How this out-of-band information is communicated is outside the scope of this document. As an example the length in bytes of encoding symbols for each source block may be the same for all source blocks. As another example, the encoding symbol length may be the same for all source blocks of a given object and this length is communicated for each object. As a third example, it may be that there is a threshold value I, and for all source blocks consisting of less than I source symbols, the encoding symbol length is one fixed number of bytes, but for all source blocks consisting of I or more source symbols, the encoding symbol length is a different fixed number of bytes.
如何传达带外信息超出了本文件的范围。例如，对于所有源块，每个源块的编码符号的字节长度可以相同。作为另一示例，对于给定对象的所有源块，编码符号长度可以相同，并且该长度针对每个对象进行通信。作为第三示例，可能存在阈值I，并且对于包含少于I个源符号的所有源块，编码符号长度是一个固定数量的字节，但是对于包含I个或多个源符号的所有源块，编码符号长度是不同的固定数量的字节。
Note that each encoding symbol, i.e., each source symbol and redundant symbol, must be the same length for a given source block, and this implies that each source block length is a multiple of its encoding symbol length. If the original source block length is not a multiple of the encoding symbol length, it is up to the sending application to appropriately pad the original source block to form the source block to be encoded, and to communicate this padding to the receiving application. The form of this padding, if used, and how it is communicated to the receiving application, is outside the scope of this document, and must be handled at the application level.
注意，对于给定的源块，每个编码符号（即每个源符号和冗余符号）必须具有相同的长度，这意味着每个源块长度是其编码符号长度的倍数。如果原始源块长度不是编码符号长度的倍数，则由发送应用程序适当地填充原始源块以形成要编码的源块，并将该填充传递给接收应用程序。此填充的形式（如果使用）以及如何将其传达给接收应用程序不在本文档的范围内，必须在应用程序级别进行处理。
The FEC building block does not provide any support for congestion control. Any complete protocol MUST provide congestion control that conforms to RFC 2357 [5], and thus this MUST be provided by another building block when the FEC building block is used in a protocol.
FEC构建块不支持拥塞控制。任何完整的协议都必须提供符合RFC 2357[5]的拥塞控制，因此当FEC构建块用于协议时，必须由另一个构建块提供。
There are no other specific requirements from other building blocks for the use of this FEC building block. However, any protocol that uses the FEC building block will inevitably use other building blocks for example to provide support for sending higher level session information within data packets containing FEC encoding symbols.
对于该FEC构建块的使用，其他构建块没有其他具体要求。然而，使用FEC构建块的任何协议将不可避免地使用其他构建块例如来提供对在包含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 to 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 the decoded objects be checked for integrity before delivering objects to an application. For example, an MD5 hash [8] of an object may be appended before transmission, and the MD5 hash is computed and checked after the object is decoded but before it is delivered to an application. Moreover, in order to obtain strong cryptographic integrity protection a digital signature verifiable by the receiver SHOULD be computed on top of such a hash value. It is also RECOMMENDED that a packet authentication protocol such as TESLA [7] 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
数据传输可能受到攻击者的拒绝服务攻击，攻击者发送被接收方视为合法的损坏数据包。这对于多播交付来说尤其令人担忧，因为损坏的分组可能被注入到靠近多播树根的会话中，在这种情况下，损坏的分组将到达多个接收机。这是FEC构建块特别关注的问题，因为即使使用一个包含编码数据的损坏分组也可能导致对完全损坏和不可用的对象进行解码。因此，建议在将对象交付给应用程序之前检查解码对象的完整性。例如，对象的MD5散列[8]可以在传输之前被追加，并且MD5散列在对象被解码之后但在其被交付到应用程序之前被计算和检查。此外，为了获得强大的密码完整性保护，应在此类散列值的基础上计算可由接收器验证的数字签名。还建议使用诸如TESLA[7]之类的数据包认证协议来检测和丢弃到达时损坏的数据包。此外，建议在所有网络路由器和交换机中启用反向路径转发检查
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.
沿着从发送方到接收方的路径，以限制坏代理将损坏的数据包成功注入多播树数据路径的可能性。
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. FEC Encoding IDs and FEC Instance IDs are hierarchical: FEC Encoding IDs scope 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的值受IANA注册的约束。FEC编码ID和FEC实例ID是分层的：FEC编码ID范围是FEC实例ID的范围。只有与指定的FEC方案对应的FEC编码ID才能作用于相应的FEC实例ID集。
The FEC Encoding ID is a numeric non-negative index. 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 3.1. This specification already assigns the values 128 and 129, as described in Section 5.
FEC编码ID是一个数字非负索引。在本文档中，FEC编码ID的值范围为0到255。0到127之间的值为完全指定的FEC方案保留，128到255之间的值为未指定的FEC方案保留，详见第3.1节。如第5节所述，本规范已经指定了值128和129。
Each FEC Encoding ID assigned to an Under-Specified FEC scheme scopes an independent range of FEC Instance IDs (i.e., the same value of FEC Instance ID can be reused for different FEC Encoding IDs). An FEC Instance ID is a numeric non-negative index.
分配给未充分指定的FEC方案的每个FEC编码ID限定FEC实例ID的独立范围（即，相同的FEC实例ID值可用于不同的FEC编码ID）。FEC实例ID是数字非负索引。
This document defines a name-space for FEC Encoding IDs named:
本文档定义了FEC编码ID的名称空间，名称为：
ietf:rmt:fec:encoding
ietf:rmt:fec:encoding
IANA has established and manages the new registry for the "ietf:rmt:fec:encoding" name-space. 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 "Specification Required" basis as defined in RFC 2434 [6]: An IETF RFC MUST exist and specify the FEC Payload ID fields and formats as well as the FEC Object Transmission Information for the value of "ietf:rmt:fec:encoding" (FEC Encoding ID) being assigned by IANA (see Section 3.1 for more details). Note that the values 128
IANA已经为“ietf:rmt:fec:encoding”名称空间建立并管理了新的注册表。可以在“ietf:rmt:fec:encoding”名称空间中分配的值是[0255]范围内的数字索引，包括边界。分配请求根据RFC 2434[6]中定义的“所需规范”予以批准：IETF RFC必须存在，并为IANA分配的“IETF:rmt:FEC:encoding”（FEC编码ID）的值指定FEC有效载荷ID字段和格式以及FEC对象传输信息（更多详细信息，请参见第3.1节）。请注意，值为128
and 129 of "ietf:rmt:fec:encoding" are already assigned by this document as described in Section 5.
“ietf:rmt:fec:encoding”的第129条和第129条已由本文件指定，如第5节所述。
This document also defines a name-space for FEC Instance IDs named:
本文档还定义了FEC实例ID的名称空间，名称为：
ietf:rmt:fec:encoding:instance
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 numeric indices. Assignment requests are granted on a "First Come First Served" basis as defined in RFC 2434 [6]. 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”子名称空间中分配的值是非负数字索引。根据RFC 2434[6]中的定义，分配请求以“先到先得”的方式授予。“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.
请求者有责任使上述所有信息保持最新。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETF已收到关于本文件所含部分或全部规范的知识产权声明。有关更多信息，请查阅在线权利主张列表。
Brian Adamson contributed to this document by shaping Section 5.2 and providing general feedback. We also wish to thank Vincent Roca, Justin Chapweske and Roger Kermode for their extensive comments.
Brian Adamson通过形成第5.2节并提供一般反馈为本文件做出了贡献。我们还要感谢文森特·罗卡、贾斯汀·查普韦斯克和罗杰·克莫德的广泛评论。
[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, "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] 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] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[6] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[7] Perrig, A., Canetti, R., Song, D. and J. Tygar, "Efficient and Secure Source Authentication for Multicast", Network and Distributed System Security Symposium, NDSS 2001, pp. 35-46, February 2001.
[7] Perrig，A.，Canetti，R.，Song，D.和J.Tygar，“多播的高效和安全源认证”，网络和分布式系统安全研讨会，NDSS 2001，第35-46页，2001年2月。
[8] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[8] Rivest，R.，“MD5消息摘要算法”，RFC1321，1992年4月。
[9] 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.
[9] Whetten，B.，Vicisano，L.，Kermode，R.，Handley，M.，Floyd，S.和M.Luby，“一对多批量数据传输的可靠多播传输构建块”，RFC 3048，2001年1月。
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
Jim Gemmell Microsoft Research 455 Market St. #1690 San Francisco, CA, 94105
吉姆GMMELL微软研究455市场S.Syz 1690旧金山，CA，94105
EMail: jgemmell@microsoft.com
EMail: jgemmell@microsoft.com
Luigi Rizzo Dip. di Ing. dell'Informazione Universita` di Pisa via Diotisalvi 2, 56126 Pisa, Italy
路易吉·里佐·迪普。迪宁。意大利比萨信息大学经迪奥蒂萨尔维256126
EMail: luigi@iet.unipi.it
EMail: luigi@iet.unipi.it
Mark Handley ICSI Center for Internet Research 1947 Center St. Berkeley CA, USA, 94704
马克·汉德利ICSI互联网研究中心1947年加利福尼亚州圣伯克利中心，美国，94704
EMail: mjh@icir.org
EMail: mjh@icir.org
Jon Crowcroft Marconi Professor of Communications Systems University of Cambridge Computer Laboratory William Gates Building J J Thomson Avenue Cambridge CB3 0FD
Jon Crowcroft Marconi通信系统教授剑桥大学计算机实验室威廉盖茨大厦J J汤姆逊大道剑桥CB3 0FD
EMail: Jon.Crowcroft@cl.cam.ac.uk
EMail: Jon.Crowcroft@cl.cam.ac.uk
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。