RFC3695 日本語訳

Network Working Group                                            M. Luby
Request for Comments: 3695                              Digital Fountain
Category: Experimental                                       L. Vicisano
                                                                   Cisco
                                                           February 2004

Lubyがコメントのために要求するワーキンググループM.をネットワークでつないでください: 3695年のデジタル噴水カテゴリ: 実験的なL.Vicisanoコクチマス2004年2月

             Compact Forward Error Correction (FEC) Schemes

コンパクトな前進型誤信号訂正(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 (2004).  All Rights Reserved.

Copyright(C)インターネット協会(2004)。 All rights reserved。

Abstract

要約

   This document introduces some Forward Error Correction (FEC) schemes
   that supplement the FEC schemes described in RFC 3452.  The primary
   benefits of these additional FEC schemes are that they are designed
   for reliable bulk delivery of large objects using a more compact FEC
   Payload ID, and they can be used to sequentially deliver blocks of an
   object of indeterminate length.  Thus, they more flexibly support
   different delivery models with less packet header overhead.

このドキュメントはRFC3452で説明されたFEC体系を補ういくつかのForward Error Correction(FEC)体系を導入します。 これらの追加FEC体系の主要便益は大きいオブジェクトの信頼できる大量の配送のために、よりコンパクトなFEC Payload IDを使用することでそれらを設計して、不確定の長さのオブジェクトのブロックを連続して提供するのにそれらを使用できるということです。 したがって、彼らは、より少ないパケットのヘッダーオーバーヘッドで、より柔軟に異なった配送モデルをサポートします。

   This document also describes the Fully-Specified FEC scheme
   corresponding to FEC Encoding ID 0.  This Fully-Specified FEC scheme
   requires no FEC coding and is introduced primarily to allow simple
   interoperability testing between different implementations of
   protocol instantiations that use the FEC building block.

また、このドキュメントはFEC Encoding ID0に対応するFullyによって指定されたFEC体系について説明します。 このFullyによって指定されたFEC体系をFECコード化でないのを必要として、主としてFECブロックを使用するプロトコル具体化の異なった実装の間の簡単な相互運用性テストを許すために導入します。

Table of Contents

目次

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Packet Header Fields . . . . . . . . . . . . . . . . . . . . .  3
       2.1.  FEC Payload ID for FEC Encoding IDs 0 and 130. . . . . .  4
       2.2.  Compact No-Code FEC scheme . . . . . . . . . . . . . . .  5
       2.3.  Compact FEC scheme . . . . . . . . . . . . . . . . . . .  5
   3.  Compact No-Code FEC scheme . . . . . . . . . . . . . . . . . .  6
       3.1.  Source Block Logistics . . . . . . . . . . . . . . . . .  7
       3.2.  Sending and Receiving a Source Block . . . . . . . . . .  8
   4.  Usage Examples . . . . . . . . . . . . . . . . . . . . . . . .  9
       4.1.  Reliable Bulk Data Delivery. . . . . . . . . . . . . . .  9

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 パケットヘッダーフィールド. . . . . . . . . . . . . . . . . . . . . 3 2.1。 ID0と130をコード化するFECのためのFEC Payload ID。 . . . . . 4 2.2. コンパクトなコードがないFECは.52.3を計画します。 コンパクトなFECは.5 3を計画します。 コンパクトなコードがないFECは.63.1を計画します。 ソースブロックロジスティクス. . . . . . . . . . . . . . . . . 7 3.2。 ソースを送って、受け取ると、.8 4は立ち塞がります。 使用例. . . . . . . . . . . . . . . . . . . . . . . . 9 4.1。 信頼できる大量のデータ配送。 . . . . . . . . . . . . . . 9

Luby & Vicisano               Experimental                      [Page 1]

RFC 3695                      FEC Schemes                  February 2004

Luby&Vicisanoの実験的な[1ページ]RFC3695FECは2004年2月に計画します。

       4.2.  Block-Stream Delivery. . . . . . . . . . . . . . . . . . 10
   5.  Security Considerations. . . . . . . . . . . . . . . . . . . . 10
   6.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 10
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
       7.1.  Normative References . . . . . . . . . . . . . . . . . . 11
       7.2.  Informative References . . . . . . . . . . . . . . . . . 12
   8.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
   9.  Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13

4.2. 岩塊流配送。 . . . . . . . . . . . . . . . . . 10 5. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 10 6. IANA問題。 . . . . . . . . . . . . . . . . . . . . . 10 7. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1。 引用規格. . . . . . . . . . . . . . . . . . 11 7.2。 有益な参照. . . . . . . . . . . . . . . . . 12 8。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 12 9。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 13

1.  Introduction

1. 序論

   This document describes two new Forward Error Correction (FEC)
   schemes corresponding to FEC Encoding IDs 0 and 130 which supplement
   the FEC schemes corresponding to FEC Encoding IDs 128 and 129
   described in the FEC Building Block [4].

このドキュメントはFECビルBlock[4]のFEC Encoding ID128と129に対応するFEC体系がそれの補足について説明したFEC Encoding ID0と130に対応する2の新しいForward Error Correction(FEC)体系について説明します。

   The new FEC schemes are particularly applicable when an object is
   partitioned into equal-length source blocks.  In this case, the
   source block length common to all source blocks can be communicated
   out-of-band, thus saving the additional overhead of carrying the
   source block length within the FEC Payload ID of each packet.  The
   new FEC schemes are similar to the FEC schemes with FEC Encoding ID
   128 defined in RFC 3452 [4], except that the FEC Payload ID is half
   as long.  This is the reason that these new FEC schemes are called
   Compact FEC schemes.

オブジェクトが等しい長さのソースブロックに仕切られるとき、新しいFEC体系は特に適切です。 この場合、バンドの外ですべてのソースブロックに共通のソースブロック長を伝えることができます、その結果、それぞれのパケットのFEC Payload IDの中でソースブロック長を運ぶ追加オーバーヘッドを節約します。 FEC Encoding ID128がRFC3452[4]で定義されている状態で、新しいFEC体系はFEC体系と同様です、FEC Payload IDが長いとして半分を除いて。 これはこれらの新しいFEC体系がCompact FEC体系と呼ばれる理由です。

   The primary focus of FEC Encoding IDs 128 and 129 is to reliably
   deliver bulk objects of known length.  The FEC schemes described in
   this document are designed to be used for both reliable delivery of
   bulk objects of known length, and for the delivery of a stream of
   source blocks for an object of indeterminate length.  Within the
   block-stream delivery model, reliability guarantees can range from
   acknowledged reliable delivery of each block to unacknowledged
   enhanced-reliability delivery of time-sensitive blocks, depending on
   the properties of the protocol instantiation in which the FEC scheme
   is used.  Acknowledged reliable block-stream delivery is similar in
   spirit to the byte-stream delivery that TCP offers, except that the
   unit of delivery is a block of data instead of a byte of data.  In
   the spirit of a building block (see RFC 3048 [6]), the FEC schemes
   described in this document can be used to provide reliability for
   other service models as well.

FEC Encoding ID128と129の焦点は知られている長さの大量のオブジェクトを確かに提供することになっています。 本書では説明されたFEC体系は、知られている長さの大量のオブジェクトのともに信頼できる配送、および不確定の長さのオブジェクトのためのソースブロックのストリームの配送に使用されるように設計されています。 岩塊流配送モデルの中では、信頼性の保証はそれぞれのブロックの承認された信頼できる配信から不承認の時間機密のブロックの高められた信頼性の配送まで及ぶことができます、FEC体系が使用されているプロトコル具体化の所有地によって。 承認された信頼できる岩塊流配送は精神においてTCPが提供するバイト・ストリーム配送と同様です、配送のユニットが1バイトのデータの代わりに1ブロックのデータであるのを除いて。 ブロックの精神、(3048[6])、体系がこれで説明したFECがまた、他のサービスモデルに信頼性を供給するのに使用できると記録するRFCを見てください。

   The two new FEC Encoding IDs 0 and 130 are described in Section 2,
   and this supplements Section 5 of the FEC building block [4].
   Section 3 of this document describes the Fully-Specified FEC scheme
   corresponding to the FEC Encoding ID 0.  This Fully-Specified FEC

2新しいFEC Encoding ID0と130がセクション2で説明されます、そして、これはFECブロック[4]のセクション5を補います。 このドキュメントのセクション3はFEC Encoding ID0に対応するFullyによって指定されたFEC体系について説明します。 この完全に指定されたFEC

Luby & Vicisano               Experimental                      [Page 2]

RFC 3695                      FEC Schemes                  February 2004

Luby&Vicisanoの実験的な[2ページ]RFC3695FECは2004年2月に計画します。

   scheme requires no FEC coding and is specified primarily to allow
   simple interoperability testing between different implementations of
   protocol instantiations that use the FEC building block.

体系は、FECコード化でないのを必要として、主としてFECブロックを使用するプロトコル具体化の異なった実装の間の簡単な相互運用性テストを許すために指定されます。

   This document inherits the context, language, declarations and
   restrictions of the FEC building block [4].  This document also uses
   the terminology of the companion document [7] 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.

このドキュメントはFECブロック[4]の文脈、言語、宣言、および制限を引き継ぎます。 また、このドキュメントは信頼できるIPマルチキャスト輸送の文脈の中でFECコードの使用について説明して、いくつかの一般的に使用されたFECコードに序論を提供する仲間ドキュメント[7]の用語を使用します。

   Building blocks are defined in RFC 3048 [6].  This document is a
   product of the IETF RMT WG and follows the general guidelines
   provided in RFC 3269 [3].

ブロックはRFC3048[6]で定義されます。 このドキュメントは、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 RFC 2119 [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 (RMT) protocol in accordance with RFC
   2357 [5].  As per RFC 2357, the use of any reliable multicast
   protocol in the Internet requires an adequate congestion control
   scheme.

このメモはRFC2357[5]によると、Reliable Multicast Transport(RMT)プロトコルを完全に指定するのに必要な定義の一部を含んでいます。 RFC2357に従って、インターネットでのどんな信頼できるマルチキャストプロトコルの使用も適切な輻輳制御体系を必要とします。

   While waiting for such a scheme to be available, or for an existing
   scheme to be proven adequate, the RMT working group publishes this
   Request for Comments in the "Experimental" category.

そのような体系が利用可能であるか、または既存の体系が適切であると立証されるのを待っている間、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.  Packet Header Fields

2. パケットのヘッダー分野

   This section specifies FEC Encoding IDs 0 and 130 and the associated
   FEC Payload ID formats and the specific information in the
   corresponding FEC Object Transmission Information.  The FEC scheme
   associated with FEC Encoding ID 0 is Fully-Specified whereas the FEC
   schemes associated with FEC Encoding ID 130 are Under-Specified.

このセクションはFEC Encoding ID0と130、関連FEC有効搭載量ID形式、および対応するFEC Object Transmission情報の特殊情報を指定します。 FEC Encoding ID0に関連しているFEC体系はFullyによって指定されていますが、FEC Encoding ID130に関連しているFEC体系はUnderによって指定されています。

   FEC Encoding IDs 0 and 130 have the same FEC Payload ID format, which
   is described in the following subsection.  The FEC Object
   Transmission Information for FEC Encoding IDs 0 and 130 is different,
   and is described in the subsequent two subsections.

FEC Encoding ID0と130には、以下の小区分で説明されるのと同じFEC有効搭載量ID形式があります。 FEC Encoding ID0と130のためのFEC Object Transmission情報は、異なって、その後の2つの小区分で説明されます。

Luby & Vicisano               Experimental                      [Page 3]

RFC 3695                      FEC Schemes                  February 2004

Luby&Vicisanoの実験的な[3ページ]RFC3695FECは2004年2月に計画します。

2.1.  FEC Payload ID for FEC Encoding IDs 0 and 130

2.1. ID0と130をコード化するFECのためのFEC Payload ID

   The FEC Payload ID for FEC Encoding IDs 0 and 130 is composed of a
   Source Block Number and an Encoding Symbol ID structured as follows:

FEC Encoding ID0と130のための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 16-bit Source Block Number is used to identify from which source
   block of the object the encoding symbol in the payload of the packet
   is generated.  There are two possible modes: In the unique SBN mode
   each source block within the object has a unique Source Block Number
   associated with it, and in the non-unique SBN mode the same Source
   Block Number may be used for more than one source block within the
   object.  Which mode is being used for an object is outside the scope
   of this document and MUST be communicated, either explicitly or
   implicitly, out-of-band to receivers.

16ビットのSource Block Numberは、パケットのペイロードのコード化シンボルがオブジェクトのどのソースブロックから発生しているかを特定するのに使用されます。 2つの可能なモードがあります: ユニークなSBNモードで、オブジェクトの中のそれぞれのソースブロックは、それに関連しているユニークなSource Block Numberを持って、1つ以上のソースブロック以上にオブジェクトの中に同じ非ユニークなSBNモードSource Block Numberで使用されるかもしれません。 どのモードがオブジェクトに使用されているか受信機にこのドキュメントの範囲の外にあって、バンドの外で明らかかそれとなく伝えなければなりません。

   If the unique SBN mode is used then successive Source Block Numbers
   are associated with consecutive source blocks of the object starting
   with Source Block Number 0 for the first source block of the object.
   In this case, there are at most 2^16 source blocks in the object.

ユニークなSBNモードが使用されているなら、連続したSource Block民数記はオブジェクトの最初のソースブロックにSource Block Number0から始まるオブジェクトの連続したソースブロックに関連しています。 この場合、2^16ソースブロックがオブジェクトに高々あります。

   If the non-unique SBN mode is used then the mapping from source
   blocks to Source Block Numbers MUST be communicated out-of-band to
   receivers, and how this is done is outside the scope of this
   document.  This mapping could be implicit, for example determined by
   the transmission order of the source blocks.   In non-unique SBN
   mode, packets for two different source blocks mapped to the same
   Source Block Number SHOULD NOT be sent within an interval of time
   that is shorter than the transport time of a source block.  The
   transport time of a source block includes the amount of time the
   source block is processed at the transport layer by the sender, the
   network transit time for packets, and the amount of time the source
   block is processed at the transport layer by a receiver.  This allows
   the receiver to clearly decide which packets belong to which source
   block.

非ユニークなSBNモードが使用されているなら、バンドの外でソースブロックからSource Block民数記までのマッピングを受信機に伝えなければなりません、そして、このドキュメントの範囲の外にこれがどう完了しているかがあります。 例えば、ソースブロックのトランスミッション命令で決定して、このマッピングは暗黙であるかもしれません。 非ユニークなSBNモード、同じSource Block Number SHOULDに写像された2つの異なったソースブロックパケットでは、1つのソースブロックの輸送時間より短い間の間隔以内に送られないでください。 1つのソースブロックの輸送時間はソースブロックが送付者によってトランスポート層に処理される時間、パケットのためのネットワークトランジット時間、およびソースブロックが受信機によってトランスポート層に処理される時間を含んでいます。これは、受信機が、どのパケットがどのソースブロックに属すかを明確に決めるのを許容します。

   The 16-bit Encoding Symbol ID identifies which specific encoding
   symbol generated from the source block is carried in the packet
   payload.  The exact details of the correspondence between Encoding
   Symbol IDs and the encoding symbols in the packet payload for FEC
   Encoding ID 0 are specified in Section 3.  The exact details of the
   correspondence between Encoding Symbol IDs and the encoding symbol(s)
   in the packet payload for FEC Encoding ID 130 are dependent on the

16ビットのEncoding Symbol IDは、ソースブロックから生成されたどの特定のコード化シンボルがパケットペイロードで運ばれるかを特定します。 Encoding Symbol IDの間の通信の正確な詳細とパケットペイロードのFEC Encoding ID0のコード化シンボルはセクション3で指定されます。 Encoding Symbol IDの間の通信の正確な詳細とパケットペイロードのFEC Encoding ID130のコード化シンボルは依存しています。

Luby & Vicisano               Experimental                      [Page 4]

RFC 3695                      FEC Schemes                  February 2004

Luby&Vicisanoの実験的な[4ページ]RFC3695FECは2004年2月に計画します。

   particular encoding algorithm used as identified by the FEC Encoding
   ID and by the FEC Instance ID.

FEC Encoding IDとFEC Instance IDによって特定されるように使用される特定のコード化アルゴリズム。

2.2.  Compact No-Code FEC scheme

2.2. コンパクトなコードがないFEC体系

   This subsection reserves FEC Encoding ID 0 for the Compact No-Code
   FEC scheme described in this subsection and in Section 3.  This is a
   Fully-Specified FEC scheme that is primarily intended to be used for
   simple interoperability testing between different implementations of
   protocol instantiations that use the FEC building block.  The value
   of this FEC scheme is that no FEC encoding or decoding is required to
   implement it and therefore it is easy to test interoperability
   between protocols that may use different proprietary FEC schemes in
   production in their first implementations.

この小区分はこの小区分とセクション3で説明されたCompactコードがないFEC体系のためにFEC Encoding ID0を予約します。 これはFECブロックを使用するプロトコル具体化の異なった実装の間の簡単な相互運用性テストに使用されることを主として意図するFullyによって指定されたFEC体系です。 このFEC体系の値はFECコード化か解読でないのがそれを実装するのに必要であり、したがって、それらの最初の実装に異なった独占FEC体系を生産に使用するかもしれないプロトコルの間の相互運用性をテストするのが簡単であるということです。

   The FEC Payload ID format for FEC Encoding ID 0 is described in
   Subsection 2.1.  The FEC Object Transmission Information has the
   following specific information:

FEC Encoding ID0のためのFEC有効搭載量ID形式はSubsection2.1で説明されます。 FEC Object Transmission情報には、以下の特殊情報があります:

   o The FEC Encoding ID 0.

o ID0をコード化するFEC。

   o For each source block of the object, the length in bytes of the
     encoding symbol carried in the packet payload.  This length MUST be
     the same for all packets sent for the same source block, but MAY be
     different for different source blocks in the same object.

o オブジェクトのそれぞれのソースブロックに関しては、コード化シンボルのバイトで表現される長さはパケットペイロードで運ばれました。 この長さは、同じソースブロックに送られたすべてのパケットに同じでなければなりませんが、同じオブジェクトでの異なったソースブロックにおいて、異なっているかもしれません。

   o For each source block of the object, the length of the source block
     in bytes.  Typically, each source block for the object has the same
     length and thus only one length common to all source blocks need be
     communicated, but this is not a requirement.  For convenience, the
     source block length MAY be a multiple of the length of the encoding
     symbol carried in one packet payload.

o オブジェクトのそれぞれのソースブロック、バイトで表現されるソースブロックの長さのために。 通常、オブジェクトのためのそれぞれのソースブロックでブロックが必要とするすべてのソースに、一般的な同じ長さとその結果ワンレンだけを伝えますが、これは要件ではありません。 便宜のために、ソースブロック長は1個のパケットペイロードで運ばれたコード化シンボルの長さの倍数であるかもしれません。

   How this out-of-band information is communicated is outside the scope
   of this document.

このドキュメントの範囲の外にこのバンドで出ている情報がどう伝えられるかがあります。

   Other information, such as the object length and the number of source
   blocks of the object for an object of known length may be needed by a
   receiver to support some delivery models, i.e., reliable bulk data
   delivery.

知られている長さのオブジェクトのためのオブジェクトのソースブロックのオブジェクトの長さや数の他の情報は、何人かの配送モデル(すなわち、信頼できる大量のデータ配送)をサポートするために受信機によって必要とされるかもしれません。

2.3.  Compact FEC scheme

2.3. コンパクトなFEC体系

   This subsection reserves FEC Encoding ID 130 for the Compact FEC
   scheme that is described in this subsection.  This is an
   Under-Specified FEC scheme.  This FEC scheme is similar in spirit to
   the Compact No-Code FEC scheme, except that a non-trivial FEC
   encoding (that is Under-Specified) may be used to generate encoding

この小区分はこの小区分で説明されるCompact FEC体系のためにFEC Encoding ID130を予約します。 これはUnderによって指定されたFEC体系です。 このFEC体系は精神においてCompactコードがないFEC体系と同様です、重要なFECコード化(それはUnderによって指定されている)がコード化を生成するのに使用されるかもしれないのを除いて

Luby & Vicisano               Experimental                      [Page 5]

RFC 3695                      FEC Schemes                  February 2004

Luby&Vicisanoの実験的な[5ページ]RFC3695FECは2004年2月に計画します。

   symbol(s) placed in the payload of each packet and a corresponding
   FEC decoder may be used to produce the source block from received
   packets.

それぞれのパケットのペイロードと対応するFECデコーダに置かれたシンボルは、容認されたパケットからソースブロックを作り出すのに使用されるかもしれません。

   The FEC Payload ID format for FEC Encoding ID 0 is described in
   Subsection 2.1.  The FEC Object Transmission Information has the
   following specific information:

FEC Encoding ID0のためのFEC有効搭載量ID形式はSubsection2.1で説明されます。 FEC Object Transmission情報には、以下の特殊情報があります:

   o The FEC Encoding ID 130.

o ID130をコード化するFEC。

   o The FEC Instance ID associated with the FEC Encoding ID 130 to be
     used.

o FEC Instance IDは、使用されるためにFEC Encoding ID130と交際しました。

   o For each source block of the object, the aggregate length of the
     encoding symbol(s) carried in one packet payload.  This length MUST
     be the same for all packets sent for the same source block, but MAY
     be different for different source blocks in the same object.

o オブジェクトのそれぞれのソースブロックに関しては、コード化シンボルの集合長さは1個のパケットペイロードで運ばれました。 この長さは、同じソースブロックに送られたすべてのパケットに同じでなければなりませんが、同じオブジェクトでの異なったソースブロックにおいて、異なっているかもしれません。

   o For each source block of the object, the length of the source block
     in bytes.  Typically, each source block for the object has the same
     length and thus only one length common to all source blocks need to
     be communicated, but this is not a requirement.  For convenience,
     the source block length MAY be a multiple of the aggregate length
     of the encoding symbol(s) carried in one packet payload.

o オブジェクトのそれぞれのソースブロック、バイトで表現されるソースブロックの長さのために。 通常、すべてのソースブロックに共通の同じ長さとその結果、ワンレンだけが、オブジェクトのためのそれぞれのソースブロックでコミュニケートする必要がありますが、これは要件ではありません。 便宜のために、ソースブロック長は1個のパケットペイロードで運ばれたコード化シンボルの集合長さの倍数であるかもしれません。

   How this out-of-band information is communicated is outside the scope
   of this document.

このドキュメントの範囲の外にこのバンドで出ている情報がどう伝えられるかがあります。

   Other information, such as the object length and the number of source
   blocks of the object for an object of known length may be needed by a
   receiver to support some delivery models, i.e., reliable bulk data
   delivery.

知られている長さのオブジェクトのためのオブジェクトのソースブロックのオブジェクトの長さや数の他の情報は、何人かの配送モデル(すなわち、信頼できる大量のデータ配送)をサポートするために受信機によって必要とされるかもしれません。

3.  Compact No-Code FEC scheme

3. コンパクトなコードがないFEC体系

   In this section we describe a Fully-Specified FEC scheme
   corresponding to FEC Encoding ID 0.  The primary purpose for
   introducing these FEC schemes is to allow simple interoperability
   testing between different implementations of the same protocol
   instantiation that uses the FEC building block.

このセクションで、私たちはFEC Encoding ID0に対応するFullyによって指定されたFEC体系について説明します。 これらのFEC体系を導入するためのプライマリ目的はFECブロックを使用する同じプロトコル具体化の異なった実装の間の簡単な相互運用性テストを許すことです。

   The Compact No-Code FEC scheme does not require FEC encoding or
   decoding.  Instead, each encoding symbol consists of consecutive
   bytes of a source block of the object.  The FEC Payload ID consists
   of two fields, the 16-bit Source Block Number and the 16-bit Encoding
   Symbol ID, as described in Subsection 2.1.  The relative lengths of
   these fields were chosen for their similarity with the corresponding
   fields of the FEC Payload ID associated with FEC Encoding ID 130, and

CompactコードがないFEC体系はFECコード化か解読を必要としません。 代わりに、それぞれシンボルをコード化するのはオブジェクトの1つのソースブロックの連続したバイトから成ります。 FEC Payload IDが2つの分野から成って、16ビットは、Source Block Numberと16ビットのEncoding Symbol IDです、Subsection2.1で説明されるように。 そしてこれらの分野の相対的な長さがFEC Encoding ID130に関連しているFEC Payload IDの対応する分野でそれらの類似性に選ばれた。

Luby & Vicisano               Experimental                      [Page 6]

RFC 3695                      FEC Schemes                  February 2004

Luby&Vicisanoの実験的な[6ページ]RFC3695FECは2004年2月に計画します。

   because of this testing interoperability of the FEC scheme associated
   with FEC Encoding ID 0 provides a first basic step to testing
   interoperability of an FEC scheme associated with FEC Encoding ID
   130.

FEC Encodingに関連しているFEC体系のこのテスト相互運用性のために、ID0はFEC Encoding ID130に関連しているFEC体系のテスト相互運用性に最初の基本的なステップを提供します。

   Subsection 2.1. describes mapping between source blocks of an object
   and Source Block Numbers.  The next two subsections describe the
   details of how the Compact No-Code FEC scheme operates for each
   source block of an object.  These subsections are not meant to
   suggest a particular implementation, but just to illustrate the
   general algorithm through the description of a simple, non-optimized
   implementation.

小区分2.1は、ソースブロックのオブジェクトとSource Blockの間で民数記を写像すると説明します。 次の2つの小区分がCompactコードがないFEC体系がどうオブジェクトのそれぞれのソースブロックに作動するかに関する詳細について説明します。 特定の実装を示すことが意味されるのではなく、これらの小区分は、ただ簡単で、非最適化された実装の記述で一般的なアルゴリズムを例証するために意味されます。

3.1.  Source Block Logistics

3.1. ソースブロックロジスティクス

   Let X > 0 be the length of a source block in bytes.  The value of X
   is part of the FEC Object Transmission Information, and how this
   information is communicated to a receiver is outside the scope of
   this document.

X>0がバイトで表現される1つのソースブロックの長さであることをさせてください。 Xの値はFEC Object Transmission情報の一部です、そして、このドキュメントの範囲の外にこの情報がどう受信機に伝えられるかがあります。

   Let L > 0 be the length of the encoding symbol contained in the
   payload of each packet.  There are several possible ways the length
   of the encoding symbol L can be communicated to the receiver, and how
   this is done is outside the scope of this document.  As an example, a
   sender could fix the packet payload length to be L in order to place
   the encoding symbol of length L into the packet, and then a receiver
   could infer the value of L from the length of the received packet
   payload.  It is REQUIRED that L be the same for all packets sent for
   the same source block but MAY be different for different source
   blocks within the same object.

L>0がそれぞれのパケットのペイロードに含まれたコード化シンボルの長さであることをさせてください。 コード化しているシンボルLの長さを受信機に伝えることができて、このドキュメントの範囲の外にこれがどう完了しているかがあるいくつかの可能な方法があります。 例として、長さLのコード化シンボルをパケットに置いて、送付者はLになるようにパケットペイロード長を固定できて、次に、受信機は容認されたパケットペイロードの長さからのLの値を推論するかもしれません。 Lが同じソースブロックに送られたすべてのパケットに同じですが、異なったソースブロックにおいて、同じオブジェクトの中に異なるかもしれないのは、REQUIREDです。

   For a given source block X bytes in length with Source Block Number
   I, let N = X/L rounded up to the nearest integer.  The encoding
   symbol carried in the payload of a packet consists of a consecutive
   portion of the source block.  The source block is logically
   partitioned into N encoding symbols, each L bytes in length, and the
   corresponding Encoding Symbol IDs range from 0 through N-1 starting
   at the beginning of the source block and proceeding to the end.
   Thus, the encoding symbol with Encoding Symbol ID Y consists of bytes
   L*Y through L*(Y+1)-1 of the source block, where the bytes of the
   source block are numbered from 0 through X-1.  If X/L is not integral
   then the last encoding symbol with Encoding Symbol ID = N-1 consists
   of bytes L*(N-1) through the last byte X-1 of the source block, and
   the remaining L*N - X bytes of the encoding symbol can by padded out
   with zeroes.

与えられたソースに、Source Block Number Iと共に長さにおけるXバイトを妨げてください、そして、Nを最も近い整数まで一周したX/Lとの等しさにしてください。 パケットのペイロードで運ばれたコード化シンボルはソースブロックの連続した部分から成ります。 ソースブロックはシンボルをコード化するNに論理的に仕切られて、それぞれは長さがLバイトです、そして、対応するEncoding Symbol IDが、ソースブロックの始めに始まって、終わりまで続きながら、N-1を通して0から変化します。 したがって、Encoding Symbol ID Yがあるコード化シンボルは-1L*(Y+1)ソースブロックを通ってバイトL*Yから成ります。そこでは、ソースブロックのバイトがX-1を通して0から付番されます。 X/Lが不可欠でないなら、Encoding Symbol IDと共にシンボルをコード化する最終=N-1はソースブロックの最後のバイトX-1、および残っているL*Nを通してバイトL*(N-1)から成ります--コード化のXバイトはゼロで広げられた缶を象徴します。

Luby & Vicisano               Experimental                      [Page 7]

RFC 3695                      FEC Schemes                  February 2004

Luby&Vicisanoの実験的な[7ページ]RFC3695FECは2004年2月に計画します。

   As an example, suppose that the source block length X = 20,400 and
   encoding symbol length L = 1,000.  The encoding symbol with Encoding
   Symbol ID = 10 contains bytes 10,000 through 10,999 of the source
   block, and the encoding symbol with Encoding Symbol ID = 20 contains
   bytes 20,000 through the last byte 20,399 of the source block and the
   remaining 600 bytes of the encoding symbol can be padded with zeroes.

例として、ソースブロック長Xが2万400とシンボルの長さL=1,000をコード化するのと等しいと仮定してください。 Encoding Symbol ID=10があるコード化シンボルはソースブロックのバイト1万〜10,999を含んでいます、そして、Encoding Symbol ID=20があるコード化シンボルはソースブロックの最後のバイト20,399を通してバイト20,000を含んでいます、そして、ゼロでコード化シンボルの残っている600バイトは水増しできます。

   There are no restrictions beyond the rules stated above on how a
   sender generates encoding symbols to send from a source block.
   However, it is recommended that an implementor of refer to the
   companion document [7] for general advice.

制限は全く送付者が、コード化がソースブロックから送るシンボルであるとどう生成するかに関して上に述べられた規則を超えていません。 しかしながら、それがそれに推薦される、作成者、一般的助言を求める仲間ドキュメント[7]を参照してください。

   In the next subsection a procedure is recommended for sending and
   receiving source blocks.

次の小区分では、手順は送受信ソースブロック推薦されます。

3.2.  Sending and Receiving a Source Block

3.2. ソースブロックを送って、受け取ります。

   The following carousel procedure is RECOMMENDED for a sender to
   generate packets containing FEC Payload IDs and corresponding
   encoding symbols for a source block with Source Block Number I.  Set
   the length in bytes of an encoding symbol to a fixed value L which is
   reasonable for a packet payload (e.g., ensure that the total packet
   size does not exceed the MTU) and that is smaller than the source
   block length X, e.g., L = 1,000 for X >= 1,000.  Initialize Y to a
   value randomly chosen in the interval [0..N-1].  Repeat the following
   for each packet of the source block to be sent.

以下の回転木馬手順は送付者がFEC有効搭載量IDを含むパケットを生成するRECOMMENDEDです、そして、Source Block Number I.Setと共に1つのソースブロックのシンボルをコード化しながら対応している、パケットペイロード(例えば、総パケットサイズがMTUを超えていないのを確実にする)とそれに、妥当な一定の価値Lへのコード化シンボルのバイトで表現される長さはソースブロック長Xよりわずかです、例えば、X>=1,000のためのL=1,000。 間隔[0..N-1]で手当たりしだいに選ばれた値にYを初期化してください。 以下を繰り返して、ソースブロックの各パケットを送ってください。

   o If Y < N-1 then generate the encoding symbol consisting of the L
     bytes of the source block numbered L*Y through L*(Y+1)-1.

o 次に、Y<N-1がコード化を生成するなら、ソースブロックのLバイトのシンボルの成るのはL*(Y+1)-1を通してL*Yに付番しました。

   o If Y = N-1 then generate the encoding symbol consisting of the last
     X - L*(N-1) bytes of the source block numbered L*(N-1) through X-1
     followed by L*N - X padding bytes of zeroes.

o YがN-1と等しいなら、コード化が最後のXから成るシンボルであると生成してください--ソースブロックのL*(N-1)バイトはL*N--Xがバイトのゼロを水増ししながらあとに続いたX-1を通してL*(N-1)に付番しました。

   o Set the Source Block Length to X, set the Source Block Number = I,
     set the Encoding Symbol ID = Y, place the FEC Payload ID and the
     encoding symbol into the packet to send.

o X(Source Block Number=私(セットEncoding Symbol ID=Y)が送るためにFEC Payload IDとパケットへのコード化シンボルを置くセット)にSource Block Lengthを設定してください。

   o In preparation for the generation of the next packet: if Y < N-1
     then increment Y by one else if Y = N-1 then reset Y to zero.

o 次のパケットの世代に備えて: 次に、YがN-1と等しいならY<N-1がほかにYを1つ増加するなら、ゼロにYをリセットしてください。

   The following procedure is RECOMMENDED for a receiver to recover the
   source block based on receiving packets for the source block from a
   sender that is using the carousel procedure describe above.  The
   receiver can determine from which source block a received packet was
   generated by the Source Block Number carried in the FEC Payload ID.
   Upon receipt of the first FEC Payload ID for a source block, the
   receiver uses the source block length received out-of-band as part of

以下の手順は送付者からの回転木馬手順が上で説明する使用であるソースブロックにパケットを受けることに基づいて受信機がソースブロックを回収するRECOMMENDEDです。 受信機は、容認されたパケットがFEC Payload IDで運ばれたSource Block Numberによってどのソースブロックから生成されたかを決定できます。 ソースブロック、ソースブロック長が部分としてバンドの外で受信した受信機用途のための最初のFEC Payload IDを受け取り次第

Luby & Vicisano               Experimental                      [Page 8]

RFC 3695                      FEC Schemes                  February 2004

Luby&Vicisanoの実験的な[8ページ]RFC3695FECは2004年2月に計画します。

   the FEC Object Transmission Information to determine the length X in
   bytes of the source block, and allocates space for the X bytes that
   the source block requires.  The receiver also computes the length L
   of the encoding symbol in the payload of the packet by substracting
   the packet header length from the total length of the received packet
   (and the receiver checks that this length is the same in each
   subsequent received packet from the same source block).  After
   calculating N = X/L rounded up to the nearest integer, the receiver
   allocates a boolean array RECEIVED[0..N-1] with all N entries
   initialized to false to track received encoding symbols.  The
   receiver keeps receiving packets for the source block as long as
   there is at least one entry in RECEIVED still set to false or until
   the application decides to give up on this source block and move on
   to other source blocks.  For each received packet for the source
   block (including the first packet) the steps to be taken to help
   recover the source block are as follows.  Let Y be the value of the
   Encoding Symbol ID within FEC Payload ID of the packet.  If Y < N-1
   then the receiver copies the L bytes of the encoding symbol into
   bytes numbered L*Y through L*(Y+1)-1 of the space reserved for the
   source block.  If Y = N-1 then the receiver copies the first
   X - L*(N-1) bytes of the encoding symbol into bytes numbered L*(N-1)
   through X-1 of the space reserved for the source block.  In either
   case, the receiver sets RECEIVED[Y] = true.  At each point in time,
   the receiver has successfully recovered bytes L*Y through L*(Y+1)-1
   of the source block for all Y in the interval [0..N-1] for which
   RECEIVED[Y] is true.  If all N entries of RECEIVED are true then the
   receiver has recovered the entire source block.

FEC Object Transmission情報、ソースブロックのバイトで長さXを測定して、スペースをソースブロックが必要とするXバイト割り当てます。 また、受信機は、容認されたパケットの全長からパケットヘッダ長をsubstractingすることによって、パケットのペイロードのコード化シンボルの長さLを計算します(受信機は、この長さがそれぞれのその後の容認されたパケットで同じソースブロックから同じであることをチェックします)。 Nが最も近い整数まで一周したX/Lと等しいと見込んだ後に、受信機はシンボルをコード化するすべてのNエントリーが追跡するために誤っているのに初期化されているRECEIVED[0..N-1]が受けた論理演算子配列を割り当てます。 受信機は少なくとも1つのエントリーがまだ誤るのに用意ができているRECEIVEDにある限り、アプリケーションがこのソースブロックに見切りをつけて、他のソースブロックに移行すると決めるまでソースブロックにパケットを受け続けます。 ソースブロック(最初のパケットを含んでいる)でそれぞれの容認されたパケットに関しては、ソースブロックを回収するのを助けるために取られるべきステップは以下の通りです。 パケットのFEC Payload IDの中でYがEncoding Symbol IDの値であることをさせてください。 Y<N-1であるなら、受信機は-1の番号付のYからL*L*(Y+1)へのスペースがソースブロックに予約したバイトにコード化シンボルのLバイトをコピーします。 YがN-1と等しいなら、受信機は最初のXをコピーします--バイトへのコード化シンボルのL*(N-1)バイトはソースブロックへの予約されたスペースのX-1を通してL*(N-1)に付番しました。 どちらの場合ではも、受信機は= 本当にRECEIVED[Y]を設定します。 時間内にの各ポイントでは、受信機はRECEIVED[Y]が本当である間隔[0..N-1]のすべてのYのための-1L*(Y+1)ソースブロックを通って首尾よくバイトL*Yを回復しました。 RECEIVEDのすべてのNエントリーが本当であるなら、受信機は全体のソースブロックを回収しました。

4.  Usage Examples

4. 使用例

   The following subsections outline some usage examples for FEC
   Encoding IDs 0 and 130.

以下の小区分はFEC Encoding ID0と130のためのいくつかの使用例について概説します。

4.1.  Reliable Bulk Data Delivery

4.1. 信頼できる大量のデータ配送

   One possible delivery model that can be supported using any FEC
   scheme described in this document is reliable bulk data delivery.  In
   this model, one or more potentially large objects are delivered
   reliably to potentially multiple receivers using multicast.  For this
   delivery model the unique SBN mode is often used.  Using this mode
   the maximum length of an object that can be delivered is at most the
   number of possible source blocks times the maximum length of a source
   block.  If the aggregate length of encoding symbols carried in a
   packet payload is L bytes then the maximum length of a source block
   is the number of distinct Encoding Symbol IDs times L, or 2^16 * L
   for FEC Encoding IDs 0 and 130.  If for example L = 1 KB then the
   length of a source block can be up to around 65 MB.   However, in
   practice the length of the source block is usually shorter than the

本書では説明されたどんなFEC体系も使用することでサポートできる1つの可能な配送モデルは信頼できる大量のデータ配送です。 このモデルでは、1個以上の潜在的に大きいオブジェクトが、潜在的に複数の受信機にマルチキャストを使用することで確かに提供されます。 この配送モデルのために、ユニークなSBNモードはしばしば使用されます。 このモードを使用して、提供されているのが、高々可能なソースの数であるということであるかもしれないオブジェクトの最大の長さは1つのソースブロックの最大の長さの倍を妨げます。 集合長さについてパケットペイロードで運ばれたシンボルをコード化するのが、Lバイトであるなら、1つのソースブロックの最大の長さはFEC Encoding ID0と130のための異なったEncoding Symbol ID回数L、または2^16*Lの数です。 例えば、Lが1KBと等しいなら、1つのソースブロックの長さはおよそ65MBまで達することができます。 しかしながら、実際には、通常、ソースブロックの長さは、より不足しています。

Luby & Vicisano               Experimental                      [Page 9]

RFC 3695                      FEC Schemes                  February 2004

Luby&Vicisanoの実験的な[9ページ]RFC3695FECは2004年2月に計画します。

   number of distinct Encoding Symbol IDs times L, and thus generally
   the length of a source block is a fraction of 65 MB.  Since the
   number of distinct Source Block Numbers is 2^16, for this example an
   object can be more than a terabyte.

異なったEncoding Symbol ID回数Lの数、およびその結果、一般に1つのソースブロックの長さはそうです。65MBの何分の一。 異なったSource Block民数記の数が2^16であるので、この例に関して、オブジェクトはテラバイト以上であるかもしれません。

   The non-unique SBN mode of delivery can also be effectively used for
   reliably delivering large object.  In this case, the length of the
   object delivered could be arbitrarily large, depending on the
   out-of-band mapping between source blocks and Source Block Numbers.

また、事実上、大きいオブジェクトを確かに提供するのに配送の非ユニークなSBNモードを使用できます。 この場合、提供されたオブジェクトの長さは任意に大きいかもしれません、ソースブロックとSource Block民数記の間のバンドで出ているマッピングによって。

4.2.  Block-Stream Delivery

4.2. 岩塊流配送

   Another possible delivery model that can be supported using FEC
   Encoding ID 0 or 130 is block-stream delivery of an object.  In this
   model, the source blocks of a potentially indeterminate length object
   are to be reliably delivered in sequence to one or multiple
   receivers.  Thus, the object could be partitioned into source blocks
   on-the-fly at the sender as the data arrives, and all packets
   generated for one source block are sent before any packets are sent
   for the subsequent source block.  In this example, all source blocks
   could be of the same length and this length could be communicated
   out-of-band to a receiver before the receiver joins the session.  For
   this delivery model it is not required that the Source Block Numbers
   for all source blocks are unique.  However, a suggested usage is to
   use all 2^16 Source Block Numbers for consecutive source blocks of
   the object, and thus the time between reuse of a Source Block Number
   is the time it takes to send the packets for 2^16 source blocks.

FEC Encoding ID0か130を使用することでサポートできる別の可能な配送モデルは物の岩塊流配送です。 このモデルでは、潜在的に不確定の長さの物のソースブロックは連続して1か複数の受信機に確かに渡すことです。 したがって、データが到着するとき、送付者で急いでソースブロックに物を仕切ることができました、そして、その後のソースブロックにどんなパケットも送る前に1ソースブロックして発生するすべてのパケットを送ります。 この例では、すべてのソースブロックが同じ長さのものであるかもしれません、そして、受信機がセッションに参加する前にバンドの外でこの長さは受信機に伝えることができました。 この配送モデルにおいて、すべてのソースブロックSource Block民数記がユニークであることが必要ではありません。 しかしながら、提案された用法が物の連続したソースブロックにすべての2^16Source Block民数記を使用することであり、その結果、Source Block Numberの再利用の間の時間はわざわざですそれが2^のためにパケットを16ソースブロック送る。

   This delivery model can be used to reliably deliver an object to one
   or multiple receivers, using either an ACK or NACK based
   acknowledgement based scheme for each source block.  As another
   example the sender could send a fixed number of packets for each
   source block without any acknowledgements from receivers, for example
   in a live streaming without feedback application.

1か複数の受信機に物を確かに渡すのにこの配送モデルを使用できて、ACKかナックのどちらかを使用して、ベースの承認はそれぞれのソースブロックの計画を基礎づけました。 別の例として、送付者は少しも承認なしでパケットの定数を受信機からそれぞれのソースブロックに送ることができました、例えば、フィードバックアプリケーションのないライブストリーミングで。

5.  Security Considerations

5. セキュリティ問題

   The security considerations for this document are the same as they
   are for RFC 3452 [4].

このドキュメントのためのセキュリティ問題はそれらがRFC3452[4]のためのものであるのと同じです。

6.  IANA Considerations

6. IANA問題

   Values of FEC Encoding IDs and FEC Instance IDs are subject to IANA
   registration.  For general guidelines on IANA considerations as they
   apply to this document, see RFC 3452 [4].  This document assigns the
   Fully-Specified FEC Encoding ID 0 under the ietf:rmt:fec:encoding
   name-space to "Compact No-Code".  The FEC Payload ID format and
   corresponding FEC Object Transmission Information associated with FEC

FEC Encoding IDとFEC Instance IDの値はIANA登録を受けることがあります。 IANA問題に関する一般的ガイドラインに関しては、それらがこのドキュメントに適用するとき、RFC3452[4]を見てください。 このドキュメントはietf: rmt: fecの下でFullyによって指定されたFEC Encoding ID0を割り当てます: 「コンパクトなコードがありません」に名前スペースをコード化します。 FECに関連しているFEC有効搭載量ID形式と対応するFEC Object Transmission情報

Luby & Vicisano               Experimental                     [Page 10]

RFC 3695                      FEC Schemes                  February 2004

Luby&Vicisanoの実験的な[10ページ]RFC3695FECは2004年2月に計画します。

   Encoding ID 0 is described in Subsections 2.1 and 2.2, and the
   corresponding FEC scheme is described in Section 3.

ID0をコード化するのはSubsections2.1と2.2で説明されます、そして、対応するFEC計画はセクション3で説明されます。

   This document assigns the Under-Specified FEC Encoding ID 130 under
   the ietf:rmt:fec:encoding name-space to "Compact FEC".  The FEC
   Payload ID format and corresponding FEC Object Transmission
   Information associated with FEC Encoding ID 130 are described in
   Subsections 2.1 and 2.3.

このドキュメントはietf: rmt: fecの下でUnderによって指定されたFEC Encoding ID130を割り当てます: 「コンパクトなFEC」に名前スペースをコード化します。 FEC Encoding ID130に関連しているFEC有効搭載量ID形式と対応するFEC Object Transmission情報はSubsections2.1と2.3で説明されます。

   As FEC Encoding ID 130 is Under-Specified, a new "FEC Instance ID"
   sub-name-space must be established, in accordance to RFC 3452. Hence
   this document also establishes a new "FEC Instance ID" registry named

FEC Encoding ID130がUnderによって指定されているように、新しい「FEC Instance ID」サブ名のスペースを確立しなければなりません、RFC3452との一致で。 したがって、また、このドキュメントは指定された新しい「FEC Instance ID」登録を確立します。

   ietf:rmt:fec:encoding:instance:130

ietf: rmt:fec:コード化:例:130

   and scoped by

見られる

   ietf:rmt:fec:encoding = 130 (Compact FEC)

ietf:rmt:fec: =130をコード化すること。(コンパクトなFEC)

   As per RFC 3452, the values that can be assigned within
   ietf:rmt:fec:encoding:instance:130 are non-negative numeric indices.
   Assignment requests are granted on a "First Come First Served" basis.
   RFC 3452 specifies additional criteria that MUST be met for the
   assignment within the generic ietf:rmt:fec:encoding:instance name-
   space.  These criteria also apply to
   ietf:rmt:fec:encoding:instance:130.

RFC3452、ietfの中で割り当てることができる値に従って: rmt:fec:コード化:例:130は非否定的な数値インデックスリストです。 課題要求は「先着順」ベースで承諾されます。 RFC3452は一般的なietf:rmt:fecの中の課題のために満たさなければならない追加評価基準を指定します: : 例をコード化して、スペースを命名してください。 また、これらの評価基準はietfに適用されます: rmt:fec:コード化:例:130。

7.  References

7. 参照

7.1.  Normative References

7.1. 引用規格

   [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は「信頼できるマルチキャスト輸送(RMT)ブロックとプロトコル具体化ドキュメントのためのガイドラインを書きます」、RFC3269、2002年4月。

   [4] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and
       J. Crowcroft, "Forward Error Correction (FEC) Building Block",
       RFC 3452, December 2002.

[4] Luby(M.、Vicisano、L.、Gemmell、J.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト)は「エラー修正(FEC)ブロックを進めます」、RFC3452、2002年12月。

Luby & Vicisano               Experimental                     [Page 11]

RFC 3695                      FEC Schemes                  February 2004

Luby&Vicisanoの実験的な[11ページ]RFC3695FECは2004年2月に計画します。

   [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] 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.

[6]WhettenとB.とVicisanoとL.とカーモードとR.とハンドレーとM.とフロイドとS.とM.Luby、「多くへの1のための信頼できるマルチキャスト輸送ブロックバルク・データ転送」、RFC3048、2001年1月。

7.2.  Informative References

7.2. 有益な参照

   [7] 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.

[7]LubyとM.とVicisanoとL.とGemmellとJ.とリゾーとL.とハンドレーとM.とJ.クロウクロフト、「信頼できるマルチキャストにおける前進型誤信号訂正(FEC)の使用」、RFC3453、2002年12月。

8.  Authors' Addresses

8. 作者のアドレス

   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コクチマスSystems Inc.170の西タスマン博士、サンノゼ(カリフォルニア)、米国95134

   EMail: lorenzo@cisco.com

メール: lorenzo@cisco.com

Luby & Vicisano               Experimental                     [Page 12]

RFC 3695                      FEC Schemes                  February 2004

Luby&Vicisanoの実験的な[12ページ]RFC3695FECは2004年2月に計画します。

9.  Full Copyright Statement

9. 完全な著作権宣言文

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78 and
   except as set forth therein, the authors retain all their rights.

Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Luby & Vicisano               Experimental                     [Page 13]

Luby&Vicisano実験的です。[13ページ]