Internet Engineering Task Force (IETF) U. Kozat
Request for Comments: 6801 DOCOMO Innovations
Category: Informational A. Begen
ISSN: 2070-1721 Cisco
November 2012
Internet Engineering Task Force (IETF) U. Kozat
Request for Comments: 6801 DOCOMO Innovations
Category: Informational A. Begen
ISSN: 2070-1721 Cisco
November 2012
Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in the Forward Error Correction (FEC) Framework
前向纠错（FEC）框架中用于保护多个源流的伪内容交付协议（CDP）
Abstract
摘要
This document provides a pseudo Content Delivery Protocol (CDP) to protect multiple source flows with one or more repair flows based on the Forward Error Correction (FEC) Framework and the Session Description Protocol (SDP) elements defined for the framework. The purpose of the document is not to provide a full-fledged protocol but to show how the defined framework and SDP elements can be combined together to implement a CDP.
本文档提供了一个伪内容交付协议（CDP），以基于前向纠错（FEC）框架和为该框架定义的会话描述协议（SDP）元素，使用一个或多个修复流保护多个源流。本文档的目的不是提供一个完整的协议，而是展示如何将已定义的框架和SDP元素组合在一起以实现CDP。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc6801.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6801.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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/Abbreviations .......................................3
3. Construction of a Repair Flow from Multiple Source Flows ........3
3.1. Example: Two Source Flows Protected by a Single
Repair Flow ................................................6
4. Reconstruction of Source Flows from Repair Flow(s) ..............9
4.1. Example: Multiple Source Flows Protected by a
Single Repair Flow .........................................9
5. Security Considerations ........................................10
6. Acknowledgments ................................................10
7. Normative References ...........................................11
1. Introduction ....................................................3
2. Definitions/Abbreviations .......................................3
3. Construction of a Repair Flow from Multiple Source Flows ........3
3.1. Example: Two Source Flows Protected by a Single
Repair Flow ................................................6
4. Reconstruction of Source Flows from Repair Flow(s) ..............9
4.1. Example: Multiple Source Flows Protected by a
Single Repair Flow .........................................9
5. Security Considerations ........................................10
6. Acknowledgments ................................................10
7. Normative References ...........................................11
The Forward Error Correction (FEC) Framework (described in [RFC6363]) and SDP Elements for FEC Framework (described in [RFC6364]) together define mechanisms sufficient enough to build an actual Content Delivery Protocol (CDP) with FEC protection. Methods to convey FEC Framework Configuration Information (described in [RFC6695]), on the other hand, provide the signaling protocols that may be used as part of CDP to communicate FEC-Scheme-Specific Information from FEC sender to a single as well as multiple FEC receivers. This document provides a guideline on how the mechanisms defined in [RFC6363] and [RFC6364] can be sufficiently used to design a CDP over a non-trivial scenario, namely, protection of multiple source flows with one or more repair flows.
前向纠错（FEC）框架（如[RFC6363]所述）和FEC框架的SDP元素（如[RFC6364]所述）共同定义了足以构建具有FEC保护的实际内容交付协议（CDP）的机制。另一方面，用于传送FEC框架配置信息的方法（在[RFC6695]中描述）提供信令协议，该信令协议可被用作CDP的一部分，以将FEC方案特定信息从FEC发送方传送到单个以及多个FEC接收机。本文件提供了一个指南，说明如何充分利用[RFC6363]和[RFC6364]中定义的机制在非平凡场景中设计CDP，即使用一个或多个修复流保护多个源流。
In particular, we provide clarifications and descriptions on how:
特别是，我们对如何：
o source and repair flows may be uniquely identified,
o 来源和维修流程可以唯一标识，
o source blocks may be generated from one or more source flows,
o 源块可以由一个或多个源流生成，
o repair flows may be paired with the source flows,
o 修复流可以与源流配对，
o the receiver explicitly and implicitly identifies individual flows, and
o 接收方显式和隐式地标识各个流，以及
o source blocks are regenerated at the receiver and the missing source symbols in a source block are recovered.
o 在接收器处重新生成源块，并恢复源块中丢失的源符号。
This document uses all the definitions and abbreviations from Section 2 of [RFC6363] minus the RFC 2119 requirements language.
本文件使用[RFC6363]第2节中的所有定义和缩写，减去RFC 2119需求语言。
At the sender side, CDP constructs the source blocks (SBs) by multiplexing transport payloads from multiple flows (see Figures 1 and 2). According to the FEC Framework, each source block is FEC-protected separately. Each source block is given to the specific FEC encoder used within the CDP as input and as the outputs Explicit Source FEC Payload ID, Repair FEC Payload ID, and Repair Payloads corresponding to that source block are generated. Note that the Explicit Source FEC Payload ID is optional, and if the CDP has an implicit means of constructing the source block at the sender/ receiver (e.g., by using any existing sequence numbers in the payload), the Explicit Source FEC Payload ID might not be output.
在发送方，CDP通过多路复用来自多个流的传输有效负载来构造源块（SBs）（见图1和图2）。根据FEC框架，每个源块分别受到FEC保护。每个源块被给予CDP内使用的特定FEC编码器作为输入和输出，并生成与该源块对应的显式源FEC有效负载ID、修复FEC有效负载ID和修复有效负载。注意，显式源FEC有效载荷ID是可选的，并且如果CDP具有在发送器/接收器处构造源块的隐式方法（例如，通过使用有效载荷中的任何现有序列号），则显式源FEC有效载荷ID可能不会被输出。
+------------+
s_1 --------> | |
. Source | Source | +--------+ +--------+ +--------+
. Flows | Block |==> ..|SB_(j+1)| | SB_j | |SB_(j-1)| ..
s_n --------> | Generation | +--------+ +--------+ +--------+
+------------+
+------------+
s_1 --------> | |
. Source | Source | +--------+ +--------+ +--------+
. Flows | Block |==> ..|SB_(j+1)| | SB_j | |SB_(j-1)| ..
s_n --------> | Generation | +--------+ +--------+ +--------+
+------------+
Figure 1: Source Block Generation for a FEC Scheme
图1：FEC方案的源块生成
Figure 2 shows the structure of a source block. A CDP must clearly specify which payload corresponds to which source flow and the length of each payload.
图2显示了源块的结构。CDP必须明确指定哪个有效负载对应于哪个源流以及每个有效负载的长度。
<------------------ Source Block (SB) ------------------->
<------------------ Source Block (SB) ------------------->
+-------...-----+-------...-----+- -+-------...-----+
| Payload_1 | Payload_2 | . . . | Payload_n |
+-------...-----+-------...-----+- -+-------...-----+
\______ _______|______ _______| |______ _______|
\/ \/ \/
FID_1,Len_1 FID_2,Len_2 FID_n,Len_n
+-------...-----+-------...-----+- -+-------...-----+
| Payload_1 | Payload_2 | . . . | Payload_n |
+-------...-----+-------...-----+- -+-------...-----+
\______ _______|______ _______| |______ _______|
\/ \/ \/
FID_1,Len_1 FID_2,Len_2 FID_n,Len_n
Figure 2: Structure of a Source Block
图2：源块的结构
The Flow ID (FID) value provides a unique shorthand identifier for the source flows. FID is specified and associated with the possibly wildcarded tuple of {source IP address, source port, destination IP address, destination port, transport protocol} in the SDP description. When wildcarded, certain fields in the tuple are not needed for distinguishing the source flows. The tuple is carried in the IP and transport headers of the source packets. Since FID is utilized by the CDP and FEC scheme to distinguish between the source packets, the tuple must have a one-to-one mapping to a valid FID. This point will be clearer in the specific example given later in this section. The length of FID must be a priori fixed and known to both the receiver and sender. Alternatively, it might be specified in the FEC-Scheme-Specific Information field in the SDP element [RFC6364].
流ID（FID）值为源流提供唯一的速记标识符。FID在SDP描述中指定并与{源IP地址、源端口、目标IP地址、目标端口、传输协议}的可能通配符元组关联。当使用通配符时，元组中的某些字段不需要用于区分源流。元组携带在源数据包的IP和传输头中。由于CDP和FEC方案使用FID来区分源数据包，因此元组必须具有到有效FID的一对一映射。这一点在本节后面给出的具体示例中会更清楚。FID的长度必须是先验固定的，并且接收方和发送方都知道。或者，它可以在SDP元素[RFC6364]中的FEC方案特定信息字段中指定。
The payload length (Len) information is needed to figure out how many bits, bytes, or symbols (depending on the FEC scheme) from a particular source flow are included in the source block. If the payload is not an integer multiple of the specified symbol length, the remaining portion is padded with zeros (see Figures 3 and 4).
需要有效负载长度（Len）信息来确定源块中包括来自特定源流的多少位、字节或符号（取决于FEC方案）。如果有效载荷不是指定符号长度的整数倍，则剩余部分用零填充（见图3和图4）。
+------+
+--------+ +--------+ +--------+ | | -------> r_1
.. |SB_(j+1)| | SB_j | |SB_(j-1)| .. ==> | FEC | Repair .
+--------+ +--------+ +--------+ |Scheme| Flows .
| | -------> r_k
+------+
+------+
+--------+ +--------+ +--------+ | | -------> r_1
.. |SB_(j+1)| | SB_j | |SB_(j-1)| .. ==> | FEC | Repair .
+--------+ +--------+ +--------+ |Scheme| Flows .
| | -------> r_k
+------+
Figure 3: Repair Flow Generation by a FEC Scheme
图3：通过FEC方案生成修复流
<------------------ Source Block (SB) ------------------->
| | | | | |
+-------...-----+-------...-----+- -+-------...-----+ |
| Payload_1 | Payload_2 | . . . | Payload_n |0|
+-------...-----+-------...-----+- -+-------...-----+ |
| | | | | |
| Symbol_1 | Symbol_2 | Symbol_3 | . . . | Symbol_m |
|<-------->|<-------->|<-------->| |<-------->|
<------------------ Source Block (SB) ------------------->
| | | | | |
+-------...-----+-------...-----+- -+-------...-----+ |
| Payload_1 | Payload_2 | . . . | Payload_n |0|
+-------...-----+-------...-----+- -+-------...-----+ |
| | | | | |
| Symbol_1 | Symbol_2 | Symbol_3 | . . . | Symbol_m |
|<-------->|<-------->|<-------->| |<-------->|
+------+
Symbol_1,..,Symbol_m => | FEC | => Symbol_u,..,Symbol_1
| Enc. |
+------+
+------+
Symbol_1,..,Symbol_m => | FEC | => Symbol_u,..,Symbol_1
| Enc. |
+------+
Figure 4: Repair Flow Payload Generation
图4：修复流有效载荷生成
FEC schemes typically expect a source block of certain size, say, m symbols. Therefore, the FEC encoder divides each source block into m symbols (with some padding if the source block is shorter than the expected m symbols) and generates u repair symbols, which are functions of the m symbols in the original source block. The repair symbols are grouped by the FEC scheme into repair payloads with each repair payload assigned a Repair FEC Payload ID in order to associate each repair payload with a particular source block at the receiver. If the payloads in a given source block have sequence numbers that can uniquely specify their location in the source block, an Explicit Source FEC Payload ID may not be generated for these payloads. Otherwise, Explicit Source FEC Payload IDs are generated for each payload and indicate the order the payloads appear in the source block.
FEC方案通常期望具有特定大小的源块，例如m个符号。因此，FEC编码器将每个源块划分为m个符号（如果源块比预期的m个符号短，则使用一些填充），并生成u个修复符号，其是原始源块中m个符号的函数。通过FEC方案将修复符号分组到修复有效载荷中，每个修复有效载荷分配有修复FEC有效载荷ID，以便将每个修复有效载荷与接收机处的特定源块相关联。如果给定源块中的有效载荷具有可唯一指定其在源块中位置的序列号，则可能不会为这些有效载荷生成显式源FEC有效载荷ID。否则，将为每个有效负载生成显式源FEC有效负载ID，并指示有效负载在源块中出现的顺序。
Note that FID and length information are not actually transmitted with the source payloads since both information can be gathered by other means as it will be clear in the next sections.
请注意，FID和长度信息实际上并不随源有效载荷一起传输，因为可以通过其他方式收集这两种信息，这将在下一节中明确。
In this section, we present an example of source flow and repair flow generation by the CDP. We have two source flows with flow IDs of 0 and 1 to be protected by a single repair flow (see Figure 5). The first source flow is multicast to 233.252.0.1, and the second source flow is multicast to 233.252.0.2. Both flows use the port number 30000.
在本节中，我们将展示一个由CDP生成源流和修复流的示例。我们有两个流ID为0和1的源流，由单个修复流保护（见图5）。第一个源流多播到233.252.0.1，第二个源流多播到233.252.0.2。两个流都使用端口号30000。
SOURCE FLOWS
S1: Source Flow | | INSTANCE #1
|---------| R3: Repair Flow
S2: Source Flow |
SOURCE FLOWS
S1: Source Flow | | INSTANCE #1
|---------| R3: Repair Flow
S2: Source Flow |
Figure 5: Example: Two Source Flows and One Repair Flow
图5：示例：两个源流和一个修复流
The SDP description below states that the source flow defined by the tuple {*,*,233.252.0.1,30000} is identified with FID=0 and the source flow defined by the tuple {*,*,233.252.0.2,30000} is identified with FID=1 (via the 'id' parameter of the "fec-source-flow" attribute). The SDP description also states that the repair flow is to be received at the multicast address of 233.252.0.3 and at port 30000.
下面的SDP描述说明，元组{*，*，233.252.0.130000}定义的源流用FID=0标识，元组{*，*，233.252.0.230000}定义的源流用FID=1标识（通过“fec源流”属性的“id”参数）。SDP说明还说明将在多播地址233.252.0.3和端口30000处接收修复流。
v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=FEC Framework Examples
t=0 0
a=group:FEC-FR S1 S2 R3
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=rtpmap:100 MP2T/90000
a=fec-source-flow: id=0
a=mid:S1
m=video 30000 RTP/AVP 101
c=IN IP4 233.252.0.2/127
a=rtpmap:101 MP2T/90000
a=fec-source-flow: id=1
a=mid:S2
m=application 30000 UDP/FEC
c=IN IP4 233.252.0.3/127
a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5
a=repair-window:150ms
a=mid:R3
v=0
o=ali 1122334455 1122334466 IN IP4 fec.example.com
s=FEC Framework Examples
t=0 0
a=group:FEC-FR S1 S2 R3
m=video 30000 RTP/AVP 100
c=IN IP4 233.252.0.1/127
a=rtpmap:100 MP2T/90000
a=fec-source-flow: id=0
a=mid:S1
m=video 30000 RTP/AVP 101
c=IN IP4 233.252.0.2/127
a=rtpmap:101 MP2T/90000
a=fec-source-flow: id=1
a=mid:S2
m=application 30000 UDP/FEC
c=IN IP4 233.252.0.3/127
a=fec-repair-flow: encoding-id=0; ss-fssi=n:7,k:5
a=repair-window:150ms
a=mid:R3
Figure 6 shows the first and the second source blocks (SB_1 and SB_2) generated from these two source flows. In this example, SB_1 is of length 10000 bytes. Suppose that the FEC scheme uses a symbol length
图6显示了从这两个源流生成的第一个和第二个源块（SB_1和SB_2）。在本例中，SB_1的长度为10000字节。假设FEC方案使用符号长度
of 512 bytes. Then, SB_1 can be divided into 20 symbols after padding the source block for 240 bytes. Assume that the FEC scheme is rate-2/3 erasure code; hence, it generates 10 repair symbols from 20 original symbols for SB_1. On the other hand, SB_2 is 7000 bytes long and can be divided into 14 symbols after padding 168 bytes. Using the same encoder, suppose that seven repair symbols are generated for SB_2.
512字节。然后，在将源块填充240字节后，SB_1可以被划分为20个符号。假设FEC方案是速率为2/3的擦除码；因此，它从20个原始符号中为SB_1生成10个修复符号。另一方面，SB_2的长度为7000字节，在填充168字节后可分为14个符号。使用相同的编码器，假设为SB_2生成了七个修复符号。
<-------- Source Block 1 -------->
+------------+-------------------+
| $1 $2 $3 $4| #1 #2 #3 #4 #5 #6 | 0..00
+------------+-------------------+
\__________________ __________________/
\/
@1 @2 @3 @4 @5 @6 @7 @8 @9 @10
<-------- Source Block 1 -------->
+------------+-------------------+
| $1 $2 $3 $4| #1 #2 #3 #4 #5 #6 | 0..00
+------------+-------------------+
\__________________ __________________/
\/
@1 @2 @3 @4 @5 @6 @7 @8 @9 @10
<---- Source Block 2 ---->
+----------------+-------+
| $5 $6 $7 $8 $9 | #7 #8 |0..00
+----------------+-------+
\______________ _____________/
\/
@11 @12 @13 @14 @15 @16 @17
<---- Source Block 2 ---->
+----------------+-------+
| $5 $6 $7 $8 $9 | #7 #8 |0..00
+----------------+-------+
\______________ _____________/
\/
@11 @12 @13 @14 @15 @16 @17
$: 1000-byte payload from source flow 1
#: 1000-byte payload from source flow 2
@: Repair symbol
$: 1000-byte payload from source flow 1
#: 1000-byte payload from source flow 2
@: Repair symbol
Figure 6: Source Block with Two Source Flows
图6：具有两个源流的源块
The information on the unit of payload length, FEC scheme, symbol size, and coding rates can be specified in the FEC-Scheme-Specific Information (FSSI) field of the SDP element. If the values of the payload lengths from each source flow and the order of appearance of source flows in every source block are fixed during the session, these values may be also provided in the FSSI field. To carry FSSI information to the FEC receivers, one may use the signaling methods described in [RFC6695]. In our example, we will consider the case where the ordering is fixed and known both at the sender and the receiver, but the payload lengths will be variable from one source block to another. We assume that the payload of a source flow with an FID smaller than another flow's FID precedes other payloads in a source block.
可以在SDP元素的FEC方案特定信息（FSSI）字段中指定关于有效载荷长度、FEC方案、符号大小和编码速率的单位的信息。如果来自每个源流的有效载荷长度的值和每个源块中的源流的出现顺序在会话期间是固定的，那么这些值也可以在FSSI字段中提供。为了将FSSI信息传送到FEC接收机，可以使用[RFC6695]中描述的信令方法。在我们的例子中，我们将考虑在发送者和接收者中的顺序是固定的和已知的情况，但是有效载荷长度将从一个源块变为另一个源块。我们假设FID小于另一个流FID的源流的有效负载先于源块中的其他有效负载。
The FEC scheme gets the source blocks as input and generates the parity blocks for each source block to protect the whole source block. In the example, the repair payloads for SB_1 consist of 512-
FEC方案将源块作为输入，并为每个源块生成奇偶校验块以保护整个源块。在本例中，SB_1的修复有效载荷由512个组成-
byte symbols, denoted by @1 to @10. Similarly, @11 to @17 constitutes the repair payloads for SB_2. The FEC scheme outputs the repair payloads along with the Repair FEC Payload IDs. In our example, Repair FEC Payload ID provides information on the source block sequence number and the order the repair symbols are generated. For instance, @3 is the third FEC repair symbol for SB_1, and the three tuple {@3,SB_1,3} can uniquely deliver this information. In our example, the FEC scheme also provides Explicit Source FEC Payload IDs that carry information to indicate which source symbols correspond to which source block sequence number and the relative position in the source block. For instance, the two tuple {SB_2,2} can be attached to $6 as the Explicit Source FEC Payload ID to indicate that $6 is protected together with packets belonging to SB_2, and $6 is the second payload in SB_2.
字节符号，由@1到@10表示。同样，@11至@17构成SB_2的修复有效载荷。FEC方案输出修复有效载荷以及修复FEC有效载荷ID。在我们的示例中，Repair FEC Payload ID提供关于源块序列号和生成修复符号的顺序的信息。例如，@3是SB_1的第三个FEC修复符号，三元组{@3，SB_1,3}可以唯一地传递此信息。在我们的示例中，FEC方案还提供显式源FEC有效负载id，其携带信息以指示哪些源符号对应于哪个源块序列号以及源块中的相对位置。例如，两元组{SB_2,2}可以附加到$6作为显式源FEC有效负载ID，以指示$6与属于SB_2的包一起受到保护，并且$6是SB_2中的第二个有效负载。
The source packets are generated from the source symbols by concatenating consecutive symbols in one packet. There should not be any fragmentation of a source symbol; e.g., symbols #7 and #8 can be concatenated in one transport payload of 2000 bytes (the implementation should make sure that the size of the resulting source packet -- payload plus the overhead -- is not larger than the path MTU), but one portion of symbol #7 should not be put in one source packet and the remaining portion in another source packet. The simplest implementation is to place each source symbol in a different source packet as shown in Figure 7.
源分组通过在一个分组中串联连续符号从源符号生成。源符号不应有任何碎片；e、 例如，符号#7和#8可以连接在一个2000字节的传输有效负载中（实现应确保生成的源数据包的大小——有效负载加上开销——不大于路径MTU），但符号#7的一部分不应放在一个源数据包中，其余部分不应放在另一个源数据包中。最简单的实现是将每个源符号放在不同的源数据包中，如图7所示。
+------------------------------------+
| IP header {233.252.0.1} |
+------------------------------------+
| Transport header {30000} |
+------------------------------------+
| Original Transport Payload {$6} |
+------------------------------------+
| Source FEC Payload ID {SB_2,2} |
+------------------------------------+
+------------------------------------+
| IP header {233.252.0.1} |
+------------------------------------+
| Transport header {30000} |
+------------------------------------+
| Original Transport Payload {$6} |
+------------------------------------+
| Source FEC Payload ID {SB_2,2} |
+------------------------------------+
Figure 7: Example of a Source Packet for IPv4
图7:IPv4的源数据包示例
The repair packets are generated from the repair symbols belonging to the same source block by grouping consecutive symbols in one packet. There should not be any fragmentation of a repair symbol; e.g., symbols @4, @5, and @6 can be concatenated in one transport payload of 1536 bytes, but @6 should not be divided into smaller sub-symbols and spread over multiple repair packets. The Repair FEC Payload ID must carry sufficient information for the decoding process. In our example, for instance, indicating source block sequence number, length of each source payload, and the order that the first parity symbol in the repair packet among all the parity symbols generated
通过在一个分组中分组连续符号，从属于同一源块的修复符号生成修复分组。维修符号不应有任何碎片；e、 例如，符号@4、@5和@6可以连接在一个1536字节的传输有效负载中，但是@6不应该被划分成更小的子符号，并分布在多个修复包中。修复FEC有效负载ID必须携带足够的解码过程信息。例如，在我们的示例中，指示源块序列号、每个源有效负载的长度以及修复分组中第一个奇偶校验符号在所有奇偶校验符号中生成的顺序
for the same source block is sufficient. The exact header format of Repair FEC Payload ID may be specified in the FSSI field of the SDP element. In Figure 8, for instance, the repair symbols @4, @5, and @6 are concatenated together. The Payload ID {SB_1,4,4,6} states that the repair symbols protect SB_1, the first repair symbol in the payload is generated as the fourth symbol and the source block consists of two source flows carrying four and six packets from each.
对于相同的源块就足够了。修复FEC有效载荷ID的确切报头格式可以在SDP元素的FSSI字段中指定。例如，在图8中，修复符号@4、@5和@6连接在一起。有效载荷ID{SB_1,4,4,6}表示修复符号保护SB_1，有效载荷中的第一个修复符号被生成为第四个符号，并且源块由两个源流组成，每个源流携带四个和六个分组。
+------------------------------------+
| IP header {233.252.0.3} |
+------------------------------------+
| Transport header {30000} |
+------------------------------------+
| Repair FEC Payload ID {SB_1,4,4,6} |
+------------------------------------+
| Repair Symbols {@4,@5,@6} |
+------------------------------------+
+------------------------------------+
| IP header {233.252.0.3} |
+------------------------------------+
| Transport header {30000} |
+------------------------------------+
| Repair FEC Payload ID {SB_1,4,4,6} |
+------------------------------------+
| Repair Symbols {@4,@5,@6} |
+------------------------------------+
Figure 8: Example of a Repair Packet for IPv4
图8:IPv4的修复包示例
Here we provide an example for reconstructing multiple source flows from a single repair flow.
这里我们提供了一个从单个修复流重建多个源流的示例。
At the receiver, source flows 1 and 2 are received at {233.252.0.1,30000} and {233.252.0.2,30000}, while the repair flow is received at {233.252.0.3,30000}. The CDP can map these tuples to the flow IDs using the SDP elements. Accordingly, the payloads received at {233.252.0.1,30000} and {233.252.0.2,30000} are mapped to flow IDs 0 and 1, respectively.
在接收器处，源流1和2在{233.252.0.130000}和{233.252.0.230000}接收，而修复流在{233.252.0.330000}接收。CDP可以使用SDP元素将这些元组映射到流ID。因此，在{233.252.0.130000}和{233.252.0.230000}接收的有效载荷分别映射到流id 0和1。
The CDP passes the flow IDs and received payloads along with the Explicit Source FEC Payload ID to the FEC scheme defined in the SDP description. The CDP also passes the received repair packet payloads and Repair FEC Payload ID to the FEC scheme. The FEC scheme can construct the original source block with missing packets by using the information given in the FEC Payload IDs. The FEC Repair Payload ID provides the information that SB_1 has packets from two flows with four packets from the first one and six packets from the second one. Flow IDs state that the packets from source flow 0 precede the packets from source flow 1. Explicit Source FEC Payload IDs, on the other hand, provide the information about which source payload appears in what order. Therefore, the FEC scheme can depict a source block with exact locations of the missing packets. Figure 9 depicts the case for SB_1. Since the original source block with missing
CDP将流ID和接收的有效负载以及显式源FEC有效负载ID传递给SDP描述中定义的FEC方案。CDP还将接收到的修复分组有效载荷和修复FEC有效载荷ID传递给FEC方案。FEC方案可以利用FEC有效负载id中给出的信息来构造具有丢失分组的原始源块。FEC修复有效负载ID提供sbu 1具有来自两个流的分组的信息，其中来自第一个流的四个分组和来自第二个流的六个分组。流ID表示源流0的数据包在源流1的数据包之前。另一方面，显式源FEC有效负载ID提供关于哪个源有效负载以什么顺序出现的信息。因此，FEC方案可以用丢失分组的精确位置来描述源块。图9描述了SB_1的情况。由于原始源代码块丢失
packets can be constructed at the decoder and the FEC scheme knows the coding rate (e.g., it might be carried in the FSSI field in the SDP description), a proper decoding operation can start as soon as the repair symbols are provided to the FEC scheme.
可以在解码器处构造分组，并且FEC方案知道编码速率（例如，它可能被携带在SDP描述中的FSSI字段中），只要修复符号被提供给FEC方案，就可以开始适当的解码操作。
<-------- Source Block 1 -------->
+------------+-------------------+
| $1 $2 X X | #1 X #3 #4 #5 #6 |
+------------+-------------------+
<-------- Source Block 1 -------->
+------------+-------------------+
| $1 $2 X X | #1 X #3 #4 #5 #6 |
+------------+-------------------+
O: Symbols received from the source flow 1 for SB_1 #: Symbols received from the source flow 2 for SB_1 X: Lost source symbols
O:SB_1从源流1接收的符号：SB_1从源流2接收的符号X：丢失的源符号
Figure 9: Source Block Regeneration
图9：源块再生
When the FEC scheme can recover any missing symbol while more repair symbols are arriving, it provides the recovered blocks along with the source flow IDs of the recovered blocks as outputs to the CDP. The receiver knows how long to wait to repair the remaining missing packets (e.g., specified by the 'repair-window' attribute in the SDP description). After the associated timer expires, the CDP hands over whatever could be recovered from the source flow to the application layer and continues with processing the next source block.
当FEC方案能够在更多修复符号到达时恢复任何丢失的符号时，它将恢复的块以及恢复的块的源流id作为输出提供给CDP。接收器知道修复剩余丢失的数据包需要等待多长时间（例如，由SDP描述中的“修复窗口”属性指定）。关联的计时器过期后，CDP将可以从源流恢复的内容移交给应用层，并继续处理下一个源块。
For the general security considerations related to the FEC Framework, refer to [RFC6363]. For the security considerations related to the SDP elements in the FEC Framework, refer to [RFC6364]. There are no additional security considerations that apply to this document.
有关FEC框架的一般安全注意事项，请参阅[RFC6363]。有关FEC框架中SDP元素的安全注意事项，请参阅[RFC6364]。没有适用于本文档的其他安全注意事项。
The authors would like to thank the FEC Framework design team for their inputs, suggestions, and contributions.
作者要感谢FEC框架设计团队的投入、建议和贡献。
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, October 2011.
[RFC6363]Watson，M.，Begen，A.，和V.Roca，“前向纠错（FEC）框架”，RFC6363，2011年10月。
[RFC6364] Begen, A., "Session Description Protocol Elements for the Forward Error Correction (FEC) Framework", RFC 6364, October 2011.
[RFC6364]Begen，A.，“前向纠错（FEC）框架的会话描述协议元素”，RFC6364，2011年10月。
[RFC6695] Asati, R., "Methods to Convey Forward Error Correction (FEC) Framework Configuration Information", RFC 6695, August 2012.
[RFC6695]Asati，R.“传递前向纠错（FEC）框架配置信息的方法”，RFC 6695，2012年8月。
Authors' Addresses
作者地址
Ulas C. Kozat DOCOMO Innovations 3240 Hillview Avenue Palo Alto, CA 94304-1201 USA
美国加利福尼亚州帕洛阿尔托Hillview大道3240号Ulas C.Kozat DOCOMO创新公司，邮编94304-1201
Phone: +1 650 496 4739
EMail: kozat@docomolabs-usa.com
Phone: +1 650 496 4739
EMail: kozat@docomolabs-usa.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