[要約] RFC 5510は、Reed-Solomon Forward Error Correction (FEC) Schemesに関する標準化ドキュメントです。このRFCの目的は、ネットワーク通信におけるエラー訂正のための効果的なFECスキームを提供することです。
Network Working Group J. Lacan
Request for Comments: 5510 ISAE/LAAS-CNRS
Category: Standards Track V. Roca
INRIA
J. Peltotalo
S. Peltotalo
Tampere University of Technology
April 2009
Reed-Solomon 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の法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Abstract
概要
This document describes a Fully-Specified Forward Error Correction (FEC) Scheme for the Reed-Solomon FEC codes over GF(2^^m), where m is in {2..16}, and its application to the reliable delivery of data objects on the packet erasure channel (i.e., a communication path where packets are either received without any corruption or discarded during transmission). This document also describes a Fully-Specified FEC Scheme for the special case of Reed-Solomon codes over GF(2^^8) when there is no encoding symbol group. Finally, in the context of the Under-Specified Small Block Systematic FEC Scheme (FEC Encoding ID 129), this document assigns an FEC Instance ID to the special case of Reed-Solomon codes over GF(2^^8).
このドキュメントでは、GF（2 ^^ M）を介したReed-Solomon FECコードの完全に指定されたフォワードエラー補正（FEC）スキーム（Mが{2..16}）と、データの信頼できる配信への適用について説明します。パケット消去チャネル上のオブジェクト（つまり、パケットが破損せずに受信されるか、送信中に破棄される通信パス）。このドキュメントでは、エンコードシンボルグループがない場合のGF（2 ^^ 8）をめぐるReed-Solomonコードの特別なケースのための完全に指定されたFECスキームについても説明しています。最後に、不足している小さなブロック系統的FECスキーム（FECエンコードID 129）のコンテキストで、このドキュメントは、GF（2 ^^ 8）を介したReed-Solomonコードの特別なケースにFECインスタンスIDを割り当てます。
Reed-Solomon codes belong to the class of Maximum Distance Separable (MDS) codes, i.e., they enable a receiver to recover the k source symbols from any set of k received symbols. The schemes described here are compatible with the implementation from Luigi Rizzo.
Reed-Solomonコードは、最大距離分離可能な（MDS）コードのクラスに属します。つまり、受信したシンボルのセットからkソース記号を受信者が回復できるようにします。ここで説明するスキームは、Luigi Rizzoの実装と互換性があります。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................5
3. Definitions Notations and Abbreviations .........................5
3.1. Definitions ................................................5
3.2. Notations ..................................................6
3.3. Abbreviations ..............................................7
4. Formats and Codes with FEC Encoding ID 2 ........................7
4.1. FEC Payload ID .............................................7
4.2. FEC Object Transmission Information ........................8
4.2.1. Mandatory Elements ..................................8
4.2.2. Common Elements .....................................8
4.2.3. Scheme-Specific Elements ............................9
4.2.4. Encoding Format .....................................9
5. Formats and Codes with FEC Encoding ID 5 .......................11
5.1. FEC Payload ID ............................................11
5.2. FEC Object Transmission Information .......................12
5.2.1. Mandatory Elements .................................12
5.2.2. Common Elements ....................................12
5.2.3. Scheme-Specific Elements ...........................12
5.2.4. Encoding Format ....................................12
6. Procedures with FEC Encoding IDs 2 and 5 .......................13
6.1. Determining the Maximum Source Block Length (B) ...........13
6.2. Determining the Number of Encoding Symbols of a Block .....14
7. Small Block Systematic FEC Scheme (FEC Encoding ID 129)
and Reed-Solomon Codes over GF(2^^8) ...........................15
8. Reed-Solomon Codes Specification for the Erasure Channel .......16
8.1. Finite Field ..............................................16
8.2. Reed-Solomon Encoding Algorithm ...........................17
8.2.1. Encoding Principles ................................17
8.2.2. Encoding Complexity ................................18
8.3. Reed-Solomon Decoding Algorithm ...........................18
8.3.1. Decoding Principles ................................18
8.3.2. Decoding Complexity ................................19
8.4. Implementation for the Packet Erasure Channel .............19
9. Security Considerations ........................................22
9.1. Problem Statement .........................................22
9.2. Attacks against the Data Flow .............................23
9.2.1. Access to Confidential Objects .....................23
9.2.2. Content Corruption .................................23
9.3. Attacks against the FEC Parameters ........................24
10. IANA Considerations ...........................................25
11. Acknowledgments ...............................................25
12. References ....................................................26
12.1. Normative References .....................................26
12.2. Informative References ...................................26
The use of Forward Error Correction (FEC) codes is a classical solution to improve the reliability of multicast and broadcast transmissions. The [RFC5052] document describes a general framework to use FEC in Content Delivery Protocols (CDPs). The companion document [RFC3453] describes some applications of FEC codes for content delivery.
フォワードエラー補正（FEC）コードの使用は、マルチキャストとブロードキャストの送信の信頼性を改善するための古典的なソリューションです。[RFC5052]ドキュメントは、コンテンツ配信プロトコル（CDP）でFECを使用する一般的なフレームワークについて説明しています。コンパニオンドキュメント[RFC3453]は、コンテンツ配信のためのFECコードのいくつかのアプリケーションについて説明しています。
Recent FEC schemes like [RFC5053] and [RFC5170] proposed erasure codes based on sparse graphs/matrices. These codes are efficient in terms of processing but not optimal in terms of correction capabilities when dealing with "small" objects.
[RFC5053]や[RFC5170]などの最近のFECスキームは、スパースグラフ/マトリックスに基づいて消去コードを提案しました。これらのコードは、処理の点で効率的ですが、「小さな」オブジェクトを扱う際の補正機能の点では最適ではありません。
The FEC schemes described in this document belongs to the class of Maximum Distance Separable codes that are optimal in terms of erasure correction capability. In others words, it enables a receiver to recover the k source symbols from any set of exactly k encoding symbols. They are also systematic codes, which means that the k source symbols are part of the encoding symbols. Even if the encoding/decoding complexity is larger than that of [RFC5053] or [RFC5170], this family of codes is very useful.
このドキュメントで説明されているFECスキームは、消去補正機能の観点から最適な最大距離分離可能なコードのクラスに属します。他の言葉では、レシーバーは、正確なKエンコードシンボルのセットからkソース記号を回復することができます。また、体系的なコードです。つまり、Kソースシンボルはエンコードシンボルの一部です。エンコード/デコードの複雑さが[RFC5053]または[RFC5170]のエンコード/デコードが大きい場合でも、このコードファミリは非常に便利です。
Many applications dealing with content transmission or content storage already rely on packet-based Reed-Solomon codes. In particular, many of them use the Reed-Solomon codec of Luigi Rizzo [RS-codec] [Rizzo97]. The goal of the present document is to specify an implementation of Reed-Solomon codes that is compatible with this codec.
コンテンツの送信またはコンテンツストレージを扱う多くのアプリケーションは、すでにパケットベースのReed-Solomonコードに依存しています。特に、それらの多くは、Luigi Rizzo [RS-Codec] [Rizzo97]のReed-Solomon Codecを使用しています。現在のドキュメントの目標は、このコーデックと互換性のあるリードソロモンコードの実装を指定することです。
The present document:
現在のドキュメント：
o introduces the Fully-Specified FEC Scheme with FEC Encoding ID 2, which specifies the use of Reed-Solomon codes over GF(2^^m), where m is in {2..16},
o FECをエンコードするID 2を使用して完全に指定されたFECスキームを導入します。これは、GF（2 ^^ m）を介したリードソロモンコードの使用を指定します。ここで、mは{2..16}です。
o introduces the Fully-Specified FEC Scheme with FEC Encoding ID 5, which focuses on the special case of Reed-Solomon codes over GF(2^^8) and no encoding symbol group (i.e., exactly one symbol per packet), and
o FECをエンコードID 5で完全に指定したFECスキームを導入します。これは、GF（2 ^^ 8）およびエンコードシンボルグループ（つまり、パケットごとに1つのシンボル）を介したリードソロモンコードの特別なケースに焦点を当てています。
o in the context of the Under-Specified Small Block Systematic FEC Scheme (FEC Encoding ID 129) [RFC5445], assigns the FEC Instance ID 0 to the special case of Reed-Solomon codes over GF(2^^8) and no encoding symbol group.
o 不足していない小さなブロック系統的FECスキーム（FECエンコードID129）[RFC5445）のコンテキストでは、FECインスタンスID 0をGF（2 ^^ 8）上のリードソロモンコードの特別なケースに割り当て、エンコードシンボルはありませんグループ。
For a definition of the terms Fully-Specified and Under-Specified FEC Schemes, see [RFC5052], Section 4.
完全に指定されていないFECスキームの用語の定義については、[RFC5052]、セクション4を参照してください。
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 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
This document uses the same terms and definitions as those specified in [RFC5052]. Additionally, it uses the following definitions:
このドキュメントは、[RFC5052]で指定されている用語と同じ用語と定義を使用します。さらに、次の定義を使用します。
Source symbol: unit of data used during the encoding process.
ソースシンボル：エンコーディングプロセス中に使用されるデータの単位。
Encoding symbol: unit of data generated by the encoding process.
エンコーディングシンボル：エンコードプロセスによって生成されたデータの単位。
Repair symbol: encoding symbol that is not a source symbol.
修復シンボル：ソースシンボルではないエンコードシンボル。
Code rate: the k/n ratio, i.e., the ratio between the number of source symbols and the number of encoding symbols. By definition, the code rate is such that: 0 < code rate <= 1. A code rate close to 1 indicates that a small number of repair symbols have been produced during the encoding process.
コードレート：K/N比、つまり、ソースシンボルの数とエンコーディングシンボルの数との比率。定義上、コードレートは次のとおりです。0<コードレート<= 1に近いコードレートは、エンコーディングプロセス中に少数の修復記号が生成されたことを示します。
Systematic code: FEC code in which the source symbols are part of the encoding symbols.
系統的コード：ソースシンボルがエンコードシンボルの一部であるFECコード。
Source block: a block of k source symbols that are considered together for the encoding.
ソースブロック：エンコーディングのために一緒に考慮されるKソース記号のブロック。
Encoding Symbol Group: a group of encoding symbols that are sent together within the same packet, and whose relationships to the source block can be derived from a single Encoding Symbol ID.
エンコーディングシンボルグループ：同じパケット内で一緒に送信され、ソースブロックとの関係を単一のエンコードシンボルIDから導き出すことができるエンコードシンボルのグループ。
Source Packet: a data packet containing only source symbols.
ソースパケット：ソース記号のみを含むデータパケット。
Repair Packet: a data packet containing only repair symbols.
修理パケット：修理記号のみを含むデータパケット。
Packet Erasure Channel: a communication path where packets are either dropped (e.g., by a congested router, or because the number of transmission errors exceeds the correction capabilities of the physical layer codes) or received. When a packet is received, it is assumed that this packet is not corrupted.
パケット消去チャネル：パケットがドロップされる通信パス（たとえば、混雑したルーターによって、または伝送エラーの数が物理層コードの修正機能を超えるため）または受信した通信パス。パケットが受信されると、このパケットが破損していないと想定されます。
This document uses the following notations:
このドキュメントでは、次の表記法を使用しています。
L the object transfer length in bytes.
lバイト単位のオブジェクト転送長。
k the number of source symbols in a source block.
kソースブロック内のソース記号の数。
n_r the number of repair symbols generated for a source block.
N_Rソースブロック用に生成された修理記号の数。
n the encoding block length, i.e., the number of encoding symbols generated for a source block. Therefore: n = k + n_r.
nエンコーディングブロック長、つまり、ソースブロックに生成されたエンコードシンボルの数。したがって、n = k n_r。
max_n the maximum number of encoding symbols generated for any source block.
max_n任意のソースブロックに対して生成されたエンコードシンボルの最大数。
B the maximum source block length in symbols, i.e., the maximum number of source symbols per source block.
bシンボルの最大ソースブロック長、つまりソースブロックごとのソース記号の最大数。
N the number of source blocks into which the object shall be partitioned.
nオブジェクトが分割されるソースブロックの数。
E the encoding symbol length in bytes.
eバイトのエンコーディングシンボル長。
S the symbol size in units of m-bit elements. When m = 8, then S and E are equal.
s Mビット要素の単位のシンボルサイズ。M = 8の場合、SとEは等しくなります。
m the length of the elements in the finite field, in bits. In this document, m belongs to {2..16}.
M有限フィールドの要素の長さ、ビット。このドキュメントでは、mは{2..16}に属します。
q the number of elements in the finite field. We have: q = 2^^m in this specification.
Q有限フィールドの要素の数。この仕様にはq = 2 ^^ mがあります。
G the number of encoding symbols per group, i.e., the number of symbols sent in the same packet.
gグループごとのエンコーディングシンボルの数、つまり、同じパケットで送信されるシンボルの数。
GM the Generator Matrix of a Reed-Solomon code.
GMリードソロモンコードのジェネレーターマトリックス。
CR the "code rate", i.e., the k/n ratio.
CR「コードレート」、つまりK/N比。
a^^b a raised to the power b.
a ^^ b a a a power b。
a^^-1 the inverse of a.
a ^^ -1 aの逆数。
I_k the k*k identity matrix.
i_k k*k Identityマトリックス。
This document uses the following abbreviations:
このドキュメントでは、次の略語を使用しています。
ESI Encoding Symbol ID.
ESIエンコードシンボルID。
FEC OTI FEC Object Transmission Information.
FEC OTI FECオブジェクト伝送情報。
RS Reed-Solomon.
RSリードソロモン。
MDS Maximum Distance Separable code.
MDS最大距離分離可能なコード。
GF(q) a finite field (also known as Galois Field) with q elements. We assume that q = 2^^m in this document.
GF（Q）Q要素を備えた有限フィールド（ガロワフィールドとも呼ばれます）。このドキュメントではq = 2 ^^ mであると想定しています。
This section introduces the formats and codes associated with the Fully-Specified FEC Scheme with FEC Encoding ID 2, which specifies the use of Reed-Solomon codes over GF(2^^m).
このセクションでは、GF（2 ^^ m）を介したリードソロモンコードの使用を指定するFECを使用して、完全に指定されたFECスキームに関連するフォーマットとコードを紹介します。
The FEC Payload ID is composed of the Source Block Number and the Encoding Symbol ID. The lengths of these two fields depend on the parameter m (which is transmitted in the FEC OTI) as follows:
FECペイロードIDは、ソースブロック番号とエンコードシンボルIDで構成されています。これらの2つのフィールドの長さは、次のようにパラメーターM（FEC OTIで送信されます）に依存します。
o The Source Block Number (field of size 32-m bits) identifies from which source block of the object the encoding symbol(s) in the payload are generated. There is a maximum of 2^^(32-m) blocks per object.
o ソースブロック番号（サイズ32 mビットのフィールド）は、ペイロードのエンコーディングシンボルが生成されるオブジェクトのソースブロックから識別します。オブジェクトごとに最大2 ^^（32-m）ブロックがあります。
o The Encoding Symbol ID (field of size m bits) identifies which specific encoding symbol(s) generated from the source block are carried in the packet payload. There is a maximum of 2^^m encoding symbols per block. The first k values (0 to k - 1) identify source symbols, the remaining n-k values identify repair symbols.
o エンコーディングシンボルID（サイズMビットのフィールド）は、ソースブロックから生成された特定のエンコードシンボルがパケットペイロードに掲載されるかを識別します。ブロックごとに最大2 ^^ mエンコードシンボルがあります。最初のk値（0からk -1）はソースシンボルを識別し、残りのn -k値は修復記号を識別します。
There MUST be exactly one FEC Payload ID per source or repair packet. In case of an Encoding Symbol Group, when multiple encoding symbols are sent in the same packet, the FEC Payload ID refers to the first symbol of the packet. The other symbols can be deduced from the ESI of the first symbol by incrementing sequentially the ESI.
ソースまたは修理パケットごとにFECペイロードIDが1つだけある必要があります。エンコードシンボルグループの場合、複数のエンコードシンボルが同じパケットで送信される場合、FECペイロードIDはパケットの最初のシンボルを指します。他のシンボルは、ESIを連続的に増加させることにより、最初のシンボルのESIから推定できます。
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 (32-8=24 bits) | Enc. Symb. ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: FEC Payload ID Encoding Format for m = 8 (Default)
図1：M = 8のFECペイロード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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Block Nb (32-16=16 bits) | Enc. Symbol ID (m=16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: FEC Payload ID Encoding Format for m = 16
図2：M = 16のFECペイロードIDエンコード形式
The formats of the FEC Payload ID for m = 8 and m = 16 are illustrated in Figure 1 and Figure 2, respectively.
M = 8およびM = 16のFECペイロードIDの形式を、それぞれ図1と図2に示します。
o FEC Encoding ID: the Fully-Specified FEC Scheme described in this section uses FEC Encoding ID 2.
o FECエンコーディングID：このセクションで説明する完全に指定されたFECスキームでは、FECエンコーディングID 2を使用します。
The following elements MUST be defined with the present FEC scheme.
次の要素は、現在のFECスキームで定義する必要があります。
o Transfer-Length (L): a non-negative integer indicating the length of the object in bytes. There are some restrictions on the maximum Transfer-Length that can be supported:
o トランスファーレングス（L）：バイト内のオブジェクトの長さを示す非陰性整数。サポートできる最大転送長にはいくつかの制限があります。
max_transfer_length = 2^^(32-m) * B * E
For instance, for m = 8, for B = 2^^8 - 1 (because the codec operates on a finite field with 2^^8 elements), and if E = 1024 bytes, then the maximum transfer length is approximately equal to 2^^42 bytes (i.e., 4 terabytes). Similarly, for m = 16, for B = 2^^16 - 1, and if E = 1024 bytes, then the maximum transfer length is also approximately equal to 2^^42 bytes. For larger objects, another FEC scheme, with a larger Source Block Number field in the FEC Payload ID, could be defined. Another solution consists in fragmenting large objects into smaller objects, each of them complying with the above limits.
たとえば、m = 8の場合、b = 2 ^^ 8-1の場合（コーデックは2 ^^ 8要素を持つ有限フィールドで動作するため）。2 ^^ 42バイト（つまり、4テラバイト）。同様に、m = 16の場合、b = 2 ^^ 16-1の場合、およびe = 1024バイトの場合、最大転送長は2 ^^ 42バイトにもほぼ等しくなります。より大きなオブジェクトの場合、FECペイロードIDに大きなソースブロック番号フィールドを備えた別のFECスキームを定義できます。別のソリューションは、大きなオブジェクトを小さなオブジェクトに断片化することで構成されており、それぞれが上記の制限に準拠しています。
o Encoding-Symbol-Length (E): a non-negative integer indicating the length of each encoding symbol in bytes.
o エンコーディング-Symbol-Length（e）：バイト内の各エンコーディングシンボルの長さを示す非陰性整数。
o Maximum-Source-Block-Length (B): a non-negative integer indicating the maximum number of source symbols in a source block.
o 最大ソースブロック長（b）：ソースブロック内のソース記号の最大数を示す非陰性整数。
o Max-Number-of-Encoding-Symbols (max_n): a non-negative integer indicating the maximum number of encoding symbols generated for any source block.
o Max-Number-of-Encoding-Symbols（MAX_N）：ソースブロックに生成されたエンコード記号の最大数を示す非陰性整数。
Section 6 explains how to derive the values of each of these elements.
セクション6では、これらの各要素の値を導出する方法について説明します。
The following element MUST be defined with the present FEC scheme. It contains two distinct pieces of information:
次の要素は、現在のFECスキームで定義する必要があります。2つの異なる情報が含まれています。
o G: a non-negative integer indicating the number of encoding symbols per group used for the object. The default value is 1, meaning that each packet contains exactly one symbol. When no G parameter is communicated to the decoder, then the latter MUST assume that G = 1.
o G：オブジェクトに使用されるグループごとのエンコード記号の数を示す非陰性整数。デフォルトの値は1です。つまり、各パケットには1つのシンボルが正確に含まれています。Gパラメーターがデコーダーに通信されない場合、後者はG = 1と仮定する必要があります。
o m: The m parameter is the length of the finite field elements, in bits. It also characterizes the number of elements in the finite field: q = 2^^m elements. The default value is m = 8. When no finite field size parameter is communicated to the decoder, then the latter MUST assume that m = 8.
o M：Mパラメーターは、ビット内の有限フィールド要素の長さです。また、有限フィールドの要素の数を特徴付けます：q = 2 ^^ m要素。デフォルト値はM = 8です。フィールドサイズの有限サイズパラメーターがデコーダーに通信されない場合、後者はM = 8と仮定する必要があります。
This section shows the two possible encoding formats of the above FEC OTI. The present document does not specify when one encoding format or the other should be used.
このセクションでは、上記のFEC OTIの2つの可能なエンコード形式を示します。現在のドキュメントでは、1つのエンコード形式またはもう1つのドキュメントを使用する必要がある場合は指定されていません。
The FEC OTI binary format is the following, when the EXT_FTI mechanism is used (e.g., within the ALC [ALC] or NORM [NORM] protocols).
fec otiバイナリ形式は、ext_ftiメカニズムが使用される場合（たとえば、alc [alc]またはnorm [norm]プロトコル）を使用します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET = 64 | HEL = 4 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Transfer Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| m | G | Encoding Symbol Length (E) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Source Block Length (B) | Max Nb Enc. Symbols (max_n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: EXT_FTI Header Format
図3：ext_ftiヘッダー形式
When it is desired that the FEC OTI be carried in the FDT (File Delivery Table) Instance of a FLUTE session [FLUTE], the following XML attributes must be described for the associated object:
FEC OTIをFDT（ファイル配信テーブル）フルートセッション[フルート]のインスタンスに携帯することが望ましい場合は、次のXML属性を関連するオブジェクトについて説明する必要があります。
o FEC-OTI-FEC-Encoding-ID
o FEC-OTI-FEC-ENCODING-ID
o FEC-OTI-Transfer-Length (L)
o fec-oti transfer-length（l）
o FEC-OTI-Encoding-Symbol-Length (E)
o fec-oti-encoding-symbol-length（e）
o FEC-OTI-Maximum-Source-Block-Length (B)
o fec-oti-maximum-source-block-length（b）
o FEC-OTI-Max-Number-of-Encoding-Symbols (max_n)
o fec-oti-max-number-of-encoding-symbols（max_n）
o FEC-OTI-Scheme-Specific-Info
o FEC-OTI-SCHEME特異的INFO
The FEC-OTI-Scheme-Specific-Info contains the string resulting from the Base64 encoding (in the XML Schema xs:base64Binary sense) of the following value:
FEC-OTI-SCHEME特異的INFOには、次の値のbase64エンコード（XMLスキーマXS：base64Birany感覚）から生じる文字列が含まれています。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| m | G |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: FEC OTI Scheme Specific Information To Be Included in the FDT Instance
図4：FEC OTIスキームFDTインスタンスに含まれる特定の情報
When no m parameter is to be carried in the FEC OTI, the m field is set to 0 (which is not a valid seed value). Otherwise, the m field contains a valid value as explained in Section 4.2.3. Similarly, when no G parameter is to be carried in the FEC OTI, the G field is set to 0 (which is not a valid seed value). Otherwise, the G field contains a valid value as explained in Section 4.2.3. When neither m nor G are to be carried in the FEC OTI, then the sender simply omits the FEC-OTI-Scheme-Specific-Info attribute.
FEC OTIでMパラメーターを運ばない場合、Mフィールドは0に設定されています（これは有効な種子値ではありません）。それ以外の場合、Mフィールドには、セクション4.2.3で説明されているように有効な値が含まれています。同様に、gパラメーターがfec otiに運ばれない場合、gフィールドは0に設定されています（これは有効なシード値ではありません）。それ以外の場合、Gフィールドには、セクション4.2.3で説明されているように有効な値が含まれています。MもGもFEC OTIで運ばない場合、送信者はFEC-OTI-SCHEME固有のINFO属性を単純に省略します。
During Base64 encoding, the 2 bytes of the FEC OTI Scheme-Specific Information are transformed into a string of 4 printable characters (in the 64-character alphabet) that is added to the FEC-OTI-Scheme-Specific-Info attribute.
Base64エンコーディング中、FEC OTIスキーム固有の情報の2バイトは、FEC-OTI-SCHEME固有のINFO属性に追加される4つの印刷可能な文字（64文字のアルファベット）の文字列に変換されます。
This section introduces the formats and codes associated with the Fully-Specified FEC Scheme with FEC Encoding ID 5, which focuses on the special case of Reed-Solomon codes over GF(2^^8) and no encoding symbol group.
このセクションでは、FECをエンコードするID 5を使用した完全に指定されたFECスキームに関連するフォーマットとコードを紹介します。これは、GF（2 ^^ 8）およびエンコードシンボルグループを介したリードソロモンコードの特別なケースに焦点を当てています。
The FEC Payload ID is composed of the Source Block Number and the Encoding Symbol ID:
FECペイロードIDは、ソースブロック番号とエンコードシンボルIDで構成されています。
o The Source Block Number (24-bit field) identifies from which source block of the object the encoding symbol in the payload is generated. There is a maximum of 2^^24 blocks per object.
o ソースブロック番号（24ビットフィールド）は、ペイロード内のエンコードシンボルが生成されるオブジェクトのソースブロックから識別します。オブジェクトごとに最大2 ^^ 24ブロックがあります。
o The Encoding Symbol ID (8-bit field) identifies which specific encoding symbol generated from the source block is carried in the packet payload. There is a maximum of 2^^8 encoding symbols per block. The first k values (0 to k - 1) identify source symbols; the remaining n-k values identify repair symbols.
o エンコーディングシンボルID（8ビットフィールド）は、ソースブロックから生成された特定のエンコードシンボルがパケットペイロード内で運ばれるかを識別します。ブロックごとに最大2つの^^ 8エンコードシンボルがあります。最初のk値（0からk -1）はソースシンボルを識別します。残りのn-k値は、修復記号を識別します。
There MUST be exactly one FEC Payload ID per source or repair packet. This FEC Payload ID refers to the one and only symbol of the packet.
ソースまたは修理パケットごとにFECペイロードIDが1つだけある必要があります。このFECペイロード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 (24 bits) | Enc. Symb. ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: FEC Payload ID Encoding Format with FEC Encoding ID 5
図5：FECエンコードID 5を使用したFECペイロードIDエンコード形式
o FEC Encoding ID: the Fully-Specified FEC Scheme described in this section uses FEC Encoding ID 5.
o FECエンコーディングID：このセクションで説明する完全に指定されたFECスキームでは、FECエンコーディングID 5を使用します。
The Common elements are the same as those specified in Section 4.2.2 when m = 8 and G = 1.
共通要素は、M = 8およびG = 1の場合、セクション4.2.2で指定された要素と同じです。
No Scheme-Specific elements are defined by this FEC scheme.
このFECスキームでは、スキーム固有の要素は定義されていません。
This section shows the two possible encoding formats of the above FEC OTI. The present document does not specify when one encoding format or the other should be used.
このセクションでは、上記のFEC OTIの2つの可能なエンコード形式を示します。現在のドキュメントでは、1つのエンコード形式またはもう1つのドキュメントを使用する必要がある場合は指定されていません。
The FEC OTI binary format is the following, when the EXT_FTI mechanism is used (e.g., within the ALC [ALC] or NORM [NORM] protocols).
fec otiバイナリ形式は、ext_ftiメカニズムが使用される場合（たとえば、alc [alc]またはnorm [norm]プロトコル）を使用します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET = 64 | HEL = 3 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Transfer Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol Length (E) | MaxBlkLen (B) | max_n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: EXT_FTI Header Format with FEC Encoding ID 5
図6：FECをエンコードするID5を備えたExt_ftiヘッダー形式
When it is desired that the FEC OTI be carried in the FDT Instance of a FLUTE session [FLUTE], the following XML attributes must be described for the associated object:
FEC OTIをフルートセッション[フルート]のFDTインスタンスに携帯することが望ましい場合は、関連するオブジェクトについて次のXML属性を説明する必要があります。
o FEC-OTI-FEC-Encoding-ID o FEC-OTI-Transfer-Length (L)
o FEC-OTI-FEC-ENCODING-ID O FEC-OTI-TRANSFER-LENGTH（L）
o FEC-OTI-Encoding-Symbol-Length (E)
o fec-oti-encoding-symbol-length（e）
o FEC-OTI-Maximum-Source-Block-Length (B)
o fec-oti-maximum-source-block-length（b）
o FEC-OTI-Max-Number-of-Encoding-Symbols (max_n)
o fec-oti-max-number-of-encoding-symbols（max_n）
This section defines procedures that are common to FEC Encoding IDs 2 and 5. In case of FEC Encoding ID 5, m = 8 and G = 1. The block partitioning algorithm that is defined in Section 9.1 of [RFC5052] MUST be used with FEC Encoding IDs 2 and 5.
このセクションでは、FECをエンコードするID 2および5に共通する手順を定義します。FECをエンコードするID 5、M = 8、およびg = 1の場合、[RFC5052]のセクション9.1で定義されているブロックパーティションアルゴリズムは、FECで使用する必要があります。ID 2および5のエンコード。
The finite field size parameter, m, defines the number of non-zero elements in this field, which is equal to: q - 1 = 2^^m - 1. Note that q - 1 is also the theoretical maximum number of encoding symbols that can be produced for a source block. For instance, when m = 8 (default) there is a maximum of 2^^8 - 1 = 255 encoding symbols.
有限のフィールドサイズパラメーターMは、このフィールドの非ゼロ要素の数を定義します。これはQ -1 = 2 ^^ m -1に等しい。ソースブロック用に作成できます。たとえば、m = 8（デフォルト）の場合、最大2 ^^ 8-1 = 255エンコードシンボルがあります。
Given the target FEC code rate (e.g., provided by the user when starting a FLUTE sending application), the sender calculates:
ターゲットFECコードレート（たとえば、フルートの送信アプリケーションを開始するときにユーザーが提供する）を考えると、送信者は次のように計算します。
max1_B = floor((2^^m - 1) * CR)
This max1_B value leaves enough room for the sender to produce the desired number of parity symbols.
このmax1_b値は、送信者が望ましい数のパリティシンボルを生成するのに十分なスペースを残します。
Additionally, a codec MAY impose other limitations on the maximum block size. Yet it is not expected that such limits exist when using the default m = 8 value. This decision MUST be clarified at implementation time, when the target use case is known. This results in a max2_B limitation.
さらに、コーデックは最大ブロックサイズに他の制限を課す場合があります。しかし、デフォルトのM = 8値を使用する場合、そのような制限が存在することは予想されません。この決定は、ターゲットユースケースが既知の場合に、実装時に明確にする必要があります。これにより、MAX2_Bの制限が得られます。
Then, B is given by:
次に、Bは次のように与えられます。
B = min(max1_B, max2_B)
b = min（max1_b、max2_b）
Note that this calculation is only required at the coder, since the B parameter is communicated to the decoder through the FEC OTI.
BパラメーターはFEC OTIを介してデコーダーに通信されるため、この計算はコーダーでのみ必要であることに注意してください。
The following algorithm, also called "n-algorithm", explains how to determine the maximum number of encoding symbols generated for any source block (max_n) and the number of encoding symbols for a given block (n) as a function of the target code rate.
「n-アルゴリズム」とも呼ばれる次のアルゴリズムは、ターゲットコードの関数として、任意のソースブロック（max_n）に生成されたエンコーディングシンボルの最大数と、特定のブロック（n）のエンコードシンボルの数を決定する方法を説明します。レート。
AT A SENDER:
送信者で：
Input:
入力：
B: Maximum source block length, for any source block. Section 6.1 explains how to determine its value.
B：ソースブロックの最大ソースブロック長。セクション6.1では、その価値を決定する方法について説明します。
k: Current source block length. This parameter is given by the block partitioning algorithm.
K：現在のソースブロック長。このパラメーターは、ブロックパーティションアルゴリズムによって与えられます。
CR: FEC code rate, which is given by the user (e.g., when starting a FLUTE sending application). It is expressed as a floating point value.
CR：FECコードレート。これは、ユーザーによって与えられます（たとえば、フルートの送信アプリケーションを開始するとき）。これは、浮動小数点値として表されます。
Output:
出力：
max_n: Maximum number of encoding symbols generated for any source block.
MAX_N：ソースブロックに対して生成されたエンコードシンボルの最大数。
n: Number of encoding symbols generated for this source block.
N：このソースブロックに生成されたエンコードシンボルの数。
Algorithm:
アルゴリズム：
max_n = ceil(B / CR);
if (max_n > 2^^m - 1), then return an error ("invalid code rate");
n = floor(k * max_n / B);
AT A RECEIVER:
レシーバーで：
Input:
入力：
B: Extracted from the received FEC OTI.
B：受信したFEC OTIから抽出。
max_n: Extracted from the received FEC OTI.
MAX_N：受信したFEC OTIから抽出。
k: Given by the block partitioning algorithm.
K：ブロックパーティションアルゴリズムによって与えられます。
Output:
出力：
n
n
Algorithm:
アルゴリズム：
n = floor(k * max_n / B);
It is RECOMMENDED that the "n-algorithm" be used by a sender, but other algorithms remain possible to determine max_n and/or n.
「n-アルゴリズム」を送信者が使用することをお勧めしますが、MAX_Nおよび/またはnを決定するために他のアルゴリズムは引き続き可能です。
At a receiver, the max_n value is extracted from the received FEC OTI. Since the Reed-Solomon decoder does not need to know the actual n value, using the receiver part of the "n-algorithm" is not necessary from a decoding point of view.
受信機では、MAX_N値が受信したFEC OTIから抽出されます。Reed-Solomon Decoderは実際のn値を知る必要はないため、「n-algorithm」の受信部品を使用することは、デコードの観点からは必要ありません。
However, a receiver may want to have an estimate of n for other reasons (e.g., for memory management purposes). In that case, a receiver knows that the number of encoding symbols of a block cannot exceed max_n. Additionally, if a receiver believes that a sender uses the "n-algorithm", this receiver MAY use the receiver part of the "n-algorithm" to get a better estimate of n. When this is the case, a receiver MUST be prepared to handle symbols with an Encoding Symbol ID superior or equal to the computed n value (e.g., it can choose to simply drop them).
ただし、受信者は、他の理由で（メモリ管理の目的など）、Nの推定値を持ちたい場合があります。その場合、レシーバーは、ブロックのエンコード記号の数がMAX_Nを超えないことを知っています。さらに、受信者が送信者が「nアルゴリズム」を使用すると信じている場合、このレシーバーは「nアルゴリズム」の受信者部分を使用してnのより良い推定値を取得することができます。この場合、レシーバーは、計算されたn値よりも優れているか等しいエンコードシンボルIDでシンボルを処理するために準備する必要があります（たとえば、単にドロップすることを選択できます）。
In the context of the Under-Specified Small Block Systematic FEC Scheme (FEC Encoding ID 129) [RFC5445], this document assigns the FEC Instance ID 0 to the special case of Reed-Solomon codes over GF(2^^8) and no encoding symbol group.
不足していない小さなブロック系統的FECスキーム（FECエンコードID 129）[RFC5445）のコンテキストでは、このドキュメントは、GF（2 ^^ 8）およびNO NOを介したReed-Solomonコードの特別なケースにFECインスタンスID 0を割り当てます。シンボルグループをエンコードします。
The FEC Instance ID 0 uses the Formats and Codes specified in [RFC5445].
FECインスタンスID 0は、[RFC5445]で指定された形式とコードを使用します。
The FEC scheme with FEC Instance ID 0 MAY use the block partitioning algorithm defined in Section 9.1 of [RFC5052] to partition the object into source blocks. This FEC scheme MAY also use another algorithm. For instance, the CDP sender may change the length of each source block dynamically, depending on some external criteria (e.g., to adjust the FEC coding rate to the current loss rate experienced by NORM receivers) and inform the CDP receivers of the current block length by means of the EXT_FTI mechanism. This choice is out of the scope of the current document.
FECインスタンスID 0を使用したFECスキームは、[RFC5052]のセクション9.1で定義されたブロックパーティションアルゴリズムを使用して、オブジェクトをソースブロックに分割することができます。このFECスキームは、別のアルゴリズムを使用する場合もあります。たとえば、CDP送信者は、一部の外部基準（たとえば、NORM受信機が経験した現在の損失率にFECコーディングレートを調整する）に応じて、各ソースブロックの長さを動的に変更し、CDPレシーバーに現在のブロックレジットを通知する場合があります。ext_ftiメカニズムによって。この選択は、現在のドキュメントの範囲外です。
Reed-Solomon (RS) codes are linear block codes. They also belong to the class of MDS codes. A [n,k]-RS code encodes a sequence of k source elements defined over a finite field GF(q) into a sequence of n encoding elements, where n is upper bounded by q - 1. The implementation described in this document is based on a generator matrix built from a Vandermonde matrix put into systematic form.
Reed-Solomon（RS）コードは線形ブロックコードです。また、MDSコードのクラスにも属します。a [n、k] -RSコードは、有限フィールドGF（q）を介して定義されたkソース要素のシーケンスをエンコードして、nがq -1によって上限に境界があるnエンコード要素のシーケンスにエンコードします。このドキュメントで説明する実装はです。系統的な形に置かれたヴァンダーモンドマトリックスから構築されたジェネレーターマトリックスに基づいています。
Sections 8.1 to 8.3 specify the [n,k]-RS codes when applied to m-bit elements, and Section 8.4 specifies the use of [n,k]-RS codes when applied to symbols composed of several m-bit elements. The use described in Section 8.4 is the crux of this specification.
セクション8.1〜8.3は、Mビット要素に適用されたときに[n、k] -RSコードを指定し、セクション8.4は、いくつかのMビット要素で構成されるシンボルに適用された場合の[n、k] -RSコードの使用を指定します。セクション8.4で説明する使用は、この仕様の核心です。
A reader who wants to understand the underlying theory is invited to refer to references [Rizzo97] and [MWS77].
基礎となる理論を理解したい読者は、参照[Rizzo97]および[MWS77]を参照するように招待されています。
A finite field GF(q) is defined as a finite set of q elements that has a structure of field. It contains necessarily q = p^^m elements, where p is a prime number. With packet erasure channels, p is always set to 2. The elements of the field GF(2^^m) can be represented by polynomials with binary coefficients (i.e., over GF(2)) of degree lower or equal to m-1. The polynomials can be associated with binary vectors of length m. For example, the vector (11001) represents the polynomial 1 + x + x^^4. This representation is often called polynomial representation. The addition between two elements is defined as the addition of binary polynomials in GF(2) and the multiplication is the multiplication modulo a given irreducible polynomial over GF(2) of degree m. Note that all the roots of this polynomial are in GF(2^^m) but not in GF(2).
有限フィールドGF（Q）は、フィールドの構造を持つQ要素の有限セットとして定義されます。必然的にq = p ^^ m要素が含まれ、pは素数です。パケット消去チャネルでは、Pは常に2に設定されます。フィールドGF（2 ^^ m）の要素は、M-1以下のバイナリ係数（すなわち、GF（2）を超える）を持つ多項式で表現できます。。多項式は、長さmのバイナリベクターに関連付けられます。たとえば、ベクトル（11001）は多項式1 x x ^^ 4を表します。この表現は、しばしば多項式表現と呼ばれます。2つの要素間の添加は、GF（2）のバイナリ多項式の添加として定義され、乗算は、程度mのGF（2）にわたって与えられた既約多項式の乗算モジュロです。この多項式のすべての根はGF（2 ^^ m）にあるが、GF（2）にはないことに注意してください。
The chosen polynomial representation of the finite field GF(2^^m) is completely characterized by the irreducible polynomial. The following polynomials are chosen to represent the field GF(2^^m), for m varying from 2 to 16:
有限フィールドGF（2 ^^ m）の選択された多項式表現は、既約多項式によって完全に特徴付けられます。2から16までのmの場合、フィールドGF（2 ^^ m）を表すために、次の多項式が選択されています。
m = 2, "111" (1+x+x^^2)
m = 3, "1101", (1+x+x^^3)
m = 4, "11001", (1+x+x^^4)
m = 5, "101001", (1+x^^2+x^^5)
m = 6, "1100001", (1+x+x^^6)
m = 7, "10010001", (1+x^^3+x^^7)
m = 8, "101110001", (1+x^^2+x^^3+x^^4+x^^8)
m = 9, "1000100001", (1+x^^4+x^^9)
m = 10, "10010000001", (1+x^^3+x^^10)
m = 11, "101000000001", (1+x^^2+x^^11)
m = 12, "1100101000001", (1+x+x^^4+x^^6+x^^12)
m = 13, "11011000000001", (1+x+x^^3+x^^4+x^^13)
m = 14, "110000100010001", (1+x+x^^6+x^^10+x^^14)
m = 15, "1100000000000001", (1+x+x^^15)
m = 16, "11010000000010001", (1+x+x^^3+x^^12+x^^16)
In order to facilitate the implementation, these polynomials are also primitive. This means that any element of GF(2^^m) can be expressed as a power of a given root of this polynomial. These polynomials are also chosen so that they contain the minimum number of monomials.
実装を促進するために、これらの多項式も原始的です。これは、GF（2 ^^ m）のすべての要素が、この多項式の特定の根の力として表現できることを意味します。これらの多項式も選択されているため、最小数のモノマリアルが含まれています。
Let s = (s_0, ..., s_{k-1}) be a source vector of k elements over
GF(2^^m). Let e = (e_0, ..., e_{n-1}) be the corresponding encoding
vector of n elements over GF(2^^m). Being a linear code, encoding is
performed by multiplying the source vector by a generator matrix, GM,
of k rows and n columns over GF(2^^m). Thus:
e = s * GM.
e = s * gm。
The definition of the generator matrix completely characterizes the RS code.
ジェネレーターマトリックスの定義は、RSコードを完全に特徴付けます。
Let us consider that n = 2^^m - 1 and that 0 < k <= n. Let us denote by alpha the root of the primitive polynomial of degree m chosen in the list of Section 8.1 for the corresponding value of m. Let us consider a Vandermonde matrix of k rows and n columns, denoted by V_{k,n}, and built as follows: the {i, j} entry of V_{k,n} is v_{i,j} = alpha^^(i*j), where 0 <= i <= k - 1 and 0 <= j <= n - 1. This matrix generates a MDS code. However, this MDS code is not systematic, which is a problem for many networking applications. To obtain a systematic matrix (and code), the simplest solution consists in considering the matrix V_{k,k} formed by the first k columns of V_{k,n}, then to invert it and to multiply this inverse by V_{k,n}. Clearly, the product V_{k,k}^^-1 * V_{k,n} contains the identity matrix I_k on its first k columns, meaning that the first k encoding elements are equal to source elements. Besides, the associated code keeps the MDS property.
n = 2 ^^ m -1と0 <k <= nを考えてみましょう。Alphaは、Mの対応する値について、セクション8.1のリストで選択された次数mの原始多項式の根を示します。v_ {k、n}で示され、次のように構築されたk行とn列のヴァンダーモンドマトリックスを考えてみましょう。v_{k、n}の{i、j}エントリはv_ {i、j} = alphaです^^（i*j）、ここで、0 <= i <= k -1および0 <= j <= n -1。このマトリックスはMDSコードを生成します。ただし、このMDSコードは体系的ではなく、多くのネットワーキングアプリケーションにとって問題です。系統的行列（およびコード）を取得するために、最も単純なソリューションは、V_ {k、n}の最初のk列によって形成されたマトリックスV_ {k、k}を考慮し、それを反転させ、v_ {K、n}。明らかに、製品v_ {k、k} ^^ -1 * v_ {k、n}には、最初のk列にIDマトリックスi_kが含まれています。つまり、最初のkエンコード要素はソース要素に等しいことを意味します。その上、関連するコードはMDSプロパティを保持します。
Therefore, the generator matrix of the code considered in this document is:
したがって、このドキュメントで検討されているコードのジェネレーターマトリックスは次のとおりです。
GM = (V_{k,k}^^-1) * V_{k,n}
Note that, in practice, the [n,k]-RS code can be shortened to a [n',k]-RS code, where k <= n' < n, by considering the sub-matrix formed by the n' first columns of GM.
実際には、[n、k] -RSコードは、n 'によって形成されたサブマトリックスを考慮することにより、k <= n' <nでa [n '、k] -RSコードに短縮できることに注意してください。GMの最初の列。
Encoding can be performed by first pre-computing GM and by multiplying the source vector (k elements) by GM (k rows and n columns). The complexity of the pre-computation of the generator matrix can be estimated as the complexity of the multiplication of the inverse of a Vandermonde matrix by n-k vectors (i.e., the last n-k columns of V_{k,n}). Since the complexity of the inverse of a k*k-Vandermonde matrix by a vector is O(k * (log(k))^^2), the generator matrix can be computed in 0((n-k)* k * (log(k))^^2)) operations. When the generator matrix is pre-computed, the encoding needs k operations per repair element (vector-matrix multiplication).
エンコーディングは、最初の事前計算GMと、ソースベクトル（k要素）にGM（k行とn列）を掛けることで実行できます。発電機マトリックスの事前計算の複雑さは、n-kベクター（すなわち、v_ {k、n}の最後のn-k列）によるヴァンダーモンドマトリックスの逆の乗算の複雑さとして推定できます。ベクトルによるk * k-vandermondeマトリックスの逆の複雑さはo（k *（log（k））^^ 2）であるため、ジェネレーターマトリックスは0（（n-k） * k *（log（log））で計算できます。k））^^ 2））操作。発電機マトリックスが事前に計算されている場合、エンコーディングは修復要素ごとにK操作が必要です（ベクトルマトリックス増殖）。
Encoding can also be performed by first computing the product s *
V_{k,k}^^-1 and then by multiplying the result with V_{k,n}. The
multiplication by the inverse of a square Vandermonde matrix is known
as the interpolation problem and its complexity is O(k *
(log(k))^^2). The multiplication by a Vandermonde matrix, known as
the multipoint evaluation problem, requires O((n-k) * log(k)) by
using Fast Fourier Transform, as explained in [GO94]. The total
complexity of this encoding algorithm is then O((k/(n-k)) *
(log(k))^^2 + log(k)) operations per repair element.
The Reed-Solomon decoding algorithm for the erasure channel allows the recovery of the k source elements from any set of k received elements. It is based on the fundamental property of the generator matrix, which is such that any k*k-submatrix is invertible (see
消去チャネルのReed-Solomonデコードアルゴリズムにより、kの受信要素のセットからkソース要素を回復することができます。これは、発電機マトリックスの基本的な特性に基づいています。これは、k*k-submatrixが反転可能であるようなものです（参照
[MWS77]). The first step of the decoding consists in extracting the k*k submatrix of the generator matrix obtained by considering the columns corresponding to the received elements. Indeed, since any encoding element is obtained by multiplying the source vector by one column of the generator matrix, the received vector of k encoding elements can be considered as the result of the multiplication of the source vector by a k*k submatrix of the generator matrix. Since this submatrix is invertible, the second step of the algorithm is to invert this matrix and to multiply the received vector by the obtained matrix to recover the source vector.
[MWS77]）。デコードの最初のステップは、受信した要素に対応する列を考慮することにより得られた発電機マトリックスのk*kサブマトリックスを抽出することです。実際、エンコード要素はソースベクトルにジェネレーターマトリックスの1つの列を掛けることで取得されるため、K*Kサブマトリックスによるソースベクトルの増殖の結果として、K*Kサブマトリックスによるソースベクトルの乗算の結果として考慮されます。。このサブマトリックスは反転可能であるため、アルゴリズムの2番目のステップは、このマトリックスを反転させ、受信したベクトルに取得したマトリックスを掛けてソースベクトルを回復することです。
The decoding algorithm described previously includes the matrix inversion and the vector-matrix multiplication. With the classical Gauss-Jordan algorithm, the matrix inversion requires O(k^^3) operations and the vector-matrix multiplication is performed in O(k^^2) operations.
以前に説明したデコードアルゴリズムには、マトリックスの反転とベクトルマトリックス乗算が含まれます。古典的なガウスヨルダンアルゴリズムでは、マトリックスの反転にはO（k ^^ 3）操作が必要であり、ベクターマトリックスの乗算はO（k ^^ 2）操作で実行されます。
This complexity can be improved by considering that the received submatrix of GM is the product between the inverse of a Vandermonde matrix (V_(k,k)^^-1) and another Vandermonde matrix (denoted by V', which is a submatrix of V_(k,n)). The decoding can be done by multiplying the received vector by V'^^-1 (interpolation problem with complexity O( k * (log(k))^^2) ) then by V_{k,k} (multipoint evaluation with complexity O(k * log(k))). The global decoding complexity is then O((log(k))^^2) operations per source element.
この複雑さは、GMの受信したサブマトリックスがヴァンダーモンドマトリックス（V_（k、k）^^ -1）の逆数と別のヴァンダーモンドマトリックス（v 'で示されています。V_（K、N））。デコードは、受信したベクトルにv '^^ -1（補間の複雑さO（k *（log（k））^^ 2））をv_ {k、k}（複雑さを伴うマルチポイント評価）を掛けることで実行できます。o（k * log（k）））。グローバルデコードの複雑さは、ソース要素ごとのo（（log（k））^^ 2）操作です。
In a packet erasure channel, each packet (including its symbol(s), since packets contain G >= 1 symbols) is either correctly received or erased. The location of the erased symbols in the sequence of symbols MUST be known. The following specification describes the use of Reed-Solomon codes for generating redundant symbols from the k source symbols and for recovering the source symbols from any set of k received symbols.
パケット消去チャネルでは、各パケット（パケットにはg> = 1シンボルが含まれているため、そのシンボルを含む）が正しく受信または消去されます。シンボルのシーケンス内の消去されたシンボルの位置を知っておく必要があります。次の仕様では、Kソース記号から冗長記号を生成し、kの受信記号のセットからソース記号を回復するためのリードソロモンコードの使用について説明します。
The k source symbols of a source block are assumed to be composed of S m-bit elements. Each m-bit element corresponds to an element of the finite field GF(2^^m) through the polynomial representation (Section 8.1). If some of the source symbols contain less than S elements, they MUST be virtually padded with zero elements (this can be the case for the last symbol of the last block of the object). However, this padding does not need to be actually sent with the data to the receivers.
ソースブロックのKソース記号は、S Mビット要素で構成されていると想定されています。各Mビット要素は、多項式表現を介して有限フィールドGF（2 ^^ m）の要素に対応します（セクション8.1）。ソースシンボルの一部にSより少ない要素が含まれている場合、それらはゼロ要素で実質的にパディングする必要があります（これは、オブジェクトの最後のブロックの最後のシンボルに当てはまります）。ただし、このパディングは、データをレシーバーに実際に送信する必要はありません。
The encoding process produces n encoding symbols of size S m-bit elements, of which k are source symbols (this is a systematic code) and n-k are repair symbols (Figure 7). The m-bit elements of the repair symbols are calculated using the corresponding m-bit elements of the source symbol set. A logical u-th source vector, comprised of the u-th elements from the set of source symbols, is used to calculate a u-th encoding vector. This u-th encoding vector then provides the u-th elements for the set encoding symbols calculated for the block. As a systematic code, the first k encoding symbols are the same as the k source symbols, and the last n-k repair symbols are the result of the Reed-Solomon encoding.
エンコーディングプロセスは、サイズs mビット要素のnエンコードシンボルを生成し、そのkはソースシンボル（これは系統的コードです）、n-kは修復記号です（図7）。修復記号のMビット要素は、ソースシンボルセットの対応するMビット要素を使用して計算されます。ソースシンボルのセットからのU番目の要素で構成される論理U-Thソースベクトルは、U-Thエンコードベクトルを計算するために使用されます。このU-Thエンコードベクトルは、ブロックに対して計算されたセットエンコードシンボルのU-Th要素を提供します。系統的コードとして、最初のKエンコードシンボルはKソース記号と同じであり、最後のN-K修復シンボルはリードソロモンエンコードの結果です。
Input: k source symbols
入力：Kソースシンボル
0 u S-1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |X| | source symbol 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |X| | source symbol 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |X| | source symbol k-1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*
*
+--------------------+
| generator matrix |
| GM |
| (k x n) |
+--------------------+
| V
|v
Output: n encoding symbols (source + repair)
出力：nエンコーディングシンボル（ソース修理）
0 u S-1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |X| | enc. symbol 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |X| | enc. symbol 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Y| | enc. symbol n-1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Packet Encoding Scheme
図7：パケットエンコーディングスキーム
An asset of this scheme is that the loss of some encoding symbols produces the same erasure pattern for each of the S encoding vectors. It follows that the matrix inversion must be done only once and will be used by all the S encoding vectors. For large S, this matrix inversion cost becomes negligible in front of the S vector-matrix multiplications.
このスキームの資産は、一部のエンコードシンボルを失うと、各エンコードベクトルに対して同じ消去パターンが生成されることです。したがって、マトリックスの反転は一度だけ行われなければならず、すべてのsエンコードベクトルによって使用されます。大規模なSの場合、このマトリックス反転コストは、Sベクターマトリックス乗算の前で無視できます。
Another asset is that the n-k repair symbols can be produced on demand. For instance, a sender can start by producing a limited number of repair symbols and later on, depending on the observed erasures on the channel, decide to produce additional repair symbols, up to the n-k upper limit. Indeed, to produce the repair symbol e_j, where k <= j < n, it is sufficient to multiply the S source vectors with column j of GM.
別の資産は、N-K修復記号をオンデマンドで作成できることです。たとえば、送信者は、限られた数の修理記号を生成することから始まり、後でチャネルで観察された消去に応じて、N-Kの上限までの追加の修理記号を作成することを決定します。実際、修復記号E_Jを生成するには、k <= j <nでは、SソースベクトルにGMの列jを掛けるだけで十分です。
A content delivery system is potentially subject to many attacks: some of them target the network (e.g., to compromise the routing infrastructure, by compromising the congestion control component), others target the Content Delivery Protocol (CDP) (e.g., to compromise its normal behavior), and finally some attacks target the content itself. Since this document focuses on a FEC building block independently of any particular CDP (even if ALC and NORM are two natural candidates), this section only discusses the additional threats that an arbitrary CDP may be exposed to when using this building block.
コンテンツ配信システムは、多くの攻撃の対象となる可能性があります。それらのいくつかはネットワークをターゲットにします（たとえば、輻輳制御コンポーネントを侵害することにより、ルーティングインフラストラクチャを侵害するため）、コンテンツ配信プロトコル（CDP）をターゲットにする他のもの（例えば、通常を損なうために動作）、最後にいくつかの攻撃はコンテンツ自体をターゲットにします。このドキュメントは、特定のCDPとは無関係にFECビルディングブロックに焦点を当てているため（ALCとNORMが2つの自然候補であっても）、このセクションでは、このビルディングブロックを使用するときに任意のCDPがさらされる可能性のある追加の脅威についてのみ説明します。
More specifically, several kinds of attacks exist:
より具体的には、いくつかの種類の攻撃が存在します：
o those that are meant to give access to confidential content (e.g., in case of non-free content),
o 機密コンテンツにアクセスすることを意図したもの（例：非フリーコンテンツの場合）、
o those that try to corrupt the object being transmitted (e.g., to inject malicious code within an object or to prevent a receiver from using an object),
o 送信されているオブジェクトを破損しようとするもの（たとえば、オブジェクト内に悪意のあるコードを注入するか、受信者がオブジェクトを使用しないようにするため）、
o and those that try to compromise the receiver's behavior (e.g., by making the decoding of an object computationally expensive).
o そして、受信者の動作を妥協しようとするもの（たとえば、オブジェクトのデコードを計算高価にすることにより）。
These attacks can be launched either against the data flow itself (e.g., by sending forged symbols) or against the FEC parameters that are sent either in-band (e.g., in an EXT_FTI or FDT Instance) or out-of-band (e.g., in a session description).
これらの攻撃は、データフロー自体（たとえば、偽造シンボルを送信することにより）または帯域内（例えば、ext_ftiまたはfdtインスタンス）または帯域外（例：セッションの説明で）。
First of all, let us consider the attacks against the data flow.
まず、データフローに対する攻撃を考えてみましょう。
Access control to the object being transmitted is typically provided by means of encryption. This encryption can be done over the whole object (e.g., by the content provider, before the FEC encoding process), or be done on a packet per-packet basis (e.g., when IPsec Encapsulating Security Payload (ESP) is used [RFC4303]). If access control is a concern, it is RECOMMENDED that one of these solutions be used. Even if we mention these attacks here, they are not related nor facilitated by the use of FEC.
送信されるオブジェクトへのアクセス制御は、通常、暗号化によって提供されます。この暗号化は、オブジェクト全体（たとえば、FECエンコーディングプロセスの前にコンテンツプロバイダーによって）で実行されるか、パケットごとにパケットごとに実行できます（たとえば、セキュリティペイロードをカプセル化するIPSEC（ESP）が使用される場合[RFC4303]）。アクセス制御が懸念される場合は、これらのソリューションの1つを使用することをお勧めします。ここでこれらの攻撃に言及したとしても、FECの使用によって関連したり促進されたりしていません。
Protection against corruptions (e.g., after sending forged packets) is achieved by means of a content integrity verification/sender authentication scheme. This service can be provided at the object level, but in that case a receiver has no way to identify which symbol(s) are corrupted if the object is detected as corrupted. This service can also be provided at the packet level. In this case, after removing all forged packets, the object may be recovered sometimes. Several techniques can provide this source authentication/content integrity service:
腐敗に対する保護（たとえば、偽造パケットを送信した後）は、コンテンツの整合性検証/送信者認証スキームによって達成されます。このサービスはオブジェクトレベルで提供できますが、その場合、受信者は、オブジェクトが破損していると検出された場合、どのシンボルが破損しているかを識別する方法がありません。このサービスは、パケットレベルでも提供できます。この場合、すべての鍛造パケットを削除した後、オブジェクトは時々回復することがあります。いくつかの手法では、このソース認証/コンテンツインテグリティサービスを提供できます。
o At the object level, the object MAY be digitally signed (with public key cryptography), for instance by using RSASSA-PKCS1-v1_5 [RFC3447]. This signature enables a receiver to check the object integrity, once the object has been fully decoded. Even if digital signatures are computationally expensive, this calculation occurs only once per object, which is usually acceptable.
o オブジェクトレベルでは、たとえばRSASSA-PKCS1-V1_5 [RFC3447]を使用して、オブジェクトがデジタル署名（公開キー暗号化）に署名することができます（公開キー暗号化）。この署名により、オブジェクトが完全にデコードされたら、受信機がオブジェクトの整合性を確認できます。デジタル署名が計算高価であっても、この計算はオブジェクトごとに1回のみ発生しますが、通常は許容されます。
o At the packet level, each packet can be digitally signed. A major limitation is the high computational and transmission overheads that this solution requires (unless Elliptic Curve Cryptography (ECC) is used). To avoid this problem, the signature may span a set of symbols (instead of a single one) in order to amortize the signature calculation. But if a single symbol is missing, the integrity of the whole set cannot be checked.
o パケットレベルでは、各パケットにデジタル署名できます。主な制限は、このソリューションが必要とする高い計算および伝送オーバーヘッドです（楕円曲線暗号化（ECC）が使用されない限り）。この問題を回避するために、署名の計算を償却するために、署名は（単一のシンボルの代わりに）一連の記号に及ぶことがあります。ただし、単一のシンボルが欠落している場合、セット全体の整合性をチェックできません。
o At the packet level, a Group Message Authentication Code (MAC) [RFC2104] scheme can be used; for instance, by using HMAC-SHA-256 with a secret key shared by all the group members (i.e., the sender(s) and receivers). Thanks to the secret key, this technique creates a cryptographically secured digest of a packet that is sent along with the packet. The Group MAC scheme does not create prohibitive processing load nor transmission overhead, but it has a major limitation: it only provides a group authentication/integrity service since all group members share the same secret group key, which means that each member can send a forged packet. It is therefore restricted to situations where group members are fully trusted (or in association with another technique as a pre-check).
o パケットレベルでは、グループメッセージ認証コード（MAC）[RFC2104]スキームを使用できます。たとえば、すべてのグループメンバー（つまり、送信者と受信機）が共有する秘密キーを持つHMAC-SHA-256を使用することにより。シークレットキーのおかげで、この手法は、パケットとともに送信されるパケットの暗号化されたダイジェストを作成します。Group MACスキームは、法外な処理負荷も張り出しもオーバーヘッドを作成しませんが、大きな制限があります。すべてのグループメンバーが同じシークレットグループキーを共有しているため、グループ認証/整合性サービスを提供します。つまり、各メンバーは偽造を送信できます。パケット。したがって、グループメンバーが完全に信頼されている（または事前チェックとしての別の手法に関連して）状況に制限されています。
o At the packet level, TESLA [RFC4082] is a very attractive and efficient solution that is robust to losses, provides a true authentication/integrity service, and does not create any prohibitive processing load or transmission overhead. Yet checking a packet requires a small delay (a second or more) after its reception.
o パケットレベルでは、Tesla [RFC4082]は、損失に対して堅牢で、真の認証/整合性サービスを提供する非常に魅力的で効率的なソリューションであり、禁止されている処理負荷またはトランスミッションオーバーヘッドを作成しません。しかし、パケットをチェックするには、受信後にわずかな遅延（1秒以上）が必要です。
Techniques relying on public key cryptography (digital signatures and TESLA during the bootstrap process, when used) require that public keys be securely associated to the entities. This can be achieved by a Public Key Infrastructure (PKI), or by a PGP Web of Trust, or by pre-distributing the public keys of each group member.
公開キーの暗号化（使用時にブートストラッププロセス中にデジタル署名とテスラ）に依存する手法では、パブリックキーがエンティティにしっかりと関連する必要があります。これは、公開キーインフラストラクチャ（PKI）、PGP Web of Trust、または各グループメンバーの公開キーを事前に配布することによって達成できます。
Techniques relying on symmetric key cryptography (group MAC) require that a secret key be shared by all group members. This can be achieved by means of a group key management protocol, or simply by pre-distributing the secret key (but this manual solution has many limitations).
対称キー暗号化（グループMAC）に依存する手法では、すべてのグループメンバーが秘密鍵を共有する必要があります。これは、グループキー管理プロトコルによって、または単にシークレットキーを事前に配置することで実現できます（ただし、この手動ソリューションには多くの制限があります）。
It is up to the developer and deployer, who know the security requirements and features of the target application area, to define which solution is the most appropriate. Nonetheless, in case there is any concern of the threat of object corruption, it is RECOMMENDED that at least one of these techniques be used.
ターゲットアプリケーション領域のセキュリティ要件と機能を知っている開発者と展開者次第で、どのソリューションが最も適切かを定義します。それにもかかわらず、オブジェクトの腐敗の脅威に懸念がある場合は、これらの手法の少なくとも1つを使用することをお勧めします。
Let us now consider attacks against the FEC parameters (or FEC OTI). The FEC OTI can either be sent in-band (i.e., in an EXT_FTI or in an FDT Instance containing FEC OTI for the object) or out-of-band (e.g., in a session description). Attacks on these FEC parameters can prevent the decoding of the associated object: for instance, modifying the B parameter will lead to a different block partitioning at a receiver thereby compromising decoding; or setting the m parameter to 16 instead of 8 with FEC Encoding ID 2 will increase the processing load while compromising decoding.
ここで、FECパラメーター（またはFEC OTI）に対する攻撃を考えてみましょう。fec otiは、バンド内（つまり、ext_ftiまたはオブジェクトのfec otiを含むfdtインスタンス）またはバンド外（たとえば、セッションの説明で）のいずれかを送信できます。これらのFECパラメーターへの攻撃により、関連するオブジェクトのデコードが妨げられます。たとえば、Bパラメーターを変更すると、レシーバーでの異なるブロックパーティションが表示され、デコードが損なわれます。または、FECエンコードID 2では、8の代わりにMパラメーターを16に設定すると、デコードが損なわれながら処理荷重が増加します。
It is therefore RECOMMENDED that security measures be taken to guarantee the FEC OTI integrity. To that purpose, the packets carrying the FEC parameters sent in-band in an EXT_FTI header extension SHOULD be protected by one of the per-packet techniques described above: digital signature, group MAC, or TESLA. When FEC OTI is contained in an FDT Instance, this FDT Instance object SHOULD be protected, for instance, by digitally signing it with XML digital signatures [RFC3275]. Finally, when FEC OTI is sent out-of-band (e.g., in a session description), this FEC OTI SHOULD be protected, for instance, by digitally signing the object that includes this FEC OTI.
したがって、FEC OTIの完全性を保証するためにセキュリティ対策を講じることをお勧めします。その目的のために、ext_ftiヘッダー拡張機能で帯域内で送信されたFECパラメーターを運ぶパケットは、上記のパケットごとの手法の1つであるデジタル署名、グループMAC、またはテスラによって保護する必要があります。FEC OTIがFDTインスタンスに含まれている場合、このFDTインスタンスオブジェクトは、たとえば、XMLデジタル署名[RFC3275]でデジタル的に署名することにより、保護する必要があります。最後に、FEC OTIが帯域外に送られる場合（たとえば、セッションの説明で）、このFEC OTIは、このFEC OTIを含むオブジェクトにデジタル署名することにより、保護する必要があります。
The same considerations concerning the key management aspects apply here also.
主要な管理の側面に関する同じ考慮事項もここにも当てはまります。
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 2 under the "ietf:rmt:fec:encoding" name-space to "Reed-Solomon Codes over GF(2^^m)".
このドキュメントでは、「IETF：RMT：FEC：「NAME-SPACE」に「GF（2 ^^ M）」をエンコードする「IETF：RMT：FEC：エンコード」の下に、完全に指定されたFECエンコードID 2を割り当てます。
This document assigns the Fully-Specified FEC Encoding ID 5 under the "ietf:rmt:fec:encoding" name-space to "Reed-Solomon Codes over GF(2^^8)".
このドキュメントでは、「IETF：RMT：FEC：「NAME-SPACE」に「GF（2 ^^ 8）」をエンコードする「IETF：RMT：FEC：エンコード」の下に、完全に指定されたFECエンコードID 5を割り当てます。
This document assigns the FEC Instance ID 0 scoped by the Under-Specified FEC Encoding ID 129 to "Reed-Solomon Codes over GF(2^^8)". More specifically, under the "ietf:rmt:fec:encoding:instance" sub-name-space that is scoped by the "ietf:rmt:fec:encoding" called "Small Block Systematic FEC Codes", this document assigns FEC Instance ID 0 to "Reed-Solomon Codes over GF(2^^8)".
このドキュメントは、不足しているFECインスタンスID 0を、不足しているFECエンコードID 129によって「GF（2 ^^ 8）上のリードソロモンコード」にscopedを割り当てます。より具体的には、「IETF：RMT：FEC：Encoding：Instance」の下で、「IETF：RMT：FEC：「Small Block Systematic FEC Codes」と呼ばれるエンコード」によってスコープされたサブ名ました。このドキュメントは、FECインスタンスIDを割り当てます0から「GF（2 ^^ 8）上のリードソロモンコード」。
The authors want to thank Brian Adamson, Igor Slepchin, Stephen Kent, Francis Dupont, Elwyn Davies, Magnus Westerlund, and Alfred Hoenes for their valuable comments. The authors also want to thank Luigi Rizzo for his comments and for the design of the reference Reed-Solomon codec.
著者は、ブライアン・アダムソン、イゴール・スレプチン、スティーブン・ケント、フランシス・デュポン、エルウィン・デイヴィス、マグナス・ウェスターランド、そして彼らの貴重なコメントに感謝したいと考えています。著者はまた、Luigi Rizzoのコメントと参照リードソロモンコーデックのデザインについて感謝したいと考えています。
[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月。
[RFC5445] Watson, M., "Basic Forward Error Correction (FEC) Schemes", RFC 5445, March 2009.
[RFC5445] Watson、M。、「基本的なフォワードエラー補正（FEC）スキーム」、RFC 5445、2009年3月。
[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月。
[RS-codec] Rizzo, L., "Reed-Solomon FEC codec", available at http://info.iet.unipi.it/~luigi/vdm98/vdm980702.tgz and mirrored at http://planete-bcast.inrialpes.fr/, revised version of July 1998.
[RS-Codec] Rizzo、L。、「Reed-Solomon FEC Codec」、http：//info.iet.unipi.it/~luigi/vdm98/vdm980702.tgzで入手し、http：// planete-bcastでミラーリングされています。.inrialpes.fr/、1998年7月の改訂版。
[Rizzo97] Rizzo, L., "Effective Erasure Codes for Reliable Computer Communication Protocols", ACM SIGCOMM Computer Communication Review Vol.27, No.2, pp.24-36, April 1997.
[Rizzo97] Rizzo、L。、「信頼できるコンピューター通信プロトコルの効果的な消去コード」、ACM Sigcomm Computer Communication Review Vol.27、No.2、pp.24-36、1997年4月。
[MWS77] Mac Williams, F. and N. Sloane, "The Theory of Error Correcting Codes", North Holland, 1977.
[MWS77] Mac Williams、F。およびN. Sloane、「エラー修正コードの理論」、North Holland、1977。
[GO94] Gohberg, I. and V. Olshevsky, "Fast algorithms with preprocessing for matrix-vector multiplication problems", Journal of Complexity, pp. 411-427, vol. 10, 1994.
[GO94] Gohberg、I。およびV. Olshevsky、「マトリックスベクトル乗算の問題に対する前処理を伴う高速アルゴリズム」、Journal of Complexity、pp。411-427、vol。10、1994。
[RFC5170] Roca, V., Neumann, C., and D. Furodet, "Low Density Parity Check (LDPC) Forward Error Correction", RFC 5170, June 2008.
[RFC5170] Roca、V.、Neumann、C。、およびD. Furodet、「低密度パリティチェック（LDPC）前方エラー補正」、RFC 5170、2008年6月。
[RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer, "Raptor Forward Error Correction Scheme", RFC 5053, October 2007.
[RFC5053] Luby、M.、Shokrollahi、A.、Watson、M。、およびT. Stockhammer、「Raptor Forward Error Correction Scheme」、RFC 5053、2007年10月。
[ALC] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", Work in Progress, November 2008.
[ALC] Luby、M.、Watson、M。、およびL. Vicisano、「非同期層コーディング（ALC）プロトコルインスタンス化」、2008年11月、作業進行中。
[NORM] Adamson, B., Bormann, C., Handley, M., and J. Macker, "NACK-Oriented Reliable Multicast Protocol", Work in Progress, March 2009.
[Norm] Adamson、B.、Bormann、C.、Handley、M。、およびJ. Macker、「Nack指向の信頼できるマルチキャストプロトコル」、2009年3月、Work in Progress。
[FLUTE] Paila, T., Walsh, R., Luby, M., Lehtonen, R., and V. Roca, "FLUTE - File Delivery over Unidirectional Transport", Work in Progress, September 2008.
[Flute] Paila、T.、Walsh、R.、Luby、M.、Lehtonen、R.、およびV. Roca、「フルート - 単方向輸送を介したファイル配信」、2008年9月の進行中。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447] Jonsson、J.およびB. Kaliski、「Public-Key Cryptography Standards（PKCS）＃1：RSA暗号仕様バージョン2.1」、RFC 3447、2003年2月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC2104] "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、1997年2月。
[RFC4082] "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005.
[RFC4082]「タイムされた効率的なストリーム損失耐性認証（TESLA）：マルチキャストソース認証変換導入」、RFC 4082、2005年6月。
[RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[RFC3275] EastLake 3rd、D.、Reagle、J。、およびD. Solo、 "（拡張可能なマークアップ言語）XML-Signature構文と処理"、RFC 3275、2002年3月。
Authors' Addresses
著者のアドレス
Jerome Lacan ISAE/LAAS-CNRS 1, place Emile Blouin Toulouse 31056 France
ジェロームラカンイサエ/laas-cnrs 1、場所エミールブルーイントゥールーズ31056フランス
EMail: jerome.lacan@isae.fr
URI: http://pagespro.isae.fr/jerome-lacan/
Vincent Roca INRIA 655, av. de l'Europe Inovallee; Montbonnot ST ISMIER cedex 38334 France
Vincent Roca Inria 655、av。de l'Ueporn Inovallee;Montbonnot St Ismier Cedex 38334フランス
EMail: vincent.roca@inria.fr
URI: http://planete.inrialpes.fr/people/roca/
Jani Peltotalo Tampere University of Technology P.O. Box 553 (Korkeakoulunkatu 1) Tampere FIN-33101 Finland
Jani Peltotalo Tampere Technology P.O.Box 553（Korkeakoulunkatu 1）Tampere Fin-33101フィンランド
EMail: jani.peltotalo@tut.fi
URI: http://mad.cs.tut.fi/
Sami Peltotalo Tampere University of Technology P.O. Box 553 (Korkeakoulunkatu 1) Tampere FIN-33101 Finland
Sami Peltotalo Tampere Technology P.O.Box 553（Korkeakoulunkatu 1）Tampere Fin-33101フィンランド
EMail: sami.peltotalo@tut.fi
URI: http://mad.cs.tut.fi/