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
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）IETFトラスト（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.
この文書では、効率的に提供するために、前方誤り訂正（FEC）コードを使用し、および/またはIPマルチキャストを超える大量のデータ転送のための信頼性を強化する方法について説明します。この文書は、バルクデータ転送のために、符号化データ自体に加えて、その情報を通信するためのフォーマット及び符号の定義のために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（ - 第4章を参照してください両方完全に指定し、アンダー指定FECスキームのための）に対応するFECスキームのRFCを書く方法についての詳細なガイドラインを提供します。
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.
この提案された標準仕様は、このように[3]更新RFC 3452の発行以来蓄積された経験と成長プロトコル成熟度に応じて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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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符号化シンボルは、受信機が、異なる符号化シンボルを受信しても、オブジェクトを再構成するために、すべての受信機に有用であることができるので、FECコードを使用すると、IPマルチキャストと信頼性の高い配信のコンテキストで有効です。さらに、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コードがのCDPと共に使用することができる方法を定義し、FEC符号またはアルゴリズムの仕様と組み合わされ、補助情報および手順を定義します。 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に共通である本書では説明主要な機能は、送信者から受信者（複数可）への情報の三種類の定義および輸送です。
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.
受信される関係する符号化シンボルの一つ以上の場合は、この情報は、受信機のみによって必要とされることに留意することが重要です。
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情報を含むことができ、パケットの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情報及び（S）のいずれかの帯域外又は内のデータ・パケットを送信側から受信側へ伝達されなければならないFEC情報の両方を指定します。例えば、この情報を搬送するためのプロトコルメカニズム、フィールド及びパケットフォーマットの仕様は、この文書の範囲外です。代わりに、この文書では、より高いレベルで通信し、詳細なフィールドと、パケットフォーマットが定義されなければならないところですFECスキームおよびコンテンツ配信プロトコルの仕様のための詳細な要件を、提供しなければならない情報を指定します。
FEC information is classified as follows:
次のように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.
2. FEC information associated with specific encoding symbols for an object
オブジェクトの特定の符号化シンボルに関連付けられた前記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.
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:
2つの「容器」は、上述のFEC情報を通信するために設けられているが、FEC情報のクラスと使用される機構との間に1対1の対応が必ずしも存在しません。二つのメカニズムは以下のとおりです。
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.
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.
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.
FECスキームの2種類は、この文書で定義されています：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及びFEC符号化ID及びFECインスタンスIDの両方で指定のFECスキームのオブジェクトをデコードするデコーダのために必須です。このように、彼らは、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.
タイプ、意味論、及びFECペイロードID及びFECオブジェクト伝送情報の符号化フォーマットを定義する必要があり、O。
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オブジェクト伝送情報要素を定義し、instance-を除き、スキーム固有の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スキームのインスタンスが完全にタプル（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スキームとアンダー特定FECスキームの値の範囲は128-255のためのFEC符号化IDの値の範囲0〜127を予約します。
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オブジェクト伝送情報は、いくつかの要素から構成されてもよいし、次のように各要素は、三種類のものであってもよいです。
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.
必須：これらの要素は、本明細書で定義され、各FECスキームの2種類のうちの少なくとも一方のために必須です。必須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オブジェクト伝送情報要素の種類、意味論、および符号化フォーマットを指定します。得られたオクテットストリングが「符号化されたスキーマ固有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. 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. A確実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オブジェクト伝送情報要素のそれぞれのための個々の符号化フォーマットを定義することができます。共通FECオブジェクト伝送情報要素を搬送するものとする方法の選択、（a）又は（b）に示すように、コンテンツ配信プロトコルによって行われ、そして特定の方法は、コンテンツ配信プロトコル仕様で定義されるべきです。 CDPは、1つまたは両方のオプションのサポートを提供する場合があります。
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.
異なるFECスキームが共通FECオブジェクト伝送情報要素の異なる組み合わせを使用できることを考慮しなければならないが、共通FECオブジェクト伝送情報要素のCDPによって定義される任意の符号化フォーマットは、この意味では不透明ではありません。
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符号化は、次のとおり、特定の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：アンダー指定FECスキームのインスタンスを識別する0から65535までの整数
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は、各要素の符号化フォーマットを提供してもよいです。その場合には、この符号化形式（2 ^^ 16）-1 FECインスタンスIDの場合、（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
FECペイロードIDは、FECデコーダに特定のパケットとFEC符号化変換によって運ばれる符号化シンボル間の関係を示す情報を含んでいます。パケットがソースシンボルを搬送する場合、例えば、次にFECペイロードIDは、オブジェクトのソースシンボルはパケットによって運ばれるかを示します。パケットは、リペアシンボルを運ぶ場合は、FECペイロード
ID indicates how those repair symbols were constructed from the object.
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スキームによって定義されます。 CDPは、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フォーマット、少なくとも一つのリペアシンボルを運ぶパケットのための唯一のソースシンボルを運ぶパケットのための1つおよび別のものを指定するかもしれ。 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スキームを識別するFEC符号化ID値。セクション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フォーマットは、ソースシンボルを搬送するパケットで使用するために指定されなければならない、そして、他のFECペイロードIDフォーマットがで使用するために指定されなければなりません少なくとも一つのリペアシンボルを搬送するパケット。
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スキームは、さらに指定する必要があります。
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).
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ペイロードID値、および有効なパケットペイロードサイズによって使用されるFECオブジェクト伝送情報要素のそれぞれの有効な値が与えられると、仕様が一意に符号化シンボルオクテットの値を定義する必要があります所与の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スキームによって使用されるFECオブジェクト伝送情報要素のそれぞれの有効な値の正確な仕様を提供することです入力としてオブジェクト、有効なFECペイロードID、およびパケットペイロード長は、出力として符号化シンボルオクテットの正確な値を生成します。
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.
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.1 FEC Payload ID(s) <define the type and format of one or two
FEC Payload IDs>
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ペイロードID及びFECオブジェクト伝送情報内のフィールドの特定の導出と解釈において、このFECスキームに固有の任意の手順を記載しています。>
4. FEC code specification (for Fully-Specified FEC schemes only) <provide a complete specification of the FEC Code>
前記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.
必須FECオブジェクト伝送情報要素の符号化フォーマットの1.定義。
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. Aを確実に（1）で定義された符号化形式を使用して、（S）送信側から受信側へ強制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
いずれかまたはFECスキームまたはCDPによって定義された（b）の符号化フォーマットによって定義された（a）の符号化フォーマットの両方の使用を確実に送信側から受信側へ共通FECオブジェクト伝送情報要素を通信するための手段3（S）
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. Aを確実にFECスキームによって定義されたスキーマ固有FECオブジェクト伝送情報要素の符号化フォーマットを使用して、（S）送信側から受信側へのスキーム固有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. Aは、データパケットに関連して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. Aは、パケット内のFECペイロードIDは、パケットが唯一のソースシンボルを含む、または少なくとも一つの修復シンボルを含むパケットのフォーマットに従ってのフォーマットに従って符号化されているかどうかを示すことを意味します。
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は、アルゴリズムをscheme-またはプロトコル固有に優先して、これらのアルゴリズムを使用するべきです。
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).
このアルゴリズムは、二段階に記載されている、第二のは、いくつかの場合において独立アルゴリズムとしてそれ自体において有用であり得ます。最初のステップでは、ソースシンボルの数（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).
第二ステップでは、オブジェクトの分割はソースシンボルの数（T）及びソースブロックの数（N）に由来します。分割はソースブロック（I）の最初の数、ソースブロックの第二の数（NI）、最初のソースブロック（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
E - オクテットで符号化シンボルの長さ
Output:
出力：
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:
アルゴリズム：
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）は最も近い整数に切り捨て）長さ* 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.
データの配信は、受信機によって正当なものとして受け入れている破損したパケットを送信する攻撃者によってサービス拒否攻撃の対象にすることができます。破損したパケットは、破損したパケットは、多くの受信機に到着した場合にマルチキャストツリーのルートに近いセッションに注入することができるので、これは特に、マルチキャスト配信のための関心事です。符号化データを含む一つでも破損したパケットの使用が完全に破損し使用できないオブジェクトの復号化をもたらし得るので、これは特にFECビルディングブロックの関心事です。このようにチェック源認証と完全性をアプリケーションにオブジェクトを配信する前にデコードされたオブジェクトに適用することをお勧めします。例えば、オブジェクトのSHA-1ハッシュ[7]は、送信の前に付加することができる、およびSHA-1ハッシュを計算し、チェックオブジェクトがデコードされた後に、それがアプリケーションに配信される前にされています。ソース認証は、例えば、受信機によって検証可能とハッシュ値の上に計算されたデジタル署名を含めることによって、提供されるべきです。また、そのようなタイミングの効率的な流れ損失トレラント認証（テスラ）のようなパケット認証プロトコル[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登録の対象となっています。 http://www.iana.org/assignments/rmt-fec-parameters：彼らはで発行時点のものであり、「信頼できるマルチキャストトランスポート（RMT）FEC符号化IDとFECインスタンスIDが」という名前のレジストリであります
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インスタンスIDの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 127から0〜255の値は、完全に指定FECスキームのために予約されており、よりに記載されているように128から255までの値は、下で指定のFECスキームのために予約されています6.1節で詳細。
This document defines a name-space for FEC Encoding IDs named: ietf:rmt:fec:encoding
IETF：この文書では、名前のFEC符号化IDの名前空間を定義しRMT：FEC：エンコード
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.
内で割り当て可能な値「：RMT：FEC：IETFコード」名前空間は範囲[0、255]の数値のインデックスであり、境界が含まれます。割り当て要求は、[2]で定義されている「IETFコンセンサス」に基づき付与されます。第7節は、新しいFECエンコーディングIDを定義する文書が満たさなければならない明示的な要件を定義します。
This document also defines a name-space for FEC Instance IDs named: ietf:rmt:fec:encoding:instance
IETF：この文書はまた、名前のFECインスタンスIDの名前空間を定義しRMT：FEC：エンコーディング：インスタンス
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：符号：インスタンス」名前空間名空間「：RMT：FEC符号化IETF」に関連付けられたサブ名前空間です。 「：RMT：FEC：IETFエンコーディング」の各値「：RMT：FEC：符号：例えばIETF」サブ名前空間がスコープこと範囲[128、255]で割り当ては、別個を有しています。 "：RMT：FEC：IETFエンコーディング" の値範囲[0、127]しない範囲 "IETF：RMT：FEC：符号：例えば" サブ名前空間。
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".
各内割り当てることができる値「：RMT：IETF FEC：符号：例えば」サブ名前空間は、で定義されるよう未満65536割り当て要求は、「まず最初に配信是非」に基づいて付与される非負整数です[ 2]。複数の異なるサブ名前空間、すなわち、同一の値の範囲内割り当てることができる「IETF：RMT：FEC：エンコーディング：インスタンスは、」複数の値のために使用することができる「：RMT：FEC：符号化インスタンスは、IETF」の同じ値"：RMT：FEC：エンコーディングIETF" の。
Requestors of "ietf:rmt:fec:encoding:instance" assignments MUST provide the following information:
「：RMT：FEC：符号：IETFインスタンス」のリクエスタ割り当ては、次の情報を提供しなければなりません。
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].
"IETF：RMT：FEC：符号：インスタンス" スコープサブネームスペースを "：RMT：FEC符号化IETF" の値O。これは、範囲[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).
「：RMT：FEC：符号：例えばIETF」が割り当てられ、それを得るための方法（例えば、公的に利用可能なreference-へのポインタの値に関連付けられたアンダー指定FECスキームを記述公的にアクセス可能なドキュメントへのポインタO実装または名前と、それを販売する会社の連絡先、別々に、または製品に組み込まれました）。
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.
基本的なFECスキームの定義oを個別にこれらを発行することを意図して削除されました。
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の三つのクラス（必須、一般的な、そして特有のスキーム）は、これらの要素を運ぶために、コンテンツ配信プロトコルでは明示的なフィールドの再利用可能な定義を可能とするために導入されています。
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符号の場合、それぞれ、ソースおよびリペアパケットと一緒に使用するための2つのFECペイロードIDフォーマットを定義するためのFECスキームの可能性が導入されます。
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.
推奨される一般的なアルゴリズムは、適切なFECスキームによって再利用するようO FLUTEからファイルブロックのアルゴリズムはここに含まれています。
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.リゾー、M.ハンドレー、およびJ.クロウクロフト。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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]ルビー、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト、 "前方誤り訂正（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]ルビー、M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト、 "信頼できるマルチキャストの前方誤り訂正（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、RFC 3269、2002年4月 "信頼できるマルチキャストトランスポート（RMT）ビルディングブロックとプロトコルのインスタンス文書の作者のガイドライン"。
[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]マンキン、A.、ロマノフ、A.、ブラドナー、S.、およびV.パクソン、 "信頼できるマルチキャストトランスポート及びアプリケーションプロトコルを評価するための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、セキュアハッシュ標準、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.、ルビー、M.、Lehtonenの、R.、ロカ、V.、およびR.ウォルシュ、 "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.、歌、D.、カネッティ、R.、Tygar、J.、およびB.ブリスコウ、 "時限効率ストリーム損失トレラント認証（テスラ）：マルチキャスト発信元認証は、はじめの変換" は、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.、ハンドレー、M.、フロイド、S.、およびM.ルビー、 "信頼できるマルチキャストトランスポート・ビルディング・ブロック一対多バルクデータ転送のための" 、RFC 3048、2001年1月。
Authors' Addresses
著者のアドレス
Mark Watson Digital Fountain 39141 Civic Center Drive Suite 300 Fremont, CA 94538 U.S.A.
マーク・ワトソンデジタル噴水39141シビックセンタードライブスイート300フリーモント、CA 94538 U.S.A.
EMail: mark@digitalfountain.com
メールアドレス：mark@digitalfountain.com
Michael Luby Digital Fountain 39141 Civic Center Drive Suite 300 Fremont, CA 94538 U.S.A.
マイケル・ルビーデジタル噴水39141シビックセンタードライブスイート300フリーモント、CA 94538 U.S.A.
EMail: luby@digitalfountain.com
メールアドレス：luby@digitalfountain.com
Lorenzo Vicisano Digital Fountain 39141 Civic Center Drive Suite 300 Fremont, CA 94538 U.S.A.
ロレンツォVicisanoデジタル噴水39141シビックセンタードライブスイート300フリーモント、CA 94538 U.S.A.
EMail: lorenzo@digitalfountain.com
メールアドレス：lorenzo@digitalfountain.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。