Network Working Group V. Roca
Request for Comments: 5170 INRIA
Category: Standards Track C. Neumann
Thomson
D. Furodet
STMicroelectronics
June 2008
Low Density Parity Check (LDPC) Staircase and Triangle
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）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document describes two Fully-Specified Forward Error Correction (FEC) Schemes, Low Density Parity Check (LDPC) Staircase and LDPC Triangle, and their 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). These systematic FEC codes belong to the well-known class of "Low Density Parity Check" codes, and are large block FEC codes in the sense of RFC 3453.
この文書では、2完全指定前方誤り訂正（FEC）スキーム、低密度パリティチェック（LDPC）階段とLDPCトライアングル、およびパケット消失チャネル（すなわち、パケットの通信経路上のデータ・オブジェクトの信頼性の高い配信への応用を説明しいずれかの）任意の破損なく受信又は送信時に廃棄されます。これらの系統的なFECコードは、「低密度パリティチェック」コードのよく知られたクラスに属し、およびRFC 3453の意味での大きなブロックFECコードです。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Definitions, Notations, and Abbreviations . . . . . . . . . . 3
3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
4. Formats and Codes . . . . . . . . . . . . . . . . . . . . . . 6
4.1. FEC Payload IDs . . . . . . . . . . . . . . . . . . . . . 6
4.2. FEC Object Transmission Information . . . . . . . . . . . 6
4.2.1. Mandatory Element . . . . . . . . . . . . . . . . . . 6
4.2.2. Common Elements . . . . . . . . . . . . . . . . . . . 6
4.2.3. Scheme-Specific Elements . . . . . . . . . . . . . . . 7
4.2.4. Encoding Format . . . . . . . . . . . . . . . . . . . 8
5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Determining the Maximum Source Block Length (B) . . . . . 11
5.3. Determining the Encoding Symbol Length (E) and Number
of Encoding Symbols per Group (G) . . . . . . . . . . . . 12
5.4. Determining the Maximum Number of Encoding Symbols
Generated for Any Source Block (max_n) . . . . . . . . . . 13
5.5. Determining the Number of Encoding Symbols of a Block
(n) . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.6. Identifying the G Symbols of an Encoding Symbol Group . . 14
5.7. Pseudo-Random Number Generator . . . . . . . . . . . . . . 17
6. Full Specification of the LDPC-Staircase Scheme . . . . . . . 19
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Parity Check Matrix Creation . . . . . . . . . . . . . . . 19
6.3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.4. Decoding . . . . . . . . . . . . . . . . . . . . . . . . . 21
7. Full Specification of the LDPC-Triangle Scheme . . . . . . . . 22
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.2. Parity Check Matrix Creation . . . . . . . . . . . . . . . 22
7.3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.4. Decoding . . . . . . . . . . . . . . . . . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 24
8.2. Attacks Against the Data Flow . . . . . . . . . . . . . . 24
8.2.1. Access to Confidential Objects . . . . . . . . . . . . 24
8.2.2. Content Corruption . . . . . . . . . . . . . . . . . . 25
8.3. Attacks Against the FEC Parameters . . . . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Trivial Decoding Algorithm (Informative Only) . . . . 30
[RFC3453] introduces large block FEC codes as an alternative to small block FEC codes like Reed-Solomon. The main advantage of such large block codes is the possibility to operate efficiently on source blocks with a size of several tens of thousands (or more) of source symbols. The present document introduces the Fully-Specified FEC Encoding ID 3 that is intended to be used with the LDPC-Staircase FEC codes, and the Fully-Specified FEC Encoding ID 4 that is intended to be used with the LDPC-Triangle FEC codes [RN04][MK03]. Both schemes belong to the broad class of large block codes. For a definition of the term Fully-Specified Scheme, see Section 4 of [RFC5052].
[RFC3453]は、リードソロモンのような小さなブロックFECコードの代替として大ブロックFECコードを導入します。このような大きなブロック符号の主な利点は、ソースシンボルの数千から数十（またはそれ以上）のサイズを有するソースブロックに効率的に動作する可能性があります。本文書は、RN04 [LDPC-トライアングルFECコードで使用されるように意図されているLDPC-階段FEC符号を使用することを目的として完全に指定されたFEC符号化ID 3、及び完全に指定FEC符号化ID 4を紹介します] [MK03]。どちらの方式では、大きなブロック符号の幅広いクラスに属します。スキーム完全に指定された用語の定義については、[RFC5052]のセクション4を参照してください。
LDPC codes rely on a dedicated matrix, called a "parity check matrix", at the encoding and decoding ends. The parity check matrix defines relationships (or constraints) between the various encoding symbols (i.e., source symbols and repair symbols), which are later used by the decoder to reconstruct the original k source symbols if some of them are missing. These codes are systematic, in the sense that the encoding symbols include the source symbols in addition to the repair symbols.
LDPC符号は、専用のマトリックスに依存して符号化及び復号化端で、「パリティ検査行列」と呼ばれます。パリティ検査行列は、後にそれらの一部が欠落している場合、元のk個のソースシンボルを再構成するためにデコーダによって使用される様々な符号化シンボル（すなわち、ソースシンボルおよびリペアシンボル）の間の関係（または制約）を定義します。これらのコードは、符号化シンボルは、リペアシンボルに加えてソースシンボルを含むという意味で、体系的です。
Since the encoder and decoder must operate on the same parity check matrix, information must be communicated between them as part of the FEC Object Transmission Information.
エンコーダおよびデコーダは同じパリティ検査行列に動作しなければならないので、情報は、FECオブジェクト伝送情報の一部としてそれらの間で通信されなければなりません。
A publicly available reference implementation of these codes is available and distributed under a GNU/LGPL (Lesser General Public License) [LDPC-codec]. Besides, the code extracts included in this document are directly contributed to the IETF process by the authors of this document and by Radford M. Neal.
これらのコードの公的に利用可能なリファレンス実装が利用可能であり、GNU / LGPL（劣等一般公有使用許諾）の下で配布[LDPC-コーデック]です。また、この文書に含まれるコードの抽出物を、直接、この文書の著者によって及びラドフォード・M・ニールによってIETFプロセスに貢献しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This document uses the same terms and definitions as those specified in [RFC5052]. Additionally, it uses the following definitions:
この文書では、[RFC5052]で指定されたものと同一の用語と定義を使用しています。さらに、それは次の定義を使用します。
Source Symbol: a unit of data used during the encoding process
ソースシンボル：符号化プロセス中に使用されるデータの単位
Encoding Symbol: a unit of data generated by the encoding process
符号化シンボル：符号化処理により生成されたデータの単位
Repair Symbol: an 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. The code rate belongs to a ]0; 1] interval. 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]間隔。 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 object 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 denotes the object transfer length in bytes.
Lは、バイト単位でオブジェクト転送長を表します。
k denotes the source block length in symbols, i.e., the number of source symbols of a source block.
kは、すなわち、ソースブロックのソースシンボルの数をシンボル内のソースブロック長を表します。
n denotes the encoding block length, i.e., the number of encoding symbols generated for a source block.
nは、符号化ブロックの長さを示し、すなわち、ソースブロックに対して生成された符号化シンボルの数。
E denotes the encoding symbol length in bytes.
Eは、バイト単位の符号化シンボル長です。
B denotes the maximum source block length in symbols, i.e., the maximum number of source symbols per source block.
Bは、シンボルの最大ソースブロック長、即ち、ソースブロック当たりのソースシンボルの最大数を示します。
N denotes the number of source blocks into which the object shall be partitioned.
Nは、オブジェクトを分割しなければならないその中にソースブロックの数を表します。
G denotes the number of encoding symbols per group, i.e., the number of symbols sent in the same packet.
Gは、グループごとに符号化シンボル、すなわち、同一のパケットで送信されるシンボルの数の数を示します。
CR denotes the "code rate", i.e., the k/n ratio.
CRは、「符号化率」、即ち、K / N比を示します。
max_n denotes the maximum number of encoding symbols generated for any source block. This is in particular the number of encoding symbols generated for a source block of size B.
max_nは、任意のソースブロックに対して生成された符号化シンボルの最大数を示します。これは、特に、サイズBのソースブロックに対して生成された符号化シンボルの数であります
H denotes the parity check matrix.
Hはパリティチェック行列を表します。
N1 denotes the target number of "1s" per column in the left side of the parity check matrix.
N1は、パリティ検査行列の左側の列ごとに「1」の目標数を表します。
N1m3 denotes the value N1 - 3, where N1 is the target number of "1s" per column in the left side of the parity check matrix.
N1は、パリティ検査行列の左側の列当たり「1」の目標数は3、 - N1m3は値N1を表します。
pmms_rand(m) denotes the pseudo-random number generator defined in Section 5.7 that returns a new random integer in [0; m-1] each time it is called.
pmms_rand（m）は[0で新しいランダムな整数を返し、セクション5.7で定義された擬似乱数生成器を表します。 M-1]が呼び出されるたび。
This document uses the following abbreviations:
このドキュメントでは、次の略語を使用しています：
ESI: Encoding Symbol ID
パパイヤ：シンボルIDをエンコード
FEC OTI: FEC Object Transmission Information
THAT GG：GG Ovgikt伝送情報
FPI: FEC Payload ID
FPI：FECペイロードID
LDPC: Low Density Parity Check
LDPC：低密度パリティチェック
PRNG: Pseudo-Random Number Generator
PRNG疑似乱数ジェネレータ
The FEC Payload ID is composed of the Source Block Number and the Encoding Symbol ID:
FECペイロードIDは、ソースブロック番号および符号化シンボルIDで構成されています。
The Source Block Number (12-bit field) identifies from which source block of the object the encoding symbol(s) in the packet payload is(are) generated. There is a maximum of 2^^12 blocks per object. Source block numbering starts at 0.
ソースブロック番号（12ビットのフィールド）は、パケットペイロードにおける符号化シンボル（S）は、オブジェクトのどのソースブロックから発生する（される）を識別する。オブジェクトごとに2つの^^ 12ブロックの最大があります。ソースブロック番号は0から始まります。
The Encoding Symbol ID (20-bit field) identifies which encoding symbol(s) generated from the source block is(are) carried in the packet payload. There is a maximum of 2^^20 encoding symbols per block. The first k values (0 to k-1) identify source symbols, the remaining n-k values (k to n-k-1) identify repair symbols.
符号化シンボルID（20ビットのフィールド）は、ソースブロックから生成された符号化シンボル（単数または複数）を識別するパケットペイロードで運ばれた（されます）。ブロックあたり2 ^^ 20個の符号化シンボルの最大値があります。最初のk値（0 K-1のための）残りのn-k値（N-K-1 k）はリペアシンボルを識別する、ソースシンボルを識別する。
There MUST be exactly one FEC Payload ID per packet. In the 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 thanks to a dedicated function, as explained in Section 5.6
パケットごとに1つのFECペイロードIDがあるに違いありません。複数の符号化シンボルが同じパケットで送信される場合に符号化シンボルグループの場合には、FECペイロードIDは、パケットの最初のシンボルを指します。 5.6節で説明したように他の記号は、最初のシンボルの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 | Encoding Symbol ID (20 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: FEC Payload ID encoding format for FEC Encoding ID 3 and 4
図1：FEC符号化ID 3および4のFECペイロードIDのエンコード形式
o FEC Encoding ID: the LDPC-Staircase and LDPC-Triangle Fully-Specified FEC Schemes use the FEC Encoding ID 3 (Staircase) and 4 (Triangle), respectively.
FEC符号化ID（O）LDPC-階段及びLDPC-トライアングル完全に指定されたFECスキームは、それぞれ、FEC符号化ID 3（階段）及び4（三角）を使用します。
The following elements MUST be defined with the present FEC Schemes:
以下の要素は、本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）：バイト内のオブジェクトの長さを示す負でない整数。サポートできる最大転送長にはいくつかの制限があります。
maximum transfer length = 2^^12 * B * E
最大転送長= 2 ^^ 12 * B * E
For instance, if B=2^^19 (because of a code rate of 1/2, Section 5.2), and if E=1024 bytes, then the maximum transfer length is 2^^41 bytes (or 2 TB). The upper limit, with symbols of size 2^^16-1 bytes and a code rate larger or equal to 1/2, amounts to 2^^47 bytes (or 128 TB).
例えば、もしB = ^^ 19 2、及びもしE = 1024バイト、最大転送長が2 ^^ 41バイト（または2 TB）である（1/2のコードレート、セクション5.2のが原因）。サイズのシンボル2 ^^ 16-1バイトより大きなまたは1/2に等しい符号レートと上限は、2 ^^ 47バイト（または128 TB）になります。
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. There are some restrictions on the maximum B value, as explained in Section 5.2.
O最大ソースブロック長（B）：ソースブロック内のソースシンボルの最大数を示す負でない整数。 5.2節で説明したように最大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. There are some restrictions on the maximum max_n value. In particular max_n is at most equal to 2^^20.
O最大数-の符号化シンボル（max_n）：任意のソースブロックに対して生成された符号化シンボルの最大数を示す負でない整数。最大max_n値にはいくつかの制限があります。特にmax_n 2 ^^ 20にせいぜい等しいです。
Section 5 explains how to define the values of each of these elements.
第5節では、これらの各要素の値を定義する方法について説明します。
The following elements MUST be defined with the present FEC Scheme:
次の要素が存在FECスキームで定義する必要があります。
o N1m3: an integer between 0 (default) and 7, inclusive. The target number of "1s" per column in the left side of the parity check matrix, N1, is then equal to N1m3 + 3 (see Sections 6.2 and 7.2). Using the default value of 0 for N1m3 is recommended when the sender has no information on the decoding scheme used by the receivers. A value greater than 0 for N1m3 can be a good choice in specific situations, e.g., with LDPC-staircase codes when the sender knows that all the receivers use a Gaussian elimination decoding scheme. Nevertheless, the current document does not mandate any specific value. This choice is left to the codec developer.
O N1m3：込み0（デフォルト）と7の間の整数。パリティ検査行列の左側の列当たり「1」の目標数、N1は、（セクション6.2および7.2を参照）N1m3 + 3に等しいです。 N1m3のためのデフォルト値の0を使用すると、送信者が受信機で使用される復号方式についての情報を持っていない場合に推奨されます。送信者は、すべての受信機がスキームを復号ガウス消去法を使用することを知っている場合N1m3 0より大きい値は、LDPC-階段コードで、例えば、特定の状況では良い選択であることができます。それにもかかわらず、現在のドキュメントには、任意の特定の値を強制しません。この選択は、コーデックの開発者に任されています。
o G: an integer between 1 (default) and 31, inclusive, indicating the number of encoding symbols per group (i.e., per packet). The default value is 1, meaning that each packet contains exactly one symbol. Values greater than 1 can also be defined, as explained in Section 5.3.
O G：1（デフォルト）と31の間の整数含め、グループ当たり符号化シンボル（すなわち、パケットあたり）の数を示します。デフォルト値は、各パケットが正確に1つのシンボルを含んでいることを意味し、1です。 5.3節で説明したように1より大きい値も、定義することができます。
o PRNG seed: the seed is a 32-bit unsigned integer between 1 and 0x7FFFFFFE (i.e., 2^^31-2) inclusive. This value is used to initialize the Pseudo-Random Number Generator (Section 5.7).
PRNGシード（O）種子1及び0x7FFFFFFE（すなわち、2 ^^ 31-2）までの間の32ビットの符号なし整数です。この値は、擬似乱数発生器（5.7節）を初期化するために使用されます。
This section shows two possible encoding formats of the above FEC OTI. The present document does not specify when or how these encoding formats should be used.
このセクションでは、上記FEC OTIの二つの可能な符号化フォーマットを示しています。とき、またはどのようにこれらのエンコード形式を使用しなければならない存在文書が指定されていません。
The FEC OTI binary format is the following when the EXT_FTI mechanism is used (e.g., within the Asynchronous Layer Coding (ALC) [RMT-PI-ALC] or NACK-Oriented Reliable Multicast (NORM) [RMT-PI-NORM] protocols).
FEC OTIバイナリフォーマットは以下EXT_FTI機構が使用されている場合（例えば、非同期層符号化（ALC）[RMT-PI-ALC]またはNACK指向高信頼マルチキャスト（NORM）[RMT-PI-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 = 5 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Transfer-Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol Length (E) | N1m3| G | B (MSB) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B (LSB) | Max Nb of Enc. Symbols (max_n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRNG seed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: EXT_FTI Header for FEC Encoding ID 3 and 4
図2：FEC符号化ID 3および4のEXT_FTIヘッダ
In particular:
特に：
o The Transfer-Length (L) field size (48 bits) is larger than the size required to store the maximum transfer length (Section 4.2.2) for field alignment purposes.
O転送長さ（L）フィールドのサイズ（48ビット）フィールドの位置合わせの目的のための最大転送長（4.2.2）を格納するのに必要なサイズよりも大きくなっています。
o The Maximum-Source-Block-Length (B) field (20 bits) is split into two parts: the 8 most significant bits (MSB) are in the third 32- bit word of the EXT_FTI, and the remaining 12 least significant bits (LSB) are in the fourth 32-bit word.
最大ソースブロック長（B）フィールド（20ビット）は2つの部分に分割されている○：8つの最上位ビット（MSB）EXT_FTIの第三の32ビット・ワードであり、残りの12個の最下位ビット（LSB）は第32ビット・ワードです。
When it is desired that the FEC OTI be carried in the File Delivery Table (FDT) Instance of a File Delivery over Unidirectional Transport (FLUTE) session [RMT-FLUTE], the following XML attributes must be described for the associated object:
それは（FLUTE）セッション[RMT-FLUTE]単方向トランスポート上のファイル配信の（FDT）インスタンスFEC OTIがファイル配信テーブルに運ばれることが所望される場合、以下のXML属性は、関連するオブジェクトのために記載されなければなりません。
o FEC-OTI-FEC-Encoding-ID
ああFEC-OTI-FECエンコード-ID
o FEC-OTI-Transfer-length
O FEC-OTI-転送長
o FEC-OTI-Encoding-Symbol-Length
O FEC-OTI-符号化シンボル長
o FEC-OTI-Maximum-Source-Block-Length
O FEC-OTI-最大ソースブロック長
o FEC-OTI-Max-Number-of-Encoding-Symbols
O FEC-OTI-マックス・ナンバー・オブ・エンコーディングシンボル
o FEC-OTI-Scheme-Specific-Info
FEC OTI-スキーム固有の情報
The FEC-OTI-Scheme-Specific-Info contains the string resulting from the Base64 encoding [RFC4648] of the following value:
FEC-OTI-スキーム特定情報は、以下の値のBase64エンコーディング[RFC4648]からの結果の文字列が含まれています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRNG seed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| N1m3| G |
+-+-+-+-+-+-+-+-+
Figure 3: FEC OTI Scheme-Specific Information to be Included in the FDT Instance for FEC Encoding ID 3 and 4
図3：FEC符号化ID 3および4のFDTインスタンスに含まれるFEC OTIスキーム固有の情報
During Base64 encoding, the 5 bytes of the FEC OTI Scheme-Specific Information are transformed into a string of 8 printable characters (in the 64-character alphabet) that is added to the FEC-OTI-Scheme-Specific-Info attribute.
Base64エンコードの際、FEC OTIスキーム固有の情報の5つのバイトは、FEC-OTI-スキーム固有-info属性に追加されます（64文字のアルファベットで）8印刷可能な文字の文字列に変換されます。
This section defines procedures that are common to FEC Encoding IDs 3 and 4.
このセクションは、FEC符号化IDが3と4に共通の手順を定義します。
The B (maximum source block length in symbols), E (encoding symbol length in bytes), and G (number of encoding symbols per group) parameters are first determined. The algorithms of Section 5.2 and
B（シンボルにおける最大ソースブロック長）、E（バイト単位の符号化シンボル長）、およびG（グループ当たり符号化シンボルの数）のパラメータが最初に決定されます。 5.2節のアルゴリズムと
Section 5.3 MAY be used to that purpose. Using other algorithms is possible without compromising interoperability since the B, E, and G parameters are communicated to the receiver by means of the FEC OTI.
5.3節は、その目的のために使用することができます。他のアルゴリズムを使用してB、Eための相互運用性を損なうことなく可能であり、そしてGパラメータは、FEC OTIによって受信機に伝達されます。
Then, the source object MUST be partitioned using the block partitioning algorithm specified in [RFC5052]. To that purpose, the B, L (object transfer length in bytes), and E arguments are provided. As a result, the object is partitioned into N source blocks. These blocks are numbered consecutively from 0 to N-1. The first I source blocks consist of A_large source symbols, the remaining N-I source blocks consist of A_small source symbols. Each source symbol is E bytes in length, except perhaps the last symbol, which may be shorter.
次いで、ソースオブジェクトは、[RFC5052]で指定されたブロック分割アルゴリズムを用いて分配しなければなりません。そのため、B、L（バイトオブジェクト転送長）、及びE引数に提供されます。結果として、オブジェクトがN個のソースブロックに分割されます。これらのブロックは、0からN-1まで連続して番号が付けられています。第IソースブロックがA_largeのソースシンボルから成り、残りのN-IのソースブロックはA_smallのソースシンボルから成ります。各ソースシンボルは、Eが短くなることがあり、おそらく最後のシンボルを除いて、長さがバイトです。
Then, the max_n (maximum number of encoding symbols generated for any source block) parameter is determined. The algorithm in Section 5.4 MAY be used to that purpose. Using another algorithm is possible without compromising interoperability since the max_n parameter is communicated to the receiver by means of the FEC OTI.
次いで、パラメータmax_n（任意のソースブロックに対して生成された符号化シンボルの最大数）が決定されます。 5.4節では、アルゴリズムは、その目的のために使用することができます。別のアルゴリズムを使用することmax_nパラメータはFEC OTIによって受信機に伝達されるので、相互運用性を損なうことなく可能です。
For each block, the actual number of encoding symbols, n, MUST then be determined using the "n-algorithm" detailed in Section 5.5.
各ブロックについて、符号化シンボルの実際の数、Nは、その後、セクション5.5で詳細な「N-アルゴリズム」を用いて決定されなければなりません。
Then, FEC encoding and decoding can be done block per block, independently. To that purpose, a parity check matrix is created, that forms a system of linear equations between the source and repair symbols of a given block, where the basic operator is XOR.
次に、FEC符号化および復号化は、独立して、ブロックごとにブロックを行うことができます。そのために、パリティ検査行列が作成され、基本的なオペレータがXORである所与のブロックのソースおよびリペアシンボル間の線形方程式の系を形成します。
This parity check matrix is logically divided into two parts: the left side (from column 0 to k-1) describes the occurrences of each source symbol in the system of linear equations; the right side (from column k to n-1) describes the occurrences of each repair symbol in the system of linear equations. The only difference between the LDPC-Staircase and LDPC-Triangle schemes is the construction of this right sub-matrix. An entry (a "1") in the matrix at position (i,j) (i.e., at row i and column j) means that the symbol with ESI j appears in equation i of the system.
このパリティ検査行列は、論理的に2つの部分に分割される：（列0からK-1まで）左側は線形方程式のシステムの各ソースシンボルの出現を記述する。 （カラムkからN-1まで）右辺は線形方程式の系における各リペアシンボルの出現を記述する。 LDPC-階段及びLDPC三角形方式の間の唯一の違いは、この右側のサブ行列の構造です。位置（i、j）における行列のエントリは（「1」）（すなわち、行におけるi及び列j）ESI jを有するシンボルは、システムのI式に表示されていることを意味します。
When the parity symbols have been created, the sender transmits source and parity symbols. The way this transmission occurs can largely impact the erasure recovery capabilities of the LDPC-* FEC. In particular, sending parity symbols in sequence is suboptimal. Instead, it is usually recommended to shuffle these symbols. The interested reader will find more details in [NRFF05].
パリティシンボルが作成されている場合は、送信者は、ソースとパリティシンボルを送信します。この送信が発生する方法は、主にLDPC- * FECの消去回復機能に影響を与えることができます。具体的には、順番にパリティシンボルを送信することは最適ではありません。代わりに、通常、これらのシンボルをシャッフルすることをお勧めします。興味のある読者は、[NRFF05]と、より詳細な情報を確認します。
The following sections detail how the B, E, G, max_n, and n parameters are determined (in Sections 5.2, 5.3, 5.4 and 5.5, respectively). Section 5.6 details how Encoding Symbol Groups are created, and finally, Section 5.7 covers the PRNG.
以下のセクションで詳細方法B、E、G、max_n、及びnのパラメータは（セクションはそれぞれ5.2、5.3、5.4及び5.5に）決定されます。符号化シンボルグループが作成され、そして最終的には、セクション5.7はPRNGがどの程度カバーするか、セクション5.6の詳細。
The B parameter (maximum source block length in symbols) depends on several parameters: the code rate (CR), the Encoding Symbol ID field length of the FEC Payload ID (20 bits), as well as possible internal codec limitations.
Bパラメータ（シンボルにおける最大ソースブロック長）は、いくつかのパラメータに依存する：符号レート（CR）、FECペイロードID（20ビット）の符号化シンボルIDフィールドの長さ、並びに可能な内部コーデックの制限。
The B parameter cannot be larger than the following values, derived from the FEC Payload ID limitations, for a given code rate:
Bパラメータは、所与のコードレートのために、FECペイロードIDの制限に由来する、以下の値よりも大きくすることができません。
max1_B = 2^^(20 - ceil(Log2(1/CR)))
max1_B = 2 ^^（20 - CEIL（LOG2（1 / CR）））
Some common max1_B values are:
いくつかの一般的なmax1_B値は以下のとおりです。
o CR == 1 (no repair symbol): max1_B = 2^^20 = 1,048,576
O CR == 1（なし修復シンボル）：max1_B = 2 ^^ 20 = 1,048,576
o 1/2 <= CR < 1: max1_B = 2^^19 = 524,288 symbols
O 1/2 <= CR <1：max1_B = 2 ^^ 19 = 524,288シンボル
o 1/4 <= CR < 1/2: max1_B = 2^^18 = 262,144 symbols
O 1/4 <= CR <1/2：max1_B = 2 ^^ 18 = 262,144シンボル
o 1/8 <= CR < 1/4: max1_B = 2^^17 = 131,072 symbols
O 1/8 <= CR <1/4：max1_B = 2 ^^ 17 = 131,072シンボル
Additionally, a codec MAY impose other limitations on the maximum block size. For instance, this is the case when the codec uses internally 16-bit unsigned integers to store the Encoding Symbol ID, since it does not enable to store all the possible values of a 20-bit field. In that case, if for instance, 1/2 <= CR < 1, then the maximum source block length is 2^^15. Other limitations may also apply, for instance, because of a limited working memory size. This decision MUST be clarified at implementation time, when the target use case is known. This results in a max2_B limitation.
また、コーデックは、最大ブロックサイズに他の制限を課すことができます。例えば、これは、コーデックは、それが20ビットフィールドの全ての可能な値を格納することを可能にしないので、符号化シンボルIDを格納するために内部的に16ビットの符号なし整数を使用する場合です。その場合、例えば、1/2 <= CR <1は、最大ソースブロック長は2 ^^ 15である場合。他の制限もあるため限られたワーキングメモリのサイズを、例えば、適用される場合があります。この決定は、対象ユースケースが知られている場合、実装時に明らかにしなければなりません。これは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介してデコーダに伝達されるので、この計算は単に、符号化器で必要とされることに留意されたいです。
5.3. Determining the Encoding Symbol Length (E) and Number of Encoding Symbols per Group (G)
5.3. 符号化シンボルの長さ（E）と、グループごとに符号化シンボルの数（G）の決定
The E parameter usually depends on the maximum transmission unit on the path (PMTU) from the source to each receiver. In order to minimize the protocol header overhead (e.g., the Layered Coding Transport (LCT), UDP, IPv4, or IPv6 headers in the case of ALC), E is chosen to be as large as possible. In that case, E is chosen so that the size of a packet composed of a single symbol (G=1) remains below but close to the PMTU.
Eパラメータは、通常、各受信機への供給源からのパス（PMTU）上で最大伝送単位に依存します。プロトコルヘッダのオーバーヘッドを最小にするために（例えば、階層符号化トランスポート（LCT）ALCの場合、UDPはIPv4またはIPv6のヘッダ）は、Eは、できるだけ大きくなるように選択されます。単一のシンボル（G = 1）からなるパケットのサイズは、以下のままであるように、その場合には、Eが選択されるが、PMTUに近いです。
However, other considerations can exist. For instance, the E parameter can be made a function of the object transfer length. Indeed, LDPC codes are known to offer better protection for large blocks. In the case of small objects, it can be advantageous to reduce the encoding symbol length (E) in order to artificially increase the number of symbols and therefore the block size.
しかし、他の考慮事項が存在することができます。例えば、Eパラメータは、オブジェクトの転送長の関数とすることができます。確かに、LDPC符号は、大きなブロックのためのより良い保護を提供することが知られています。小さな物体の場合には、人為的にシンボルの数、従って、ブロックサイズを大きくするために、符号化シンボルの長さ（E）を低減するために有利であり得ます。
In order to minimize the protocol header overhead, several symbols can be grouped in the same Encoding Symbol Group (i.e., G > 1). Depending on how many symbols are grouped (G) and on the packet loss rate (G symbols are lost for each packet erasure), this strategy might or might not be appropriate. A balance must therefore be found.
プロトコルヘッダのオーバーヘッドを最小にするために、いくつかのシンボルは、同じ符号化シンボルグループ（即ち、G> 1）にグループ化することができます。 （Gシンボルは、各パケットの消去のために失われた）（G）グループ化されているどのように多くのシンボルにし、パケット損失率に応じて、この戦略は、または適切でない場合があります。バランスがゆえ見つけなければなりません。
The current specification does not mandate any value for either E or G. The current specification only provides an example of possible choices for E and G. Note that this choice is made by the sender, and the E and G parameters are then communicated to the receiver thanks to the FEC OTI. Note also that the decoding algorithm used influences the choice of the E and G parameters. Indeed, increasing the number of symbols will negatively impact the processing load when decoding is based (in part or totally) on Gaussian elimination, whereas the impacts will be rather low when decoding is based on the trivial algorithm sketched in Section 6.4.
現在の仕様では、現在の仕様にのみ、この選択は、送信者によって行われ、EとGのパラメータは、その後に伝達されることEおよびG注可能な選択肢の例を提供するEまたはGのいずれかのために任意の値を強制しませんFEC OTIに受信機のおかげ。復号アルゴリズムが影響をEとGのパラメータの選択を使用することにも留意されたいです。復号化が（部分的にまたは完全に）基づいている場合、復号は、セクション6.4に描か些細なアルゴリズムに基づいている場合の影響がかなり低くなるのに対し、実際に、シンボルの数を増やすと、負、ガウスの消去の処理負荷に影響を与えます。
Example:
例：
Let us assume that the trivial decoding algorithm sketched in Section 6.4 is used. First, define the target packet payload size, pkt_sz (at most equal to the PMTU minus the size of the various protocol headers). The pkt_sz must be chosen in such a way that the symbol size is an integer. This can require that pkt_sz be a multiple of 4, 8, or 16 (see the table below). Then calculate the number of packets in the object: nb_pkts = ceil(L / pkt_sz). Finally, thanks to nb_pkts, use the following table to find a possible G value.
私たちは、6.4節でスケッチ些細なデコードアルゴリズムが使用されていると仮定しましょう。まず、pkt_sz（PMTUマイナス種々のプロトコルヘッダのサイズに最大で等しい）、ターゲット・パケット・ペイロード・サイズを定義します。 pkt_szシンボル・サイズが整数であるように選択されなければなりません。これはそのpkt_szは、4,8、または16の倍数である必要ができる（以下の表を参照）。 nb_pkts = CEIL（L / pkt_sz）：そのオブジェクト内のパケットの数を計算します。最後に、nb_pktsのおかげで、可能なG値を検索するには、次の表を使用します。
+------------------------+----+-------------+-------------------+
| Number of packets | G | Symbol size | k |
+------------------------+----+-------------+-------------------+
| 4000 <= nb_pkts | 1 | pkt_sz | 4000 <= k |
| | | | |
| 1000 <= nb_pkts < 4000 | 4 | pkt_sz / 4 | 4000 <= k < 16000 |
| | | | |
| 500 <= nb_pkts < 1000 | 8 | pkt_sz / 8 | 4000 <= k < 8000 |
| | | | |
| 1 <= nb_pkts < 500 | 16 | pkt_sz / 16 | 16 <= k < 8000 |
+------------------------+----+-------------+-------------------+
5.4. Determining the Maximum Number of Encoding Symbols Generated for Any Source Block (max_n)
5.4. 任意のソースブロック（max_n）のために生成された符号化シンボルの最大数を決定します
The following algorithm MAY be used by a sender to determine the maximum number of encoding symbols generated for any source block (max_n) as a function of B and the target code rate. Since the max_n parameter is communicated to the decoder by means of the FEC OTI, another method MAY be used to determine max_n.
以下のアルゴリズムは、Bの関数と目標符号レートなどの任意のソースブロック（max_n）に対して生成符号化シンボルの最大数を決定するために、送信者によって使用されてもよいです。 max_nパラメータがFEC OTIによってデコーダに伝達されるので、別の方法ではmax_nを決定するために使用され得ます。
Input:
入力：
B: Maximum source block length, for any source block. Section 5.2 MAY be used to determine its value.
B：最大ソースブロック長、任意のソースブロックの。 5.2節では、その値を決定するために使用され得ます。
CR: FEC code rate, which is provided by the user (e.g., when starting a FLUTE sending application). It is expressed as a floating point value. The CR value must be such that the resulting number of encoding symbols per block is at most equal to 2^^20 (Section 4.1).
CR：ユーザによって提供されるFEC符号化率、（例えば、FLUTE送信アプリケーションを起動するとき）。これは、浮動小数点値として表現されます。 CR値は、ブロックごとの符号化シンボルが得られる数が2 ^^ 20（セクション4.1）に多くとも等しくなるようなものでなければなりません。
Output:
出力：
max_n: Maximum number of encoding symbols generated for any source block.
max_n：任意のソースブロックに対して生成された符号化シンボルの最大数。
Algorithm:
アルゴリズム：
max_n = ceil(B / CR);
max_n = CEIL（B / CR）。
if (max_n > 2^^20), then return an error ("invalid code rate");
（max_n> 2 ^^ 20）場合、エラー（ "無効なコードレート"）を返します。
(NB: if B has been defined as explained in Section 5.2, this error should never happen.)
（NBは：5.2節で説明したようにBが定義されている場合、このエラーは発生しません。）
The following algorithm, also called "n-algorithm", MUST be used by the sender and the receiver to determine the number of encoding symbols for a given block (n) as a function of B, k, and max_n.
また、「N-アルゴリズム」と呼ばれる以下のアルゴリズムは、B、K、及びmax_nの関数として所与のブロックのための符号化シンボル（N）の数を決定するために、送信者と受信者によって使用されなければなりません。
Input:
入力：
B: Maximum source block length, for any source block. At a sender, Section 5.2 MAY be used to determine its value. At a receiver, this value MUST be extracted from the received FEC OTI.
B：最大ソースブロック長、任意のソースブロックの。送信側では、5.2節では、その値を決定するために使用され得ます。受信機において、この値は、受信されたFEC OTIから抽出しなければなりません。
k: Current source block length. At a sender or receiver, the block partitioning algorithm MUST be used to determine its value.
K：現在のソースブロック長。送信側または受信側において、ブロック分割アルゴリズムは、その値を決定するために使用されなければなりません。
max_n: Maximum number of encoding symbols generated for any source block. At a sender, Section 5.4 MAY be used to determine its value. At a receiver, this value MUST be extracted from the received FEC OTI.
max_n：任意のソースブロックに対して生成された符号化シンボルの最大数。送信側では、5.4節では、その値を決定するために使用され得ます。受信機において、この値は、受信されたFEC OTIから抽出しなければなりません。
Output:
出力：
n: Number of encoding symbols generated for this source block.
N：このソースブロックに対して生成された符号化シンボルの数。
Algorithm:
アルゴリズム：
n = floor(k * max_n / B);
N =フロア（K * max_n / B）。
When multiple encoding symbols are sent in the same packet, the FEC Payload ID information of the packet MUST refer to the first encoding symbol. It MUST then be possible to identify each symbol from this single FEC Payload ID. To that purpose, the symbols of an Encoding Symbol Group (i.e., packet):
複数の符号化シンボルが同じパケットで送信される場合、パケットのFECペイロードID情報は、第1の符号化シンボルを参照しなければなりません。この単一のFECペイロードIDから各シンボルを識別することができなければなりません。そのため、符号化シンボルグループ（すなわち、パケット）のシンボルに：
o MUST all be either source symbols or repair symbols. Therefore, only source packets and repair packets are permitted, not mixed ones.
Oは、すべてのソースシンボルまたはリペアシンボルのいずれかでなければなりません。したがって、唯一のソースパケットとリペアパケットは、混合したものではないが許可されています。
o are identified by a function, sender(resp. receiver)_find_ESIs_of_group(), that takes as argument:
O引数として取る関数は、送信者（RESPレシーバ）_find_ESIs_of_group（）によって識別されます。
* for a sender, the index of the Encoding Symbol Group (i.e., packet) that the application wants to create,
*送信者のために、符号化シンボルグループ（すなわち、パケット）アプリケーションを作成するために望んでいることの指標、
* for a receiver, the ESI information contained in the FEC Payload ID.
*受信機、FECペイロードIDに含まESI情報について。
and returns a list of G Encoding Symbol IDs. In the case of a source packet, the G Encoding Symbol IDs are chosen consecutively, by incrementing the ESI. In the case of a repair packet, the G repair symbols are chosen randomly, as explained below.
そしてG符号化シンボルIDのリストを返します。ソースパケットの場合には、G符号化シンボルIDは、ESIを増分することによって、連続的に選択されます。以下に説明するように修復パケットの場合には、Gのリペアシンボルは、ランダムに選択されています。
o are stored in sequence in the packet, without any padding. In other words, the last byte of the i-th symbol is immediately followed by the first byte of (i+1)-th symbol.
O任意のパディングなしで、パケットのシーケンスに格納されています。換言すれば、i番目のシンボルの最後のバイトを直ちに（I + 1）番目のシンボルの最初のバイトが続きます。
The system must first be initialized by creating a random permutation of the n-k indexes. This initialization function MUST be called immediately after creating the parity check matrix. More precisely, since the PRNG seed is not re-initialized, there must not have been a call to the PRNG function between the time the parity check matrix has been initialized and the time the following initialization function is called. This is true both at a sender and at a receiver.
システムは、最初のn-k個のインデックスのランダム順列を作成することによって初期化されなければなりません。この初期化関数は、パリティ検査行列を作成した直後に呼び出さなければなりません。 PRNGシードが再初期化されていないので、より正確には、パリティ検査行列が初期化されている時間と、次の初期化関数が呼び出されるまでの間PRNG関数の呼び出しがあったてはいけません。これは、送信側と受信時の両方で真です。
int *txseqToID;
int *IDtoTxseq;
/*
* Initialization function.
* Warning: use only when G > 1.
*/
void
initialize_tables ()
{
int i;
int randInd;
int backup;
txseqToID = malloc((n-k) * sizeof(int));
IDtoTxseq = malloc((n-k) * sizeof(int));
if (txseqToID == NULL || IDtoTxseq == NULL)
handle the malloc failures as appropriate...
/* initialize the two tables that map ID
* (i.e., ESI-k) to/from TxSequence. */
for (i = 0; i < n - k; i++) {
IDtoTxseq[i] = i;
txseqToID[i] = i;
}
/* now randomize everything */
for (i = 0; i < n - k; i++) {
randInd = pmms_rand(n - k);
backup = IDtoTxseq[i];
IDtoTxseq[i] = IDtoTxseq[randInd];
IDtoTxseq[randInd] = backup;
txseqToID[IDtoTxseq[i]] = i;
txseqToID[IDtoTxseq[randInd]] = randInd;
}
return;
}
It is then possible, at the sender, to determine the sequence of G Encoding Symbol IDs that will be part of the group.
それは、グループの一部となるG符号化シンボルIDの配列を決定するために、送信側では、可能です。
/*
* Determine the sequence of ESIs for the packet under construction
* at a sender.
* Warning: use only when G > 1.
* PktIdx (IN): index of the packet, in
* {0..ceil(k/G)+ceil((n-k)/G)} range
* ESIs[] (OUT): list of ESIs for the packet
*/
void
sender_find_ESIs_of_group (int PktIdx,
ESI_t ESIs[])
{
int i;
if (PktIdx < nbSourcePkts) {
/* this is a source packet */
ESIs[0] = PktIdx * G;
for (i = 1; i < G; i++) {
ESIs[i] = (ESIs[0] + i) % k;
}
} else {
/* this is a repair packet */
for (i = 0; i < G; i++) {
ESIs[i] =
k +
txseqToID[(i + (PktIdx - nbSourcePkts) * G)
% (n - k)];
}
}
return;
}
Similarly, upon receiving an Encoding Symbol Group (i.e., packet), a receiver can determine the sequence of G Encoding Symbol IDs from the first ESI, esi0, that is contained in the FEC Payload ID.
同様に、符号化シンボルグループ（すなわち、パケット）を受信すると、受信機は、FECペイロードIDに含まれる最初のESI、esi0、からG符号化シンボルIDの配列を決定することができます。
/*
* Determine the sequence of ESIs for the packet received.
* Warning: use only when G > 1.
* esi0 (IN): : ESI contained in the FEC Payload ID
* ESIs[] (OUT): list of ESIs for the packet
*/
void
receiver_find_ESIs_of_group (ESI_t esi0,
ESI_t ESIs[])
{
int i;
if (esi0 < k) {
/* this is a source packet */
ESIs[0] = esi0;
for (i = 1; i < G; i++) {
ESIs[i] = (esi0 + i) % k;
}
} else {
/* this is a repair packet */
for (i = 0; i < G; i++) {
ESIs[i] =
k +
txseqToID[(i + IDtoTxseq[esi0 - k])
% (n - k)];
}
}
}
The FEC Encoding IDs 3 and 4 rely on a pseudo-random number generator (PRNG) that must be fully specified, in particular in order to enable the receivers and the senders to build the same parity check matrix.
FEC符号化IDが3と4は、完全に同一のパリティ検査行列を構築するための受信機および送信を可能にするために、特に指定されなければならない擬似乱数生成器（PRNG）に依存しています。
The Park-Miler "minimal standard" PRNG [PM88] MUST be used. It defines a simple multiplicative congruential algorithm: Ij+1 = A * Ij (modulo M), with the following choices: A = 7^^5 = 16807 and M = 2^^31 - 1 = 2147483647. A validation criteria of such a PRNG is the following: if seed = 1, then the 10,000th value returned MUST be equal to 1043618065.
パーク・ミレル「最小標準」PRNG [PM88]使用しなければなりません。そのような1 = 2147483647検証基準 - A = 7 ^^ 5 = 16807およびM = 2 ^^ 31：+ 1 = A * Ijの（モジュロM）、次の選択肢とIjの：これは、単純な乗法合同アルゴリズムを定義しますPRNGは、以下：シード= 1は、戻さ10,000値は1043618065に等しくなければならない場合。
Several implementations of this PRNG are known and discussed in the literature. An optimized implementation of this algorithm, using only 32-bit mathematics, and which does not require any division, can be found in [rand31pmc]. It uses the Park and Miller algorithm [PM88] with the optimization suggested by D. Carta in [CA90]. The history behind this algorithm is detailed in [WI08]. Yet, any other
このPRNGのいくつかの実装では知られており、文献に記載されています。任意の分割を必要としない最適化されただけの32ビットの数学を使用して、このアルゴリズムの実装、および、[rand31pmc]に見出すことができます。これは、[CA90]でD.カルタによって提案された最適化と公園とミラーアルゴリズム[PM88]を使用しています。このアルゴリズムの背後にある歴史は[WI08]で詳細です。しかし、他の
implementation of the PRNG algorithm that matches the above validation criteria, like the ones detailed in [PM88], is appropriate.
上記検証条件に一致するPRNGアルゴリズムの実装は、[PM88]に詳述されたもののような、適切です。
This PRNG produces, natively, a 31-bit value between 1 and 0x7FFFFFFE (2^^31-2) inclusive. Since it is desired to scale the pseudo-random number between 0 and maxv-1 inclusive, one must keep the most significant bits of the value returned by the PRNG (the least significant bits are known to be less random, and modulo-based solutions should be avoided [PTVF92]). The following algorithm MUST be used:
このPRNGは、ネイティブ、1及び0x7FFFFFFE（2 ^^ 31-2）までの間の31ビット値を生成します。それが0とMAXV-1までの間の擬似乱数を拡張することが望まれるので、一つはPRNG（最下位ビットが少なく、ランダムであることが知られており、モジュロベースのソリューションによって返される値の最上位ビットを保持しなければなりません）[PTVF92]避けるべきです。次のアルゴリズムを使用しなければなりません。
Input:
入力：
raw_value: random integer generated by the inner PRNG algorithm, between 1 and 0x7FFFFFFE (2^^31-2) inclusive.
RAW_VALUE：1と0x7FFFFFFE（2 ^^ 31-2）までの間の内部PRNGアルゴリズムによって生成されたランダムな整数、。
maxv: upper bound used during the scaling operation.
MAXV：スケーリング操作中に使用上限。
Output:
出力：
scaled_value: random integer between 0 and maxv-1 inclusive.
scaled_value：0とMAXV-1までの間のランダムな整数。
Algorithm:
アルゴリズム：
scaled_value = (unsigned long) ((double)maxv * (double)raw_value / (double)0x7FFFFFFF);
scaled_value =（unsigned long型）（（二重）MAXV *（二重）RAW_VALUE /（ダブル）0x7FFFFFFFで）。
(NB: the above C type casting to unsigned long is equivalent to using floor() with positive floating point values.)
（NB：上記C型鋳造符号なしlongには、正の浮動小数点値で床（）を使用するのと同じです。）
In this document, pmms_rand(maxv) denotes the PRNG function that implements the Park-Miller "minimal standard" algorithm, defined above, and that scales the raw value between 0 and maxv-1 inclusive, using the above scaling algorithm. Additionally, a function should be provided to enable the initialization of the PRNG with a seed (i.e., a 31-bit integer between 1 and 0x7FFFFFFE inclusive) before calling pmms_rand(maxv) the first time.
この文書、pmms_rand（MAXV）において上記で定義されたパーク・ミラー「最小標準」アルゴリズムを実装PRNG関数を示し、それは、上記のスケーリングアルゴリズムを使用して、0とMAXV-1までの間の生の値をスケーリングします。また、関数はpmms_rand（MAXV）最初の時間を呼び出す前に、シード（1と0x7FFFFFFEまでの間、すなわち、31ビットの整数）とPRNGの初期化を可能にするために提供されるべきです。
The LDPC-Staircase scheme is identified by the Fully-Specified FEC Encoding ID 3.
LDPC-階段方式は完全に指定FEC符号化ID 3によって識別されます。
The PRNG used by the LDPC-Staircase scheme must be initialized by a seed. This PRNG seed is an instance-specific FEC OTI attribute (Section 4.2.3).
LDPC-階段スキームで使用されるPRNGはシードで初期化する必要があります。このPRNGシードは、インスタンス固有のFEC OTIの属性（4.2.3項）です。
The LDPC-Staircase matrix can be divided into two parts: the left side of the matrix defines in which equations the source symbols are involved; the right side of the matrix defines in which equations the repair symbols are involved.
LDPC-階段行列は二つの部分に分けることができる：マトリックスの左側には、ソースシンボルが関与方程式た定義します。行列の右側には、リペアシンボルが関与方程式た定義します。
The left side MUST be generated by using the following function:
左側は次の関数を用いて生成しなければなりません。
/*
* Initialize the left side of the parity check matrix.
* This function assumes that an empty matrix of size n-k * k has
* previously been allocated/reset and that the matrix_has_entry(),
* matrix_insert_entry() and degree_of_row() functions can access it.
* (IN): the k, n and N1 parameters.
*/
void left_matrix_init (int k, int n, int N1)
{
int i; /* row index or temporary variable */
int j; /* column index */
int h; /* temporary variable */
int t; /* left limit within the list of possible choices u[] */
int u[N1*MAX_K]; /* table used to have a homogeneous 1 distrib. */
/* Initialize a list of all possible choices in order to
* guarantee a homogeneous "1" distribution */
for (h = N1*k-1; h >= 0; h--) {
u[h] = h % (n-k);
}
/* Initialize the matrix with N1 "1s" per column, homogeneously */
t = 0;
for (j = 0; j < k; j++) { /* for each source symbol column */
for (h = 0; h < N1; h++) { /* add N1 "1s" */
/* check that valid available choices remain */
for (i = t; i < N1*k && matrix_has_entry(u[i], j); i++);
if (i < N1*k) {
/* choose one index within the list of possible
* choices */
do {
i = t + pmms_rand(N1*k-t);
} while (matrix_has_entry(u[i], j));
matrix_insert_entry(u[i], j);
/* replace with u[t] which has never been chosen */
u[i] = u[t];
t++;
} else {
/* no choice left, choose one randomly */
do {
i = pmms_rand(n-k);
} while (matrix_has_entry(i, j));
matrix_insert_entry(i, j);
}
}
}
/* Add extra bits to avoid rows with less than two "1s".
* This is needed when the code rate is smaller than 2/(2+N1) */
for (i = 0; i < n-k; i++) { /* for each row */
if (degree_of_row(i) == 0) {
j = pmms_rand(k);
matrix_insert_entry(i, j);
}
if (degree_of_row(i) == 1) {
do {
j = pmms_rand(k);
} while (matrix_has_entry(i, j));
matrix_insert_entry(i, j);
}
}
}
The right side (the staircase) MUST be generated by using the following function:
右側（階段）は、次の関数を用いて生成しなければなりません。
/*
* Initialize the right side of the parity check matrix with a
* staircase structure.
* (IN): the k and n parameters.
*/
void right_matrix_staircase_init (int k, int n)
{
int i; /* row index */
matrix_insert_entry(0, k); /* first row */
for (i = 1; i < n-k; i++) { /* for the following rows */
matrix_insert_entry(i, k+i); /* identity */
matrix_insert_entry(i, k+i-1); /* staircase */
}
}
Note that just after creating this parity check matrix, when Encoding Symbol Groups are used (i.e., G > 1), the function initializing the two random permutation tables (Section 5.6) MUST be called. This is true both at a sender and at a receiver.
ちょうど符号化シンボルグループが使用される場合、このパリティ検査行列を作成した後（即ち、G> 1）、2つのランダム順列テーブル（セクション5.6）を初期化関数が呼び出さなければならないことに留意されたいです。これは、送信側と受信時の両方で真です。
Thanks to the staircase matrix, repair symbol creation is straightforward: each repair symbol is equal to the sum of all source symbols in the associated equation, plus the previous repair symbol (except for the first repair symbol). Therefore, encoding MUST follow the natural repair symbol order: start with the first repair symbol and generate a repair symbol with ESI i before a symbol with ESI i+1.
階段行列のおかげで、リペアシンボルの作成は容易である：各リペアシンボルは、関連する式のすべてのソースシンボルの合計、プラス（第リペアシンボルを除く）前リペアシンボルに等しいです。したがって、符号化は、天然の修復シンボル順序に従う必要があります最初の修復シンボルで始まり、ESI I + 1シンボル前ESI Iとリペアシンボルを生成します。
Decoding basically consists in solving a system of n-k linear equations whose variables are the n source and repair symbols. Of course, the final goal is to recover the value of the k source symbols only.
復号は、基本的には、変数NソースおよびリペアシンボルであるN-k個の線形方程式の系を解くことにあります。もちろん、最終的な目標は、唯一のk個のソースシンボルの値を回復することです。
To that purpose, many techniques are possible. One of them is the following trivial algorithm [ZP74]: given a set of linear equations, if one of them has only one remaining unknown variable, then the value of this variable is that of the constant term. So, replace this variable by its value in all the remaining linear equations and reiterate. The value of several variables can therefore be found recursively. Applied to LDPC FEC codes working over an erasure channel, the parity check matrix defines a set of linear equations whose variables are the source symbols and repair symbols. Receiving or decoding a symbol is equivalent to having the value of a variable. Appendix A sketches a possible implementation of this algorithm.
その目的のために、多くの技術が可能です。それらの一つは、以下の些細なアルゴリズムは[ZP74]である：それらのいずれか一方のみの未知の変数の残りがある場合、線形方程式のセットを与えられ、その後、この変数の値は、定数項のことです。だから、残りのすべての線形方程式で、その値によって、この変数を交換して繰り返します。いくつかの変数の値は、したがって、再帰的に見つけることができます。消去チャネルを介して作業LDPCのFEC符号に適用され、パリティ検査行列は、変数ソースシンボルおよびリペアシンボルである線形方程式のセットを定義します。シンボルを受信又は復号する変数の値を有することと等価です。付録Aは、このアルゴリズムの可能な実装をスケッチ。
A Gaussian elimination (or any optimized derivative) is another possible decoding technique. Hybrid solutions that start by using the trivial algorithm above and finish with a Gaussian elimination are also possible [CR08].
ガウスの消去（又は任意の最適化された誘導体）は、別の可能な復号化技術です。上に些細なアルゴリズムを用いて開始し、ガウスの消去法で仕上げハイブリッドソリューションも可能[CR08]います。
Because interoperability does not depend on the decoding algorithm used, the current document does not recommend any particular technique. This choice is left to the codec developer.
相互運用性は、使用復号化アルゴリズムに依存しないので、現在の文書は、特定の技術を推奨していません。この選択は、コーデックの開発者に任されています。
However, choosing a decoding technique will have great practical impacts. It will impact the erasure capabilities: a Gaussian elimination enables to solve the system with a smaller number of known symbols compared to the trivial technique. It will also impact the CPU load: a Gaussian elimination requires more processing than the above trivial algorithm. Depending on the target use case, the codec developer will favor one feature or the other.
しかし、復号化技術を選択することが実用上大きな影響を持つことになります。これは、消去機能に影響を与える：ガウス消去は自明の技術に比べて既知シンボルの数が少ないシステムを解決することが可能となります。また、CPUの負荷に影響を与えます：ガウスの消去は、上記の些細なアルゴリズムよりも多くの処理が必要となります。ターゲット・ユースケースによっては、コーデックの開発者は、一つの特徴や他のを好むでしょう。
LDPC-Triangle is identified by the Fully-Specified FEC Encoding ID 4.
LDPC-三角形が完全指定FEC符号化ID 4によって識別されます。
The PRNG used by the LDPC-Triangle scheme must be initialized by a seed. This PRNG seed is an instance-specific FEC OTI attribute (Section 4.2.3).
LDPC-トライアングル方式で使用さPRNGはシードで初期化する必要があります。このPRNGシードは、インスタンス固有のFEC OTIの属性（4.2.3項）です。
The LDPC-Triangle matrix can be divided into two parts: the left side of the matrix defines in which equations the source symbols are involved; the right side of the matrix defines in which equations the repair symbols are involved.
LDPC-三角行列は二つの部分に分けることができる：マトリックスの左側には、ソースシンボルが関与方程式た定義します。行列の右側には、リペアシンボルが関与方程式た定義します。
The left side MUST be generated by using the same left_matrix_init() function as with LDPC-Staircase (Section 6.2).
左側は、LDPC-階段（セクション6.2）と同じleft_matrix_init（）関数を用いて生成されなければなりません。
The right side (the triangle) MUST be generated by using the following function:
右側（三角形）は次の関数を用いて生成しなければなりません。
/*
* Initialize the right side of the parity check matrix with a
* triangle structure.
* (IN): the k and n parameters.
*/
void right_matrix_staircase_init (int k, int n)
{
int i; /* row index */
int j; /* randomly chosen column indexes in 0..n-k-2 */
int l; /* limitation of the # of "1s" added per row */
matrix_insert_entry(0, k); /* first row */
for (i = 1; i < n-k; i++) { /* for the following rows */
matrix_insert_entry(i, k+i); /* identity */
matrix_insert_entry(i, k+i-1); /* staircase */
/* now fill the triangle */
j = i-1;
for (l = 0; l < j; l++) { /* limit the # of "1s" added */
j = pmms_rand(j);
matrix_insert_entry(i, k+j);
}
}
}
Note that just after creating this parity check matrix, when Encoding Symbol Groups are used (i.e., G > 1), the function initializing the two random permutation tables (Section 5.6) MUST be called. This is true both at a sender and at a receiver.
ちょうど符号化シンボルグループが使用される場合、このパリティ検査行列を作成した後（即ち、G> 1）、2つのランダム順列テーブル（セクション5.6）を初期化関数が呼び出さなければならないことに留意されたいです。これは、送信側と受信時の両方で真です。
Here also, repair symbol creation is straightforward: each repair symbol of ESI i is equal to the sum of all source and repair symbols (with ESI lower than i) in the associated equation. Therefore, encoding MUST follow the natural repair symbol order: start with the first repair symbol, and generate repair symbol with ESI i before symbol with ESI i+1.
ここでも、リペアシンボルの作成は簡単である：ESIの各リペアシンボル私は、関連する式（Iよりも低いESI有する）すべてのソースおよびリペアシンボルの和に等しいです。したがって、符号化は、天然の修復シンボル順序に従う必要があります最初の修復シンボルで始まり、そしてESI I + 1シンボル前ESI Iとリペアシンボルを生成します。
Decoding basically consists in solving a system of n-k linear equations, whose variables are the n source and repair symbols. Of course, the final goal is to recover the value of the k source symbols only. To that purpose, many techniques are possible, as explained in Section 6.4.
復号は、基本的には、変数NソースおよびリペアシンボルであるN-kの線形方程式の系を解くことにあります。もちろん、最終的な目標は、唯一のk個のソースシンボルの値を回復することです。 6.4節で説明したように、その目的のために、多くの技術が可能です。
Because interoperability does not depend on the decoding algorithm used, the current document does not recommend any particular technique. This choice is left to the codec implementer.
相互運用性は、使用復号化アルゴリズムに依存しないので、現在の文書は、特定の技術を推奨していません。この選択は、コーデックの実装者に任されています。
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 an 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 a confidential content (e.g., in case of a 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), and
破損オブジェクトが送信されてしようとするもの（例えば、オブジェクト内の悪意のあるコードを注入する、またはオブジェクトを使用してから受信することを防止するために）、およびo
o 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 a confidential 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/ESP is used [RFC4303]). If confidentiality is a concern,
機密オブジェクトへのアクセス制御は、通常、暗号化によって提供されて送信されています。この暗号化は、（FEC符号化処理の前に、コンテンツプロバイダによって、例えば）オブジェクト全体にわたって行うことができ、又は（例えば、IPsecの/ ESPは、[RFC4303]を使用する場合）パケットのパケット単位で行われます。機密性が懸念される場合には、
it is RECOMMENDED that one of these solutions be used. Even if we mention these attacks here, they are not related or facilitated by the use of FEC.
これらのソリューションの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) is(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, in some cases, recovered. 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 latter 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 perhaps if 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-1 with a secret key shared by all the group members, senders, and receivers. This technique creates a cryptographically secured (thanks to the secret key) digest of a packet that is sent along with the packet. The Group MAC scheme does not create a prohibitive processing load or 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 such as a pre-check);
パケットレベルでO、グループメッセージ認証コード（MAC）[RFC2104]スキームは、すべてのグループメンバー、送信者、及び受信機によって共有された秘密鍵を用いてHMAC-SHA-1を用いて、例えば、使用することができます。この技術は、暗号確保（秘密鍵のおかげで）パケットと共に送信されるパケットのダイジェスト作成します。グループMAC方式は、法外な処理負荷や伝送オーバーヘッドを作成しませんが、それは大きな制限があります：すべてのグループメンバーが各メンバーが送信できることを意味し、同じ秘密のグループ鍵を、共有しているため、それが唯一のグループ認証/完全性サービスを提供しています偽造パケット。従って、グループのメンバーが完全に（または他の技術に関連してそのような事前チェックとして）信頼されている状況に制限されています。
o at the packet level, Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [RFC4082] is an attractive 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、時限効率ストリーム損失トレラント認証（テスラ）[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 CDP developer, who knows 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.
これは、最も適切なソリューションを定義するには、対象のアプリケーション領域のセキュリティ要件と機能を知っているCDPの開発者に任されています。それにもかかわらず、オブジェクトの破損の脅威の任意の懸念がある場合には、これらの技術のうちの少なくとも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.
私たちは今、FECパラメータ（またはFEC OTI）に対する攻撃を考えてみましょう。いずれか（セッション記述において、例えば）バンドで（すなわち、EXT_FTI又はFDTインスタンス内のオブジェクトのFEC OTIを含む）または帯域外送信することができるFEC OTI。これらのFECパラメータの攻撃が関連付けられたオブジェクトの復号化を防止することができる：例えば、Bパラメータを変更することは、異なるブロック分割につながります。
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 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) the latter SHOULD be protected, for instance, by digitally signing it with [RFC3852].
したがって、セキュリティ対策がFEC OTIの整合性を保証するために取られることが推奨されます。デジタル署名、グループMAC、またはTESLA：そのために、EXT_FTIヘッダ拡張内のインバンド送信FECパラメータを搬送するパケットは、上述したパケットごとの技術のいずれかによって保護されるべきです。 FEC OTIは、FDTインスタンスに含まれる場合、このオブジェクトは、例えば、デジタルXMLデジタル署名[RFC3275]で署名することにより、保護されるべきです。最後に、場合FEC OTIが送信され、帯域外（例えば、セッション記述に）後者デジタル[RFC3852]で署名することにより、例えば、保護されるべきです。
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 3 under the "ietf:rmt:fec:encoding" name-space to "LDPC Staircase Codes".
「LDPC階段コード」に名前空間をこの文書では、「：RMT：FEC符号化IETF」の下で完全に指定されたFEC符号化ID 3を割り当てます。
This document assigns the Fully-Specified FEC Encoding ID 4 under the "ietf:rmt:fec:encoding" name-space to "LDPC Triangle Codes".
「LDPCトライアングルコード」に名前空間をこの文書では、「：RMT：FEC符号化IETF」の下で完全に指定されたFEC符号化ID 4が割り当てられます。
Section 5.5 is derived from an earlier document, and we would like to thank S. Peltotalo and J. Peltotalo for their contribution. We would also like to thank Pascal Moniot, Laurent Fazio, Mathieu Cunche, Aurelien Francillon, Shao Wenjian, Magnus Westerlund, Brian Carpenter, Tim Polk, Jari Arkko, Chris Newman, Robin Whittle, and Alfred Hoenes for their comments.
5.5節では、以前の文書から導出され、我々は彼らの貢献のためのS. PeltotaloとJ. Peltotaloに感謝したいと思います。我々はまた、彼らのコメントのためにパスカルMoniot、ローラン・ファジオ、マチューCunche、オーレリアンFrancillon、少Wenjian、マグヌスウェスター、ブライアン・カーペンター、ティムポーク、ヤリArkko、クリス・ニューマン、ロビン削る、とアルフレッドHoenesに感謝したいと思います。
Last but not least, the authors are grateful to Radford M. Neal (University of Toronto) whose LDPC software (http://www.cs.toronto.edu/~radford/ldpc.software.html) inspired this work.
最後になりましたが、著者は、そのLDPCソフトウェア（http://www.cs.toronto.edu/~radford/ldpc.software.html）この作品にインスピレーションを与えラドフォード・M・ニール（トロント大学）に感謝しています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、RFC 2119、BCP 14、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月。
[ZP74] Zyablov, V. and M. Pinsker, "Decoding Complexity of Low-Density Codes for Transmission in a Channel with Erasures", Translated from Problemy Peredachi Informatsii, Vol.10, No. 1, pp.15-28, January-March 1974.
【ZP74] Problemy Peredachi Informatsii、VOL.10、第1号、pp.15-28、1月から翻訳さZyablov、V.とM. Pinsker、「抹消とチャネルにおける送信のための低密度符号の復号複雑」、 1974 -march。
[RN04] Roca, V. and C. Neumann, "Design, Evaluation and Comparison of Four Large Block FEC Codecs: LDPC, LDGM, LDGM-Staircase and LDGM-Triangle, Plus a Reed-Solomon Small Block FEC Codec", INRIA Research Report RR-5225, June 2004.
[RN04]ロカ、V.とC.ノイマン、「4つの大ブロックFECコーデックの設計、評価と比較：LDPC、LDGM、LDGM-階段とLDGM-トライアングル、プラスリードソロモンスモールブロックFECコーデック」、INRIAの研究レポートRR-5225、2004年6月。
[NRFF05] Neumann, C., Roca, V., Francillon, A., and D. Furodet, "Impacts of Packet Scheduling and Packet Loss Distribution on FEC Performances: Observations and Recommendations", ACM CoNEXT'05 Conference, Toulouse, France (an extended version is available as INRIA Research Report RR-5578), October 2005.
[NRFF05]ノイマン、C.、ロカ、V.、Francillon、A.、およびD. Furodet、 "FECパフォーマンス上のパケットスケジューリングの影響およびパケット損失分布：所見と提言"、ACM CoNEXT'05会議、トゥールーズ、フランス、2005年10月（拡張版は、INRIA研究報告RR-5578として入手可能です）。
[CR08] Cunche, M. and V. Roca, "Improving the Decoding of LDPC Codes for the Packet Erasure Channel with a Hybrid Zyablov Iterative Decoding/Gaussian Elimination Scheme", INRIA Research Report RR-6473, March 2008.
[CR08] Cunche、M.およびV.ロカ、INRIA研究報告RR-6473、2008年3月「ハイブリッドZyablov反復復号/ガウス消去スキームを持つパケット消去チャネル用LDPC符号の復号を改善します」。
[LDPC-codec] Roca, V., Neumann, C., Cunche, M., and J. Laboure, "LDPC-Staircase/LDPC-Triangle Codec Reference Implementation", INRIA Rhone-Alpes and STMicroelectronics, <http://planete-bcast.inrialpes.fr/>.
[LDPC-コーデック]ロカ、V.、ノイマン、C.、Cunche、M.、およびJ.ラブレ、 "LDPC-階段/ LDPC-トライアングルコーデックリファレンス実装"、INRIAローヌとSTマイクロエレクトロニクス、<HTTP：// planete-bcast.inrialpes.fr/>。
[MK03] MacKay, D., "Information Theory, Inference and Learning Algorithms", Cambridge University Press, ISBN: 0-521-64298-1, 2003.
[MK03]マッケイ、D.、 "情報理論、推論と学習アルゴリズム"、ケンブリッジ大学出版、ISBN：0-521-64298-1、2003。
[PM88] Park, S. and K. Miller, "Random Number Generators: Good Ones are Hard to Find", Communications of the ACM, Vol. 31, No. 10, pp.1192-1201, 1988.
[PM88]パーク、S.とK.・ミラー、「乱数ジェネレータ：良いものを見つけるのは難しいです」、ACMのコミュニケーション、巻。 31、第10号、pp.1192-1201、1988。
[CA90] Carta, D., "Two Fast Implementations of the Minimal Standard Random Number Generator", Communications of the ACM, Vol. 33, No. 1, pp.87-88, January 1990.
[CA90]カルタ、D.、「最小標準乱数発生器の2つの高速実装」、ACM、巻のコミュニケーション。 33、第1号、pp.87-88、1990年1月。
[WI08] Whittle, R., "Park-Miller-Carta Pseudo-Random Number Generator", January 2008, <http://www.firstpr.com.au/dsp/rand31/>.
[WI08] Whittleさん、R.、 "パーク・ミラー・カルタ擬似乱数発生器"、2008年1月、<http://www.firstpr.com.au/dsp/rand31/>。
[rand31pmc] Whittle, R., "31 bit pseudo-random number generator", September 2005, <http://www.firstpr.com.au/dsp/rand31/ rand31-park-miller-carta.cc.txt>.
【rand31pmc]削る、R.、 "31ビットの擬似乱数発生器" 2005年9月、<http://www.firstpr.com.au/dsp/rand31/ rand31パーク・ミラー-carta.cc.txt> 。
[PTVF92] Press, W., Teukolsky, S., Vetterling, W., and B. Flannery, "Numerical Recipes in C; Second Edition", Cambridge University Press, ISBN: 0-521-43108-5, 1992.
[PTVF92]を押して、W.、Teukolsky、S.、Vetterling、W.、およびB.フラナリー、 "Cにおける数値のレシピ;第二版"、ケンブリッジ大学出版、ISBN：0-521-43108-5、1992。
[RMT-PI-ALC] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", Work in Progress, November 2007.
[RMT-PI-ALC]ルビー、M.、ワトソン、M.、およびL. Vicisanoは、進行中、仕事、2007年11月の "非同期階層は（ALC）プロトコルインスタンスのコーディング"。
[RMT-PI-NORM] Adamson, B., Bormann, C., Handley, M., and J. Macker, "Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol", Work in Progress, January 2008.
[RMT-PI-NORM]アダムソン、B.、ボルマン、C.、ハンドレー、M.、およびJ. Macker、 "否定応答（NACK）配向高信頼マルチキャスト（NORM）プロトコル" 2008進行中で働いて1月。
[RMT-FLUTE] Paila, T., Walsh, R., Luby, M., Lehtonen, R., and V. Roca, "FLUTE - File Delivery over Unidirectional Transport", Work in Progress, October 2007.
[RMT-FLUTE] Paila、T.、ウォルシュ、R.、ルビー、M.、Lehtonenの、R.、およびV.ロカ、 "FLUTE - 単方向トランスポート上でファイル配信"、進歩、2007年10月の作業。
[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, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[RFC3275]イーストレーク、D.、Reagle、J.、およびD.ソロ "（拡張マークアップ言語）、XML署名の構文および処理"、RFC 3275、2002年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月。
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[RFC3852] Housley氏、R.、 "暗号メッセージ構文（CMS）"、RFC 3852、2004年7月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648] Josefsson氏、S.、 "Base16、Base32、およびBase64でデータエンコーディング"、RFC 4648、2006年10月。
Appendix A. Trivial Decoding Algorithm (Informative Only)
付録A.簡易復号アルゴリズム（参考のみ）
A trivial decoding algorithm is sketched below (please see [LDPC-codec] for the details omitted here):
些細な復号化アルゴリズムは、（ここでは省略詳細については、[LDPC-コーデック]を参照してください）以下にスケッチされています。
Initialization: allocate a table partial_sum[n-k] of buffers, each buffer being of size the symbol size. There's one entry per equation since the buffers are meant to store the partial sum of each equation; Reset all the buffers to zero;
初期化：各バッファのサイズのシンボルの大きさ、バッファーの[N-k]をテーブルpartial_sumを割り当てます。バッファは各方程式の部分和を保存するために意図されているので、式ごとに1つのエントリがあります。ゼロにすべてのバッファをリセットします。
/*
* For each newly received or decoded symbol, try to make progress
* in the decoding of the associated source block.
* NB: in case of a symbol group (G>1), this function is called for
* each symbol of the received packet.
* NB: a callback function indicates to the caller that new symbol(s)
* has(have) been decoded.
* new_esi (IN): ESI of the new symbol received or decoded
* new_symb (IN): Buffer of the new symbol received or decoded
*/
void
decoding_step(ESI_t new_esi,
symbol_t *new_symb)
{
If (new_symb is an already decoded or received symbol) {
Return; /* don't waste time with this symbol */
}
If (new_symb is the last missing source symbol) {
Remember that decoding is finished;
Return; /* work is over now... */
}
Create an empty list of equations having symbols decoded during this decoding step;
この復号化ステップの間に復号化されたシンボルを有する方程式の空のリストを作成します。
/*
* First add this new symbol to the partial sum of all the
* equations where the symbol appears.
*/
For (each equation eq in which new_symb is a variable and
having more than one unknown variable) {
Add new_symb to partial_sum[eq];
[EQ]をpartial_sumするnew_symbを追加します。
Remove entry(eq, new_esi) from the H matrix;
H行列から（当量、new_esi）のエントリを削除します。
If (the new degree of equation eq == 1) {
/* a new symbol can be decoded, remember the
* equation */
Append eq to the list of equations having symbols
decoded during this decoding step;
}
}
/*
* Then finish with recursive calls to decoding_step() for each
* newly decoded symbol.
*/
For (each equation eq in the list of equations having symbols
decoded during this decoding step) {
/*
* Because of the recursion below, we need to check that
* decoding is not finished, and that the equation is
* __still__ of degree 1
*/
If (decoding is finished) {
break; /* exit from the loop */
}
If ((degree of equation eq == 1) { Let dec_esi be the ESI of the newly decoded symbol in equation eq;
式EQ == 1の（（度）場合{dec_esiは、式EQで新たに復号されたシンボルのESIとします。
Remove entry(eq, dec_esi);
エントリを削除する（EQ、dec_esi）。
Allocate a buffer, dec_symb, for this symbol and copy partial_sum[eq] to dec_symb;
このシンボルのバッファ、dec_symbを割り当て、[EQ] dec_symbするpartial_sumをコピーします。
Inform the caller that a new symbol has been decoded via a callback function;
新しいシンボルは、コールバック関数を経由して復号化された発信者を知らせます。
/* finally, call this function recursively */
decoding_step(dec_esi, dec_symb);
}
}
Free the list of equations having symbols decoded;
Return;
}
Authors' Addresses
著者のアドレス
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/
Christoph Neumann Thomson 12, bd de Metz Rennes 35700 France
クリストフ・ノイマントムソン12、大通り・デ・メッツ35700レンヌフランス
EMail: christoph.neumann@thomson.net URI: http://planete.inrialpes.fr/people/chneuman/
電子メール：christoph.neumann@thomson.net URI：http://planete.inrialpes.fr/people/chneuman/
David Furodet STMicroelectronics 12, Rue Jules Horowitz BP217 Grenoble Cedex 38019 France
デビッドFurodet STマイクロエレクトロニクス12、ルージュール・ホロヴィッツBP217グルノーブルセデックス38019フランス
EMail: david.furodet@st.com URI: http://www.st.com/
電子メール：david.furodet@st.com URI：http://www.st.com/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。