RFC3452 日本語訳
3452 Forward Error Correction (FEC) Building Block. M. Luby, L.Vicisano, J. Gemmell, L. Rizzo, M. Handley, J. Crowcroft. December 2002. (Format: TXT=38368 bytes) (Obsoleted by RFC5052) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
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
Lubyがコメントのために要求するワーキンググループM.をネットワークでつないでください: 3452年のデジタル噴水カテゴリ: 実験的なL.のJ.GemmellマイクロソフトL.リゾーVicisanoコクチマス大学 ピサM.ハンドレーICIR J.クロウクロフトケンブリッジ大学 2002年12月
Forward Error Correction (FEC) Building Block
前進型誤信号訂正(FEC)ブロック
Status of this Memo
この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.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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".
一般に、このドキュメントはデータ伝送のために信頼性を効率的に提供する、そして/または、増大させるのにForward Error Correction(FEC)コードを使用する方法を説明します。 このドキュメントの焦点はIPマルチキャストを使用する多くへの1つの信頼できるデータ伝送へのFECコードの適用です。 このドキュメントは、どんな情報が特定のFECコードを特定するのに必要であるか、そして、どんな情報が、FECコードを使用するためにバンドの外でコミュニケートする必要があるか、そして、どんな情報がそれらが運ぶコード化シンボルを特定するのにデータ・パケットで必要であるかを説明します。 また、インターネットAssigned民数記Authority(IANA)にFECコードを指定して、それらを登録するための手順は説明されます。 このドキュメントは題をつけられた仲間ドキュメント、「信頼できるマルチキャストにおける前進型誤信号訂正(FEC)の使用」について読んで、用語を使用することであるべきです。
Luby, et. al. Experimental [Page 1] RFC 3452 FEC Building Block December 2002
et Luby、アル。 [1ページ]実験的なRFC3452FECブロック2002年12月
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . 2 2。 原理。 . . . . . . . . . . . . . . . . . . . . . . . . 3 3. 機能性。 . . . . . . . . . . . . . . . . . . . . . . 3 3.1 IDとFEC Instance IDをコード化するFEC。 . . . . . . . . . . 5 3.2 FEC Payload IDとFECオブジェクトトランスミッション情報. 6 4。 適用性証明. . . . . . . . . . . . . . . . . 7 5。 .85.1わずかなブロックのパケットのヘッダー分野、大量株、および拡張可能なFECコード。 . . . 8 5.2 小さいブロック系統的なFECは.9 6をコード化します。 他のブロックからの要件。 . . . . . . . . . 11 7. セキュリティ問題。 . . . . . . . . . . . . . . . . . 11 8. IANA問題。 . . . . . . . . . . . . . . . . . . . 12 8.1 明白なIANA課題ガイドライン。 . . . . . . . . . . 12 9. 知的所有権公開. . . . . . . . . . . . . 13 10。 承認。 . . . . . . . . . . . . . . . . . . . . . 14 11. 参照. . . . . . . . . . . . . . . . . . . . . . . . 14 12。 作者のアドレス. . . . . . . . . . . . . . . . . . . . 15 13。 完全な著作権宣言文. . . . . . . . . . . . . . . . . 16
1. Introduction
1. 序論
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マルチキャストを使用することで内容の信頼できる配信のサポートを提供するのにForward Error Correction(FEC)コードを使用する方法を説明します。 このドキュメントは、仲間ドキュメント[4]の用語を読まれて、使用するべきです。(それは、信頼できるIPマルチキャスト輸送の文脈の中でFECコードの使用について説明して、いくつかの一般的に使用されたFECコードに序論を提供します)。
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].
このドキュメントはRFC3048[9]で定義されるようにブロックについて説明します。 このドキュメントは、IETF RMT WGの製品であり、RFC3269[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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは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.
このメモはRFC2357によると、Reliable Multicast Transportプロトコルを完全に指定するのに必要な定義の一部を含んでいます。 RFC2357に従って、インターネットでのどんな信頼できるマルチキャストプロトコルの使用も適切な輻輳制御体系を必要とします。
Luby, et. al. Experimental [Page 2] RFC 3452 FEC Building Block December 2002
et Luby、アル。 [2ページ]実験的なRFC3452FECブロック2002年12月
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.
そのような体系が利用可能であるか、または既存の体系が適切であると立証されるのを待っている間、Reliable Multicast Transportワーキンググループ(RMT)はCommentsのために「実験的な」カテゴリでこのRequestを発行します。
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がこの仕様を再提出する意図です。
2. Rationale
2. 原理
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ブロックの目標は、直接FECコードにすべての信頼できる内容物配送IPマルチキャストプロトコルに共通の状態で関連する機能性について説明して、特定のプロトコルに特定のどんな追加機能性も省くことです。 本書では説明された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]は、信頼できる内容物配送にFECコードを使用する利益に関する詳報のためにIPマルチキャストを使用することで参照されるべきです。 また、FECコードもユニキャストの文脈で役に立ちます、そして、その結果、このドキュメントの範囲と適用性はIPマルチキャストに限られていません。
3. Functionality
3. 機能性
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情報を含んでいます。 いくつかのプロトコルがセッション制御かフィードバックパケットを使用しないかもしれないことに注意してください。
Luby, et. al. Experimental [Page 3] RFC 3452 FEC Building Block December 2002
et Luby、アル。 [3ページ]実験的なRFC3452FECブロック2002年12月
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) IDをコード化するFEC
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 Encoding IDの値は、特定のオブジェクトに関連するデータのすべての伝達に同じでなければなりませんが、異なったオブジェクトに関するデータの異なった送信の向こう側に異なるかもしれません、同じセットについてマルチキャストチャンネル、そして/または、ただ一つの上側の層のセッションを使用するのに伝えられても。 FEC Encoding IDはIANA登録を受けることがあります。
2) FEC Instance ID
2) FEC Instance 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.
Underによって指定されたFEC体系に使用されるFECエンコーダの、より特定の識別を提供します。 この値はFullyによって指定されたFEC体系に使用されません。 (Underによって指定されてFullyによって指定されたFEC体系の定義に関してセクション3.1を見てください。) FEC Instance IDは、FEC Encoding IDによって見られて、IANA登録を受けることがあります。
3) FEC Payload ID
3) FEC Payload 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 Payload IDの分野のタイプと長さ(すなわち、FEC Payload IDの形式)はFEC Encoding IDのそばで決定しています。 それぞれの分野の完全な仕様をFEC Encoding IDがFullyによって指定されたFEC体系のために唯一決定しなければならなくて、Underによって指定されたFEC体系のためにFEC Encoding IDとFEC Instance IDの組み合わせで唯一決定しなければなりません。 Underに指定にされるののためにFECが計画する例として
Luby, et. al. Experimental [Page 4] RFC 3452 FEC Building Block December 2002
et Luby、アル。 [4ページ]実験的なRFC3452FECブロック2002年12月
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 Encoding ID129がセクション5.1で定義されて、FEC Payload IDの分野はこれらの分野の両方の完全な仕様がFEC Instance IDによる32ビットのEncoding Symbol IDによっていうことになられた32ビットのSource Block Numberです。
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デコーダによって必要とされた特定のオブジェクトのコード化の情報です。 例として、FEC Encoding ID129がセクション5.1で定義されているUnderによって指定された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 Encoding FEC Instance ID(ID)(Underによって指定されたFEC体系のための)、およびFEC Object Transmission情報を受信機に送ることができます。 どのような場合でも、このドキュメントの範囲の外にこれを受信機に伝えるための手段があります。 データ・パケットヘッダーフィールドにFEC Payload IDを含まなければなりません、シンボルがパケットに含んだコード化の記述を提供するとき。
3.1. FEC Encoding ID and FEC Instance ID
3.1. IDとFEC Instance IDをコード化するFEC
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 Encoding IDはクラスについて同じFEC Payload IDを共有する体系をコード化するとフォーマットされる特定のFEC体系ORを特定する数値インデックスです。
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体系はFullyによって指定されたFEC体系です、独立している作成者がIETF RFCである仕様からエンコーダとデコーダの両方を実装することができる方法で。 FEC Encoding IDは唯一Fullyによって指定されたFEC体系を特定します。 この仕様の仲間ドキュメントは、Fullyによって指定されたFEC体系を指定して、FEC Encoding ID値にそれらを関連づけるかもしれません。
These documents MUST also specify a format for the FEC Payload ID and specify the information in the FEC Object Transmission Information.
これらのドキュメントは、また、FEC Payload IDに形式を指定して、FEC Object Transmission情報で情報を指定しなければなりません。
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:
FEC体系がFullyによって指定されたFEC体系でないかもしれない可能、コード化体系を所有している、アルゴリズムか仕様を明らかにすることを望んでいないパーティーが仕様が絶対に利用可能でないか、または存在するので。 私たちはUnderによって指定されたFEC体系のような体系をコード化するFECについて言及します。 Underによって指定されたFEC体系のための以下の船倉:
Luby, et. al. Experimental [Page 5] RFC 3452 FEC Building Block December 2002
et Luby、アル。 [5ページ]実験的なRFC3452FECブロック2002年12月
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.
o Underによって指定されたFEC体系のために分野とそれらのFEC Payload IDの形式とFEC Object Transmission情報の特殊情報を定義しなければなりません。
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 Payload IDの形式とFEC Object Transmission情報の特殊情報にFEC Encoding IDへの値を予約されて、関連づけなければなりません。 関連FEC Payload IDに同じ分野と形式があるなら、既に予約されたFEC Encoding ID価値を再利用しなければなりません、そして、FEC Object Transmission情報は新しいUnderによって指定されたFEC体系に必要であるものに同じ情報を持っています。
o A value for the FEC Instance ID MUST be reserved.
o FEC Instance 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.
Underによって指定されたFEC体系はtuple(FEC Encoding FEC Instance ID(ID))によって完全に特定されます。 tupleは少なくとも1つの実装を持っているただ一つの体系を特定しなければなりません。 このtupleを所有しているパーティーはどうtupleと例えば、公的に利用可能な参照実装への指針か名前と別々にそれを販売する会社の接触によって特定されるか、または別の製品に埋め込まれたUnderによって指定された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 Encoding IDを共有しますが、異なったFEC Instance IDを持っている異なったUnderによって指定されたFEC体系が、また、FEC Payload IDの同じ分野と対応する形式を共有して、FEC Object Transmission情報の同じ情報を指定します。
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.
この仕様はFullyによって指定されたFEC体系のためのFEC Encoding IDの値とUnderによって指定されたFEC体系の値のための範囲128-255への範囲0-127を予約します。
3.2. FEC Payload ID and FEC Object Transmission Information
3.2. FEC Payload IDとFECオブジェクトトランスミッション情報
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 Encoding IDの値を予約するドキュメントは、分野とそれらのパケット・フォーマットをFEC Payload IDと定義して、コード化体系の必要性に従って、FEC Object Transmission情報の情報を指定しなければなりません。 これはFullyによって指定されてUnderによって指定の両方にされたFEC体系のためにFEC Encoding 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
FEC Payload IDへの分野とそれらのパケット・フォーマットの仕様は分野とそれらの形式の意味を特定のビットのレベルまで指定しなければなりません。 すべての全長
Luby, et. al. Experimental [Page 6] RFC 3452 FEC Building Block December 2002
et Luby、アル。 [6ページ]実験的なRFC3452FECブロック2002年12月
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 Payload IDの分野には、4バイトの単語の倍数である長さがなければなりません。 この要件はプロトコル具体化における、パケット分野の整列を容易にします。
4. Applicability Statement
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ブロックは、より高い平らなセッションサポートを提供しません。 このようにして、例えば、多くのオブジェクトが同じセッション中に伝えられるかもしれません、その場合、セッションにおける各オブジェクトが各パケットの中でTOIに基づいたセッション中に「反-マルチプレックス」パケットに受信機を許容するように、より高い平らなブロックはユニークなTransport Object ID(TOI)を運ぶかもしれません。 別の例として、受信機は一度に、1つ以上のセッションに申し込まれるかもしれません。
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に基づいた「反-マルチプレックス」パケットに受信機を許容するように、より高い平らなブロックはユニークなTransport Session 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 Object Transmission情報の一部です、そして、この情報を提供する別のブロックの文脈の中にこれを受信機に供給するための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.
いくつかのプロトコルが、パケットの損失を修理するのにメカニズムとしてFECコードを使用するかもしれません。 FEC修理体系の文脈の中では、フィードバックパケットは、FEC retransmissionを要求するのに(任意に)使用されます。 通常、フィードバックパケットの現在のFEC関連の情報は修理されているブロック、および要求されたRepair Symbolsの数を定義するFEC Block IDを含んでいます。 これは最も一般的なそうですが、異形は受信機が要求されたRepair Symbolsの、より特定の情報を提供するもので可能です(例えば、インデックス範囲かシンボルのリストが受け入れました)。 また、単一のフィードバックパケットでの複数の要求を含んでいるのも可能です。 このドキュメントは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ブロックは輻輳制御の少しのサポートも提供しません。 どんな完全なプロトコルもRFC2357[5]に従う輻輳制御を提供しなければなりません、そして、FECブロックがプロトコルに使用されるとき、その結果、別のブロックはこれを提供しなければなりません。
Luby, et. al. Experimental [Page 7] RFC 3452 FEC Building Block December 2002
et Luby、アル。 [7ページ]実験的なRFC3452FECブロック2002年12月
A more complete description of the applicability of FEC codes can be found in the companion document [4].
仲間ドキュメント[4]でFECコードの適用性の、より完全な記述を見つけることができます。
5. Packet Header Fields
5. パケットのヘッダー分野
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 FEC Encoding Payload ID(ID)形式、および多くの知られているUnderによって指定されたFEC体系のためのFEC Object Transmission情報の特殊情報を指定します。 FEC Object Transmission情報(このセクションで指定されたFEC Encoding IDの1つのような)の同じFEC有効搭載量ID分野、形式、および特殊情報を使用する下の指定されたFEC体系は対応するFEC Encoding IDを使用しなければなりません。 他のFEC Encoding IDは仲間ドキュメントの他のUnderの指定されたFEC体系に指定されるかもしれません。
5.1. Small Block, Large Block and Expandable FEC Codes
5.1. わずかなブロック、大量株、および拡張可能な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.
この小区分はSmall Block FECコード、Large Block FECコード、およびExpandable FECコードと呼ばれる[4]で説明されたUnderによって指定されたFEC体系のためにFEC Encoding ID価値128を予約します。
The FEC Payload ID is composed of a Source Block Number and an Encoding Symbol ID structured as follows:
FEC Payload IDは以下の通り構造化されたSource Block NumberとEncoding Symbol 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソース街区番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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.
Source Block Numberは、ペイロードのコード化シンボルがオブジェクトのどのソースブロックから発生しているかを特定します。 これらのブロックは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.
Encoding Symbol IDは、ソースブロックから生成されたどの特定のコード化シンボルがパケットペイロードで運ばれるかを特定します。 Encoding Symbol IDの間の通信の正確な詳細とパケットペイロードのコード化シンボルはFEC Encoding IDとFEC Instance IDによって特定されるように使用される特定のコード化アルゴリズムに依存しています、そして、これらの詳細は独占であるかもしれません。
The FEC Object Transmission Information has the following specific information:
FEC Object Transmission情報には、以下の特殊情報があります:
o The FEC Encoding ID 128.
o ID128をコード化するFEC。
Luby, et. al. Experimental [Page 8] RFC 3452 FEC Building Block December 2002
et Luby、アル。 [8ページ]実験的なRFC3452FECブロック2002年12月
o The FEC Instance ID associated with the FEC Encoding ID 128 to be
used.
o FEC Instance IDは、使用されるためにFEC Encoding ID128と交際しました。
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番目の例は完全な大きさで分けられたソースブロック長を提供して、これが計算される最後のソースブロック以外の完全なソースブロック長とオブジェクトの長さに基づくすべてに使用される長さであるということであるかもしれません。
5.2. Small Block Systematic FEC Codes
5.2. 小さいブロック系統的なFECコード
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.
この小区分はSmall Block Systematic FECコードと呼ばれる[4]で説明されたUnderによって指定されたFEC体系のためにFEC Encoding ID価値129を予約します。 Small Block Systematic 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 Encoding IDは一般にこれらのコードに対応できますが、特定のFEC Encoding IDは、Small Block Systematic FECコードが、より多くの柔軟性を許容して、ヘッダーコンパクト性を保有するために定義されます。 しばしばシステマティック・コードを特徴付けるわずかなソースブロック長の、そして、小さい膨張係数は、データ送信端末が頻繁にソースブロック長を変えるのを必要とするかもしれません。 ソースブロック長のダイナミックな変化を許容して、それを受信機に低いオーバーヘッドと伝えるために、ブロック長はFEC Payload IDに含まれています。
The FEC Payload ID is composed of the Source Block Number, Source Block Length and the Encoding Symbol ID:
FEC Payload IDはSource Block Number、Source Block Length、およびEncoding Symbol 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソース街区番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースブロック長| Symbol IDをコード化します。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Luby, et. al. Experimental [Page 9] RFC 3452 FEC Building Block December 2002
et Luby、アル。 [9ページ]実験的なRFC3452FECブロック2002年12月
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.
Source Block Numberは、ペイロードのコード化シンボルがオブジェクトのどのソースブロックから発生しているかを特定します。 これらのブロックは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.
Source Block Lengthは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.
Encoding Symbol IDは、ソースブロックから生成されたどの特定のコード化シンボルがパケットペイロードで運ばれるかを特定します。 シンボルをコード化するのは、それぞれ、エンコーダによって生成された一次資料シンボルか余分なシンボルのどちらかです。 Encoding Symbol IDの間の通信の正確な詳細とパケットペイロードのコード化シンボルはFEC Encoding IDとFEC Instance IDによって特定されるように使用される特定のコード化アルゴリズムに依存しています、そして、これらの詳細は独占であるかもしれません。
The FEC Object Transmission Information has the following specific information:
FEC Object Transmission情報には、以下の特殊情報があります:
o The FEC Encoding ID 129.
o ID129をコード化するFEC。
o The FEC Instance ID associated with the FEC Encoding ID 129 to be
used.
o FEC Instance IDは、使用されるためにFEC Encoding ID129と交際しました。
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 どんなソースブロックにも生成することができるコード化シンボルの最大数。 例えば解読するのに適当なpreallocateバッファ領域への受信機がどんなソースブロックも回収するのを許容するためにこの野原を供給します。
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から成るすべてのソースブロックか、より多くのソースシンボルのために、コード化しているシンボルの長さはバイトの異なった定数です。
Luby, et. al. Experimental [Page 10] RFC 3452 FEC Building Block December 2002
et Luby、アル。 [10ページ]実験的なRFC3452FECブロック2002年12月
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.
それぞれのコード化シンボル(すなわちそれぞれのソースシンボルと余分なシンボル)が与えられたソースブロック同じ長さであるに違いないことに注意してください。そうすれば、これは、それぞれのソースブロック長がシンボルの長さをコード化する倍数であることを含意します。 一次資料ブロック長がコード化しているシンボルの長さの倍数でないなら、この詰め物をコード化されて、伝えるソースブロックを受信アプリケーションに形成するために適切に一次資料ブロックを水増しするのは送付アプリケーションまで達しています。 この詰め物のフォーム、使用されるならそして、どうそれを受信アプリケーションに伝えられて、このドキュメントの範囲の外にあって、アプリケーションレベルで扱わなければならないか。
6. Requirements from other building blocks
6. 他のブロックからの要件
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ブロックは輻輳制御の少しのサポートも提供しません。 どんな完全なプロトコルもRFC2357[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を含んでいて、データ・パケットの中で、より高い平らなセッション情報を送るサポートを提供するのに必然的に他のブロックを使用するでしょう。
7. Security Considerations
7. セキュリティ問題
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
データ配送は攻撃者による受信機で正統であるとして認められる崩壊したパケットを送るサービス不能攻撃を受けることがある場合があります。 これが崩壊したパケットがマルチキャスト木の根の近くでのセッションに注がれるかもしれないので特にマルチキャスト配送に関する心配である、その場合、崩壊したパケットは多くの受信機に到着するでしょう。 これは、データを暗号化を含む1つの崩壊したパケットさえの使用が完全に崩壊して使用不可能なオブジェクトの解読をもたらすかもしれないので、特にFECブロックに関する心配です。 その結果、オブジェクトをアプリケーションに提供する前に解読されたオブジェクトが保全がないかどうかチェックされるのは、RECOMMENDEDです。 例えば、トランスミッションの前にオブジェクトのMD5ハッシュ[8]を追加するかもしれなくて、オブジェクトが解読された後にもかかわらず、それがアプリケーションに提供される前を除いて、MD5ハッシュは、計算されて、チェックされます。 そのうえ、受信機SHOULDが証明可能な強い暗号の保全保護aデジタル署名を得るには、そのようなハッシュ値の上で計算されてください。 また、テスラ[7]などのパケット認証プロトコルが到着のときに崩壊したパケットを検出して、捨てるのに使用されるのは、RECOMMENDEDです。 その上、Reverse Path Forwardingチェックがすべてのネットワークルータとスイッチで可能にされるのは、RECOMMENDEDです。
Luby, et. al. Experimental [Page 11] RFC 3452 FEC Building Block December 2002
et Luby、アル。 [11ページ]実験的なRFC3452FECブロック2002年12月
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.
送付者から悪いエージェントが首尾よくマルチキャスト木のデータ経路に崩壊したパケットを注ぐ可能性を制限する受信機までの経路に沿って。
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情報を得るかもしれないということであり、セッション記述が鍛造されるか、または崩壊すると、受信機は、容認されたパケットから内容を解読するのに正しいプロトコルを使用しないでしょう。 対策が受信機が不正確なセッション記述を受け入れるのを防ぐために実施されるのは、これらの問題を避けるためには、RECOMMENDEDです、例えば、受信機が認可された送付者から正統のセッション記述を受け入れるだけであるのを保証するのにソース認証を使用することによって。
8. IANA Considerations
8. IANA問題
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 Encoding IDとFEC Instance IDの値はIANA登録を受けることがあります。 FEC Encoding IDとFEC Instance IDは階層的です: FEC Instance IDのFEC Encoding ID範囲の範囲。 Underによって指定されたFECに対応するFEC Encoding IDだけが対応が設定するFEC Instance 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 Encoding IDは数値非負のインデックスです。 本書では、FEC Encoding IDのための値の範囲は、0〜255です。 0〜127までの値はFullyによって指定されたFEC体系のために予約されます、そして、128〜255までのValuesはUnderによって指定された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.
Underによって指定されたFEC体系に割り当てられたそれぞれのFEC Encoding IDは独立している範囲のFEC Instance IDを見ます(異なったFEC Encoding IDのためにすなわち、FEC Instance IDの同じ値を再利用できます)。 FEC Instance IDは数値非負のインデックスです。
8.1. Explicit IANA Assignment Guidelines
8.1. 明白なIANA課題ガイドライン
This document defines a name-space for FEC Encoding IDs named:
このドキュメントは指定されたFEC Encoding 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: 」 名前空間をコード化します。 それを割り当てることができる値、「ietf:rmt:fec: 」 名前空間をコード化するのは、境界を含んでいる範囲[0、255]の数値インデックスです。 課題要求はRFC2434[6]で定義されるように「仕様が必要である」というベースで承諾されます: IANAによって割り当てられながら、IETF RFC MUSTは存在していて、「ietf:rmt:fec: コード化(FEC Encoding ID)」の値のためのFEC Object Transmission情報と同様にFEC有効搭載量ID分野と形式を指定します(その他の詳細に関してセクション3.1を見てください)。 それに注意してください、値128
Luby, et. al. Experimental [Page 12] RFC 3452 FEC Building Block December 2002
et Luby、アル。 [12ページ]実験的なRFC3452FECブロック2002年12月
and 129 of "ietf:rmt:fec:encoding" are already assigned by this document as described in Section 5.
129、「ietf:rmt:fec: コード化」はセクション5で説明されるようにこのドキュメントによって既に割り当てられます。
This document also defines a name-space for FEC Instance IDs named:
また、このドキュメントは指定されたFEC Instance 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:コード化:インスタンス」名前空間が交際したサブ名前空間である、「ietf:rmt:fec: 」 名前空間をコード化します。 範囲[128、255]で割り当てられた「ietf:rmt:fec: コード化」の各値には、それが見る別々の「ietf:rmt:fec:コード化:インスタンス」サブ名前空間があります。 範囲[0、127]の「ietf:rmt:fec: コード化」の値は「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".
それぞれの「ietf:rmt:fec:コード化:インスタンス」サブ名前空間の中で割り当てることができる値は非否定的な数値インデックスリストです。 課題要求はRFC2434[6]で定義されるように「先着順」ベースで承諾されます。 複数の異なったサブ名前空間の中で「ietf:rmt:fec:コード化:インスタンス」の同じ値を割り当てることができます、すなわち、「ietf:rmt:fec: コード化」の複数の値に「ietf:rmt:fec:コード化:インスタンス」の同じ値を使用できます。
Requestors of "ietf:rmt:fec:encoding:instance" assignments MUST provide the following information:
「ietf:rmt:fec:コード化:インスタンス」課題の要請者は以下の情報を提供しなければなりません:
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: コード化」の値。 これは範囲[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:コード化:インスタンス」の値に関連づけられたUnderによって指定されたFEC体系について説明する公的に理解できるドキュメンテーションへの指針とそれ(例えば、別々にそれを販売したか、または製品を中に埋め込んだ会社の公的に利用可能な参照実装か名前と接触への指針)を得る方法。
It is the responsibility of the requestor to keep all the above information up to date.
すべての上記の情報が時代について行かせるのは、要請者の責任です。
9. Intellectual Property Disclosure
9. 知的所有権公開
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は本書では含まれた仕様いくつかかすべてに関して要求された知的所有権について通知されました。 詳しい情報に関しては、要求された権利のオンラインリストに相談してください。
Luby, et. al. Experimental [Page 13] RFC 3452 FEC Building Block December 2002
et Luby、アル。 [13ページ]実験的なRFC3452FECブロック2002年12月
10. Acknowledgments
10. 承認
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、およびロジャー・カーモードに感謝申し上げます。
11. References
11. 参照
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[1] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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] カーモード、R.、およびL.Vicisanoは「ドキュメントをBlocksとプロトコルInstantiationに造って、Reliable Multicast Transport(RMT)のためにGuidelinesを書きます」、RFC3269、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.とリゾーとL.とハンドレーとM.とJ.クロウクロフト、「信頼できるマルチキャストにおける前進型誤信号訂正(FEC)の使用」、RFC3453、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.、ブラドナー、S.、および「信頼できるマルチキャスト輸送とアプリケーション・プロトコルを評価するIETF評価基準」、RFC2357(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問題部に書くためのガイドライン」BCP26、RFC2434(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.とカネッティとR.とSongとD.とJ.Tygarと「マルチキャストのための効率的で安全なソース認証」とNetworkとDistributed System Security Symposium、NDSS2001、ページ 35-46と、2001年2月。
[8] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[8] 1992年4月、最もRivestなR.、「MD5メッセージダイジェストアルゴリズム」RFC1321。
[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.とカーモードとR.とハンドレーとM.とフロイドとS.とM.Luby、「多くへの1のための信頼できるマルチキャスト輸送ブロックバルク・データ転送」、RFC3048、2001年1月。
Luby, et. al. Experimental [Page 14] RFC 3452 FEC Building Block December 2002
et Luby、アル。 [14ページ]実験的なRFC3452FECブロック2002年12月
12. Authors' Addresses
12. 作者のアドレス
Michael Luby Digital Fountain, Inc. 39141 Civic Center Drive Suite 300 Fremont, CA 94538
フレモント、マイケルLubyのデジタル噴水Inc.39141シビック・センタードライブSuite300カリフォルニア 94538
EMail: luby@digitalfountain.com
メール: luby@digitalfountain.com
Lorenzo Vicisano Cisco Systems, Inc. 170 West Tasman Dr., San Jose, CA, USA, 95134
ロレンツォVicisanoシスコシステムズInc.170の西タスマン博士、サンノゼ(カリフォルニア)、米国95134
EMail: lorenzo@cisco.com
メール: lorenzo@cisco.com
Jim Gemmell Microsoft Research 455 Market St. #1690 San Francisco, CA, 94105
ジムGemmellマイクロソフトResearch455はサンフランシスコ、聖#1690カリフォルニア 94105を売り出します。
EMail: jgemmell@microsoft.com
メール: jgemmell@microsoft.com
Luigi Rizzo Dip. di Ing. dell'Informazione Universita` di Pisa via Diotisalvi 2, 56126 Pisa, Italy
ルーイジリゾーDipディIng Diotisalvi2、56126ピサ、イタリア経由でdell'Informazione Universita'ディピサ
EMail: luigi@iet.unipi.it
メール: luigi@iet.unipi.it
Mark Handley ICSI Center for Internet Research 1947 Center St. Berkeley CA, USA, 94704
カリフォルニア、インターネット研究1947センター通り米国バークレー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
Luby, et. al. Experimental [Page 15] RFC 3452 FEC Building Block December 2002
et Luby、アル。 [15ページ]実験的なRFC3452FECブロック2002年12月
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Luby, et. al. Experimental [Page 16]
et Luby、アル。 実験的[16ページ]
一覧
スポンサーリンク
