[要約] 要約： RFC 6801は、複数のソースフローを保護するための擬似コンテンツ配信プロトコル（CDP）を提案しています。このプロトコルは、転送エラー訂正（FEC）フレームワーク内で使用されます。目的： このRFCの目的は、複数のソースフローを効果的に保護するための新しいプロトコルを提案し、FECフレームワークの機能を向上させることです。
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
Forward Error Correction（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）を提供し、Forward Error Correction（FEC）フレームワークとフレームワークに定義されたセッション記述プロトコル（SDP）要素に基づいて、1つ以上の修復フローで複数のソースフローを保護します。このドキュメントの目的は、本格的なプロトコルを提供することではなく、定義されたフレームワークとSDP要素を組み合わせてCDPを実装する方法を示すことです。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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.
Forward Error Correction（FEC）フレームワーク（[RFC6363]で説明）とFECフレームワークのSDP要素（[RFC6364]で説明）は、FEC保護を備えた実際のコンテンツ配信プロトコル（CDP）を構築するのに十分なメカニズムを一緒に定義します。一方、FECフレームワーク構成情報（[RFC6695]で説明）を伝達する方法は、CDPの一部として使用できるシグナリングプロトコルを提供し、FECスキーマ固有の情報をFEC送信者から単一および複数に通信します。 FECレシーバー。このドキュメントでは、[RFC6363]と[RFC6364]で定義されたメカニズムを使用して、重要なシナリオ、つまり1つ以上の修復フローによる複数のソースフローの保護で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 ソースブロックは、1つ以上のソースフローから生成できます。
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は複数のフローからのトランスポートペイロードを多重化することにより、ソースブロック（SB）を構築します（図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 | +--------+ +--------+ +--------+
+------------+
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) ------------------->
+-------...-----+-------...-----+- -+-------...-----+
| 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およびトランスポートヘッダーで運ばれます。 FIDはソースパケットを区別するためにCDPおよびFECスキームで使用されるため、タプルには有効なFIDへの1対1のマッピングが必要です。この点については、このセクションで後述する特定の例で明らかになります。 FIDの長さは、事前に固定され、受信者と送信者の両方に認識されている必要があります。または、SDP要素の[FEC-Scheme-Specific Information]フィールドで指定することもできます[RFC6364]。
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
+------+
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 |
|<-------->|<-------->|<-------->| |<-------->|
+------+
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シンボルよりも短い場合はパディングを行います）、元のソースブロックのmシンボルの関数であるu修復シンボルを生成します。修復シンボルは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の2つのソースフローがあり、1つの修復フローで保護されています（図5を参照）。最初のソースフローは233.252.0.1へのマルチキャストであり、2番目のソースフローは233.252.0.2へのマルチキャストです。どちらのフローもポート番号30000を使用します。
SOURCE FLOWS
S1: Source Flow | | INSTANCE #1
|---------| R3: Repair Flow
S2: Source Flow |
Figure 5: Example: Two Source Flows and One Repair Flow
図5：例：2つのソースフローと1つの修復フロー
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.1,30000}によって定義されたソースフローはFID = 0で識別され、タプル{*、*、233.252.0.2,30000}によって定義されたソースフローはFID = 1で識別されます（「fec-source-flow」属性の「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
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 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.
図6は、これら2つのソースフローから生成された1番目と2番目のソースブロック（SB_1とSB_2）を示しています。この例では、SB_1の長さは10000バイトです。 FECスキームが512バイトのシンボル長を使用するとします。次に、ソースブロックを240バイト埋め込んだ後、SB_1を20シンボルに分割できます。 FECスキームがレート2/3の消去コードであると仮定します。したがって、SB_1の元の20個のシンボルから10個の修復シンボルを生成します。一方、SB_2は7000バイトの長さで、168バイトのパディング後に14のシンボルに分割できます。同じエンコーダーを使用して、SB_2に対して7つの修復シンボルが生成されたとします。
<-------- 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
$: 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：2つのソースフローを持つソースブロック
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.
ペイロードの長さの単位、FECスキーム、シンボルサイズ、およびコーディングレートに関する情報は、SDPエレメントのFEC-Scheme-Specific Information（FSSI）フィールドで指定できます。各ソースフローからのペイロード長の値と、すべてのソースブロック内のソースフローの出現順序がセッション中に固定されている場合、これらの値は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- 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.
FECスキームは、ソースブロックを入力として取得し、各ソースブロックのパリティブロックを生成して、ソースブロック全体を保護します。この例では、SB_1の修復ペイロードは、@ 1から@ 10で表される512バイトのシンボルで構成されています。同様に、@ 11から@ 17はSB_2の修復ペイロードを構成します。 FECスキームは、修復FECペイロードIDとともに修復ペイロードを出力します。この例では、Repair FEC Payload IDは、ソースブロックのシーケンス番号と、修復シンボルが生成される順序に関する情報を提供します。たとえば、@ 3はSB_1の3番目のFEC修復シンボルであり、3つのタプル{@ 3、SB_1,3}はこの情報を一意に配信できます。この例では、FECスキームは、どのソースシンボルがどのソースブロックシーケンス番号とソースブロック内の相対位置に対応するかを示す情報を運ぶ明示的なソースFECペイロードIDも提供します。たとえば、2つのタプル{SB_2,2}を明示的なソースFECペイロードIDとして$ 6にアタッチして、$ 6がSB_2に属するパケットと一緒に保護され、$ 6がSB_2の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.
ソースパケットは、連続するシンボルを1つのパケットに連結することにより、ソースシンボルから生成されます。ソースシンボルの断片化があってはなりません。たとえば、シンボル＃7と＃8は2000バイトの1つのトランスポートペイロードに連結できます（実装では、結果のソースパケットのサイズ（ペイロードとオーバーヘッドを加えたもの）がパスMTUより大きくないことを確認する必要があります）。シンボル＃7の一部を1つのソースパケットに入れ、残りの部分を別のソースパケットに入れることはできません。最も単純な実装は、図7に示すように、各ソースシンボルを異なるソースパケットに配置することです。
+------------------------------------+
| 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 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.
修復パケットは、連続するシンボルを1つのパケットにグループ化することにより、同じソースブロックに属する修復シンボルから生成されます。修復シンボルの断片化があってはなりません。たとえば、シンボル@ 4、@ 5、および@ 6は、1536バイトの1つのトランスポートペイロードに連結できますが、@ 6を小さなサブシンボルに分割して、複数の修復パケットに分散することはできません。修理FECペイロードIDには、デコードプロセスに十分な情報が含まれている必要があります。たとえば、この例では、ソースブロックのシーケンス番号、各ソースペイロードの長さ、および同じソースブロックに対して生成されたすべてのパリティシンボルのうちの修復パケットの最初のパリティシンボルで十分な順序を示しています。 Repair FEC Payload IDの正確なヘッダー形式は、SDP要素のFSSIフィールドで指定できます。たとえば、図8では、修復記号@ 4、@ 5、および@ 6が連結されています。ペイロードID {SB_1,4,4,6}は、修復シンボルがSB_1を保護し、ペイロードの最初の修復シンボルが4番目のシンボルとして生成され、ソースブロックが、それぞれから4つと6つのパケットを運ぶ2つのソースフローで構成されることを示します。
+------------------------------------+
| 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.1,30000}および{233.252.0.2,30000}で受信され、修復フローが{233.252.0.3,30000}で受信されます。 CDPは、SDP要素を使用してこれらのタプルをフローIDにマップできます。したがって、{233.252.0.1,30000}および{233.252.0.2,30000}で受信されたペイロードは、それぞれフロー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 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.
CDPは、フローIDと受信したペイロードを、明示的なソースFECペイロードIDとともに、SDPの説明で定義されているFECスキームに渡します。 CDPは、受信した修復パケットペイロードと修復FECペイロードIDもFECスキームに渡します。 FECスキームは、FECペイロードIDで提供される情報を使用して、パケットが欠落している元のソースブロックを構築できます。 FEC修復ペイロードIDは、SB_1に2つのフローからのパケットがあり、最初のフローからの4つのパケットと2番目のフローからの6つのパケットがあるという情報を提供します。フローIDは、ソースフロー0からのパケットがソースフロー1からのパケットに先行することを示します。一方、明示的なソースFECペイロードIDは、どのソースペイロードがどの順序で出現するかについての情報を提供します。したがって、FECスキームは、欠落したパケットの正確な位置を含むソースブロックを表すことができます。図9は、SB_1の場合を示しています。パケットが欠落している元のソースブロックはデコーダーで構築でき、FECスキームはコーディングレートを知っているため（たとえば、SDPの説明のFSSIフィールドで運ばれる可能性があります）、修復するとすぐに適切なデコード処理を開始できますシンボルはFECスキームに提供されます。
<-------- 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スキームは、より多くの修復シンボルが到着している間に欠落したシンボルを回復できる場合、CDPへの出力として、回復されたブロックのソースフローIDとともに回復されたブロックを提供します。受信者は、残りの欠落パケットを修復するために待機する時間を知っています（たとえば、SDP記述の「repair-window」属性で指定されます）。関連するタイマーの期限が切れた後、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、「Forward Error Correction（FEC）Framework」、RFC 6363、2011年10月。
[RFC6364] Begen, A., "Session Description Protocol Elements for the Forward Error Correction (FEC) Framework", RFC 6364, October 2011.
[RFC6364] Begen、A。、「Forward Error Correction（FEC）フレームワークのセッション記述プロトコル要素」、RFC 6364、2011年10月。
[RFC6695] Asati, R., "Methods to Convey Forward Error Correction (FEC) Framework Configuration Information", RFC 6695, August 2012.
[RFC6695] Asati、R。、「Methods to Convey Forward Error Correction（FEC）Framework Configuration Information」、RFC 6695、2012年8月。
Authors' Addresses
著者のアドレス
Ulas C. Kozat DOCOMO Innovations 3240 Hillview Avenue Palo Alto, CA 94304-1201 USA
レビューC. Kozat DOCOMO Innovations 3240 Hillview Avenue Palo Alto、CA 94304-1201 USA
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 Bay Streetトロント、ON M5J 2T3カナダ
EMail: abegen@cisco.com