Network Working Group M. Luby
Request for Comments: 3452 Digital Fountain
Category: Experimental L. Vicisano
Cisco
J. Gemmell
Microsoft
L. Rizzo
Univ. Pisa
M. Handley
ICIR
J. Crowcroft
Cambridge Univ.
December 2002
Forward Error Correction (FEC) Building Block
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document generally describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for data transport. The primary focus of this document is the application of FEC codes to one-to-many reliable data transport using IP multicast. This document describes what information is needed to identify a specific FEC code, what information needs to be communicated out-of-band to use the FEC code, and what information is needed in data packets to identify the encoding symbols they carry. The procedures for specifying FEC codes and registering them with the Internet Assigned Numbers Authority (IANA) are also described. This document should be read in conjunction with and uses the terminology of the companion document titled, "The Use of Forward Error Correction (FEC) in Reliable Multicast".
この文書では、一般的に効率的に提供および/またはデータ転送のための信頼性を強化するために誤り訂正（FEC）コードをフォワードの使用方法について説明します。このドキュメントの主な焦点は、IPマルチキャストを使用して1対多の信頼性の高いデータ転送にFECコードのアプリケーションです。この文書は、特定のFECコードを識別するために必要とされる情報を説明し、どのような情報は、FECコードを使用するアウトオブバンド通信される必要があり、彼らが運ぶ符号化シンボルを識別するために、データパケットにどのような情報が必要とされています。 FEC符号を指定してインターネット割り当て番号機関（IANA）でそれらを登録するための手順も記載されています。この文書では、と合わせて読むと、「信頼性マルチキャストにおける前方誤り訂正（FEC）の使用」というタイトルのコンパニオン文書の用語を使用してしなければなりません。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2. Rationale. . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Functionality. . . . . . . . . . . . . . . . . . . . . . . 3
3.1 FEC Encoding ID and FEC Instance ID. . . . . . . . . . . 5
3.2 FEC Payload ID and FEC Object Transmission Information . 6
4. Applicability Statement . . . . . . . . . . . . . . . . . 7
5. Packet Header Fields . . . . . . . . . . . . . . . . . . . 8
5.1 Small Block, Large Block and Expandable FEC Codes. . . . 8
5.2 Small Block Systematic FEC Codes . . . . . . . . . . . . 9
6. Requirements from other building blocks. . . . . . . . . . 11
7. Security Considerations. . . . . . . . . . . . . . . . . . 11
8. IANA Considerations. . . . . . . . . . . . . . . . . . . . 12
8.1 Explicit IANA Assignment Guidelines. . . . . . . . . . . 12
9. Intellectual Property Disclosure . . . . . . . . . . . . . 13
10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . 14
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 15
13. Full Copyright Statement . . . . . . . . . . . . . . . . . 16
This document describes how to use Forward Error Correction (FEC) codes to provide support for reliable delivery of content using IP multicast. This document should be read in conjunction with and uses the terminology of the companion document [4], which describes the use of FEC codes within the context of reliable IP multicast transport and provides an introduction to some commonly used FEC codes.
この文書では、IPマルチキャストを使用して、コンテンツの信頼性の高い配信のためのサポートを提供するために、前方誤り訂正（FEC）コードを使用する方法について説明します。この文書ではと併せて読むと信頼性の高いIPマルチキャストトランスポートのコンテキスト内でFEC符号の使用について説明し、いくつかの一般的に使用されるFEC符号への導入を提供するコンパニオン文献[4]の用語を使用しなければなりません。
This document describes a building block as defined in RFC 3048 [9]. This document is a product of the IETF RMT WG and follows the general guidelines provided in RFC 3269 [3].
この文書は、RFC 3048で定義されるように構築ブロックを説明し[9]。この文書は、IETF RMT WGの産物である[3] RFC 3269に設けられた一般的なガイドラインに従います。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC2119 [2]に記載のように解釈されます。
Statement of Intent
主旨書
This memo contains part of the definitions necessary to fully specify a Reliable Multicast Transport protocol in accordance with RFC 2357. As per RFC 2357, the use of any reliable multicast protocol in the Internet requires an adequate congestion control scheme.
このメモは、完全にRFC 2357を1としてRFC 2357.に従い、信頼性の高いマルチキャストトランスポートプロトコルを指定するために必要な定義の一部が含まれている、インターネットのいずれかの信頼できるマルチキャストプロトコルの使用は、適切な輻輳制御方式が必要です。
While waiting for such a scheme to be available, or for an existing scheme to be proven adequate, the Reliable Multicast Transport working group (RMT) publishes this Request for Comments in the "Experimental" category.
このようなスキームを待っているが利用できるようにする、または既存のスキームのための十分な証明することが、信頼性の高いマルチキャスト交通ワーキンググループ（RMT）は「実験」カテゴリ内のコメントのためにこの要求を発行しています。
It is the intent of RMT to re-submit this specification as an IETF Proposed Standard as soon as the above condition is met.
すぐに上記の条件が満たされたとしてIETFのProposed Standardとして、この明細書を再提出するRMTの意図です。
FEC codes are a valuable basic component of any transport protocol that is to provide reliable delivery of content. Using FEC codes is valuable in the context of IP multicast and reliable delivery because FEC encoding symbols can be useful to all receivers for reconstructing content 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コードは、コンテンツの信頼できる配信を提供することを目的とする任意のトランスポートプロトコルの有益な基本的なコンポーネントです。 FEC符号化シンボルは、受信機が、異なる符号化シンボルを受信した場合でも、コンテンツを再構成するためのすべての受信機に有用であることができるので、FECコードを使用すると、IPマルチキャストと信頼性の高い配信の文脈において有用です。さらに、FECコードは改善またはさえ失われたパケットの再送を要求するために受信機から送信者へのフィードバックの必要性を排除することができます。
The goal of the FEC building block is to describe functionality directly related to FEC codes that is common to all reliable content delivery IP multicast protocols, and to leave out any additional functionality that is specific to particular protocols. The primary functionality described in this document that is common to all such protocols that use FEC codes are FEC encoding symbols for an object that is included in packets that flow from a sender to receivers. This document for example does not describe how receivers may request transmission of particular encoding symbols for an object. This is because although there are protocols where requests for transmission are of use, there are also protocols that do not require such requests.
FECビルディングブロックの目標は、すべての信頼性の高いコンテンツ配信IPマルチキャストプロトコルに共通するFECコードに直接関連する機能を記述するために、特定のプロトコルに固有の任意の追加機能を除外することです。 FECコードを使用するこのようなすべてのプロトコルに共通で、この文書に記載され主要な機能は、受信機に送信機から流れるパケットに含まれるオブジェクトのFEC符号化シンボルです。例えば、この文書では、受信機がオブジェクトの特定の符号化シンボルの送信を要求することができる方法を記載していません。伝送のための要求が有用であるプロトコルがありますが、このような要求を必要としないプロトコルもあるからです。
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マルチキャストに限定されるものではありません。
This section describes FEC information that is either to be sent out-of-band or in packets. The FEC information is associated with transmission of data about 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 protocols may not use session-control or feedback packets.
このセクションでは、いずれかの帯域外又はパケットで送信されるFEC情報を記述する。 FEC情報は、特定のオブジェクトに関するデータの送信に関連しています。データ・パケット、セッション制御パケットとフィードバックパケット：FEC情報を含むことができ、パケットの3つのクラスがあります。彼らは一般的にFEC異なる種類の情報が含まれています。いくつかのプロトコルは、セッション制御またはフィードバックパケットを使用することはできませんので注意してください。
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.
データパケットは、時々もセッション制御パケットとして働くことができます。データ及びセッション制御パケットの両方は、一般的に受信機に向けて送信側から下流側に移動し、マルチキャストチャネルまたはユニキャストを使用して、特定の受信機に送信されます。
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 the FEC information that must be carried in data packets and the other FEC information that must be communicated either out-of-band or in data packets. This document does not specify out-of-band methods nor does it specify the way out-of-band FEC information is associated with FEC information carried in data packets. These methods must be specified in a complete protocol instantiation that uses the FEC building block. FEC information is classified as follows:
この文書は、データパケットの帯域外またはデータパケットのいずれかで通信されなければならない他のFEC情報で搬送されなければならないFEC情報を指定します。この文書では、帯域外の方法を指定しておらず、FEC情報がデータパケットで運ばFEC情報に関連付けられている帯域外の方法を指定しません。これらのメソッドは、FECビルディングブロックを使用して完全なプロトコルのインスタンスで指定する必要があります。次のようにFEC情報が分類されます：
1) FEC Encoding ID
1）FEC符号化ID
Identifies the FEC encoder being used and allows receivers to select the appropriate FEC decoder. The value of the FEC Encoding ID MUST be the same for all transmission of data related to a particular object, but MAY vary across different transmissions of data about different objects, even if transmitted to the same set of multicast channels and/or using a single upper-layer session. The FEC Encoding ID is subject to IANA registration.
使用されるFECエンコーダを識別し、受信機は、適切なFECデコーダを選択することができます。 FEC符号化IDの値は、特定のオブジェクトに関連するすべてのデータ送信のために同じでなければならないが、同じマルチキャストチャネルのセットおよび/または単を使用して送信しても、異なるオブジェクトに関するデータの異なる送信を横切って異なるかもしれ上位層セッション。 FEC符号化IDは、IANA登録の対象となります。
2) FEC Instance ID
2）FECインスタンスID
Provides a more specific identification of the FEC encoder being used for an Under-Specified FEC scheme. This value is not used for Fully-Specified FEC schemes. (See Section 3.1 for the definition of Under-Specified and Fully-Specified FEC schemes.) The FEC Instance ID is scoped by the FEC Encoding ID, and is subject to IANA registration.
アンダー指定FEC方式に使用されるFEC符号器のより具体的な同定を提供します。この値は、完全に指定されたFECスキームには使用されません。 （アンダー指定され、完全に指定されたFECスキームの定義については、セクション3.1を参照。）FECインスタンスIDは、FEC符号化IDによってスコープ、およびIANA登録の対象とされています。
3) FEC Payload ID
3）FECペイロードID
Identifies the encoding symbol(s) in the payload of the packet. The types and lengths of the fields in the FEC Payload ID, i.e., the format of the FEC Payload ID, are determined by the FEC Encoding ID. The full specification of each field MUST be uniquely determined by the FEC Encoding ID for Fully-Specified FEC schemes, and MUST be uniquely determined by the combination of the FEC Encoding ID and the FEC Instance ID for Under-Specified FEC schemes. As an example, for the Under-Specified FEC scheme with
パケットのペイロードに符号化シンボル（複数可）を識別する。タイプとFECペイロードIDフィールドの長さ、すなわち、FECペイロードIDの形式は、FEC符号化IDによって決定されます。各フィールドの完全な仕様は、一意完全に指定FECスキームのためにFEC符号化IDによって決定されなければならない、一意アンダー指定FECスキームのFEC符号化ID及びFECインスタンスIDの組み合わせによって決定されなければなりません。アンダー指定FECスキームのための一例として、
FEC Encoding ID 129 defined in Section 5.1, the fields in the FEC Payload ID are a 32-bit Source Block Number followed by a 32-bit Encoding Symbol ID, where the full specification of both of these fields depends on the FEC Instance ID.
セクション5.1で定義されたFEC符号化ID 129は、FECペイロードIDのフィールドは、32ビットソースブロック番号は、これらのフィールドの両方の完全な仕様は、FECインスタンスIDに依存する32ビットの符号化シンボルID、が続きます。
4) FEC Object Transmission Information
4）FECオブジェクト伝送情報
This is information regarding the encoding of a specific object needed by the FEC decoder. As an example, for the Under-Specified FEC scheme with FEC Encoding ID 129 defined in Section 5.1, this information might include the lengths of the different source blocks that make up the object and the overall object length. This might also include specific parameters of the FEC encoder.
これは、FECデコーダが必要とする特定のオブジェクトの符号化に関する情報です。一例として、セクション5.1で定義されたFEC符号化ID 129とアンダー指定FECスキームのために、この情報は、オブジェクトとオブジェクト全体の長さを構成する異なるソースブロックの長さを含み得ます。また、これはFECエンコーダの特定のパラメータを含めることができます。
The FEC Encoding ID, FEC Instance ID (for Under-Specified FEC schemes) and 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. In any case, the means for communicating this to a receiver is outside the scope of this document. The FEC Payload ID MUST be included in the data packet header fields, as it provides a description of the encoding symbols contained in the packet.
（アンダー指定FECスキームの）FEC符号化ID、FECインスタンスIDとFECオブジェクト伝送情報は、セッション制御パケット内の、またはいくつかの他の手段によって、データパケットヘッダ内の受信機に送信することができます。いずれの場合においても、受信機にこれを伝達するための手段は、この文書の範囲外です。それがパケットに含まれる符号化シンボルの説明を提供するようにFECペイロードIDは、データ・パケットのヘッダフィールドに含まれなければなりません。
The FEC Encoding ID is a numeric index that identifies a specific FEC scheme OR a class of encoding schemes that share the same FEC Payload ID format.
FEC符号化IDは、特定のFECスキームOR同じFECペイロードIDフォーマットを共有する符号化方式のクラスを識別する数値指標です。
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. The FEC Encoding ID uniquely identifies a Fully-Specified FEC scheme. Companion documents of this specification may specify Fully-Specified FEC schemes and associate them with FEC Encoding ID values.
FEC方式は、符号化方式が正式と完全に独立した実装は、IETF RFCで仕様からエンコーダおよびデコーダの両方を実現することができるように、指定されている場合、完全に指定FECスキームです。 FEC符号化IDは一意に完全に指定されたFECスキームを識別する。この仕様のコンパニオンドキュメントは完全に指定されたFECスキームを指定し、FEC符号化ID値とそれらを関連付けることができます。
These documents MUST also specify a format for the FEC Payload ID and specify the information in the FEC Object Transmission Information.
これらの文書はまた、FECペイロードIDの形式を指定し、FECオブジェクト伝送情報に情報を指定する必要があります。
It is possible that a 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 schemes as an Under-Specified FEC scheme. The following holds for an Under-Specified FEC scheme: o The fields and their formats of the FEC Payload ID and the specific information in the FEC Object Transmission Information MUST be defined for the Under-Specified FEC scheme.
どちらかの仕様が単純に利用できないか、当事者がそれが符号化方式を所有しており、アルゴリズムや仕様を開示することを望んでいないが存在するので、FECスキームは、完全指定FECスキームではないかもしれない可能性があります。私たちは、アンダー指定FECスキームなどのFEC符号化方式を参照してください。フィールド及びFECペイロードID及びFECオブジェクト伝送情報内の特定情報のその形式oをアンダー指定FECスキームに定義する必要があります。以下はアンダー指定FECスキームにも当てはまります。
o A value for the FEC Encoding ID MUST be reserved and associated with the fields and their formats of the FEC Payload ID and the specific information in the FEC Object Transmission Information. An already reserved FEC Encoding ID value MUST be reused if the associated FEC Payload ID has the same fields and formats and the FEC Object Transmission Information has same information as the ones needed for the new Under-Specified FEC scheme.
FEC符号化IDの値が予約されたフィールドとFECペイロードID及びFECオブジェクト伝送情報内の特定情報のその形式に関連付けられている必要があり、O。関連するFECペイロードIDが同じフィールドとフォーマットを持っており、FECオブジェクト伝送情報が新しいの下では、指定されたFECスキームのために必要なものと同じ情報を持っている場合、既に予約さFEC符号化ID値が再利用されなければなりません。
o A value for the FEC Instance ID MUST be reserved.
O FECインスタンスIDの値が予約されなければなりません。
An Under-Specified FEC scheme is fully identified by the tuple (FEC Encoding ID, FEC Instance ID). The tuple MUST identify a single scheme 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 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スキーム、例えば、一般に入手可能な参照実装や名前と、それを販売する会社の連絡先へのポインタを取得する方法についての情報を提供できなければなりません別々に、または他の製品に組み込まれました。
Different Under-Specified FEC schemes that share the same FEC Encoding ID -- but have different FEC Instance IDs -- also share the same fields and corresponding formats of the FEC Payload ID and specify the same information in the FEC Object Transmission Information.
しかし、異なるFECインスタンスIDを持っている - - 同じFEC符号化IDを共有する異なるアンダー指定されたFEC方式も同じフィールドとFECペイロードIDの対応フォーマットを共有し、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を予約します。
A document that specifies an FEC scheme and reserves a value of FEC Encoding ID MUST define the fields and their packet formats for the FEC Payload ID and specify the information in the FEC Object Transmission Information according to the needs of the encoding scheme. This applies to documents that reserve values of FEC Encoding IDs for both Fully-Specified and Under-Specified FEC schemes.
FECスキームを指定し、FECペイロードIDのフィールドと、そのパケットフォーマットを定義し、符号化方式のニーズに応じてFECオブジェクト伝送情報で情報を指定する必要があり、FEC符号化IDの値を予約文書。これは、両方の完全指定およびアンダー指定FECスキームのFEC符号化IDの値を予約した文書に適用されます。
The specification of the fields and their packet formats for the FEC Payload ID MUST specify the meaning of the fields and their format down to the level of specific bits. The total length of all the fields in the FEC Payload ID MUST have a length that is a multiple of a 4-byte word. This requirement facilitates the alignment of packet fields in protocol instantiations.
FECペイロードIDのフィールドと、そのパケットフォーマットの仕様は、フィールドの意味及び特定のビットのレベルまで、それらの形式を指定しなければなりません。 FECペイロードIDのすべてのフィールドの合計長さは4バイトワードの倍数の長さでなければなりません。この要件は、プロトコルのインスタンス化におけるパケットフィールドの位置合わせを容易にします。
The FEC building block applies to creating and sending encoding symbols for objects that are to be reliably transported using IP multicast or unicast. The FEC building block does not provide higher level session support. Thus, for example, many objects may be transmitted within the same session, in which case a higher level building block may carry a unique Transport Object ID (TOI) for each object in the session to allow the receiver to demultiplex packets within the session based on the TOI within each packet. As another example, a receiver may subscribe to more than one session at a time.
FECビルディングブロックを確実にIPマルチキャストまたはユニキャストを使用して搬送されるオブジェクトのための符号化シンボルを生成し、送信に適用されます。 FECビルディングブロックは、より高いレベルのセッションのサポートを提供していません。したがって、例えば、多くのオブジェクトは、受信機がベースのセッション内のパケットを逆多重化することを可能にするために、より高いレベルのビルディングブロックは、セッション内の各オブジェクトに一意のトランスポートオブジェクトID（TOI）を運ぶことができる場合には、同じセッション内で送信することができます各パケット内のTOIに。別の例として、受信機は、一度に複数のセッションに加入することができます。
In this case a higher level building block may carry a unique Transport Session ID (TSI) for each session to allow the receiver to demultiplex packets based on the TSI within each packet.
この場合、より高いレベルのビルディングブロックは、受信機は、各パケット内のTSIに基づいてパケットを逆多重化することを可能にするセッションごとに一意のトランスポートセッションID（TSI）を搬送することができます。
Other building blocks may supply direct support for carrying out-of-band information directly relevant to the FEC building block to receivers. For example, the length of the object is part of the FEC Object Transmission Information that may in some cases be communicated out-of-band to receivers, and one mechanism for providing this to receivers is within the context of another building block that provides this information.
他のビルディングブロックは、帯域外受信機にFECビルディングブロックに直接関連する情報を搬送するための直接サポートを供給することができます。これを提供する別のビルディングブロックのコンテキスト内で、例えば、オブジェクトの長さがある場合には受信機に帯域外通信することができるFECオブジェクト伝送情報の一部、および受信機にこれを提供するための一つのメカニズムであります情報。
Some protocols may use FEC codes as a mechanism for repairing the loss of packets. Within the context of FEC repair schemes, feedback packets are (optionally) used to request FEC retransmission. The FEC-related information present in feedback packets usually contains an FEC Block ID that defines the block that is being repaired, and the number of Repair Symbols requested. Although this is the most common case, variants are possible in which the receivers provide more specific information about the Repair Symbols requested (e.g., an index range or a list of symbols accepted). It is also possible to include multiple requests in a single feedback packet. This document does not provide any detail about feedback schemes used in combination with FEC nor the format of FEC information in feedback packets. If feedback packets are used in a complete protocol instantiation, these details must be provided in the protocol instantiation specification.
一部のプロトコルは、パケットの損失を修復するためのメカニズムとしてFECコードを使用することができます。 FECリペア方式のコンテキスト内で、フィードバックパケットが（任意に）FEC再送を要求するために使用されます。フィードバックパケットに存在するFEC関連の情報は、通常、修復されているブロック、および要求されたリペアシンボルの数を定義するFECブロックIDを含んでいます。これは最も一般的なケースであるが、変異体は、ここで受信機が要求されたリペアシンボルについてのより具体的な情報を提供可能である（例えば、インデックス範囲または受け入れられたシンボルのリスト）。単一のフィードバックパケット内の複数の要求を含むことも可能です。この文書では、フィードバックFECと組み合わせて使用するスキームもフィードバックパケットでFEC情報のフォーマットについての詳細を提供していません。フィードバックパケットが完全なプロトコルのインスタンス化に使用されている場合は、これらの詳細は、プロトコルのインスタンス仕様で提供されなければなりません。
The FEC building block does not provide any support for congestion control. Any complete protocol MUST provide congestion control that conforms to RFC 2357 [5], and thus this MUST be provided by another building block when the FEC building block is used in a protocol.
FECビルディングブロックは、輻輳制御のためのあらゆるサポートを提供していません。任意完全なプロトコルは、RFC 2357に準拠し、輻輳制御[5]を提供しなければなりません、そしてFECビルディングブロックは、プロトコルで使用されるとき、したがって、これは、他のビルディングブロックによって提供されなければなりません。
A more complete description of the applicability of FEC codes can be found in the companion document [4].
FEC符号の適用のより完全な説明は、コンパニオン文書に見出すことができる[4]。
This section specifies the FEC Encoding ID, the associated FEC Payload ID format, and the specific information in the FEC Object Transmission Information for a number of known Under-Specified FEC schemes. Under-Specified FEC schemes that use the same FEC Payload ID fields, formats, and specific information in the FEC Object Transmission Information (as for one of the FEC Encoding IDs specified in this section) MUST use the corresponding FEC Encoding ID. Other FEC Encoding IDs may be specified for other Under-Specified FEC schemes in companion documents.
このセクションは、FEC符号化ID、関連するFECペイロードIDフォーマット、アンダー指定FECスキーム既知の数のFECオブジェクト伝送情報内の特定情報を特定します。アンダー指定された（このセクションで指定されたFEC符号化IDのいずれかのように）FECオブジェクト伝送情報で同じFECペイロードIDフィールド、フォーマット、および特定の情報を使用するFEC方式対応するFEC符号化IDを使用しなければなりません。他のFEC符号化IDは、コンパニオンドキュメント内の他の下で、指定したFECスキームのために指定することができます。
This subsection reserves the FEC Encoding ID value 128 for the Under-Specified FEC schemes described in [4] that are called Small Block FEC codes, Large Block FEC codes and Expandable FEC codes.
ここでは、小ブロックFECコード、大ブロックFECコードおよび拡張FEC符号と呼ばれている[4]に記載のアンダー指定FECスキームのためにFEC符号化ID値128を留保します。
The FEC Payload ID is composed of a Source Block Number and an Encoding Symbol ID structured as follows:
FECペイロードIDは、次のように構造化ソースブロック番号および符号化シンボルIDで構成されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Source Block Number identifies from which source block of the object the encoding symbol(s) in the payload are generated. These blocks are numbered consecutively from 0 to N-1, where N is the number of source blocks in the object.
ソースブロック番号は、ペイロード内のオブジェクトの符号化シンボル（複数可）のソースブロックが生成されるから識別する。これらのブロックは、N-1、Nは、オブジェクト内のソースブロックの数であり、0から連続的に番号付けされます。
The Encoding Symbol ID identifies which specific encoding symbol(s) generated from the source block are carried in the packet payload. The exact details of the correspondence between Encoding Symbol IDs and the encoding symbol(s) in the packet payload are dependent on the particular encoding algorithm used as identified by the FEC Encoding ID and by the FEC Instance ID, and these details may be proprietary.
符号化シンボルIDは、ソースブロックから生成された特定の符号化シンボル（s）は、パケットペイロードで運ばれる特定します。符号化シンボルIDおよびパケットペイロードにおける符号化シンボル（S）との対応関係の正確な詳細は、FEC符号化IDによって及びFECインスタンスIDによって識別されるように使用される特定の符号化アルゴリズムに依存し、そしてこれらの詳細は、専用であってもよいです。
The FEC Object Transmission Information has the following specific information:
FECオブジェクト伝送情報は、以下の具体的な情報があります。
o The FEC Encoding ID 128.
FEC符号化ID 128 O。
o The FEC Instance ID associated with the FEC Encoding ID 128 to be used.
O FEC符号化ID 128に関連付けられたFECインスタンスIDを使用します。
o The total length of the object in bytes.
バイト内のオブジェクトの全長O。
o The number of source blocks that the object is partitioned into, and the length of each source block in bytes.
Oオブジェクトはに分割されるソースブロックの数、及びバイト内の各ソースブロックの長さ。
To understand how this out-of-band information is communicated, one must look outside the scope of this document. One example may be that the source block lengths may be derived by a fixed algorithm from the object length. Another example may be that all source blocks are the same length and this is what is passed out-of-band to the receiver. A third example could be that the full sized source block length is provided and this is the length used for all but the last source block, which is calculated based on the full source block length and the object length.
この帯域外の情報が伝達される方法を理解するためには、この文書の範囲外で見なければなりません。一例では、ソースブロック長は、物体の長さから一定のアルゴリズムによって導出されてもよいこととすることができます。別の例では、すべてのソースブロックは同じ長さであることであってもよく、これは、受信機への帯域外渡されるものです。第3の例は、フルサイズのソースブロック長が提供され、これは完全なソースブロック長と物体長に基づいて算出される最後のソースブロックが、すべてに使用される長さであることとすることができます。
This subsection reserves the FEC Encoding ID value 129 for the Under-Specified FEC schemes described in [4] that are called Small Block Systematic FEC codes. For Small Block Systematic FEC codes, each source block is of length at most 65536 source symbols.
ここでは、小ブロックシステマティックFEC符号と呼ばれている[4]に記載のアンダー指定FECスキームのためにFEC符号化ID値129を留保します。小ブロックシステマティックFECコードに対して、各ソースブロックは、最も65536個のソースシンボルで長さです。
Although these codes can generally be accommodated by the FEC Encoding ID described in Section 5.1, a specific FEC Encoding ID is defined for Small Block Systematic FEC codes to allow more flexibility and to retain header compactness. The small source block length and small expansion factor that often characterize systematic codes may require the data source to frequently change the source block length. To allow the dynamic variation of the source block length and to communicate it to the receivers with low overhead, the block length is included in the FEC Payload ID.
これらのコードは、一般に、FEC符号化IDに収容することができるが、セクション5.1で説明し、特定のFEC符号化IDは、より多くの柔軟性を可能にするために、ヘッダコンパクトを保持する小ブロックシステマティックFECコードに対して定義されています。多くの場合、組織符号を特徴付ける小さなソースブロック長と小さな膨張係数が頻繁にソースブロック長を変更するために、データソースを必要とするかもしれません。ソースブロック長の動的変化を可能にするために、低オーバーヘッドで受信機にそれを通信するために、ブロック長は、FECペイロードIDに含まれています。
The FEC Payload ID is composed of the Source Block Number, Source Block Length and the Encoding Symbol ID:
FECペイロードIDは、ソースブロック番号、ソースブロック長および符号化シンボルIDで構成されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length | Encoding Symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Source Block Number identifies from which source block of the object the encoding symbol(s) in the payload are generated. These blocks are numbered consecutively from 0 to N-1, where N is the number of source blocks in the object.
ソースブロック番号は、ペイロード内のオブジェクトの符号化シンボル（複数可）のソースブロックが生成されるから識別する。これらのブロックは、N-1、Nは、オブジェクト内のソースブロックの数であり、0から連続的に番号付けされます。
The Source Block Length is the length in units of source symbols of the source block identified by the Source Block Number.
ソースブロック長は、ソースブロック番号によって識別されるソースブロックのソースシンボル単位の長さです。
The Encoding Symbol ID identifies which specific encoding symbol(s) generated from the source block are carried in the packet payload. Each encoding symbol is either an original source symbol or a redundant symbol generated by the encoder. The exact details of the correspondence between Encoding Symbol IDs and the encoding symbol(s) in the packet payload are dependent on the particular encoding algorithm used as identified by the FEC Encoding ID and by the FEC Instance ID, and these details may be proprietary.
符号化シンボルIDは、ソースブロックから生成された特定の符号化シンボル（s）は、パケットペイロードで運ばれる特定します。各符号化シンボルは、元のソースシンボルまたはエンコーダによって生成される冗長シンボルのいずれかです。符号化シンボルIDおよびパケットペイロードにおける符号化シンボル（S）との対応関係の正確な詳細は、FEC符号化IDによって及びFECインスタンスIDによって識別されるように使用される特定の符号化アルゴリズムに依存し、そしてこれらの詳細は、専用であってもよいです。
The FEC Object Transmission Information has the following specific information:
FECオブジェクト伝送情報は、以下の具体的な情報があります。
o The FEC Encoding ID 129.
FEC符号化ID 129、O。
o The FEC Instance ID associated with the FEC Encoding ID 129 to be used.
O FEC符号化ID 129に関連付けられたFECインスタンスIDを使用します。
o The total length of the object in bytes.
バイト内のオブジェクトの全長O。
o The maximum number of encoding symbols that can be generated for any source block. This field is provided for example to allow receivers to preallocate buffer space that is suitable for decoding to recover any source block.
任意のソースブロックに対して生成することができる符号化シンボルの最大数、O。このフィールドは、受信機は、任意のソースブロックを回復するために復号化するのに適しているバッファスペースを事前に割り当てることができるように、例えば提供されます。
o For each source block, the length in bytes of encoding symbols for the source block.
各ソースブロックのO、ソースブロックの符号化シンボルの長さ（バイト単位）。
How this out-of-band information is communicated is outside the scope of this document. As an example the length in bytes of encoding symbols for each source block may be the same for all source blocks. As another example, the encoding symbol length may be the same for all source blocks of a given object and this length is communicated for each object. As a third example, it may be that there is a threshold value I, and for all source blocks consisting of less than I source symbols, the encoding symbol length is one fixed number of bytes, but for all source blocks consisting of I or more source symbols, the encoding symbol length is a different fixed number of bytes.
どのようにこの帯域外の情報が伝達され、この文書の範囲外です。例として、各ソースブロックの符号化シンボルの長さ（バイト単位）は、すべてのソースブロックに対して同じであってもよいです。別の例として、符号化シンボルの長さが指定されたオブジェクトのすべてのソースブロックに対して同じであってもよく、この長さは、各オブジェクトに対して通信されます。第3の例として、それはI、及びIのソースシンボル未満からなる全てのソースブロックの閾値が存在することであってもよい、符号化シンボルの長さはバイトの固定数であるが、すべてのソースIからなるブロック以上ソースシンボルは、符号化シンボルの長さはバイトの異なる固定された数です。
Note that each encoding symbol, i.e., each source symbol and redundant symbol, must be the same length for a given source block, and this implies that each source block length is a multiple of its encoding symbol length. If the original source block length is not a multiple of the encoding symbol length, it is up to the sending application to appropriately pad the original source block to form the source block to be encoded, and to communicate this padding to the receiving application. The form of this padding, if used, and how it is communicated to the receiving application, is outside the scope of this document, and must be handled at the application level.
各符号化シンボル、すなわち、各ソースシンボルおよび冗長シンボルは、所与のソースブロックの同じ長さでなければならないことに注意してください、これは、各ソースブロック長は、その符号化シンボル長の倍数であることを意味します。オリジナルソースブロック長は、符号化シンボル長の倍数でない場合、それは適切パッド元のソースブロックを符号化すべきソースブロックを形成するために、受信アプリケーションにこのパディングを通信するために送信側アプリケーション次第です。この詰め物の形態は、使用される場合、それは受信側アプリケーションに通信される方法は、この文書の範囲外であり、アプリケーション・レベルで処理されなければなりません。
The FEC building block does not provide any support for congestion control. Any complete protocol MUST provide congestion control that conforms to RFC 2357 [5], and thus this MUST be provided by another building block when the FEC building block is used in a protocol.
FECビルディングブロックは、輻輳制御のためのあらゆるサポートを提供していません。任意完全なプロトコルは、RFC 2357に準拠し、輻輳制御[5]を提供しなければなりません、そしてFECビルディングブロックは、プロトコルで使用されるとき、したがって、これは、他のビルディングブロックによって提供されなければなりません。
There are no other specific requirements from other building blocks for the use of this FEC building block. However, any protocol that uses the FEC building block will inevitably use other building blocks for example to provide support for sending higher level session information within data packets containing FEC encoding symbols.
このFECビルディングブロックを使用するための他のビルディングブロックから他の特定の要件はありません。しかし、FECビルディングブロックを使用する任意のプロトコルは必然的に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 to 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 the decoded objects be checked for integrity before delivering objects to an application. For example, an MD5 hash [8] of an object may be appended before transmission, and the MD5 hash is computed and checked after the object is decoded but before it is delivered to an application. Moreover, in order to obtain strong cryptographic integrity protection a digital signature verifiable by the receiver SHOULD be computed on top of such a hash value. It is also RECOMMENDED that a packet authentication protocol such as TESLA [7] 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ビルディングブロックの関心事です。このように復号化されたオブジェクトは、アプリケーションにオブジェクトを配信する前に整合性をチェックすることが推奨されます。例えば、オブジェクトのMD5ハッシュ[8]は、送信の前に付加することができる、およびMD5ハッシュを計算し、チェックオブジェクトがデコードされた後に、それがアプリケーションに配信される前にされています。また、強力な暗号化、完全性保護を得るために受信機によって検証デジタル署名は、ハッシュ値の上に計算されるべきです。また、TESLAとしてパケット認証プロトコル[7]検出し、到着時に破損したパケットを廃棄するために使用することを推奨されています。さらに、リバースパス転送チェックが悪いエージェントが正常にマルチキャストツリーデータパスに破損したパケットを注入する可能性を制限するために受信機に送信者からのパスに沿ってすべてのネットワークルータとスイッチで有効にすることが推奨されます。
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. FEC Encoding IDs and FEC Instance IDs are hierarchical: FEC Encoding IDs scope 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の値は、IANA登録の対象となっています。 FEC符号化IDとFECインスタンスIDは階層的です：FECインスタンスIDのFEC符号化IDのスコープ範囲。アンダー指定FECスキームの範囲FECインスタンスIDの対応するセットに対応する唯一のFEC符号化IDは。
The FEC Encoding ID is a numeric non-negative index. 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 3.1. This specification already assigns the values 128 and 129, as described in Section 5.
FEC符号化IDは、数値以外の負のインデックスです。この文書では、FEC符号化IDの値の範囲は、より詳細に記載されるように0〜127 0〜255の値は、完全に指定されたFECスキームと128から下指定のFECスキームのために予約されている255の値のために予約されていますセクション3.1インチセクション5で説明したように、本明細書では既に、値128及び129を割り当てます。
Each FEC Encoding ID assigned to an Under-Specified FEC scheme scopes an independent range of FEC Instance IDs (i.e., the same value of FEC Instance ID can be reused for different FEC Encoding IDs). An FEC Instance ID is a numeric non-negative index.
アンダー指定FECスキームに割り当てられた各FEC符号化ID（すなわち、FECインスタンスIDの同じ値を異なるFEC符号化IDのために再利用することができる）FECインスタンスIDの独立した範囲をスコープ。 FECインスタンスIDは、数値以外の負のインデックスです。
This document defines a name-space for FEC Encoding IDs named:
この文書では、名前のFEC符号化IDの名前空間を定義しています。
ietf:rmt:fec:encoding
IETF：RMT：FEC：エンコーディング
IANA has established and manages the new registry for the "ietf:rmt:fec:encoding" name-space. 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 "Specification Required" basis as defined in RFC 2434 [6]: An IETF RFC MUST exist and specify the FEC Payload ID fields and formats as well as the FEC Object Transmission Information for the value of "ietf:rmt:fec:encoding" (FEC Encoding ID) being assigned by IANA (see Section 3.1 for more details). Note that the values 128
IANAが確立され、「IETF：RMT：FEC：エンコーディング」のための新しいレジストリを管理している名前空間。内で割り当て可能な値「：RMT：FEC：IETFコード」名前空間は範囲[0、255]の数値のインデックスであり、境界が含まれます。 RFC 2434で定義されるように割当要求が「仕様が必要」に基づいて付与されている[6]：IETF RFCは、IETF」の値に対してFECペイロードIDフィールドとフォーマットならびにFECオブジェクト伝送情報が存在すると指定する必要があります。RMT ：FEC：エンコーディング」（FEC符号化ID）はIANAによって割り当てられている（詳細はセクション3.1を参照）。なお、値128を
and 129 of "ietf:rmt:fec:encoding" are already assigned by this document as described in Section 5.
そして「IETF：RMT：FEC：コードが」129セクション5に記載されているように、既にこの文書によって割り当てられます。
This document also defines a name-space for FEC Instance IDs named:
また、このドキュメントでは、名前のFECインスタンスIDの名前空間を定義しています。
ietf:rmt:fec:encoding:instance
IETF：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 numeric indices. Assignment requests are granted on a "First Come First Served" basis as defined in RFC 2434 [6]. 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：FEC：符号：IETFインスタンス」内に割り当てることができる値のサブ名前空間は、負の数値のインデックスです。 RFC 2434で定義された割り当て要求は、「まず第一に役立っ是非」に基づき付与されている[6]。複数の異なるサブ名前空間、すなわち、同一の値の範囲内割り当てることができる「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.
最新の上記のすべての情報を保持するために要求者の責任です。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETFは、この文書に含まれる仕様の一部またはすべてについて記載知的財産権について通知されています。詳細については、要求された権利のオンラインリストを参照してください。
Brian Adamson contributed to this document by shaping Section 5.2 and providing general feedback. We also wish to thank Vincent Roca, Justin Chapweske and Roger Kermode for their extensive comments.
ブライアン・アダムソンは、5.2節を整形すると一般的なフィードバックを提供することにより、この文書に貢献しました。我々はまた、彼らの多くのコメントのためにヴィンセントロカ、ジャスティンChapweskeとロジャーKermodeに感謝したいです。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents", RFC 3269, April 2002.
[3] Kermode、R.とL. Vicisano、RFC 3269、2002年4月 "信頼できるマルチキャストトランスポート（RMT）ビルディングブロックとプロトコルのインスタンス文書の作者のガイドライン"。
[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] Mankin, A., Romanow, A., Bradner, S. and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[5]マンキン、A.、Romanow、A.、RFC 2357、1998年6月ブラドナー、S.およびV.パクソン、 "信頼できるマルチキャストトランスポート及びアプリケーションプロトコルを評価するためのIETF基準"。
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[6] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[7] Perrig, A., Canetti, R., Song, D. and J. Tygar, "Efficient and Secure Source Authentication for Multicast", Network and Distributed System Security Symposium, NDSS 2001, pp. 35-46, February 2001.
[7] 2001 Perrig、A.、カネッティ、R.、歌、D.とJ. Tygar、 "マルチキャストのための効率的で安全なソース認証"、ネットワークと分散システムセキュリティシンポジウム、NDSS 2001、頁35-46、2月。
[8] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[8]リベスト、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[9] 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.
[9] Whetten、B.、Vicisano、L.、Kermode、R.、ハンドレー、M.、フロイド、S.及びM.ルビー、 "一対多バルクデータ転送のための信頼できるマルチキャストトランスポート・ビルディング・ブロック"、 RFC 3048、2001年1月。
Michael Luby Digital Fountain, Inc. 39141 Civic Center Drive Suite 300 Fremont, CA 94538
マイケル・ルビーデジタル泉社39141シビックセンタードライブスイート300フリーモント、CA 94538
EMail: luby@digitalfountain.com
メールアドレス：luby@digitalfountain.com
Lorenzo Vicisano Cisco Systems, Inc. 170 West Tasman Dr., San Jose, CA, USA, 95134
ロレンツォVicisanoシスコシステムズ、株式会社170西タスマン博士は、サンノゼ、CA、USA、95134
EMail: lorenzo@cisco.com
メールアドレス：lorenzo@cisco.com
Jim Gemmell Microsoft Research 455 Market St. #1690 San Francisco, CA, 94105
ジム・Gemmellマイクロソフトリサーチ455市場セント＃1690サンフランシスコ、CA、94105
EMail: jgemmell@microsoft.com
メールアドレス：jgemmell@microsoft.com
Luigi Rizzo Dip. di Ing. dell'Informazione Universita` di Pisa via Diotisalvi 2, 56126 Pisa, Italy
ルイジ・リゾディップ。のIng。ディオーティソルビ2、56126ピサ、イタリア経由ピサの情報大学
EMail: luigi@iet.unipi.it
メールアドレス：luigi@iet.unipi.it
Mark Handley ICSI Center for Internet Research 1947 Center St. Berkeley CA, USA, 94704
インターネットリサーチ1947センターセントバークレー、CA、USA、94704のためのマーク・ハンドリーICSIセンター
EMail: mjh@icir.org
メールアドレス：mjh@icir.org
Jon Crowcroft Marconi Professor of Communications Systems University of Cambridge Computer Laboratory William Gates Building J J Thomson Avenue Cambridge CB3 0FD
ケンブリッジの通信システム大学のコンピュータ研究所のウィリアム・ゲイツビルJ JトムソンアベニューケンブリッジCB3 0FDのジョン・クロークロフトマルコーニ教授
EMail: Jon.Crowcroft@cl.cam.ac.uk
メールアドレス：Jon.Crowcroft@cl.cam.ac.uk
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。