[要約] RFC 5170は、LDPCステアケースとトライアングルのFECスキームに関する標準化ドキュメントです。このRFCの目的は、高効率な誤り訂正スキームを提供することです。
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
低密度パリティチェック（LDPC）階段および三角形の前方エラー補正（FEC）スキーム
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
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]は、Reed-Solomonのような小さなブロックFECコードの代替として、大きなブロックFECコードを導入します。このような大きなブロックコードの主な利点は、数万（またはそれ以上）のソース記号のソースブロックで効率的に動作する可能性です。現在のドキュメントでは、LDPC階段FECコードで使用することを目的とした完全に指定されたFECエンコードID 3と、LDPC-Triangle FECコード[RN04] [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-Codec]の下で配布されます。また、このドキュメントに含まれるコード抽出物は、このドキュメントの著者とRadford M. Nealによって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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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比、つまり、ソースシンボルの数とエンコーディングシンボルの数との比率。コードレートはa] 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は、パリティチェックマトリックスの左側にある列あたりの「1S」のターゲット数を示します。
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.
N1M3は値n1-3を示します。ここで、n1はパリティチェックマトリックスの左側にある列あたりの「1S」のターゲット数です。
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）は、セクション5.7で定義された擬似ランダム数ジェネレーターを示し、[0;M-1]そのたびに呼び出されます。
This document uses the following abbreviations:
このドキュメントでは、次の略語を使用しています。
ESI: Encoding Symbol ID
ESI：シンボルIDをエンコードします
FEC OTI: FEC Object Transmission Information
FEC OTI：FECオブジェクト伝送情報
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ビットフィールド）は、オブジェクトのソースブロックからパケットペイロードのエンコードシンボルが生成されるかどうかを識別します。オブジェクトごとに最大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値（kからn-k-1）が修復記号を識別します。
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
パケットごとにFECペイロードIDが1つある必要があります。エンコードシンボルグループの場合、複数のエンコードシンボルが同じパケットで送信される場合、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.
o FECエンコーディングID：LDPC階段ケースとLDPC-Trianger完全に指定されたFECスキームは、それぞれFEC Encoding 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
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 = 2 ^^ 19（コードレート1/2、セクション5.2のため）の場合、E = 1024バイトの場合、最大転送長は2 ^^ 41バイト（または2 TB）です。サイズ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 エンコーディング-Symbol-Length（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-Number-of-Encoding-Symbols（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の間の整数、包括的。パリティチェックマトリックスN1の左側にある列あたりの「1S」の目標番号は、N1M3 3に等しくなります（セクション6.2および7.2を参照）。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).
o PRNGシード：シードは、1〜0x7fffffffe（つまり、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の2つの可能なエンコード形式を示しています。現在のドキュメントでは、これらのエンコード形式をいつまたはどのように使用するかを指定していません。
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.
o 最大ソースブロック長（b）フィールド（20ビット）は2つの部分に分割されます。8つの最も重要なビット（MSB）は、ext_ftiの32ビット単語と、残りの12の最小ビット（LSB）は4番目の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:
FEC OTIをファイル配信テーブル（FDT）インスタンスに掲載することが望ましい場合は、単方向輸送（Flute）セッション[RMT-Flute]を介したファイル配信のインスタンスで、関連するオブジェクトについて次のXML属性を説明する必要があります。
o FEC-OTI-FEC-Encoding-ID
o FEC-OTI-FEC-ENCODING-ID
o FEC-OTI-Transfer-length
o fec-oti-transfer-length
o FEC-OTI-Encoding-Symbol-Length
o FEC-OTI-ENCODING-SYMBOL-LENGTH
o FEC-OTI-Maximum-Source-Block-Length
o FEC-Oti-Maximum-Source-Block-Length
o FEC-OTI-Max-Number-of-Encoding-Symbols
o FEC-OTI-MAX-Number-of-Encoding-Symbols
o FEC-OTI-Scheme-Specific-Info
o FEC-OTI-SCHEME特異的INFO
The FEC-OTI-Scheme-Specific-Info contains the string resulting from the Base64 encoding [RFC4648] of the following value:
FEC-OTI-SCHEME固有のINFOには、次の値の[RFC4648]をエンコードするBase64から生じる文字列が含まれています。
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 Encoding 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-SCHEME固有のINFO属性に追加される8つの印刷可能な文字（64文字のアルファベット）の文字列に変換されます。
This section defines procedures that are common to FEC Encoding IDs 3 and 4.
このセクションでは、ID 3および4をエンコードするFECに共通する手順を定義します。
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 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.
b（シンボルの最大ソースブロック長）、e（バイトのシンボル長をエンコード）、およびg（グループごとのエンコードシンボルの数）パラメーターが最初に決定されます。セクション5.2およびセクション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-triangleスキームの唯一の違いは、この右マトリックスの構築です。位置のマトリックスのエントリ（a "1"）（i、j）（つまり、行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.6では、シンボルグループがどのように作成されるかを詳しく説明し、最後にセクション5.7でPRNGをカバーしています。
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のエンコードシンボル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)))
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/4 <= CR < 1/2: max1_B = 2^^18 = 262,144 symbols
o 1/8 <= CR < 1/4: max1_B = 2^^17 = 131,072 symbols
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.
さらに、コーデックは最大ブロックサイズに他の制限を課す場合があります。たとえば、これは、コーデックが内部的に16ビットの符号なし整数を使用して、エンコードシンボルIDを保存する場合です。これは、20ビットフィールドのすべての可能な値を保存できないためです。その場合、たとえば1/2 <= cr <1の場合、最大ソースブロック長は2 ^^ 15です。たとえば、作業メモリサイズが限られているため、他の制限も適用される場合があります。この決定は、ターゲットユースケースが既知の場合に、実装時に明確にする必要があります。これにより、MAX2_Bの制限が得られます。
Then, B is given by:
次に、Bは次のように与えられます。
B = min(max1_B, max2_B)
b = min（max1_b、max2_b）
Note that this calculation is only required at the coder, since the B parameter is communicated to the decoder through the FEC OTI.
BパラメーターはFEC OTIを介してデコーダーに通信されるため、この計算はコーダーでのみ必要であることに注意してください。
The 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）の最大伝送ユニットに依存します。プロトコルヘッダーのオーバーヘッド（たとえば、ALCの場合の層状コーディング輸送（LCT）、UDP、IPv4、またはIPv6ヘッダーなど）を最小化するために、Eは可能な限り大きくなるように選択されます。その場合、Eが選択され、単一のシンボル（g = 1）で構成されるパケットのサイズが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 |
+------------------------+----+-------------+-------------------+
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コードレート。これはユーザーが提供する（たとえば、フルートの送信アプリケーションを開始するとき）。これは、浮動小数点値として表されます。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);
if (max_n > 2^^20), then return an error ("invalid code rate");
(NB: if B has been defined as explained in Section 5.2, this error should never happen.)
（NB：Bがセクション5.2で説明されているように定義されている場合、このエラーは決して発生しないはずです。）
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-アルゴリズム」とも呼ばれる次のアルゴリズムは、送信者と受信機が使用して、特定のブロック（n）のエンコード記号の数をB、k、およびmax_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);
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情報は、最初のエンコードシンボルを参照する必要があります。その後、この単一の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。Receiver）_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.
シンボルIDをエンコードするGのリストを返します。ソースパケットの場合、ESIを増加させることにより、GエンコードシンボルIDが連続して選択されます。修理パケットの場合、以下で説明するように、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）-thシンボルの最初のバイトが続きます。
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からシンボルIDのエンコードシンボル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.
特に、レシーバーと送信者が同じパリティチェックマトリックスを構築できるようにするために、特に完全に指定する必要がある擬似ランダム数ジェネレーター（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.
Park-Milerの「Minimal Standard」PRNG [PM88]を使用する必要があります。これは、単純な乗数合式アルゴリズム：IJ 1 = a * ij（Modulo M）を定義し、次の選択肢を選択します。A= 7 ^^ 5 = 16807およびM = 2 ^^ 31-1 =2147483647。PRNGは次のとおりです。Seed= 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 implementation of the PRNG algorithm that matches the above validation criteria, like the ones detailed in [PM88], is appropriate.
このPRNGのいくつかの実装は、文献で知られており、議論されています。このアルゴリズムの最適化された実装は、32ビット数学のみを使用し、分割を必要としないものを[RAND31PMC]に見つけることができます。[CA90]でD. cartaによって提案された最適化とともに、公園とミラーのアルゴリズム[PM88]を使用しています。このアルゴリズムの背後にある履歴は[Wi08]で詳しく説明されています。しかし、[PM88]で詳述されているように、上記の検証基準に一致するPRNGアルゴリズムの他の実装が適切です。
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〜0x7fffffffe（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);
(NB: the above C type casting to unsigned long is equivalent to using floor() with positive floating point values.)
（NB：上記のCタイプのキャストは、署名されていないロングまでの鋳造は、フロアー（）を正の浮動小数点値で使用するのと同等です。
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）は、上記のスケーリングアルゴリズムを使用して、上記で定義されたパークミラーの「最小標準」アルゴリズムを実装し、0とMAXV-1の間の生値をスケーリングするPRNG関数を示します。さらに、PMMS_RAND（MAXV）を初めて呼び出す前に、PRNGのシード（つまり、1〜0x7ffffffeを含む31ビット整数）を使用して有効にするように関数を提供する必要があります。
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階段マトリックスは、2つの部分に分割できます。マトリックスの左側は、ソースシンボルが関与する方程式を定義します。マトリックスの右側は、修復記号が含まれる方程式を定義します。
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）を初期化する関数（セクション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.
その目的のために、多くのテクニックが可能です。そのうちの1つは次の些細なアルゴリズム[Zp74]です。一連の線形方程式が与えられた場合、そのうちの1つが残りの変数が1つしかない場合、この変数の値は定数の値です。したがって、この変数を残りのすべての線形方程式におけるその値で置き換えて繰り返します。したがって、いくつかの変数の値は再帰的に見つけることができます。消去チャネルで動作する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].
ガウス除去（または最適化された導関数）は、もう1つの可能なデコード手法です。上記の些細なアルゴリズムを使用し、ガウス除去で終了することから始まるハイブリッドソリューションも可能です[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負荷にも影響します。ガウス除去には、上記の些細なアルゴリズムよりも多くの処理が必要です。ターゲットのユースケースに応じて、コーデック開発者は1つの機能を支持します。
LDPC-Triangle is identified by the Fully-Specified FEC Encoding ID 4.
LDPC-triangleは、完全に指定された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-Triangleスキームで使用される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-三角マトリックスは、2つの部分に分割できます。マトリックスの左側は、ソースシンボルが関与する方程式を定義します。マトリックスの右側は、修復記号が含まれる方程式を定義します。
The left side MUST be generated by using the same left_matrix_init() function as with LDPC-Staircase (Section 6.2).
左側は、LDPC階段（セクション6.2）と同じrept_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）を初期化する関数（セクション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.
また、修復記号の作成は簡単です。ESIIの各修復記号は、関連する方程式のすべてのソースおよび修復記号（Eより低い）の合計に等しくなります。したがって、エンコーディングは、自然修理記号の順序に従う必要があります。最初の修復記号で開始し、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とは無関係にFECビルディングブロックに焦点を当てているため（ALCとNORMが2つの自然候補であっても）、このセクションでは、このビルディングブロックを使用するときに任意の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インスタンス）または帯域外（例えば、セッションの説明で）。
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, 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.
送信される機密オブジェクトへのアクセス制御は、通常、暗号化によって提供されます。この暗号化は、オブジェクト全体（たとえば、FECエンコーディングプロセスの前にコンテンツプロバイダーによって）で実行されるか、パケットごとにパケットベースで実行できます（例：IPSEC/ESPを使用する場合[RFC4303]）。機密性が懸念される場合、これらのソリューションの1つを使用することをお勧めします。ここでこれらの攻撃に言及したとしても、FECの使用によって関連または促進されていません。
Protection against corruptions (e.g., after sending forged packets) is achieved by means of a content integrity verification/sender authentication scheme. This service can be provided at the object level, but in that case a receiver has no way to identify which symbol(s) 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 パケットレベルでは、たとえば、すべてのグループメンバー、送信者、レシーバーが共有するシークレットキーを使用してHMAC-SHA-1を使用することにより、グループメッセージ認証コード（MAC）[RFC2104]スキームを使用できます。この手法は、パケットとともに送信されるパケットの暗号化された（秘密の鍵のおかげで）ダイジェストを作成します。グループ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 パケットレベルでは、タイミングの効率的なストリーム損失耐性認証（TESLA）[RFC4082]は、損失に対して堅牢で、真の認証/整合性サービスを提供し、禁止されている処理負荷またはトランスミッションオーバーヘッドを作成しない魅力的なソリューションです。しかし、パケットをチェックするには、受信後にわずかな遅延（2秒以上）が必要です。
Techniques relying on public key cryptography (digital signatures and TESLA during the bootstrap process, when used) require that public keys be securely associated to the entities. This can be achieved by a Public Key Infrastructure (PKI), or by a PGP Web of Trust, or by pre-distributing the public keys of each group member.
公開キーの暗号化（使用時にブートストラッププロセス中にデジタル署名とテスラ）に依存する手法では、パブリックキーがエンティティにしっかりと関連する必要があります。これは、公開キーインフラストラクチャ（PKI）、PGP Web of Trust、または各グループメンバーの公開キーを事前に配布することによって達成できます。
Techniques relying on symmetric key cryptography (Group MAC) require that a secret key be shared by all group members. This can be achieved by means of a group key management protocol, or simply by pre-distributing the secret key (but this manual solution has many limitations).
対称キー暗号化（グループMAC）に依存する手法では、すべてのグループメンバーが秘密鍵を共有する必要があります。これは、グループキー管理プロトコルによって、または単にシークレットキーを事前に配置することで実現できます（ただし、この手動ソリューションには多くの制限があります）。
It is up to the 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）に対する攻撃を考えてみましょう。fec otiは、バンド内（つまり、ext_ftiまたはオブジェクトのfec otiを含むfdtインスタンス）またはバンド外（たとえば、セッションの説明で）のいずれかを送信できます。これらの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の完全性を保証するためにセキュリティ対策を講じることをお勧めします。その目的のために、ext_ftiヘッダー拡張機能で帯域内で送信されたFECパラメーターを運ぶパケットは、上記のパケットごとの手法の1つであるデジタル署名、グループMAC、またはテスラによって保護する必要があります。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".
このドキュメントでは、「IETF：RMT：FEC：「LDPC階段コード」への「名前」のエンコード「IETF：RMT：FEC」の下に、完全に指定された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".
このドキュメントは、「IETF：RMT：FEC：「LDPCトライアングルコード」への「名前空間」のエンコード「IETF：RMT：FEC」の下に、完全に指定された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の貢献に感謝します。また、パスカル・モニオット、ローラン・ファジオ、マシュー・カンチェ、オーレリア・フランシヨン、シャオ・ウェンジアン、マグナス・ウェスターランド、ブライアン・カーペンター、ティム・ポーク、ジャリ・アークコ、クリス・ニューマン、ロビン・ホイットル、アルフレッド・ヘネスのコメントに感謝します。
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Watson、M.、Luby、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] Zyablov、V。およびM. Pinsker、「消去を伴うチャネルでの伝送のための低密度コードの複雑さのデコード」、問題の多いPeredachi informatsii、Vol.10、No。1、pp.15-28、1月から翻訳 - 1974年3月。
[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] Roca、V。およびC. Neumann、「LDPC、LDGM、LDGM-StaircaseおよびLDGM-Triangleの4つの大きなブロックFECコーデックの設計、評価、比較、およびReed-Solomon Small Block FEC Codec」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] Neumann、C.、Roca、V.、Francillon、A。、およびD. Furodet、「FECパフォーマンスに対するパケットスケジューリングとパケット損失分布の影響：観察と推奨（拡張バージョンは、2005年10月、INRIA Research Report 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. Roca、「ハイブリッドZyablov反復解読/ガウスエリミネーションスキームを使用したパケット消去チャネルのLDPCコードのデコードの改善」、INRIA Research Report RR-6473、2008年3月。
[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-Codec] Roca、V.、Neumann、C.、Cunche、M。、およびJ. Lovouree、「LDPC-Staircase/LDPC-Triangle Codecリファレンス実装」、Inria Rhone-Alpes and Stmicroelectronics、<http：///planete-bcast.inrialpes.fr/>。
[MK03] MacKay, D., "Information Theory, Inference and Learning Algorithms", Cambridge University Press, ISBN: 0-521-64298-1, 2003.
[MK03] Mackay、D。、「情報理論、推論および学習アルゴリズム」、Cambridge University Press、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] Park、S。およびK. Miller、「乱数ジェネレーター：良いものを見つけるのが難しい」、ACMの通信、Vol。31、No。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] Carta、D。、「最小標準乱数発電機の2つの高速実装」、ACMの通信、Vol。33、No。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。、「Park-Miller-Carta Pseudo-Random Number Generator」、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] Whittle、R。、「31ビット擬似ランダム数ジェネレーター」、2005年9月、<http://www.firstpr.com.au/dsp/rand31/ rand31-park-miller-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] Press、W.、Teukolsky、S.、Vetterling、W。、およびB. Flannery、「Cの数値レシピ」、Cambridge University Press、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] Luby、M.、Watson、M。、およびL. Vicisano、「非同期層状コーディング（ALC）プロトコルインスタンス化」、2007年11月、Work in Progress。
[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] Adamson、B.、Bormann、C.、Handley、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.、Walsh、R.、Luby、M.、Lehtonen、R.、およびV. Roca、「フルート - 単方向輸送を介したファイル配信」、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] Jonsson、J.およびB. Kaliski、「Public-Key Cryptography Standards（PKCS）＃1：RSA暗号仕様バージョン2.1」、RFC 3447、2003年2月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC2104] "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、1997年2月。
[RFC4082] "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005.
[RFC4082]「タイミングの効率的なストリーム損失耐性認証（TESLA）：マルチキャストソース認証変換導入」、RFC 4082、2005年6月。
[RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[RFC3275] Eastlake、D.、Reagle、J。、およびD. Solo、「（拡張可能なマークアップ言語）XML-Signature構文と処理」、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] Luby、M.、Vicisano、L.、Gemmell、J.、Rizzo、L.、Handley、M。、およびJ. Crowcroft、「信頼できるマルチキャストでのフォワードエラー補正（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-Codec]を参照してください）：
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;
初期化：バッファーのテーブルPartial_sum [n-k]を割り当て、各バッファーはシンボルサイズのサイズです。バッファーは各方程式の部分的な合計を保存することを目的としているため、方程式ごとに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];
partial_sum [eq]にnew_symbを追加します。
Remove entry(eq, new_esi) from the H matrix;
H行列からエントリ（eq、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;
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を割り当て、partial_sum [eq]をdec_symbにコピーします。
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
Vincent Roca Inria 655、av。de l'Ueporn Inovallee;Montbonnot St Ismier Cedex 38334フランス
EMail: vincent.roca@inria.fr
URI: http://planete.inrialpes.fr/people/roca/
Christoph Neumann Thomson 12, bd de Metz Rennes 35700 France
クリストフ・ノイマン・トムソン12、bd de Metz Rennes 35700 France
EMail: christoph.neumann@thomson.net
URI: http://planete.inrialpes.fr/people/chneuman/
David Furodet STMicroelectronics 12, Rue Jules Horowitz BP217 Grenoble Cedex 38019 France
David Furodet Stmicroelectronics 12、Rue Jules Horowitz BP217 Groenoble Cedex 38019 France
EMail: david.furodet@st.com
URI: http://www.st.com/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。