Internet Engineering Task Force (IETF) M. Watson
Request for Comments: 6363 Netflix, Inc.
Category: Standards Track A. Begen
ISSN: 2070-1721 Cisco
V. Roca
INRIA
October 2011
Internet Engineering Task Force (IETF) M. Watson
Request for Comments: 6363 Netflix, Inc.
Category: Standards Track A. Begen
ISSN: 2070-1721 Cisco
V. Roca
INRIA
October 2011
Forward Error Correction (FEC) Framework
前向纠错（FEC）框架
Abstract
摘要
This document describes a framework for using Forward Error Correction (FEC) codes with applications in public and private IP networks to provide protection against packet loss. The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. This framework can be used to define Content Delivery Protocols that provide FEC for streaming media delivery or other packet flows. Content Delivery Protocols defined using this framework can support any FEC scheme (and associated FEC codes) that is compliant with various requirements defined in this document. Thus, Content Delivery Protocols can be defined that are not specific to a particular FEC scheme, and FEC schemes can be defined that are not specific to a particular Content Delivery Protocol.
本文档描述了在公共和专用IP网络中使用前向纠错（FEC）代码以提供数据包丢失保护的框架。该框架支持将FEC应用于不可靠传输上的任意数据包流，主要用于实时或流媒体。此框架可用于定义为流媒体交付或其他数据包流提供FEC的内容交付协议。使用此框架定义的内容交付协议可以支持符合本文档中定义的各种需求的任何FEC方案（以及相关FEC代码）。因此，可以定义不特定于特定FEC方案的内容递送协议，并且可以定义不特定于特定内容递送协议的FEC方案。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6363.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6363.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
2. Definitions and Abbreviations ...................................5
3. Architecture Overview ...........................................7
4. Procedural Overview ............................................11
4.1. General ...................................................11
4.2. Sender Operation ..........................................13
4.3. Receiver Operation ........................................15
5. Protocol Specification .........................................19
5.1. General ...................................................19
5.2. Structure of the Source Block .............................19
5.3. Packet Format for FEC Source Packets ......................19
5.3.1. Generic Explicit Source FEC Payload ID .............21
5.4. Packet Format for FEC Repair Packets ......................21
5.4.1. Packet Format for FEC Repair Packets over RTP ......22
5.5. FEC Framework Configuration Information ...................22
5.6. FEC Scheme Requirements ...................................24
6. Feedback .......................................................26
7. Transport Protocols ............................................27
8. Congestion Control .............................................27
8.1. Motivation ................................................27
8.2. Normative Requirements ....................................29
9. Security Considerations ........................................29
9.1. Problem Statement .........................................29
9.2. Attacks against the Data Flows ............................31
9.2.1. Access to Confidential Content .....................31
9.2.2. Content Corruption .................................32
9.3. Attacks against the FEC Parameters ........................33
9.4. When Several Source Flows Are to Be Protected Together ....33
9.5. Baseline Secure FEC Framework Operation ...................34
10. Operations and Management Considerations ......................35
10.1. What Are the Key Aspects to Consider? ....................35
10.2. Operational and Management Recommendations ...............36
11. IANA Considerations ...........................................39
12. Acknowledgments ...............................................39
13. References ....................................................40
13.1. Normative References .....................................40
13.2. Informative References ...................................40
1. Introduction ....................................................3
2. Definitions and Abbreviations ...................................5
3. Architecture Overview ...........................................7
4. Procedural Overview ............................................11
4.1. General ...................................................11
4.2. Sender Operation ..........................................13
4.3. Receiver Operation ........................................15
5. Protocol Specification .........................................19
5.1. General ...................................................19
5.2. Structure of the Source Block .............................19
5.3. Packet Format for FEC Source Packets ......................19
5.3.1. Generic Explicit Source FEC Payload ID .............21
5.4. Packet Format for FEC Repair Packets ......................21
5.4.1. Packet Format for FEC Repair Packets over RTP ......22
5.5. FEC Framework Configuration Information ...................22
5.6. FEC Scheme Requirements ...................................24
6. Feedback .......................................................26
7. Transport Protocols ............................................27
8. Congestion Control .............................................27
8.1. Motivation ................................................27
8.2. Normative Requirements ....................................29
9. Security Considerations ........................................29
9.1. Problem Statement .........................................29
9.2. Attacks against the Data Flows ............................31
9.2.1. Access to Confidential Content .....................31
9.2.2. Content Corruption .................................32
9.3. Attacks against the FEC Parameters ........................33
9.4. When Several Source Flows Are to Be Protected Together ....33
9.5. Baseline Secure FEC Framework Operation ...................34
10. Operations and Management Considerations ......................35
10.1. What Are the Key Aspects to Consider? ....................35
10.2. Operational and Management Recommendations ...............36
11. IANA Considerations ...........................................39
12. Acknowledgments ...............................................39
13. References ....................................................40
13.1. Normative References .....................................40
13.2. Informative References ...................................40
Many applications have a requirement to transport a continuous stream of packetized data from a source (sender) to one or more destinations (receivers) over networks that do not provide guaranteed packet delivery. Primary examples are real-time, or streaming, media applications such as broadcast, multicast, or on-demand forms of audio, video, or multimedia.
许多应用程序都要求通过不提供包传递保证的网络将连续的包化数据流从源（发送方）传输到一个或多个目的地（接收方）。主要示例是实时或流媒体应用程序，如广播、多播或音频、视频或多媒体的按需形式。
Forward Error Correction (FEC) is a well-known technique for improving the reliability of packet transmission over networks that do not provide guaranteed packet delivery, especially in multicast and broadcast applications. The FEC Building Block, defined in [RFC5052], provides a framework for the definition of Content Delivery Protocols (CDPs) for object delivery (including, primarily, file delivery) that make use of separately defined FEC schemes. Any CDP defined according to the requirements of the FEC Building Block can then easily be used with any FEC scheme that is also defined according to the requirements of the FEC Building Block.
前向纠错（FEC）是一种众所周知的技术，用于在不提供保证的数据包交付的网络上提高数据包传输的可靠性，特别是在多播和广播应用中。[RFC5052]中定义的FEC构建块为使用单独定义的FEC方案的对象交付（主要包括文件交付）的内容交付协议（CDP）定义提供了一个框架。然后，根据FEC构建块的要求定义的任何CDP可以容易地与也根据FEC构建块的要求定义的任何FEC方案一起使用。
Note that the term "Forward Erasure Correction" is sometimes used, erasures being a type of error in which data is lost and this loss can be detected, rather than being received in corrupted form. The focus of this document is strictly on erasures, and the term "Forward Error Correction" is more widely used.
请注意，有时使用术语“前向擦除校正”，擦除是一种错误类型，其中数据丢失并且可以检测到该丢失，而不是以损坏的形式接收。本文件的重点是严格的擦除，术语“前向纠错”的使用更为广泛。
This document defines a framework for the definition of CDPs that provide for FEC protection for arbitrary packet flows over unreliable transports such as UDP. As such, this document complements the FEC Building Block of [RFC5052], by providing for the case of arbitrary packet flows over unreliable transport, the same kind of framework as that document provides for object delivery. This document does not define a complete CDP; rather, it defines only those aspects that are expected to be common to all CDPs based on this framework.
本文档定义了一个CDP定义框架，该框架为通过不可靠传输（如UDP）的任意数据包流提供FEC保护。因此，本文件补充了[RFC5052]的FEC构建块，为不可靠传输上的任意数据包流提供了与该文件提供的对象交付相同的框架。本文件未定义完整的CDP；相反，它仅定义了基于此框架的所有CDP所共有的方面。
This framework does not define how the flows to be protected are determined, nor does it define how the details of the protected flows and the FEC streams that protect them are communicated from sender to receiver. It is expected that any complete CDP specification that makes use of this framework will address these signaling requirements. However, this document does specify the information that is required by the FEC Framework at the sender and receiver, e.g., details of the flows to be FEC protected, the flow(s) that will carry the FEC protection data, and an opaque container for FEC-Scheme-Specific Information.
该框架没有定义如何确定要保护的流，也没有定义受保护流的细节以及保护它们的FEC流如何从发送方传递到接收方。预计任何使用该框架的完整CDP规范都将满足这些信令需求。然而，本文件确实规定了发送方和接收方的FEC框架所需的信息，例如，需要FEC保护的流的详细信息、将携带FEC保护数据的流以及FEC方案特定信息的不透明容器。
FEC schemes designed for use with this framework must fulfill a number of requirements defined in this document. These requirements are different from those defined in [RFC5052] for FEC schemes for object delivery. However, there is a great deal of commonality, and FEC schemes defined for object delivery may be easily adapted for use with the framework defined in this document.
设计用于此框架的FEC方案必须满足本文件中定义的许多要求。这些要求与[RFC5052]中针对对象交付的FEC方案定义的要求不同。然而，有很多共同点，并且为对象交付定义的FEC方案可以很容易地适用于本文档中定义的框架。
Since RTP [RFC3550] is (often) used over UDP, this framework can be applied to RTP flows as well. FEC repair packets may be sent directly over UDP or RTP. The latter approach has the advantage that RTP instrumentation, based on the RTP Control Protocol (RTCP), can be used for the repair flow. Additionally, the post-repair RTCP extended reports [RFC5725] may be used to obtain information about the loss rate after FEC recovery.
由于RTP[RFC3550]通常通过UDP使用，因此该框架也可以应用于RTP流。FEC修复数据包可以直接通过UDP或RTP发送。后一种方法的优点是，基于RTP控制协议（RTCP）的RTP检测可用于维修流程。此外，修复后RTCP扩展报告[RFC5725]可用于获取FEC恢复后的丢失率信息。
The use of RTP for repair flows is defined for each FEC scheme by defining an RTP payload format for that particular FEC scheme (possibly in the same document).
通过为特定FEC方案（可能在同一文档中）定义RTP有效负载格式，为每个FEC方案定义RTP用于修复流。
Application Data Unit (ADU): The unit of source data provided as payload to the transport layer.
应用数据单元（ADU）：作为有效负载提供给传输层的源数据单元。
ADU Flow: A sequence of ADUs associated with a transport-layer flow identifier (such as the standard 5-tuple {source IP address, source port, destination IP address, destination port, transport protocol}).
ADU流：与传输层流标识符（如标准5元组{源IP地址、源端口、目标IP地址、目标端口、传输协议}）关联的ADU序列。
AL-FEC: Application-layer Forward Error Correction.
AL-FEC：应用层前向纠错。
Application Protocol: Control protocol used to establish and control the source flow being protected, e.g., the Real-Time Streaming Protocol (RTSP).
应用协议：用于建立和控制受保护的源流的控制协议，例如实时流协议（RTSP）。
Content Delivery Protocol (CDP): A complete application protocol specification that, through the use of the framework defined in this document, is able to make use of FEC schemes to provide FEC capabilities.
内容交付协议（CDP）：一个完整的应用程序协议规范，通过使用本文档中定义的框架，能够利用FEC方案来提供FEC功能。
FEC Code: An algorithm for encoding data such that the encoded data flow is resilient to data loss. Note that, in general, FEC codes may also be used to make a data flow resilient to corruption, but that is not considered in this document.
FEC编码：一种编码数据的算法，使得编码后的数据流能够抵抗数据丢失。请注意，一般来说，FEC代码也可用于使数据流具有抗损坏能力，但本文档中未考虑这一点。
FEC Framework: A protocol framework for the definition of Content Delivery Protocols using FEC, such as the framework defined in this document.
FEC框架：使用FEC定义内容交付协议的协议框架，如本文档中定义的框架。
FEC Framework Configuration Information: Information that controls the operation of the FEC Framework.
FEC框架配置信息：控制FEC框架操作的信息。
FEC Payload ID: Information that identifies the contents of a packet with respect to the FEC scheme.
FEC有效负载ID：标识与FEC方案相关的数据包内容的信息。
FEC Repair Packet: At a sender (respectively, at a receiver), a payload submitted to (respectively, received from) the transport protocol containing one or more repair symbols along with a Repair FEC Payload ID and possibly an RTP header.
FEC修复包：在发送方（分别在接收方），提交（分别从）传输协议的有效载荷，包含一个或多个修复符号以及修复FEC有效载荷ID和可能的RTP报头。
FEC Scheme: A specification that defines the additional protocol aspects required to use a particular FEC code with the FEC Framework.
FEC方案：定义在FEC框架中使用特定FEC代码所需的附加协议方面的规范。
FEC Source Packet: At a sender (respectively, at a receiver), a payload submitted to (respectively, received from) the transport protocol containing an ADU along with an optional Explicit Source FEC Payload ID.
FEC源数据包：在发送方（分别在接收方），提交给（分别从）包含ADU的传输协议的有效载荷以及可选的显式源FEC有效载荷ID。
Protection Amount: The relative increase in data sent due to the use of FEC.
保护量：由于使用FEC而发送的数据的相对增加量。
Repair Flow: The packet flow carrying FEC data.
修复流：承载FEC数据的数据包流。
Repair FEC Payload ID: A FEC Payload ID specifically for use with repair packets.
修复FEC有效负载ID：专门用于修复数据包的FEC有效负载ID。
Source Flow: The packet flow to which FEC protection is to be applied. A source flow consists of ADUs.
源流：应用FEC保护的数据包流。源流由ADU组成。
Source FEC Payload ID: A FEC Payload ID specifically for use with source packets.
源FEC有效负载ID：专门用于源数据包的FEC有效负载ID。
Source Protocol: A protocol used for the source flow being protected, e.g., RTP.
源协议：用于受保护的源流的协议，例如RTP。
Transport Protocol: The protocol used for the transport of the source and repair flows, e.g., UDP and the Datagram Congestion Control Protocol (DCCP).
传输协议：用于传输源流和修复流的协议，例如UDP和数据报拥塞控制协议（DCCP）。
The following definitions are aligned with [RFC5052]:
以下定义与[RFC5052]一致：
Code Rate: The ratio between the number of source symbols and the number of encoding symbols. By definition, the code rate is such that 0 < code rate <= 1. A code rate close to 1 indicates that a small number of repair symbols have been produced during the encoding process.
码率：源符号数与编码符号数的比率。根据定义，编码率为0<编码率<=1。接近1的码率表示在编码过程中产生了少量修复符号。
Encoding Symbol: Unit of data generated by the encoding process. With systematic codes, source symbols are part of the encoding symbols.
编码符号：编码过程产生的数据单位。对于系统代码，源符号是编码符号的一部分。
Packet Erasure Channel: A communication path where packets are either dropped (e.g., by a congested router, or because the number of transmission errors exceeds the correction capabilities of the physical-layer codes) or received. When a packet is received, it is assumed that this packet is not corrupted.
数据包擦除信道：数据包被丢弃（例如，被拥塞的路由器丢弃，或者因为传输错误的数量超过了物理层代码的纠正能力）或被接收的通信路径。当接收到数据包时，假定该数据包未损坏。
Repair Symbol: Encoding symbol that is not a source symbol.
修复符号：编码非源符号的符号。
Source Block: Group of ADUs that are to be FEC protected as a single block.
源块：作为单个块受FEC保护的ADU组。
Source Symbol: Unit of data used during the encoding process.
源符号：编码过程中使用的数据单位。
Systematic Code: FEC code in which the source symbols are part of the encoding symbols.
系统代码：FEC代码，其中源符号是编码符号的一部分。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The FEC Framework is described in terms of an additional layer between the transport layer (e.g., UDP or DCCP) and protocols running over this transport layer. As such, the data path interface between the FEC Framework and both underlying and overlying layers can be thought of as being the same as the standard interface to the transport layer; i.e., the data exchanged consists of datagram payloads each associated with a single ADU flow identified by the standard 5-tuple {source IP address, source port, destination IP address, destination port, transport protocol}. In the case that RTP is used for the repair flows, the source and repair data can be multiplexed using RTP onto a single UDP flow and needs to be consequently demultiplexed at the receiver. There are various ways in which this multiplexing can be done (for example, as described in [RFC4588]).
FEC框架根据传输层（例如UDP或DCCP）和在该传输层上运行的协议之间的附加层来描述。因此，FEC框架与底层和覆盖层之间的数据路径接口可以被认为与传输层的标准接口相同；i、 例如，交换的数据由数据报有效载荷组成，每个数据报有效载荷与标准5元组{源IP地址、源端口、目标IP地址、目标端口、传输协议}标识的单个ADU流相关联。在RTP用于修复流的情况下，可以使用RTP将源数据和修复数据复用到单个UDP流上，因此需要在接收器处解复用。可以通过多种方式实现多路复用（例如，如[RFC4588]中所述）。
It is important to understand that the main purpose of the FEC Framework architecture is to allocate functional responsibilities to separately documented components in such a way that specific instances of the components can be combined in different ways to describe different protocols.
重要的是要理解，FEC框架体系结构的主要目的是将功能职责分配给单独记录的组件，以使组件的特定实例可以以不同的方式组合，以描述不同的协议。
The FEC Framework makes use of a FEC scheme, in a similar sense to that defined in [RFC5052], and uses the terminology of that document. The FEC scheme defines the FEC encoding and decoding, and it defines the protocol fields and procedures used to identify packet payload data in the context of the FEC scheme. The interface between the FEC
FEC框架使用FEC方案（与[RFC5052]中定义的方案类似），并使用该文件的术语。FEC方案定义FEC编码和解码，并定义用于在FEC方案的上下文中识别分组有效载荷数据的协议字段和过程。FEC与FEC之间的接口
Framework and a FEC scheme, which is described in this document, is a logical one that exists for specification purposes only. At an encoder, the FEC Framework passes ADUs to the FEC scheme for FEC encoding. The FEC scheme returns repair symbols with their associated Repair FEC Payload IDs and, in some cases, Source FEC Payload IDs, depending on the FEC scheme. At a decoder, the FEC Framework passes transport packet payloads (source and repair) to the FEC scheme, and the FEC scheme returns additional recovered source packet payloads.
本文档中描述的框架和FEC方案是一种逻辑方案，仅用于规范目的。在编码器处，FEC框架将ADU传递给FEC方案以进行FEC编码。FEC方案返回修复符号及其相关联的修复FEC有效负载ID，在某些情况下，还返回源FEC有效负载ID，具体取决于FEC方案。在解码器处，FEC框架将传输分组有效载荷（源和修复）传递给FEC方案，并且FEC方案返回额外的恢复的源分组有效载荷。
This document defines certain FEC Framework Configuration Information that MUST be available to both sender and receiver(s). For example, this information includes the specification of the ADU flows that are to be FEC protected, specification of the ADU flow(s) that will carry the FEC protection (repair) data, and the relationship(s) between these source and repair flows (i.e., which source flow(s) are protected by repair flow(s)). The FEC Framework Configuration Information also includes information fields that are specific to the FEC scheme. This information is analogous to the FEC Object Transmission Information defined in [RFC5052].
本文档定义了发送方和接收方都必须可用的某些FEC框架配置信息。例如，该信息包括要受FEC保护的ADU流的规范、将携带FEC保护（修复）数据的ADU流的规范以及这些源流和修复流之间的关系（即，哪些源流受修复流保护）。FEC框架配置信息还包括特定于FEC方案的信息字段。该信息类似于[RFC5052]中定义的FEC对象传输信息。
The FEC Framework does not define how the FEC Framework Configuration Information for the stream is communicated from sender to receiver. This has to be defined by any CDP specification, as described in the following sections.
FEC框架没有定义流的FEC框架配置信息如何从发送方传递到接收方。这必须由任何CDP规范定义，如以下章节所述。
In this architecture, we assume that the interface to the transport layer supports the concepts of data units (referred to here as Application Data Units (ADUs)) to be transported and identification of ADU flows on which those data units are transported. Since this is an interface internal to the architecture, we do not specify this interface explicitly. We do require that ADU flows that are distinct from the transport layer point of view (for example, distinct UDP flows as identified by the UDP source/destination addresses/ports) are also distinct on the interface between the transport layer and the FEC Framework.
在该体系结构中，我们假设传输层的接口支持要传输的数据单元（这里称为应用程序数据单元（ADU））的概念以及传输这些数据单元的ADU流的标识。由于这是体系结构内部的接口，因此我们不明确指定此接口。我们确实要求在传输层和FEC框架之间的接口上，与传输层观点不同的ADU流（例如，由UDP源/目标地址/端口标识的不同UDP流）也是不同的。
As noted above, RTP flows are a specific example of ADU flows that might be protected by the FEC Framework. From the FEC Framework point of view, RTP source flows are ADU flows like any other, with the RTP header included within the ADU.
如上所述，RTP流是可能受FEC框架保护的ADU流的一个具体示例。从FEC框架的角度来看，RTP源流与其他任何流一样都是ADU流，RTP头包含在ADU中。
Depending on the FEC scheme, RTP can also be used as a transport for repair packet flows. In this case, a FEC scheme has to define an RTP payload format for the repair data.
根据FEC方案，RTP还可以用作修复数据包流的传输。在这种情况下，FEC方案必须为修复数据定义RTP有效负载格式。
The architecture outlined above is illustrated in Figure 1. In this architecture, two (optional) RTP instances are shown, for the source and repair data, respectively. This is because the use of RTP for the source data is separate from, and independent of, the use of RTP for the repair data. The appearance of two RTP instances is more natural when one considers that in many FEC codes, the repair payload contains repair data calculated across the RTP headers of the source packets. Thus, a repair packet carried over RTP starts with an RTP header of its own, which is followed (after the Repair Payload ID) by repair data containing bytes that protect the source RTP headers (as well as repair data for the source RTP payloads).
上面概述的体系结构如图1所示。在此体系结构中，分别显示了源数据和修复数据的两个（可选）RTP实例。这是因为对源数据使用RTP独立于对修复数据使用RTP。当考虑到在许多FEC代码中，修复有效负载包含跨源分组的RTP报头计算的修复数据时，两个RTP实例的出现更为自然。因此，通过RTP携带的修复分组以其自身的RTP报头开始，随后（在修复有效负载ID之后）是包含保护源RTP报头的字节的修复数据（以及源RTP有效负载的修复数据）。
+--------------------------------------------+
| Application |
+--------------------------------------------+
|
|
|
+ - - - - - - - - - - - - - - - - - - - - - - - -+
| +--------------------------------------------+ |
| Application Layer |
| +--------------------------------------------+ |
| |
| + -- -- -- -- -- -- -- -- -- -- --+ | |
| RTP (Optional) | |
| | | |- Configuration/
+- -- -- -- -- -- -- -- -- -- -- -+ | Coordination
| | | |
| ADU flows |
| | v |
+--------------------------------------------+ +------------+
| | FEC Framework (This document) |<--->| FEC Scheme |
+--------------------------------------------+ +------------+
| | | |
Source | Repair |
| | | |
+-- -- -- -- --|-- --+ -- -- -- -- -- + -- --+
| | RTP Layer | | RTP Processing | | |
| (Optional) | +-- -- -- |- -- -+ |
| | +-- -- -- -- -- -- -- |--+ | |
| | RTP (De)multiplexing | |
| +-- -- -- --- -- -- -- -- -- -- -- -- -- -- -+ |
|
| +--------------------------------------------+ |
| Transport Layer (e.g., UDP) |
| +--------------------------------------------+ |
|
| +--------------------------------------------+ |
| IP |
| +--------------------------------------------+ |
+--------------------------------------------+
| Application |
+--------------------------------------------+
|
|
|
+ - - - - - - - - - - - - - - - - - - - - - - - -+
| +--------------------------------------------+ |
| Application Layer |
| +--------------------------------------------+ |
| |
| + -- -- -- -- -- -- -- -- -- -- --+ | |
| RTP (Optional) | |
| | | |- Configuration/
+- -- -- -- -- -- -- -- -- -- -- -+ | Coordination
| | | |
| ADU flows |
| | v |
+--------------------------------------------+ +------------+
| | FEC Framework (This document) |<--->| FEC Scheme |
+--------------------------------------------+ +------------+
| | | |
Source | Repair |
| | | |
+-- -- -- -- --|-- --+ -- -- -- -- -- + -- --+
| | RTP Layer | | RTP Processing | | |
| (Optional) | +-- -- -- |- -- -+ |
| | +-- -- -- -- -- -- -- |--+ | |
| | RTP (De)multiplexing | |
| +-- -- -- --- -- -- -- -- -- -- -- -- -- -- -+ |
|
| +--------------------------------------------+ |
| Transport Layer (e.g., UDP) |
| +--------------------------------------------+ |
|
| +--------------------------------------------+ |
| IP |
| +--------------------------------------------+ |
| Content Delivery Protocol |
+ - - - - - - - - - - - - - - - - - - - - - - - +
| Content Delivery Protocol |
+ - - - - - - - - - - - - - - - - - - - - - - - +
Figure 1: FEC Framework Architecture
图1:FEC框架架构
The content of the transport payload for repair packets is fully defined by the FEC scheme. For a specific FEC scheme, a means MAY be defined for repair data to be carried over RTP, in which case, the repair packet payload format starts with the RTP header. This corresponds to defining an RTP payload format for the specific FEC scheme.
修复包的传输有效载荷的内容完全由FEC方案定义。对于特定FEC方案，可以定义用于通过RTP携带的修复数据的方法，在这种情况下，修复分组有效载荷格式从RTP报头开始。这对应于为特定FEC方案定义RTP有效负载格式。
The use of RTP for repair packets is independent of the protocols used for source packets: if RTP is used for source packets, repair packets may or may not use RTP and vice versa (although it is unlikely that there are useful scenarios where non-RTP source flows are protected by RTP repair flows). FEC schemes are expected to recover entire transport payloads for recovered source packets in all cases. For example, if RTP is used for source flows, the FEC scheme is expected to recover the entire UDP payload, including the RTP header.
RTP用于修复数据包独立于用于源数据包的协议：如果RTP用于源数据包，修复数据包可能使用RTP，也可能不使用RTP，反之亦然（尽管不太可能存在非RTP源流受RTP修复流保护的有用场景）。在所有情况下，FEC方案都将恢复恢复源数据包的整个传输有效负载。例如，如果RTP用于源流，则FEC方案将恢复整个UDP有效负载，包括RTP报头。
The mechanism defined in this document does not place any restrictions on the ADUs that can be protected together, except that the ADU be carried over a supported transport protocol (see Section 7). The data can be from multiple source flows that are protected jointly. The FEC Framework handles the source flows as a sequence of source blocks each consisting of a set of ADUs, possibly from multiple source flows that are to be protected together. For example, each source block can be constructed from those ADUs related to a particular segment in time of the flow.
本文件中定义的机制对可一起保护的ADU没有任何限制，但ADU通过受支持的传输协议传输（见第7节）。数据可以来自联合保护的多个源流。FEC框架将源流处理为一系列源块，每个源块由一组ADU组成，可能来自要一起保护的多个源流。例如，每个源块都可以从流中与特定段相关的ADU构建。
At the sender, the FEC Framework passes the payloads for a given block to the FEC scheme for FEC encoding. The FEC scheme performs the FEC encoding operation and returns the following information:
在发送方，FEC框架将给定块的有效载荷传递给FEC方案进行FEC编码。FEC方案执行FEC编码操作并返回以下信息：
o Optionally, FEC Payload IDs for each of the source payloads (encoded according to a FEC-Scheme-Specific format).
o 可选地，每个源有效载荷的FEC有效载荷id（根据FEC方案特定格式编码）。
o One or more FEC repair packet payloads.
o 一个或多个FEC修复数据包有效载荷。
o FEC Payload IDs for each of the repair packet payloads (encoded according to a FEC-Scheme-Specific format).
o 每个修复分组有效载荷的FEC有效载荷id（根据FEC方案特定格式编码）。
The FEC Framework then performs two operations. First, it appends the Source FEC Payload IDs, if provided, to each of the ADUs, and sends the resulting packets, known as "FEC source packets", to the receiver. Second, it places the provided FEC repair packet payloads and corresponding Repair FEC Payload IDs appropriately to construct FEC repair packets and send them to the receiver.
然后，FEC框架执行两个操作。首先，它将源FEC有效负载id（如果提供的话）附加到每个adu，并将产生的分组（称为“FEC源分组”）发送到接收机。其次，它适当地放置所提供的FEC修复包有效载荷和相应的修复FEC有效载荷id，以构造FEC修复包并将其发送给接收机。
This document does not define how the sender determines which ADUs are included in which source blocks or the sending order and timing of FEC source and repair packets. A specific CDP MAY define this mapping, or it MAY be left as implementation dependent at the sender. However, a CDP specification MUST define how a receiver determines a minimum length of time that it needs to wait to receive FEC repair packets for any given source block. FEC schemes MAY define limitations on this mapping, such as maximum size of source blocks, but they SHOULD NOT attempt to define specific mappings. The sequence of operations at the sender is described in more detail in Section 4.2.
本文档未定义发送方如何确定哪些ADU包含在哪些源块中，或FEC源和修复数据包的发送顺序和定时。特定的CDP可以定义此映射，也可以将其保留为依赖于发送方的实现。然而，CDP规范必须定义接收器如何确定它需要等待接收任何给定源块的FEC修复数据包的最小时间长度。FEC方案可以定义此映射的限制，例如源块的最大大小，但不应尝试定义特定映射。第4.2节详细描述了发送方的操作顺序。
At the receiver, original ADUs are recovered by the FEC Framework directly from any FEC source packets received simply by removing the Source FEC Payload ID, if present. The receiver also passes the contents of the received ADUs, plus their FEC Payload IDs, to the FEC scheme for possible decoding.
在接收机处，FEC框架通过移除源FEC有效载荷ID（如果存在）直接从接收到的任何FEC源分组恢复原始adu。接收机还将接收到的adu的内容及其FEC有效负载id传递给FEC方案以进行可能的解码。
If any ADUs related to a given source block have been lost, then the FEC scheme can perform FEC decoding to recover the missing ADUs (assuming sufficient FEC source and repair packets related to that source block have been received).
如果与给定源块相关的任何adu已经丢失，则FEC方案可以执行FEC解码以恢复丢失的adu（假设已经接收到足够的FEC源和与该源块相关的修复分组）。
Note that the receiver might need to buffer received source packets to allow time for the FEC repair packets to arrive and FEC decoding to be performed before some or all of the received or recovered packets are passed to the application. If such a buffer is not provided, then the application has to be able to deal with the severe re-ordering of packets that can occur. However, such buffering is CDP- and/or implementation-specific and is not specified here. The receiver operation is described in more detail in Section 4.3.
注意，接收机可能需要缓冲接收到的源分组，以允许FEC修复分组到达并且在将部分或全部接收或恢复的分组传递给应用之前执行FEC解码的时间。如果没有提供这样的缓冲区，那么应用程序必须能够处理可能发生的严重的数据包重排序。然而，这种缓冲是特定于CDP和/或实现的，这里没有指定。接收器操作在第4.3节中有更详细的描述。
The FEC source packets MUST contain information that identifies the source block and the position within the source block (in terms specific to the FEC scheme) occupied by the ADU. This information is known as the Source FEC Payload ID. The FEC scheme is responsible for defining and interpreting this information. This information MAY be encoded into a specific field within the FEC source packet format defined in this specification, called the Explicit Source FEC Payload ID field. The exact contents and format of the Explicit Source FEC Payload ID field are defined by the FEC schemes. Alternatively, the
FEC源数据包必须包含标识源块的信息以及ADU占用的源块内的位置（就FEC方案而言）。此信息称为源FEC有效负载ID。FEC方案负责定义和解释此信息。该信息可以编码到本规范中定义的FEC源分组格式内的特定字段中，称为显式源FEC有效负载ID字段。显式源FEC有效负载ID字段的确切内容和格式由FEC方案定义。或者
FEC scheme MAY define how the Source FEC Payload ID is derived from other fields within the source packets. This document defines the way that the Explicit Source FEC Payload ID field is appended to source packets to form FEC source packets.
FEC方案可以定义如何从源分组内的其他字段导出源FEC有效负载ID。本文档定义了将显式源FEC有效负载ID字段附加到源数据包以形成FEC源数据包的方式。
The FEC repair packets MUST contain information that identifies the source block and the relationship between the contained repair payloads and the original source block. This is known as the Repair FEC Payload ID. This information MUST be encoded into a specific field, the Repair FEC Payload ID field, the contents and format of which are defined by the FEC schemes.
FEC修复数据包必须包含标识源块以及包含的修复有效载荷与原始源块之间关系的信息。这称为修复FEC有效负载ID。该信息必须编码到特定字段中，即修复FEC有效负载ID字段，其内容和格式由FEC方案定义。
The FEC scheme MAY use different FEC Payload ID field formats for source and repair packets.
FEC方案可以对源和修复分组使用不同的FEC有效载荷ID字段格式。
It is assumed that the sender has constructed or received original data packets for the session. These could be carrying any type of data. The following operations, illustrated in Figure 2 for the case of UDP repair flows and in Figure 3 for the case of RTP repair flows, describe a possible way to generate compliant source and repair flows:
假定发送方已构造或接收会话的原始数据包。它们可以携带任何类型的数据。以下操作（图2针对UDP修复流和图3针对RTP修复流）描述了生成兼容源和修复流的可能方法：
1. ADUs are provided by the application.
1. ADU由应用程序提供。
2. A source block is constructed as specified in Section 5.2.
2. 按照第5.2节的规定构造源块。
3. The source block is passed to the FEC scheme for FEC encoding. The Source FEC Payload ID information of each source packet is determined by the FEC scheme. If required by the FEC scheme, the Source FEC Payload ID is encoded into the Explicit Source FEC Payload ID field.
3. 将源块传递给FEC方案进行FEC编码。每个源分组的源FEC有效负载ID信息由FEC方案确定。如果FEC方案需要，则将源FEC有效负载ID编码到显式源FEC有效负载ID字段中。
4. The FEC scheme performs FEC encoding, generating repair packet payloads from a source block and a Repair FEC Payload ID field for each repair payload.
4. FEC方案执行FEC编码，从源块生成修复分组有效载荷，并为每个修复有效载荷生成修复FEC有效载荷ID字段。
5. The Explicit Source FEC Payload IDs (if used), Repair FEC Payload IDs, and repair packet payloads are provided back from the FEC scheme to the FEC Framework.
5. 显式源FEC有效负载id（如果使用）、修复FEC有效负载id和修复分组有效负载从FEC方案返回到FEC框架。
6. The FEC Framework constructs FEC source packets according to Section 5.3, and FEC repair packets according to Section 5.4, using the FEC Payload IDs and repair packet payloads provided by the FEC scheme.
6. FEC框架使用FEC方案提供的FEC有效载荷ID和修复数据包有效载荷，根据第5.3节构造FEC源数据包，根据第5.4节构造FEC修复数据包。
7. The FEC source and repair packets are sent using normal transport-layer procedures. The port(s) and multicast group(s) to be used for FEC repair packets are defined in the FEC Framework Configuration Information. The FEC source packets are sent using the same ADU flow identification information as would have been used for the original source packets if the FEC Framework were not present (for example, in the UDP case, the UDP source and destination addresses and ports on the IP datagram carrying the source packet will be the same whether or not the FEC Framework is applied).
7. FEC源和修复数据包使用正常的传输层过程发送。用于FEC修复分组的端口和多播组在FEC框架配置信息中定义。如果没有FEC框架，FEC源数据包使用与原始源数据包相同的ADU流标识信息发送（例如，在UDP情况下，无论是否应用FEC框架，承载源数据包的IP数据报上的UDP源地址和目标地址以及端口都将相同）。
+----------------------+
| Application |
+----------------------+
|
|(1) ADUs
|
v
+----------------------+ +----------------+
| FEC Framework | | |
| |-------------------------->| FEC Scheme |
|(2) Construct source |(3) Source Block | |
| blocks | |(4) FEC Encoding|
|(6) Construct FEC |<--------------------------| |
| source and repair | | |
| packets |(5) Explicit Source FEC | |
+----------------------+ Payload IDs +----------------+
| Repair FEC Payload IDs
| Repair symbols
|
|(7) FEC source and repair packets
v
+----------------------+
| Transport Layer |
| (e.g., UDP) |
+----------------------+
+----------------------+
| Application |
+----------------------+
|
|(1) ADUs
|
v
+----------------------+ +----------------+
| FEC Framework | | |
| |-------------------------->| FEC Scheme |
|(2) Construct source |(3) Source Block | |
| blocks | |(4) FEC Encoding|
|(6) Construct FEC |<--------------------------| |
| source and repair | | |
| packets |(5) Explicit Source FEC | |
+----------------------+ Payload IDs +----------------+
| Repair FEC Payload IDs
| Repair symbols
|
|(7) FEC source and repair packets
v
+----------------------+
| Transport Layer |
| (e.g., UDP) |
+----------------------+
Figure 2: Sender Operation
图2：发送器操作
+----------------------+
| Application |
+----------------------+
|
|(1) ADUs
|
v
+----------------------+ +----------------+
| FEC Framework | | |
| |-------------------------->| FEC Scheme |
|(2) Construct source |(3) Source Block | |
| blocks | |(4) FEC Encoding|
|(6) Construct FEC |<--------------------------| |
| source packets and| | |
| repair payloads |(5) Explicit Source FEC | |
+----------------------+ Payload IDs +----------------+
| | Repair FEC Payload IDs
| | Repair symbols
| |
|(7) Source |(7') Repair payloads
| packets |
| |
| + -- -- -- -- -+
| | RTP |
| +-- -- -- -- --+
v v
+----------------------+
| Transport Layer |
| (e.g., UDP) |
+----------------------+
+----------------------+
| Application |
+----------------------+
|
|(1) ADUs
|
v
+----------------------+ +----------------+
| FEC Framework | | |
| |-------------------------->| FEC Scheme |
|(2) Construct source |(3) Source Block | |
| blocks | |(4) FEC Encoding|
|(6) Construct FEC |<--------------------------| |
| source packets and| | |
| repair payloads |(5) Explicit Source FEC | |
+----------------------+ Payload IDs +----------------+
| | Repair FEC Payload IDs
| | Repair symbols
| |
|(7) Source |(7') Repair payloads
| packets |
| |
| + -- -- -- -- -+
| | RTP |
| +-- -- -- -- --+
v v
+----------------------+
| Transport Layer |
| (e.g., UDP) |
+----------------------+
Figure 3: Sender Operation with RTP Repair Flows
图3:RTP修复流的发送方操作
The following describes a possible receiver algorithm, illustrated in Figures 4 and 5 for the case of UDP and RTP repair flows, respectively, when receiving a FEC source or repair packet:
以下描述了在接收FEC源或修复数据包时，UDP和RTP修复流情况下可能的接收器算法，如图4和图5所示：
1. FEC source packets and FEC repair packets are received and passed to the FEC Framework. The type of packet (source or repair) and the source flow to which it belongs (in the case of source packets) are indicated by the ADU flow information, which identifies the flow at the transport layer.
1. 接收FEC源数据包和FEC修复数据包并将其传递给FEC框架。包的类型（源或修复）及其所属的源流（在源包的情况下）由ADU流信息指示，该信息标识传输层的流。
In the special case that RTP is used for repair packets, and source and repair packets are multiplexed onto the same UDP flow, then RTP demultiplexing is required to demultiplex source and
在特殊情况下，RTP用于修复数据包，并且源数据包和修复数据包被复用到同一UDP流上，则需要RTP解复用来解复用源数据包和修复数据包
repair flows. However, RTP processing is applied only to the repair packets at this stage; source packets continue to be handled as UDP payloads (i.e., including their RTP headers).
修复流程。然而，RTP处理在此阶段仅应用于修复分组；源数据包继续作为UDP有效负载处理（即，包括其RTP报头）。
2. The FEC Framework extracts the Explicit Source FEC Payload ID field (if present) from the source packets and the Repair FEC Payload ID from the repair packets.
2. FEC框架从源分组中提取显式源FEC有效负载ID字段（如果存在），并从修复分组中提取修复FEC有效负载ID。
3. The Explicit Source FEC Payload IDs (if present), Repair FEC Payload IDs, and FEC source and repair payloads are passed to the FEC scheme.
3. 显式源FEC有效负载ID（如果存在）、修复FEC有效负载ID以及FEC源和修复有效负载被传递给FEC方案。
4. The FEC scheme uses the received FEC Payload IDs (and derived FEC Source Payload IDs in the case that the Explicit Source FEC Payload ID field is not used) to group source and repair packets into source blocks. If at least one source packet is missing from a source block, and at least one repair packet has been received for the same source block, then FEC decoding can be performed in order to recover missing source payloads. The FEC scheme determines whether source packets have been lost and whether enough data for decoding of any or all of the missing source payloads in the source block has been received.
4. FEC方案使用接收到的FEC有效负载ID（以及在不使用显式源FEC有效负载ID字段的情况下导出的FEC源有效负载ID）将源分组并将分组修复到源块中。如果源块中缺少至少一个源分组，并且已经为同一源块接收到至少一个修复分组，则可以执行FEC解码以恢复缺少的源有效载荷。FEC方案确定源分组是否已经丢失，以及是否已经接收到足够的数据来解码源块中任何或所有丢失的源有效载荷。
5. The FEC scheme returns the ADUs to the FEC Framework in the form of source blocks containing received and decoded ADUs and indications of any ADUs that were missing and could not be decoded.
5. FEC方案以源块的形式将ADU返回FEC框架，源块包含接收和解码的ADU以及任何缺失且无法解码的ADU的指示。
6. The FEC Framework passes the received and recovered ADUs to the application.
6. FEC框架将接收和恢复的ADU传递给应用程序。
The description above defines functionality responsibilities but does not imply a specific set of timing relationships. Source packets that are correctly received and those that are reconstructed MAY be delivered to the application out of order and in a different order from the order of arrival at the receiver. Alternatively, buffering and packet re-ordering MAY be applied to re-order received and reconstructed source packets into the order they were placed into the source block, if that is necessary according to the application.
上面的描述定义了功能职责，但并不意味着一组特定的时序关系。正确接收的源分组和重构的源分组可以无序地并且以与到达接收器的顺序不同的顺序交付给应用程序。或者，如果根据应用需要，可以应用缓冲和分组重新排序来将接收到的和重构的源分组重新排序为它们被放入源块的顺序。
+----------------------+
| Application |
+----------------------+
^
|
|(6) ADUs
|
+----------------------+ +----------------+
| FEC Framework | | |
| |<--------------------------| FEC Scheme |
|(2)Extract FEC Payload|(5) ADUs | |
| IDs and pass IDs & | |(4) FEC Decoding|
| payloads to FEC |-------------------------->| |
| scheme |(3) Explicit Source FEC | |
+----------------------+ Payload IDs +----------------+
^ Repair FEC Payload IDs
| Source payloads
| Repair payloads
|
|(1) FEC source and repair packets
|
+----------------------+
| Transport Layer |
| (e.g., UDP) |
+----------------------+
+----------------------+
| Application |
+----------------------+
^
|
|(6) ADUs
|
+----------------------+ +----------------+
| FEC Framework | | |
| |<--------------------------| FEC Scheme |
|(2)Extract FEC Payload|(5) ADUs | |
| IDs and pass IDs & | |(4) FEC Decoding|
| payloads to FEC |-------------------------->| |
| scheme |(3) Explicit Source FEC | |
+----------------------+ Payload IDs +----------------+
^ Repair FEC Payload IDs
| Source payloads
| Repair payloads
|
|(1) FEC source and repair packets
|
+----------------------+
| Transport Layer |
| (e.g., UDP) |
+----------------------+
Figure 4: Receiver Operation
图4：接收器操作
+----------------------+
| Application |
+----------------------+
^
|
|(6) ADUs
|
+----------------------+ +----------------+
| FEC Framework | | |
| |<--------------------------| FEC Scheme |
|(2)Extract FEC Payload|(5) ADUs | |
| IDs and pass IDs & | |(4) FEC Decoding|
| payloads to FEC |-------------------------->| |
| scheme |(3) Explicit Source FEC | |
+----------------------+ Payload IDs +----------------+
^ ^ Repair FEC Payload IDs
| | Source payloads
| | Repair payloads
| |
|Source |Repair payloads
|packets |
| |
+-- |- -- -- -- -- -- -+
|RTP| | RTP Processing |
| | +-- -- -- --|-- -+
| +-- -- -- -- -- |--+ |
| | RTP Demux | |
+-- -- -- -- -- -- -- -+
^
|(1) FEC source and repair packets
|
+----------------------+
| Transport Layer |
| (e.g., UDP) |
+----------------------+
+----------------------+
| Application |
+----------------------+
^
|
|(6) ADUs
|
+----------------------+ +----------------+
| FEC Framework | | |
| |<--------------------------| FEC Scheme |
|(2)Extract FEC Payload|(5) ADUs | |
| IDs and pass IDs & | |(4) FEC Decoding|
| payloads to FEC |-------------------------->| |
| scheme |(3) Explicit Source FEC | |
+----------------------+ Payload IDs +----------------+
^ ^ Repair FEC Payload IDs
| | Source payloads
| | Repair payloads
| |
|Source |Repair payloads
|packets |
| |
+-- |- -- -- -- -- -- -+
|RTP| | RTP Processing |
| | +-- -- -- --|-- -+
| +-- -- -- -- -- |--+ |
| | RTP Demux | |
+-- -- -- -- -- -- -- -+
^
|(1) FEC source and repair packets
|
+----------------------+
| Transport Layer |
| (e.g., UDP) |
+----------------------+
Figure 5: Receiver Operation with RTP Repair Flows
图5：具有RTP修复流程的接收器操作
Note that the above procedure might result in a situation in which not all ADUs are recovered.
请注意，上述程序可能导致并非所有ADU都能恢复的情况。
This section specifies the protocol elements for the FEC Framework. Three components of the protocol are defined in this document and are described in the following sections:
本节指定FEC框架的协议元素。本文件定义了协议的三个组成部分，并在以下章节中进行了描述：
1. Construction of a source block from ADUs. The FEC code will be applied to this source block to produce the repair payloads.
1. 从ADUs建造一个源区。FEC代码将应用于该源块，以产生修复有效载荷。
2. A format for packets containing source data.
2. 包含源数据的数据包的格式。
3. A format for packets containing repair data.
3. 包含修复数据的数据包的格式。
The operation of the FEC Framework is governed by certain FEC Framework Configuration Information, which is defined in this section. A complete protocol specification that uses this framework MUST specify the means to determine and communicate this information between sender and receiver.
FEC框架的操作由本节中定义的某些FEC框架配置信息控制。使用此框架的完整协议规范必须指定在发送方和接收方之间确定和传递此信息的方法。
The FEC Framework and FEC scheme exchange ADUs in the form of source blocks. A source block is generated by the FEC Framework from an ordered sequence of ADUs. The allocation of ADUs to blocks is dependent on the application. Note that some ADUs may not be included in any block. Each source block provided to the FEC scheme consists of an ordered sequence of ADUs where the following information is provided for each ADU:
FEC框架和FEC方案以源块的形式交换ADU。FEC框架根据ADU的有序序列生成源块。ADU到块的分配取决于应用程序。请注意，某些ADU可能不包括在任何块中。提供给FEC方案的每个源块由ADU的有序序列组成，其中为每个ADU提供以下信息：
o A description of the source flow with which the ADU is associated.
o 与ADU关联的源流的描述。
o The ADU itself.
o ADU本身。
o The length of the ADU.
o ADU的长度。
The packet format for FEC source packets MUST be used to transport the payload of an original source packet. As depicted in Figure 6, it consists of the original packet, optionally followed by the Explicit Source FEC Payload ID field. The FEC scheme determines whether the Explicit Source FEC Payload ID field is required. This determination is specific to each ADU flow.
FEC源数据包的数据包格式必须用于传输原始源数据包的有效负载。如图6所示，它由原始数据包组成，可选地后跟显式源FEC有效负载ID字段。FEC方案确定是否需要显式源FEC有效负载ID字段。该测定针对每个ADU流量。
+------------------------------------+
| IP Header |
+------------------------------------+
| Transport Header |
+------------------------------------+
| Application Data Unit |
+------------------------------------+
| Explicit Source FEC Payload ID |
+------------------------------------+
+------------------------------------+
| IP Header |
+------------------------------------+
| Transport Header |
+------------------------------------+
| Application Data Unit |
+------------------------------------+
| Explicit Source FEC Payload ID |
+------------------------------------+
Figure 6: Structure of the FEC Packet Format for FEC Source Packets
图6:FEC源数据包的FEC数据包格式结构
The FEC source packets MUST be sent using the same ADU flow as would have been used for the original source packets if the FEC Framework were not present. The transport payload of the FEC source packet MUST consist of the ADU followed by the Explicit Source FEC Payload ID field, if required.
如果FEC框架不存在，则FEC源数据包必须使用与原始源数据包相同的ADU流发送。如果需要，FEC源数据包的传输有效负载必须由ADU和显式源FEC有效负载ID字段组成。
The Explicit Source FEC Payload ID field contains information required to associate the source packet with a source block and for the operation of the FEC algorithm, and is defined by the FEC scheme. The format of the Source FEC Payload ID field is defined by the FEC scheme. In the case that the FEC scheme or CDP defines a means to derive the Source FEC Payload ID from other information in the packet (for example, a sequence number used by the application protocol), then the Source FEC Payload ID field is not included in the packet. In this case, the original source packet and FEC source packet are identical.
显式源FEC有效载荷ID字段包含将源分组与源块关联以及FEC算法操作所需的信息，并且由FEC方案定义。源FEC有效负载ID字段的格式由FEC方案定义。在FEC方案或CDP定义了从分组中的其他信息（例如，由应用协议使用的序列号）导出源FEC有效载荷ID的方法的情况下，源FEC有效载荷ID字段不包括在分组中。在这种情况下，原始源分组和FEC源分组是相同的。
In applications where avoidance of IP packet fragmentation is a goal, CDPs SHOULD consider the Explicit Source FEC Payload ID size when determining the size of ADUs that will be delivered using the FEC Framework. This is because the addition of the Explicit Source FEC Payload ID increases the packet length.
在避免IP分组碎片化的应用中，CDP在确定将使用FEC框架交付的ADU的大小时应考虑显式源FEC有效载荷ID大小。这是因为添加显式源FEC有效负载ID增加了分组长度。
The Explicit Source FEC Payload ID is placed at the end of the packet, so that in the case that Robust Header Compression (ROHC) [RFC3095] or other header compression mechanisms are used, and in the case that a ROHC profile is defined for the protocol carried within the transport payload (for example, RTP), then ROHC will still be applied for the FEC source packets. Applications that are used with this framework need to consider that FEC schemes can add this Explicit Source FEC Payload ID and thereby increase the packet size.
显式源FEC有效载荷ID被放置在分组的末尾，以便在使用鲁棒报头压缩（ROHC）[RFC3095]或其他报头压缩机制的情况下，以及在为传输有效载荷（例如，RTP）内携带的协议定义ROHC简档的情况下，然后，ROHC仍将应用于FEC源数据包。与此框架一起使用的应用程序需要考虑FEC方案可以添加这个显式源FEC有效载荷ID，从而增加分组大小。
In many applications, support for FEC is added to a pre-existing protocol, and in this case, use of the Explicit Source FEC Payload ID can break backward compatibility, since source packets are modified.
在许多应用程序中，对FEC的支持被添加到预先存在的协议中，在这种情况下，使用显式源FEC有效负载ID可能会破坏向后兼容性，因为源数据包会被修改。
In order to apply FEC protection using multiple FEC schemes to a single source flow, all schemes have to use the same Explicit Source FEC Payload ID format. In order to enable this, it is RECOMMENDED that FEC schemes support the Generic Explicit Source FEC Payload ID format described below.
为了将使用多个FEC方案的FEC保护应用于单个源流，所有方案必须使用相同的显式源FEC有效负载ID格式。为了实现这一点，建议FEC方案支持下面描述的通用显式源FEC有效负载ID格式。
The Generic Explicit Source FEC Payload ID has a length of two octets and consists of an unsigned packet sequence number in network-byte order. The allocation of sequence numbers to packets is independent of any FEC scheme and of the source block construction, except that the use of this sequence number places a constraint on source block construction. Source packets within a given source block MUST have consecutive sequence numbers (where consecutive includes wrap-around from the maximum value that can be represented in two octets (65535) to 0). Sequence numbers SHOULD NOT be reused until all values in the sequence number space have been used.
通用显式源FEC有效负载ID的长度为两个八位字节，由网络字节顺序的无符号数据包序列号组成。向分组分配序列号独立于任何FEC方案和源块构造，除非使用该序列号对源块构造施加约束。给定源块内的源数据包必须具有连续的序列号（其中连续包含从两个八位字节（65535）中可以表示的最大值到0的环绕）。在使用序列号空间中的所有值之前，不应重复使用序列号。
Note that if the original packets of the source flow are already carrying a packet sequence number that is at least two bytes long, there is no need to add the generic Explicit Source FEC Payload ID and modify the packets.
注意，如果源流的原始分组已经携带至少两个字节长的分组序列号，则无需添加通用显式源FEC有效负载ID并修改分组。
The packet format for FEC repair packets is shown in Figure 7. The transport payload consists of a Repair FEC Payload ID field followed by repair data generated in the FEC encoding process.
FEC修复数据包的数据包格式如图7所示。传输有效载荷由修复FEC有效载荷ID字段组成，后跟在FEC编码过程中生成的修复数据。
+------------------------------------+
| IP Header |
+------------------------------------+
| Transport Header |
+------------------------------------+
| Repair FEC Payload ID |
+------------------------------------+
| Repair Symbols |
+------------------------------------+
+------------------------------------+
| IP Header |
+------------------------------------+
| Transport Header |
+------------------------------------+
| Repair FEC Payload ID |
+------------------------------------+
| Repair Symbols |
+------------------------------------+
Figure 7: Packet Format for FEC Repair Packets
图7:FEC修复数据包的数据包格式
The Repair FEC Payload ID field contains information required for the operation of the FEC algorithm at the receiver. This information is defined by the FEC scheme. The format of the Repair FEC Payload ID field is defined by the FEC scheme.
修复FEC有效负载ID字段包含在接收器处操作FEC算法所需的信息。该信息由FEC方案定义。修复FEC有效负载ID字段的格式由FEC方案定义。
For FEC schemes that specify the use of RTP for repair packets, the packet format for repair packets includes an RTP header as shown in Figure 8.
对于指定RTP用于修复数据包的FEC方案，修复数据包的数据包格式包括一个RTP报头，如图8所示。
+------------------------------------+
| IP Header |
+------------------------------------+
| Transport Header (UDP) |
+------------------------------------+
| RTP Header |
+------------------------------------+
| Repair FEC Payload ID |
+------------------------------------+
| Repair Symbols |
+------------------------------------+
+------------------------------------+
| IP Header |
+------------------------------------+
| Transport Header (UDP) |
+------------------------------------+
| RTP Header |
+------------------------------------+
| Repair FEC Payload ID |
+------------------------------------+
| Repair Symbols |
+------------------------------------+
Figure 8: Packet Format for FEC Repair Packets over RTP
图8:RTP上FEC修复数据包的数据包格式
The FEC Framework Configuration Information is information that the FEC Framework needs in order to apply FEC protection to the ADU flows. A complete CDP specification that uses the framework specified here MUST include details of how this information is derived and communicated between sender and receiver.
FEC框架配置信息是FEC框架为将FEC保护应用于ADU流而需要的信息。使用此处指定的框架的完整CDP规范必须包括如何派生此信息以及发送方和接收方之间如何进行通信的详细信息。
The FEC Framework Configuration Information includes identification of the set of source flows. For example, in the case of UDP, each source flow is uniquely identified by a tuple {source IP address, source UDP port, destination IP address, destination UDP port}. In some applications, some of these fields can contain wildcards, so that the flow is identified by a subset of the fields. In particular, in many applications the limited tuple {destination IP address, destination UDP port} is sufficient.
FEC框架配置信息包括源流集合的标识。例如，在UDP的情况下，每个源流由元组{源IP地址、源UDP端口、目标IP地址、目标UDP端口}唯一标识。在某些应用程序中，其中一些字段可以包含通配符，因此流由字段的子集标识。特别是，在许多应用程序中，有限元组{目标IP地址，目标UDP端口}就足够了。
A single instance of the FEC Framework provides FEC protection for packets of the specified set of source flows, by means of one or more packet flows consisting of repair packets. The FEC Framework Configuration Information includes, for each instance of the FEC Framework:
FEC框架的单个实例通过由修复分组组成的一个或多个分组流，为指定源流集合的分组提供FEC保护。对于FEC框架的每个实例，FEC框架配置信息包括：
1. Identification of the repair flows.
1. 识别维修流程。
2. For each source flow protected by the repair flow(s):
2. 对于受修复流保护的每个源流：
A. Definition of the source flow.
A.源流的定义。
B. An integer identifier for this flow definition (i.e., tuple). This identifier MUST be unique among all source flows that are protected by the same FEC repair flow. Integer identifiers can be allocated starting from zero and increasing by one for each flow. However, any random (but still unique) allocation is also possible. A source flow identifier need not be carried in source packets, since source packets are directly associated with a flow by virtue of their packet headers.
B.此流定义的整数标识符（即元组）。该标识符在受同一FEC修复流保护的所有源流中必须是唯一的。整数标识符可以从零开始分配，并为每个流增加一个。然而，任何随机（但仍然是唯一的）分配也是可能的。源流标识符不需要在源分组中携带，因为源分组凭借其分组报头直接与流相关联。
3. The FEC Encoding ID, identifying the FEC scheme.
3. FEC编码ID，标识FEC方案。
4. The length of the Explicit Source FEC Payload ID (in octets).
4. 显式源FEC有效负载ID的长度（以八位字节为单位）。
5. Zero or more FEC-Scheme-Specific Information (FSSI) elements, each consisting of a name and a value where the valid element names and value ranges are defined by the FEC scheme.
5. 零个或多个FEC方案特定信息（FSSI）元素，每个元素由名称和值组成，其中有效元素名称和值范围由FEC方案定义。
Multiple instances of the FEC Framework, with separate and independent FEC Framework Configuration Information, can be present at a sender or receiver. A single instance of the FEC Framework protects packets of the source flows identified in (2) above; i.e., all packets sent on those flows MUST be FEC source packets as defined in Section 5.3. A single source flow can be protected by multiple instances of the FEC Framework.
具有独立FEC框架配置信息的FEC框架的多个实例可以存在于发送方或接收方。FEC框架的单个实例保护上文（2）中标识的源流的分组；i、 例如，在这些流上发送的所有数据包必须是第5.3节中定义的FEC源数据包。单个源流可以由FEC框架的多个实例保护。
The integer flow identifier identified in (2B) above is a shorthand to identify source flows between the FEC Framework and the FEC scheme. The reason for defining this as an integer, and including it in the FEC Framework Configuration Information, is so that the FEC scheme at the sender and receiver can use it to identify the source flow with which a recovered packet is associated. The integer flow identifier can therefore take the place of the complete flow description (e.g., UDP 4-tuple).
上面（2B）中标识的整数流标识符是用于标识FEC框架和FEC方案之间的源流的缩写。将其定义为整数并将其包括在FEC框架配置信息中的原因是，发送方和接收方的FEC方案可以使用它来识别与恢复的分组相关联的源流。因此，整数流标识符可以代替完整的流描述（例如，UDP 4元组）。
Whether and how this flow identifier is used is defined by the FEC scheme. Since repair packets can provide protection for multiple source flows, repair packets either would not carry the identifier at all or can carry multiple identifiers. However, in any case, the flow identifier associated with a particular source packet can be recovered from the repair packets as part of a FEC decoding operation.
是否以及如何使用该流标识符由FEC方案定义。由于修复包可以为多个源流提供保护，修复包要么根本不携带标识符，要么可以携带多个标识符。然而，在任何情况下，作为FEC解码操作的一部分，可以从修复分组恢复与特定源分组相关联的流标识符。
A single FEC repair flow provides repair packets for a single instance of the FEC Framework. Other packets MUST NOT be sent within this flow; i.e., all packets in the FEC repair flow MUST be FEC repair packets as defined in Section 5.4 and MUST relate to the same FEC Framework instance.
单个FEC修复流为FEC框架的单个实例提供修复包。其他数据包不得在此流中发送；i、 例如，FEC修复流中的所有数据包必须是第5.4节中定义的FEC修复数据包，并且必须与同一FEC框架实例相关。
In the case that RTP is used for repair packets, the identification of the repair packet flow can also include the RTP payload type to be used for repair packets.
在RTP用于修复分组的情况下，修复分组流的标识还可以包括用于修复分组的RTP有效载荷类型。
FSSI includes the information that is specific to the FEC scheme used by the CDP. FSSI is used to communicate the information that cannot be adequately represented otherwise and is essential for proper FEC encoding and decoding operations. The motivation behind separating the FSSI required only by the sender (which is carried in a Sender-Side FEC-Scheme-Specific Information (SS-FSSI) container) from the rest of the FSSI is to provide the receiver or the third-party entities a means of controlling the FEC operations at the sender. Any FSSI other than the one solely required by the sender MUST be communicated via the FSSI container.
FSSI包括特定于CDP使用的FEC方案的信息。FSSI用于传递无法以其他方式充分表示的信息，对于正确的FEC编码和解码操作至关重要。将仅由发送方（在发送方FEC方案特定信息（SS-FSSI）容器中携带）所需的FSSI与FSSI的其余部分分离的动机是为接收方或第三方实体提供控制发送方FEC操作的手段。除发送方单独要求的FSSI以外的任何FSSI必须通过FSSI容器进行通信。
The variable-length SS-FSSI and FSSI containers transmit the information in textual representation and contain zero or more distinct elements, whose descriptions are provided by the fully specified FEC schemes.
可变长度SS-FSSI和FSSI容器以文本表示形式传输信息，并包含零个或多个不同元素，其描述由完全指定的FEC方案提供。
For the CDPs that choose the Session Description Protocol (SDP) [RFC4566] for their multimedia sessions, the ABNF [RFC5234] syntax for the SS-FSSI and FSSI containers is provided in Section 4.5 of [RFC6364].
对于为多媒体会话选择会话描述协议（SDP）[RFC4566]的CDP，SS-FSSI和FSSI容器的ABNF[RFC5234]语法见[RFC6364]的第4.5节。
In order to be used with this framework, a FEC scheme MUST be capable of processing data arranged into blocks of ADUs (source blocks).
为了与该框架一起使用，FEC方案必须能够处理排列成ADU块（源块）的数据。
A specification for a new FEC scheme MUST include the following:
新FEC方案的规范必须包括以下内容：
1. The FEC Encoding ID value that uniquely identifies the FEC scheme. This value MUST be registered with IANA, as described in Section 11.
1. 唯一标识FEC方案的FEC编码ID值。如第11节所述，该值必须向IANA注册。
2. The type, semantics, and encoding format of the Repair FEC Payload ID.
2. 修复FEC有效负载ID的类型、语义和编码格式。
3. The name, type, semantics, and text value encoding rules for zero or more FEC-Scheme-Specific Information elements.
3. 零个或多个FEC方案特定信息元素的名称、类型、语义和文本值编码规则。
4. A full specification of the FEC code.
4. FEC代码的完整规范。
This specification MUST precisely define the valid FEC-Scheme-Specific Information values, the valid FEC Payload ID values, and the valid packet payload sizes (where packet payload refers to the space within a packet dedicated to carrying encoding symbols).
本规范必须精确定义有效的FEC方案特定信息值、有效的FEC有效负载ID值和有效的分组有效负载大小（其中分组有效负载指分组内专用于承载编码符号的空间）。
Furthermore, given a source block as defined in Section 5.2, valid values of the FEC-Scheme-Specific Information, a valid Repair FEC Payload ID value, and a valid packet payload size, the specification MUST uniquely define the values of the encoding symbols to be included in the repair packet payload of a packet with the given Repair FEC Payload ID value.
此外，给定第5.2节中定义的源块、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 that -- given a source block, valid values of the FEC-Scheme-Specific Information, a valid Repair FEC Payload ID value, and a valid packet payload size as input -- produces the exact value of the encoding symbols as output.
将FEC代码指定到所需详细程度的一种常见且简单的方法是提供编码算法的精确说明，该编码算法——给定源块、FEC方案特定信息的有效值、有效修复FEC有效负载ID值，一个有效的数据包有效负载大小作为输入——产生编码符号的精确值作为输出。
5. A description of practical encoding and decoding algorithms.
5. 实用编码和解码算法的描述。
This description need not be to the same level of detail as for the encoding above; however, it has to be sufficient to demonstrate that encoding and decoding of the code are both possible and practical.
该描述不必与上述编码的详细程度相同；然而，它必须足以证明编码和解码的代码是可能的和实用的。
FEC scheme specifications MAY additionally define the following:
FEC方案规范可另外定义以下内容：
Type, semantics, and encoding format of an Explicit Source FEC Payload ID.
显式源FEC有效负载ID的类型、语义和编码格式。
Whenever a FEC scheme specification defines an 'encoding format' for an element, this has to be defined in terms of a sequence of bytes that can be embedded within a protocol. The length of the encoding format either MUST be fixed or it MUST be possible to derive the length from examining the encoded bytes themselves. For example, the initial bytes can include some kind of length indication.
每当FEC方案规范定义元素的“编码格式”时，必须根据可嵌入到协议中的字节序列来定义。编码格式的长度必须是固定的，或者可以通过检查编码字节本身来推导长度。例如，初始字节可以包括某种长度指示。
FEC scheme specifications SHOULD use the terminology defined in this document and SHOULD follow the following format:
FEC方案规范应使用本文件中定义的术语，并应遵循以下格式：
1. Introduction <Describe the use cases addressed by this FEC scheme>
1. 简介<描述此FEC方案解决的用例>
2. Formats and Codes
2. 格式和代码
2.1. Source FEC Payload ID(s) <Either define the type and format of the Explicit Source FEC Payload ID or define how Source FEC Payload ID information is derived from source packets>
2.1. 源FEC有效负载ID<定义显式源FEC有效负载ID的类型和格式，或定义源FEC有效负载ID信息如何从源数据包派生>
2.2. Repair FEC Payload ID <Define the type and format of the Repair FEC Payload ID>
2.2. 修复FEC有效负载ID<定义修复FEC有效负载ID的类型和格式>
2.3. FEC Framework Configuration Information <Define the names, types, and text value encoding formats of the FEC-Scheme-Specific Information elements>
2.3. FEC框架配置信息<定义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 IDs and FEC-Scheme-Specific Information>
3. 过程<描述特定于此FEC方案的任何过程，特别是FEC有效载荷ID和FEC方案特定信息中字段的推导和解释>
4. FEC Code Specification <Provide a complete specification of the FEC Code>
4. FEC代码规范<提供FEC代码的完整规范>
Specifications can include additional sections including 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 (except, of course, a specification of one FEC scheme can include portions of another by reference). Where an RTP payload format is defined for repair data for a specific FEC scheme, the RTP payload format and the FEC scheme can be specified within the same document.
每个FEC方案必须独立于所有其他FEC方案来指定，例如，在单独的规范或更大规范的完全独立部分中（当然，一个FEC方案的规范可以通过引用包括另一个FEC方案的部分除外）。如果为特定FEC方案的维修数据定义了RTP有效载荷格式，则RTP有效载荷格式和FEC方案可以在同一文档中指定。
Many applications require some kind of feedback on transport performance, e.g., how much data arrived at the receiver, at what rate, and when? When FEC is added to such applications, feedback mechanisms may also need to be enhanced to report on the performance of the FEC, e.g., how much lost data was recovered by the FEC?
许多应用程序需要对传输性能进行某种反馈，例如，有多少数据到达接收器，以何种速率，以及何时到达？当FEC被添加到此类应用中时，可能还需要增强反馈机制以报告FEC的性能，例如，FEC恢复了多少丢失的数据？
When used to provide instrumentation for engineering purposes, it is important to remember that FEC is generally applied to relatively small blocks of data (in the sense that each block is transmitted over a relatively small period of time). Thus, feedback information that is averaged over longer periods of time will likely not provide sufficient information for engineering purposes. More detailed feedback over shorter time scales might be preferred. For example, for applications using RTP transport, see [RFC5725].
当用于为工程目的提供仪器时，必须记住，FEC通常应用于相对较小的数据块（即每个数据块在相对较短的时间段内传输）。因此，较长时间内平均的反馈信息可能无法为工程目的提供足够的信息。在较短的时间范围内提供更详细的反馈可能是首选。例如，有关使用RTP传输的应用程序，请参阅[RFC5725]。
Applications that use feedback for congestion control purposes MUST calculate such feedback on the basis of packets received before FEC recovery is applied. If this requirement conflicts with other uses of the feedback information, then the application MUST be enhanced to support information calculated both pre- and post-FEC recovery. This is to ensure that congestion control mechanisms operate correctly based on congestion indications received from the network, rather than on post-FEC recovery information that would give an inaccurate picture of congestion conditions.
出于拥塞控制目的而使用反馈的应用程序必须在应用FEC恢复之前根据接收到的数据包计算此类反馈。如果此要求与反馈信息的其他用途相冲突，则必须对应用程序进行增强，以支持在FEC恢复之前和之后计算的信息。这是为了确保拥塞控制机制基于从网络接收到的拥塞指示而正确运行，而不是基于FEC恢复后的信息，该信息将给出不准确的拥塞状况图片。
New applications that require such feedback SHOULD use RTP/RTCP [RFC3550].
需要此类反馈的新应用程序应使用RTP/RTCP[RFC3550]。
This framework is intended to be used to define CDPs that operate over transport protocols providing an unreliable datagram service, including in particular the User Datagram Protocol (UDP) and the Datagram Congestion Control Protocol (DCCP).
该框架旨在定义在提供不可靠数据报服务的传输协议上运行的CDP，尤其包括用户数据报协议（UDP）和数据报拥塞控制协议（DCCP）。
This section starts with some informative background on the motivation of the normative requirements for congestion control, which are spelled out in Section 8.2.
本节首先介绍了第8.2节中阐述的拥塞控制规范性要求动机的一些信息背景。
o The enforcement of congestion control principles has gained a lot of momentum in the IETF over recent years. While the need for congestion control over the open Internet is unquestioned, and the goal of TCP friendliness is generally agreed upon for most (but not all) applications, the problem of congestion detection and measurement in heterogeneous networks can hardly be considered solved. Most congestion control algorithms detect and measure congestion by taking (primarily or exclusively) the packet loss rate into account. This appears to be inappropriate in environments where a large percentage of the packet losses are the result of link-layer errors and independent of the network load.
o 近年来，在IETF中，拥塞控制原则的实施取得了很大的进展。尽管开放互联网上拥塞控制的必要性是毋庸置疑的，并且大多数（但不是所有）应用程序普遍认同TCP友好的目标，但异构网络中的拥塞检测和测量问题很难被认为是解决的。大多数拥塞控制算法通过（主要或专门）考虑数据包丢失率来检测和测量拥塞。在很大一部分数据包丢失是由于链路层错误造成的，并且与网络负载无关的环境中，这似乎是不合适的。
o The authors of this document are primarily interested in applications where the application reliability requirements and end-to-end reliability of the network differ, such that it warrants higher-layer protection of the packet stream, e.g., due to the presence of unreliable links in the end-to-end path and where real-time, scalability, or other constraints prohibit the use of higher-layer (transport or application) feedback. A typical example for such applications is multicast and broadcast streaming or multimedia transmission over heterogeneous networks. In other cases, application reliability requirements can be so high that the required end-to-end reliability will be difficult to achieve. Furthermore, the end-to-end network reliability is not necessarily known in advance.
o 本文件的作者主要对应用程序可靠性要求和网络端到端可靠性不同的应用程序感兴趣，例如，由于端到端路径中存在不可靠链路以及实时性、可扩展性、，或其他限制禁止使用更高层（传输或应用）反馈。此类应用的一个典型示例是异构网络上的多播和广播流或多媒体传输。在其他情况下，应用程序可靠性要求可能非常高，以至于难以实现所需的端到端可靠性。此外，端到端网络可靠性不一定事先已知。
o This FEC Framework is not defined as, nor is it intended to be, a quality-of-service (QoS) enhancement tool to combat losses resulting from highly congested networks. It should not be used for such purposes.
o 该FEC框架未被定义为，也不打算成为一种服务质量（QoS）增强工具，用于对抗因高度拥挤的网络而造成的损失。不应将其用于此类目的。
o In order to prevent such misuse, one approach is to leave standardization to bodies most concerned with the problem described above. However, the IETF defines base standards used by several bodies, including the Digital Video Broadcasting (DVB) Project, the Third Generation Partnership Project (3GPP), and 3GPP2, all of which appear to share the environment and the problem described.
o 为了防止此类误用，一种方法是将标准化留给最关心上述问题的机构。然而，IETF定义了几个机构使用的基本标准，包括数字视频广播（DVB）项目、第三代合作伙伴关系项目（3GPP）和3GPP2，所有这些项目似乎都共享所描述的环境和问题。
o Another approach is to write a clear applicability statement. For example, one could restrict the use of this framework to networks with certain loss characteristics (e.g., wireless links). However, there can be applications where the use of FEC is justified to combat congestion-induced packet losses -- particularly in lightly loaded networks, where congestion is the result of relatively rare random peaks in instantaneous traffic load -- thereby intentionally violating congestion control principles. One possible example for such an application could be a no-matter-what, brute-force FEC protection of traffic generated as an emergency signal.
o 另一种方法是编写清晰的适用性声明。例如，可以将此框架的使用限制为具有某些损耗特性的网络（例如，无线链路）。然而，在某些应用中，FEC的使用有理由对抗由拥塞引起的数据包丢失——特别是在轻负载网络中，其中拥塞是瞬时流量负载中相对罕见的随机峰值造成的——从而故意违反拥塞控制原则。这种应用程序的一个可能的例子是，对作为紧急信号生成的通信量进行强制FEC保护。
o A third approach is to require, at a minimum, that the use of this framework with any given application, in any given environment, does not cause congestion issues that the application alone would not itself cause; i.e., the use of this framework must not make things worse.
o 第三种方法是，至少要求在任何给定的环境中，对任何给定的应用程序使用此框架不会导致应用程序本身不会导致的拥塞问题；i、 例如，使用这个框架不能让事情变得更糟。
o Taking the above considerations into account, Section 8.2 specifies a small set of constraints for FEC; these constraints are mandatory for all senders compliant with this FEC Framework. Further restrictions can be imposed by certain CDPs.
o 考虑到上述因素，第8.2节规定了FEC的一小部分约束条件；这些约束对于符合此FEC框架的所有发件人都是强制性的。某些CDP可以施加进一步的限制。
o The bandwidth of FEC repair data MUST NOT exceed the bandwidth of the original source data being protected (without the possible addition of an Explicit Source FEC Payload ID). This disallows the (static or dynamic) use of excessively strong FEC to combat high packet loss rates, which can otherwise be chosen by naively implemented dynamic FEC-strength selection mechanisms. We acknowledge that there are a few exotic applications, e.g., IP traffic from space-based senders, or senders in certain hardened military devices, that could warrant a higher FEC strength. However, in this specification, we give preference to the overall stability and network friendliness of average applications.
o FEC修复数据的带宽不得超过受保护的原始源数据的带宽（无需添加明确的源FEC有效负载ID）。这不允许（静态或动态）使用过强的FEC来对抗高丢包率，否则可以通过简单实现的动态FEC强度选择机制来选择高丢包率。我们承认，有一些特殊的应用，例如，来自天基发送器的IP通信，或某些加固军事设备中的发送器，可以保证更高的FEC强度。然而，在本规范中，我们优先考虑一般应用程序的总体稳定性和网络友好性。
o Whenever the source data rate is adapted due to the operation of congestion control mechanisms, the FEC repair data rate MUST be similarly adapted.
o 无论何时由于拥塞控制机制的操作而调整源数据速率，都必须类似地调整FEC修复数据速率。
First of all, it must be clear that the application of FEC protection to a stream does not provide any kind of security. On the contrary, the FEC Framework itself could be subject to attacks or could pose new security risks. The goals of this section are to state the problem, discuss the risks, and identify solutions when feasible. It also defines a mandatory-to-implement (but not mandatory-to-use) security scheme.
首先，必须明确的是，对流应用FEC保护不会提供任何类型的安全性。相反，FEC框架本身可能受到攻击，或者可能带来新的安全风险。本节的目标是陈述问题，讨论风险，并在可行时确定解决方案。它还定义了强制实施（但不强制使用）安全方案。
A content delivery system is potentially subject to many attacks. Attacks can target the content, the CDP, or the network itself, with completely different consequences, particularly in terms of the number of impacted nodes.
内容交付系统可能会受到多种攻击。攻击可以针对内容、CDP或网络本身，后果完全不同，特别是受影响节点的数量。
Attacks can have several goals:
攻击可以有几个目标：
o They can try to give access to confidential content (e.g., in the case of non-free content).
o 他们可以尝试访问机密内容（例如，在非免费内容的情况下）。
o They can try to corrupt the source flows (e.g., to prevent a receiver from using them), which is a form of denial-of-service (DoS) attack.
o 他们可以尝试破坏源流（例如，阻止接收方使用源流），这是拒绝服务（DoS）攻击的一种形式。
o They can try to compromise the receiver's behavior (e.g., by making the decoding of an object computationally expensive), which is another form of DoS attack.
o 他们可以尝试妥协接收者的行为（例如，通过使对象的解码在计算上昂贵），这是另一种形式的拒绝服务攻击。
o They can try to compromise the network's behavior (e.g., by causing congestion within the network), which potentially impacts a large number of nodes.
o 他们可能试图破坏网络的行为（例如，通过在网络内造成拥塞），这可能会影响大量节点。
These attacks can be launched either against the source and/or repair flows (e.g., by sending fake FEC source and/or repair packets) or against the FEC parameters that are sent either in-band (e.g., in the Repair FEC Payload ID or in the Explicit Source FEC Payload ID) or out-of-band (e.g., in the FEC Framework Configuration Information).
这些攻击可以针对源和/或修复流（例如，通过发送假FEC源和/或修复包）或针对带内（例如，在修复FEC有效负载ID或显式源FEC有效负载ID中）或带外（例如，在FEC框架配置信息中）发送的FEC参数发起。
Several dimensions to the problem need to be considered. The first one is the way the FEC Framework is used. The FEC Framework can be used end-to-end, i.e., it can be included in the final end-device where the upper application runs, or the FEC Framework can be used in middleboxes, for instance, to globally protect several source flows exchanged between two or more distant sites.
需要考虑问题的几个方面。第一个是FEC框架的使用方式。FEC框架可以端到端地使用，即，它可以包括在上层应用程序运行的最终终端设备中，或者FEC框架可以在中间盒中使用，例如，用于全局保护两个或更多远程站点之间交换的多个源流。
A second dimension is the threat model. When the FEC Framework operates in the end-device, this device (e.g., a personal computer) might be subject to attacks. Here, the attacker is either the end-user (who might want to access confidential content) or somebody else. In all cases, the attacker has access to the end-device but does not necessarily fully control this end-device (a secure domain can exist). Similarly, when the FEC Framework operates in a middlebox, this middlebox can be subject to attacks or the attacker can gain access to it. The threats can also concern the end-to-end transport (e.g., through the Internet). Here, examples of threats include the transmission of fake FEC source or repair packets; the replay of valid packets; the drop, delay, or misordering of packets; and, of course, traffic eavesdropping.
第二个维度是威胁模型。当FEC框架在终端设备中运行时，该设备（例如，个人计算机）可能会受到攻击。在这里，攻击者可能是最终用户（可能希望访问机密内容）或其他人。在所有情况下，攻击者都可以访问终端设备，但不一定完全控制该终端设备（可以存在安全域）。类似地，当FEC框架在中间箱中运行时，该中间箱可能会受到攻击，或者攻击者可以访问该中间箱。威胁还可能涉及端到端传输（例如，通过互联网）。这里，威胁的例子包括假FEC源或修复包的传输；有效数据包的重放；数据包的丢弃、延迟或错误排序；当然，还有交通窃听。
The third dimension consists in the desired security services. Among them, the content integrity and sender authentication services are probably the most important features. We can also mention DoS mitigation, anti-replay protection, or content confidentiality.
第三个维度包括所需的安全服务。其中，内容完整性和发件人身份验证服务可能是最重要的功能。我们还可以提到DoS缓解、反重播保护或内容机密性。
Finally, the fourth dimension consists in the security tools available. This is the case of the various Digital Rights Management (DRM) systems, defined outside of the context of the IETF, that can be proprietary solutions. Otherwise, the Secure Real-Time Transport Protocol (SRTP) [RFC3711] and IPsec/Encapsulating Security Payload (IPsec/ESP) [RFC4303] are two tools that can turn out to be useful in the context of the FEC Framework. Note that using SRTP requires that the application generate RTP source flows and, when applied below the
最后，第四个维度包括可用的安全工具。这是在IETF上下文之外定义的各种数字版权管理（DRM）系统的情况，这些系统可以是专有解决方案。否则，安全实时传输协议（SRTP）[RFC3711]和IPsec/封装安全有效负载（IPsec/ESP）[RFC4303]是两个在FEC框架上下文中非常有用的工具。请注意，使用SRTP需要应用程序生成RTP源流，并且在应用于
FEC Framework, that both the FEC source and repair packets be regular RTP packets. Therefore, SRTP is not considered to be a universal solution applicable in all use cases.
FEC框架，即FEC源和修复数据包都是常规RTP数据包。因此，SRTP不被认为是适用于所有用例的通用解决方案。
In the following sections, we further discuss security aspects related to the use of the FEC Framework.
在以下部分中，我们将进一步讨论与FEC框架的使用相关的安全方面。
Access control to the source flow being transmitted is typically provided by means of encryption. This encryption can be done by the content provider itself, or within the application (for instance, by using SRTP [RFC3711]), or at the network layer on a per-packet basis when IPsec/ESP is used [RFC4303]. If confidentiality is a concern, it is RECOMMENDED that one of these solutions be used. Even if we mention these attacks here, they are neither related to nor facilitated by the use of FEC.
对正在传输的源流的访问控制通常通过加密的方式提供。这种加密可以由内容提供商自己完成，也可以在应用程序内完成（例如，通过使用SRTP[RFC3711]），或者在使用IPsec/ESP时在网络层以每个数据包为基础完成[RFC4303]。如果涉及保密性，建议使用其中一种解决方案。即使我们在这里提到这些攻击，它们也与FEC的使用无关，也不为FEC的使用提供便利。
Note that when encryption is applied, this encryption MUST be applied either on the source data before the FEC protection or, if done after the FEC protection, on both the FEC source packets and repair packets (and an encryption at least as cryptographically secure as the encryption applied on the FEC source packets MUST be used for the FEC repair packets). Otherwise, if encryption were to be performed only on the FEC source packets after FEC encoding, a non-authorized receiver could be able to recover the source data after decoding the FEC repair packets, provided that a sufficient number of such packets were available.
请注意，当应用加密时，必须在FEC保护之前对源数据应用此加密，或者如果在FEC保护之后对FEC源数据包和修复数据包应用此加密（对于FEC修复数据包，必须使用至少与FEC源数据包上应用的加密一样加密安全的加密）。否则，如果在FEC编码后仅对FEC源数据包执行加密，则非授权接收器可以在解码FEC修复数据包后恢复源数据，前提是有足够数量的此类数据包可用。
The following considerations apply when choosing where to apply encryption (and more generally where to apply security services beyond encryption). Once decryption has taken place, the source data is in plaintext. The full path between the output of the deciphering module and the final destination (e.g., the TV display in the case of a video) MUST be secured, in order to prevent any unauthorized access to the source data.
在选择在何处应用加密（更一般地说，在何处应用加密以外的安全服务）时，应考虑以下事项。解密完成后，源数据将以明文形式显示。解密模块输出和最终目的地（例如，视频中的电视显示器）之间的完整路径必须安全，以防止对源数据的任何未经授权的访问。
When the FEC Framework endpoint is the end-system (i.e., where the upper application runs) and if the threat model includes the possibility that an attacker has access to this end-system, then the end-system architecture is very important. More precisely, in order to prevent an attacker from getting hold of the plaintext, all processing, once deciphering has taken place, MUST occur in a protected environment. If encryption is applied after FEC protection
如果FEC框架端点是终端系统（即，上层应用程序运行的地方），并且如果威胁模型包括攻击者有权访问该终端系统的可能性，则终端系统体系结构非常重要。更准确地说，为了防止攻击者获得明文，所有处理，一旦解密发生，必须在受保护的环境中进行。如果在FEC保护后应用加密
at the sending side (i.e., below the FEC Framework), it means that FEC decoding MUST take place in the protected environment. With certain use cases, this MAY be complicated or even impossible. In such cases, applying encryption before FEC protection is preferred.
在发送端（即，在FEC框架下），这意味着FEC解码必须在受保护的环境中进行。对于某些用例，这可能是复杂的，甚至是不可能的。在这种情况下，最好在FEC保护之前应用加密。
When the FEC Framework endpoint is a middlebox, the recovered source flow, after FEC decoding, SHOULD NOT be sent in plaintext to the final destination(s) if the threat model includes the possibility that an attacker eavesdrops on the traffic. In that case, it is preferable to apply encryption before FEC protection.
当FEC框架终结点是一个中间盒时，如果威胁模型包括攻击者窃听流量的可能性，则FEC解码后恢复的源流不应以明文形式发送到最终目的地。在这种情况下，最好在FEC保护之前应用加密。
In some cases, encryption could be applied both before and after the FEC protection. The considerations described above still apply in such cases.
在某些情况下，可以在FEC保护之前和之后应用加密。上述注意事项仍适用于此类情况。
Protection against corruptions (e.g., against forged FEC source/ repair packets) is achieved by means of a content integrity verification/source authentication scheme. This service is usually provided at the packet level. In this case, after removing all the forged packets, the source flow might sometimes be recovered. Several techniques can provide this content integrity/source authentication service:
通过内容完整性验证/源认证方案实现对损坏的保护（例如，针对伪造的FEC源/修复数据包）。此服务通常在数据包级别提供。在这种情况下，删除所有伪造数据包后，有时可能会恢复源流。有几种技术可以提供此内容完整性/源身份验证服务：
o At the application layer, SRTP [RFC3711] provides several solutions to check the integrity and authenticate the source of RTP and RTCP messages, among other services. For instance, when associated with the Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [RFC4383], SRTP is an attractive solution that is robust to losses, provides a true authentication/integrity service, and does not create any prohibitive processing load or transmission overhead. Yet, with TESLA, checking a packet requires a small delay (a second or more) after its reception. Whether or not this extra delay, both in terms of startup delay at the client and end-to-end delay, is appropriate depends on the target use case. In some situations, this might degrade the user experience. In other situations, this will not be an issue. Other building blocks can be used within SRTP to provide content integrity/authentication services.
o 在应用层，SRTP[RFC3711]提供了多种解决方案，用于检查RTP和RTCP消息的完整性并验证其来源，以及其他服务。例如，当与定时高效流丢失容忍认证（TESLA）[RFC4383]相关联时，SRTP是一个具有吸引力的解决方案，它对丢失具有鲁棒性，提供真正的认证/完整性服务，并且不会产生任何禁止性的处理负载或传输开销。然而，对于特斯拉来说，检查数据包需要在接收后有一个小的延迟（一秒或更长）。这个额外的延迟（客户端的启动延迟和端到端延迟）是否合适取决于目标用例。在某些情况下，这可能会降低用户体验。在其他情况下，这将不是一个问题。可以在SRTP中使用其他构建块来提供内容完整性/身份验证服务。
o At the network layer, IPsec/ESP [RFC4303] offers (among other services) an integrity verification mechanism that can be used to provide authentication/content integrity services.
o 在网络层，IPsec/ESP[RFC4303]提供（除其他服务外）完整性验证机制，可用于提供身份验证/内容完整性服务。
It is up to the developer and the person in charge of deployment, who know the security requirements and features of the target application area, to define which solution is the most appropriate. Nonetheless, it is RECOMMENDED that at least one of these techniques be used.
由开发人员和负责部署的人员（他们了解目标应用程序领域的安全需求和功能）来定义哪种解决方案最合适。尽管如此，建议至少使用其中一种技术。
Note that when integrity protection is applied, it is RECOMMENDED that it take place on both FEC source and repair packets. The motivation is to keep corrupted packets from being considered during decoding, as such packets would often lead to a decoding failure or result in a corrupted decoded source flow.
注意，当应用完整性保护时，建议在FEC源和修复数据包上都进行完整性保护。其动机是在解码期间不考虑损坏的数据包，因为此类数据包通常会导致解码失败或导致损坏的解码源流。
Attacks on these FEC parameters can prevent the decoding of the associated object. For instance, modifying the finite field size of a Reed-Solomon FEC scheme (when applicable) will lead a receiver to consider a different FEC code.
对这些FEC参数的攻击可以阻止相关对象的解码。例如，修改里德-所罗门FEC方案（适用时）的有限场大小将导致接收机考虑不同的FEC码。
Therefore, it is RECOMMENDED that security measures be taken to guarantee the integrity of the FEC Framework Configuration Information. Since the FEC Framework does not define how the FEC Framework Configuration Information is communicated from sender to receiver, we cannot provide further recommendations on how to guarantee its integrity. However, any complete CDP specification MUST give recommendations on how to achieve it. When the FEC Framework Configuration Information is sent out-of-band, e.g., in a session description, it SHOULD be protected, for instance, by digitally signing it.
因此，建议采取安全措施保证FEC框架配置信息的完整性。由于FEC框架没有定义如何将FEC框架配置信息从发送方传递到接收方，因此我们无法提供关于如何保证其完整性的进一步建议。然而，任何完整的CDP规范都必须给出如何实现它的建议。当FEC框架配置信息在带外发送时，例如在会话描述中，应该对其进行保护，例如，对其进行数字签名。
Attacks are also possible against some FEC parameters included in the Explicit Source FEC Payload ID and Repair FEC Payload ID. For instance, modifying the Source Block Number of a FEC source or repair packet will lead a receiver to assign this packet to a wrong block.
还可能对显式源FEC有效负载ID和修复FEC有效负载ID中包含的某些FEC参数进行攻击。例如，修改FEC源或修复数据包的源块号将导致接收器将该数据包分配到错误的数据块。
Therefore, it is RECOMMENDED that security measures be taken to guarantee the integrity of the Explicit Source FEC Payload ID and Repair FEC Payload ID. To that purpose, one of the packet-level source authentication/content integrity techniques described in Section 9.2.2 can be used.
因此，建议采取安全措施，以保证显式源FEC有效负载ID的完整性，并修复FEC有效负载ID。为此，可使用第9.2.2节所述的包级源认证/内容完整性技术之一。
When several source flows, with different security requirements, need to be FEC protected jointly, within a single FEC Framework instance, then each flow MAY be processed appropriately, before the protection. For instance, source flows that require access control MAY be encrypted before they are FEC protected.
当具有不同安全性要求的多个源流需要在单个FEC框架实例内共同受到FEC保护时，则可以在保护之前适当地处理每个流。例如，需要访问控制的源流可以在FEC保护之前进行加密。
There are also situations where the only insecure domain is the one over which the FEC Framework operates. In that case, this situation MAY be addressed at the network layer, using IPsec/ESP (see Section 9.5), even if only a subset of the source flows has strict security requirements.
还有一些情况下，唯一不安全的域是FEC框架操作的域。在这种情况下，可以在网络层使用IPsec/ESP（见第9.5节）解决这种情况，即使只有一部分源流具有严格的安全要求。
Since the use of the FEC Framework should not add any additional threat, it is RECOMMENDED that the FEC Framework aggregate flow be in line with the maximum security requirements of the individual source flows. For instance, if denial-of-service (DoS) protection is required, an integrity protection SHOULD be provided below the FEC Framework, using, for instance, IPsec/ESP.
由于FEC框架的使用不应增加任何额外的威胁，因此建议FEC框架聚合流符合单个源流的最大安全要求。例如，如果需要拒绝服务（DoS）保护，则应在FEC框架下提供完整性保护，例如使用IPsec/ESP。
Generally speaking, whenever feasible, it is RECOMMENDED that FEC protecting flows with totally different security requirements be avoided. Otherwise, significant processing overhead would be added to protect source flows that do not need it.
一般来说，只要可行，建议避免具有完全不同安全要求的FEC保护流。否则，将增加大量的处理开销，以保护不需要它的源流。
The FEC Framework has been defined in such a way to be independent from the application that generates source flows. Some applications might use purely unidirectional flows, while other applications might also use unicast feedback from the receivers. For instance, this is the case when considering RTP/RTCP-based source flows.
FEC框架以独立于生成源流的应用程序的方式定义。一些应用程序可能使用纯单向流，而其他应用程序也可能使用来自接收器的单播反馈。例如，考虑基于RTP/RTCP的源流时就是这种情况。
This section describes a baseline mode of secure FEC Framework operation based on the application of the IPsec protocol, which is one possible solution to solve or mitigate the security threats introduced by the use of the FEC Framework.
本节描述了基于IPsec协议应用的安全FEC框架操作的基线模式，这是解决或缓解FEC框架使用带来的安全威胁的一种可能的解决方案。
Two related documents are of interest. First, Section 5.1 of [RFC5775] defines a baseline secure Asynchronous Layered Coding (ALC) operation for sender-to-group transmissions, assuming the presence of a single sender and a source-specific multicast (SSM) or SSM-like operation. The proposed solution, based on IPsec/ESP, can be used to provide a baseline FEC Framework secure operation, for the downstream source flow.
有两份相关文件值得关注。首先，[RFC5775]第5.1节定义了发送方到组传输的基线安全异步分层编码（ALC）操作，假设存在单个发送方和源特定多播（SSM）或类似SSM的操作。所提出的解决方案基于IPsec/ESP，可用于为下游源流提供基线FEC框架安全操作。
Second, Section 7.1 of [RFC5740] defines a baseline secure NACK-Oriented Reliable Multicast (NORM) operation, for sender-to-group transmissions as well as unicast feedback from receivers. Here, it is also assumed there is a single sender. The proposed solution is also based on IPsec/ESP. However, the difference with respect to [RFC5775] relies on the management of IPsec Security Associations (SAs) and corresponding Security Policy Database (SPD) entries, since NORM requires a second set of SAs and SPD entries to be defined to protect unicast feedback from receivers.
第二，[RFC5740]第7.1节定义了一个基线安全的面向NACK的可靠多播（NORM）操作，用于发送方到组的传输以及来自接收方的单播反馈。这里，还假设只有一个发送者。提议的解决方案也基于IPsec/ESP。然而，[RFC5775]的区别在于IPsec安全关联（SA）和相应的安全策略数据库（SPD）条目的管理，因为NORM要求定义第二组SAs和SPD条目，以保护来自接收器的单播反馈。
Note that the IPsec/ESP requirement profiles outlined in [RFC5775] and [RFC5740] are commonly available on many potential hosts. They can form the basis of a secure mode of operation. Configuration and operation of IPsec typically require privileged user authorization. Automated key management implementations are typically configured with the privileges necessary to allow the needed system IPsec configuration.
请注意，[RFC5775]和[RFC5740]中概述的IPsec/ESP需求配置文件通常在许多潜在主机上可用。它们可以构成安全操作模式的基础。IPsec的配置和操作通常需要特权用户授权。自动密钥管理实现通常配置有允许所需系统IPsec配置所需的特权。
The question of operating and managing the FEC Framework and the associated FEC scheme(s) is of high practical importance. The goals of this section are to discuss aspects and recommendations related to specific deployments and solutions.
操作和管理FEC框架和相关FEC方案的问题具有高度的实际重要性。本节的目标是讨论与特定部署和解决方案相关的方面和建议。
In particular, this section discusses the questions of interoperability across vendors/use cases and whether defining mandatory-to-implement (but not mandatory-to-use) solutions is beneficial.
特别是，本节讨论了跨供应商/用例的互操作性问题，以及定义强制实施（但非强制使用）解决方案是否有益。
Several aspects need to be considered, since they will directly impact the way the FEC Framework and the associated FEC schemes can be operated and managed.
需要考虑几个方面，因为它们将直接影响FEC框架和相关FEC方案的操作和管理方式。
This section lists them as follows:
本节将其列示如下：
1. A Single Small Generic Component within a Larger (and Often Legacy) Solution: The FEC Framework is one component within a larger solution that includes one or several upper-layer applications (that generate one or several ADU flows) and an underlying protocol stack. A key design principle is that the FEC Framework should be able to work without making any assumption with respect to either the upper-layer application(s) or the underlying protocol stack, even if there are special cases where assumptions are made.
1. 大型（通常是遗留）解决方案中的单个小型通用组件：FEC框架是大型解决方案中的一个组件，包括一个或多个上层应用程序（生成一个或多个ADU流）和底层协议堆栈。一个关键的设计原则是，FEC框架应该能够在不对上层应用程序或底层协议栈进行任何假设的情况下工作，即使存在作出假设的特殊情况。
2. One-to-One with Feedback vs. One-to-Many with Feedback vs. One-to-Many without Feedback Scenarios: The FEC Framework can be used in use cases that completely differ from one another. Some use cases are one-way (e.g., in broadcast networks), with either a one-to-one, one-to-many, or many-to-many transmission model, and the receiver(s) cannot send any feedback to the sender(s). Other use cases follow a bidirectional one-to-one, one-to-many, or many-to-many scenario, and the receiver(s) can send feedback to the sender(s).
2. 有反馈的一对一、有反馈的一对多、无反馈的一对多场景：FEC框架可用于完全不同的用例中。一些用例是单向的（例如，在广播网络中），具有一对一、一对多或多对多传输模型，并且接收器不能向发送者发送任何反馈。其他用例遵循双向一对一、一对多或多对多场景，接收方可以向发送方发送反馈。
3. Non-FEC Framework Capable Receivers: With the one-to-many and many-to-many use cases, the receiver population might have different capabilities with respect to the FEC Framework itself and the supported FEC schemes. Some receivers might not be capable of decoding the repair packets belonging to a particular FEC scheme, while some other receivers might not support the FEC Framework at all.
3. 不支持FEC框架的接收器：对于一对多和多对多用例，接收器群体可能具有与FEC框架本身和支持的FEC方案不同的能力。一些接收机可能无法解码属于特定FEC方案的修复分组，而一些其他接收机可能根本不支持FEC框架。
4. Internet vs. Non-Internet Networks: The FEC Framework can be useful in many use cases that use a transport network that is not the public Internet (e.g., with IPTV or Mobile TV). In such networks, the operational and management considerations can be achieved through an open or proprietary solution, which is specified outside of the IETF.
4. 互联网与非互联网网络：FEC框架在使用非公共互联网的传输网络（例如，IPTV或移动电视）的许多用例中都很有用。在此类网络中，可通过IETF之外指定的开放或专有解决方案实现操作和管理考虑。
5. Congestion Control Considerations: See Section 8 for a discussion on whether or not congestion control is needed, and its relationships with the FEC Framework.
5. 拥塞控制注意事项：有关是否需要拥塞控制及其与FEC框架的关系的讨论，请参见第8节。
6. Within End-Systems vs. within Middleboxes: The FEC Framework can be used within end-systems, very close to the upper-layer application, or within dedicated middleboxes (for instance, when it is desired to protect one or several flows while they cross a lossy channel between two or more remote sites).
6. 终端系统内与中间盒内：FEC框架可在终端系统内使用，非常接近上层应用程序，或在专用中间盒内使用（例如，当一个或多个流穿过两个或多个远程站点之间的有损信道时，需要保护一个或多个流）。
7. Protecting a Single Flow vs. Several Flows Globally: The FEC Framework can be used to protect a single flow or several flows globally.
7. 全局保护单个流与多个流：FEC框架可用于全局保护单个流或多个流。
Overall, from the discussion in Section 10.1, it is clear that the CDPs and FEC schemes compatible with the FEC Framework differ widely in their capabilities, application, and deployment scenarios such that a common operation and management method or protocol that works well for all of them would be too complex to define. Thus, as a design choice, the FEC Framework does not dictate the use of any particular technology or protocol for transporting FEC data, managing the hosts, signaling the configuration information, or encoding the configuration information. This provides flexibility and is one of the main goals of the FEC Framework. However, this section gives some RECOMMENDED guidelines.
总的来说，从第10.1节中的讨论可以看出，与FEC框架兼容的CDP和FEC方案在其能力、应用和部署场景方面存在很大差异，因此，一个通用的操作和管理方法或协议对所有这些方案都适用，这将太复杂，无法定义。因此，作为一种设计选择，FEC框架不规定使用任何特定技术或协议来传输FEC数据、管理主机、向配置信息发送信号或编码配置信息。这提供了灵活性，也是FEC框架的主要目标之一。但是，本节给出了一些建议指南。
1. A Single Small Generic Component within a Larger (and Often Legacy) Solution: It is anticipated that the FEC Framework will often be used to protect one or several RTP streams. Therefore, implementations SHOULD make feedback information accessible via RTCP to enable users to take advantage of the tools using (or used by) RTCP to operate and manage the FEC Framework instance along with the associated FEC schemes.
1. 大型（通常是遗留）解决方案中的单个小型通用组件：预计FEC框架通常用于保护一个或多个RTP流。因此，实施应通过RTCP访问反馈信息，使用户能够利用RTCP使用（或使用）的工具操作和管理FEC框架实例以及相关的FEC方案。
2. One-to-One with Feedback vs. One-to-Many with Feedback vs. One-to-Many without Feedback Scenarios: With use cases that are one-way, the FEC Framework sender does not have any way to gather feedback from receivers. With use cases that are bidirectional, the FEC Framework sender can collect detailed feedback (e.g., in the case of a one-to-one scenario) or at least occasional feedback (e.g., in the case of a multicast, one-to-many scenario). All these applications have naturally different operational and management aspects. They also have different requirements or features, if any, for collecting feedback, processing it, and acting on it. The data structures for carrying the feedback also vary.
2. 有反馈的一对一与有反馈的一对多与没有反馈的一对多场景：对于单向用例，FEC框架发送者没有任何方法从接收者收集反馈。对于双向的用例，FEC框架发送者可以收集详细的反馈（例如，在一对一场景的情况下）或至少偶尔的反馈（例如，在多播的情况下，一对多场景）。所有这些应用程序自然具有不同的操作和管理方面。他们也有不同的要求或特点，如果有的话，用于收集反馈、处理反馈和采取行动。用于承载反馈的数据结构也各不相同。
Implementers SHOULD make feedback available using either an in-band or out-of-band asynchronous reporting mechanism. When an out-of-band solution is preferred, a standardized reporting mechanism, such as Syslog [RFC5424] or Simple Network Management Protocol (SNMP) notifications [RFC3411], is RECOMMENDED. When required, a mapping mechanism between the Syslog and SNMP reporting mechanisms could be used, as described in [RFC5675] and [RFC5676].
实现者应该使用带内或带外异步报告机制提供反馈。当首选带外解决方案时，建议使用标准化的报告机制，如Syslog[RFC5424]或简单网络管理协议（SNMP）通知[RFC3411]。需要时，可以使用Syslog和SNMP报告机制之间的映射机制，如[RFC5675]和[RFC5676]中所述。
3. Non-FEC Framework Capable Receivers: Section 5.3 gives recommendations on how to provide backward compatibility in the presence of receivers that cannot support the FEC scheme being used or the FEC Framework itself: basically, the use of Explicit Source FEC Payload ID is banned. Additionally, a non-FEC Framework capable receiver MUST also have a means not to receive the repair packets that it will not be able to decode in the first place or a means to identify and discard them appropriately upon receiving them. This SHOULD be achieved by sending repair packets on a different transport-layer flow. In the case of RTP transport, and if both source and repair packets will be sent on the same transport-layer flow, this SHOULD be achieved by using an RTP framing for FEC repair packets with a different payload type. It is the responsibility of the sender to select the appropriate mechanism when needed.
3. 不支持FEC框架的接收器：第5.3节给出了如何在存在无法支持所使用的FEC方案或FEC框架本身的接收器时提供向后兼容性的建议：基本上，禁止使用显式源FEC有效负载ID。此外，不支持FEC框架的接收器还必须具有不接收其首先将无法解码的修复包的方法，或者在接收到修复包时适当地识别和丢弃修复包的方法。这应该通过在不同的传输层流上发送修复包来实现。在RTP传输的情况下，如果源数据包和修复数据包都将在同一传输层流上发送，那么这应该通过对具有不同有效负载类型的FEC修复数据包使用RTP帧来实现。发送方有责任在需要时选择适当的机制。
4. Within End-Systems vs. within Middleboxes: When the FEC Framework is used within middleboxes, it is RECOMMENDED that the paths between the hosts where the sending applications run and the middlebox that performs FEC encoding be as reliable as possible, i.e., not be prone to packet loss, packet reordering, or varying delays in delivering packets.
4. 终端系统内与中间盒内：当在中间盒内使用FEC框架时，建议发送应用程序运行的主机与执行FEC编码的中间盒之间的路径尽可能可靠，即不易丢失数据包、数据包重新排序或传输数据包时出现不同的延迟。
Similarly, when the FEC Framework is used within middleboxes, it is RECOMMENDED that the paths be as reliable as possible between the middleboxes that perform FEC decoding and the end-systems where the receiving applications operate.
类似地，当在中间盒内使用FEC框架时，建议执行FEC解码的中间盒与接收应用程序运行的终端系统之间的路径尽可能可靠。
5. Management of Communication Issues before Reaching the Sending FECFRAME Instance: Let us consider situations where the FEC Framework is used within middleboxes. At the sending side, the general reliability recommendation for the path between the sending applications and the middlebox is important, but it may not guarantee that a loss, reordering, or long delivery delay cannot happen, for whatever reason. If such a rare event happens, this event SHOULD NOT compromise the operation of the FECFRAME instances, at either the sending side or the receiving side. This is particularly important with FEC schemes that do not modify the ADU for backward-compatibility purposes (i.e., do not use any Explicit Source FEC Payload ID) and rely on, for instance, the RTP sequence number field to identify FEC source packets within their source block. In this case, packet loss or packet reordering leads to a gap in the RTP sequence number space seen by the FECFRAME instance. Similarly, varying delay in delivering packets over this path can lead to significant timing issues. With FEC schemes that indicate in the Repair FEC Payload ID, for each source block, the base RTP sequence number and number of consecutive RTP packets that belong to this source block, a missing ADU or an ADU delivered out of order could cause the FECFRAME sender to switch to a new source block. However, some FEC schemes and/or receivers may not necessarily handle such varying source block sizes. In this case, one could consider duplicating the last ADU received before the loss, or inserting zeroed ADU(s), depending on the nature of the ADU flow. Implementers SHOULD consider the consequences of such alternative approaches, based on their use cases.
5. 在到达发送FECGrice实例之前，管理通信问题：让我们考虑FEC框架在中间框中使用的情况。在发送端，发送应用程序和中间盒之间路径的一般可靠性建议很重要，但它可能无法保证无论出于何种原因，都不会发生丢失、重新订购或长时间交付延迟。如果发生这种罕见的事件，则该事件不应影响发送侧或接收侧的FECFRAME实例的操作。这对于不出于向后兼容性目的修改ADU（即，不使用任何显式源FEC有效负载ID）并且依赖于例如RTP序列号字段来识别其源块内的FEC源分组的FEC方案尤其重要。在这种情况下，数据包丢失或数据包重新排序会导致FECFRAME实例看到的RTP序列号空间出现间隙。类似地，通过该路径传递数据包时的不同延迟可能导致重大的定时问题。对于在修复FEC有效负载ID中指示的FEC方案，对于每个源块，基本RTP序列号和属于该源块的连续RTP分组的数量，丢失的ADU或无序交付的ADU可能导致FECFRAME发送器切换到新的源块。然而，一些FEC方案和/或接收机可能不一定处理这种变化的源块大小。在这种情况下，根据ADU流的性质，可以考虑复制丢失之前接收到的最后ADU，或者插入零点ADU（S）。实施者应考虑这些替代方法的后果，基于它们的使用情况。
6. Protecting a Single Flow vs. Several Flows Globally: In the general case, the various ADU flows that are globally protected can have different features, and in particular different real-time requirements (in the case of real-time flows). The process of globally protecting these flows SHOULD take into account the requirements of each individual flow. In particular, it would be counterproductive to add repair traffic to a real-time flow for
6. 全局保护单个流与多个流：在一般情况下，全局保护的各种ADU流可以具有不同的特性，特别是不同的实时要求（在实时流的情况下）。全球保护这些流量的过程应考虑到每个单独流量的要求。特别是，将修复流量添加到实时数据流中会适得其反
which the FEC decoding delay at a receiver makes decoded ADUs for this flow useless because they do not satisfy the associated real-time constraints. From a practical point of view, this means that the source block creation process at the sending FEC Framework instance SHOULD consider the most stringent real-time requirements of the ADU flows being globally protected.
接收机处的FEC解码延迟使得该流的解码ADU无用，因为它们不满足相关的实时约束。从实际的角度来看，这意味着在发送FEC框架实例的源块创建过程应该考虑到被全局保护的ADU流的最严格的实时要求。
7. ADU Flow Bundle Definition and Flow Delivery: By design, a repair flow might enable a receiver to recover the ADU flow(s) that it protects even if none of the associated FEC source packets are received. Therefore, when defining the bundle of ADU flows that are globally protected and when defining which receiver receives which flow, the sender SHOULD make sure that the ADU flow(s) and repair flow(s) of that bundle will only be received by receivers that are authorized to receive all the ADU flows of that bundle. See Section 9.4 for additional recommendations for situations where strict access control for ADU flows is needed.
7. ADU流束定义和流交付：根据设计，修复流可能使接收器能够恢复其保护的ADU流，即使没有收到任何相关FEC源数据包。因此，当定义受全局保护的ADU流束以及定义哪个接收方接收哪个流时，发送方应确保该束的ADU流和修复流将仅由授权接收该束的所有ADU流的接收方接收。有关需要对ADU流进行严格访问控制的情况的其他建议，请参见第9.4节。
Additionally, when multiple ADU flows are globally protected, a receiver that wants to benefit from FECFRAME loss protection SHOULD receive all the ADU flows of the bundle. Otherwise, the missing FEC source packets would be considered lost, which might significantly reduce the efficiency of the FEC scheme.
此外，当多个ADU流受到全局保护时，想要从FEC帧丢失保护中获益的接收器应该接收捆绑包的所有ADU流。否则，丢失的FEC源分组将被视为丢失，这可能显著降低FEC方案的效率。
FEC schemes for use with this framework are identified in protocols using FEC Encoding IDs. Values of FEC Encoding IDs are subject to IANA registration. For this purpose, this document creates a new registry called the "FEC Framework (FECFRAME) FEC Encoding IDs".
用于此框架的FEC方案在使用FEC编码ID的协议中标识。FEC编码ID的值受IANA注册的约束。为此，本文创建了一个名为“FEC框架（FEC框架）FEC编码ID”的新注册表。
The values that can be assigned within the "FEC Framework (FECFRAME) FEC Encoding IDs" registry are numeric indexes in the range (0, 255). Values of 0 and 255 are reserved. Assignment requests are granted on an IETF Review basis as defined in [RFC5226]. Section 5.6 defines explicit requirements that documents defining new FEC Encoding IDs should meet.
可以在“FEC框架（FEC框架）FEC编码ID”注册表中分配的值是范围（0255）内的数字索引。保留0和255的值。根据[RFC5226]中的定义，分配请求在IETF审查的基础上获得批准。第5.6节定义了定义新FEC编码ID的文件应满足的明确要求。
This document is based in part on [FEC-SF], and so thanks are due to the additional authors of that document: Mike Luby, Magnus Westerlund, and Stephan Wenger. That document was in turn based on the FEC Streaming Protocol defined by 3GPP in [MBMSTS], and thus, thanks are also due to the participants in 3GPP SA Working Group 4. Further thanks are due to the members of the FECFRAME Working Group for their comments and reviews.
本文件部分基于[FEC-SF]，因此感谢该文件的其他作者：迈克·鲁比、马格纳斯·韦斯特隆德和斯蒂芬·温格。该文档反过来基于3GPP在[MBMSTS]中定义的FEC流协议，因此，也要感谢3GPP SA工作组4的参与者。还应感谢FECFRAME工作组成员的评论和审查。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411]Harrington，D.，Presohn，R.，和B.Wijnen，“描述简单网络管理协议（SNMP）管理框架的体系结构”，STD 62，RFC 3411，2002年12月。
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5052]Watson，M.，Luby，M.，和L.Vicisano，“前向纠错（FEC）构建块”，RFC 5052，2007年8月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424]Gerhards，R.，“系统日志协议”，RFC 54242009年3月。
[FEC-SF] Watson, M., Luby, M., Westerlund, M., and S. Wenger, "Forward Error Correction (FEC) Streaming Framework", Work in Progress, July 2005.
[FEC-SF]Watson，M.，Luby，M.，Westerlund，M.，和S.Wenger，“前向纠错（FEC）流媒体框架”，正在进行的工作，2005年7月。
[MBMSTS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs", 3GPP TS 26.346, March 2009, <http://ftp.3gpp.org/specs/html-info/26346.htm>.
[MBMSTS]3GPP，“多媒体广播/多播服务（MBMS）；协议和编解码器”，3GPP TS 26.3462009年3月<http://ftp.3gpp.org/specs/html-info/26346.htm>.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[RFC3095]Bormann，C.，Burmeister，C.，Degermark，M.，Fukushima，H.，Hannu，H.，Jonsson，L-E.，Hakenberg，R.，Koren，T.，Le，K.，Liu，Z.，Martenson，A.，Miyazaki，A.，Svanbro，K.，Wiebke，T.，Yoshimura，T.，和H.Zheng，“鲁棒头压缩（ROHC）：框架和四个配置文件：RTP，UDP，ESP，和未压缩”，RFC 3095，2001年7月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)", RFC 4383, February 2006.
[RFC4383]Baugher，M.和E.Carrara，“在安全实时传输协议（SRTP）中使用定时高效流丢失容忍认证（TESLA）”，RFC 4383，2006年2月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006.
[RFC4588]Rey，J.，Leon，D.，Miyazaki，A.，Varsa，V.，和R.Hakenberg，“RTP重传有效载荷格式”，RFC 4588，2006年7月。
[RFC5675] Marinov, V. and J. Schoenwaelder, "Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages", RFC 5675, October 2009.
[RFC5675]Marinov，V.和J.Schoenwaeld，“将简单网络管理协议（SNMP）通知映射到系统日志消息”，RFC 5675，2009年10月。
[RFC5676] Schoenwaelder, J., Clemm, A., and A. Karmakar, "Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications", RFC 5676, October 2009.
[RFC5676]Schoenwaeld，J.，Clemm，A.，和A.Karmakar，“将系统日志消息映射到简单网络管理协议（SNMP）通知的受管对象的定义”，RFC 5676，2009年10月。
[RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)", RFC 5725, February 2010.
[RFC5725]Begen，A.，Hsu，D.，和M.Lague，“RTP控制协议（RTCP）扩展报告（XRs）的修复后损失RLE报告块类型”，RFC 5725，2010年2月。
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", RFC 5740, November 2009.
[RFC5740]Adamson，B.，Bormann，C.，Handley，M.，和J.Macker，“面向NACK的可靠多播（NORM）传输协议”，RFC 57402009年11月。
[RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 5775, April 2010.
[RFC5775]Luby，M.，Watson，M.，和L.Vicisano，“异步分层编码（ALC）协议实例化”，RFC 5775，2010年4月。
[RFC6364] Begen, A., "Session Description Protocol Elements for FEC Framework", RFC 6364, October 2011.
[RFC6364]Begen，A.，“FEC框架的会话描述协议元素”，RFC6364，2011年10月。
Authors' Addresses
作者地址
Mark Watson Netflix, Inc. 100 Winchester Circle Los Gatos, CA 95032 USA
Mark Watson Netflix，Inc.美国加利福尼亚州洛斯加托斯温彻斯特圈100号，邮编95032
EMail: watsonm@netflix.com
EMail: watsonm@netflix.com
Ali Begen Cisco 181 Bay Street Toronto, ON M5J 2T3 Canada
Ali Begen Cisco位于加拿大多伦多湾街181号M5J 2T3
EMail: abegen@cisco.com
EMail: abegen@cisco.com
Vincent Roca INRIA 655, av. de l'Europe Inovallee; Montbonnot ST ISMIER cedex 38334 France
Vincent Roca INRIA 655，av。欧洲伊诺瓦利；蒙博诺圣伊斯梅尔塞德斯38334法国
EMail: vincent.roca@inria.fr
URI: http://planete.inrialpes.fr/people/roca/
EMail: vincent.roca@inria.fr
URI: http://planete.inrialpes.fr/people/roca/