[要約] RFC 3452は、Forward Error Correction（FEC）の基本的な概念と技術を説明しています。このRFCの目的は、ネットワーク通信におけるエラー訂正の手法を提供し、信頼性と効率性を向上させることです。
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
フォワードエラー補正（FEC）ビルディングブロック
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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の製品であり、RFC 3269 [3]で提供される一般的なガイドラインに従います。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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に従って信頼性の高いマルチキャストトランスポートプロトコルを完全に指定するために必要な定義の一部が含まれています。RFC2357によると、インターネットでの信頼できるマルチキャストプロトコルの使用には、適切な渋滞制御スキームが必要です。
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提案標準として再提出することは、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コードの使用は、IPマルチキャストと信頼性の高い配信のコンテキストで価値があります。FECエンコードシンボルは、レシーバーが異なるエンコードシンボルを受け取った場合でもコンテンツを再構築するためにすべての受信機に役立つ可能性があるためです。さらに、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つのクラスには、データパケット、セッションコントロールパケット、フィードバックパケットの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 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.
パケットのペイロードにエンコードシンボルを識別します。FECペイロードIDのフィールドのタイプと長さ、つまりFECペイロードIDの形式は、FECエンコードIDによって決定されます。各フィールドの完全な仕様は、完全に指定されたFECスキームのFECエンコーディングIDによって一意に決定される必要があり、FECエンコードIDと不十分なFECスキームのFECインスタンスIDの組み合わせによって一意に決定する必要があります。例として、セクション5.1で定義されたFECエンコードID 129を備えた不足しているFECスキームの場合、FECペイロードIDのフィールドは32ビットソースブロック番号に続いて32ビットエンコードシンボルIDが続きます。これらの両方のフィールドのうち、FECインスタンス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エンコードID、FECインスタンスID（不足しているFECスキーム用）、および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スキームまたは同じ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スキームのために保持されます。OFECペイロードIDのフィールドとその形式、および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.
o FECエンコーディングIDの値は、FECペイロードIDのフィールドとその形式、およびFECオブジェクト伝送情報の特定の情報に関連付けられ、関連付けられている必要があります。関連する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スキームは、Tuple（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スキームも、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の値の範囲0-127を、完全に指定されたFECスキームのIDをコードするIDをエンコードする値と、不足しているFECスキームの値に対して範囲128-255を留保します。
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ペイロードIDのフィールドとそのパケット形式を定義し、エンコードスキームのニーズに応じてFECオブジェクト伝送情報の情報を指定する必要があります。これは、完全に指定されたFECスキームと不足している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ビルディングブロックは、より高いレベルのセッションサポートを提供しません。したがって、たとえば、同じセッション内で多くのオブジェクトが送信される場合があります。この場合、セッション内の各オブジェクトに高レベルのビルディングブロックがセッション内のセッション内でパケットをDemultlexパケットに繰り返すことができるようにすることができます。各パケット内の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.
この場合、より高いレベルのビルディングブロックは、各セッションに一意のトランスポートセッションID（TSI）を運ぶことができ、各パケット内のTSIに基づいて受信機がDemultiPlexパケットを使用できるようにします。
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オブジェクトトランスミッション情報の一部であり、場合によっては帯域外にレシーバーに通知される可能性があり、これを受信機に提供するための1つのメカニズムは、これを提供する別のビルディングブロックのコンテキスト内にあります情報。
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.
一部のプロトコルは、Packetの損失を修復するためのメカニズムとして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オブジェクト伝送情報に同じFECペイロードIDフィールド、フォーマット、および特定の情報を使用する不足しているFECスキーム（このセクションで指定されたFECエンコードIDのいずれかについて）は、対応する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.
このサブセクションでは、[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.
ソースブロック番号は、ペイロード内のエンコードシンボルが生成されるオブジェクトのソースブロックを識別します。これらのブロックには、0からn-1まで連続して番号が付けられ、nはオブジェクト内のソースブロックの数です。
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は、ソースブロックから生成された特定のエンコードシンボルがパケットペイロード内で運ばれるかを識別します。エンコードシンボルIDとパケットペイロードのエンコードシンボルとの対応の正確な詳細は、FECエンコードIDおよびFECインスタンスIDによって識別される特定のエンコードアルゴリズムに依存します。
The FEC Object Transmission Information has the following specific information:
FECオブジェクトトランスミッション情報には、次の特定の情報があります。
o The FEC Encoding ID 128.
o FECエンコードID 128。
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.
この帯域外の情報がどのように伝えられているかを理解するには、このドキュメントの範囲の外側を見る必要があります。1つの例は、ソースブロックの長さがオブジェクト長から固定アルゴリズムによって導出される可能性があることです。別の例は、すべてのソースブロックが同じ長さであり、これがレシーバーに帯域外に渡されるものであることです。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.
このサブセクションは、[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.
これらのコードは通常、セクション5.1で説明されているFECエンコードIDに対応できますが、特定の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.
ソースブロック番号は、ペイロード内のエンコードシンボルが生成されるオブジェクトのソースブロックを識別します。これらのブロックには、0からn-1まで連続して番号が付けられ、nはオブジェクト内のソースブロックの数です。
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は、ソースブロックから生成された特定のエンコードシンボルがパケットペイロード内で運ばれるかを識別します。各エンコードシンボルは、元のソースシンボルまたはエンコーダーによって生成される冗長シンボルのいずれかです。エンコードシンボルIDとパケットペイロードのエンコードシンボルとの対応の正確な詳細は、FECエンコードIDおよびFECインスタンスIDによって識別される特定のエンコードアルゴリズムに依存します。
The FEC Object Transmission Information has the following specific information:
FECオブジェクトトランスミッション情報には、次の特定の情報があります。
o The FEC Encoding ID 129.
o FECエンコードID 129。
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ソースシンボルよりも少ないすべてのソースブロックについて、エンコーディングシンボルの長さは1つの固定バイト数ですが、すべてのソースブロックでは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.
データ配信は、攻撃者によるサービス拒否攻撃の対象となる可能性があります。攻撃者は、受信者によって合法として受け入れられている破損したパケットを送信します。これは、マルチキャストツリーのルートに近いセッションに破損したパケットが注入される可能性があるため、マルチキャスト配信の懸念事項です。この場合、破損したパケットは多くのレシーバーに到着します。これは、エンコードデータを含む1つの破損したパケットを使用することで、完全に破損して使用できないオブジェクトのデコードが生じる可能性があるため、特に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〜255です。0〜127の値は、完全に指定されたFECスキームに予約されており、128から255の値は、より詳細に説明されているように、不足しているFECスキームに予約されています。セクション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
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 and 129 of "ietf:rmt:fec:encoding" are already assigned by this document as described in Section 5.
IANAは、「IETF：RMT：FEC：エンコード」という名前の名前空間の新しいレジストリを確立および管理しています。「IETF：RMT：FEC：エンコード」という名前内で割り当てることができる値は、範囲[0、255]の数値インデックス、境界が含まれます。割り当て要求は、RFC 2434 [6]で定義されている「仕様が必要」に基づいて付与されます。IETFRFCが存在し、FECペイロードIDフィールドとフォーマット、および「IETF：RMTの値のFECオブジェクト伝送情報を指定する必要があります。：FEC：Encoding "（FECエンコードID）IANAによって割り当てられています（詳細についてはセクション3.1を参照）。「IETF：RMT：FEC：エンコード」の値128と129は、セクション5で説明されているように、このドキュメントによって既に割り当てられていることに注意してください。
This document also defines a name-space for FEC Instance IDs named:
このドキュメントは、次の名前のFECインスタンスIDの名前空間も定義します。
ietf:rmt:fec:encoding:instance
The "ietf:rmt:fec:encoding:instance" name-space is a sub-name-space associated with the "ietf:rmt:fec:encoding" name-space. Each value of "ietf:rmt:fec:encoding" assigned in the range [128, 255] has a separate "ietf:rmt:fec:encoding:instance" sub-name-space that it scopes. Values of "ietf:rmt:fec:encoding" in the range [0, 127] do not scope a "ietf:rmt:fec:encoding:instance" sub-name-space.
「IETF：RMT：FEC：Encoding：Instance "NAME-SPACEは、「IETF：RMT：FEC：エンコード」名前空間に関連付けられたサブネームスペースです。範囲[128、255]で割り当てられた「IETF：RMT：FEC：FEC：Encoding」の各値には、スコープする個別の「IETF：RMT：FEC：ENCODING：INSTANCE」サブネームスペースがあります。「IETF：RMT：FEC：エンコード」の範囲[0、127]の値は、「IETF：RMT：FEC：Encoding：Instance」サブ名空間をスコープしません。
The values that can be assigned within each "ietf:rmt:fec:encoding:instance" sub-name-space are non-negative 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".
各「IETF：RMT：FEC：Encoding：Instance」サブネームスペース内に割り当てることができる値は、非陰性数値インデックスです。割り当てリクエストは、RFC 2434 [6]で定義されているように、「First Come First Servent」ベースで付与されます。「IETF：RMT：FEC：Encoding：Instance」の同じ値は、複数の個別のサブ名スペース、つまり「IETF：RMT：FEC：エンコーディング：インスタンス」の同じ値に割り当てることができます。複数の値に使用できます。「IETF：RMT：FEC：エンコード」の。
Requestors of "ietf:rmt:fec:encoding:instance" assignments MUST provide the following information:
「IETF：RMT：FEC：Encoding：Instance」の要求者は、次の情報を提供する必要があります。
o The value of "ietf:rmt:fec:encoding" that scopes the "ietf:rmt:fec:encoding:instance" sub-name-space. This must be in the range [128, 255].
o 「IETF：RMT：FEC：エンコード」の値は、「IETF：RMT：FEC：Encoding：Instance」サブネームスペースをスコープします。これは範囲内でなければなりません[128、255]。
o Point of contact information
o 連絡先情報
o A pointer to publicly accessible documentation describing the Under-Specified FEC scheme, associated with the value of "ietf:rmt:fec:encoding:instance" assigned, and a way to obtain it (e.g., a pointer to a publicly available reference-implementation or the name and contacts of a company that sells it, either separately or embedded in a product).
o 「IETF：RMT：FEC：ENCODING：INSTANCE」の値に関連付けられた、不足しているFECスキームを説明する公開されているドキュメントへのポインタ。または、それを販売する会社の名前と連絡先、個別に、または製品に埋め込まれています）。
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を形成し、一般的なフィードバックを提供することにより、この文書に貢献しました。また、Vincent Roca、Justin Chapweske、Roger Kermodeに、広範なコメントをしてくれたことにも感謝します。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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、「信頼できるマルチキャストトランスポート（RMT）ビルディングブロックとプロトコルインスタンス化ドキュメントの著者ガイドライン」、RFC 3269、2002年4月。
[4] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002.
[4] Luby、M.、Vicisano、L.、Gemmell、J.、Rizzo、L.、Handley、M。、およびJ. Crowcroft、「信頼できるマルチキャストでのフォワードエラー補正（FEC）の使用」、RFC 3453、2002年12月。
[5] Mankin, A., Romanow, A., Bradner, S. and V. Paxson, "IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols", RFC 2357, June 1998.
[5] Mankin、A.、Romanow、A.、Bradner、S。and V. Paxson、「信頼できるマルチキャストトランスポートおよびアプリケーションプロトコルを評価するためのIETF基準」、RFC 2357、1998年6月。
[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] Perrig、A.、Canetti、R.、Song、D。and J. Tygar、「マルチキャストの効率的かつ安全なソース認証」、ネットワークおよび分散システムセキュリティシンポジウム、NDSS 2001、pp。35-46、2001年2月。
[8] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[8] Rivest、R。、「The Md5 Message-Digest Algorithm」、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.、Handley、M.、Floyd、S。、およびM. Luby、「1対Many Bulk-Data転送用の信頼できるマルチキャスト輸送ビルディングブロック」、RFC 3048、2001年1月。
Michael Luby Digital Fountain, Inc. 39141 Civic Center Drive Suite 300 Fremont, CA 94538
Michael Luby Digital Fountain、Inc。39141 Civic Center Drive Suite 300 Fremont、CA 94538
EMail: luby@digitalfountain.com
Lorenzo Vicisano Cisco Systems, Inc. 170 West Tasman Dr., San Jose, CA, USA, 95134
Lorenzo Vicisano Cisco Systems、Inc。170 West Tasman Dr.、San Jose、CA、USA、95134
EMail: lorenzo@cisco.com
Jim Gemmell Microsoft Research 455 Market St. #1690 San Francisco, CA, 94105
Jim Gemmell Microsoft Research 455 Market St.＃1690 San Francisco、CA、94105
EMail: jgemmell@microsoft.com
Luigi Rizzo Dip. di Ing. dell'Informazione Universita` di Pisa via Diotisalvi 2, 56126 Pisa, Italy
Luigi Rizzo Dip。ディーイング。Dell'informazione Universita` Diotisalvi 2、56126 Pisa、イタリア経由
EMail: luigi@iet.unipi.it
Mark Handley ICSI Center for Internet Research 1947 Center St. Berkeley CA, USA, 94704
マークハンドリーICSIインターネット研究センター1947センターセントバークレーCA、米国、94704
EMail: 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
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。