Network Working Group M. Luby
Request for Comments: 3695 Digital Fountain
Category: Experimental L. Vicisano
Cisco
February 2004
Compact Forward Error Correction (FEC) Schemes
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
Abstract
抽象
This document introduces some Forward Error Correction (FEC) schemes that supplement the FEC schemes described in RFC 3452. The primary benefits of these additional FEC schemes are that they are designed for reliable bulk delivery of large objects using a more compact FEC Payload ID, and they can be used to sequentially deliver blocks of an object of indeterminate length. Thus, they more flexibly support different delivery models with less packet header overhead.
この文書では、これらの追加FECスキームの主な利点は、それらがよりコンパクトなFECペイロードIDを使用して大規模なオブジェクトの信頼性の高い大量配信のために設計されているということであるRFC 3452.に記述FECスキームを補完するいくつかの前方誤り訂正（FEC）スキームが導入され、それらは順次不定長のオブジェクトのブロックを送達するために使用することができます。したがって、それらはより柔軟に少ないパケットヘッダオーバーヘッドで異なる配信モデルをサポートします。
This document also describes the Fully-Specified FEC scheme corresponding to FEC Encoding ID 0. This Fully-Specified FEC scheme requires no FEC coding and is introduced primarily to allow simple interoperability testing between different implementations of protocol instantiations that use the FEC building block.
この文書はまた、この完全に指定されたFECスキームFEC符号化ID 0に対応する完全に指定されたFECスキームにはFEC符号化を必要としない説明し、FECビルディングブロックを使用するプロトコルのインスタンスの異なる実装の間の単純な相互運用性テストを可能にするために主に導入されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Packet Header Fields . . . . . . . . . . . . . . . . . . . . . 3
2.1. FEC Payload ID for FEC Encoding IDs 0 and 130. . . . . . 4
2.2. Compact No-Code FEC scheme . . . . . . . . . . . . . . . 5
2.3. Compact FEC scheme . . . . . . . . . . . . . . . . . . . 5
3. Compact No-Code FEC scheme . . . . . . . . . . . . . . . . . . 6
3.1. Source Block Logistics . . . . . . . . . . . . . . . . . 7
3.2. Sending and Receiving a Source Block . . . . . . . . . . 8
4. Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Reliable Bulk Data Delivery. . . . . . . . . . . . . . . 9
4.2. Block-Stream Delivery. . . . . . . . . . . . . . . . . . 10
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 12
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
This document describes two new Forward Error Correction (FEC) schemes corresponding to FEC Encoding IDs 0 and 130 which supplement the FEC schemes corresponding to FEC Encoding IDs 128 and 129 described in the FEC Building Block [4].
この文書では、FEC符号化IDに対応する二つの新しい順方向誤り訂正（FEC）スキームを説明0と130れる補足FECビルディングブロック[4]に記載のFEC符号化IDが128と129に対応するFEC方式を。
The new FEC schemes are particularly applicable when an object is partitioned into equal-length source blocks. In this case, the source block length common to all source blocks can be communicated out-of-band, thus saving the additional overhead of carrying the source block length within the FEC Payload ID of each packet. The new FEC schemes are similar to the FEC schemes with FEC Encoding ID 128 defined in RFC 3452 [4], except that the FEC Payload ID is half as long. This is the reason that these new FEC schemes are called Compact FEC schemes.
オブジェクトは等長ソースブロックに分割されるとき、新しいFEC方式は特に適用可能です。この場合、全てのソースブロックに共通のソースブロック長は、このように、各パケットのFECペイロードID内のソースブロック長を運ぶ追加のオーバーヘッドを節約する、アウト・オブ・バンド通信することができます。新たなFEC方式は、FECペイロードIDは、半分の長さであることを除いて、[4] RFC 3452で定義されたFEC符号化ID 128とFECスキームに類似しています。これは、これらの新しいFECスキームは、コンパクトなFECスキームと呼ばれる理由です。
The primary focus of FEC Encoding IDs 128 and 129 is to reliably deliver bulk objects of known length. The FEC schemes described in this document are designed to be used for both reliable delivery of bulk objects of known length, and for the delivery of a stream of source blocks for an object of indeterminate length. Within the block-stream delivery model, reliability guarantees can range from acknowledged reliable delivery of each block to unacknowledged enhanced-reliability delivery of time-sensitive blocks, depending on the properties of the protocol instantiation in which the FEC scheme is used. Acknowledged reliable block-stream delivery is similar in spirit to the byte-stream delivery that TCP offers, except that the unit of delivery is a block of data instead of a byte of data. In the spirit of a building block (see RFC 3048 [6]), the FEC schemes described in this document can be used to provide reliability for other service models as well.
FEC符号化IDが128と129の主な焦点は、確実に既知の長さの大部分のオブジェクトを提供することです。この文書に記載されたFECスキームは、既知の長さの大部分のオブジェクトの信頼できる配信の両方のために、及び不定長さのオブジェクトのソースブロックのストリームの送達のために使用されるように設計されています。ブロックストリーム配信モデル内で、信頼性の保証は、FECスキームが使用されるプロトコルインスタンスの特性に応じて、各ブロックの認め信頼できる配信の時間に敏感なブロックの未確認の向上、信頼性のデリバリーの範囲とすることができます。信頼性の高いブロックストリームの配信を認め配達の単位ではなく、データのバイトのデータのブロックであることを除いて、TCPが提供するバイトストリームの配信とその精神において似ています。ビルディングブロックの精神で、この文書に記載さFECスキームは、他のサービスモデルの信頼性を提供するために使用することができる（[6] RFC 3048を参照）。
The two new FEC Encoding IDs 0 and 130 are described in Section 2, and this supplements Section 5 of the FEC building block [4]. Section 3 of this document describes the Fully-Specified FEC scheme corresponding to the FEC Encoding ID 0. This Fully-Specified FEC 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符号化IDは0と130は、セクション2に記載されており、これはFECビルディングブロックのセクション5を補足[4]。このドキュメントのセクション3は、この完全に指定されたFECスキームはないFEC符号化を必要とせず、FECビルディングを使用するプロトコルのインスタンスの異なる実装の間の単純な相互運用性テストを可能にするために、主に指定されたFEC符号化ID 0に対応する完全に指定されたFECスキームが記載されてブロック。
This document inherits the context, language, declarations and restrictions of the FEC building block [4]. This document also uses the terminology of the companion document [7] 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ビルディングブロック[4]の制限を継承します。この文書はまた、信頼性の高いIPマルチキャストトランスポートのコンテキスト内でFEC符号の使用について説明し、いくつかの一般的に使用されるFEC符号への導入を提供するコンパニオン文献[7]の用語を使用します。
Building blocks are defined in RFC 3048 [6]. This document is a product of the IETF RMT WG and follows the general guidelines provided in RFC 3269 [3].
ビルディングブロックは、RFC 3048で定義されている[6]。この文書は、IETF RMT WGの産物である[3] RFC 3269に設けられた一般的なガイドラインに従います。
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 RFC 2119 [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[2]。
Statement of Intent
主旨書
This memo contains part of the definitions necessary to fully specify a Reliable Multicast Transport (RMT) protocol in accordance with RFC 2357 [5]. As per RFC 2357, the use of any reliable multicast protocol in the Internet requires an adequate congestion control scheme.
このメモは、完全にRFC 2357に従って高信頼マルチキャストトランスポート（RMT）プロトコルを指定するために必要な定義の一部を含む[5]。 RFC 2357に従って、インターネットの任意の信頼できるマルチキャストプロトコルの使用は、適切な輻輳制御方式を必要とします。
While waiting for such a scheme to be available, or for an existing scheme to be proven adequate, the RMT working group publishes this Request for Comments in the "Experimental" category.
このようなスキームを待っているが利用できるようにする、または既存のスキームのための十分な証明されている間、RMTワーキンググループは、「実験」カテゴリ内のコメントのためにこの要求を発行しています。
It is the intent of RMT to re-submit this specification as an IETF Proposed Standard as soon as the above condition is met.
すぐに上記の条件が満たされたとしてIETFのProposed Standardとして、この明細書を再提出するRMTの意図です。
This section specifies FEC Encoding IDs 0 and 130 and the associated FEC Payload ID formats and the specific information in the corresponding FEC Object Transmission Information. The FEC scheme associated with FEC Encoding ID 0 is Fully-Specified whereas the FEC schemes associated with FEC Encoding ID 130 are Under-Specified.
このセクションは、FEC符号化IDは0と130と関連するFECペイロードIDフォーマットと対応するFECオブジェクト伝送情報内の特定情報を特定します。 FEC符号化ID 130に関連付けられたFECスキームの下、指定されているのに対し、FEC符号化ID 0に関連付けられたFECスキームは、完全に指定されています。
FEC Encoding IDs 0 and 130 have the same FEC Payload ID format, which is described in the following subsection. The FEC Object Transmission Information for FEC Encoding IDs 0 and 130 is different, and is described in the subsequent two subsections.
FEC符号化IDは0と130は、以下のサブセクションで説明されているのと同じFECペイロードIDフォーマットを有します。 FEC符号化IDは0と130のためのFECオブジェクト伝送情報は異なり、後続の2つのサブセクションに記載されています。
The FEC Payload ID for FEC Encoding IDs 0 and 130 is composed of a Source Block Number and an Encoding Symbol ID structured as follows:
FEC符号化IDは0と130のための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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 16-bit Source Block Number 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.
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 the source block is processed at the transport layer by the sender, the network transit time for packets, and the amount of time the source block is processed at the transport layer by a receiver. This allows the receiver to clearly decide which packets belong to which source block.
非ユニークなSBNモードはその後、ソースブロック番号にソースブロックからのマッピングを使用する場合は、アウトオブバンド受信機に伝え、そしてどのようにこれが行われるが、この文書の範囲外であるしなければなりません。このマッピングは、ソースブロックの送信順序によって決定される、例えば、暗黙的であってもよいです。非ユニークなSBNモードでは、同じソースブロック番号にマッピングされた二つの異なるソースブロックのパケットがソースブロックの輸送時間よりも短い時間の間隔内に送るべきではありません。ソースブロックの輸送時間は、ソースブロックが送信者によってトランスポート層で処理される時間の量、パケットのネットワーク通過時間、およびソースブロックは、受信機によってトランスポート層で処理される時間の量を含みます。これは明らかに、どのソースブロックに属するパケットを決定する受信機を可能にします。
The 16-bit Encoding Symbol ID 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 for FEC Encoding ID 0 are specified in Section 3. The exact details of the correspondence between Encoding Symbol IDs and the encoding symbol(s) in the packet payload for FEC Encoding ID 130 are dependent on the particular encoding algorithm used as identified by the FEC Encoding ID and by the FEC Instance ID.
16ビットの符号化シンボルIDは、ソースブロックから生成された特定の符号化シンボルはパケットペイロードで運ばれているかを識別する。符号化シンボルIDとFEC符号化ID 0のパケットペイロードにおける符号化シンボルの対応関係の正確な詳細はセクション3で指定されたパケットのペイロードに符号化シンボルIDおよび符号化シンボル（S）との対応関係の正確な詳細FEC符号化のためのID 130は、FEC符号化IDによって及びFECインスタンスIDによって識別されるように使用される特定の符号化アルゴリズムに依存しています。
This subsection reserves FEC Encoding ID 0 for the Compact No-Code FEC scheme described in this subsection and in Section 3. This is a Fully-Specified FEC scheme that is primarily intended to be used for simple interoperability testing between different implementations of protocol instantiations that use the FEC building block. The value of this FEC scheme is that no FEC encoding or decoding is required to implement it and therefore it is easy to test interoperability between protocols that may use different proprietary FEC schemes in production in their first implementations.
このサブセクションでは、セクション3に記載のコンパクト無コードFECスキームのための本項準備FEC符号化ID 0は、これは、主にそのプロトコルのインスタンスの異なる実装の間の単純な相互運用性テストに使用されることが意図されている完全に指定されたFEC方式でありますFECビルディングブロックを使用。このFECスキームの値は、FEC符号化または復号化は、それを実現するために必要とされないことがあり、したがって、彼らの最初の実装では生産に異なる独自のFECスキームを使用することができるプロトコルの間の相互運用性をテストすることは容易です。
The FEC Payload ID format for FEC Encoding ID 0 is described in Subsection 2.1. The FEC Object Transmission Information has the following specific information:
FEC符号化ID 0のためのFECペイロードIDフォーマットは、サブセクション2.1に記載されています。 FECオブジェクト伝送情報は、以下の具体的な情報があります。
o The FEC Encoding ID 0.
FEC符号化ID 0、O。
o For each source block of the object, the length in bytes of the encoding symbol carried in the packet payload. This length MUST be the same for all packets sent for the same source block, but MAY be different for different source blocks in the same object.
Oオブジェクトの各ソースブロックについて、符号化シンボルのバイト単位の長さは、パケットペイロードで運ばれました。この長さは、同じソースブロックのため送信されるすべてのパケットに対して同一でなければならないが、同じオブジェクトの異なるソースブロックのために異なっていてもよいです。
o For each source block of the object, the length of the source block in bytes. Typically, each source block for the object has the same length and thus only one length common to all source blocks need be communicated, but this is not a requirement. For convenience, the source block length MAY be a multiple of the length of the encoding symbol carried in one packet payload.
オブジェクトの各ソースブロック、バイト内のソースブロックの長さについては、O。典型的には、オブジェクトの各ソースブロックは同じ長さを有し、したがって、すべてのソースブロックに共通の唯一の長さを伝達することが必要とするが、これは必要条件ではありません。便宜上、ソースブロック長は1つのパケットペイロードで運ばれた符号化シンボルの長さの倍数であってもよいです。
How this out-of-band information is communicated is outside the scope of this document.
どのようにこの帯域外の情報が伝達され、この文書の範囲外です。
Other information, such as the object length and the number of source blocks of the object for an object of known length may be needed by a receiver to support some delivery models, i.e., reliable bulk data delivery.
そのようなオブジェクトの長さと既知の長さのオブジェクトのオブジェクトのソースブロックの数のような他の情報は、いくつかの配信モデル、すなわち、信頼性の高いバルクデータ配信をサポートするために受信機により必要とされるかもしれません。
This subsection reserves FEC Encoding ID 130 for the Compact FEC scheme that is described in this subsection. This 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符号化ID 130。これは、アンダー指定FECスキームです。このFECスキームは、各パケットのペイロード及びAに配置された非自明なFEC符号化（つまりアンダー指定されている）符号化シンボル（単数または複数）を生成するために使用されてもよいことを除いて、コンパクト無コードFEC方式に精神に類似していますFEC復号器を対応する受信したパケットからソースブロックを生成するために使用されてもよいです。
The FEC Payload ID format for FEC Encoding ID 0 is described in Subsection 2.1. The FEC Object Transmission Information has the following specific information:
FEC符号化ID 0のためのFECペイロードIDフォーマットは、サブセクション2.1に記載されています。 FECオブジェクト伝送情報は、以下の具体的な情報があります。
o The FEC Encoding ID 130.
FEC符号化ID 130 O。
o The FEC Instance ID associated with the FEC Encoding ID 130 to be used.
O FEC符号化ID 130に関連付けられたFECインスタンスIDを使用します。
o For each source block of the object, the aggregate length of the encoding symbol(s) carried in one packet payload. This length MUST be the same for all packets sent for the same source block, but MAY be different for different source blocks in the same object.
Oオブジェクトの各ソースブロックについて、符号化シンボル（S）の総計長さが1つのパケットペイロードで運ばれました。この長さは、同じソースブロックのため送信されるすべてのパケットに対して同一でなければならないが、同じオブジェクトの異なるソースブロックのために異なっていてもよいです。
o For each source block of the object, the length of the source block in bytes. Typically, each source block for the object has the same length and thus only one length common to all source blocks need to be communicated, but this is not a requirement. For convenience, the source block length MAY be a multiple of the aggregate length of the encoding symbol(s) carried in one packet payload.
オブジェクトの各ソースブロック、バイト内のソースブロックの長さについては、O。典型的には、オブジェクトの各ソースブロックは同じ長さを有し、従って、唯一の長さのすべてのソースブロックに共通に通信される必要があるが、これは必要条件ではありません。便宜上、ソースブロック長は1つのパケットペイロードで運ばれた符号化シンボル（単数または複数）の凝集体長さの倍数であってもよいです。
How this out-of-band information is communicated is outside the scope of this document.
どのようにこの帯域外の情報が伝達され、この文書の範囲外です。
Other information, such as the object length and the number of source blocks of the object for an object of known length may be needed by a receiver to support some delivery models, i.e., reliable bulk data delivery.
そのようなオブジェクトの長さと既知の長さのオブジェクトのオブジェクトのソースブロックの数のような他の情報は、いくつかの配信モデル、すなわち、信頼性の高いバルクデータ配信をサポートするために受信機により必要とされるかもしれません。
In this section we describe a Fully-Specified FEC scheme corresponding to FEC Encoding ID 0. The primary purpose for introducing these FEC schemes is to allow simple interoperability testing between different implementations of the same protocol instantiation that uses the FEC building block.
このセクションでは、これらのFECのスキームを導入するための第一の目的は、FECビルディングブロックを使用し、同じプロトコルのインスタンスの異なる実装の間の単純な相互運用性テストを可能にすることでFEC符号化ID 0に対応する完全に指定されたFECスキームが記載されています。
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. The FEC Payload ID consists of two fields, the 16-bit Source Block Number and the 16-bit Encoding Symbol ID, as described in Subsection 2.1. The relative lengths of these fields were chosen for their similarity with the corresponding fields of the FEC Payload ID associated with FEC Encoding ID 130, and because of this testing interoperability of the FEC scheme associated with FEC Encoding ID 0 provides a first basic step to testing interoperability of an FEC scheme associated with FEC Encoding ID 130.
コンパクト無コードFEC方式は、FEC符号化または復号化を必要としません。代わりに、各符号化シンボルは、オブジェクトのソースブロックの連続したバイトで構成されています。サブセクション2.1に記載されているようにFECペイロードIDは、二つのフィールド、16ビットのソースブロック番号と16ビットの符号化シンボルIDで構成されています。これらのフィールドの相対的な長さは、FEC符号化ID 130に関連付けられたFECペイロードIDの対応するフィールドとの類似性のために選択され、そしてためFEC符号化ID 0に関連付けられたFECスキームのこのテストの相互運用性試験の最初の基本的なステップを提供しました。 FEC符号化ID 130に関連付けられたFECスキームの相互運用。
Subsection 2.1. describes mapping between source blocks of an object and Source Block Numbers. The next two subsections describe the details of how the Compact No-Code FEC scheme operates for each source block of an object. These subsections are not meant to suggest a particular implementation, but just to illustrate the general algorithm through the description of a simple, non-optimized implementation.
サブセクション2.1。オブジェクトのソースブロックとソースブロック番号の間のマッピングを記述します。次の2つのサブセクションは、コンパクト無コードFECスキームは、オブジェクトの各ソースブロックの動作方法の詳細を記載しています。これらのサブセクションは、特定の実装を提案することではなく、単純な、非最適化実装の記述を通じて一般的なアルゴリズムを説明することを意図するものではありません。
Let X > 0 be the length of a source block in bytes. The value of X is 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バイト内のソースブロックの長さとします。 Xの値は、FECオブジェクト伝送情報の一部であり、この情報は、受信機に伝達されるどのようにこの文書の範囲外です。
Let L > 0 be the length of the encoding symbol contained in the payload of each packet. There are several possible ways the length of the encoding symbol L can be communicated to the receiver, and how this is done is outside the scope of this document. As an example, a sender could fix the packet payload length to be L in order to place the encoding symbol of length L into the packet, and then a receiver could infer the value of L from the length of the received packet payload. It is REQUIRED that L be the same for all packets sent for the same source block but MAY be different for different source blocks within the same object.
L> 0は、各パケットのペイロードに含まれる符号化シンボルの長さとします。そこエンコーディングシンボルLの長さは、受信機に伝達することができるいくつかの可能な方法があり、これはどのように行われるが、この文書の範囲外です。一例として、送信者がパケットに長さLの符号化シンボルを配置するためにLであると、パケットペイロードの長さを固定することができ、その後、受信機は、受信したパケットのペイロードの長さからLの値を推測することができました。なお、Lは、同じソースブロックのため送信されるすべてのパケットに対して同じであることが必要であるが、同じオブジェクト内の異なるソースブロックに対して異なっていてもよいです。
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 of refer to the companion document [7] for general advice.
送信者がソースブロックから送信する符号化シンボルを生成する方法で上記のルールを超えた制限はありません。しかし、の実装は、一般的なアドバイスのための仲間ドキュメント[7]を参照することをお勧めします。
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 L = 1,000、例えば、（例えば、合計パケットサイズがMTUを超えていないことを確認）、そのソースブロック長さXよりも小さいです。ランダム間隔[0..N-1]で選択された値にYを初期化します。送信するソースブロックの各パケットのために、以下の手順を繰り返します。
o If Y < N-1 then generate the encoding symbol consisting of the L bytes of the source block numbered L*Y through L*(Y+1)-1.
O Y <N-1は、L×（Y + 1）-1を介してソースブロック番号のL * YのLバイトからなる符号化シンボルを生成した場合。
o If Y = N-1 then generate the encoding symbol consisting of the last X - L*(N-1) bytes of the source block numbered L*(N-1) through X-1 followed by L*N - X padding bytes of zeroes.
L * Nに続いてX-1を介してL×（N-1）番目のソースブロックのL *（N-1）バイト - - XパディングO Y = N-1が最後のXからなる符号化シンボルを生成する場合ゼロのバイト。
o 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、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 describe 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 received out-of-band as part of the FEC Object Transmission Information to determine the length X in bytes of the source block, and allocates space for the X bytes that the source block requires. The receiver also computes the length L of the encoding symbol in the payload of the packet by substracting the packet header length from the total length of the received packet (and the receiver checks that this length is the same in each subsequent received packet from the same source block). 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 FEC Payload ID of the packet. If Y < N-1 then the receiver copies the L bytes of the encoding symbol into bytes numbered L*Y through L*(Y+1)-1 of the space reserved for the source block. If Y = N-1 then the receiver copies the first X - L*(N-1) bytes of the encoding symbol into bytes numbered L*(N-1) through X-1 of the space reserved for the source block. In either case, the receiver sets RECEIVED[Y] = true. At each point in time, the receiver has successfully recovered bytes L*Y through L*(Y+1)-1 of the source block for all Y in the interval [0..N-1] for which RECEIVED[Y] is true. If all N entries of RECEIVED are true then the receiver has recovered the entire source block.
以下の手順は、カルーセルの手順を使用して上述されている送信者からのソースブロックのパケットを受け取ることに基づいてソースブロックを回復するために受信機に推奨されます。受信機は、受信したパケットがFECペイロードIDで運ばソースブロック番号によって生成されたブロックするソースから決定することができます。ソースブロックの最初のFECペイロードIDを受信すると、受信機は、ソースブロック長は、ソースブロックのバイト単位の長さXを決定するためにFECオブジェクト伝送情報の一部として、アウトオブバンド受信使用し、そしてためのスペースを割り当てますXは、ソースブロックが必要とするバイト。受信機はまた、この長さは同じから後続の各受信したパケットに同一であることを受信されたパケット（及び受信チェックの全体の長さからパケットヘッダ長をsubstractingによりパケットのペイロードに符号化シンボルの長さLを算出しますソースブロック）。最も近い整数に切り上げN = X / Lを算出した後、受信機は、ブール配列は、受信符号化シンボルを追跡するためにfalseに初期化され、すべてのN個のエントリと[0..N-1]は受信割り当てます。受信機であれば、まだ偽に、またはアプリケーションがこのソースブロックをあきらめると他のソースブロックに移動することを決定するまで、設定受信中の少なくとも1つのエントリがあるように、ソースブロックのためのパケットを受信し続けます。それぞれについて、以下のようにソースブロックを回復を助けるために取られるステップである（最初のパケットを含む）は、ソースブロックのためのパケットを受信しました。 Yは、パケットのFECペイロードID内の符号化シンボルIDの値とします。 Y場合<N-1、レシーバコピー符号化シンボルのLバイトのL *を介してL * Y（Y + 1）のソースブロックのために予約領域の-1番のバイトに。 Yは、= N-1の場合、受信機コピー最初のX - の符号化シンボルのL×（N-1）バイトのX-1ソースブロックのために予約空間のを通してL×（N-1）番のバイトに変換します。いずれの場合においても、受信機セットは、真= [Y]を受けました。各時点で、受信機は、バイトLを正常に回復した*間隔内のすべてのYのソースブロックのL *を介してY（Y + 1）-1 [0..N-1]れるために受信[Y]であります真。 RECEIVEDのすべてのN個のエントリが真である場合、受信機は、全ソースブロックを回復しました。
The following subsections outline some usage examples for FEC Encoding IDs 0 and 130.
以下のサブセクションでは、FEC符号化IDが0と130のためのいくつかの使用例を概説します。
One possible delivery model that can be supported using any FEC scheme described in this document is reliable bulk data delivery. In this model, one or more potentially large objects are delivered reliably to potentially multiple receivers using multicast. For this delivery model the unique SBN mode is often used. Using this mode the maximum length of an object that can be delivered is at most the number of possible source blocks times the maximum length of a source block. If the aggregate length of encoding symbols carried in a packet payload is L bytes then the maximum length of a source block is the number of distinct Encoding Symbol IDs times L, or 2^16 * L for FEC Encoding IDs 0 and 130. If for example L = 1 KB then the length of a source block can be up to around 65 MB. However, in practice the length of the source block is usually shorter than the number of distinct Encoding Symbol IDs times L, and thus generally the length of a source block is a fraction of 65 MB. Since the number of distinct Source Block Numbers is 2^16, for this example an object can be more than a terabyte.
本資料に記載されたFECスキームを使用してサポートすることができる一つの可能な配信モデルは、信頼性の高い大容量データ配信です。このモデルでは、一つ以上の潜在的に大きなオブジェクトは、マルチキャストを使用して、潜在的に複数の受信機に確実に送達されます。この配信モデルのためのユニークなSBNモードが使用されることが多いです。このモードを送達することができるオブジェクトの最大長さを使用することが可能とソースブロック回数ソースブロックの最大長以下です。パケットペイロードで運ばれた符号化シンボルの集合体の長さがLバイトである場合、ソースブロックの最大長が異なる符号化シンボルIDの回数L、又はFEC符号化IDが0と130のための場合は2 ^ 16×Lの数であります= 1キロバイト例Lは、ソースブロックの長さは約65 MBにまですることができます。しかし、実際には、ソースブロックの長さは、異なる符号化シンボルIDの回数Lの数よりも通常短いので、一般的にソースブロックの長さは、65メガバイトの割合です。異なるソースブロック番号の数が2 ^ 16であるため、この例の目的は、テラバイト以上とすることができます。
The non-unique SBN mode of delivery can also be effectively used for reliably delivering large object. In this case, the length of the object delivered could be arbitrarily large, depending on the out-of-band mapping between source blocks and Source Block Numbers.
配達の非ユニークなSBNモードも効果的に確実に大きなオブジェクトを送達するために使用することができます。この場合には、配信対象の長さは、ソースブロック及びソースブロック番号との間の帯域外マッピングに応じて、任意の大きさであってもよいです。
Another possible delivery model that can be supported using FEC Encoding ID 0 or 130 is block-stream delivery of an object. In this model, the source blocks of a potentially indeterminate length object are to be reliably delivered in sequence to one or multiple receivers. Thus, the object could be partitioned into source blocks on-the-fly at the sender as the data arrives, and all packets generated for one source block are sent before any packets are sent for the subsequent source block. In this example, all source blocks could be of the same length and this length could be communicated out-of-band to a receiver before the receiver joins the session. For this delivery model it is not required that the Source Block Numbers for all source blocks are unique. However, a suggested usage is to use all 2^16 Source Block Numbers for consecutive source blocks of the object, and thus the time between reuse of a Source Block Number is the time it takes to send the packets for 2^16 source blocks.
FEC符号化ID 0または130を使用してサポートすることができる別の可能な配信モデルは、オブジェクトのブロックストリームの配信です。このモデルでは、潜在的に不定長さオブジェクトのソースブロックを確実に一つまたは複数の受信機に順次配信されます。したがって、データが到着するように、オブジェクトは、送信者にオンザフライソースブロックに分割することができ、任意のパケットが後続のソースブロックのため送信される前に一つのソースブロックに対して生成されたすべてのパケットが送信されます。この例では、全てのソースブロックは同じ長さとすることができ、受信機はセッションに参加する前に、この長さは、受信機へのアウトオブバンド通信することができました。この配信モデルの場合は、すべてのソースブロックのソースブロック番号が一意であることを必要とされていません。しかし、提案の使用は、オブジェクトの連続したソースブロックのすべての2 ^ 16のソースブロック番号を使用することであり、したがって、ソースブロック番号の再利用との間の時間は、それが2 ^ 16のソースブロックのためのパケットを送信するのにかかる時間です。
This delivery model can be used to reliably deliver an object to one or multiple receivers, using either an ACK or NACK based acknowledgement based scheme for each source block. As another example the sender could send a fixed number of packets for each source block without any acknowledgements from receivers, for example in a live streaming without feedback application.
この配信モデルでは、確実に各ソースブロックの方式をベースACKまたはNACKベースの肯定応答のいずれかを使用して、一つまたは複数の受信機にオブジェクトを配信するために使用することができます。別の例として、送信側はフィードバック印加せずライブストリーミング、例えば、受信機からのいかなる肯定応答せず、各ソースブロックのパケットの固定された数を送信することができます。
The security considerations for this document are the same as they are for RFC 3452 [4].
この文書のセキュリティ上の考慮事項は、彼らがRFC 3452 [4]のためのものと同じです。
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 RFC 3452 [4]. This document assigns the Fully-Specified FEC Encoding ID 0 under the ietf:rmt:fec:encoding name-space to "Compact No-Code". The FEC Payload ID format and corresponding FEC Object Transmission Information associated with FEC
FEC符号化IDとFECインスタンスIDの値は、IANA登録の対象となっています。 IANAの考慮の一般的なガイドライン彼らは、この文書に適用されるために、RFC 3452 [4]を参照してください。このドキュメントは、IETFの下で完全に指定されたFEC符号化ID 0を割り当てます。RMT：FEC：「コンパクト無規範」に名前空間をコードします。 FECペイロードIDフォーマットおよびFECに関連付けられた対応するFECオブジェクト伝送情報
Encoding ID 0 is described in Subsections 2.1 and 2.2, and the corresponding FEC scheme is described in Section 3.
符号化ID 0は、サブセクション2.1および2.2に記載され、対応するFECスキームは、セクション3に記載されています。
This document assigns the Under-Specified FEC Encoding ID 130 under the ietf:rmt:fec:encoding name-space to "Compact FEC". The FEC Payload ID format and corresponding FEC Object Transmission Information associated with FEC Encoding ID 130 are described in Subsections 2.1 and 2.3.
このドキュメントは、IETFの下にアンダー指定されたFEC符号化ID 130を割り当て：RMT：FEC：「コンパクトFEC」に名前空間をコードします。 FECペイロードIDフォーマットとFEC符号化ID 130に関連付けられたFECオブジェクト伝送情報を対応するサブセクション2.1および2.3に記載されています。
As FEC Encoding ID 130 is Under-Specified, a new "FEC Instance ID" sub-name-space must be established, in accordance to RFC 3452. Hence this document also establishes a new "FEC Instance ID" registry named
FEC符号化ID 130が下に、指定されているとして、新しい「FECインスタンスID」サブ名前空間は、RFC 3452.によれば、確立されなければならないしたがって、この文書では、という名前の新しい「FECインスタンスID」のレジストリを設定します
ietf:rmt:fec:encoding:instance:130
IETF：RMT：FEC：符号：インスタンス：130
and scoped by
とによってスコープ
ietf:rmt:fec:encoding = 130 (Compact FEC)
IETF：RMT：FEC：エンコーディング= 130（コンパクトFEC）
As per RFC 3452, the values that can be assigned within ietf:rmt:fec:encoding:instance:130 are non-negative numeric indices. Assignment requests are granted on a "First Come First Served" basis. RFC 3452 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:130.
RFC 3452に従って、IETF内で割り当て可能な値：RMT：FEC：符号：インスタンス：130は、負の数値のインデックスです。割り当て要求は「まず第一に役立っ是非」に基づき付与されます。 RMT：FEC：エンコーディング：インスタンス名空間RFC 3452は、一般的なIETF内の割り当てのために満たさなければならない追加の基準を指定します。これらの基準はまた、IETFに適用：RMT：FEC：符号：インスタンス：130。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation Documents", RFC 3269, April 2002.
[3] Kermode、R.とL. Vicisano、RFC 3269、2002年4月 "信頼できるマルチキャストトランスポート（RMT）ビルディングブロックとプロトコルのインスタンス文書のための著者のガイドライン"。
[4] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002.
[4]ルビー、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.及びJ.クロウクロフト、 "前方誤り訂正（FEC）ビルディングブロック"、RFC 3452、2002年12月。
[5] Mankin, A., Romanow, A., Bradner, S. and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[5]マンキン、A.、Romanow、A.、RFC 2357、1998年6月ブラドナー、S.およびV.パクソン、 "信頼できるマルチキャストトランスポート及びアプリケーションプロトコルを評価するためのIETF基準"。
[6] 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.
[6] Whetten、B.、Vicisano、L.、Kermode、R.、ハンドレー、M.、フロイド、S.及びM.ルビー、 "一対多バルクデータ転送のための信頼できるマルチキャストトランスポート・ビルディング・ブロック"、 RFC 3048、2001年1月。
[7] 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.
[7]ルビー、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.及びJ.クロウクロフト、 "信頼できるマルチキャストの前方誤り訂正（FEC）の使用"、RFC 3453、 2002年12月。
Michael Luby Digital Fountain, Inc. 39141 Civic Center Drive Suite 300 Fremont, CA 94538
マイケル・ルビーデジタル泉社39141シビックセンタードライブスイート300フリーモント、CA 94538
EMail: luby@digitalfountain.com
メールアドレス：luby@digitalfountain.com
Lorenzo Vicisano cisco Systems, Inc. 170 West Tasman Dr., San Jose, CA, USA, 95134
ロレンツォVicisanoシスコシステムズ株式会社170西タスマン博士は、サンノゼ、CA、USA、95134
EMail: lorenzo@cisco.com
メールアドレス：lorenzo@cisco.com
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利、ライセンスおよび制限があり、そこに記載された以外、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。