[要約] RFC 5445は、基本的な転送エラー訂正（FEC）スキームに関する情報を提供する。その目的は、ネットワーク通信の信頼性を向上させるために、エラー訂正技術を使用する方法を定義することである。
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
基本的なフォワードエラー補正（FEC）スキーム
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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
o コンパクトノーコードFECスキーム
o Small Block, Large Block, and Expandable FEC Scheme
o 小さなブロック、大きなブロック、拡張可能なFECスキーム
o Small Block Systematic FEC Scheme
o 小さなブロック系統的FECスキーム
o Compact FEC Scheme
o コンパクトFECスキーム
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]。このドキュメントでは、コンパニオンドキュメント[RFC3453]の用語も使用します。これは、信頼できるIPマルチキャストトランスポートのコンテキスト内でFECコードの使用を説明し、一般的に使用されるFECコードの紹介を提供します。
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は、「実験的」カテゴリに掲載されました。RMTワーキンググループが、これらの仕様をIETF提案された基準をやがて再提出することを目的とした意図でした。この文書は廃止[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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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.
Compact No-Code 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.
Compact No-Code FECスキームのFECペイロードIDは、図1に示すように、ソースブロック番号とエンコードシンボル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ビットの符号なし整数です。可能なモードは2つあります。一意の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モードでは、同じソースブロック番号にマッピングされた2つの異なるソースブロックのパケットは、ソースブロックの輸送時間よりも短い時間間隔内で送信しないでください。ソースブロックの輸送時間には、送信者輸送層でソースブロックを処理するのに必要な時間、パケットのネットワークトランジット時間、レシーバー輸送でソースブロックを処理するのに必要な時間が含まれます。これにより、受信者はどのパケットがどのソースブロックに属しているかを明確に決定できます。
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)
o FECエンコードID：ゼロ（0）
The Common FEC Object Transmission Information elements and their value ranges for the Compact No-Code FEC Scheme are:
Compact No-Code 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を最も近い整数まで丸めます。パケットのペイロードで運ばれるエンコードシンボルは、ソースブロックの連続した部分で構成されています。ソースブロックは、長さが各Lバイトのnエンコードシンボルに論理的に分割され、対応するエンコードシンボルIDの範囲は、ソースブロックの先頭から始まり、最後まで進みます。したがって、シンボルID yをエンコードするエンコーディングシンボルは、ソースブロックのバイトl*yからl*（y 1）-1で構成され、ソースブロックのバイトは0からx-1から番号が付けられています。x/lが積分でない場合、シンボルID = n-1をエンコードする最後のエンコードシンボルは、ソースブロックの最後のバイトx-1を介したバイトl*（n-1）と残りのl*n-xで構成されています。エンコーディングシンボルのバイトは、ゼロでパッドアウトすることによってできます。
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のエンコードシンボルには、ソースブロックの10,000〜10,999が含まれ、エンコードシンボルID = 20のエンコードシンボルには、ソースブロックの最後のバイト20,399とエンコーディングシンボルの残りの600バイトから20,000バイトが含まれます。ゼロでパディングできます。
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.
次のカルーセル手順は、送信者がFECペイロードIDを含むパケットを生成し、ソースブロック番号Iのソースブロックの対応するエンコードシンボルを生成することをお勧めします。パケットペイロード（たとえば、合計パケットサイズがMTUを超えないことを確認してください）、それはソースブロック長xよりも小さい、例えばx> = 1,000のL = 1,000。間隔[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.
o FECペイロードID内で、ソースブロック長を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 = 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に掲載されたソースブロック番号によって受信されたパケットAが生成されたソースブロックからどのソースブロックが生成されたかを決定できます。ソースブロックの最初のFECペイロードIDを受信すると、受信者はソースブロックの長さとエンコードシンボルの長さを使用して、FECオブジェクトトランスミッション情報の一部として帯域外の長さを使用して、ソースブロックのバイトで長さxを決定します。各エンコードシンボルのバイトの長さl。受信機は、ソースブロックが必要とするxバイトのスペースを割り当てます。また、受信者は、受信したパケットの全長からパケットヘッダーの長さを差し引くことにより、パケットのペイロードにエンコードシンボルの長さを計算します。受信機は、このシンボルの長さがLに等しいことを確認します。ただし、これがソースブロックの最後のシンボルである場合を除き、パケットのシンボルの長さはLよりも少ない場合があります。最寄りの整数に、受信者は受信した[0..N-1]をfalseに初期化して受信したエンコードシンボルを追跡して、受信した[0..N-1]を割り当てます。受信者は、少なくとも1つのエントリがfalseに設定されているか、アプリケーションがこのソースブロックをあきらめて他のソースブロックに移動することを決定するまで、ソースブロックのパケットを受信し続けます。ソースブロック（最初のパケットを含む）の受信パケットごとに、ソースブロックを回復するのに役立つ手順は次のとおりです。パケットのFECペイロードID内のエンコードシンボルIDの値とします。y <= n-1の場合、レシーバーはエンコードシンボルをソースブロックに予約されたスペース内の適切な場所にコピーし、[y] = trueを受信します。受信のすべての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.
ソースブロック番号は、32ビットの符号なし整数であり、ペイロードのエンコーディングシンボルが生成されるオブジェクトのソースブロックを識別します。これらのブロックには、0からn-1まで連続して番号が付けられ、nはオブジェクト内のソースブロックの数です。
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は、ソースブロックから生成された特定のエンコードシンボルがパケットペイロードに配置される32ビットの符号なし整数です。エンコード記号IDとパケットペイロードのエンコードシンボルの間の対応の正確な詳細は、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.
これらのコードは通常、セクション4で説明されているFECエンコードIDに対応できますが、特定の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.
FECペイロードIDは、図6に示すように、ソースブロック番号、ソースブロック長、およびエンコードシンボル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.
ソースブロック番号は、32ビットの符号なし整数であり、ペイロードのエンコーディングシンボルが生成されるオブジェクトのソースブロックを識別します。これらのブロックには、0からn-1まで連続して番号が付けられ、nはオブジェクト内のソースブロックの数です。
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は、ソースブロックから生成された特定のエンコードシンボルがパケットペイロードに掲載される16ビットの非署名整数です。各エンコードシンボルは、元のソースシンボルまたはエンコーダーによって生成される冗長シンボルのいずれかです。エンコードシンボルIDとパケットペイロードのエンコードシンボルとの対応の正確な詳細は、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エンコード（不足している）を使用して、各パケットのペイロードに配置されたエンコードシンボルと対応する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.
この文書は、マイケル・ルビーとロレンツォ・ヴィジサノによる[RFC3695]、[RFC3452]、[RFC3452]によるマイケル・ルビー、ロレンツォ・ヴィジサノ、ジム・ジェムメル、ルイージ・リッツォ、マーク・ハンドリー、ジョン・クロフトに基づいています。
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.
ID 0および130のFECが最初に定義され、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：RMT：FEC：Encoding Name-Space（[RFC3695]によって以前に割り当てられていた、このドキュメントによって廃止された[コンパクトNO-Code]に指定された「コンパクトノーコード」）に基づいて、完全に指定されたFECエンコードID 0を割り当てます。上記のセクション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.
このドキュメントでは、IETF：RMT：FEC：名前空間（以前は[RFC3452]によって割り当てられていた）に基づいて、IETF：RMT：FECの下にある不足しているFECエンコードID 128を「小さなブロック、大きなブロック、そしてコンマを追加したことに注意してください。このドキュメント全体で大きなブロックと拡張性の間にあります（RFCエディタースタイルは、シリーズの最後のアイテムの前に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.
このドキュメントは、IETF：RMT：FEC：Encoding Name-Space（[RFC3452]によって以前に割り当てられていた）に基づいて、上記のセクション5で指定されている「Small block systematic FECコード」に、不足しているFECエンコードID 129を割り当てます。
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.
このドキュメントでは、IETF：RMT：FEC：Encoding Name-Space（[RFC3695]によって以前に割り当てられていた）に基づいて、このドキュメントで廃止された[RFC3695]によってエンコードされたID 130を指定していないID 130を割り当てます。セクション6で指定されているように「コンパクトFEC」その上。
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.
ID 128、129、および130のFECをエンコードすると、[RFC5052]に従って、「FECインスタンスID」サブネームスペースを確立する必要があります。したがって、このドキュメントは、「FEC Instance ID」レジストリの名前の責任も課しています。
ietf:rmt:fec:encoding:instance:128, scoped by ietf:rmt:fec:
encoding = 128
ietf:rmt:fec:encoding:instance:129, scoped by ietf:rmt:fec:
encoding = 129
ietf:rmt:fec:encoding:instance:130, scoped by ietf:rmt:fec:
encoding = 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.
これらの名前空間内で割り当てることができる値は、非陰性の数値インデックスです。割り当てリクエストは、「First Come First Fort」ベースで付与されます。[RFC5052]汎用IETF内の割り当てに対して満たされなければならない追加の基準を指定します：RMT：FEC：エンコード：インスタンス名スペース。これらの基準は、IETF：RMT：FEC：Encoding：Instance：128、IETF：RMT：FEC：Encoding：Instance：129、およびIETF：RMT：FEC：Encoding：Instance：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.
o 正確な形式はFECスキームに依存するため、コンテンツ配信プロトコル仕様内ではなく、各スキームのFECオブジェクト伝送情報の完全なエンコード形式は、ここで定義されています。
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.
o コンパクトノーコードと小さなブロックの系統的FECスキームの以前の仕様では、オブジェクトのすべてのエンコードシンボルが同じ長さを持つ必要はありませんでした。この要件は、この仕様に導入されています。オブジェクト内のエンコードシンボル長のバリエーションをサポートするプロトコルは定義されていないため、これは逆方向の互換性の問題を引き起こすべきではありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5052] Watson、M.、Luby、M。、およびL. Vicisano、「フォワードエラー補正（FEC）ビルディングブロック」、RFC 5052、2007年8月。
[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] Luby、M.、Vicisano、L.、Gemmell、J.、Rizzo、L.、Handley、M。、およびJ. Crowcroft、「フォワードエラー補正（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] Luby、M.、Vicisano、L.、Gemmell、J.、Rizzo、L.、Handley、M。、およびJ. Crowcroft、「信頼できるマルチキャストでのフォワードエラー補正（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、「信頼できるマルチキャスト輸送（RMT）ビルディングブロックとプロトコルインスタンス化ドキュメントの著者ガイドライン」、RFC 3269、2002年4月。
[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.、Handley、M.、Floyd、S。、およびM. Luby、「1対Many Bulk-Data転送用の信頼できるマルチキャスト輸送ビルディングブロック」、RFC 3048、2001年1月。
[RFC3695] Luby, M. and L. Vicisano, "Compact Forward Error Correction (FEC) Schemes", RFC 3695, February 2004.
[RFC3695] Luby、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フリーモント、カリフォルニア94538 USA
EMail: mark@digitalfountain.com