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
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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).
この文書では、mは{2..16}であり、データの信頼できる配信への応用GF（2 ^^ M）上のリードソロモンFECコードの完全指定フォワード誤り訂正（FEC）スキームを記載しますパケット消失チャネル（すなわち、パケットがいずれかの任意の破損なく受信または送信中に破棄された通信経路）上のオブジェクト。また、このドキュメントはない符号化シンボルグループが存在しないGFオーバーリードソロモン符号の特殊なケース（2 ^^ 8）のための完全指定FECスキームが記載されています。最後に、下で指定の小ブロックシステマティックFECスキーム（FEC符号化ID 129）の文脈において、本文書は、GF（2 ^ ^ 8）上のリードソロモン符号の特別な場合に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.
リードソロモン符号、すなわち、それらはk個の受信シンボルのセットからK個のソースシンボルを回復するために受信機をイネーブルに、最大距離分離（MDS）符号のクラスに属します。ここで説明するスキームはルイジ・リゾからの実装と互換性があります。
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.
コンテンツの送信またはコンテンツストレージを扱う多くのアプリケーションでは、すでにパケット・ベースのリードソロモン符号に依存しています。特に、それらの多くは、ルイジ・リゾ[RS-コーデック] [Rizzo97]のリードソロモンコーデックを使用します。本書の目標は、このコーデックと互換性のあるリード・ソロモン符号の実装を指定することです。
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は、mは{2..16}であるGF（2 ^^ m）の上リードソロモン符号の使用を指定FEC符号化ID 2、で完全に指定FECスキームを導入します
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はGF（2 ^ ^ 8）上のリードソロモン符号の特別な場合と無しの符号化シンボル群（パケット当たり即ち、正確に一つのシンボル）に焦点を当ててFEC符号化ID 5で完全に指定FECスキームを導入し、そして
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.
アンダー特定小ブロックシステマティックFECスキーム（FEC符号化ID 129）[RFC5445]は、GF（2 ^ ^ 8）上のリードソロモン符号の特別な場合とない符号化FECインスタンスID 0を割り当てるの文脈におけるOシンボルグループ。
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比、即ち、ソースシンボルの数と符号化シンボルの数との比。 <1に近いコードレート<= 1のコードレートがリペアシンボルの数が少ない符号化プロセス中に生成されたことを示す0：定義により、符号化率は、ようなものです。
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.
電力Bに上げB ^^。
a^^-1 the inverse of a.
1の逆 - ^^。
I_k the k*k identity matrix.
K・Kの単位行列I_K。
This document uses the following abbreviations:
このドキュメントでは、次の略語を使用しています：
ESI Encoding Symbol ID.
パパイヤ符号化シンボルID。
FEC OTI FEC Object Transmission Information.
GGのGG Ovgikt伝送情報。
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符号化ID 2、で完全に指定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で構成されています。これら二つのフィールドの長さは次のように（FEC OTIで送信される）パラメータmに依存します。
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ビットのフィールド）は、ペイロード内の符号化シンボル（s）が生成されるオブジェクトのどのソースブロックから識別する。オブジェクトごとに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.
符号化シンボルID（サイズmビットのフィールド）Oソースブロックから生成された特定の符号化シンボル（複数可）を識別は、パケットペイロードで運ばれます。ブロックあたり2つの^^ m個の符号化シンボルの最大値があります。最初のk値（kに、0 - 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.
ソースまたはリペアパケットごとに1つのFECペイロードIDがあるに違いありません。複数の符号化シンボルが同じパケットで送信される場合に符号化シンボルグループの場合には、FECペイロードIDは、パケットの最初のシンボルを指します。他の記号は順次ESIをインクリメントすることにより、第1のシンボルの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.
FECエンコーディングOであり：このセクションで説明する完全に指定された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
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要素を有する有限フィールド上で動作するため）、及びE = 1024バイトであれば、最大転送長さがほぼ等しいです2 ^^ 42バイト（すなわち、4件のテラバイト）。同様に、M = 16、B = 2 ^^ 16 - E = 1024バイトであれば1、及び、最大転送長はまた、2 ^^ 42バイトにほぼ等しいです。大きなオブジェクトの場合、他のFECスキームは、FECペイロードIDで大きなソースブロック番号フィールドで、定義できます。別の解決策は、それらの各々は、上記制限に準拠し、より小さなオブジェクトにラージ・オブジェクトを断片化することからなります。
o Encoding-Symbol-Length (E): a non-negative integer indicating the length of each encoding symbol in bytes.
O符号化シンボル長（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_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スキームで定義されなければなりません。これは、情報の二つの異なる部分が含まれています。
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の二つの可能な符号化フォーマットを示しています。 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:
それはFLUTEセッションのインスタンス[FLUTE】FEC OTIは、FDT（ファイル配信テーブル）で運ばれることが所望される場合、以下のXML属性は、関連するオブジェクトのために記載されなければなりません。
o FEC-OTI-FEC-Encoding-ID
ああFEC-OTI-FECエンコード-ID
o FEC-OTI-Transfer-Length (L)
O FEC-OTI-転送長さ（L）
o FEC-OTI-Encoding-Symbol-Length (E)
FEC-OTI-符号化シンボル長（E）
o FEC-OTI-Maximum-Source-Block-Length (B)
O FEC-OTI-最大ソースブロック長（B）
o FEC-OTI-Max-Number-of-Encoding-Symbols (max_n)
O FEC-OTI-最大数-の符号化シンボル（max_n）
o FEC-OTI-Scheme-Specific-Info
FEC OTI-スキーム固有の情報
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-スキーム特定情報（base64BinaryのセンスXMLスキーマXS）でBase64エンコードの結果の文字列が含まれています。
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：FDTインスタンスに含まれるFEC OTIスキーム固有の情報
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,
何mパラメータは、FEC OTIで実施されるべきではない場合、Mフィールドは、（有効なシード値ではない）を0に設定されています。セクション4.2.3で説明したようにそれ以外の場合は、m個のフィールドには、有効な値が含まれています。同様に、
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.
何GパラメータはFEC OTIで実施されるべきではない場合、Gフィールドは、（有効なシード値されていない）を0に設定されています。セクション4.2.3で説明したようにそれ以外の場合は、Gフィールドは有効な値が含まれています。 mとGは、FEC OTIに運ばれている場合は、送信者は、単にFEC-OTI-スキーム固有-情報属性が省略されています。
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-スキーム固有-info属性に追加されます（64文字のアルファベットで）4印刷可能な文字の文字列に変換されます。
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.
このセクションでは、GF（2 ^^ 8）と無符号化シンボルグループ上リードソロモン符号の特別な場合に焦点を当ててFEC符号化ID 5で完全に指定FECスキームに関連付けられているフォーマットとコードを導入します。
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.
ソースブロック番号（24ビットのフィールド）Oペイロードに符号化シンボルが生成されたオブジェクトのどのソースブロックから識別する。オブジェクトごとに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.
符号化シンボルID（8ビットのフィールド）Oソースブロックから生成された特定の符号化シンボルがパケットペイロードで運ばれているかを識別する。ブロックあたり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.
ソースまたはリペアパケットごとに1つのFECペイロードIDがあるに違いありません。このFECペイロードIDは1とパケットの唯一のシンボルを参照します。
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.
FECエンコーディングOであり：このセクションで説明する完全に指定された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の二つの可能な符号化フォーマットを示しています。 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エンコーディングID 5と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は、FLUTEセッションのFDTインスタンス[FLUTE]で運ばれることが所望される場合、以下のXML属性は、関連するオブジェクトのために記載されなければなりません。
o FEC-OTI-FEC-Encoding-ID o FEC-OTI-Transfer-Length (L)
OH FEC-OTI-FEC-FEC-OTI-転送エンコードO-IDの長さ（50）
o FEC-OTI-Encoding-Symbol-Length (E)
FEC-OTI-符号化シンボル長（E）
o FEC-OTI-Maximum-Source-Block-Length (B)
O FEC-OTI-最大ソースブロック長（B）
o FEC-OTI-Max-Number-of-Encoding-Symbols (max_n)
O FEC-OTI-最大数-の符号化シンボル（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.
このセクションでは、[RFC5052]のセクション9.1で定義されるFEC符号化ID 5、M = 8、G = 1のブロック分割アルゴリズムの場合、FEC符号化IDは2と5に共通する手順を定義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.
1また、符号化シンボルの理論上の最大数である - - 1 = 2 ^^ M - それqは1注Q：有限サイズパラメータは、mは、に等しく、この分野での非ゼロ要素の数を定義しますすなわち、ソースブロックのために製造することができます。 1 = 255符号化シンボル - 例えば、M = 8（デフォルト）2 ^^ 8の最大があります。
Given the target FEC code rate (e.g., provided by the user when starting a FLUTE sending application), the sender calculates:
（アプリケーションを送信FLUTEを開始するとき、例えば、ユーザによって提供された）ターゲットFECコードレートを考えると、送信者は、計算します：
max1_B = floor((2^^m - 1) * CR)
max1_B =フロア（（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 =分（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:
SENDER AT：
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符号化率、（例えば、FLUTE送信アプリケーションを起動するとき）。これは、浮動小数点値として表現されます。
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);
max_n = CEIL（B / CR）。
if (max_n > 2^^m - 1), then return an error ("invalid code rate");
IF（max_n> 2 ^^ M - 1）、エラーを返す（ "無効なコードレート"）。
n = floor(k * max_n / B);
N =フロア（K * max_n / B）。
AT A RECEIVER:
RECEIVER AT：
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
ん
Algorithm:
アルゴリズム：
n = floor(k * max_n / B);
N =フロア（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から抽出されます。リードソロモンデコーダは、「N-アルゴリズム」の受信機部分を使用して、実際のn値を知る必要がないので、ビューの復号化の観点から必要ではありません。
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-アルゴリズム」の受信機の一部を使用するかもしれません。このケースである場合、受信機は、符号化シンボルIDは、優れた又は計算されたn値に等しい（例えば、それは、単にそれらを削除することを選択できる）でシンボルを処理するために準備しなければなりません。
7. Small Block Systematic FEC Scheme (FEC Encoding ID 129) and Reed-Solomon Codes over GF(2^^8)
7.小ブロックシステマティックFECスキーム（FEC符号化ID 129）及びGFオーバーリードソロモン符号（2 ^^ 8）
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）の特別な場合に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.
リード・ソロモン（RS）コード線形ブロック符号です。彼らはまた、MDSコードのクラスに属します。 1.本書に記載の実装は、 - [N、k]は、符号NはQで囲まれ、上側であるn個の符号化要素のシーケンスに有限体GF（q）は上で定義されたk個のソース・エレメントの配列をコード-RS体系的な形に入れVandermonde行列から構築された生成行列に基づきます。
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要素の有限集合として定義されます。必ずしも、pは素数であり、Q = P ^^ m個の要素を含んでいます。パケット消失チャネルで、pは常にフィールドGF（2 ^^ M）の要素（すなわち、GF上（2））より低いまたはそれに等しい程度のm-1個のバイナリ係数を有する多項式で表すことができる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 = 2、 "111"（1 + X + X ^^ 2）
m = 3, "1101", (1+x+x^^3)
M = 3、 "1101"、（1 + X + X ^^ 3）
m = 4, "11001", (1+x+x^^4)
M = 4、 "11001"、（1 + X + X ^^ 4）
m = 5, "101001", (1+x^^2+x^^5)
M = 5、 "101001"、（1 + X 2 + X ^^ ^^ 5）
m = 6, "1100001", (1+x+x^^6) m = 7, "10010001", (1+x^^3+x^^7)
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 = 8、 "101110001"、（1 + X 2 + X ^^ ^^ 3 + X 4 + X ^^ ^^ 8）
m = 9, "1000100001", (1+x^^4+x^^9)
M = 9、 "1000100001"、（1 + X 4 + X ^^ ^^ 9）
m = 10, "10010000001", (1+x^^3+x^^10)
M = 10、 "10010000001"、（1 + X ^ ^ 3 + X ^^ 10）
m = 11, "101000000001", (1+x^^2+x^^11)
M = 11、 "101000000001"、（1 + X 2 + X ^^ ^^ 11）
m = 12, "1100101000001", (1+x+x^^4+x^^6+x^^12)
M = 12、 "1100101000001"、（1 + X + X ^ ^ 4 + X ^^ 6 + X ^^ 12）
m = 13, "11011000000001", (1+x+x^^3+x^^4+x^^13)
M = 13、 "11011000000001"、（1 + X + X ^ ^ 3 + X 4 + X ^^ ^^ 13）
m = 14, "110000100010001", (1+x+x^^6+x^^10+x^^14)
M = 14、 "110000100010001"、（1 + X + X ^^ 6 + X ^ ^ 10 + X ^^ 14）
m = 15, "1100000000000001", (1+x+x^^15)
M = 15、 "1100000000000001"、（1 + X + X ^^ 15）
m = 16, "11010000000010001", (1+x+x^^3+x^^12+x^^16)
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:
GF（2 ^^ m）の上にk個の要素のソースベクトルでS =（s_0、...、S_ {K-1}）してみましょう。 E =は（E_0、...、E_ {N-1}）GF（2 ^^ m）の上にn個の要素の対応する符号ベクトルであるとします。線形符号であり、符号化は、GF（2 ^^ m）の上にk行n列の、生成行列、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.
1と0 <K <= nであること - 私たちはそのN = 2 ^^メートルを考えてみましょう。私たちはアルファによってm個の対応する値の8.1節のリストで選択された次数mの原始多項式の根を表すものとします。私たちはV_ {K、N}で表されるk行n列のVandermonde行列を考えると、次のように構築された：V_ {K、N}の{I、J}項目{I、J} =アルファV_あります^^（iはjは*）、0 <= iが= Kを< - 1、0 <= jの<= N - 1。このマトリックスは、MDSコードを生成します。しかし、このMDSコードは、多くのネットワークアプリケーションのための問題である、体系的ではありません。系統的マトリックス（およびコード）を得るために、最も簡単な解決策は、それを反転し、V_ {によってこの逆を乗算し、次に、V_ {K、N}の最初のk列によって形成される行列V_ {K、K}を考慮することからなりますK、N}。明らかに、製品V_ {K、K} ^^ - 1 * V_ {K、N}は最初のk個の符号化要素はソース・エレメントに等しいことを意味し、その最初のk列の単位行列I_Kを含有します。また、関連するコードは、MDSのプロパティを保持します。
Therefore, the generator matrix of the code considered in this document is:
したがって、本文書において考慮コードの生成行列です。
GM = (V_{k,k}^^-1) * V_{k,n}
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]は[N <N、N-によって形成されるサブ行列を考慮して」、k]は、K <= Nコードを、-RS 'にコードを短縮することができる-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).
符号化は、第1のプリ計算GMによって、およびGM（k行n列）によってソースベクトル（k個の要素）を乗算することにより行うことができます。生成行列の事前計算の複雑さは、n-k個のベクトル（即ち、V_ {K、N}の最後のn-k列）によってVandermonde行列の逆行列の乗算の複雑さを推定することができます。 AKの逆の複雑ため*ベクターによるK-Vandermonde行列はO（K×（（k）をログ）^^ 2）、生成行列は、0（（NK）* K *の計算することができる（ログ（あります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.
符号化はまた、第1演算積S * V_ {K、K} ^^によって行うことができる - 1、次いでV_ {K、N}で結果を乗算することにより。正方Vandermonde行列の逆数による乗算は、補間問題として知られており、その複雑さはO（K×（ログ（K））^^ 2）。 [GO94]で説明したように多評価問題として知られているVandermonde行列による乗算は、高速フーリエ変換を用いてO（（N-K）*ログ（K））を必要とします。この符号化アルゴリズムの総複雑性は、次いでO（（K /（N-K））*（ログ（K））^^ 2 +ログ（k））を修復要素ごとの操作です。
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
消去チャネルのためのリードソロモン復号アルゴリズムは、k個受信要素の任意の集合からk個のソース・エレメントの回復を可能にします。これは、任意のk *は、K部分行列が可逆であるようなものである生成行列の基本的な特性に基づいている（参照
[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個の符号化要素の受信ベクトルは、AKによってソースベクトルの乗算生成行列の* 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.
の部分行列であり、別のVandermonde行列（Vによって表さ」、 - この複雑さは、GMの受信部分行列は、Vandermonde行列（1 V_（K、K）^^）の逆数との積であることを考慮することによって改善することができますV_（K、N））。復号は^^ V 'によって受信されたベクトルを乗算することにより行うことができる - 複雑さと、次にによってV_ {K、K}（マルチ評価1（複雑性O（K×（ログ（K））^^ 2）と補間の問題を） O（k個の*ログ（K）））。グローバルデコーディングの複雑さはO（（ログ（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ビット要素は多項式表現（8.1節）を介して、有限体GF（2 ^^ M）の要素に対応します。ソースシンボルのいくつかは、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.
符号化プロセスは、ソースシンボル（これは系統的コードである）およびN-Kであるリペアシンボル（図7）であるkのサイズS Mビット素子のn個の符号化シンボルを生成します。リペアシンボルのmビットの要素はソースシンボルセットの対応するmビット要素を使用して計算されます。ソースシンボルのセットからのu番目の要素から成る論理U番目のソースベクトルは、U番目の符号化ベクトルを計算するために使用されます。このU番目の符号化ベクトルは、ブロックについて算出セットエンコーディングシンボルのU番目の要素を提供します。組織符号として、最初の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
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のために、この行列反転コストは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の上限まで、追加のリペアシンボルを生成することを決定します。実際、K <= jが<N、GMの列jとSソースベクトルを乗算するのに十分であるリペアシンボルe_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（ALCおよびNORMは、2つの天然の候補である場合であっても）のFECビルディングブロックに焦点を当てているので、このセクションは、このビルディングブロックを使用する場合、任意の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インスタンスで）かout-of-band送信されたFECパラメータのいずれかに対して起動することができますセッション記述で）。
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] ）。アクセス制御が懸念される場合には、これらの解決策の一つが使用することをお勧めします。私たちはここに、これらの攻撃に言及している場合でも、彼らは関連も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]スキームを使用することができます。例えば、すべてのグループメンバー（すなわち、送信者（S）と受信機）によって共有された秘密鍵を用いてHMAC-SHA-256を使用して。秘密鍵のおかげで、この技術は、パケットと一緒に送信されたパケットの暗号化によって確保ダイジェストを作成します。グループ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]は、損失に堅牢で非常に魅力的かつ効率的なソリューションであり、真の認証/完全性サービスを提供し、任意の法外な処理負荷や伝送オーバーヘッドを作成しません。まだパケットをチェックすると、その受信後にわずかな遅延（秒以上）を必要とします。
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によって、または各グループメンバーの事前配布する公開鍵によって達成することができます。
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）に対する攻撃を考えてみましょう。いずれか（セッション記述において、例えば）バンドで（すなわち、EXT_FTI又はFDTインスタンス内のオブジェクトのFEC OTIを含む）または帯域外送信することができるFEC OTI。これらのFECパラメータの攻撃が関連付けられたオブジェクトの復号化を防止することができる：例えば、それによって復号化を損なう受信機における異なるブロック分割につながるBパラメータを変更します。復号化を妥協しながら、またはFEC符号化ID 2と16の代わりに、8にm個のパラメータを設定すると、処理負荷が増大します。
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の整合性を保証するために取られることが推奨されます。デジタル署名、MAC基、又はTESLA：そのために、EXT_FTIヘッダ拡張内のインバンド送信FECパラメータを搬送するパケットは、上述したパケットごとの技術のいずれかによって保護されるべきです。 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)".
「GF（2 ^^ M）上のリードソロモンコード」に名前空間をこの文書では、「：RMT：FEC符号化IETF」で完全に指定された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)".
「GF（2 ^ ^ 8）上のリードソロモンコード」に名前空間をこの文書では、「：RMT：FEC符号化IETF」で完全に指定された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)".
この文書では、「GF（2 ^ ^ 8）上のリードソロモンコード」にアンダー指定FEC符号化ID 129によってスコープFECインスタンスID 0を割り当てます。より具体的には、下の「IETF：RMT：FEC：符号：例えば」サブ名前空間によってスコープされる「IETF：RMT：FEC：エンコーディング」「小ブロックシステマティックFECコード」と呼ばれ、この文書は、FECインスタンスIDを割り当て"GFオーバーリードソロモン符号（2 ^^ 8）" 0。
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.
作者は彼らの貴重なコメントのためにブライアン・アダムソン、イゴールSlepchin、スティーブン・ケント、フランシスデュポン、エルウィン・デイヴィス、マグヌスウェスター、とアルフレッドHoenesに感謝したいと思います。著者らはまた、彼のコメントを参照してリードソロモンコーデックの設計のためのルイジ・リゾに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5052]ワトソン、M.、ルビー、M.、およびL. Vicisano、 "前方誤り訂正（FEC）ビルディングブロック"、RFC 5052、2007年8月。
[RFC5445] Watson, M., "Basic Forward Error Correction (FEC) Schemes", RFC 5445, March 2009.
[RFC5445]ワトソン、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]ルビー、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト、 "信頼できるマルチキャストの前方誤り訂正（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-コーデック] Rizzo氏、L.、http://info.iet.unipi.it/~luigi/vdm98/vdm980702.tgzで利用可能とのhttpでミラー "リードソロモンFECコーデック"、：// PLANETE-BCAST 1998年7月の.inrialpes.fr /、改訂版。
[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コンピュータコミュニケーションレビューVol.27、第2号、pp.24-36、1997年4月。
[MWS77] Mac Williams, F. and N. Sloane, "The Theory of Error Correcting Codes", North Holland, 1977.
[MWS77]マックウィリアムズ、F.およびN.スローン、北オランダ、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、「行列 - ベクトル乗算の問題のための前処理と高速アルゴリズム」、複雑誌、頁411から427まで、体積10、1994。
[RFC5170] Roca, V., Neumann, C., and D. Furodet, "Low Density Parity Check (LDPC) Forward Error Correction", RFC 5170, June 2008.
[RFC5170]ロカ、V.、ノイマン、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]ルビー、M.、ショクロラヒ、A.、ワトソン、M.、およびT. Stockhammer、 "ラプター前方誤り訂正方式"、RFC 5053、2007年10月。
[ALC] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", Work in Progress, November 2008.
[ALC]ルビー、M.、ワトソン、M.、およびL. Vicisanoは、進行中、仕事、2008年11月の "非同期階層は（ALC）プロトコルインスタンスのコーディング"。
[NORM] Adamson, B., Bormann, C., Handley, M., and J. Macker, "NACK-Oriented Reliable Multicast Protocol", Work in Progress, March 2009.
[NORM]アダムソン、B.、ボルマン、C.、ハンドレー、M.、およびJ. Macker、 "NACK指向高信頼マルチキャストプロトコル"、進歩、2009年3月に働いています。
[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.、ウォルシュ、R.、ルビー、M.、Lehtonenの、R.、およびV.ロカ、 "FLUTE - 単方向トランスポート上でファイル配信"、進歩、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]ジョンソン、J.とB. Kaliski、 "公開鍵暗号規格（PKCS）＃1：RSA暗号仕様バージョン2.1"、RFC 3447、2003年2月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（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]イーストレーク3、D.、Reagle、J.、およびD.ソロ "（拡張マークアップ言語）、XML署名の構文および処理"、RFC 3275、2002年3月。
Authors' Addresses
著者のアドレス
Jerome Lacan ISAE/LAAS-CNRS 1, place Emile Blouin Toulouse 31056 France
ジェロームラカンISAE / LAAS-CNRS 1つの場所エミールBlouinの31056トゥールーズフランス
EMail: jerome.lacan@isae.fr URI: http://pagespro.isae.fr/jerome-lacan/
電子メール：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
INRIAヴィンセントロカ655、AV。ドゥヨーロッパInovallée。フランス38334 CEDEX MontbonnotセントIsmier
EMail: vincent.roca@inria.fr URI: http://planete.inrialpes.fr/people/roca/
電子メール：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
テクノロジーのヤニフィールドハウスタンペレ大学、P。ボックス553（Korkeakoulunkatu 1）FIN-33101タンペレフィンランド
EMail: jani.peltotalo@tut.fi URI: http://mad.cs.tut.fi/
電子メール：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
テクノロジーのサミフィールドハウスタンペレ大学、P。ボックス553（Korkeakoulunkatu 1）FIN-33101タンペレフィンランド
EMail: sami.peltotalo@tut.fi URI: http://mad.cs.tut.fi/
電子メール：sami.peltotalo@tut.fi URI：http://mad.cs.tut.fi/