[要約] RFC 5052は、Forward Error Correction（FEC）の構築に関する情報を提供する。その目的は、ネットワーク通信の信頼性と効率性を向上させるために、FEC技術の実装と使用方法を定義することである。
Network Working Group M. Watson
Request for Comments: 5052 M. Luby
Obsoletes: 3452 L. Vicisano
Category: Standards Track Digital Fountain
August 2007
Forward Error Correction (FEC) Building Block
フォワードエラー補正（FEC）ビルディングブロック
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
This document describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for bulk data transfer over IP multicast. This document defines a framework for the definition of the information that needs to be communicated in order to use an FEC code for bulk data transfer, in addition to the encoded data itself, and for definition of formats and codes for communication of that information. Both information communicated with the encoded data itself and information that needs to be communicated 'out-of-band' are considered. The procedures for specifying new FEC codes, defining the information communication requirements associated with those codes and registering them with the Internet Assigned Numbers Authority (IANA) are also described. The requirements on Content Delivery Protocols that wish to use FEC codes defined within this framework are also defined. The companion document titled "The Use of Forward Error Correction (FEC) in Reliable Multicast" describes some applications of FEC codes for delivering content. This document obsoletes RFC 3452.
このドキュメントでは、IPマルチキャストを介したバルクデータ転送の信頼性を効率的に提供および/または増強するために、フォワードエラー補正（FEC）コードを使用する方法について説明します。このドキュメントは、エンコードされたデータ自体に加えて、バルクデータ転送にFECコードを使用するために伝達する必要がある情報の定義のフレームワークを定義し、その情報の通信のための形式とコードの定義について定義します。エンコードされたデータ自体と通信した情報と、「帯域外」を伝える必要がある情報が考慮されます。新しいFECコードを指定し、それらのコードに関連付けられた情報通信要件を定義し、インターネットに割り当てられた番号当局（IANA）に登録する手順についても説明します。このフレームワーク内で定義されたFECコードを使用したいコンテンツ配信プロトコルの要件も定義されています。「信頼できるマルチキャストでのフォワードエラー補正（FEC）の使用」というタイトルのコンパニオンドキュメントは、コンテンツを配信するためのFECコードのいくつかのアプリケーションを説明しています。このドキュメントは、RFC 3452を廃止します。
Table of Contents
目次
1. Introduction ....................................................3
2. Definitions and Abbreviations ...................................4
3. Requirements Notation ...........................................4
4. Rationale .......................................................5
5. Applicability Statement .........................................6
6. Functionality ...................................................6
6.1. FEC Schemes ................................................8
6.2. FEC Object Transmission Information .......................10
6.2.1. Transport of FEC Object Transmission Information ...11
6.2.2. Opacity of FEC Object Transmission Information .....12
6.2.3. Mandatory FEC Object Transmission
Information Elements ...............................12
6.2.4. Common FEC Object Transmission Information
Elements ...........................................12
6.2.5. Scheme-Specific FEC Object Transmission
Information Element ................................13
6.3. FEC Payload ID ............................................13
7. FEC Scheme Specifications ......................................14
8. CDP Specifications .............................................17
9. Common Algorithms ..............................................18
9.1. Block Partitioning Algorithm ..............................18
9.1.1. First Step .........................................18
9.1.2. Second step ........................................19
10. Requirements from Other Building Blocks .......................20
11. Security Considerations .......................................20
12. IANA Considerations ...........................................21
12.1. Explicit IANA Assignment Guidelines ......................21
13. Changes from RFC 3452 .........................................22
14. Acknowledgments ...............................................23
15. References ....................................................23
15.1. Normative References .....................................23
15.2. Informative References ...................................23
This document describes how to use Forward Error Correction (FEC) codes to provide support for reliable delivery of content within the context of a Content Delivery Protocol (CDP). This document describes a building block as defined in [10], specifically Section 4.2 of that document, and follows the general guidelines provided in [5].
このドキュメントでは、コンテンツ配信プロトコル（CDP）のコンテキスト内でコンテンツの信頼できる配信をサポートするために、フォワードエラー補正（FEC）コードを使用する方法について説明します。このドキュメントでは、[10]で定義されているビルディングブロック、特にそのドキュメントのセクション4.2について説明し、[5]で提供される一般的なガイドラインに従います。
The purpose of this building block is to define a framework for forward error correction such that:
このビルディングブロックの目的は、次のような前方エラー修正のフレームワークを定義することです。
1. CDPs can be designed to operate with a range of different FEC codes/schemes, without needing to know details of the specific FEC code/scheme that may be used.
1. CDPは、使用できる特定のFECコード/スキームの詳細を知る必要なく、さまざまなFECコード/スキームで動作するように設計できます。
2. FEC schemes can be designed to operate with a range of different CDPs, without needing to know details of the specific CDPs.
2. FECスキームは、特定のCDPの詳細を知る必要なく、さまざまなCDPの範囲で動作するように設計できます。
Note that a 'CDP' in the context of this document may consist of several distinct protocol mechanisms and may support any kind of application requiring reliable transport -- for example, object delivery and streaming applications.
このドキュメントのコンテキストでの「CDP」は、いくつかの異なるプロトコルメカニズムで構成され、信頼できる輸送など、オブジェクト配信やストリーミングアプリケーションを必要とするあらゆるアプリケーションをサポートする場合があることに注意してください。
This document also provides detailed guidelines on how to write an RFC for an FEC scheme corresponding to a new FEC Encoding ID (for both Fully-Specified and Under-Specified FEC Schemes -- see Section 4).
このドキュメントは、新しいFECエンコードIDに対応するFECスキームのRFCを作成する方法に関する詳細なガイドラインも提供します（完全に指定されたFECスキームと不足しているFECスキームの両方 - セクション4を参照）。
RFC 3452 [3], which is obsoleted by this document, contained a previous version, which was published in the "Experimental" category. RFC 3452 was published as an Experimental RFC in part due to the lack at that time of specified congestion control strategies suitable for use with Reliable Multicast protocols.
このドキュメントで廃止されたRFC 3452 [3]には、「実験的」カテゴリで公開された以前のバージョンが含まれていました。RFC 3452は、信頼性の高いマルチキャストプロトコルでの使用に適した指定された混雑制御戦略の不足のために、一部は実験的RFCとして公開されました。
This Proposed Standard specification is thus based on RFC 3452 [3] updated according to accumulated experience and growing protocol maturity since the publication of RFC 3452 [3]. Said experience applies both to this specification itself and to congestion control strategies related to the use of this specification.
したがって、この提案された標準仕様は、RFC 3452 [3]の公開以来、累積経験とプロトコルの成長の増加に応じて更新されたRFC 3452 [3]に基づいています。上記の経験は、この仕様自体と、この仕様の使用に関連する混雑制御戦略の両方に適用されます。
The differences between RFC 3452 [3] and this document are listed in Section 13.
RFC 3452 [3]とこのドキュメントの違いは、セクション13にリストされています。
Object: An ordered sequence of octets to be transferred by the transport protocol. For example, a file or stream.
オブジェクト：輸送プロトコルによって転送されるオクテットの順序付けられたシーケンス。たとえば、ファイルまたはストリーム。
Symbol: A unit of data processed by the Forward Error Correction code. A symbol is always considered as a unit, i.e., it is either completely received or completely lost.
シンボル：フォワードエラー修正コードによって処理されるデータの単位。シンボルは常にユニットと見なされます。つまり、完全に受信されるか、完全に失われます。
Source symbol: A symbol containing information from the original object.
ソースシンボル：元のオブジェクトからの情報を含むシンボル。
Repair symbol: A symbol containing information generated by the FEC code which can be used to recover lost source symbols.
修復シンボル：失われたソースシンボルを回復するために使用できるFECコードによって生成された情報を含む記号。
Encoding symbol: A source symbol or a repair symbol.
エンコーディングシンボル：ソースシンボルまたは修理シンボル。
Encoder: The FEC scheme specific functions required to transform a object into FEC encoded data. That is, the functions that produce repair symbols using source symbols.
エンコーダ：FECスキーム特定の機能は、オブジェクトをFECエンコードデータに変換するために必要です。つまり、ソース記号を使用して修復記号を生成する関数。
Decoder: The FEC scheme-specific functions required to transform received FEC-encoded data into a copy of the original object.
デコーダー：受信したFECエンコードデータを元のオブジェクトのコピーに変換するために必要なFECスキーム固有の関数。
Receiver: A system supporting the receiving functions of a CDP and FEC scheme according to this specification.
受信機：この仕様に従って、CDPおよびFECスキームの受信機能をサポートするシステム。
Sender: A system supporting the sending functions of a CDP and FEC scheme according to this specification.
送信者：この仕様に従って、CDPおよびFECスキームの送信機能をサポートするシステム。
Source Block: A part of the object formed from a subset of the object's source symbols.
ソースブロック：オブジェクトのソース記号のサブセットから形成されたオブジェクトの一部。
CDP: Content Delivery Protocol
CDP：コンテンツ配信プロトコル
FEC: Forward Error Correction
FEC：フォワードエラー修正
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 [1].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[1]に記載されているとおりに解釈される。
An FEC code, in the general sense, is a valuable basic component of any CDP that is to provide reliable delivery of an object. Using FEC codes is effective in the context of IP multicast and reliable delivery because FEC encoding symbols can be useful to all receivers for reconstructing an object even when the receivers have received different encoding symbols. Furthermore, FEC codes can ameliorate or even eliminate the need for feedback from receivers to senders to request retransmission of lost packets.
一般的な意味でのFECコードは、オブジェクトの信頼できる配信を提供するためのCDPの貴重な基本コンポーネントです。FECコードを使用することは、IPマルチキャストと信頼性の高い配信のコンテキストで効果的です。FECエンコードシンボルは、レシーバーが異なるエンコーディングシンボルを受信した場合でもオブジェクトを再構築するためにすべての受信機に役立つ可能性があるためです。さらに、FECコードは、失われたパケットの再送信を要求するために、受信者から送信者へのフィードバックの必要性を改善または排除することさえあります。
Central to this document is the concept of an 'FEC Scheme', which we distinguish from the concept of an 'FEC code' or 'FEC algorithm'. An FEC scheme defines the ancillary information and procedures which, combined with an FEC code or algorithm specification, fully define how the FEC code can be used with CDPs. An FEC scheme may be associated with a single standardized FEC code (A 'Fully-Specified' FEC scheme) or may be applicable to many FEC codes (An 'Under-Specified' FEC scheme).
このドキュメントの中心は、「FECスキーム」の概念であり、これを「FECコード」または「FECアルゴリズム」の概念と区別します。FECスキームは、FECコードまたはアルゴリズムの仕様と組み合わせて、FECコードをCDPで使用する方法を完全に定義する補助情報と手順を定義します。FECスキームは、単一の標準化されたFECコード（「完全に指定された」FECスキーム）に関連付けられているか、多くのFECコード（「不足している」FECスキーム）に適用できる場合があります。
This document describes a framework for the definition of FEC schemes. Definition of actual FEC schemes is outside the scope of this document. This document also defines requirements for reliable CDPs that make use of FEC schemes. Any CDP that is compliant to the requirements specified in this document can make use of any FEC scheme that is defined within the framework described here. Note that FEC schemes may place restrictions on the types of CDP they are intended to be used with. For example, some FEC schemes may be specific to particular types of application, such as file delivery or streaming.
このドキュメントでは、FECスキームの定義のフレームワークについて説明します。実際のFECスキームの定義は、このドキュメントの範囲外です。このドキュメントでは、FECスキームを使用する信頼できるCDPの要件も定義しています。このドキュメントで指定された要件に準拠したCDPは、ここで説明するフレームワーク内で定義されているFECスキームを使用できます。FECスキームは、使用することを目的としたCDPの種類に制限を課す可能性があることに注意してください。たとえば、一部のFECスキームは、ファイル配信やストリーミングなど、特定のタイプのアプリケーションに固有の場合があります。
The goal of the FEC building block is to describe functionality directly related to FEC codes that is common to all reliable CDPs and to all FEC schemes, and to leave out any additional functionality that is specific to particular CDPs or particular FEC schemes. The primary functionality described in this document that is common to all such CDPs that use FEC codes is the definition and transport of three kinds of information from sender to receiver(s):
FECビルディングブロックの目標は、すべての信頼できるCDPおよびすべてのFECスキームに共通するFECコードに直接関連する機能を記述し、特定のCDPまたは特定のFECスキームに固有の追加機能を除外することです。FECコードを使用するすべてのCDPに共通するこのドキュメントで説明されている主要な機能は、送信者から受信者への3種類の情報の定義と輸送です。
1) encoding symbols themselves, 2) ancillary information associated with encoding symbols (or groups of such symbols, such as the group of symbols in a single packet, or the group of symbols related to a single source block), and 3) ancillary information associated with the whole object being transferred.
1) シンボル自体をエンコードする2）エンコードシンボル（または単一のパケット内のシンボルのグループ、または単一のソースブロックに関連するシンボルのグループなどのシンボルのグループ）に関連する補助情報、および3）に関連する補助情報転送されるオブジェクト全体。
It is important to note that this information is only required by the receiver if one or more of the encoding symbols to which it relates are received.
この情報は、それが関連するエンコードシンボルの1つ以上が受信された場合にのみ、受信者が必要とすることに注意することが重要です。
This document does not describe how receivers may request transmission of particular encoding symbols for an object. This is because although there are CDPs where requests for transmission are of use, there are also CDPs that do not require such requests.
このドキュメントでは、受信機がオブジェクトの特定のエンコード記号の送信をどのように要求するかについては説明していません。これは、送信のリクエストが使用されるCDPがあるが、そのような要求を必要としないCDPもあるためです。
The companion document [4] should be consulted for a full explanation of the benefits of using FEC codes for reliable content delivery using IP multicast. FEC codes are also useful in the context of unicast, and thus the scope and applicability of this document is not limited to IP multicast.
コンパニオンドキュメント[4]は、IPマルチキャストを使用して信頼できるコンテンツ配信にFECコードを使用することの利点についての完全な説明について参照する必要があります。FECコードはユニキャストのコンテキストでも役立つため、このドキュメントの範囲と適用性はIPマルチキャストに限定されません。
The FEC building block does not provide any support for congestion control. Any complete multicast CDP MUST provide congestion control that conforms to [6], in particular, Section 3.2 of that document. Thus, congestion control MUST be provided by another building block when the FEC building block is used in a CDP.
FECビルディングブロックは、混雑制御をサポートしません。完全なマルチキャストCDPは、[6]、特にそのドキュメントのセクション3.2に適合する混雑制御を提供する必要があります。したがって、FECビルディングブロックがCDPで使用される場合、別のビルディングブロックによって混雑制御を提供する必要があります。
A more complete description of the applicability of FEC codes can be found in the companion document [4].
FECコードの適用性のより完全な説明は、コンパニオンドキュメント[4]に記載されています。
This section describes FEC information that is to be sent either in packets also containing FEC encoding symbols or 'out-of-band'. The FEC information is associated with transmission of encoding symbols related to a particular object. There are three classes of packets that may contain FEC information: data packets, session-control packets, and feedback packets. They generally contain different kinds of FEC information. Note that some CDPs may not use session-control or feedback packets.
このセクションでは、FEC情報を含むパケットに送信されるFEC情報について説明します。FECエンコードシンボルまたは「帯域外」も含まれています。FEC情報は、特定のオブジェクトに関連するエンコードシンボルの送信に関連付けられています。FEC情報を含む可能性のある3つのクラスには、データパケット、セッションコントロールパケット、フィードバックパケットの3つのクラスがあります。通常、さまざまな種類のFEC情報が含まれています。一部のCDPは、セッションコントロールまたはフィードバックパケットを使用しない場合があることに注意してください。
Data packets may sometimes serve as session-control packets as well; both data and session-control packets generally travel downstream from the sender towards receivers and are sent to a multicast channel or to a specific receiver using unicast. Session-control packets may additionally travel upstream from receivers to senders.
データパケットは、セッション制御パケットとしても機能する場合があります。データとセッションコントロールの両方のパケットは、通常、送信者からレシーバーに向かって下流に移動し、ユニキャストを使用してマルチキャストチャネルまたは特定のレシーバーに送信されます。セッションコントロールパケットは、さらにレシーバーから送信者に上流に移動する場合があります。
As a general rule, feedback packets travel upstream from receivers to the sender. Sometimes, however, they might be sent to a multicast channel or to another receiver or to some intermediate node or neighboring router that provides recovery services.
一般的なルールとして、フィードバックパケットはレシーバーから送信者まで上流に移動します。ただし、マルチキャストチャネル、別のレシーバー、またはリカバリサービスを提供する中間ノードまたは隣接ルーターに送信される場合があります。
This document specifies both the FEC information that must be carried in data packets and the FEC information that must be communicated from sender to receiver(s) either out-of-band or in data packets. Specification of protocol mechanisms for transporting this information, for example, field and packet formats, is out of scope of this document. Instead, this document specifies at a higher level the information that must be communicated and provides detailed requirements for FEC Scheme and Content Delivery Protocol specifications, which are where the detailed field and packet formats should be defined.
このドキュメントは、データパケットに携帯する必要があるFEC情報と、送信者から帯域外またはデータパケットのいずれかを受信者に伝える必要があるFEC情報の両方を指定します。この情報を輸送するためのプロトコルメカニズム、たとえばフィールドやパケット形式の仕様は、このドキュメントの範囲外です。代わりに、このドキュメントは、伝達する必要がある情報をより高いレベルで指定し、FECスキームとコンテンツ配信プロトコル仕様の詳細な要件を提供します。ここでは、詳細なフィールドとパケット形式を定義する必要があります。
FEC information is classified as follows:
FEC情報は次のように分類されます。
1. FEC information associated with an object
1. オブジェクトに関連付けられたFEC情報
This is information that is essential for the FEC decoder to decode a specific object. An example of this information is the identity of the FEC scheme that is being used to encode the object, in the form of the FEC Encoding ID. The FEC Encoding ID is described further below. This information may also include FEC scheme-specific parameters for the FEC decoder.
これは、FECデコーダーが特定のオブジェクトをデコードするために不可欠な情報です。この情報の例は、FECエンコードIDの形でオブジェクトをエンコードするために使用されているFECスキームのIDです。FECエンコーディングIDについては、以下にさらに説明します。この情報には、FECデコーダーのFECスキーム固有のパラメーターも含まれる場合があります。
2. FEC information associated with specific encoding symbols for an object
2. オブジェクトの特定のエンコード記号に関連付けられたFEC情報
This is information that is associated with one or more encoding symbols and is thus needed by the decoder whenever one or more of those encoding symbols have been received. Depending on the FEC scheme, information may be associated with individual symbols and/or with groups of symbols. One common such grouping is the group of symbols included within a single packet. Many FEC schemes also segment the object being encoded into multiple 'source blocks', each of which is processed independently for FEC purposes. Information about each source block is another type of information associated with a group of encoding symbols -- in this case, the group of symbols which are related to a given source block.
これは、1つ以上のエンコードシンボルに関連付けられている情報であり、したがって、それらのエンコードシンボルの1つ以上が受信されたときはいつでもデコーダーによって必要です。FECスキームに応じて、情報は個々のシンボルやシンボルのグループに関連付けられている場合があります。このようなグループの1つは、単一のパケットに含まれるシンボルのグループです。また、多くのFECスキームは、複数の「ソースブロック」にエンコードされているオブジェクトをセグメント化します。それぞれがFECの目的で個別に処理されます。各ソースブロックに関する情報は、エンコードシンボルのグループに関連付けられた別のタイプの情報です。この場合、特定のソースブロックに関連するシンボルのグループです。
Two 'containers' are provided for communicating the FEC information described above, but there is not necessarily a one-to-one correspondence between the class of FEC information and the mechanism used. The two mechanisms are:
上記のFEC情報を通信するために2つの「コンテナ」が提供されていますが、FEC情報のクラスと使用されるメカニズムの間には必ずしも1対1の対応がありません。2つのメカニズムは次のとおりです。
a. FEC Object Transmission Information
a. FECオブジェクト伝送情報
CDPs must provide a reliable mechanism for communicating certain FEC information from sender to receiver(s). This information is known as 'FEC Object Transmission Information' and its contents depend on the particular FEC scheme. It includes all information of the first class above and may include information of the second class. The FEC Object Transmission Information can be sent to a receiver within the data packet headers, within session control packets, or by some other means.
CDPは、送信者から受信機への特定のFEC情報を通信するための信頼できるメカニズムを提供する必要があります。この情報は「FECオブジェクト伝送情報」として知られており、その内容は特定のFECスキームに依存します。上記の最初のクラスのすべての情報が含まれており、2番目のクラスの情報が含まれている場合があります。FECオブジェクト伝送情報は、データパケットヘッダー内の受信機、セッション制御パケット内、またはその他の手段で送信できます。
b. FEC Payload ID
b. FECペイロードID
CDPs must provide a mechanism for communicating information which identifies (for FEC purposes) the encoding symbols carried by a packet. This information is known as the FEC Payload ID, and its contents depend on the FEC scheme. It includes only information of the second class above. A data packet that carries encoding symbols MUST include an FEC Payload ID.
CDPは、パケットによって運ばれるエンコーディングシンボルを（FEC目的で）識別する情報を通信するためのメカニズムを提供する必要があります。この情報はFECペイロードIDとして知られており、その内容はFECスキームに依存します。上記の2番目のクラスの情報のみが含まれています。エンコーディングシンボルを搭載するデータパケットには、FECペイロードIDを含める必要があります。
Two types of FEC scheme are defined by this document: 'Fully-Specified' FEC schemes and 'Under-Specified' FEC schemes. An FEC scheme is a Fully-Specified FEC scheme if the encoding scheme is formally and Fully-Specified, in a way that independent implementors can implement both encoder and decoder from a specification that is an IETF RFC.
このドキュメントでは、2種類のFECスキームが定義されています。「完全に指定された」FECスキームと「不足している」FECスキーム。IETF RFCである仕様から独立した実装者がエンコーダーとデコーダーの両方を実装できるように、エンコードスキームが正式かつ完全に指定されている場合、FECスキームは完全に指定されたFECスキームです。
It is possible that an FEC scheme may not be a Fully-Specified FEC scheme, because either a specification is simply not available or a party exists that owns the encoding scheme and is not willing to disclose the algorithm or specification. We refer to such an FEC encoding scheme as an Under-Specified FEC scheme.
仕様が単に利用できないか、エンコードスキームを所有し、アルゴリズムまたは仕様を開示する意思がない当事者が存在しないため、FECスキームが完全に指定されたFECスキームではない可能性があります。このようなFECエンコーディングスキームを、指定されていないFECスキームと呼びます。
FEC schemes are identified by an FEC Encoding ID, which is an integer identifier assigned by IANA. The FEC Encoding ID allows receivers to select the appropriate FEC decoder. The value of the FEC Encoding ID MUST be the same for all transmission of encoding symbols related to a particular object, but MAY vary across different transmissions of encoding symbols about different objects, even if transmitted to the same set of multicast channels and/or using a single upper-layer session.
FECスキームは、IANAによって割り当てられた整数識別子であるFECエンコードIDによって識別されます。FECエンコードIDを使用すると、受信機は適切なFECデコーダーを選択できます。FECエンコードIDの値は、特定のオブジェクトに関連するエンコードシンボルのすべての伝送で同じでなければなりませんが、同じマルチキャストチャネルのセットに送信された場合でも、異なるオブジェクトに関するエンコード記号の異なる送信によって異なる場合があります。単一の上層セッション。
The FEC Instance ID is an integer value that identifies a specific instance of an Under-Specified FEC scheme. This value is not used for Fully-Specified FEC schemes. The FEC Instance ID is scoped by the FEC Encoding ID, and FEC Instance ID values are subject to IANA registration.
FECインスタンスIDは、不足しているFECスキームの特定のインスタンスを識別する整数値です。この値は、完全に指定されたFECスキームには使用されません。FECインスタンスIDはFECエンコードIDによってスコープされ、FECインスタンスID値はIANA登録の対象となります。
The FEC Encoding ID for Fully-Specified FEC Schemes and both the FEC Encoding ID and FEC Instance ID for Under-Specified FEC Schemes are essential for the decoder to decode an object. Thus, they are part of the FEC Object Transmission Information.
完全に指定されたFECスキームのFECエンコードIDと、Decoderがオブジェクトをデコードするには、Decoderがオブジェクトをデコードするためには、FECエンコードIDとFECインスタンスIDの両方が不可欠です。したがって、それらはFECオブジェクト伝送情報の一部です。
The following requirements apply to all FEC schemes, whether Fully-Specified or Under-Specified:
以下の要件は、完全に指定されていないか不足しているかどうかにかかわらず、すべてのFECスキームに適用されます。
o The type, semantics, and an encoding format for the FEC Payload ID and the FEC Object Transmission Information MUST be defined.
o FECペイロードIDおよびFECオブジェクト伝送情報のタイプ、セマンティクス、およびエンコード形式を定義する必要があります。
o A value for the FEC Encoding ID MUST be reserved and associated with the types, semantics, and encoding format of the FEC Payload ID and the FEC Object Transmission Information.
o FECエンコーディングIDの値は、FECペイロードIDのタイプ、セマンティクス、およびエンコード形式とFECオブジェクト伝送情報に関連付けられ、関連付けられている必要があります。
The specification for an Under-Specified FEC Scheme MAY allocate a sub-field within the Scheme-specific FEC Object Transmission Information element which is for instance-specific information. Each specific instance of the Under-Specified FEC Scheme may then use this field in an instance-specific way. The FEC scheme should define the scheme-specific FEC Object Transmission Information element in such a way that receivers that do not support the received FEC Instance ID can still parse and interpret the scheme-specific FEC Object Transmission Information element with the exception of the instance-specific field.
不足しているFECスキームの仕様は、たとえば固有の情報であるスキーム固有のFECオブジェクト伝送情報要素内にサブフィールドを割り当てる場合があります。不足しているFECスキームの各特定のインスタンスは、このフィールドをインスタンス固有の方法で使用できます。FECスキームは、受信したFECインスタンスIDをサポートしていない受信機が、インスタンスを除き、スキーム固有のFECオブジェクト伝送情報要素を解析および解釈できるように、スキーム固有のFECオブジェクト伝送情報要素を定義する必要があります。特定のフィールド。
An already defined Under-Specified FEC Scheme (i.e., FEC Encoding ID value) MUST be reused if the associated FEC Payload ID and FEC Object Transmission Information have the required fields and encoding formats for a new Under-Specified FEC scheme instance.
関連するFECペイロードIDおよびFECオブジェクトトランスミッション情報に必要なフィールドとエンコード形式がある場合は、新しい未定のFECスキームインスタンスにエンコード形式がある場合、既に定義されている不足しているFECスキーム（つまり、FECエンコードID値）を再利用する必要があります。
An instance of an Under-Specified FEC scheme is fully identified by the tuple (FEC Encoding ID, FEC Instance ID). The tuple MUST identify a single scheme instance that has at least one implementation. The party that owns this tuple MUST be able to provide information on how to obtain the Under-Specified FEC scheme instance identified by the tuple, e.g., a pointer to a publicly available reference-implementation or the name and contacts of a company that sells it, either separately or embedded in another product.
不足しているFECスキームのインスタンスは、Tuple（FECエンコードID、FECインスタンスID）によって完全に識別されます。タプルは、少なくとも1つの実装を持つ単一のスキームインスタンスを識別する必要があります。このタプルを所有するパーティーは、タプルによって特定された不足しているFECスキームインスタンスを取得する方法に関する情報を提供できる必要があります。、別の製品に別々にまたは埋め込まれています。
This specification reserves the range 0-127 for the values of FEC Encoding IDs for Fully-Specified FEC schemes and the range 128-255 for the values of Under-Specified FEC schemes.
この仕様は、FECの値の範囲0-127を、完全に指定されたFECスキームのIDをコードするIDをエンコードする値と、不足しているFECスキームの値に対して範囲128-255を留保します。
The FEC Object Transmission Information contains information which is essential to the decoder in order to decode the encoded object. It may also contain information which is required to decode certain groups of encoding symbols, for example, individual Source Blocks within the object. This information is communicated reliably by the CDP to the receiver(s) as described in Section 8.
FECオブジェクト伝送情報には、エンコードされたオブジェクトをデコードするためにデコーダーに不可欠な情報が含まれています。また、オブジェクト内の個々のソースブロックなど、エンコードシンボルの特定のグループをデコードするために必要な情報も含まれている場合があります。この情報は、セクション8で説明されているように、CDPによって受信機に確実に伝達されます。
The FEC Object Transmission Information may consist of several elements and each element may be one of three types, as follows:
FECオブジェクト伝送情報はいくつかの要素で構成され、各要素は次のように3つのタイプのいずれかである場合があります。
Mandatory: These elements are defined in this specification and are each mandatory for at least one of the two types of FEC Scheme. Each FEC scheme specifies how the values of the Mandatory FEC Object Transmission Information elements are determined and each CDP specifies how this information is encoded and reliably communicated to the receiver(s). The Mandatory FEC Object Transmission Information includes the identification of the FEC Scheme, which is needed by the receiver to determine whether it supports the FEC Scheme.
必須：これらの要素はこの仕様で定義されており、それぞれ2種類のFECスキームのうち少なくとも1つについて必須です。各FECスキームは、必須のFECオブジェクトトランスミッション情報要素の値が決定される方法を指定し、各CDPはこの情報のエンコード化方法を指定し、受信者に確実に通信する方法を指定します。必須のFECオブジェクト伝送情報には、FECスキームをサポートするかどうかを判断するために受信機が必要とするFECスキームの識別が含まれます。
Common: These elements are defined in this specification and are optional to be used by an FEC scheme. Each FEC scheme specifies which of the Common FEC Object Transmission Information elements it uses and how the values of these elements are determined.
共通：これらの要素はこの仕様で定義されており、FECスキームで使用されるようにオプションです。各FECスキームは、使用する一般的なFECオブジェクト伝送情報要素のどれか、これらの要素の値がどのように決定されるかを指定します。
Scheme-specific: An FEC scheme may specify a single Scheme-specific FEC Object Transmission Information element. The FEC scheme specifies the type, semantics, and encoding format of the Scheme-specific FEC Object Transmission Information element. The resulting octet string is known as the "encoded Scheme-specific FEC Object Transmission Information". Each CDP specifies how the encoded Scheme-specific FEC Object Transmission is communicated reliably to the receiver(s), i.e., exactly where it shall be carried within packets of the CDP. Note that although from the point of view of this specification and of CDPs, there is only a single Scheme-specific FEC Object Transmission Information element, the FEC scheme may specify this element to contain multiple distinct pieces of information.
スキーム固有：FECスキームは、単一のスキーム固有のFECオブジェクト伝送情報要素を指定する場合があります。FECスキームは、スキーム固有のFECオブジェクト伝送情報要素のタイプ、セマンティクス、およびエンコード形式を指定します。結果のOctet文字列は、「エンコードされたスキーム固有のFECオブジェクト伝送情報」として知られています。各CDPは、エンコードされたスキーム固有のFECオブジェクトトランスミッションが受信機と確実に通信される方法、つまりCDPのパケット内で実施する方法を指定します。この仕様とCDPの観点からは、単一のスキーム固有のFECオブジェクトトランスミッション情報要素しかないが、FECスキームは複数の異なる情報を含むようにこの要素を指定する場合があることに注意してください。
Each FEC scheme specifies an encoding format for the Common and Scheme-specific FEC Object Transmission Information. Each CDP must specify at least one of the following:
各FECスキームは、共通およびスキーム固有のFECオブジェクト伝送情報のエンコード形式を指定します。各CDPは、少なくとも1つを指定する必要があります。
1. A means to reliably communicate the Common FEC Object Transmission Information elements to the receiver(s) using the encoding format defined by the FEC scheme.
1. FECスキームで定義されたエンコード形式を使用して、一般的なFECオブジェクト伝送情報要素を受信機に確実に通信する手段。
2. An alternative, CDP-specific, encoding format for each of the Common FEC Object Transmission Information elements.
2. 一般的なFECオブジェクト伝送情報要素のそれぞれの代替のCDP固有のエンコード形式。
The Mandatory and Common FEC Object Transmission Information elements are defined in the sections below.
必須および一般的なFECオブジェクト伝送情報要素は、以下のセクションで定義されています。
It is the responsibility of the CDP to reliably transport the FEC Object Transmission Information to the receiver(s).
FECオブジェクト伝送情報を受信機に確実に輸送することは、CDPの責任です。
It is important to note that the encoding format of the Mandatory FEC Object Transmission Information elements (the FEC Encoding ID) is defined by the CDP. This is so that the receiver can identify the FEC Scheme to be used for interpreting the remaining FEC Object Transmission Information elements. All CDPs must define encoding formats for the Mandatory FEC Object Transmission Information element.
必須のFECオブジェクト伝送情報要素（FECエンコードID）のエンコード形式はCDPによって定義されていることに注意することが重要です。これは、レシーバーが残りのFECオブジェクト伝送情報要素を解釈するために使用されるFECスキームを識別できるようにするためです。すべてのCDPは、必須のFECオブジェクトトランスミッション情報要素のエンコード形式を定義する必要があります。
Common FEC Object Transmission Information elements can be transported in two different ways: (a) the FEC Scheme defines an encoding format for the Common FEC Object Transmission Information elements that it uses, and the CDP transports this encoded data block, or (b) the CDP defines an encoding format for each Common FEC Object Transmission Information element and transports the information in this format.
一般的なFECオブジェクト伝送情報要素は、次の2つの異なる方法で輸送できます。（a）FECスキームは、使用する一般的なFECオブジェクト伝送情報要素のエンコード形式を定義し、CDPはこのエンコードされたデータブロックを輸送する、または（b）CDPは、一般的な各FECオブジェクト伝送情報要素のエンコード形式を定義し、この形式で情報を輸送します。
An FEC Scheme MUST define an encoding format for the Common FEC Object Transmission Information elements that it uses. The resulting octet string is known as the "encoded Common FEC Object Transmission Information". A CDP MAY define individual encoding formats for each of the Common FEC Object Transmission Information elements. The choice of which way the Common FEC Object Transmission Information elements shall be transported, (a) or (b), is made by the Content Delivery Protocol, and a particular method SHOULD be defined in the Content Delivery Protocol specification. Note that a CDP may provide support for one or both options.
FECスキームは、使用する一般的なFECオブジェクト伝送情報要素のエンコード形式を定義する必要があります。結果のオクテット文字列は、「エンコードされた一般的なFECオブジェクト伝送情報」として知られています。CDPは、一般的なFECオブジェクト伝送情報要素のそれぞれの個々のエンコード形式を定義できます。（a）または（b）がコンテンツ配信プロトコルによって行われる一般的なFECオブジェクト伝送情報要素を輸送する方法の選択、および特定の方法はコンテンツ配信プロトコル仕様で定義する必要があります。CDPは、一方または両方のオプションをサポートする場合があることに注意してください。
In the case that the CDP uses the encoding format specified by the FEC scheme, it may simply concatenate the encoded Common FEC Object Transmission Information and the encoded Scheme-specific FEC Object Transmission Information, or it may carry each in a separate field or wrapper within the CDP. In the former case, the concatenated octet string is known as the encoded FEC Object Transmission Information. The FEC scheme must define the encoding format for the Common FEC Object Transmission Information elements that it uses in such a way that the length of each element is either fixed or can be determined from the encoded data itself.
CDPがFECスキームで指定されたエンコード形式を使用する場合、エンコードされた一般的なFECオブジェクトトランスミッション情報とエンコードされたスキーム固有のFECオブジェクト伝送情報を単に連結するか、それぞれがそれぞれを個別のフィールドまたはラッパーに運ぶことができます。CDP。前者の場合、連結されたオクテット文字列は、エンコードされたFECオブジェクト伝送情報として知られています。FECスキームは、各要素の長さが固定されているか、エンコードされたデータ自体から決定できるように使用する一般的なFECオブジェクト伝送情報要素のエンコード形式を定義する必要があります。
The encoding format of the Scheme-specific FEC Object Transmission Information element is defined by the FEC scheme. CDPs specify only how the resulting octet sequence is communicated. As with the encoding format for the Common FEC Object Transmission Information elements, the length of the Scheme-specific FEC Object Transmission Information must either be fixed or be possible to determine from the encoded data itself.
スキーム固有のFECオブジェクト伝送情報要素のエンコード形式は、FECスキームによって定義されます。CDPは、結果のオクテットシーケンスがどのように通信されるかのみを指定します。一般的なFECオブジェクト伝送情報要素のエンコード形式と同様に、スキーム固有のFECオブジェクト伝送情報の長さを修正するか、エンコードされたデータ自体から決定することができなければなりません。
The Scheme-specific FEC Object Transmission Information element is opaque to the CDP in the sense that inspecting the contents of this element can only be done if FEC scheme-specific logic is included in the CDP.
スキーム固有のFECオブジェクト伝送情報要素は、FECスキーム固有のロジックがCDPに含まれている場合にのみ行うことができるという意味で、CDPに不透明です。
Any encoding formats defined by the FEC scheme for the Common FEC Object Transmission Information elements are also opaque to the CDP in the same sense.
一般的なFECオブジェクト伝送情報要素のFECスキームによって定義されたエンコード形式も、同じ意味でCDPに不透明です。
Any encoding formats defined by the CDP for the Common FEC Object Transmission Information elements are not opaque in this sense, although it must be considered that different FEC Schemes may use different combinations of the Common FEC Object Transmission Information elements.
CDPで定義された一般的なFECオブジェクト伝送情報要素のCDPによって定義されたエンコード形式は、この意味では不透明ではありませんが、異なるFECスキームは、共通FECオブジェクト伝送情報要素の異なる組み合わせを使用する可能性があると考える必要があります。
The Mandatory FEC Object Transmission Information element is:
必須のFECオブジェクト伝送情報要素は次のとおりです。
FEC Encoding ID: an integer between 0 and 255 inclusive identifying a specific FEC scheme (Fully-Specified or Under-Specified.)
FECエンコーディングID：特定のFECスキームを識別する0〜255の整数（完全に指定または不足している）。
The Common FEC Object Transmission Information elements are described below. Note that with the exception of the FEC Instance ID, this specification does not provide complete definitions of these fields. Instead, only aspects of the abstract type are defined. The precise type and semantics are defined for each FEC scheme in the FEC scheme specification.
一般的なFECオブジェクト伝送情報要素を以下に説明します。FECインスタンスIDを除き、この仕様はこれらのフィールドの完全な定義を提供しないことに注意してください。代わりに、抽象型の側面のみが定義されています。正確なタイプとセマンティクスは、FECスキーム仕様の各FECスキームに対して定義されています。
FEC Instance ID: an integer between 0 and 65535 inclusive identifying an instance of an Under-Specified FEC scheme
FECインスタンスID：0〜65535の包括的識別不足のFECスキームのインスタンスの識別
Transfer-Length: a non-negative integer indicating the length of the object in octets
転送長：オクテットのオブジェクトの長さを示す非陰性整数
Encoding-Symbol-Length: a non-negative integer indicating the length of each encoding symbol in octets
エンコーディングシンボル長：オクテットの各エンコーディングシンボルの長さを示す非陰性整数
Maximum-Source-Block-Length: a non-negative integer indicating the maximum number of source symbols in a source block
最大ソースブロック長：ソースブロック内のソース記号の最大数を示す非陰性整数
Max-Number-of-Encoding-Symbols: a non-negative integer indicating the maximum number of encoding symbols (i.e., source plus repair symbols in the case of a systematic code)
最大番号エンコードシンボル：エンコーディングシンボルの最大数を示す非陰性整数（つまり、系統的コードの場合のソースプラス修復記号）
The FEC Instance ID MUST be used by all Under-Specified FEC schemes and MUST NOT be used by Fully-Specified FEC Schemes.
FECインスタンスIDは、すべての不足しているFECスキームで使用する必要があり、完全に指定されたFECスキームでは使用しないでください。
FEC Schemes define the precise type of those of the above elements that they use and in particular may restrict the value range of each element. FEC Schemes also define an encoding format for the subset of the above elements that they use. CDPs may also provide an encoding format for each element; in which case, this encoding format MUST be capable of representing values up to (2^^16)-1 in the case of the FEC Instance ID, (2^^48)-1 in the case of the Transfer-Length, and up to (2^^32)-1 for the other elements. CDPs may additionally or alternatively provide a mechanism to transport the encoded Common FEC Object Transmission information defined by the FEC scheme. For example, FLUTE [8] specifies an XML-based encoding format for these elements, but can also transport FEC scheme-specific encoding formats within the EXT-FTI LCT header extension.
FECスキームは、使用する上記の要素の正確なタイプを定義し、特に各要素の値範囲を制限する場合があります。FECスキームは、使用する上記の要素のサブセットのエンコード形式も定義します。CDPは、各要素にエンコード形式を提供する場合があります。その場合、このエンコード形式は、FECインスタンスIDの場合、（2 ^^ 16）-1、（2 ^^ 48）-1の場合の値を表すことができなければなりません。他の要素の場合（2 ^^ 32）-1まで。CDPは、FECスキームで定義されたエンコードされた共通FECオブジェクト伝送情報を輸送するメカニズムをさらにまたは代わりに提供する場合があります。たとえば、Flute [8]は、これらの要素のXMLベースのエンコーディング形式を指定しますが、ext-FTI LCTヘッダー拡張機能内でFECスキーム固有のエンコード形式を輸送することもできます。
The Scheme-specific FEC Object Transmission Information element may be used by an FEC Scheme to communicate information that is essential to the decoder and that cannot adequately be represented within the Mandatory or Common FEC Object Transmission Information elements.
スキーム固有のFECオブジェクトトランスミッション情報要素は、FECスキームによって使用されて、デコーダーに不可欠であり、必須または一般的なFECオブジェクト伝送情報要素内で適切に表現できない情報を通知できます。
From the point of view of a CDP, the Scheme-specific FEC Object Transmission Information element is an opaque, variable length, octet string. The FEC Scheme defines the structure of this octet string, which may contain multiple distinct elements.
CDPの観点から見ると、スキーム固有のFECオブジェクトトランスミッション情報要素は、不透明で可変の長さのオクテット文字列です。FECスキームは、複数の異なる要素を含む場合があるこのオクテット弦の構造を定義します。
The FEC Payload ID contains information that indicates to the FEC decoder the relationships between the encoding symbols carried by a particular packet and the FEC encoding transformation. For example, if the packet carries source symbols, then the FEC Payload ID indicates which source symbols of the object are carried by the packet. If the packet carries repair symbols, then the FEC Payload ID indicates how those repair symbols were constructed from the object.
FECペイロードIDには、FECデコーダーに特定のパケットによって運ばれるエンコーディングシンボルとFECエンコード変換との関係を示す情報が含まれています。たとえば、パケットにソースシンボルを搭載している場合、FECペイロードIDは、パケットによってオブジェクトのどのソースシンボルが運ばれるかを示します。パケットに修復記号がある場合、FECペイロードIDは、それらの修理記号がオブジェクトからどのように構築されたかを示します。
The FEC Payload ID may also contain information about larger groups of encoding symbols of which those contained in the packet are part. For example, the FEC Payload ID may contain information about the source block the symbols are related to.
FECペイロードIDには、パケットに含まれるものが一部であるエンコードシンボルのより大きなグループに関する情報も含まれている場合があります。たとえば、FECペイロードIDには、シンボルが関連しているソースブロックに関する情報が含まれている場合があります。
The FEC Payload ID for a given packet is essential to the decoder if and only if the packet itself is received. Thus, it must be possible to obtain the FEC Payload ID from the received packet. Usually, the FEC Payload ID is simply carried explicitly as a separate field within each packet. In this case, the size of the FEC Payload ID field SHOULD be a small fraction of the packet size. Some FEC schemes may specify means for deriving the relationship between the carried encoding symbols and the object implicitly from other information within the packet, such as protocol headers already present. Such FEC schemes could obviously only be used with CDPs which provided the appropriate information from which the FEC Payload ID could be derived.
特定のパケットのFECペイロードIDは、パケット自体が受信された場合にのみ、デコーダーにとって不可欠です。したがって、受信したパケットからFECペイロードIDを取得できる必要があります。通常、FECペイロードIDは、各パケット内の個別のフィールドとして明示的に運ばれます。この場合、FECペイロードIDフィールドのサイズは、パケットサイズのわずかな割合でなければなりません。一部のFECスキームは、既に存在するプロトコルヘッダーなど、パケット内の他の情報から、伝達されたエンコードシンボルとオブジェクトとの関係を導き出すための手段を指定する場合があります。このようなFECスキームは、明らかに、FECペイロードIDを導き出すことができる適切な情報を提供するCDPでのみ使用できます。
The encoding format of the FEC Payload ID, including its size, is defined by the FEC Scheme. CDPs specify how the FEC Payload ID is carried within data packets, i.e., the position of the FEC Payload ID within the CDP packet format and the how it is associated with encoding symbols.
そのサイズを含むFECペイロードIDのエンコード形式は、FECスキームによって定義されます。CDPSは、FECペイロードIDがデータパケット内でどのように運ばれるか、つまりCDPパケット形式内のFECペイロードIDの位置と、エンコードシンボルに関連付けられる方法を指定します。
FEC schemes for systematic FEC codes (that is, those codes in which the original source data is included within the encoded data) MAY specify two FEC Payload ID formats, one for packets carrying only source symbols and another for packets carrying at least one repair symbol. CDPs must include an indication of which of the two FEC Payload ID formats is included in each packet if they wish to support such FEC Schemes.
系統的FECコードのFECスキーム（つまり、元のソースデータがエンコードされたデータに含まれるコード）は、2つのFECペイロードID形式を指定できます。。CDPは、そのようなFECスキームをサポートする場合、各パケットに2つのFECペイロードID形式のどれが含まれているかを示すことを含める必要があります。
A specification for a new FEC scheme MUST include the following things:
新しいFECスキームの仕様には、次のことを含める必要があります。
1. The FEC Encoding ID value that uniquely identifies the FEC scheme. This value MUST be registered with IANA as described in Section 12.
1. FECエンコードID値は、FECスキームを一意に識別します。この値は、セクション12で説明されているように、IANAに登録する必要があります。
2. The type, semantics, and encoding format of one or two FEC Payload IDs. Where two FEC Payload ID formats are specified, then the FEC scheme MUST be a systematic FEC code and one FEC Payload ID format MUST be designated for use with packets carrying only source symbols, and the other FEC Payload ID format MUST be designated for use with packets carrying at least one repair symbol.
2. 1つまたは2つのFECペイロードIDのタイプ、セマンティクス、およびエンコード形式。2つのFECペイロードID形式が指定されている場合、FECスキームは系統的FECコードでなければならず、1つのFECペイロードID形式は、ソースシンボルのみを運ぶパケットで使用するために指定する必要があり、もう1つのFECペイロードID形式を使用するために指定する必要があります。少なくとも1つの修理シンボルを運ぶパケット。
3. The type and semantics of the FEC Object Transmission Information. The FEC Scheme MAY define additional restrictions on the type (including value range) of the Common FEC Object Transmission Information elements.
3. FECオブジェクト伝送情報のタイプとセマンティクス。FECスキームは、一般的なFECオブジェクト伝送情報要素のタイプ（値範囲を含む）の追加の制限を定義する場合があります。
4. An encoding format for the Common FEC Object Transmission Information elements used by the FEC Scheme.
4. FECスキームで使用される一般的なFECオブジェクト伝送情報要素のエンコード形式。
Fully-Specified FEC schemes MUST further specify:
完全に指定されたFECスキームは、さらに指定する必要があります。
1. A full specification of the FEC code.
1. FECコードの完全な仕様。
This specification MUST precisely define the valid FEC Object Transmission Information values, the valid FEC Payload ID values, and the valid packet payload sizes for any given object (where packet payload refers to the space -- not necessarily contiguous -- within a packet dedicated to carrying encoding symbol octets).
この仕様は、有効なFECオブジェクト伝送情報値、有効なFECペイロードID値、および特定のオブジェクトの有効なパケットペイロードサイズを正確に定義する必要があります（パケットペイロードは、スペースを指します - 必ずしも連続していない場合 - エンコードシンボルオクテットを運ぶ）。
Furthermore, given an object, valid values for each of the FEC Object Transmission Information elements used by the FEC Scheme, a valid FEC Payload ID value, and a valid packet payload size, the specification MUST uniquely define the values of the encoding symbol octets to be included in the packet payload of a packet with the given FEC Payload ID value.
さらに、オブジェクト、FECスキームで使用されるFECオブジェクト伝送情報要素のそれぞれ、有効なFECペイロードID値、および有効なパケットペイロードサイズの有効な値を指定すると、仕様はエンコードシンボルオクテットの値を一意に定義する必要があります。指定されたFECペイロードID値を持つパケットのパケットペイロードに含めます。
A common and simple way to specify the FEC code to the required level of detail is to provide a precise specification of an encoding algorithm which, given an object, valid values for each of the FEC Object Transmission Information elements used by the FEC Scheme for the object, a valid FEC Payload ID, and packet payload length as input produces the exact value of the encoding symbol octets as output.
必要なレベルの詳細にFECコードを指定する一般的で簡単な方法は、オブジェクトが与えられたエンコードアルゴリズムの正確な仕様を提供することです。オブジェクト、有効なFECペイロードID、および入力としてのパケットペイロード長は、出力としてエンコードシンボルオクテットの正確な値を生成します。
2. A description of practical encoding and decoding algorithms.
2. 実用的なエンコードおよびデコードアルゴリズムの説明。
This description need not be to the same level of detail as for (1) above; however, it must be sufficient to demonstrate that encoding and decoding of the code is both possible and practical.
この説明は、上記の（1）と同じレベルの詳細にある必要はありません。ただし、コードのエンコードとデコードが可能かつ実用的であることを実証するだけで十分でなければなりません。
FEC scheme specifications MAY additionally define the following:
FECスキームの仕様は、以下をさらに定義する場合があります。
1. Type, semantics, and encoding format of a Scheme-specific FEC Object Transmission Information element.
1. スキーム固有のFECオブジェクト伝送情報要素のタイプ、セマンティクス、およびエンコード形式。
Note that if an FEC scheme does not define a Scheme-specific FEC Object Transmission Information element, then such an element MUST NOT be introduced in future versions of the FEC Scheme. This requirement is included to ensure backwards-compatibility of CDPs designed to support only FEC Schemes that do not use the Scheme-specific FEC Object Transmission Information element.
FECスキームがスキーム固有のFECオブジェクト伝送情報要素を定義していない場合、そのような要素をFECスキームの将来のバージョンで導入してはなりません。この要件は、スキーム固有のFECオブジェクトトランスミッション情報要素を使用しないFECスキームのみをサポートするように設計されたCDPの後方互換性を確保するために含まれています。
Whenever an FEC scheme specification defines an 'encoding format' for an element, this must be defined in terms of a sequence of octets that can be embedded within a protocol. The length of the encoding format MUST either be fixed, or it must be possible to derive the length from examining the encoded octets themselves. For example, the initial octets may include some kind of length indication.
FECスキーム仕様が要素の「エンコード形式」を定義する場合はいつでも、これはプロトコル内に埋め込むことができるオクテットのシーケンスで定義する必要があります。エンコード形式の長さは固定する必要があります。または、エンコードされたオクテット自体を調べることから長さを導き出すことができなければなりません。たとえば、最初のオクテットには、何らかの長さの表示が含まれる場合があります。
FEC schemes SHOULD make use of the Common FEC Object Transmission Information elements in preference to including information in a Scheme-specific FEC Object Transmission Information element.
FECスキームは、スキーム固有のFECオブジェクトトランスミッション情報要素に情報を含めることを好むために、一般的なFECオブジェクト伝送情報要素を利用する必要があります。
FEC scheme specifications SHOULD use the terminology defined in this document and SHOULD follow the following format:
FECスキームの仕様は、このドキュメントで定義されている用語を使用し、次の形式に従う必要があります。
1. Introduction <define whether the scheme is Fully-Specified or Under-Specified>
1. はじめに<スキームが完全に指定されているか、不足しているかを定義します>
<describe the use-cases addressed by this FEC scheme>
<このFECスキームで扱われているユースケースを説明してください>
2. Formats and Codes
2. フォーマットとコード
2.1 FEC Payload ID(s) <define the type and format of one or two FEC Payload IDs>
2.1 FECペイロードID（s）<1つまたは2つのFECペイロードIDのタイプと形式を定義します>
2.2 FEC Object Transmission Information
2.2 FECオブジェクト伝送情報
2.2.1 Mandatory <define the value of the FEC Encoding ID for this FEC scheme>
2.2.1 必須<このFECスキームのFECエンコードIDの値を定義>
2.2.2 Common <describe which Common FEC Object Transmission Information elements are used by this FEC scheme, define their value ranges, and define an encoding format for them>
2.2.2 一般的なFECオブジェクト伝送情報要素がこのFECスキームで使用され、それらの値範囲を定義し、それらのエンコード形式を定義する>
2.2.3 Scheme-Specific <define the Scheme-specific FEC Object Transmission Information, including an encoding format, if required>
2.2.3 スキーム固有<エンコード形式を含むスキーム固有のFECオブジェクト伝送情報を定義します>
3. Procedures <describe any procedures that are specific to this FEC scheme, in particular derivation and interpretation of the fields in the FEC Payload ID and FEC Object Transmission Information.>
3. 手順<このFECスキームに固有の手順、特にFECペイロードIDおよびFECオブジェクト伝送情報のフィールドの派生と解釈を説明します。>
4. FEC code specification (for Fully-Specified FEC schemes only) <provide a complete specification of the FEC Code>
4. FECコード仕様（完全に指定されたFECスキームのみ）<FECコードの完全な仕様を提供>
Specifications MAY include additional sections such as those containing examples.
仕様には、例を含むなどの追加セクションが含まれる場合があります。
Each FEC scheme MUST be specified independently of all other FEC schemes; for example, in a separate specification or a completely independent section of a larger specification.
各FECスキームは、他のすべてのFECスキームとは独立して指定する必要があります。たとえば、別の仕様またはより大きな仕様の完全に独立したセクションで。
A specification for a CDP that uses this building block MUST include the following things:
このビルディングブロックを使用するCDPの仕様には、次のことを含める必要があります。
1. Definitions of an encoding format for the Mandatory FEC Object Transmission Information element.
1. 必須のFECオブジェクトトランスミッション情報要素のエンコード形式の定義。
2. A means to reliably communicate the Mandatory FEC Object Transmission Information element from sender to receiver(s) using the encoding format defined in (1).
2. （1）で定義されているエンコード形式を使用して、必須のFECオブジェクトトランスミッション情報要素を送信者から受信機に確実に通信する手段。
3. Means to reliably communicate the Common FEC Object Transmission Information element from sender to receiver(s) using either or both of (a) the encoding format defined by the FEC Scheme or (b) encoding formats defined by the CDP
3. （a）FECスキームによって定義されたエンコード形式または（b）CDPで定義されたエンコード形式のいずれかまたは両方を使用して、共通のFECオブジェクト伝送情報要素を送信者から受信機に確実に通信する手段
4. A means to reliably communicate the Scheme-specific FEC Object Transmission Information element from sender to receiver(s) using the encoding format of the Scheme-specific FEC Object Transmission Information element defined by the FEC scheme.
4. スキーム固有のFECオブジェクト情報要素を、FECスキームによって定義されたスキーム固有のFECオブジェクトトランスミッション情報要素のエンコード形式を使用して、送信者から受信機へのスキーム固有のFECオブジェクト情報要素を確実に通信する手段。
5. A means to communicate the FEC Payload ID in association with a data packet. Note that the encoding format of the FEC Payload ID is defined by the FEC Scheme.
5. データパケットに関連してFECペイロードIDを通信する手段。FECペイロードIDのエンコード形式は、FECスキームで定義されていることに注意してください。
If option (b) of (3) above is used, then the CDP MUST specify an encoding format for the Common FEC Object Transmission Information elements.
上記の（3）のオプション（b）を使用する場合、CDPは、一般的なFECオブジェクト伝送情報要素のエンコード形式を指定する必要があります。
CDPs MAY additionally specify the following things:
CDPはさらに次のことを指定できます。
1. A means to indicate whether the FEC Payload ID within a packet is encoded according to the format for packets including only source symbols or according to the format for packets including at least one repair symbol.
1. パケット内のFECペイロードIDが、ソースシンボルのみを含むパケットの形式に従って、または少なくとも1つの修理シンボルを含むパケットの形式に従ってエンコードされるかどうかを示す手段。
This section describes certain algorithms that are expected to be commonly required by FEC schemes or by CDPs. FEC Schemes and CDPs SHOULD use these algorithms in preference to scheme- or protocol-specific algorithms, where appropriate.
このセクションでは、FECスキームまたはCDPで一般的に必要とされると予想される特定のアルゴリズムについて説明します。FECスキームとCDPは、これらのアルゴリズムをスキームまたはプロトコル固有のアルゴリズムよりも優先して使用する必要があります。
This algorithm computes a partitioning of an object into source blocks so that all source blocks are as close to being equal length as possible. A first number of source blocks are of the same larger length, and the remaining second number of source blocks are of the same smaller length.
このアルゴリズムは、すべてのソースブロックが可能な限り等しい長さに近づくように、ソースブロックへのオブジェクトのパーティションを計算します。ソースブロックの最初の数は同じ長さで、残りの2番目のソースブロックの数は同じ長さです。
This algorithm is described in two steps, the second of which may be useful in itself as an independent algorithm in some cases. In the first step, the number of source symbols (T) and the number of source blocks (N) are derived from the Object transfer length (L), Maximum Source Block Length (B), and Symbol Length (E).
このアルゴリズムは2つのステップで説明されていますが、2番目のステップは、場合によっては独立したアルゴリズムとしてそれ自体が役立つ場合があります。最初のステップでは、ソースシンボルの数（t）とソースブロックの数（n）は、オブジェクト転送長（l）、最大ソースブロック長（b）、およびシンボル長（e）に由来します。
In the second step, the partitioning of the object is derived from the number of source symbols (T) and the number of source blocks (N). The partitioning is defined in terms of a first number of source blocks (I), a second number of source blocks (N-I), the length of each of the first source blocks (A_large), and the length of each of the second source blocks (A_small).
2番目のステップでは、オブジェクトのパーティション化は、ソースシンボルの数（t）の数とソースブロックの数（n）から派生します。パーティション化は、ソースブロックの最初の数（i）の数、ソースブロックの2番目の数（n-i）、最初のソースブロックのそれぞれの長さ（a_large）、および2番目のソースブロックのそれぞれの長さに関して定義されます。（小さな）。
The following notation is used in the description below:
以下の説明では、次の表記法を使用しています。
ceil[x] denotes x rounded up to the nearest integer.
ceil [x]は、xを最寄りの整数に丸めたことを示します。
floor[x] denotes x rounded down to the nearest integer.
フロア[x]は、xを最も近い整数まで丸めます。
Input:
入力：
B -- Maximum Source Block Length, i.e., the maximum number of source symbols per source block
B-最大ソースブロック長、つまり、ソースブロックごとのソース記号の最大数
L -- Transfer Length in octets
L-オクテットの転送長
E -- Encoding Symbol Length in octets Output:
E-オクテットの出力でのシンボル長のエンコード：
T -- the number of source symbols in the object.
T-オブジェクト内のソース記号の数。
N -- the number of source blocks into which the object shall be partitioned.
n-オブジェクトが分割されるソースブロックの数。
Algorithm:
アルゴリズム：
1. The number of source symbols in the transport object is computed as T = ceil[L/E].
1. トランスポートオブジェクトのソース記号の数は、t = ceil [l/e]として計算されます。
2. The transport object shall be partitioned into N = ceil[T/B] source blocks.
2. トランスポートオブジェクトは、n = ceil [t/b]ソースブロックに分割されなければなりません。
Input:
入力：
T -- the number of source symbols in the object.
T-オブジェクト内のソース記号の数。
N -- the number of source blocks into which the object is partitioned.
n-オブジェクトが分割されるソースブロックの数。
Output:
出力：
I -- the number of larger source blocks.
I-大きなソースブロックの数。
A_large -- the length of each of the larger source blocks in symbols.
A_LARGE-シンボル内の大きなソースブロックの各長さ。
A_small -- the length of each of the smaller source blocks in symbols.
A_SMALL-シンボル内の小さなソースブロックの各長さ。
Algorithm:
アルゴリズム：
1. A_large = ceil[T/N]
1. a_large = ceil [t/n]
2. A_small = floor[T/N]
2. a_small = floor [t/n]
3. I = T - A_small * N
3. i = t -a_small * n
Each of the first I source blocks then consists of A_large source symbols; each source symbol is E octets in length. Each of the remaining N-I source blocks consist of A_small source symbols; each source symbol is E octets in length, except that the last source symbol of the last source block is L-((L-1)/E) rounded down to the nearest integer)*E octets in length.
最初のIソースブロックは、A_Largeソースシンボルで構成されています。各ソースシンボルの長さはeオクテットです。残りのN-Iソースブロックのそれぞれは、A_SMALLソースシンボルで構成されています。各ソースシンボルの長さはeオクテットですが、最後のソースブロックの最後のソースシンボルはL-（（l-1）/e）長さが最も近い整数に丸められていることを除きます。
The FEC building block does not provide any support for congestion control. Any complete CDP MUST provide congestion control that conforms to [6], and thus this MUST be provided by another building block when the FEC building block is used in a CDP.
FECビルディングブロックは、混雑制御をサポートしません。完全なCDPは、[6]に適合する輻輳制御を提供する必要があるため、FECビルディングブロックがCDPで使用される場合、これは別のビルディングブロックによって提供されなければなりません。
There are no other specific requirements from other building blocks for the use of this FEC building block. However, any CDP that uses the FEC building block may use other building blocks, for example, to provide support for sending higher level session information within data packets containing FEC encoding symbols.
このFECビルディングブロックを使用するための他のビルディングブロックからの特定の要件はありません。ただし、FECビルディングブロックを使用するCDPは、たとえば他のビルディングブロックを使用して、FECエンコードシンボルを含むデータパケット内でより高いレベルのセッション情報を送信するためのサポートを提供する場合があります。
Data delivery can be subject to denial-of-service attacks by attackers which send corrupted packets that are accepted as legitimate by receivers. This is particularly a concern for multicast delivery because a corrupted packet may be injected into the session close to the root of the multicast tree, in which case, the corrupted packet will arrive at many receivers. This is particularly a concern for the FEC building block because the use of even one corrupted packet containing encoding data may result in the decoding of an object that is completely corrupted and unusable. It is thus RECOMMENDED that source authentication and integrity checking are applied to decoded objects before delivering objects to an application. For example, a SHA-1 hash [7] of an object may be appended before transmission, and the SHA-1 hash is computed and checked after the object is decoded, but before it is delivered to an application. Source authentication SHOULD be provided, for example, by including a digital signature verifiable by the receiver and computed on top of the hash value. It is also RECOMMENDED that a packet authentication protocol such as Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [9] be used to detect and discard corrupted packets upon arrival. Furthermore, it is RECOMMENDED that Reverse Path Forwarding checks be enabled in all network routers and switches along the path from the sender to receivers to limit the possibility of a bad agent successfully injecting a corrupted packet into the multicast tree data path.
データ配信は、攻撃者によるサービス拒否攻撃の対象となる可能性があります。攻撃者は、受信者によって合法として受け入れられている破損したパケットを送信します。これは、マルチキャストツリーのルートに近いセッションに破損したパケットが注入される可能性があるため、マルチキャスト配信の懸念事項です。その場合、破損したパケットは多くのレシーバーに到着します。これは、エンコードデータを含む1つの破損したパケットを使用することで、完全に破損して使用できないオブジェクトのデコードが生じる可能性があるため、特にFECビルディングブロックにとって懸念事項です。したがって、アプリケーションにオブジェクトを配信する前に、ソース認証と整合性チェックをデコードされたオブジェクトに適用することをお勧めします。たとえば、オブジェクトのSHA-1ハッシュ[7]は、送信前に追加される場合があり、SHA-1ハッシュはオブジェクトがデコードされた後に計算およびチェックされますが、アプリケーションに配信される前に確認されます。ソース認証は、たとえば、受信機が検証可能なデジタル署名を含めることで提供され、ハッシュ値の上に計算される必要があります。また、タイミングの効率的なストリーム損失耐性認証（TESLA）[9]などのパケット認証プロトコルを使用して、到着時に破損したパケットを検出および破棄することをお勧めします。さらに、すべてのネットワークルーターと送信者から受信機にパスに沿ってスイッチを入れて、不良エージェントが破損したパケットをマルチキャストツリーデータパスに正常に注入する可能性を制限することをお勧めします。
Another security concern is that some FEC information may be obtained by receivers out-of-band in a session description, and if the session description is forged or corrupted, then the receivers will not use the correct protocol for decoding content from received packets. To avoid these problems, it is RECOMMENDED that measures be taken to prevent receivers from accepting incorrect session descriptions, e.g., by using source authentication to ensure that receivers only accept legitimate session descriptions from authorized senders.
別のセキュリティ上の懸念は、セッションの説明で一部のFEC情報が帯域外の受信機によって取得される可能性があり、セッションの説明が偽造または破損している場合、受信者は受信パケットからコンテンツをデコードするために正しいプロトコルを使用しないことです。これらの問題を回避するために、レシーバーが誤ったセッションの説明を受け入れるのを防ぐための措置を講じることをお勧めします。
Values of FEC Encoding IDs and FEC Instance IDs are subject to IANA registration. They are in the registry named "Reliable Multicast Transport (RMT) FEC Encoding IDs and FEC Instance IDs" located at time of publication at: http://www.iana.org/assignments/rmt-fec-parameters
FECエンコードIDとFECインスタンスIDの値は、IANA登録の対象となります。公開時にある「信頼性の高いマルチキャストトランスポート（RMT）FEC IDSおよびFECインスタンスIDSをエンコードする」というレジストリにあります：http：//www.iana.org/assignments/rmt-fec-parameters
FEC Encoding IDs and FEC Instance IDs are hierarchical: FEC Encoding IDs scope independent ranges of FEC Instance IDs. Only FEC Encoding IDs that correspond to Under-Specified FEC schemes scope a corresponding set of FEC Instance IDs.
FECエンコーディングIDとFECインスタンスIDは階層的です。FECエンコードIDSスコープFECインスタンスIDの独立範囲。不足しているFECスキームに対応するFECエンコードIDのみが、FECインスタンスIDの対応するセットを範囲します。
The FEC Encoding ID and FEC Instance IDs are non-negative integers. In this document, the range of values for FEC Encoding IDs is 0 to 255. Values from 0 to 127 are reserved for Fully-Specified FEC schemes, and Values from 128 to 255 are reserved for Under-Specified FEC schemes, as described in more detail in Section 6.1.
FECエンコードIDおよびFECインスタンスIDは、非陰性整数です。このドキュメントでは、FECエンコードIDの値の範囲は0〜255です。0〜127の値は、完全に指定されたFECスキームに予約されており、128〜255の値は、詳細で説明されているように、不足しているFECスキームには予約されています。セクション6.1の詳細。
This document defines a name-space for FEC Encoding IDs named:
ietf:rmt:fec:encoding
The values that can be assigned within the "ietf:rmt:fec:encoding" name-space are numeric indexes in the range [0, 255], boundaries included. Assignment requests are granted on a "IETF Consensus" basis as defined in [2]. Section 7 defines explicit requirements that documents defining new FEC Encoding IDs should meet.
「IETF：RMT：FEC：エンコード」という名前内で割り当てることができる値は、範囲[0、255]の数値インデックス、境界が含まれます。[2]で定義されているように、割り当て要求は「IETFコンセンサス」ベースで付与されます。セクション7では、新しいFECエンコードIDを定義するドキュメントが満たすべき明示的な要件を定義しています。
This document also defines a name-space for FEC Instance IDs named:
ietf:rmt:fec:encoding:instance
The "ietf:rmt:fec:encoding:instance" name-space is a sub-name-space associated with the "ietf:rmt:fec:encoding" name-space. Each value of "ietf:rmt:fec:encoding" assigned in the range [128, 255] has a separate "ietf:rmt:fec:encoding:instance" sub-name-space that it scopes. Values of "ietf:rmt:fec:encoding" in the range [0, 127] do not scope a "ietf:rmt:fec:encoding:instance" sub-name-space.
「IETF：RMT：FEC：Encoding：Instance "NAME-SPACEは、「IETF：RMT：FEC：エンコード」名前空間に関連付けられたサブネームスペースです。範囲[128、255]で割り当てられた「IETF：RMT：FEC：FEC：Encoding」の各値には、スコープする個別の「IETF：RMT：FEC：ENCODING：INSTANCE」サブネームスペースがあります。「IETF：RMT：FEC：エンコード」の範囲[0、127]の値は、「IETF：RMT：FEC：Encoding：Instance」サブ名空間をスコープしません。
The values that can be assigned within each "ietf:rmt:fec:encoding: instance" sub-name-space are non-negative integers less than 65536. Assignment requests are granted on a "First Come First Served" basis as defined in [2]. The same value of "ietf:rmt:fec:encoding: instance" can be assigned within multiple distinct sub-name-spaces, i.e., the same value of "ietf:rmt:fec:encoding:instance" can be used for multiple values of "ietf:rmt:fec:encoding".
各「IETF：RMT：FEC：Encoding：Instance」サブネームスペースに割り当てることができる値は、65536未満の非陰性整数です。2]。「IETF：RMT：FEC：Encoding：Instance」の同じ値は、複数の個別のサブ名スペース、つまり「IETF：RMT：FEC：エンコーディング：インスタンス」の同じ値に割り当てることができます。複数の値に使用できます。「IETF：RMT：FEC：エンコード」の。
Requestors of "ietf:rmt:fec:encoding:instance" assignments MUST provide the following information:
「IETF：RMT：FEC：Encoding：Instance」の要求者は、次の情報を提供する必要があります。
o The value of "ietf:rmt:fec:encoding" that scopes the "ietf:rmt: fec:encoding:instance" sub-name-space. This must be in the range [128, 255].
o 「IETF：RMT：FEC：エンコード」の値は、「IETF：RMT：FEC：Encoding：Instance」サブネームスペースをスコープします。これは範囲内でなければなりません[128、255]。
o Point of contact information
o 連絡先情報
o A pointer to publicly accessible documentation describing the Under-Specified FEC scheme, associated with the value of "ietf: rmt:fec:encoding:instance" assigned, and a way to obtain it (e.g., a pointer to a publicly available reference-implementation or the name and contacts of a company that sells it, either separately or embedded in a product).
o 「IETF：RMT：FEC：ENCODING：インスタンス」の値に関連付けられた、不足しているFECスキームを説明する公開されているドキュメントへのポインタ。または、それを販売する会社の名前と連絡先、個別に、または製品に埋め込まれています）。
It is the responsibility of the requestor to keep all the above information up to date.
上記のすべての情報を最新の状態に保つことは、要求者の責任です。
This section lists the changes between the Experimental version of this specification, [3], and this version:
このセクションには、この仕様の実験バージョン[3]とこのバージョンの間の変更をリストします。
o The requirements for definition of a new FEC Scheme and the requirements for specification of new Content Delivery Protocols that use FEC Schemes are made more explicit to permit independent definition of FEC Schemes and Content Delivery Protocols.
o 新しいFECスキームの定義の要件と、FECスキームを使用する新しいコンテンツ配信プロトコルの仕様の要件は、FECスキームとコンテンツ配信プロトコルの独立した定義を可能にするために、より明確にされています。
o The definitions of basic FEC Schemes have been removed with the intention of publishing these separately.
o 基本的なFECスキームの定義は、これらを個別に公開することを目的として削除されました。
o The FEC Object Transmission Information (OTI) is more explicitly defined, and in particular, three classes of FEC OTI (Mandatory, Common, and Scheme-specific) are introduced to permit reusable definition of explicit fields in Content Delivery Protocols to carry these elements.
o FECオブジェクト伝送情報（OTI）はより明示的に定義されており、特に、これらの要素を運ぶためのコンテンツ配信プロトコルで明示的なフィールドの再利用可能な定義を許可するために、FEC OTI（必須、共通、およびスキーム固有）の3つのクラスが導入されています。
o FEC Schemes are required to specify a complete encoding for the FEC Object Transmission, which can be carried transparently by Content Delivery protocols (instead of defining explicit elements).
o FECスキームは、FECオブジェクト伝送の完全なエンコードを指定するために必要です。これは、明示的な要素を定義する代わりに）コンテンツ配信プロトコルによって透過的に運ぶことができます。
o The possibility for FEC Schemes to define two FEC Payload ID formats for use with source and repair packets, respectively, in the case of systematic FEC codes is introduced.
o 系統的FECコードの場合、FECスキームがソースパケットと修理パケットでそれぞれ使用する2つのFECペイロードID形式をそれぞれ定義する可能性が導入されています。
o The file blocking algorithm from FLUTE is included here as a common algorithm that is recommended to be reused by FEC Schemes when appropriate.
o フルートからのファイルブロッキングアルゴリズムは、適切な場合にFECスキームによって再利用することをお勧めする共通アルゴリズムとしてここに含まれています。
This document is largely based on RFC 3452 [3], and thus thanks are due to the additional authors of that document: J. Gemmell, L. Rizzo, M. Handley, and J. Crowcroft.
このドキュメントは主にRFC 3452 [3]に基づいているため、その文書の追加著者に感謝します：J。Gemmell、L。Rizzo、M。Handley、およびJ. Crowcroft。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[2] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[3] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC 3452, December 2002.
[3] Luby、M.、Vicisano、L.、Gemmell、J.、Rizzo、L.、Handley、M。、およびJ. Crowcroft、「フォワードエラー補正（FEC）ビルディングブロック」、RFC 3452、2002年12月。
[4] 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.
[4] Luby、M.、Vicisano、L.、Gemmell、J.、Rizzo、L.、Handley、M。、およびJ. Crowcroft、「信頼できるマルチキャストでのフォワードエラー補正（FEC）の使用」、RFC 3453、2002年12月。
[5] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
[5] Kermode、R。およびL. Vicisano、「信頼できるマルチキャストトランスポート（RMT）ビルディングブロックとプロトコルインスタンス化ドキュメントの著者ガイドライン」、RFC 3269、2002年4月。
[6] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[6] Mankin、A.、Romanov、A.、Bradner、S。、およびV. Paxson、「信頼できるマルチキャストトランスポートおよびアプリケーションプロトコルを評価するためのIETF基準」、RFC 2357、1998年6月。
[7] Federal Information Processing Standards Publication (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
[7] 連邦情報処理標準出版（FIPS Pub）180-1、Secure Hash Standard、1995年4月17日。
[8] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh, "FLUTE - File Delivery over Unidirectional Transport", RFC 3926, October 2004.
[8] Paila、T.、Luby、M.、Lehtonen、R.、Roca、V。、およびR. Walsh、「Flute-単方向輸送を介したファイル配信」、RFC 3926、2004年10月。
[9] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005.
[9] Perrig、A.、Song、D.、Canetti、R.、Tygar、J。、およびB. Briscoe、「タイミング効率の高いストリーム損失耐性認証（TESLA）：マルチキャストソース認証変換導入」、RFC 4082、2005年6月。
[10] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S., and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer", RFC 3048, January 2001.
[10] Whetten、B.、Vicisano、L.、Kermode、R.、Handley、M.、Floyd、S。、およびM. Luby、「1対1のバルクデータ転送用の信頼できるマルチキャスト輸送ビルディングブロック」、RFC 3048、2001年1月。
Authors' Addresses
著者のアドレス
Mark Watson Digital Fountain 39141 Civic Center Drive Suite 300 Fremont, CA 94538 U.S.A.
マークワトソンデジタルファウンテン39141シビックセンタードライブスイート300フリーモント、カリフォルニア94538 U.S.A.
EMail: mark@digitalfountain.com
Michael Luby Digital Fountain 39141 Civic Center Drive Suite 300 Fremont, CA 94538 U.S.A.
Michael Luby Digital Fountain 39141 Civic Center Drive Suite 300 Fremont、CA 94538 U.S.A.
EMail: luby@digitalfountain.com
Lorenzo Vicisano Digital Fountain 39141 Civic Center Drive Suite 300 Fremont, CA 94538 U.S.A.
Lorenzo Vicisano Digital Fountain 39141 Civic Center Drive Suite 300 Fremont、CA 94538 U.S.A.
EMail: lorenzo@digitalfountain.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。