[要約] RFC 3695は、コンパクトな転送エラー訂正（FEC）スキームに関する要約と目的を提供します。このRFCの目的は、効率的で信頼性の高いエラー訂正手法を提案し、ネットワーク通信の品質を向上させることです。
Network Working Group M. Luby
Request for Comments: 3695 Digital Fountain
Category: Experimental L. Vicisano
Cisco
February 2004
Compact Forward Error Correction (FEC) Schemes
コンパクトフォワードエラー補正（FEC）スキーム
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（c）The Internet Society（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.
このドキュメントでは、RFC 3452に記載されているFECスキームを補足するいくつかの前方エラー補正（FEC）スキームを導入します。これらの追加のFECスキームの主な利点は、よりコンパクトなFECペイロードIDを使用して大きなオブジェクトの信頼できるバルク配信用に設計されていることです。それらを使用して、不確定な長さのオブジェクトのブロックを順番に配信できます。したがって、彼らはより少ないパケットヘッダーのオーバーヘッドで、より柔軟に異なる配信モデルをサポートします。
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エンコードID 0に対応する完全に指定されたFECスキームについても説明しています。この完全に指定された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ビルディングブロックで説明されているFECエンコードID 128および129に対応するFECスキームを補足するFECエンコードID 0および130に対応する2つの新しいフォワードエラー補正（FEC）スキームについて説明します[4]。
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 128がRFC 3452 [4]で定義されているFECスキームに類似しています。ただし、FECペイロードIDが半分の長さです。これが、これらの新しい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が提供するバイトストリーム配信とスピリットで類似していますが、配信単位がデータのバイトではなくデータのブロックであることを除きます。ビルディングブロックの精神（RFC 3048 [6]を参照）では、このドキュメントで説明するFECスキームを使用して、他のサービスモデルにも信頼性を提供できます。
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.
2つの新しいFECエンコーディングID 0および130はセクション2で説明されており、これはFECビルディングブロックのセクション5をサプリメントします[4]。このドキュメントのセクション3では、FECエンコードID 0に対応する完全に指定されたFECスキームについて説明します。この完全に指定されたFECスキームは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の製品であり、RFC 3269 [3]で提供される一般的なガイドラインに従います。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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提案標準として再提出することは、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 0に関連付けられたFECスキームは完全に指定されていますが、FECエンコードID 130に関連付けられた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形式があります。ID 0と130のFECエンコードの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ビットのソースブロック番号は、パケットのペイロード内のエンコードシンボルが生成されるオブジェクトのソースブロックを識別するために使用されます。可能なモードは2つあります。一意の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モードでは、同じソースブロック番号にマッピングされた2つの異なるソースブロックのパケットは、ソースブロックの輸送時間よりも短い時間間隔内で送信しないでください。ソースブロックの輸送時間には、ソースブロックが送信者によって輸送層で処理される時間、パケットのネットワークトランジット時間、およびソースブロックがレシーバーによって輸送層で処理される時間が含まれます。これにより、受信者はどのパケットがどのソースブロックに属しているかを明確に決定できます。
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は、ソースブロックから生成された特定のエンコードシンボルがパケットペイロード内で運ばれるかを識別します。EncodingシンボルIDとFECエンコードID 0のパケットペイロードのエンコードシンボルとの間の対応の正確な詳細は、セクション3で指定されています。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.
o FECエンコーディングID 0。
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つの長さのみを通知する必要がありますが、これは要件ではありません。便利なため、ソースブロックの長さは、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スキームは、Compact No-Code FECスキームと精神的に類似しています。ただし、非自明のFECエンコーディング（不足している）を使用して、各パケットのペイロードに配置されたエンコードシンボルとAを生成することができます。対応する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.
o FECエンコードID130。
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 オブジェクトの各ソースブロックについて、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つだけ通信する必要がありますが、これは要件ではありません。便利なため、ソースブロックの長さは、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エンコードID 0に対応する完全に指定されたFECスキームについて説明します。これらのFECスキームを導入するための主な目的は、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エンコードまたはデコードは必要ありません。代わりに、各エンコードシンボルは、オブジェクトのソースブロックの連続バイトで構成されています。FECペイロードIDは、サブセクション2.1で説明されているように、16ビットソースブロック番号と16ビットエンコードシンボルIDの2つのフィールドで構成されています。これらのフィールドの相対長さは、FECエンコードID130に関連付けられた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を最も近い整数まで丸めます。パケットのペイロードで運ばれるエンコードシンボルは、ソースブロックの連続した部分で構成されています。ソースブロックは、長さが各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 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.
次のカルーセル手順は、送信者が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 consisting of the L bytes of the source block numbered L*Y through L*(Y+1)-1.
o y <n-1の場合、l*yからl*（y 1）-1の番号が付けられたソースブロックの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.
o y = n-1の場合、x-1からl*n-xパディングバイトの数字L*（n-1）の最後のx-l*（n-1）バイトで構成されるエンコード記号を生成します。ゼロの。
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 = 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に掲載されたソースブロック番号によって受信されたパケットAが生成されたソースブロックからどのソースブロックが生成されたかを決定できます。ソースブロックの最初のFECペイロードIDを受信すると、受信者はFECオブジェクトトランスミッション情報の一部として帯域外のソースブロックの長さを使用して、ソースブロックのバイト単位の長さxを決定し、スペースを割り当てます。ソースブロックが必要とするXバイト。受信機はまた、受信したパケットの全長からパケットヘッダーの長さを覆うことにより、パケットのペイロードにエンコードシンボルの長さlを計算します（および受信者は、この後続の受信したパケットでこの長さが同じであることを確認します。ソースブロック）。n = x/lを最寄りの整数に丸めて計算した後、受信機は受信した[0..N-1]をfalseに初期化して受信したエンコードシンボルを追跡して、受信した[0..N-1]を割り当てます。受信者は、少なくとも1つのエントリがfalseに設定されているか、アプリケーションがこのソースブロックをあきらめて他のソースブロックに移動することを決定するまで、ソースブロックのパケットを受信し続けます。ソースブロック（最初のパケットを含む）の受信パケットごとに、ソースブロックを回復するのに役立つ手順は次のとおりです。パケットのFECペイロードID内のエンコードシンボルIDの値とします。y <n-1の場合、レシーバーは、エンコードシンボルのlバイトを、ソースブロックに予約されたスペースのl*yからl*yからl*（y 1）-1に番号付けされたバイトにコピーします。y = n-1の場合、受信機は、ソースブロックに予約されたスペースのx-1を介して、エンコードシンボルの最初のx-l*（n-1）バイトをl*（n-1）に番号付けされたバイトにコピーします。どちらの場合でも、受信者セットは[y] = trueを受信します。各時点で、受信機は、受信した[y]が真である間隔[0..n-1]のすべてのyのソースブロックのl*yからl*yからl*yからl*yからl*yから正常に回復しました。。受信のすべてのnエントリが真である場合、レシーバーはソースブロック全体を回復しました。
The following subsections outline some usage examples for FEC Encoding IDs 0 and 130.
次のサブセクションでは、ID 0および130をエンコードするFECのいくつかの使用例を概説します。
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スキームを使用してサポートできる1つの可能な配信モデルは、信頼できるバルクデータ配信です。このモデルでは、マルチキャストを使用して潜在的に複数のレシーバーに1つ以上の潜在的に大きなオブジェクトが確実に配信されます。この配信モデルでは、一意のSBNモードがよく使用されます。このモードを使用すると、配信できるオブジェクトの最大長は、せいぜいソースブロックの数の数の数の最大長さのソースブロックの長さです。パケットペイロードで運ばれるエンコードシンボルの集計長の長さはLバイトです。ソースブロックの最大長さは、IDS 0および130のFECの場合、個別のエンコードシンボルIDS時間Lの数、または2^16 * Lの場合です。例l = 1 kbソースブロックの長さは最大約65 MBになります。ただし、実際には、ソースブロックの長さは通常、異なるエンコードシンボルIDS時間Lの数よりも短く、したがって、ソースブロックの長さは65 MBの一部です。異なるソースブロック数の数は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を使用してサポートできる別の可能な配信モデルは、オブジェクトのブロックストリーム配信です。このモデルでは、潜在的に不確定な長さのオブジェクトのソースブロックは、1つまたは複数の受信機に順番に確実に配信されます。したがって、データが到着すると、オブジェクトを送信者のフライでソースブロックに分割でき、1つのソースブロックに生成されたすべてのパケットが送信される前に送信されます。この例では、すべてのソースブロックが同じ長さである可能性があり、この長さは、受信機がセッションに参加する前にレシーバーに帯域外に通知することができます。この配信モデルでは、すべてのソースブロックのソースブロック番号が一意であることは必須ではありません。ただし、推奨される使用法は、オブジェクトの連続したソースブロックに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ベースの確認ベースのスキームを使用して、1つまたは複数の受信機にオブジェクトを確実に配信できます。別の例として、送信者は、フィードバックアプリケーションのないライブストリーミングなど、レシーバーからの確認なしに、各ソースブロックに固定数のパケットを送信できます。
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 Encoding ID 0 is described in Subsections 2.1 and 2.2, and the corresponding FEC scheme is described in Section 3.
FECエンコードIDとFECインスタンスIDの値は、IANA登録の対象となります。IANAの考慮事項に関する一般的なガイドラインについては、この文書に適用されます。RFC3452[4]を参照してください。このドキュメントは、IETF：RMT：FEC：名前空間を「Compact No-Code」にエンコードする完全に指定されたFECエンコードID 0を割り当てます。FECエンコードID 0に関連付けられたFECペイロードID形式と対応するFECオブジェクト伝送情報は、サブセクション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：RMT：FEC：名前空間を「コンパクトFEC」にエンコードする下で、不足しているFECエンコードID 130を割り当てます。FECエンコードID 130に関連付けられたFECペイロードID形式と対応する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が不足しているため、RFC 3452に従って新しい「FECインスタンスID」サブ名スペースを確立する必要があります。
ietf:rmt:fec:encoding:instance:130
and scoped by
そして、によってスコープされました
ietf:rmt:fec:encoding = 130 (Compact 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：Encoding：Instance：130内で割り当てることができる値は、非陰性数値インデックスです。割り当てリクエストは、「First Come First Fort」ベースで付与されます。RFC 3452汎用IETF内の割り当てに対して満たさなければならない追加の基準を指定します：RMT：FEC：エンコード：インスタンス名スペース。これらの基準は、IETF：RMT：FEC：エンコード：インスタンス：130にも適用されます。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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、「信頼できるマルチキャストトランスポート（RMT）ビルディングブロックとプロトコルインスタンス化ドキュメントの著者ガイドライン」、RFC 3269、2002年4月。
[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] Luby、M.、Vicisano、L.、Gemmell、J.、Rizzo、L.、Handley、M。and J. Crowcroft、「Forward Error Correction（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] Mankin、A.、Romanow、A.、Bradner、S。and V. Paxson、「信頼できるマルチキャストトランスポートおよびアプリケーションプロトコルを評価するためのIETF基準」、RFC 2357、1998年6月。
[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.、Handley、M.、Floyd、S。、およびM. Luby、「1対Many Bulk-Data転送用の信頼できるマルチキャスト輸送ビルディングブロック」、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] Luby、M.、Vicisano、L.、Gemmell、J.、Rizzo、L.、Handley、M。、およびJ. Crowcroft、「信頼できるマルチキャストでのフォワードエラー補正（FEC）の使用」、RFC 3453、2002年12月。
Michael Luby Digital Fountain, Inc. 39141 Civic Center Drive Suite 300 Fremont, CA 94538
Michael Luby Digital Fountain、Inc。39141 Civic Center Drive Suite 300 Fremont、CA 94538
EMail: luby@digitalfountain.com
Lorenzo Vicisano cisco Systems, Inc. 170 West Tasman Dr., San Jose, CA, USA, 95134
Lorenzo Vicisano Cisco Systems、Inc。170 West Tasman Dr.、San Jose、CA、USA、95134
EMail: 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）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。