Network Working Group M. Watson
Request for Comments: 5445 Digital Fountain
Obsoletes: 3452, 3695 March 2009
Category: Standards Track
Basic Forward Error Correction (FEC) Schemes
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
This document provides Forward Error Correction (FEC) Scheme specifications according to the Reliable Multicast Transport (RMT) FEC building block for the Compact No-Code FEC Scheme, the Small Block, Large Block, and Expandable FEC Scheme, the Small Block Systematic FEC Scheme, and the Compact FEC Scheme. This document obsoletes RFC 3695 and assumes responsibility for the FEC Schemes defined in RFC 3452.
この文書では、コンパクトな無コードFECスキーム、小ブロック、大ブロック、および拡張可能なFECスキーム、スモールブロック体系的FECスキームのための信頼できるマルチキャストトランスポート（RMT）FECビルディングブロックに応じて前方誤り訂正（FEC）スキームの仕様を提供します、そしてコンパクトなFECスキーム。この文書はRFC 3695を廃止し、RFC 3452で定義されたFECスキームについて責任を負うものとします。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Compact No-Code FEC Scheme . . . . . . . . . . . . . . . . . . 4
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 4
3.2.1. FEC Payload ID(s) . . . . . . . . . . . . . . . . . . 4
3.2.2. FEC Object Transmission Information . . . . . . . . . 5
3.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 7
3.4.1. Source Block Logistics . . . . . . . . . . . . . . . . 7
3.4.2. Sending and Receiving a Source Block . . . . . . . . . 8
4. Small Block, Large Block, and Expandable FEC Scheme . . . . . 9
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 9
4.2.1. FEC Payload ID(s) . . . . . . . . . . . . . . . . . . 9
4.2.2. FEC Object Transmission Information . . . . . . . . . 10
4.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 12
5. Small Block Systematic FEC Scheme . . . . . . . . . . . . . . 12
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 12
5.2.1. FEC Payload ID(s) . . . . . . . . . . . . . . . . . . 12
5.2.2. FEC Object Transmission Information . . . . . . . . . 13
5.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 14
5.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 15
6. Compact FEC Scheme . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Formats and Codes . . . . . . . . . . . . . . . . . . . . 15
6.2.1. FEC Payload ID(s) . . . . . . . . . . . . . . . . . . 15
6.2.2. FEC Object Transmission Information . . . . . . . . . 15
6.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 15
6.4. FEC Code Specification . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Changes from Schemes Defined in RFC 3452 and RFC 3695 . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . . 18
The document specifies the following FEC Schemes according to the specification requirements of the FEC building block [RFC5052]:
文書は、FECビルディングブロック[RFC5052]の仕様の要件に応じて、次のFECスキームを指定します。
o Compact No-Code FEC Scheme
コンパクト無コードFECスキームO
o Small Block, Large Block, and Expandable FEC Scheme
O小ブロック、大ブロック、および拡張FECスキーム
o Small Block Systematic FEC Scheme
スモールブロック体系的FECスキームO
o Compact FEC Scheme
コンパクトなFECスキームO
This document inherits the context, language, declarations and restrictions of the FEC building block [RFC5052]. This document also uses the terminology of the companion document [RFC3453], which describes the use of FEC codes within the context of reliable IP multicast transport and provides an introduction to some commonly used FEC codes.
この文書では、コンテキスト、言語、宣言とFECビルディングブロック[RFC5052]の制限を継承します。この文書はまた、信頼性の高いIPマルチキャストトランスポートのコンテキスト内でFEC符号の使用について説明し、いくつかの一般的に使用されるFEC符号への導入を提供する仲間ドキュメント[RFC3453]の用語を使用します。
Building blocks are defined in [RFC3048]. This document follows the general guidelines provided in [RFC3269].
ビルディングブロックは、[RFC3048]で定義されています。この文書では、[RFC3269]に提供される一般的なガイドラインに従います。
[RFC3452] and [RFC3695] contain previous versions of the FEC Schemes defined in this specification. These RFCs were published in the "Experimental" category. It was the stated intent of the RMT working group to re-submit these specifications as an IETF Proposed Standard in due course. This document obsoletes [RFC3695]. [RFC3452] has already been obsoleted by [RFC5052], and this document assumes responsibility for aspects of [RFC3452] that were not included in [RFC5052].
[RFC3452]及び[RFC3695]は、本明細書で定義されたFECスキームの以前のバージョンを含みます。これらのRFCは、「実験」カテゴリに掲載されました。やがて標準提案IETFとしてこれらの仕様を再提出するRMTワーキンググループの規定の趣旨でした。この文書では、[RFC3695]を廃止します。 [RFC3452]は、すでに[RFC5052]によって廃止されており、このドキュメントは[RFC5052]に含まれていなかった[RFC3452]の側面について責任を負うものとします。
This Proposed Standard specification is thus based on and backwards compatible with the FEC Schemes defined in [RFC3452] and [RFC3695], updated according to accumulated experience and growing protocol maturity since their original publication. Said experience applies both to this specification itself and to congestion control strategies related to the use of this specification.
この提案された標準仕様は、このように基づいて、元の出版以来蓄積された経験と成長プロトコル成熟度に応じて更新[RFC3452]及び[RFC3695]で定義されたFECスキームとの下位互換性があります。経験は、この仕様自体には、本明細書の使用に関連する輻輳制御戦略の両方に適用されると述べました。
The differences between the FEC Scheme specifications in [RFC3452] and [RFC3695] and this document are listed in Section 10.
[RFC3452]と[RFC3695]とこのドキュメントのFECスキームの仕様との違いは、セクション10に記載されています。
Integer fields specified in this document are all encoded in network byte order.
この文書で指定された整数フィールドは、すべてのネットワークバイト順に符号化されています。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The Compact No-code FEC Scheme is a Fully-Specified FEC Scheme. The scheme requires no FEC coding and is specified primarily to allow simple interoperability testing between different implementations of protocol instantiations that use the FEC building block.
コンパクト無コードFECスキームは、完全に指定されたFECスキームです。スキームにはFEC符号化を必要とせず、FECビルディングブロックを使用するプロトコルのインスタンスの異なる実装の間の単純な相互運用性テストを可能にするために、主に指定されています。
The FEC Payload ID for the Compact No-Code FEC Scheme is composed of a Source Block Number and an Encoding Symbol ID as shown in Figure 1.
図1に示すようにコンパクト無コードFECスキームのためのFECペイロードIDは、ソースブロック番号および符号化シンボルIDで構成されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Number | Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: FEC Payload ID Format for Compact No-Code FEC Scheme
図1：コンパクト無コードFECスキームのためのFECペイロードIDフォーマット
The Source Block Number (SBN) is a 16-bit unsigned integer that is used to identify from which source block of the object the encoding symbol in the payload of the packet is generated. There are two possible modes: in the unique SBN mode, each source block within the object has a unique Source Block Number associated with it, and in the non-unique SBN mode, the same Source Block Number may be used for more than one source block within the object. Which mode is being used for an object is outside the scope of this document and MUST be communicated, either explicitly or implicitly, out-of-band to receivers.
ソースブロック番号（SBN）は、パケットのペイロードに符号化シンボルが生成されたオブジェクトのどのソースブロックから識別するために使用される16ビットの符号なし整数です。二つの可能なモードが存在する：固有SBNモードでは、オブジェクト内の各ソースブロックは、それに関連付けられた一意のソースブロック番号を有し、非固有SBNモードでは、同じソースブロック番号は、複数のソースのために使用することができますオブジェクト内のブロック。オブジェクトは、アウトオブバンド受信機に明示的または暗黙的に、この文書の範囲外であると伝達されなければならないためにどのモードが使用されています。
If the unique SBN mode is used, then successive Source Block Numbers are associated with consecutive source blocks of the object starting with Source Block Number 0 for the first source block of the object. In this case, there are at most 2^^16 source blocks in the object.
ユニークなSBNモードが使用される場合、連続するソースブロック番号は、オブジェクトの最初のソースブロックのソースブロック番号0から始まるオブジェクトの連続するソースブロックに関連付けられています。この場合、オブジェクト内のせいぜい2 ^^ 16個のソースブロックが存在します。
If the non-unique SBN mode is used, then the mapping from source blocks to Source Block Numbers MUST be communicated out-of-band to receivers, and how this is done is outside the scope of this document. This mapping could be implicit, for example, determined by the transmission order of the source blocks. In non-unique SBN mode, packets for two different source blocks mapped to the same Source Block Number SHOULD NOT be sent within an interval of time that is shorter than the transport time of a source block. The transport time of a source block includes the amount of time needed to process the source block at the sender transport layer, the network transit time for packets, and the amount of time needed to process the source block at the receiver transport. This allows the receiver to clearly decide which packets belong to which source block.
非ユニークなSBNモードを使用する場合は、ソースブロック番号にソースブロックからのマッピングは、アウトオブバンド受信機に伝達されなければならない、とどのようにこれが行われるが、この文書の範囲外です。このマッピングは、例えば、ソースブロックの送信順序によって決定される、暗黙的であってもよいです。非ユニークなSBNモードでは、同じソースブロック番号にマッピングされた二つの異なるソースブロックのパケットがソースブロックの輸送時間よりも短い時間の間隔内に送るべきではありません。ソースブロックの輸送時間は、送信側のトランスポート層パケットのためのネットワーク通過時間、および受信トランスポートのソースブロックを処理するのに必要な時間の量のソースブロックを処理するのに必要な時間の量を含みます。これは明らかに、どのソースブロックに属するパケットを決定する受信機を可能にします。
The Encoding Symbol ID is a 16-bit unsigned integer that identifies which specific encoding symbol generated from the source block is carried in the packet payload. The exact details of the correspondence between Encoding Symbol IDs and the encoding symbols in the packet payload are specified in Section 3.4.
符号化シンボルIDは、ソースブロックから生成された特定の符号化シンボルがパケットペイロードで運ばれているかを識別する16ビットの符号なし整数です。符号化シンボルIDおよびパケットペイロードにおける符号化シンボルの対応関係の正確な詳細はセクション3.4で指定されています。
The mandatory FEC Object Transmission Information element for the Compact No-Code FEC Scheme is:
コンパクト無コードFECスキームのための必須FECオブジェクト伝送情報要素は次のとおりです。
o FEC Encoding ID: zero (0)
FEC符号化ID O：ゼロ（0）
The Common FEC Object Transmission Information elements and their value ranges for the Compact No-Code FEC Scheme are:
コンパクト無コードFECスキームのための共通FECオブジェクト伝送情報要素とその値の範囲は以下のとおりです。
Transfer-Length: a non-negative integer, less than 2^^48, indicating the length of the object in octets.
転送長：負でない整数、2未満^^ 48、オクテット内のオブジェクトの長さを示します。
Encoding-Symbol-Length: a non-negative integer, less than 2^^16, indicating the length of each encoding symbol in octets.
符号化シンボル長：負でない整数、2 ^^ 16未満、オクテット内の各符号化シンボルの長さを示します。
Maximum-Source-Block-Length: a non-negative integer, less than 2^^32, indicating the maximum number of source symbols in a source block.
最大ソースブロック長：負でない整数、2 ^^ 32未満の、ソースブロック内のソースシンボルの最大数を示します。
The encoded Common FEC Object Transmission Information is defined in Figure 2.
符号化された共通FECオブジェクト伝送情報を図2に定義されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transfer Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol Length | Max. Source Block Length (MSB)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max. Source Block Length (LSB)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Encoded Common FEC Object Transmission Information (OTI) for Compact No-Code FEC Scheme
図2：小型無コードFECスキームのためのコーディングされた共通FECオブジェクト伝送情報（OTI）
The Transfer Length, Encoding Symbol Length, and Maximum Source Block Length are encoded as unsigned integers, of length 48 bits, 16 bits, and 32 bits, respectively.
転送長、符号化シンボル長、及び最大ソースブロック長は、それぞれ、長さ48ビット、16ビット、および32ビットの符号なし整数として符号化されます。
All Encoding Symbols of a transport object MUST have length equal to the length specified in the Encoding Symbol Length element, with the optional exception of the last source symbol of the last source block (so that redundant padding is not mandatory in this last symbol). This last source symbol MUST be logically padded out with zeroes when another Encoding Symbol is computed based on this source symbol to ensure the same interpretation of this Encoding Symbol value by the sender and receiver. However, this padding does not actually need to be sent with the data of the last source symbol.
トランスポート・オブジェクトのすべての符号化シンボルが最後のソースブロックの最後のソースシンボルのオプションを除いて符号化シンボル長要素で指定された長さに等しい長さを有していなければならない（その結果、冗長なパディングは、この最後のシンボルに必須ではありません）。別の符号化シンボルは、送信側と受信側で、この符号化シンボル値の同じ解釈を確保するために、このソースシンボルに基づいて計算されている場合、この最後のソースシンボルは、論理的にゼロでパディングされなければなりません。しかし、このパディングが実際に最後のソースシンボルのデータを送信する必要はありません。
The "Reserved" field in the Encoded FEC Object Transmission Information MUST be set to zero by senders and its value MUST be ignored by receivers.
エンコードされたFECオブジェクト伝送情報で「予約」フィールドは、送信者によってゼロに設定しなければならなくて、その値は、受信機で無視しなければなりません。
Note: this FEC Scheme was first defined in [RFC3695], which did not require that the Encoding Symbol Length should be the same for every source block. This document introduces a general requirement that the Encoding Symbol Length be the same across source blocks. Since no protocols were defined that support variation in the Encoding Symbol Length between source blocks, this can be done without introducing backwards compatibility issues.
注意：このFECスキームは、最初に[RFC3695]で定義された、符号化シンボルの長さは、すべてのソースブロックの同じであるべきことを要求しませんでした。この文書では、符号化シンボルの長さは、ソースブロックで同じである一般的な要件を導入しています。いかなるプロトコルがソースブロック間符号化シンボル長の支持変化と定義されなかったので、これは下位互換性の問題を導入することなく行うことができます。
No Scheme-Specific FEC Object Transmission Information elements are defined by this FEC Scheme.
いいえスキーム固有のFECオブジェクト伝送情報要素は、このFECスキームによって定義されていません。
The algorithm defined in Section 9.1. of [RFC5052] MUST be used to partition the file into source blocks.
セクション9.1で定義されたアルゴリズム。 [RFC5052]のソースブロックにファイルを分割するために使用されなければなりません。
The Compact No-Code FEC Scheme does not require FEC encoding or decoding. Instead, each encoding symbol consists of consecutive bytes of a source block of the object.
コンパクト無コードFECスキームは、FEC符号化または復号化を必要としません。代わりに、各符号化シンボルは、オブジェクトのソースブロックの連続したバイトで構成されています。
The following two subsections describe the details of how the Compact No-Code FEC Scheme operates for each source block of an object.
次の2つのサブセクションは、コンパクト無コードFECスキームは、オブジェクトの各ソースブロックの動作方法の詳細を記載しています。
Let X > 0 be the length of a source block in bytes. Let L > 0 be the length of the encoding symbol contained in the payload of each packet. The value of X and L are part of the FEC Object Transmission Information, and how this information is communicated to a receiver is outside the scope of this document.
X> 0バイト内のソースブロックの長さとします。 L> 0は、各パケットのペイロードに含まれる符号化シンボルの長さとします。 X及びLの値は、FECオブジェクト伝送情報の一部であり、どのようにこの情報は、受信機に伝達され、この文書の範囲外です。
For a given source block X bytes in length with Source Block Number I, let N = X/L rounded up to the nearest integer. The encoding symbol carried in the payload of a packet consists of a consecutive portion of the source block. The source block is logically partitioned into N encoding symbols, each L bytes in length, and the corresponding Encoding Symbol IDs range from 0 through N-1 starting at the beginning of the source block and proceeding to the end. Thus, the encoding symbol with Encoding Symbol ID Y consists of bytes L*Y through L*(Y+1)-1 of the source block, where the bytes of the source block are numbered from 0 through X-1. If X/L is not integral then the last encoding symbol with Encoding Symbol ID = N-1 consists of bytes L*(N-1) through the last byte X-1 of the source block, and the remaining L*N - X bytes of the encoding symbol can by padded out with zeroes.
ソースブロック番号Iと長さXバイト所与のソースブロックについて、N = X / Lが最も近い整数に切り上げましょう。パケットのペイロードで運ばれた符号化シンボルは、ソースブロックの連続部分から成ります。ソースブロックは、論理的に、N個の符号化シンボルに分割され、それぞれ長さLバイト、及び対応する符号化シンボルIDは、ソースブロックの先頭で開始および終了に進むN-1を介して0からの範囲です。したがって、符号化シンボルID Yと符号化シンボルは、L *（Y + 1）-1ソースブロックのバイトは0からX-1を介して番号付けされたソースブロックのを通してバイトのL * Yから成ります。 X - X / Lは、符号化シンボルID = N-1は、ソースブロックの最後のバイトのX-1、および残りのL * Nを介してバイトのL *（N-1）からなると最後の符号化シンボル積分されていない場合符号化シンボルのバイトがゼロでパディングすることにより可能です。
As an example, suppose that the source block length X = 20,400 and encoding symbol length L = 1,000. The encoding symbol with Encoding Symbol ID = 10 contains bytes 10,000 through 10,999 of the source block, and the encoding symbol with Encoding Symbol ID = 20 contains bytes 20,000 through the last byte 20,399 of the source block and the remaining 600 bytes of the encoding symbol can be padded with zeroes.
一例として、そのソースブロック長X = 20,400および符号化シンボル長L = 1,000と仮定する。符号化シンボルIDの符号化シンボル= 10は、ソースブロックの10999を通してバイト10,000含み、符号化シンボルID = 20と符号化シンボルは、ソースブロックの最後のバイト20399及び符号化シンボルの残り600のバイトを通してバイト20,000含ま0でパディングすることができます。
There are no restrictions beyond the rules stated above on how a sender generates encoding symbols to send from a source block. However, it is recommended that an implementor refer to the companion document [RFC3452] for general advice.
送信者がソースブロックから送信する符号化シンボルを生成する方法で上記のルールを超えた制限はありません。しかし、実装者は一般的なアドバイスのための仲間ドキュメント[RFC3452]を参照することをお勧めします。
In the next subsection, a procedure is recommended for sending and receiving source blocks.
次のサブセクションでは、手順は、ソースブロックを送受信するために推奨されています。
The following carousel procedure is RECOMMENDED for a sender to generate packets containing FEC Payload IDs and corresponding encoding symbols for a source block with Source Block Number I. Set the length in bytes of an encoding symbol to a fixed value L, which is reasonable for a packet payload (e.g., ensure that the total packet size does not exceed the MTU) and that is smaller than the source block length X, e.g., L = 1,000 for X >= 1,000. Initialize Y to a value randomly chosen in the interval [0..N-1]. Repeat the following for each packet of the source block to be sent.
以下カルーセル手順はのための合理的である固定値Lにソースブロック番号I.セットとソースブロックの符号化シンボルの長さをバイト単位でFECペイロードIDと対応する符号化シンボルを含むパケットを生成するために、送信者に推奨されますX> = 1,000パケット・ペイロード（例えば、合計パケットサイズがMTUを超えていないことを確認）、そのソースブロック長さXよりも小さい場合、例えば、L =千。ランダム間隔[0..N-1]で選択された値にYを初期化します。送信するソースブロックの各パケットのために、以下の手順を繰り返します。
o If Y <= N-1, then generate the encoding symbol Y.
O Y <= N-1は、符号化シンボルYを生成する場合
o Within the FEC Payload ID, set the Source Block Length to X, set the Source Block Number = I, set the Encoding Symbol ID = Y, place the FEC Payload ID and the encoding symbol into the packet to send.
FECペイロードIDの中でoを、Xのソースブロック長を設定するソースブロック番号= Iを設定し、符号化シンボルID = Yを設定し、送信するパケットにFECペイロードIDとエンコードシンボルを配置します。
o In preparation for the generation of the next packet: if Y < N-1 then increment Y by one else if Y = N-1 then reset Y to zero.
O次のパケットの生成のための調製において：Y = N-1がゼロにYをリセットするとY <N-1は、他のいずれかによってYをインクリメント場合。
The following procedure is RECOMMENDED for a receiver to recover the source block based on receiving packets for the source block from a sender that is using the carousel procedure described above. The receiver can determine from which source block a received packet was generated by the Source Block Number carried in the FEC Payload ID. Upon receipt of the first FEC Payload ID for a source block, the receiver uses the Source Block Length and Encoding Symbol Length received out-of-band as part of the FEC Object Transmission Information to determine the length X in bytes of the source block and length L in bytes of each encoding symbol. The receiver allocates space for the X bytes that the source block requires. The receiver also computes the length of the encoding symbol in the payload of the packet by subtracting the packet header length from the total length of the received packet. The receiver checks that this symbol length is equal to L, except in the case that this is the last symbol of the source block in which case the symbol length in the packet may be less than L. After calculating N = X/L rounded up to the nearest integer, the receiver allocates a boolean array RECEIVED[0..N-1] with all N entries initialized to false to track received encoding symbols. The receiver keeps receiving packets for the source block as long as there is at least one entry in RECEIVED still set to false or until the application decides to give up on this source block and move on to other source blocks. For each received packet for the source block (including the first packet), the steps to be taken to help recover the source block are as follows. Let Y be the value of the Encoding Symbol ID within the FEC Payload ID of the packet. If Y <= N-1, then the receiver copies the encoding symbol into the appropriate place within the space reserved for the source block and sets RECEIVED[Y] = true. If all N entries of RECEIVED are true, then the receiver has recovered the entire source block.
以下の手順は、上記カルーセルの手順を使用している送信者からのソースブロックのパケットを受け取ることに基づいてソースブロックを回復するために受信機に推奨されます。受信機は、受信したパケットがFECペイロードIDで運ばソースブロック番号によって生成されたブロックするソースから決定することができます。ソースブロックの最初のFECペイロードIDを受信すると、受信機は、ソースブロック長を使用して符号化シンボル長は、ソースブロックのバイト単位の長さXを決定するためにFECオブジェクト伝送情報の一部として、アウト・オブ・バンド受信しました各符号化シンボルのバイト単位の長さL。 Xは、ソースブロックが必要とするバイトを受信機が空間を割り当てます。受信機はまた、受信したパケットの合計長さからパケットヘッダの長さを減算することによりパケットのペイロードにおける符号化シンボルの長さを計算します。受信機は、このシンボルの長さは、これが切り上げパケットにおけるシンボル長がN = X / Lを算出した後L.未満であってもよく、その場合、ソースブロックの最後のシンボルがある場合を除いて、Lに等しいかどうかをチェック最も近い整数に、受信機は、ブール配列は、受信符号化シンボルを追跡するためにfalseに初期化され、すべてのN個のエントリと[0..N-1]は受信割り当てます。受信機であれば、まだ偽に、またはアプリケーションがこのソースブロックをあきらめると他のソースブロックに移動することを決定するまで、設定受信中の少なくとも1つのエントリがあるように、ソースブロックのためのパケットを受信し続けます。次のように（最初のパケットを含む）、ソースブロックの各受信パケットについて、ソースブロックの回復を助けるために取られるステップです。 Yは、パケットのFECペイロードID内の符号化シンボルIDの値とします。 Y場合<= N-1、受信機コピー符号化シンボルソースブロック用に予約空間内の適切な場所へとセットは、真= [Y]を受けました。 RECEIVEDのすべてのN個のエントリが真である場合、受信機は、全ソースブロックを回復しました。
This section defines an Under-Specified FEC Scheme for Small Block FEC codes, Large Block FEC codes, and Expandable FEC codes as described in [RFC3453].
[RFC3453]に記載されているように、このセクションでは、小ブロックFECコード、大ブロックFECコード、および拡張可能なFECコードの下で指定のFECスキームを定義します。
The FEC Payload ID is composed of a Source Block Number and an Encoding Symbol ID structured as shown in Figure 3.
FECペイロードIDは、ソースブロック番号と、図3に示すように構成符号化シンボルIDで構成されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: FEC Payload ID Format for Small Block, Large Block, and Expandable FEC Codes
図3：小ブロック、大ブロック、および拡張FEC符号のFECペイロードIDフォーマット
The Source Block Number is a 32-bit unsigned integer that identifies from which source block of the object the encoding symbol(s) in the payload are generated. These blocks are numbered consecutively from 0 to N-1, where N is the number of source blocks in the object.
ソースブロック番号は、ペイロード内の符号化シンボル（s）が生成されるオブジェクトのどのソースブロックから識別する32ビットの符号なし整数です。これらのブロックは、N-1、Nは、オブジェクト内のソースブロックの数であり、0から連続的に番号付けされます。
The Encoding Symbol ID is a 32-bit unsigned integer that identifies which specific encoding symbol(s) generated from the source block are carried in the packet payload. The exact details of the correspondence between Encoding Symbol IDs and the encoding symbol(s) in the packet payload are dependent on the particular FEC Scheme instance used as identified by the FEC Encoding ID and by the FEC Instance ID, and these details may be proprietary.
符号化シンボルIDは、ソースブロックから生成された特定の符号化シンボル（s）は、パケットペイロードで運ばれる特定する32ビットの符号なし整数です。パケットのペイロードに符号化シンボルIDおよび符号化シンボル（S）との対応関係の正確な詳細は、FEC符号化IDによって及びFECインスタンスIDによって識別されるように使用される特定のFECスキームのインスタンスに依存し、そしてこれらの詳細は、専用であってもよいです。
The mandatory FEC Object Transmission Information element for the Small Block, Large Block, and Expandable FEC Scheme are:
小ブロック、大ブロック、および拡張FECスキームのための必須FECオブジェクト伝送情報要素は以下のとおりです。
o FEC Encoding ID: 128
O FECエンコーディングID：128
The Common FEC Object Transmission Information elements and their value ranges for the Small Block, Large Block, and Expandable FEC Scheme are:
小ブロック、大ブロック、および拡張FECスキームのための共通FECオブジェクト伝送情報要素とその値の範囲は以下のとおりです。
FEC Instance ID: a non-negative integer less than 2^^16.
FECインスタンスID：2 ^^ 16未満の非負の整数。
Transfer-Length: a non-negative integer less than 2^^48, indicating the length of the object in octets.
転送長：負でない整数2未満^^ 48、オクテット内のオブジェクトの長さを示します。
Encoding-Symbol-Length: a non-negative integer less than 2^^16, indicating the length of each encoding symbol in octets.
符号化シンボルの長さ：2 ^^ 16未満の非負の整数、オクテット単位で各符号化シンボルの長さを示します。
Maximum-Source-Block-Length: a non-negative integer less than 2^^32, indicating the maximum number of source symbols in a source block.
最大ソースブロック長：負でない整数2 ^^ 32未満の、ソースブロック内のソースシンボルの最大数を示します。
The encoded Common FEC Object Transmission Information is defined in Figure 4.
符号化された共通FECオブジェクト伝送情報を図4に定義されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transfer Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | FEC Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol Length | Max. Source Block Length (MSB)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max. Source Block Length (LSB)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Encoded Common FEC OTI for Small Block, Large Block, and Expandable FEC Scheme
図4：小ブロック、大ブロック、および拡張FECスキームのためにエンコードされた一般的なFEC OTI
The Transfer Length (48 bits), FEC Instance ID (16 bits), Encoding Symbol Length (16 bits), and Maximum Source Block Length (32 bits) are encoded as unsigned integers.
転送長（48ビット）、FECインスタンスID（16ビット）、符号化シンボル長（16ビット）、および最大ソースブロック長（32ビット）の符号なし整数として符号化されます。
The Scheme-Specific FEC Object Transmission Information field for the Small Block, Large Block, and Expandable FEC Scheme provides for the possibility of Instance-specific FEC Object Transmission Information. The format of the Scheme-Specific FEC Object Transmission Information for this FEC Scheme is defined in Figure 5.
小ブロック、大ブロック、および拡張FECスキームのためのスキーマ固有FECオブジェクト伝送情報フィールドは、インスタンス固有のFECオブジェクト伝送情報の可能性を提供します。このFECスキームのためのスキーマ固有FECオブジェクト伝送情報のフォーマットを図5に定義されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Instance-specific FEC OTI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Instance-specific FEC OTI contd. |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Encoded Scheme-Specific FEC OTI for Small Block, Large Block, and Expandable FEC Scheme
図5：小ブロック、大ブロック、および拡張FECスキームのための符号化されたスキーマ固有FEC OTI
The Scheme-Specific FEC Object Transmission Information field contains the following sub-fields:
スキーム固有のFECオブジェクト伝送情報フィールドには、次のサブフィールドが含まれています。
Length (1 octet): an unsigned integer that specifies the length of the Scheme-Specific FEC OTI in four-octet words (including this length field), except that the value zero indicates that no Instance-specific FEC OTI Information is provided. When the Length is zero, three padding bytes containing value zero SHALL follow the Length field to maintain 4-octet alignment.
長さ（1つのオクテット）：値ゼロはないインスタンス固有のFEC OTI情報が提供されていないことを示していることを除いて、（この長さフィールドを含む）4オクテットワードにおけるスキーマ固有FEC OTIの長さを指定する符号なし整数。長さがゼロである場合、値ゼロを含む3つのパディングバイトは4オクテット整列を維持するために、長さフィールドに従わなければなりません。
Instance-specific FEC OTI Information: the contents of this field are FEC Scheme Instance-specific.
インスタンス固有のFEC OTI情報：このフィールドの内容は、FECスキームインスタンス固有です。
Note that in the case of a Content Delivery protocol that supports external signaling of the total FEC Object Transmission Information length, then the Scheme-Specific FEC OTI field defined here is optional. Otherwise, this field MUST be included.
総FECオブジェクト伝送情報長の外部シグナリングをサポートするコンテンツ配信プロトコルの場合には、次いで、ここで定義されたスキーマ固有FEC OTIフィールドがオプションであることに留意されたいです。そうでない場合は、このフィールドを含まなければなりません。
The algorithm defined in Section 9.1. of [RFC5052] MUST be used to partition the file into source blocks.
セクション9.1で定義されたアルゴリズム。 [RFC5052]のソースブロックにファイルを分割するために使用されなければなりません。
The FEC code specification and the correspondence of Encoding Symbols IDs to encoding symbols are defined by specific instances of this scheme and so are out of scope of this document.
FEC符号の仕様及び符号化シンボルの符号化シンボルIDの対応は、このスキームの特定のインスタンスによって定義されるので、この文書の範囲外されています。
This section defines an Under-Specified FEC Scheme for Small Block Systematic FEC codes as described in [RFC3453]. For Small Block Systematic FEC codes, each source block is of length at most 65535 source symbols.
[RFC3453]に記載されているように、このセクションでは、小ブロックシステマティックFEC符号に対してアンダー指定FECスキームを定義します。小ブロックシステマティックFECコードに対して、各ソースブロックは、最も65535個のソースシンボルで長さです。
Although these codes can generally be accommodated by the FEC Encoding ID described in Section 4, a specific FEC Encoding ID is defined for Small Block Systematic FEC codes to allow more flexibility and to retain header compactness. The small source block length and small expansion factor that often characterize systematic codes may require the data source to frequently change the source block length. To allow the dynamic variation of the source block length and to communicate it to the receivers with low overhead, the block length is included in the FEC Payload ID.
これらのコードは、一般に、FEC符号化IDに収容することができるが、セクション4で説明した、特定のFEC符号化IDは、より多くの柔軟性を可能にするために、ヘッダコンパクトを保持する小ブロックシステマティックFECコードに対して定義されています。多くの場合、組織符号を特徴付ける小さなソースブロック長と小さな膨張係数が頻繁にソースブロック長を変更するために、データソースを必要とするかもしれません。ソースブロック長の動的変化を可能にするために、低オーバーヘッドで受信機にそれを通信するために、ブロック長は、FECペイロードIDに含まれています。
The FEC Payload ID is composed of the Source Block Number, Source Block Length, and the Encoding Symbol ID structured as shown in Figure 6.
図6に示すように、FECペイロードIDは、ソースブロック番号、ソースブロック長、及び構造化符号化シンボルIDで構成されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length | Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: FEC Payload ID Format for Small Block Systematic FEC Scheme
図6：スモールブロックシステマティックFECスキームのためのFECペイロードIDフォーマット
The Source Block Number is a 32-bit unsigned integer that identifies from which source block of the object the encoding symbol(s) in the payload are generated. These blocks are numbered consecutively from 0 to N-1, where N is the number of source blocks in the object.
ソースブロック番号は、ペイロード内の符号化シンボル（s）が生成されるオブジェクトのどのソースブロックから識別する32ビットの符号なし整数です。これらのブロックは、N-1、Nは、オブジェクト内のソースブロックの数であり、0から連続的に番号付けされます。
The Source Block Length is a 16-bit unsigned integer that specifies the length in units of source symbols of the source block identified by the Source Block Number.
ソースブロック長は、ソースブロック番号によって識別されるソースブロックのソースシンボルの単位で長さを指定する16ビットの符号なし整数です。
The Encoding Symbol ID is a 16-bit unsigned integer that identifies which specific encoding symbol(s) generated from the source block are carried in the packet payload. Each encoding symbol is either an original source symbol or a redundant symbol generated by the encoder. The exact details of the correspondence between Encoding Symbol IDs and the encoding symbol(s) in the packet payload are dependent on the particular FEC Scheme instance used as identified by the FEC Instance ID, and these details may be proprietary.
符号化シンボルIDは、ソースブロックから生成された特定の符号化シンボル（s）は、パケットペイロードで運ばれる特定する16ビットの符号なし整数です。各符号化シンボルは、元のソースシンボルまたはエンコーダによって生成される冗長シンボルのいずれかです。符号化シンボルIDおよびパケットペイロードにおける符号化シンボル（S）との対応関係の正確な詳細は、FECインスタンスIDによって識別されるように使用される特定のFECスキームのインスタンスに依存し、そしてこれらの詳細は、専用であってもよいです。
The mandatory FEC Object Transmission Information element for the Small Block Systematic FEC Scheme is:
スモールブロックシステマティックFECスキームのための必須FECオブジェクト伝送情報要素は次のとおりです。
o FEC Encoding ID: 129
O FECエンコーディングID：129
The Common FEC Object Transmission Information elements and their value ranges for the Small Block Systematic FEC Scheme are:
スモールブロックシステマティックFECスキームのための共通FECオブジェクト伝送情報要素とその値の範囲は以下のとおりです。
FEC Instance ID: a non-negative integer less than 2^^16.
FECインスタンスID：2 ^^ 16未満の非負の整数。
Transfer-Length: a non-negative integer less than 2^^48, indicating the length of the object in octets.
転送長：負でない整数2未満^^ 48、オクテット内のオブジェクトの長さを示します。
Encoding-Symbol-Length: a non-negative integer less than 2^^16, indicating the length of each encoding symbol in octets.
符号化シンボルの長さ：2 ^^ 16未満の非負の整数、オクテット単位で各符号化シンボルの長さを示します。
Maximum-Source-Block-Length: a non-negative integer less than 2^^16, indicating the maximum number of source symbols in a source block.
最大ソースブロック長：負でない整数2 ^^ 16未満の、ソースブロック内のソースシンボルの最大数を示します。
Max-Number-of-Encoding-Symbols: a non-negative integer less than 2^^16, indicating the maximum number of encoding symbols per block (i.e., source plus repair symbols in the case of a systematic code).
最大数-の符号化シンボル：2 ^^ 16未満の非負の整数、ブロック当たりの符号化シンボル（組織符号の場合、すなわち、ソースプラスリペアシンボル）の最大数を示します。
The encoded Common FEC Object Transmission Information is defined in Figure 7.
符号化された共通FECオブジェクト伝送情報を図7に定義されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transfer Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | FEC Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol Length | Maximum Source Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max. Num. of Encoding Symbols |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: FEC OTI Format for Small Block Systematic FEC Scheme
図7：スモールブロックシステマティックFECスキームのためのFEC OTIフォーマット
The Transfer Length (48 bits), FEC Instance ID (16 bits), Encoding Symbol Length (16 bits), Maximum Source Block Length (16 bits), and Maximum Number of Encoding Symbols (16 bits) are encoded as unsigned integers.
転送長（48ビット）、FECインスタンスID（16ビット）、符号化シンボル長（16ビット）、最大ソースブロック長（16ビット）、および符号化シンボル（16ビット）の最大数は、符号なし整数として符号化されます。
All Encoding Symbols of a transport object MUST have length equal to the length specified in the Encoding Symbol Length field, with the optional exception of the last source symbol of the last source block (so that redundant padding is not mandatory in this last symbol). This last source symbol MUST be logically padded out with zeroes when another Encoding Symbol is computed based on this source symbol to ensure the same interpretation of this Encoding Symbol value by the sender and receiver. However, this padding need not be actually sent with the data of the last source symbol.
トランスポート・オブジェクトのすべての符号化シンボルが最後のソースブロックの最後のソースシンボルのオプションを除いて符号化シンボル長フィールドに指定された長さに等しい長さを有していなければならない（その結果、冗長なパディングは、この最後のシンボルに必須ではありません）。別の符号化シンボルは、送信側と受信側で、この符号化シンボル値の同じ解釈を確保するために、このソースシンボルに基づいて計算されている場合、この最後のソースシンボルは、論理的にゼロでパディングされなければなりません。しかし、このパディングが実際に最後のソースシンボルのデータと一緒に送信する必要はありません。
Note: this FEC Scheme was first defined in [RFC3452], which did not require that the Encoding Symbol Length should be the same for every source block. However, no protocols have been defined that support variation in the Encoding Symbol Length between source blocks, and thus introduction of a general requirement that the Encoding Symbol Length be the same across source blocks (as defined here) should not cause backwards compatibility issues and will aid interoperability.
注意：このFECスキームは、最初に[RFC3452]で定義された、符号化シンボルの長さは、すべてのソースブロックの同じであるべきことを要求しませんでした。しかし、何のプロトコルは、ソースブロック間の符号化シンボルの長さでそのサポート変動を定義されていないため、（ここで定義されている）符号化シンボルの長さは、ソースブロックで同じである一般的な要件の導入は、互換性の問題を後方原因となりますべきではありません援助の相互運用性。
The Scheme-Specific FEC Object Transmission Information format defined in Section 4.2.2.3 SHALL be used.
セクション4.2.2.3で定義されたスキーマ固有FECオブジェクト伝送情報のフォーマットを使用しなければなりません。
The algorithm defined in Section 9.1. of [RFC5052] MAY be used to partition the file into source blocks. Otherwise, the FEC Scheme instance MUST specify the algorithm that is used.
セクション9.1で定義されたアルゴリズム。 [RFC5052]のソースブロックにファイルを分割するために使用されるかもしれません。それ以外の場合は、FECスキームのインスタンスが使用されるアルゴリズムを指定しなければなりません。
The FEC code specification and the correspondence of Encoding Symbols IDs to encoding symbols are defined by specific instances of this scheme and so are out of scope of this document.
FEC符号の仕様及び符号化シンボルの符号化シンボルIDの対応は、このスキームの特定のインスタンスによって定義されるので、この文書の範囲外されています。
The Compact FEC Scheme is an Under-Specified FEC Scheme. This FEC Scheme is similar in spirit to the Compact No-Code FEC Scheme, except that a non-trivial FEC encoding (that is Under-Specified) may be used to generate encoding symbol(s) placed in the payload of each packet and a corresponding FEC decoder may be used to produce the source block from received packets.
コンパクトなFECスキームの下では、指定されたFECスキームです。このFECスキームは、非自明なFEC符号化（つまりアンダー指定されている）符号化シンボル（単数または複数）を生成するために使用されてもよいことを除いて、コンパクト無コードFECスキームと精神に類似しており、各パケットのペイロード及びA中に入れFEC復号器を対応する受信したパケットからソースブロックを生成するために使用されてもよいです。
The FEC Payload ID format defined in Section 3.2.1 SHALL be used.
セクション3.2.1で定義されたFECペイロードIDフォーマットを使用しなければなりません。
The mandatory FEC Object Transmission Information element for the Compact No-Code FEC Scheme is:
コンパクト無コードFECスキームのための必須FECオブジェクト伝送情報要素は次のとおりです。
o FEC Encoding ID: 130
O FECエンコーディングID：130
The Common FEC Object Transmission Information elements and their encoding are the same as defined for the Small Block, Large Block, and Expandable FEC Scheme in Figure 4.
共通FECオブジェクト伝送情報要素とその符号化、小ブロック、大ブロック、及び図4の拡張FECスキームの定義と同じです。
The Scheme-Specific FEC Object Transmission Information format defined in Section 4.2.2.3 SHALL be used.
セクション4.2.2.3で定義されたスキーマ固有FECオブジェクト伝送情報のフォーマットを使用しなければなりません。
The algorithm defined in Section 9.1. of [RFC5052] MUST be used to partition the file into source blocks.
セクション9.1で定義されたアルゴリズム。 [RFC5052]のソースブロックにファイルを分割するために使用されなければなりません。
The FEC code specification and the correspondence of Encoding Symbols IDs to encoding symbols are defined by specific instances of this scheme and so are out of scope of this document.
FEC符号の仕様及び符号化シンボルの符号化シンボルIDの対応は、このスキームの特定のインスタンスによって定義されるので、この文書の範囲外されています。
This specification does not introduce any further security considerations beyond those described in [RFC5052].
この仕様は、[RFC5052]に記載されているものを超えて、更なるセキュリティ上の考慮事項を導入しません。
This document is substantially based on [RFC3695] by Michael Luby and Lorenzo Vicisano and [RFC3452] by Michael Luby, Lorenzo Vicisano, Jim Gemmell, Luigi Rizzo, Mark Handley, and Jon Crowcroft.
この文書は、実質的にマイケル・ルビー、ロレンツォVicisano、ジムGemmell、ルイジ・リゾ、マーク・ハンドリー、そしてジョン・クロークロフトによってマイケル・ルビーとロレンツォVicisanoと[RFC3452]で、[RFC3695]に基づいています。
FEC Encoding IDs 0 and 130 were first defined and registered in the ietf:rmt:fec:encoding namespace by [RFC3695]. This document updates and obsoletes the definitions from that specification. References to that specification should be replaced with references to this document.
FEC符号化IDは0と130が最初に定義され、IETFに登録した：RMT：FEC：[RFC3695]で名前空間をコードします。このドキュメントの更新とその仕様から定義を廃止。その仕様への参照は、この文書への参照に置き換える必要があります。
FEC Encoding IDs 128 and 129 were first defined and registered in the ietf:rmt:fec:encoding namespace by [RFC3452]. This document updates and obsoletes the definitions from that specification. References to that specification should be replaced with references to this document.
FEC符号化IDが128と129は、最初に定義され、IETFに登録した：RMT：FEC：[RFC3452]で名前空間をコードします。このドキュメントの更新とその仕様から定義を廃止。その仕様への参照は、この文書への参照に置き換える必要があります。
Values of FEC Encoding IDs and FEC Instance IDs are subject to IANA registration. For general guidelines on IANA considerations as they apply to this document, see [RFC5052].
FEC符号化IDとFECインスタンスIDの値は、IANA登録の対象となっています。彼らは、この文書に適用されるIANA問題に関する一般的なガイドラインについては、[RFC5052]を参照してください。
This document assigns the Fully-Specified FEC Encoding ID 0 under the ietf:rmt:fec:encoding name-space (which was previously assigned by [RFC3695], which is obsoleted by this document) to "Compact No-Code" as specified in Section 3 above.
この文書は、IETFの下で完全に指定されたFEC符号化ID 0を代入：RMT：FEC：（このドキュメントによって廃止され、以前に[RFC3695]によって割り当てられた、）をコードする名前空間に「コンパクト無コード」に指定され第3節以上。
This document assigns the Under-Specified FEC Encoding ID 128 under the ietf:rmt:fec:encoding name-space (which was previously assigned by [RFC3452]) to "Small Block, Large Block, and Please note that we have added a comma between large block and expandable throughout this document (RFC Editor style is to include a comme before the last item of a series). If you do not object, we will ask IANA to include this comma in their registry for consistency. --> Expandable FEC Codes" as specified in Section 4 above.
RMT：：FEC：（以前に[RFC3452]によって割り当てられた）をコードネームスペース「小ブロック、大ブロックに、我々はカンマを追加したことに注意してください。このドキュメントは、IETFの下にアンダー指定されたFEC符号化ID 128を割り当て、本書を通して、大きなブロックと拡張の間（RFC Editorのスタイルは、シリーズの最後の項目の前にCOMMEを含めることである）あなたは反対しない場合、我々は一貫性のために自分のレジストリにこのカンマが含まれるようにIANAを要求します - 。。>拡張可能上記第4節で指定されたFECコード」。
This document assigns the Under-Specified FEC Encoding ID 129 under the ietf:rmt:fec:encoding name-space (which was previously assigned by [RFC3452]) to "Small Block Systematic FEC Codes" as specified in Section 5 above.
RMT：FEC：この文書は、IETFの下にアンダー指定FEC符号化ID 129を割り当て、上記セクション5で指定されるように、「小ブロックシステマティックFECコード」（以前は[RFC3452]によって割り当てられた）名前空間をコードします。
This document assigns the Under-Specified FEC Encoding ID 130 under the ietf:rmt:fec:encoding name-space (which was previously assigned by [RFC3695], which is obsoleted by this document) to "Compact FEC" as specified in Section 6 above.
RMT：FEC：この文書は、IETFの下にアンダー指定FEC符号化ID 130を割り当てセクション6で指定されるように、「コンパクトFEC」（以前にこの文書によって廃止され[RFC3695]によって割り当てられた）をコードネームスペースを上記。
As FEC Encoding IDs 128, 129, and 130 are Under-Specified, "FEC Instance ID" sub-name-spaces must be established, in accordance to [RFC5052]. Hence, this document also assumes responsibility for the "FEC Instance ID" registries named.
FEC符号化IDは128、129、及び130は、アンダー指定されているように、「FECインスタンスID」サブ名前空間は[RFC5052]に基づいて、確立されなければなりません。したがって、この文書では、名前の「FECインスタンスID」レジストリの責任を前提としています。
ietf:rmt:fec:encoding:instance:128, scoped by ietf:rmt:fec: encoding = 128
IETF：RMT：FEC：符号化：例：128、IETFによってスコープ：RMT：FEC：エンコーディング= 128
ietf:rmt:fec:encoding:instance:129, scoped by ietf:rmt:fec: encoding = 129
IETF：RMT：FEC：符号化：例：129、IETFによってスコープ：RMT：FEC：エンコーディング= 129
ietf:rmt:fec:encoding:instance:130, scoped by ietf:rmt:fec: encoding = 130
IETF：RMT：FEC：符号化：例：130、IETFによってスコープ：RMT：FEC：エンコーディング= 130
The values that can be assigned within these namespaces are non-negative numeric indices. Assignment requests are granted on a "First Come First Served" basis. [RFC5052] specifies additional criteria that MUST be met for the assignment within the generic ietf: rmt:fec:encoding:instance name-space. These criteria also apply to ietf:rmt:fec:encoding:instance:128, ietf:rmt:fec:encoding:instance: 129, and ietf:rmt:fec:encoding:instance:130.
これらの名前空間内で割り当て可能な値は負の数値のインデックスです。割り当て要求は「まず第一に役立っ是非」に基づき付与されます。 RMT：FEC：エンコーディング：インスタンス名空間[RFC5052]は、一般的なIETF内の割り当てのために満たさなければならない追加の基準を指定します。これらの基準はまた、IETFに適用：RMT：FEC：符号化：例：128、IETF：RMT：FEC：符号化：例：129、及びIETF：RMT：FEC：符号：インスタンス：130。
This section describes the changes between the Experimental versions of these FEC Scheme specifications contained in RFC 3452 [RFC3452] and RFC 3695 [RFC3695] and those defined in this specification:
このセクションでは、RFC 3452 [RFC3452]及びRFC 3695 [RFC3695]及び本明細書で定義されたものに含まれるこれらのFECのスキーム仕様の実験バージョン間の変更について説明します。
o Scheme definitions have been updated to meet the requirements of [RFC5052].
Oスキームの定義は、[RFC5052]の要件を満たすように更新されました。
o Complete encoding formats for the FEC Object Transmission Information for each scheme are defined here, instead of within content delivery protocol specifications, since the exact format depends on the FEC Scheme.
正確なフォーマットはFECスキームに依存するので、各スキームのためのFECオブジェクト伝送情報のためのOの完全な符号化フォーマットは、代わりに、コンテンツ配信プロトコルの仕様の範囲内で、ここに定義されます。
o The previous specifications for the Compact No-Code and Small Block Systematic FEC Schemes did not require that all encoding symbols of the object should have the same length. This requirement is introduced in this specification. Since no protocols have been defined that support variation of the encoding symbol length within an object this should not cause backwards compatibility issues.
コンパクト無コードとスモールブロック体系的FECスキームのために、以前の仕様オブジェクトoのすべての符号化シンボルが同じ長さを持つべきであることを必要としませんでした。この要件は、この仕様で導入されました。何のプロトコルは、オブジェクト内の符号化シンボル長のサポート変動を定義されていないので、これは互換性の問題を後方発生することはありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5052]ワトソン、M.、ルビー、M.、およびL. Vicisano、 "前方誤り訂正（FEC）ビルディングブロック"、RFC 5052、2007年8月。
[RFC3452] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002.
[RFC3452]ルビー、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト、 "前方誤り訂正（FEC）ビルディングブロック"、RFC 3452、2002年12月。
[RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002.
[RFC3453]ルビー、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト、 "信頼できるマルチキャストの前方誤り訂正（FEC）の使用"、RFC 3453 、2002年12月。
[RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
[RFC3269] Kermode、R.とL. Vicisano、RFC 3269、2002年4月 "信頼できるマルチキャストトランスポート（RMT）ビルディングブロックとプロトコルのインスタンス文書の作者のガイドライン"。
[RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S., and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.
[RFC3048] Whetten、B.、Vicisano、L.、Kermode、R.、ハンドレー、M.、フロイド、S.、およびM.ルビー、 "信頼できるマルチキャストトランスポート・ビルディング・ブロック一対多バルクデータ転送のための" 、RFC 3048、2001年1月。
[RFC3695] Luby, M. and L. Vicisano, "Compact Forward Error Correction (FEC) Schemes", RFC 3695, February 2004.
[RFC3695]ルビー、M.およびL. Vicisano、 "コンパクト前方誤り訂正（FEC）スキーム"、RFC 3695、2004年2月。
Author's Address
著者のアドレス
Mark Watson Digital Fountain 39141 Civic Center Drive Suite 300 Fremont, CA 94538 USA
マーク・ワトソンデジタル噴水39141シビックセンタードライブスイート300フリーモント、CA 94538 USA
EMail: mark@digitalfountain.com
メールアドレス：mark@digitalfountain.com